Modelagem de Classes de

Projeto

Prof.Júlio Martins
 Da Análise ao Projeto
● No desenvolvimento de um Sistema OO, a mesma
representação para as classes é utilizada durante a
análise e o projeto desse sistema
○ Vantagem
■ Há uma uniformidade na modelagem do
sistema
○ Desvantagem
■ Torna menos nítida a separação entre o que é
feito na análise e o que é feito no projeto

2
 Da Análise ao Projeto
● Na fase de análise, estamos interessados em
identificar as funcionalidades e classes do sistema
○ Modelo de casos de uso, Modelo de classes de
análise

3
 Da Análise ao Projeto
● Esses modelos são interessantes para ENTENDER o
problema

● No projeto
○ Diversos as aspectos relacionados à solução
○ Nessa fase o interesse é: refinar os modelos de
análise

4
 Da Análise ao Projeto
● A fase de projeto = solução do problema relativo ao
desenvolvimento do sistema

● Além disso, essa fase deve aderir a certos princípios

de projeto para alcançar uma qualidade desejável no
produto de software final

● Após a realização do projeto de um sistema OO, os

modelos estão em um nível bacana para que?
○ Fornece detalhamento suficiente para
implementação

5
 Da Análise ao Projeto
● Algumas atividades
○ Detalhamento dos aspectos dinâmicos do sistema
○ Refinamento dos aspectos estáticos e estruturais
do sistema
○ Definição de estratégias de persistência
○ Realização do projeto de interface gráfica
○ Definição dos algoritmos

6
 Modelo de Classes de Projeto
● O modelo de classes de projeto é resultante de
refinamentos no modelo de classes de análise

● Esse modelo é construído em paralelo com o modelo

de interações

● O modelo de classes de projeto contém detalhes úteis

para a implementação das classes nele contidas

7
 Modelo de Classes de Projeto
● O modelo de classes de projeto é resultante de
refinamentos no modelo de classes de análise
○ Adição de novas classes
○ Estudo de novos elementos do diagrama de
classes
○ Especificação de atributos, operações e de
associações
○ Utilização de padrões de projeto

8
Especificação de Classes de Fronteira
● Não devemos atribuir a essas classes
responsabilidades relativas à lógica do negócio
○ Devem servir como um ponto de captação de
informações ou de apresentação de informações
○ Qual o motivo disso?
○ Modificação mais fácil e coesão

9
Especificação de Classes de Fronteira
● Podemos representar
○ Interfaces com seres humanos
■ Projeto da interface gŕafica produz o
detalhamento das classes
○ Outros sistemas
■ Definição de um subsistema

10
Especificação de Classes de Entidade
● A maioria das classes de entidade permanece na
passagem da análise para o projeto

● Um aspecto importante é o modo que podemos

identificar cada um de seus objetos unicamente
○ A maioria dos objetos de entidade devem ser
armazenados de forma persistente
○ Exemplo: Objeto da Classe Aluno é identificado
pelo valor se sua matrícula

11
Especificação de Classes de Controle
● Normalmente cada classe de controle deve ser
particionada em duas ou mais outras classes para
controlar diversos aspectos da solução
○ Objetivo: evitar a criação de uma única classe com
baixa coesão e alto acoplamento

● Tarefas
○ Coordenar a realização de um caso de uso do
sistema
○ Ponte entre objetos de fronteira e entidade
○ Se comunicar com outros controladores

12
Especificação de Outras Classes
● Classes de:
○ Persistência de objetos
○ Autenticação
○ Configuração
○ Threads e etc

13
Refinamento de Atributos e Métodos
● Atributos
○ Permitem que uma classe armazene informações
necessárias à realização de suas tarefas

● Métodos
○ São funções que manipulam os valores dos
atributos, com o objetivo de atender às
mensagens que o objeto recebe

14
Refinamento de Atributos e Métodos

15
Visibilidade e Encapsulamento

16
Projeto de Métodos
● Métodos de construção (criação) e destruição de
objetos

● Métodos de acesso (getX/setX)

