Análise e Projeto
Orientados a Objeto
com UML e Padrões
Parte IV
Projeto (1B)
Prof. Msc. Emerson Silas Dória
1
Projetando uma solução com
Objetos e Padrões
: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
:POST
Diagrama de
Colaboração
ou
Seqüência
A partir dos Casos de Usos
levanta-se os Eventos de
Sistema para o DSS
Prof. Msc. Emerson Silas Dória
2
Projetando uma solução com
Objetos e Padrões

1º Passo: Criar os DI:

Crie um DI separado para operação do sistema:

Para cada evento do sistema, crie um DI com o evento
como a mensagem inicial.
EntrarItem
TerminarVenda
RegistrarPagamento
Inicializar
:POST
:POST
:POST
:POST
1:???( )
1:???( )
1:???( )
A classe POST servirá
de controladora do
eventos
1:???( )
Prof. Msc. Emerson Silas Dória
3
Projetando uma solução com
Objetos e Padrões

2º Passo: Utilizar os Contratos

Caso os contratos não tenham sido construídos, deve-se
voltar aos casos de uso e pensar sobre o que deve ser
conseguido.
Contrato:
Responsabilidade:
Tipo:
Referência Cruzada:
Notas:
Exceções:
Saída:
Pré-condições:
Pós-condições:
RegistrarPagamento(quantia:numero)
Registrar o pagamento, calcular o troco e imprimir recibo.
Sistema
Funções: R2.1
Caso de Uso: Comprar Itens
Se a venda não está completa, indicar um erro
Se a quantia for menor que o total da venda, indicar um erro
Um Pagamento foi criado (criação de instância);
 Pagamento.quantiaFornecida recebeu o valor da quantia (modificação de atributos);
 O Pagamento foi associado à Venda (relacionamento foi formado);
 A Venda foi associada à Loja, para acrescentá-la ao histórico de vendas completadas
(relacionamento foi formado).

Prof. Msc. Emerson Silas Dória
4
Projetando uma solução com
Objetos e Padrões
registra-venda-de
descrito-por

1
Especificação
de Produto
Catálogo
de Produtos
contém
3º Passo: Considerar o Modelo
Conceitual
1
1..*
1
0..1
usado-por
*
descreve
*
Item Venda
*
Loja
Item
estoca
1
1
1..*
1
Venda
1
log-vendas
realizadas
6
contido-em
*
1
*
possui
1..*
POST
1
Gerente
iniciado-por
capturada-por
1
1
1
1
1
paga-por
1
Pagamento
1
1
iniciada-por
3registra-venda-no
1
Cliente
1
iniciada-por
1
Operador
Prof. Msc. Emerson Silas Dória
5
Iniciando a Construção

Criando uma nova Venda


Pelo Criador, POST cria Venda, e Venda cria
uma coleção (vazia) para registrar objetos
ItemVenda
Observações:


A exibição da descrição e do preço serão tratados
posteriormente;
Considere os contratos e modelo conceitual;
Prof. Msc. Emerson Silas Dória
6
Iniciando a Construção

Criando um novo ItemVenda




Pelo Criador, Venda cria objetos ItemVenda
POST passa o parâmetro quantidade para Venda, que o
repassa para ItemVenda como parâmetro da mensagem
criar_iv
Pelo Criador, POST envia mensagem criar_iv para Venda,
que então cria um novo ItemVenda e o adiciona à sua
coleção de objetos ItemVenda
Encontrando uma Especificação de Produto

Pelo Especialista, CatalogoDeProdutos faz a busca pela
EspecificaçãoDeProduto baseado em uma
correspondência de UPCs.
Prof. Msc. Emerson Silas Dória
7
Iniciando a Construção

Visibilidade para CatalogoDeProdutos



Buscando EspecificaçãoDeProduto no Banco de
Dados


CatalogoDeProdutos é visível para POST pois ambos
instâncias são criadas e associadas durante o caso de uso
Inicialização
Assim, é POST quem envia mensagem de busca de
especificação para CatalogoDeProdutos
Persistência será tratada posteriormente (pressupõe todos
em memória)
Mostrando Descrição e Preço

