Análise e Projeto
Orientados a Objeto
com UML e Padrões
Parte IV
Projeto (1A)
Prof. Msc. Emerson Silas Dória
1
Da Análise ao Projeto

Artefatos de análise capturam os
resultados do processo de investigação
do domínio do problema
Modelo Conceitual
Quais são os processos do
domínio?
Quais são os conceitos, termos?
Diagramas de Seqüência do
Sistema
Quais são os eventos e
operações do sistema?
Contratos
O que fazem as operações do
sistema?
Casos de Uso
Prof. Msc. Emerson Silas Dória
2
O Começo da Fase Projetar


A partir dos artefatos da fase de análise
é desenvolvida uma solução lógica
baseada no paradigma orientado a
objetos.
Os Diagramas de Interação são a base
de tal solução lógica, posteriormente,
são criados os Diagramas de Classes de
Projeto.
Prof. Msc. Emerson Silas Dória
3
Descrevendo Casos de Uso
Reais
Refin.
Plano
Sinc.
Artefatos
Análise
Projeto
1. Definir Casos
de Uso Reais
2. Definir Rel. & IU
4. Definir Diag.
Interação
5. Definir Diag.
Classe
Impl.
Teste
3. Refinar
Arquitetura
a
b
6. Definir
Esquema do BD
Notas
a. em paralelo com
diagrama de interação
b. ordem variada
Prof. Msc. Emerson Silas Dória
4
Casos de Uso Reais

Projeto “real” de um caso de uso em termos
de tecnologias concretas de entrada/saída e
sua implementação geral


Referências a janelas, componentes da interface
com o usuário, mecanismos de interação, etc.
Necessários apenas se o desenvolvedor ou
cliente requer uma descrição minuciosa
(detalhada) da interface com o usuário antes
da implementação
Prof. Msc. Emerson Silas Dória
5
Casos de Uso Reais

Exemplo de um caso de uso real
Caso de uso:
Atores:
Finalidade:
Visão Geral:
Comprar Itens com Dinheiro
Cliente, Operador
Capturar uma venda e seu pagamento em dinheiro.
Um Cliente chega no caixa, com itens que deseja
comprar. O Operador registra os itens de compra e
recebe um pagamento em dinheiro. Ao final, o Cliente
deixa a loja com os itens.
Tipo:
Referências
Cruzadas:
Primário e Essencial
Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
Prof. Msc. Emerson Silas Dória
6
Casos de Uso Reais
Seqüência Típica de Eventos
Ação do Ator
1. Este caso de uso começa
quando um Cliente chega no
caixa (equipado com um POST)
com itens que deseja comprar.
2. Para cada item, o Operador
digita o código universal de
produto (UPC) no campo A da
Janela 1. Se houver mais de um
exemplar do item, a quantidade
pode ser digitada opcionalmente.
Ele então pressiona o botão
“Entra Item” com o mouse ou
pressiona a tecla <Enter>.
4. . . .
Object Store
A
Quantidade E
Preço
B
Descrição
F
Total
C
Troco
G
Fornecido
D
UPC
Resposta do Sistema
Entrar Item
H
Terminar Venda
Registrar Pagamento
I
J
3. Determina o preço do item e
adiciona informação sobre o item
à transação de venda corrente.
Mostra a descrição e o preço do
item corrente no campo B e F da
Janela 1.
5. . . .
Prof. Msc. Emerson Silas Dória
7
Definindo Diagramas de
Interação
Refin.
Plano
Sinc.
Artefatos
Análise
Projeto
1. Definir Casos
de Uso Reais
2. Definir Rel. & IU
4. Definir Diag.
Interação
5. Definir Diag.
Classe
Impl.
Teste
3. Refinar
Arquitetura
a
b
6. Definir
Esquema do BD
Notas
a. em paralelo com
diagrama de
interação b. ordem
variada
Prof. Msc. Emerson Silas Dória
8
Ponto de Partida