● Métodos para manutenção de associações (conexão

entre objetos)
● Outros métodos
○ Formatação, conversão, métodos utilitários...

17
Projeto de Métodos
● Alguns métodos devem ter uma operação inversa
óbvia
○ Exemplo: habilitar e desabilitar; tornarVisível e
tornarInvisível; cadastrar e remover e etc

18
Associações

19
Detalhamento de Métodos
● Diagramas de interação fornecem um indicativo sobre
como métodos devem ser implementados

● Notas Explicativas também são úteis no

esclarecimento de como um método deve ser
implementado

20
Especificação de Associações

21
O Conceito de Dependência
● O relacionamento de dependência indica que uma
classe depende dos serviços fornecidos por outras
classe

22
O Conceito de Dependência
● O Diagrama indica que a Classe Pedido depende de
uma classe Item
● Portanto se modificar um método da Classe Item,
pode haver danos na classe dependente

23
Navegabilidade de Associações
● Associações podem ser bidirecionais ou
unidirecionais
○ Uma associação bidirecional indica que há um
conhecimento mútuo entre os objetos associados

○ Uma associação unidirecional indica que apenas

um dos extremos da associação tem ciência da
existência da mesma

24
Navegabilidade de Associações
● A escolha da navegabilidade de uma associação pode
ser feita através do estudo dos diagramas de
interação
○ O sentido de envio das mensagens entre objetos
influencia na necessidade ou não de
navegabilidade em cada um dos sentidos

25
Navegabilidade de Associações

26
Implementação de Associações
● Há três casos da conectividade
○ 1:1
○ 1:N
○ N:M

27
Implementação de Associações
● Para uma associação 1:1 entre duas classes A e B
○ Se a navegabilidade é unidirecional no sentido de
A para B, é definido um atributo do tipo B na
Classe A
○ Se a navegabilidade é bidirecional, podemos
aplicar o procedimento acima para as duas classes

28
Implementação de Associações
● Para uma associação 1:N ou N:M entre duas classes A e
B
○ São utilizados atributos cujos tipos representam
coleções de elementos

29
Conectividade 1:N

30
Herança
● Herança Múltipla
● Herança Simples

31
Classes Abstratas
● Geralmente, a existência de uma classe se justifica
pelo fato de haver a possibilidade de gerar instâncias
a partir da mesma
○ Essas classes são chamadas de classes concretas

● No entanto, podem existir classes que não geram

instâncias “diretamente”
○ Essas são chamadas de classes abstratas

32
Classes Abstratas

33
Classes Abstratas

34
Operações Polimórficas
● Pode ser que o comportamento de alguma operação
herdada seja diferente para a subclasse

● Nesse caso, a subclasse deve redefinir o

comportamento da operação
○ A assinatura da operação é reutilizada
○ Mas, a implementação da operação (ou seja, seu
método é diferente)

35
Operações Polimórficas

36
Operações Polimórficas

37
Interfaces
● Uma interface entre dois objetos compreende um
conjunto de assinaturas de operações
correspondentes aos serviços dos quais a classe do
objeto cliente faz uso

● Uma interface pode ser interpretada como um

contrato de comportamento entre objeto cliente e
eventuais objetos fornecedores de um determinado
serviço

38
Interfaces

39
Padrões de Projeto
● É da natureza do desenvolvimento de software o fato
de que os mesmos problemas tendem a acontecer
diversas vezes
○ Um padrão de projeto corresponde a um esboço
de uma solução reusável para um problema
recorrente

40
Padrões de Projeto
● Estudar esses padrões é uma maneira efetiva de
aprender com a experiência dos outros

● O texto clássico sobre o assunto é o “Design Patterns:

Elements of Reusable Object-Oriented Software
○ Esses autores são conhecidos como Gang of Four
○ Nesse livro, os autores catalogaram 23 padrões

41
Referências

● Princípios de Análise e Projeto de Sistemas com UML

2015

● Slides do professor Marcos de Oliveira

42
Questions?

E-mail:
juliomserafim@gmail.com

43