Upload
internet
View
111
Download
1
Embed Size (px)
Citation preview
Prof. Msc. Emerson Silas Dória 1
Análise e Projeto Orientados a Objetocom UML e Padrões
Parte IV Projeto (1A)
Prof. Msc. Emerson Silas Dória 2
Artefatos de análise capturam os resultados do processo de investigação do domínio do problema
Da Análise ao Projeto
Casos de Uso Quais são os processos do domínio?
Modelo Conceitual 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?
Prof. Msc. Emerson Silas Dória 3
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.
O Começo da Fase Projetar
Prof. Msc. Emerson Silas Dória 4
Descrevendo Casos de Uso Reais
Sinc.Artefatos
Análise Projeto TesteRefin.Plano
Impl.
2. Definir Rel. & IU
4. Definir Diag.Interação
5. Definir Diag.Classe
a
6. Definir Esquema do BD
1. Definir Casos de Uso Reais
3. Refinar Arquitetura
b
Notas
a. em paralelo com diagrama de interação b. ordem variada
Prof. Msc. Emerson Silas Dória 5
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 6
Casos de Uso Reais Exemplo de um caso de uso real
Caso de uso:Atores:Finalidade:Visão Geral:
Comprar Itens com DinheiroCliente, OperadorCapturar 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ênciasCruzadas:
Primário e Essencial
Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
Prof. Msc. Emerson Silas Dória 7
Seqüência Típica de EventosAção do Ator Resposta do Sistema
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>.
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. . . .4. . . .
1. Este caso de uso começa quando um Cliente chega no caixa (equipado com um POST) com itens que deseja comprar.
Object Store
Entrar Item
UPC
Total
Quantidade
Fornecido
Troco
A
C
E
G
H
Terminar Venda
I
Registrar Pagamento
J
Preço DescriçãoB
D
F
Casos de Uso Reais
Prof. Msc. Emerson Silas Dória 8
Definindo Diagramas de Interação
Sinc.Artefatos
Análise Projeto TesteRefin.Plano
Impl.
2. Definir Rel. & IU
4. Definir Diag.Interação
5. Definir Diag.Classe
a
6. Definir Esquema do BD
1. Definir Casos de Uso Reais
3. Refinar Arquitetura
b
Notas
a. em paralelo com diagrama de interação b. ordem variada
Prof. Msc. Emerson Silas Dória 9
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 10
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 11
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 12
Diagramas de Colaboração Ênfase na organização estrutural dos
objetos que enviam e recebem mensagens
Diagramas de Interação
Diagramas de Seqüência Ênfase na ordenação temporal das
mensagens:
:Instância_ClasseA :Instância_ClasseB1: mensagem2( )
2: mensagem3( )
mensagem1( )
:Instância_ClasseA :Instância_ClasseB
1: mensagem2( )
2: mensagem3( )
mensagem1( )
Prof. Msc. Emerson Silas Dória 13
Diagramas de Interação Exemplo de Diagrama de Colaboração
para a operação RegistrarPagamento:
:POST
:Pagamento
:VendaRegistrarPagamento(df) 1:RegistrarPagamento(df)
1.1:Criar(df)primeira mensage
m
direção da
mensagem
instânciaprimeira
mensageminterna
Prof. Msc. Emerson Silas Dória 14
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 15
Diagramas de Colaboração e Outros Artefatos
Operação:EntrarItemPós-Condições:1. Se tSe for uma nova venda, uma Venda foi criada (criação de instância);
Sistema
EntrarItem(UPC, quantidade)
TerminarVenda()
RegistrarPagamento(quantia)
EntrarItem(UPC,quantidade)
:SistemaOperador
TerminarVenda()
RegistrarPagamento(quantia)
DSS Operações doSistema
Contratos
Operação: TerminarVendaPós-Condições:1. Venda.Completada recebe o valor...
Diag. Colaboração
:POST
EntrarItem(UPC,quantidade)
Prof. Msc. Emerson Silas Dória 16
Classes e Instâncias
Notação Básica para DI
Ligações, Mensagens, Parâmetros
POST p1:Pagamento:Venda
classe instância instância nomeada
:POST
msg1( )
:Venda
1:msg1(a,b )2:msg2( )3:msg3( )
Prof. Msc. Emerson Silas Dória 17
Notação Básica para DI
Valor de Retorno
Mensagem para “self” ou “this”
:POST
msg1( )
1:clear( )
:POST
msg1( )
:Venda1:tot:=total( ):integer
Prof. Msc. Emerson Silas Dória 18
Notação Básica para DI
Iteração
Cláusula de Iteração
:POST
msg1( )
:Venda1*:l:=proximaLinhaItem( )
:POST
msg1( )
:Venda1*[i:=1..10]:l:=proximaLinhaItem( )
* Expressa mensagem enviada repetidamente
Prof. Msc. Emerson Silas Dória 19
Seqüenciamento de Mensagens
Notação Básica para DI
:ClasseA
msg1( )
:ClasseB1:msg2( )
:ClasseC
:ClasseD
2.1:msg5( )
1.1:msg3( )
2:msg4( )
2.2:msg6( )
Prof. Msc. Emerson Silas Dória 20
Mensagens Condicionais
Notação Básica para DI
:POST
msg1( )
:Venda1:[nova venda] criar( )
:ItemVendaExpressa que a mensagem só deve ser enviada se o valor de
nova venda for TRUE em tempo de execução.
Prof. Msc. Emerson Silas Dória 21
Caminhos Condicionais Mutuamente Exclusivos
Notação Básica
:ClasseA
msg1( )
:ClasseB1a:[test]msg2( )
:ClasseC
:ClasseD
2.1:msg5( )
1.1:msg3( )
1b:[not test]msg4( )
2.2:msg6( )Expressa que a mensagem 1a ou
1b podem ser executadas, dependendo do teste lógico entre
[].
Prof. Msc. Emerson Silas Dória 22
Mensagens para uma coleção
Notação Básica Coleções (multiobjects)
:ClasseB:ClasseB
vendas:VendaExpressa um conjunto lógico
de instâncias (Ex: Vector em Java)
:Venda
msg1( )
:ItemVenda1:s:=size():int :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 23
Mensagens para uma coleção e um elemento
Notação Básica
:Venda
msg1( )
iv:ItemVenda1:criar( )
:ItemVenda:ItemVenda
:ItemVenda2:additem(iv )
Prof. Msc. Emerson Silas Dória 24
Mensagens para um objeto classe
Notação Básica
:Venda
msg1( )
Data1:d1:=today( ):Date
Expressa uma mensagem sendo enviada para uma classe
Prof. Msc. Emerson Silas Dória 25
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 26
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ós-condições
POO -> Atribuição de Responsabilidade ->Bons Projetos OO
Prof. Msc. Emerson Silas Dória 27
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 28
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 29
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 30
Diagramas de Interação ilustram decisões de atribuição de responsabilidades a objetos. Quais mensagens são enviadas para diferentes
classes e objetos?
Responsabilidades e DI
Guias práticos para facilitar a tomada de decisões na atribuição de responsabilidades são oferecidos pelos padrões GRASP.
:Vendaimprimir( )
iv:ItemVenda1:[para cada] iv:=next( ) :ItemVenda
iv:ItemVenda2:imprimir( )
Implica que objetos Venda têm uma responsabilidade de
imprimirem a si mesmos.
Prof. Msc. Emerson Silas Dória 31
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 32
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 33
PadrãoEspecialista (Expert) Solução
Atribuir responsabilidade para o especialista na informação - a classe que tem a informação necessária para cumprir a responsabilidade.
Problema 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?
Informação necessária: conhecer todas as instâncias ItemVenda da Venda e o subtotal de cada uma delas. Somente uma instância de venda conhece isso.
Segundo o padrão EXPERT, devemos procurar a classe de objetos que tem a informação necessária para determinar o
total.
Prof. Msc. Emerson Silas Dória 34
Pelo padrão, a classe Venda deve ser a responsável.
Venda
datahora, status
ItemVenda
quantidade
EspecificaçãoProduto
descriçãopreçoUPC
contém
descrito
1..*
*
Modelo Conceitual Parcial
PadrãoEspecialista (Expert)
Venda
datahora
obter_total()
:Vendat:obter_total( )
Aqui ocorrem as definições
de responsabilidad
e.
Prof. Msc. Emerson Silas Dória 35
Mas quem deve ser responsável por conhecer o subtotal de um ItemVenda?
Informação necessária: ItemVenda.quantidade e EspecificaçãoProduto.preço
Pelo padrão, a classe ItemVenda deve ser a responsável.
PadrãoEspecialista (Expert)
:ItemVenda
:Vendat:obter_total( )
iv:ItemVenda :ItemVenda
2:st:=obter_subtotal()
1*:[para cada]iv:next( ) Venda
datahora
obter_total( )
Aqui ocorrem as definições
de responsabilidad
e.
ItemVenda
quantidade
obter_subtotal()
Prof. Msc. Emerson Silas Dória 36
Porém, para cumprir essa responsabilidade de conhecer ou informar seu subtotal um ItemVenda precisa conhecer o preço do Item.
Portanto, o ItemVenda deve mandar uma mensagem para a EspecificaçãoProduto para saber o preço do item.
PadrãoEspecialista (Expert)
:ItemVenda
:Vendat:obter_total( )
iv:ItemVenda :ItemVenda
2:st:=obter_subtotal( )
1*:[para cada]iv:next( )
2.1:p:=obter_preço( )
:EspecificaçãoProduto
Venda
datahora, status
obter_total( )
Aqui ocorrem as definições
de responsabilidad
e.
ItemVenda
quantidade
obter_subtotal()
EspecificaçãoProduto
descriçãopreçoUPC
obter_preço( )
Prof. Msc. Emerson Silas Dória 37
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
Venda Conhecer total da venda
Responsabilidade
ItemVenda Conhecer subtotal do item
EspecificaçãoProduto Conhecer preço do produto
PadrãoEspecialista (Expert)
Prof. Msc. Emerson Silas Dória 38
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
PadrãoEspecialista (Expert)
Prof. Msc. Emerson Silas Dória 39
PadrãoCriador (Creator) Solução
Atribuir à classe B a responsabilidade de criar uma instância da classe A se umas das seguintes condições forem verdadeiras:
B agrega instâncias de A (*) B contém instâncias de A (*) 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
Algumas vezes um criador é encontrado ao observar a classe que tem os dados
iniciais que serão passados na criação.
Prof. Msc. Emerson Silas Dória 40
Exemplo Quem deve ser responsável por criar uma
instância de ItemVenda? Pelo padrão, Venda deve ser responsável.
PadrãoCriador (Creator)
Benefícios (garante baixo acoplamento)
:Vendacriar_iv(quantidade)
:ItemVenda
1:criar_iv(quantidade)
Venda
datahora
criar_iv( )obter_total( )
Prof. Msc. Emerson Silas Dória 41
PadrãoBaixo Acoplamento (Low Coupling) Solução
Atribuir a responsabilidade de modo que o acoplamento (dependência entre classes) permaneça baixo.
Problema 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 42
PadrãoBaixo Acoplamento (Low Coupling)
:POST
RegistrarPagamento( )
p:Pagamento1:criar( )
:Venda2:adicionar_pagamento (p)
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)
Prof. Msc. Emerson Silas Dória 43
Uma solução melhor, do ponto de vista do padrão, que preserva baixo acoplamento é a própria Venda criar o Pagamento:
PadrãoBaixo Acoplamento (Low Coupling)
:POST
RegistrarPagamento( )
:Venda1:RegistrarPagamento( )
:Pagamento
1.1:criar( )
Prof. Msc. Emerson Silas Dória 44
Benefícios Responsabilidade não é (ou é pouco)
afetada por mudanças em outros componentes.
Responsabilidade é mais simples de entender isoladamente.
Maior chance para reuso.
PadrãoBaixo Acoplamento (Low Coupling)
Prof. Msc. Emerson Silas Dória 45
PadrãoAlta Coesão (High Cohesion) Solução
Atribuir uma responsabilidade de modo que a coesão permaneça alta.
Problema Como manter a complexidade (das classes) sob
controle?
Em POO a Coesão Funcional mede o quanto as
responsabilidades de um elemento são fortemente
relacionadas.
Coesão Alta: Um elemento com responsabilidades altamente
relacionadas e que não executa um grande volume de trabalho.
Baixa: Uma classe faz muitas coisas não relacionadas ou executa muitas tarefas (indesejável pois fica difícil de: compreender, reutilizar e manter; e são constantemente afetadas pelas mudanças)
Prof. Msc. Emerson Silas Dória 46
PadrãoAlta 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
adicionar_pagamento (p)
p:Pagamentocriar( )
Prof. Msc. Emerson Silas Dória 47
PadrãoAlta Coesão (High Cohesion) Exemplo
Outra forma para atribuição da responsabilidade RealizarPagamento que favorece uma coesão mais alta
:POST
RealizarPagamento( )
:Venda
:Pagamento
RealizarPagamento( )criar( )
Prof. Msc. Emerson Silas Dória 48
PadrãoAlta Coesão (High Cohesion) Níveis de coesão
Muito baixa Um única classe é responsável por muitas coisas em
áreas funcionais muito diferentes. Baixa
Um classe é a única responsável por uma tarefa complexa em uma área funcional.
Alta 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 49
PadrãoAlta 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 50
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.”