Neste curso, assumimos que você já sabe desenvolver programas pequenos em Java, mas você talvez não se sinta ainda confortável em projetar programas mais complexos com método e organização. O objetivo deste curso é fazer você compreender os princípios de orientação a objetos por meio da linguagem Java e saber como eficientemente aplicar esses princípios na prática quando projetando e desenvolvendo software de maneira ágil. Os conceitos discutidos e experimentados por você neste curso serão a base para você poder compreender os novos conceitos apresentados nos cursos seguintes desta especialização. Os conceitos Java apresentados neste curso incluem o seguinte: revisão de conceitos básicos de orientação a objetos, tais como classes, objetos, métodos e atributos, variáveis de instância e de classe; responsabilidades, colaborações e cartões CRC; testes de unidade, uso de plataforma IDE como o Eclipse; herança, classes concretas e abstratas, interfaces, modificadores de acesso, encapsulamento, métodos de acesso; aprofundamento nos conceitos de polimorfismo, sobrecarga e sobreposição; associação de classes, agregação e composição; exceções, delegação e acoplamento abstrato. Em seguida, vocês serão apresentados aos principais princípios usados para organizar o desenvolvimento de programas orientados a objetos com qualidade, dentre os quais, os princípios "Tell, Don't Ask!" e "Law of Demeter". Sempre que conveniente, cada conceito será representado por meio de diagramas UML. Você será exposto a propriedades e anotações em Java. Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que você será capaz de implementar versões iniciais do componente de gamificação constante do Trabalho de Conclusão da Especialização, com base nas boas práticas exercitadas neste curso.
Diagrama de Classes UML: Classe, Associação e Multiplicidade
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
Orientação a Objetos com Java
852 classificações
Na lição
Testes de Unidade, Diagramas UML, Colaboração e Dependência
Olá! Bem-vindo à semana 3 do curso Orientação a Objetos com Java! Nesta semana você aprofundará seu contato com Testes de Unidade e Diagramas de Classe da UML, bem como com os conceitos de dependência e contrato de classe. Ao final desta semana, você será capaz de: 1) testar com JUnit o comportamento de classes em Java; 2) projetar e representar classes com diagrama de classes da UML
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[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.
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