Interação com IU ignorada nesse estágio; objetos de
negócio não devem se comunicar com objetos da IU (Padrão
MVC(MVS))
Prof. Msc. Emerson Silas Dória
8
DI [Colaboração]
EntrarItem
EntrarItem(UPC,QTD)
1:[novavenda] criar( )
3:criar_iv(ESPEC, QTD)
:POST
:Venda
2:ESPEC:=especificação(UPC)
3.1:criar_iv(ESPEC, QTD )
:CatalogoDe
Produtos
1.1:criar( )
3.2:adicionar(iv)
2.1:ESPEC:=encontrar(UPC)
:Especificação
DeProduto
iv:ItemVenda
:ItemVenda
Prof. Msc. Emerson Silas Dória
9
DI [Colaboração]
TerminarVenda

Definindo atributo Venda.completada
TerminarVenda( )
:POST
1:completar( )
v:Venda
completar()
{
completada:=true
}
Prof. Msc. Emerson Silas Dória
10
DI [Colaboração]
TerminarVenda

Durante a criação dos DI’s
não se preocupe com a
exibição de informações,
exceto quando a informação
requerida não é conhecida
no momento.
Calculando o Total da Venda
tot:obter_total( )
:Venda
1:[para cada] iv:next( )
:ItemVenda
2:st:=obter_subtotal( )
Um DI pode não ser
iniciado por um evento
de sistema.
iv:ItemVenda
2.1:pr:=obter_preço( )
obter_total( )
{
total:=0
para cada itemvenda, iv
tot:=tot+iv.obter_subtotal( )
return( )
} classe Venda
obter_subtotal( )
{
quantidade*pd.preço
} classe ItemVenda
Prof. Msc. Emerson Silas Dória
pd:Especificação
DeProduto
11
DI [Colaboração]
RegistrarPagamento

Criando Pagamento


Pelo Especialista, POST e Venda podem criar um
Pagamento
Considerando também Alta Coesão e Baixo
Acoplamento, Venda é a melhor escolha.
registrarPagamento(df)
:POST
1:registrarPagamento(df)
:Venda
1.1:criar(df)
Pagamento
Prof. Msc. Emerson Silas Dória
12
DI [Colaboração]
Inicializar
Visibilidade
permanente de Loja
para POST.
criar( )
2:criar(cp)
:Loja
1:criar( )
Objeto inicial, mas
não responsável por
assumir o controle
da aplicação. É
criado pela camada
de apresentação.
:POST
1.1:criar( )
1.2.2*:adicionar(ep)
cp:CatalogoDe
Produtos
:ItemVenda
:EspecificaçãoDe
Produto
1.2:carregaEspeProd( )
1.2.1*:criar(UPC,PRECO,DESCRICAO)
Prof. Msc. Emerson Silas Dória
ep:Especificação
DeProduto
13
Aplicações Multicamadas

Conectando as camadas de
apresentação e lógica da
aplicação
Object Store
UPC
Quantity
Total
Tendered
Balance
presses button
Enter Item
create()
End Sale
Make Payment
Cashier
:POSTApplet
onEnterItem()
1: create()
Presentation
Layer
:POSTApplet
3: t := total() : Float
2: p := getPOST() : POST
1: enterItem(upc, qty)
2: [no sale] sale := getSale() : Sale
store :Store
Domain
Layer
post : POST
Prof. Msc. Emerson Silas Dória
sale : Sale
14
Visibilidade entre Objetos

Capacidade de um objeto “ver” ou ter uma
referência para outro objeto.


Necessária para comunicação (envio de
mensagens) entre objetos.
Quatro maneiras de B ser visível por A:

Visibilidade de atributo: B é um atributo de A
Visibilidade de parâmetro: B é um parâmetro de um

Visibilidade declarada localmente: B é declarado como


método de A
um objeto local em um método de A
Visibilidade global : B é de algum modo visível
globalmente
Prof. Msc. Emerson Silas Dória
15
Visibilidade
Atributo

Existe de A para B quando B é um atributo de A

Permanente, persiste enquanto A e B existirem
EntrarItem(UPC,QTD)
:POST
Class POST
{
private CatalagoDeProdutos cp;
}
2:ESPEC:=especificação(UPC)
cp:CatalogoDe
Produtos
EntraItem(UPC, QTD)
{
ESPEC = cp.especificacao(UPC)
} classe POST
Prof. Msc. Emerson Silas Dória
16
Visibilidade
Parâmetro

Existe de A para B quando B é passado como um parâmetro
para um método de A