Os contratos não mostram uma solução de
como os objetos de software procederão para
satisfazer as pós-condições.
Pós-condições:
Se for uma nova venda, uma Venda foi criada
(criação de instância);
 Se for uma nova venda, a nova Venda foi
associada ao POST (formada uma associação);
 Um ItemVenda foi criado (criação de instância);
 O ItemVenda foi associado à Venda (formada
uma associação);
 . . .

Prof. Msc. Emerson Silas Dória
9
Diagramas de Interação


Um Diagrama de Interação ilustra como
os objetos interagem através de
mensagens para cumprir tarefas.
A criação de um DI depende da criação
prévia dos seguinte artefatos:

Modelo Conceitual: subsidia a definição de
classes de software correspondentes a
conceitos, cujos objetos participam dos DI;
Prof. Msc. Emerson Silas Dória
10
Diagramas de Interação

continuando...


Contratos: subsidia a definição de
responsabilidades e as pós-condições que
os DI devem satisfazer
Casos de Uso Reais ou Essencias: subsidia
a coleta de informações sobre quais tarefas
os DI ilustram, além do que está nos
contratos
Prof. Msc. Emerson Silas Dória
11
Diagramas de Interação

Diagramas de Colaboração

Ênfase na organização estrutural dos objetos que
enviam e recebem mensagens
mensagem1( )
:Instância_ClasseA
1: mensagem2( )
:Instância_ClasseB
2: mensagem3( )

Diagramas de Seqüência

Ênfase na ordenação temporal das mensagens:
:Instância_ClasseA
:Instância_ClasseB
mensagem1( )
1: mensagem2( )
2: mensagem3( )
Prof. Msc. Emerson Silas Dória
12
Diagramas de Interação

Exemplo de Diagrama de Colaboração para a
operação RegistrarPagamento:
direção da
mensagem
RegistrarPagamento(df)
primeira
mensagem
:POST
1:RegistrarPagamento(df)
:Venda
1.1:Criar(df)
instância
primeira mensagem
interna
:Pagamento
Prof. Msc. Emerson Silas Dória
13
Como Fazer um Diagrama de
Colaboração

Regras úteis:
1. Criar um diagrama em separado para cada uma
das operações de sistema em desenvolvimento.

Para cada mensagem de operação de sistema, criar um
diagrama com essa mensagem como mensagem inicial.
2. Se um diagrama se tornar muito complexo, o
diagrama deve ser dividido.
3. Utilizar as responsabilidades e pós-condições dos
contratos das operações de sistema, e a descrição
dos casos de uso para projetar um sistema cujo
objetos interajam para cumprir tarefas.
Prof. Msc. Emerson Silas Dória
14
Diagramas de Colaboração e
Outros Artefatos
:Sistema
Operador
EntrarItem(UPC,quantidade)
Sistema
Operação:EntrarItem
Pós-Condições:
1. Se tSe for uma
nova venda, uma
Venda foi criada
(criação de instância);
EntrarItem(UPC,
quantidade)
EntrarItem(UPC, quantidade)
TerminarVenda()
TerminarVenda()
RegistrarPagamento(quantia)
RegistrarPagamento(quantia)
DSS
Operações do
Sistema
Operação:
TerminarVenda
Pós-Condições:
1. Venda.Completada
recebe o valor...
Contratos
Prof. Msc. Emerson Silas Dória
:POST
Diag.
Colaboração
15
Notação Básica para DI

Classes e Instâncias
:Venda
POST
classe

p1:Pagamento
instância
instância
nomeada
Ligações, Mensagens, Parâmetros
msg1( )
:POST
1:msg1(a,b )
2:msg2( )
3:msg3( )
:Venda
Prof. Msc. Emerson Silas Dória
16
Notação Básica para DI

Valor de Retorno
msg1( )
:POST

