© Ricardo Pereira e Silvawww.inf.ufsc.br/ricardo
ObjetivoApresentar o diagrama de classes de UML
Seus elementos sintáticosSua finalidade em um processo de modelagem
© Ricardo Pereira e Silva
Diagrama de classesResultado do esforço mais primitivo de
geração de modelos gráficos que descrevessem um programa orientado a objetos
Reflete a estrutura do códigoClasses
Cada classe com seus atributos e métodosRelacionamentos envolvendo classes
© Ricardo Pereira e Silva
Aparência do diagrama de classes
© Ricardo Pereira e Silva
Finalidade do diagrama de classesModelar os elementos de um programa
orientado a objetos em tempo de desenvolvimentoClasses com seus atributos e métodos
Modelar os relacionamentos entre classes, de forma mais explícita que aquela do códigoHerançaAgregação (e composição)Associação
© Ricardo Pereira e Silva
Representação de classe
© Ricardo Pereira e Silva
Representação de atributoExemplos
ocupante# ocupante: Jogador# jogadores: Jogador [2..5] {ordenado, único}
Sintaxe de UML para representação de atributo[<visibilidade >] [‘/’] <nome> [‘:’ < tipo >] [‘[‘ <multiplicidade> ‘]’] [‘=’ <valor_inicial>][‘{‘ <propriedade> [‘,’ < propriedade >]* ’}’]
© Ricardo Pereira e Silva
Representação de atributo
Pode ser representado dentro da figura de classe ou por meio de uma seta (associação unidirecional)
© Ricardo Pereira e Silva
Representação de métodoExemplos
+ iniciar()+ alocarPeao (onde : Posicao, quem: Jogador):
booleanSintaxe de UML para representação de
método[<visibilidade>] <nome> ‘(‘
[<lista_parametros>] ‘)’ [‘:’ [<tipo_retorno>] ‘{‘ <propriedade> [‘,’
< propriedade >]* ‘}’]
© Ricardo Pereira e Silva
Recomendação para estabelecimento de visibilidade Atributos → protegidos
Princípio da ocultação de informação do paradigma de orientação a objetos
Possibilita que atributos herdados ou definidos na classe sejam tratados de maneira uniforme
Necessidades específicas podem justificar atributos privados
Atributos públicos → JAMAIS
© Ricardo Pereira e Silva
Recomendação para estabelecimento de visibilidade Métodos → públicos
O meio externo acessa uma classe através de seus métodosNecessidades específicas podem justificar o aumento de
restrição de visibilidade
© Ricardo Pereira e Silva
Métodos concretos e abstratosMétodo concreto → composto por
assinatura e corpoPode ser invocado em tempo de execução para
cumprir a responsabilidade atribuída a ele
© Ricardo Pereira e Silva
Métodos concretos e abstratosMétodo abstrato → composto apenas por
assinaturaUma declaração de responsabilidade, mas sem
a capacidade de cumpri-la, em função da ausência de algoritmo
Grafado em itálico
© Ricardo Pereira e Silva
Classes concretas e abstratasClasse concreta → possui exclusivamente
métodos concretos
© Ricardo Pereira e Silva
Classes concretas e abstratasClasse abstrata → possui pelo menos um
método abstratoIdentificador da classe grafado em itálicoNem todas as responsabilidades da classe
materializadas em capacidades Nem todos os métodos possuem algoritmo definido Não pode originar instâncias em tempo de execução
© Ricardo Pereira e Silva
Relacionamentos – herança
© Ricardo Pereira e Silva
Herança Relação de especialização entre DUAS
classesUma delas corresponde a um conceito mais
genérico A outra, a um conceito mais específico
© Ricardo Pereira e Silva
Frase característica da herança<subclasse> é uma espécie de
<superclasse>No exemplo, estudante de graduação é uma
espécie de estudanteEstudante de pós-graduação também é uma
espécie de estudanteSe frase não faz sentido, o relacionamento de
herança é inadequadoCachorro é uma espécie de gato
© Ricardo Pereira e Silva
Herança é unidirecionalEstudante de graduação é uma espécie de
estudanteMAS estudante NÃO é uma espécie de
estudante de graduação
© Ricardo Pereira e Silva
Semântica da herançaOs atributos e métodos da superclasse são
herdados pela subclasseOs atributos e métodos da superclasse também
fazem parte da subclasseComo se tivessem sido definidos nela
© Ricardo Pereira e Silva
Níveis hierárquicos de herançaAtributos e métodos de
ClasseN herdados por todas as classes da hierarquia de herança
© Ricardo Pereira e Silva
Herança de atributosÉ inócuo definir em uma subclasse um
atributo com mesmo nome de um atributo de uma superclasse
Em qualquer nível da hierarquia de herançaEquivaleria à presença de mais de um
atributo com o mesmo nome em uma mesma classeInconsistente
© Ricardo Pereira e Silva
Herança de métodosMétodo em subclasse tem a mesma
assinatura de método definido em superclasse → sobrescrição de métodoMétodo definido na subclasse substitui o
método herdado
© Ricardo Pereira e Silva
Herança e classe abstrataClasse abstrata → possui pelo menos um
método abstrato, que pode ter sido definido na própria classe ou herdado e não sobrescritoO relacionamento de herança precisa ser
considerado na definição de classe abstrata
© Ricardo Pereira e Silva
Relacionamentos – agregação e composição
© Ricardo Pereira e Silva
Agregação e composiçãoAgregação → relacionamento entre DUAS
classes que estabelece que uma instância de uma agrupa uma ou mais instâncias da outraRelacionamento todo / parte
© Ricardo Pereira e Silva
Agregação e composiçãoComposição → um tipo de relação de agregação
com restrições na ligação entre parte e agregadoUma instância da parte é agregada por uma única
instância do agregado não há compartilhamento da parte
A existência da parte depende da existência do agregadoInstanciação do agregado precede a instanciação
da parte Destruição do agregado implica na destruição da
parte
© Ricardo Pereira e Silva
Agregação e composição – exemplo
© Ricardo Pereira e Silva
Relacionamentos – associação
© Ricardo Pereira e Silva
AssociaçãoQuando há o reconhecimento de um
relacionamento entre classes, que não pode ser caracterizado como herança e nem como agregação ou composiçãoPode ser unidirecional ou bidirecional Pode envolver mais de duas classes
A associação entre duas classes é chamada associação binária
© Ricardo Pereira e Silva
Associação com rótulo e papéis
© Ricardo Pereira e Silva
Associação com indicação de ordem de leitura
© Ricardo Pereira e Silva
Associação com navegabilidade explícita
© Ricardo Pereira e Silva
Outros relacionamentos – associações especializadasRealização → associação entre dois
elementos em que um deles especifica uma responsabilidade a ser implementada e o outro incorpora a obrigação de implementá-laUsado para associar uma classe a uma
interface
© Ricardo Pereira e Silva
Outros relacionamentos – associações especializadasDependência → associação entre dois
elementos em que um deles é declarado como dependente daquilo que deve estar implementado em outroUm é cliente dos serviços oferecidos pelo outro Usado para relacionar outros elementos além
de classes (como interface e classe)Usado também em outros diagramas
© Ricardo Pereira e Silva
Interfaces (semântica de Java)
© Ricardo Pereira e Silva
Vinculação de classes a uma interface previamente definida
realização dependência
© Ricardo Pereira e Silva
Estereótipo
© Ricardo Pereira e Silva
EstereótipoEstender o significado do elemento de
modelagem a que ele é associadoPode ser usado em classes para dividi-las em
categorias em uma especificaçãoPode ser associado a classes ou a qualquer
elemento de qualquer diagrama de UML
© Ricardo Pereira e Silva
ConclusãoDiagrama de classes → modelagem gráfica
mais primitiva de um programa orientado a objetosReflete a estrutura do código
Elementos sintáticos do diagramaClassesRelacionamentos
Conhecer os elementos do diagrama é requisito para usá-lo em modelagem
© Ricardo Pereira e Silva
Atividade extra-classeLer o texto de referência da presente aula
Capítulo 3, O diagrama de classes de UML, do livro UML 2 em modelagem orientada a objetos*
Exercitar a edição de diagrama em alguma ferramentaComo os diagramas apresentados nos exemplos
SILVA, Ricardo P. e. UML 2 em modelagem orientada a objetos. Florianópolis, SC: Visual Books, 2007. 232p.
© Ricardo Pereira e Silva