Temporária, persiste apenas dentro do escopo do método
EntrarItem(UPC,QTD)
:POST
1:[novavenda] criar( )
3:criar_iv(ESPEC, QTD)
:Venda
2:ESPEC:=especificação(UPC)
3.1:criar_iv(ESPEC, QTD )
:CatalogoDe
Produtos
criar_iv(EspecificacaoDeProduto ESPEC, int QTD)
{
...
} classe Venda
Prof. Msc. Emerson Silas Dória
iv:ItemVenda
17
Visibilidade
Declarada Localmente

Existe de A para B quando B é declarado como um objeto local dentro
de um método de A

Temporária, persiste apenas dentro do escopo do método

Duas maneiras comuns de alcançar:
1. Criar uma nova instância local e atribuir a uma variável local
2. Atribuir objeto de retorno de um método para uma variável local
EntrarItem(UPC,QTD)
:POST
1:[novavenda] criar( )
3:criar_iv(ESPEC, QTD)
:Venda
2:ESPEC:=especificação(UPC)
:CatalogoDe
Produtos
EntrarItem(UPC, QTD)
{
EspecificacaoDeProduto ESPEC =
cp.especializacao (UPC);
} classe POST
Prof. Msc. Emerson Silas Dória
18
Visibilidade
Global

Existe de A para B quando B é global para A


Forma menos comum de visibilidade em
sistemas desenvolvidos utilizando OO


Permanente, persiste enquanto A e B existirem
Maneira mais comum (mas menos desejável) de
atingir é atribuir nova instância a uma variável
global
Alternativa recomenda:

Padrão Singleton (GoF)
Prof. Msc. Emerson Silas Dória
19
Notação de Visibilidade na
UML

Uso opcional de “estereótipos”
específicos
:A
1:msg( )
<<atributo>>
2:msg( )
<<parâmetro>>
3:msg( )
<<local>>
4:msg( )
<<global>>
Prof. Msc. Emerson Silas Dória
:B
:C
:D
:E
20
Definindo Diagramas de
Classe
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
21
Diagramas de Classe


Um diagrama de classe ilustra as especificações de
software para as classes e interfaces do sistema
Inclui:







Classes, associações e atributos
Interfaces (com operações e constantes)
Métodos
Informação sobre o tipo dos atributos
Navegabilidade
Dependências
UML não diferencia modelo conceitual de diagrama
de classe (o termo “classe de implementação” é
usado para distinguir o segundo do primeiro)
Prof. Msc. Emerson Silas Dória
22
Diagramas de Classe

Diagrama parcial para as classes POST
e Venda no sistema POST:
informações sobre
tipos
Venda
POST
1
entrarItem( )
captura
1
data, hora
status:boolean
obter_total( )
métodos
navegabilidade
Prof. Msc. Emerson Silas Dória
23
Como Fazer um
Diagrama de Classe

Regras úteis:
1.
Identificar todas as classes participantes da
solução, proposta pelos diagramas de interação;
2.
Desenhar as classes num diagrama de classe;
3.
Incluir os atributos identificados no modelo
conceitual;
4.
Adicionar métodos tal como identificados nos
diagramas de interação;
5.
Adicionar informação sobre tipos aos atributos e
métodos;
6.
Adicionar as associações necessária para permitir
a visibilidade de atributos.
Prof. Msc. Emerson Silas Dória
24
Como Fazer um
Diagrama de Classe
Regras úteis (continuação):

7.
8.
Adicionar setas de navegabilidade para indicar a direção
da visibilidade de atributos;
Adicionar relacionamentos de dependência para indicar
outros tipos de visibilidade.
Prof. Msc. Emerson Silas Dória
25
Modelo de Conceitual X Diagrama
de Classe


Modelo Conceitual: abstração de conceitos do
mundo real
Diagrama de Classe: especificação de
componentes de software
Venda
POST
Modelo
Conceitual
1
captura
1
Venda
POST
Diagrama de
Classe
1
entrarItem( )
data, hora
status:boolean
captura
1
data, hora
status:boolean
obter_total( )
Prof. Msc. Emerson Silas Dória
26
POST
Criando Diagramas de Classe

Identificando classes e atributos

Observar os DI e Modelo Conceitual
POST
CataladoDeProdutos
quantidade
Loja
nome
endereco
Venda
data
hora
status
EspecificacaoDeProduto
descricao
preco
UPC
ItemVenda
quantidade
Prof. Msc. Emerson Silas Dória
Pagamento
quantia
27
Criando Diagramas de Classe
para o Sistema POST