1:tot:=total( ):integer
:Venda
Mensagem para “self” ou “this”
msg1( )
:POST
1:clear( )
Prof. Msc. Emerson Silas Dória
17
Notação Básica para DI

Iteração
msg1( )
:POST

1*:l:=proximaLinhaItem( )
:Venda
Cláusula de Iteração
* Expressa mensagem
enviada repetidamente
msg1( )
:POST
1*[i:=1..10]:l:=proximaLinhaItem( )
Prof. Msc. Emerson Silas Dória
:Venda
18
Notação Básica para DI

Seqüenciamento de Mensagens
msg1( )
:ClasseA
1:msg2( )
:ClasseB
1.1:msg3( )
2.1:msg5( )
2:msg4( )
:ClasseC
2.2:msg6( )
:ClasseD
Prof. Msc. Emerson Silas Dória
19
Notação Básica para DI

Mensagens Condicionais
msg1( )
:POST
1:[nova venda] criar( )
Expressa que a mensagem só deve ser
enviada se o valor de nova venda for
TRUE em tempo de execução.
:Venda
:ItemVenda
Prof. Msc. Emerson Silas Dória
20
Notação Básica

Caminhos Condicionais Mutuamente
Exclusivos
msg1( )
:ClasseA
1a:[test]msg2( )
:ClasseB
1.1:msg3( )
2.1:msg5( )
1b:[not test]msg4( )
:ClasseC
2.2:msg6( )
Expressa que a mensagem 1a ou 1b
podem ser executadas, dependendo do
teste lógico entre [].
:ClasseD
Prof. Msc. Emerson Silas Dória
21
Notação Básica

Coleções (multiobjects)
:ClasseB
:ClasseB
vendas:Venda

Expressa um conjunto lógico
de instâncias (Ex: Vector em Java)
Mensagens para uma coleção
msg1( )
:Venda
1:s:=size():int
:ItemVenda
:ItemVenda
:ItemVenda
Expressa uma mensagem enviada a
Java.util.Vector, por exemplo, para
descobrir o número de elementos no
Vetor (objeto coleção)
Prof. Msc. Emerson Silas Dória
22
Notação Básica

Mensagens para uma coleção e um
elemento
msg1( )
:Venda
1:criar( )
iv:ItemVenda
2:additem(iv )
:ItemVenda
:ItemVenda
:ItemVenda
Prof. Msc. Emerson Silas Dória
23
Notação Básica

Mensagens para um objeto classe
msg1( )
:Venda
1:d1:=today( ):Date
Data
Expressa uma mensagem sendo
enviada para uma classe
Prof. Msc. Emerson Silas Dória
24
Atribuição de Responsabilidades
O POO às vezes é definido como:
“Identificado os requisitos e o modelo
conceitual, acrescente os métodos às
classes de software e defina as
mensagens/troca de mensagens (DI)
para atender os requisitos”
Prof. Msc. Emerson Silas Dória
25
Atribuição de Responsabilidades


Contratos: suposição preliminar sobre as
responsabilidades e as pós-condições das
operações
Diagramas de Interação: ilustram a
solução, em termos de objetos interatuantes,
que satisfazem responsabilidades e póscondições
POO -> Atribuição de Responsabilidade ->
Bons Projetos OO
Prof. Msc. Emerson Silas Dória
26
Responsabilidades e Métodos

Responsabilidade é “um contrato ou
obrigação de um tipo ou classe” (Booch e
Rumbaugh, 1997)
 Relacionada as obrigações dos objetos em termos de
comportamento.

Tipos básicos

De fazer (alguma coisa)


Ex: fazer algo individualmente, iniciar ações em outros
objetos, controlar ou coordenar atividades em outros
objetos
De conhecer (alguma coisa)

Ex: dados privados encapsulados, objetos relacionados,
informação derivada ou calculada
Prof. Msc. Emerson Silas Dória
27
Responsabilidades e Métodos

Responsabilidades são atribuídas aos objetos
do sistema durante o Projeto OO



