[MÚSICA] Olá! Bem vindo ao curso de Orientação a Objetos com Java, meu nome é Clovis Fernandes. Hoje iremos tratar de diagramas de classes no contexto da UML. Nesta primeira parte iremos ver alguns conceitos iniciais tais como a própria classe, como se representam atributos e responsabilidades forma de diagramas, vamos falar de associação entre uma classe e outra e os conceitos que estão envolvidos com associação. Já a parte de multiplicidade e navegabilidade diante e agregação, composição e herança, iremos falar disso tudo na parte 2. O diagrama de classes, ele é uma ferramenta muito importante para registrar todas as classes de sistema que está sendo desenvolvido. Ele ajuda a mostrar todos os relacionamentos entre as classes e ajuda a raciocinar, a pensar sobre o que é que estamos fazendo, se estamos fazendo bem certo, ou se podemos melhorar a nossa estrutura de classes que nós estamos desenvolvendo. Então o primeiro passo é trabalhar com modelagem CRC, trabalhamos com cartões CRC, depois começamos a desenvolver os nossos programas numa linguagem de programação e para ajudar a organizar isso muitos momentos estaremos construindo diagramas de classes. Para isso vai ser importante revisitar esse assunto. Muitos de vocês já devem ter trabalhado com diagramas de classes, obviamente, iremos aqui então revisitar esse assunto para consolidar o conhecimento de vocês no assunto. Mais tarde outros momentos, deste curso e dos próximos cursos iremos sempre apresentar os nossos conceitos com base diagramas da UML, ou diagramas de classe ou diagramas de sequência, e outros diagramas. Para exemplificar apresento de cara diagrama de classes de uma aplicação que envolve pedidos de compra de alguma coisa. Então estão envolvidos classes cliente, que faz pedidos, os pedidos estão organizados na forma de linhas, de items de produto, fazendo uso da classe detalhePedido e por sua vez tem os items de produto associados. O pagamento também está associado a pedido, porque todo o pedido algum momento vai ser pago e esse pedido vai ser pago através de cartão de crédito, ou dinheiro, ou cheque e ao longo dessas duas partes nós iremos mostrar os vários conceitos que estão aí representados nesse diagrama. Ele vai ser muito usado, a maioria das nossas explicações vão girar torno desse diagrama, ou outro assunto que eu complemento com algum diagrama adicional. Vamos começar então a mostrar como é que é uma classe, como é que uma classe fica representada num diagrama UML. Tem 3 partes: o nome, os atributos e as operações ou métodos. Eu estou mostrando para vocês a classe de Pedidos relacionada com a DetalhePedido e a de Pagamento. O relacionamento entre as classes é que é importante. A representação anterior eu mostrei para vocês apenas e tão somente 2 atributos na classe Pedido e 3 métodos na classe Pedido. Aqui vocês estão vendo, nós estamos com mais informação. Porquê? Existem algumas informações que são implícitas, então o relacionamento da classe Pedido com DetalhePedido fica implícito estruturas de dados que relacionam DetalhePedido e aí a gente está chamando essa estrutura de dados item de linha, de cada pedido. Vai ter várias linhas com os seus pedidos, esse seria item de linha Temos também na classe Pagamento que a classe Pedido ela se refere a pagamento. Então tem atributo implícito que eu estou explicitando, não é, esses 2 atributos, agora nesse momento que é o Pagamento. Uma classe ela pode estar representada num diagrama de classes e eu não preciso apresentar todas as informações, porque existe esse relacionamento com as outras classes. Aulas futuras nós iremos trabalhar isso, a gente chama isso de arquitetura do código. Essa arquitetura fica uma arquitetura implícita, eu não preciso ficar mostrando. Ao mesmo tempo, ela me ajuda a codificar porque essa arquitetura tem certo formato padrão. Nós veremos isso mais para a frente, agora estamos olhando apenas a parte de diagramas. Nós temos o nome da classe e logo abaixo nós temos os atributos. Então aí no caso, nós temos atributo, data, cujo valor vai ser dado por objeto da classe Date do Java, por exemplo, no nosso exemplo aqui. Temos também o atributo status, cujo valor vai ser inteiro por isso nós estamos rotulando ele como int. Já o item de linha, ele vai ser detalhe de pedido, ele vai ser conjunto de objetos de detalhe de pedido. O atributo linhaPedido representa objetos de DetalhePedido, eu posso representar de 0 ou mais linhas de pedido. Isso fica representado pelo 0..* Eu estou querendo dizer é exatamente isso, que eu posso ter mais número indeterminado, não é, inclusive nada não é, de detalhes de pedido, objetos detalhes de pedido. Já do pagamento, vai conter objetos do tipo, ou da classe pagamento, então ele vai ser ou mais objetos da classe Pagamento. Vai ser 1 se o pagamento for 1 pagamento apenas, agora se você parcelar esse pagamento, vai ser ou mais até ao limite do parcelamento que você deu. Acabamos de falar sobre os atributos mas eu queria ressaltar que os atributos linhaPedido e pagamento, como eles são relacionados, ou seja são colaborações dos objetos detalhePedido e pagamento, a gente também costuma chamar esses atributos de relacionamentos. Os anteriores são atributos que faz uso ou de valores de dados, como int, double, string, ou usam classes que são próprias do Java como o Date, por exemplo. Já os 2 atributos com relacionamentos são relacionamentos de objetos de classes da nossa aplicação, por isso a gente chama de relacionamentos. Então nós temos o nome da classe, os atributos e agora eu vou mostrar para vocês as responsabilidades, operações ou métodos. Como é usual Java, iremos chamar as operações ou responsabilidades nesse momento de métodos. Quando estivermos tratando da parte de design, ou princípios, muitas vezes voltaremos a falar responsabilidade. Normalmente os atributos, porque é que a gente separou atributos dos métodos? Princípio, todos os atributos vão ser privados, ou seja quando eu criar objeto dessa classe por exemplo, as variáveis de instância vão ser inicializadas para esses valores e exteriormente, de forma externa ao objeto, ninguém vai poder acessar isso, a não ser através de operações ou métodos que nós vamos descrever logo a seguir. Então, princípio, nós não iremos ter atributos que não sejam privados, sempre vai ser privado, por definição, está ok? Por definição vai ser privado. Nós vamos fornecer meios de quem necessitar desses valores poder usar, está ok? Já as responsabilidades nós temos 3 tipos de responsabilidades, com relação à visibilidade, ou seja, quem vai enxergar do lado de fora objeto dessa classe, se for privado não tem acesso, então os dados, os atributos não tem acesso. Os métodos que também forem privados, que estão representados com menos antes, também ninguém vai ter acesso, só internamente na classe que vai poder usar esse método como por exemplo o getAliquota. Já os métodos getter e setter, são métodos de acesso aos atributos, falamos que os atributos são privados, então a gente coloca métodos para acessar esses atributos não só objetos dessa classe mas objetos de subclasses dessa classe. Por isso que os getter e setter por definição também, uma convenção Eles são protegidos, esse jogo da velha significa que a classe pode usar internamente, ninguém de fora pode usar esses métodos. Mais para a frente, nós veremos que de acordo com o projeto pode ser que alguns desses métodos de acesso, getter e setter, sejam públicos por necessidade do projeto, mas por definição também eles ficariam como protegido. E nós temos 3 métodos chamados de públicos, que estão representados pelo "mais", no qual a visibilidade de objetos dessa classe vão permitir que outros objetos possam referenciar esses métodos, mandar mensagens para objetos dessa classe usando esses métodos. Essa questão da visibilidade é isso, é para organizar quem pode acessar o quê no meu objeto. A gente chama isso de ocultação da informação, a gente só coloca na interface da classe ou do objeto aquilo que a gente quer que seja visto. Aquilo que a gente quer esconder a gente coloca como privado ou protegido. Nem sempre eu preciso representar uma classe usando todas as informações que uma classe deve ter. O mínimo é o nome da classe, isso a gente tem que colocar. Mas eu posso às vezes representar apenas o nome, eu posso representar usando o nome e alguns atributos, se naquele momento eu estou querendo enfatizar esses atributos, e posso também usar o nome, não colocar atributo nenhum e colocar alguns dos métodos públicos ou os métodos públicos. Não preciso representar os métodos privados ou protegidos, posso deixar isso de lado, porque muitas vezes as classes têm número muito grande de atributos e de métodos e isso torna a classe muito cheia, muito carregada visualmente. Isso dificulta na hora de fazer uma análise. Dependendo da hora, da situação, eu vou usar uma forma de representar ou outra. Se vocês lembram quando eu mostrei a modelagem CRC, eu representei as dependências entre as classes usando apenas os nomes das classes, e é isso que nós iremos fazer algumas vezes também. Quais são os relacionamentos entre classes que iremos apresentar ou revisitar ao apresentar diagramas de classes? São as associações, agregação e composição, que são 2 tipos de associação, herança e dependência. Dependência nós já falamos quando falamos de cartões CRC e iremos tratar disso outras aulas também. Então na apresentação do diagrama de classes eu não vou me ater a explicar mais detalhes sobre dependência agora, mas mais para a frente e com certeza ao longo dos cursos que apresentaremos a questão de dependência será bem tratada, porque é muito importante que os nossos programas, as nossas classes tenham acoplamento melhor. Ter acoplamento melhor significa ter menos dependência de uma classe com outra. Estritamente aquilo que for necessário. Então vamos começar a falar sobre associação. Então o diagrama de classes que nós apresentamos eu recortei apenas uma parte com as classes Cliente, Pedido e Pagamento e mostro dois tipos de associação. O quê que é uma associação? Uma associação é alguma colaboração, alguma dependência, alguma forma de relacionar uma classe com outra. Normalmente para tornar isso mais prático e fácil de a gente fazer, nós colocamos rótulos nisso. Então por exemplo o Cliente faz Pedido. Olha a gente está fazendo uma frase não é? Está certo? Que isso está representado nesse diagrama, já no outro o pedido refere-se a pagamento. Então isso aqui é uma outra, é uma outra associação. Então é uma classe associada à outra. Normalmente a gente consegue colocar rótulos, que geral os rótulos são verbos que fazem a ligação de uma classe com outra, são proposições. No diagrama vocês notam que entre Cliente e Pedido normalmente o Cliente ele faz, suponha que isso fosse por exemplo pedido num restaurante, a pessoa está fazendo o pedido só para ela, só ela que foi no restaurante. Então inicialmente não existia pedido nenhum, quando o cliente faz o pedido ele passa a ser pedido e estaria associado ao objeto Cliente. Agora imaginem vocês que eu esteja querendo pagar a conta dos meus colegas. Então eu fui com 3 colegas, então são 4 pedidos no total. Então o Cliente faz, ali está marcado 0 até asterisco, asterisco significa número indefinido, né, está certo? Então o Cliente faz 4 pedidos, seria nesse momento, ou seja, eu posso fazer de 0 ou não faço pedido nenhum, levanto e vou embora, ou faço até 4 no meu exemplo. Isso a gente chama de multiplicidade. A multiplicidade se refere ao conjunto de objetos que eu posso instanciar relativo a tipo de associação. Então por exemplo na associação Cliente, se estiver olhando esse lado, Cliente faz Pedido, o Cliente vai fazer 0 ou mais pedidos, ou seja, vão ser criadas 0 ou mais instâncias da classe Pedido, vão ser objetos da classe Pedido. Acabei de falar de multiplicidade olhando da classe Cliente para Pedido e eu representei eles cor-de-rosa e verde exatamente para mostrar que o Cliente está associado a 0 ou mais Pedidos. E o Pedido está associado a exatamente Cliente. Já o outro relacionamento de Pedido com Pagamento, Pagamento está azul, o pedido se refere a 1 ou mais Pagamentos, ou seja, se eu tiver 1 Pedido só eu vou fazer Pagamento. Não faz sentido ter 0 Pagamentos aqui, não, a cada Pedido tem que ter 1 Pagamento, por isso que fica 1 ali, de 1 ou mais. Agora, se eu por exemplo parcelei esses Pagamentos, então eu posso ter 1, 2, 3 Pagamentos ou mais. É isso que está querendo dizer esse relacionamento, essa associação, essa multiplicidade para essa associação entre Pedido e Pagamento, está verde. O contrário: Pagamento relação a Pedido ele tem associação, a cada Pagamento vai existir apenas 1 Pedido, não faz sentido ter 0 nem ter mais do que 1, é exatamente 1 pedido. Já quando a multiplicidade é 1, ou seja, aproveitando o exemplo de livro e usuário de biblioteca, toda vez que livro é emprestado a usuário de biblioteca ele fica sabendo, ele vai ser marcado na lista de livros daquele usuário. Mas só vai existir usuário associado ao livro, ou seja, eu posso ter livro associado a 0 ou 1 usuário. Por isso que quando a gente trabalhou com essas classes eu mostrava a disponibilidade do livro usando usuário para representar a disponibilidade, se o usuário não tinha emprestado era 0 usuário, o livro estava disponível, mas na hora que eu emprestei, eu emprestei para 1 usuário. Então esse 0 e 1 é opcional. Agora é o contrário: o usuário ele tem relacionamento com livro, ao ter esse relacionamento com livro, nesse meu exemplo obviamente, esse 1 a gente chama de obrigatório, enquanto que 0 dois pontos 1 é opcional quando está só o 1, ele é obrigatório, a associação é obrigatória. Essa associação é obrigatória, ou seja, eu estou dizendo exatamente que o usuário está associado a 1 e somente 1 livro. Quando é 0 dois pontos 1, a multiplicidade a gente chama de opcional. Então nesse nosso exemplo eu já mostrei para vocês. Agora podemos generalizar isso para n dois pontinhos m, onde o n e o m podem ser qualquer valor finitos, a gente não vai trabalhar com valores muito grandes, está certo? Então por exemplo Veículo está associado com Roda e eu coloquei ali "Veículo tem 1 a 6 rodas" como exemplo. Então eu posso ter veículos, como por exemplo o primeiro desenho que eu mostro aqui para vocês, a primeira imagem, é monociclo, não é qualquer que vai andar nele, mas é monociclo, só tem uma roda. Já o último carro ali, bom depois nós temos bicicleta, skate, carro, triciclo com os outros números de rodas, eventualmente não tenha com 5 rodas, pelo menos eu não conheço, mas com 6 existem vários. Nesse exemplo que eu mostro para vocês tem carro da Fórmula 1 antigo que teve 6 rodas, nós temos também SUVs modernas que estão saindo com 6 rodas também. Então no nosso exemplo eu estou querendo dizer que a multiplicidade é de número a outro, pode ser de 1 a 6 como nesse exemplo mas pode ser por exemplo de 4 a 6. Se eu estiver falando só de carros, que tenham 4 ou mais rodas, então poderia ser de 4 a 6, de 4 a 8 se tiver carros com 8 rodas. Concluímos assim a primeira parte dessa apresentação sobre diagrama de classes que falamos sobre como representar as classes, como representar as associações até o item de multiplicidade. Na próxima aula iremos dar continuidade a isso, falaremos da questão de navegabilidade entre uma classe e outra, associação do tipo agregação, associação do tipo composição e herança. Obrigado.