Adicionando nomes aos métodos

Observe as mensagens dos DI
POST
CataladoDeProdutos
quantidade
TerminarVenda()
EntrarItem()
RegistrarPagamento()
Loja
nome
endereco
EspecificacaoDeProduto
descricao
preco
UPC
Especificação()
Venda
ItemVenda
data
hora
status
quantidade
Completar()
Criar_iv()
RealizarPagamento()
Obter_Total()
Obter_Subtotal()
Prof. Msc. Emerson Silas Dória
Pagamento
quantia
28
Criando Diagramas de Classe
para o Sistema POST

Adicionando informação sobre o tipo dos atributos

Opcional

Grau de detalhe dependente do público-alvo.
Venda
data
hora
status
Completar()
Criar_iv(ESPEC: EspecificacaoDeProduto; QTD:integer)
RealizarPagamento()
Obter_Total()
Prof. Msc. Emerson Silas Dória
29
Criando Diagramas de Classe
para o Sistema POST
Navegabilidade
implica visibilidade,
geralmente
visibilidade de
atributo.

Adicionando associações e navegabilidade

Investigar os DI
Loja
nome
endereco
usa
1
1
EspecificacaoDeProduto
descricao
preco
UPC
CataladoDeProdutos
quantidade
1
contém
1
1..*
Especificação()
possui
1
1
POST
busca_em
1
As conexões envolvidas
nos DI estarão
representadas como
associações no Diagrama
de Classes
1
1
1
*
ItemVenda
Venda
captura
TerminarVenda()
EntrarItem()
RegistrarPagamento()
descreve
data
hora
status
Completar()
Criar_iv()
RealizarPagamento()
Obter_Total()
contém
1
quantidade
1..*
Obter_Subtotal()
pago_por
1
Prof. Msc. Emerson Silas Dória
1
Pagamento
quantia
30
Características dos Elementos
de Classe


UML oferece notação rica para descrever
características como visibilidade, valores iniciais, etc.
No sistema POST: todos os atributos são privados e
todos os métodos são públicos
Class Name
attribute
attribute : type
attribute : type = initial value
classAttribute
/derivedAttribute
...
method1()
method2(parameter list) : return type
abstractMethod()
+publicMethod()
-privateMethod()
#protectedMethod()
classMethod()
...
Prof. Msc. Emerson Silas Dória
31
Arquitetura do Sistema
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
32
Arquitetura Multicamadas
GartnerGroup, 95
Object Store
Apresentação
UPC
Quantity
Total
Tendered
Enter Item
Balance
End Sale
Make Payment
Lógica da Aplicação
-> objetos de domínio
Venda
Pagamento
-> objetos de serviço
BD
Segurança
Armazenamento
SGBD
Prof. Msc. Emerson Silas Dória
33
Vantagens da Arquitetura
Multicamadas


Implantação em várias configurações
Isolamento da lógica da aplicação em
componentes separados, possibilitando
reutilização

Distribuição através de diferentes
computadores e/ou processos

Alocação de desenvolvedores para construção
de camadas específicas
Prof. Msc. Emerson Silas Dória
34
Representando Arquiteturas
com Pacotes



Um pacote é um conjunto de elementos de modelo
de qualquer tipo (casos de uso, classes, diagramas
de interação), incluindo outros pacotes;
O sistema inteiro pode ser considerado dentro do
escopo de um único pacote, o pacote Sistema
Notação para pacotes na UML:
Conceitos do Dominio
Elementos
Centrais
Venda
Prof. Msc. Emerson Silas Dória
35
Pacotes
Arquitetura de um Sistema de Informação
Presentation
1
Domain
High-level
Objectoriented
Services
Layer
Relational Database
Interface
Communication
Object Database
Interface
Examples:
1. Java Applets,
MFC Documents and Views,
VisualAge Visual Parts
2. JDK, MFC, STL
Application Frameworks &
Support Libraries 2
Low-level
Services
Layer
(object and
non-object
oriented)
Relational
Database
Reporting
Object
Database
Prof. Msc. Emerson Silas Dória
36
Identificando Pacotes

Regras úteis:



Agrupar em um pacote elementos que oferecem
um serviço comum (ou uma família de serviços
relacionados), com acoplamento e colaboração
relativamente altos.
Em níveis mais altos de abstração, o pacote deve
ser visto como um elemento altamente coeso,
com responsabilidades fortemente relacionadas.
Por outro lado, o acoplamento e colaboração entre
elementos agrupados em diferentes pacotes
devem ser relativamente baixos.
Prof. Msc. Emerson Silas Dória
37
Visibilidade entre Pacotes

Visibilidade típica:

Acesso a pacotes de domínio


Outros pacotes (normalmente pacotes de apresentação)
têm visibilidade para várias das classes que representam
conceitos de domínio.
Acesso a pacotes de serviço

Outros pacotes (normalmente pacotes de domínio e
apresentação) têm visibilidade para apenas uma ou
poucas classes em cada particular pacote de serviço.


Padrão Façade (Fachada) - GoF
Acesso a pacotes de apresentação

Nenhum outro pacote tem visibilidade direta para as
classes da camada de apresentação; comunicação,
quando há, é de forma indireta.
Prof. Msc. Emerson Silas Dória
38
Interface dos Pacotes de Serviço
Patterns: Façade - GoF (Fachada)




Uma Fachada é uma classe que oferece uma
interface comum para um grupo de outros
componentes ou um conjunto de interfaces
originalmente separadas;
Usada para oferecer um interface pública comum
para um pacote de serviço;
Classes de outros pacotes comunicam-se apenas com
a fachada, a qual colabora com as outras classes
internas (privadas) para oferecer o serviço;
Suporta baixo acoplamento
Prof. Msc. Emerson Silas Dória
39
Sem Visibilidade para Janelas
Patterns: Separação Modelo-Visão



Objetos do modelo (domínio) não deveriam
ter conhecimento direto dos objetos devisão
(apresentação), ou estar diretamente
acoplados a estes.
Classes de domínio encapsulam a informação
e o comportamento relacionados à lógica da
aplicação
Classes de apresentação responsáveis apenas
por operações de entrada/saída
Prof. Msc. Emerson Silas Dória
40
Sem Visibilidade para Janelas
Patterns: Separação Modelo-Visão
Object Store
UPC
Quantity
Total
Presentation (View) Layer
(e.g., POSTApplet)
Tendered
Enter Item
1: enterItem(upc, qty)
Domain (Model) Layer
Balance
End Sale
Make Payment
1: displayMessage(msg)
:POST
:POST
Better.
Worse.
Messages from View to
Model layer. Supports
model-view separation.
Messaging or coupling from
the Model layer to the View
layer is not desirable.
Prof. Msc. Emerson Silas Dória
41
Vantagens do Padrão
Separação Modelo-Visão






Foco em processos do domínio, em vez de em mecanismo de
interação e apresentação;
Desenvolvimento separado das camadas de lógica da aplicação
e apresentação;
Redução do impacto de mudanças na camada de apresentação
nos objetos de domínio;
Capacidade de incluir novos mecanismos de interação, sem
afetar a lógica da aplicação;
Suporte para múltiplas visões do mesmo objeto de domínio;
Execução e teste da lógica da aplicação independentemente da
camada de apresentação.
Prof. Msc. Emerson Silas Dória
42
Comunicação Indireta

Evita acoplamento entre objetos remetentes
(senders) e e seus destinatários (receivers)


Suporte para difusão (broadcast) de mensagens
Mecanismo mais comuns:



Padrão Editor-Assinante (ou Observador)
Callbacks
Notificação de eventos
Prof. Msc. Emerson Silas Dória
43
Coordenadores de Aplicação


Um coordenador de aplicação é uma classe
responsável pela mediação entre as camadas
de apresentação e lógica da aplicação
Responsabilidades básicas:

Mapear informação entre objetos de domínio e IU

Responder a eventos capturados pela IU



Abrir janelas para mostrar informação produzida pelos objetos de
domínio
Atualizar janelas quando informação à mostra muda na camada de
lógica da aplicação- caso haja múltiplas visões para o mesmo
objeto de domínio
Gerenciar transações
Prof. Msc. Emerson Silas Dória
44
Armazenamento e Persistência

Requer um subsistema específico para mapear entre
objetos de domínio e objetos do BD

Implementado de forma semi-transparente através de
frameworks de persistência
Domain
Relational Database
Interface
Relational
Database
Object Database Interface
Object
Database
Prof. Msc. Emerson Silas Dória
45