“Uma Venda é responsável por imprimir a si própria”
(de fazer)
“Uma Venda é responsável por conhecer sua data”
(de conhecer)
Tradução de responsabilidades para classes e
métodos é influenciada pela granularidade da
responsabilidade


Um único método para “imprimir venda”
Dezenas de métodos para “prover um mecanismo de acesso
a SGBDR”
Prof. Msc. Emerson Silas Dória
28
Responsabilidades e Métodos

Métodos são implementados para cumprir
responsabilidades


Podem agir sozinhos ou em colaboração com
outros métodos e objetos
Exemplo:


A classe Venda pode definir um ou mais métodos específicos
para cumprir a responsabilidade de imprimir
Esse método, por sua vez, pode precisar colaborar com
outros objetos, possivelmente enviando mensagens de
impressão para cada um dos objetos ItemVenda associados
à Venda.
Prof. Msc. Emerson Silas Dória
29
Responsabilidades e DI

Diagramas de Interação ilustram decisões de
atribuição de responsabilidades a objetos.

Quais mensagens são enviadas para diferentes
classes e objetos?
imprimir( )
Implica que objetos Venda têm uma
responsabilidade de imprimirem
a si mesmos.

:Venda
1:[para cada] iv:=next( )
2:imprimir( )
:ItemVenda
iv:ItemVenda
iv:ItemVenda
Guias práticos para facilitar a tomada de
decisões na atribuição de responsabilidades
são oferecidos pelos padrões GRASP.
Prof. Msc. Emerson Silas Dória
30
Padrões (Patterns)



“Um padrão é um par nomeado problema/solução
que pode ser aplicado em novos contextos, com
conselhos sobre sua aplicação em novas situações e
uma discussão sobre as conseqüências de seu uso.”
Capturam princípios fundamentais da engenharia de
software.
Em geral, não contêm novas idéias nem soluções originais


Codificam soluções existentes comprovadas
Podem oferecer guias de como responsabilidades
devem ser atribuídas a objetos, dada uma categoria
específica de problemas.
Prof. Msc. Emerson Silas Dória
31
Padrões GRASP
(General Responsibility Assignment Software Patterns)

Atribuição competente de responsabilidades a
objetos:



Cruciais no POO e ocorre na construção dos Diagramas de
Interação
Padrões: pares de problema/solução que
codificam orientações e princípios
freqüentemente relacionados com a
atribuição de responsabilidades.
Cinco padrões mais comuns
(Especialista; Criador;
Alta Coesão; Baixo Acoplamento; Controlador)
Prof. Msc. Emerson Silas Dória
32
Padrão
Especialista (Expert)

Solução


Problema


Atribuir responsabilidade para o especialista na
informação - a classe que tem a informação necessária para
cumprir a responsabilidade.
Qual é o princípio básico pelo qual responsabilidades são
atribuídas em POO?
Exemplo:

Quem deve ser responsável por conhecer o total de uma
venda?

Segundo o padrão EXPERT, devemos
procurar a classe de objetos que tem
Informação necessária: conhecer
todas as instâncias
a informação necessária para
ItemVenda da Venda e o subtotal
de cada
determinar
o total.uma delas.
uma instância de venda conhece isso.
Prof. Msc. Emerson Silas Dória
Somente
33
Padrão
Especialista (Expert)

Pelo padrão, a classe Venda deve ser a
responsável.
Venda
t:obter_total( )
data
hora, status
:Venda
contém
Venda
1..*
ItemVenda
quantidade
* descrito
EspecificaçãoProduto
descrição
preço
UPC
data
hora
obter_total()
Aqui ocorrem as
definições de
responsabilidade.
Modelo Conceitual Parcial
Prof. Msc. Emerson Silas Dória
34
Padrão
Especialista (Expert)

Mas quem deve ser responsável por conhecer o
subtotal de um ItemVenda?


