POO 25 DiagramaClasses

Prévia do material em texto

DIAGRAMA DE CLASSES 
UML
Thaís Alves Burity Rocha
Agenda
 UML
 Introdução
 Diagrama de Classes
 Ferramentas
 Exercício
Introdução
 Para construir uma casa é necessário uma planta
 Para construir software de qualidade é necessário
um projeto (arquitetura)
 Como projetar software?
 Linguagem natural é muito imprecisa
 Código é muito preciso, mas muito detalhado
 Não é qualquer pessoa que o compreende
 Resposta: Modelos
Modelagem de Sistemas
 Um modelo é uma simplificação da realidade
 Descreve um sistema a partir de uma perspectiva
 Logo, existem diversos modelos, com diferentes níveis 
de detalhamento e público-alvo
 Modelos ajudam a entender o sistema em 
desenvolvimento
 Modelos são mais úteis se escritos em uma notação
padronizada
 Linguagens de modelagem
UML: Visão Geral
 UML: Unified Modeling Language (1995)
 Linguagem padrão para modelagem OO
 Embora possa ser usada fora desse contexto
 Não define como a modelagem deve ser 
conduzida
 Define 13 tipos de diagrama
 Diagrama de Classes (Class Diagram)
 Descreve os vários tipos de objetos no sistema e o 
relacionamento entre eles
 Objetos de uma mesma classe compartilham os mesmos
atributos, operações, relacionamentos e semântica
 Dentre outros elementos
 Exemplos:
Diagrama de Classes: Descrição
+ : Público
# : Protegido
- : Privado
Diagrama de Classes: Relacionamentos
 Uma vez definidas as classes, é necessário relacioná-las
 Relacionamentos entre classes expressam ligações ou 
comunicação entre os objetos
 Exemplo: Uma conta pertence à um cliente
 Principais tipos de relacionamento
 Associação: Agregação, Composição e Classe de 
associação
 Generalização
 Realização
 Dependência
Diagrama de Classes: Associação
 Relacionamento estrutural entre instâncias de 
classes distintas
 Significa que as classes trabalham de forma conjunta
 É uma alternativa à representação de atributos
 Exemplo: Uma instância de Professor está associado 
à uma instância de Disciplina
Diagrama de Classes: Agregação
 É um tipo especial de associação
 Representa relacionamentos todo-parte
 A classe que possui a regra do todo é composta de 
outras classes, que possuem a regra das partes
 Há dois tipos:
 Agregação simples (ou agregação)
 Agregação de composição (ou composição)
Diagrama de Classes: Agregação
Simples (Agregação)
 As partes existem independente do todo
 Caracteriza uso
 Exemplo:
Todo: Controla o 
relacionamento
Parte
class Carro{
private Roda[] rodas;
public Carro(Roda[] rodas){
this.rodas = rodas;
}
...
}
Os objetos foram instanciados fora da 
classe Carro e atribuídos no construtor
Diagrama de Classes: Agregação de 
Composição (Composição)
 As partes não existem sem o todo, ou seja, se o 
todo é destruído, as partes também o são
 Caracteriza posse
 Exemplo:
class Livro{
private Capitulo[] caps;
public Livro(int n){
this.caps = new Capitulo[n];
for(Capitulo cap: caps){
cap = new Capitulo();
} 
}
...
}
Todo Parte
Os objetos Capitulo foram 
instanciados no construtor da 
classe Livro. Quando o objeto 
Livro for destruído, seus 
capítulos também serão.
Diagrama de Classes: Classe de 
Associação
 Usada para definir atributos e operações
referentes ao relacionamento entre classes
Diagrama de Classes: Generalização
 Relacionamento de herança entre classes
 Classes específicas herdam atributos e operações da
classe base
 Classes específicas podem sobrepor operações, bem
como adicionar atributos e operações
Classe base
Classe
específica
Diagrama de Classes: Dependência
 Informa que uma classe depende de outra para
executar alguma operação
 Passagem de parâmetro, chamada de método, …
 Relacionamento não estrutural (uso)
 Mudanças na classe independente geralmente
afetam a classe dependente
Dependente
Diagrama de Classes: Realização
 Relacionamento entre uma interface e uma classe
que implementa a interface
estereótipo
Diagrama de Classes: Classes 
Abstratas
O nome da
classe fica
em itálico
Generalização
Operações
abstratas ficam
em itálico
Diagrama de Classes: Diretrizes
 No geral, deve-se primar pela simplicidade
 Usar todos os recursos em um único diagrama confunde
 O nível de detalhamento é definido pelo objetivo
do diagrama
 No geral, modelar todo o sistema não é necessário 
e em alguns casos, inviável
 Apesar disso, o diagrama de classes do projeto 
deve conter tudo
 No diagrama, resumir todas as classes de GUI em uma 
única
Exercício
 Criar diagrama de classes para o sistema bancário
Ferramentas
 Astah Community
 http://astah.net/download#community
 Umbrello UML Modeller
 http://uml.sourceforge.net/
 Microsoft Visio
 http://office.microsoft.com/pt-br/visio/
 Rational Rose
 http://www-
03.ibm.com/software/products/us/en/ratirosefami/
Referências
 http://www.uml.org/
 Craig, L. Utilizando UML e Padrões - Uma 
introdução à análise e ao projeto orientados a 
objetos e ao desenvolvimento iterativo, Ed. 
Bookman, 2007.
 Fowler, M. UML Essencial: Um Breve Guia para 
Linguagem Padrão, Ed. Bookman, 2005.
 Booch, G., Rumbaugh, J., Jacobson, I. UML – Guia
do Usuário, Ed. Elsevier, 2006.