t:obter_total( )
Informação necessária: ItemVenda.quantidade e
EspecificaçãoProduto.preço
Pelo padrão, a classe ItemVenda deve ser a responsável.
:Venda
Aqui ocorrem as
definições de
responsabilidade.
2:st:=obter_subtotal()
iv:ItemVenda
Venda
1*:[para cada]iv:next( )
:ItemVenda
:ItemVenda
data
hora
obter_total( )
ItemVenda
quantidade
obter_subtotal()
Prof. Msc. Emerson Silas Dória
35
Padrão
Especialista (Expert)

Porém, para cumprir essa responsabilidade de conhecer ou
informar seu subtotal um ItemVenda precisa conhecer o preço
do Item.

t:obter_total( )
Portanto, o ItemVenda deve mandar uma mensagem para a
EspecificaçãoProduto para saber o preço do item.
:Venda
1*:[para cada]iv:next( )
EspecificaçãoProduto
2:st:=obter_subtotal( )
iv:ItemVenda
2.1:p:=obter_preço( )
:Especificação
Produto
Venda
descrição
preço
UPC
data
hora, status
obter_preço( )
obter_total( )
:ItemVenda
:ItemVenda
ItemVenda
Aqui ocorrem as
definições de
responsabilidade.
Prof. Msc. Emerson Silas Dória
quantidade
obter_subtotal()
36
Padrão
Especialista (Expert)

Concluindo, para cumprir a responsabilidade de
conhecer e informar o total da venda, três
responsabilidades foram atribuídas a três classes de
objetos:
Classe
Responsabilidade
Venda
Conhecer total da venda
ItemVenda
Conhecer subtotal do item
EspecificaçãoProduto
Conhecer preço do produto
Prof. Msc. Emerson Silas Dória
37
Padrão
Especialista (Expert)

Contra-Indicações


Indesejável, geralmente devido ao problema do
acoplamento e coesão.
Benefícios


Mantém encapsulamento pois objetos usam sua
própria informação, favorecendo o baixo
acoplamento
Comportamento é distribuído através das classes
que tem a informação necessária para cumprir a
responsabilidade, obtendo alta coesão
Prof. Msc. Emerson Silas Dória
38
Padrão
Criador (Creator)

Solução

Atribuir à classe B a responsabilidade de criar uma instância
da classe A se umas das seguintes condições forem
verdadeiras:






Algumas vezes um criador é
B agrega instâncias de A (*)
encontrado ao observar a classe que
tem os dados iniciais que serão
B contém instâncias de A (*)
passados na criação.
B registra instâncias de A
B usa bem de perto instâncias de A
B tem os dados de inicialização para criar instâncias de A (B
portanto é um especialista na criação de A)
Problema

Quem deve ser responsável por criar uma nova instância de
alguma classe?
(*) priorizar
Prof. Msc. Emerson Silas Dória
39
Padrão
Criador (Creator)

Exemplo


Quem deve ser responsável por criar uma
instância de ItemVenda?
Pelo padrão, Venda deve ser responsável.
criar_iv(quantidade)
:Venda
1:criar_iv(quantidade)
Venda
data
hora
criar_iv( )
obter_total( )
:ItemVenda

Benefícios (garante baixo acoplamento)
Prof. Msc. Emerson Silas Dória
40
Padrão
Baixo Acoplamento (Low Coupling)

Solução


Problema


Atribuir a responsabilidade de modo que o acoplamento
(dependência entre classes) permaneça baixo.
Como conseguir menor dependência (entre as classes) e
maior reuso?
Acoplamento


Baixo: Não depende de outros elementos (classes)
Alto: Depende de muitos outros elementos (classes)

Tais classes podem ter os seguintes problemas: mudanças em
classes relacionadas forçam mudanças locais; difíceis de
compreender isoladamente; difíceis de serem reutilizadas.
Prof. Msc. Emerson Silas Dória
41
Padrão
Baixo Acoplamento (Low Coupling)

Exemplo


Quem deve ser responsável por criar um Pagamento e
associá-lo à Venda?
Pelo padrão Criador, poderia ser POST (uma vez que POST
“registra” pagamentos no mundo real)
RegistrarPagamento( )
:POST
1:criar( )
2:adicionar_pagamento (p)
Prof. Msc. Emerson Silas Dória
p:Pagamento
:Venda
42
Padrão
Baixo Acoplamento (Low Coupling)

Uma solução melhor, do ponto de vista do padrão,
que preserva baixo acoplamento é a própria Venda
criar o Pagamento:
RegistrarPagamento( )
:POST
1:RegistrarPagamento( )
:Venda
1.1:criar( )
:Pagamento
Prof. Msc. Emerson Silas Dória
43
Padrão
Baixo Acoplamento (Low Coupling)

Benefícios



Responsabilidade não é (ou é pouco)
afetada por mudanças em outros
componentes.
Responsabilidade é mais simples de
entender isoladamente.
Maior chance para reuso.
Prof. Msc. Emerson Silas Dória
44
Padrão
Alta Coesão (High Cohesion)

Solução


Problema


Atribuir uma responsabilidade de modo que a coesão
permaneça alta.
Como manter a complexidade (das classes) sob controle?
Coesão


Alta: Um elemento com responsabilidades altamente
relacionadas e que não executa um grande volume de
trabalho.
Em POO a Coesão Funcional mede o
quantonão
as responsabilidades
de um ou
Baixa: Uma classe faz muitas coisas
relacionadas
elemento são fortemente
executa muitas tarefas (indesejável poisrelacionadas.
fica difícil de:
compreender, reutilizar e manter; e são constantemente
afetadas pelas mudanças)
Prof. Msc. Emerson Silas Dória
45
Padrão
Alta Coesão (High Cohesion)

Exemplo


Quem deve ser responsável por criar um Pagamento e
associá-lo à Venda?
Pelo padrão Criador, seria POST. Mas se POST for o
responsável pela maioria das operações do sistema, ele vai
ficar cada vez mais sobrecarregado e sem coesão.
:POST
RealizarPagamento( )
:Venda
criar( )
p:Pagamento
adicionar_pagamento (p)
Prof. Msc. Emerson Silas Dória
46
Padrão
Alta Coesão (High Cohesion)

Exemplo

Outra forma para atribuição da responsabilidade
RealizarPagamento que favorece uma coesão mais alta
:POST
RealizarPagamento( )
:Venda
RealizarPagamento( )
criar( )
Prof. Msc. Emerson Silas Dória
:Pagamento
47
Padrão
Alta Coesão (High Cohesion)

Níveis de coesão

Muito baixa


Baixa


Um classe é a única responsável por uma tarefa complexa em
uma área funcional.
Alta


Um única classe é responsável por muitas coisas em áreas
funcionais muito diferentes.
Um classe tem responsabilidades moderadas em uma área
funcional e colabora com outras classes para realizar tarefas.
Moderada

Uma classe tem peso leve e responsabilidades exclusivas em
algumas áreas logicamente relacionadas ao conceito da classe,
mas não uma com a outra.
Prof. Msc. Emerson Silas Dória
48
Padrão
Alta Coesão (High Cohesion)

Benefícios




Aumento da clareza e compreensão do
projeto
Simplificação da manutenção
Favorece baixo acoplamento
Reuso facilitado
Prof. Msc. Emerson Silas Dória
49
Princípios Básicos (Pressman,1995)

Acoplamento


“O acoplamento é uma medida da interconexão
entre os módulos de uma estrutura de software,
depende da complexidade de interface entre
módulos”;
Coesão

“Um módulo coeso executa uma única tarefa
dentro do procedimento de software, exigindo
pouca interação com procedimentos executados
em outras partes de um programa.”
Prof. Msc. Emerson Silas Dória
50