© Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV...

© Nabor C. Mendonça 2001 1

Análise e Projeto Orientados a Objetocom UML e Padrões

Parte IV

Projeto (1A)


Artefatos de análise capturam os resultados do processo de investigação do domínio do problema

Artefatos de projeto capturam uma solução para o problema baseada no paradigma de OO– Diagramas de interação e classe de projeto

– Atribuição de responsabilidades e uso de padrões

Da Análise ao Projeto

Artefato

Casos de uso

Questões Respondidas

Quais são os processos do domínio?

Modelo conceitual Quais são os conceitos, termos?

Diagramas de seqüência Quais são os eventos e operações do sistema?

Contratos O que fazem as operações do sistema?


Descrevendo Casos de Uso Reais

2. Definir Rel. & IU

4. Definir Diag.Interação

5. Definir Diag.Classe a

6. Definir Esquemado BD

1. Definir Casos deUso Reais

3. Refinar Arquitetura b

Notas

a. em paralelo com diag. interaçãob. ordem variada

Sinc.Artefatos Análise Projeto TesteRefin.

Plano Impl.

Um Ciclo de Desenvolvimento


Casos de Uso Reais

Projeto “real” de um caso de uso em termos de tecnologias concretas de entrada/saída e sua implementação como um todo– Referências a janelas, componentes da interface

com o usuário, mecanismos de interação, etc.

Necessários apenas se desenvolvedor ou cliente requer uma descrição minuciosa da interface com o usuário antes da implementação

Alternativa: rascunhos de storyboards para a interface com o usuário, com detalhes sendo adicionados na implementação


Casos de Uso Reais

Exemplo: Comprar Itens - Versão 1

Caso de uso:Atores:Propósito:Descrição:

Comprar Itens - Versão 1 (apenas com dinheiro)Cliente (Iniciador), OperadorCapturar uma venda e seu pagamento em dinheiro.Um Cliente chega no caixa com itens para comprar. O Operador registra os itens e coleta um pagamento com dinheiro. Ao final, o Cliente sai com os itens.

Tipo:Referencia:

primário e real Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1

Object Store

Enter Item End Sale

UPC

Make Payment

Total

Quantity

Tendered

Balance

A

C

E

G

H I J

PriceDescB

D

F


Casos de Uso Reais

Exemplo: Comprar Itens - Versão 1 (cont.)

1. Este caso de uso começa quando um Cliente chega no caixa com itens para comprar.

Típica Seqüência de EventosAção do Ator Resposta do Sistema

.

2. Para cada item, o Operador digita o UPC em A da Janela-1. Se tem mais de um do mesmo item, ele pode opcionalmente digitar a quantidade em E. Ao final de cada item, ele pressiona H.

3. Determina o preço do item e adiciona informação sobre o item à transação de venda em anda-mento.Mostra a descrição e o preço do item corrente em B e F da Janela-1.

4. Após o último item ter sido processado, o Operador indica final de venda pressionando I.

5. Calcula total da venda e mostra em C.6. ...


Definindo Diagramas de Interação

2. Definir Rel. & IU

4. Definir Diag.Interação

5. Definir Diag.Classe a

6. Definir Esquemado BD

1. Definir Casos deUso Reais

3. Refinar Arquitetura b

Notas

a. em paralelo com diag. interaçãob. ordem variada

Sinc.Artefatos Análise Projeto TesteRefin.

Plano Impl.

Um Ciclo de Desenvolvimento


Diagramas de Interação

Um diagrama de interação ilustra as interações de mensagens entre instâncias (e classes) no modelo de classes– Atribuição de responsabilidades aos objetos

– Ponto de partida é o cumprimento das pós-condições especificadas nos contratos de operação

A UML defines dois tipos (equivalentes) de diagramas de interação:– Diagramas de colaboração

– Diagramas de seqüência


Diagrama de colaboração– Ilustra interações num formato de grafo ou rede

Diagramas de seqüência– Ilustra interações num formato de colunas ou cerca

Tipos de Diagramas de Interação

:ClassAInstance :ClassBInstance

1: message2()2: message3()message1()

:ClassAInstance :ClassBInstance

message2()

message3()

message1()


Diagramas de Colaboração

Exemplo para a operação fazerPagamento:

1: makePayment(cashTendered)

1.1: create(cashTendered)

:POST :Sale

:Payment

makePayment(cashTendered)

parameter

direction of message

first message

instance

first internal message

link line


Como Fazer um Diagrama de Colaboração

Regras úteis:

1. Criar um diagrama em separado para cada uma das operações de sistema sendo desenvolvidas no ciclo atual.

- Para cada mensagem de operação de sistema, criar um diagrama com essa mensagem como mensagem inicial.

2. Se um diagrama fica muito complexo (não cabe facilmente num folha de papel A4), o diagrama deve ser dividido em diagramas menores.

3. Usar as responsabilidades e pós-condições dos contratos de operação, e a descrição dos casos de uso para projetar um sistema cujo objetos interagem para cumprir as tarefas exigidas.


Diagramas de Colaboração e Outros Artefatos

Cashier System

enterItem(upc,

quantity)

endSale()

makePayment(amount)

CollaborationDiagrams

SystemSequenceDiagram

Operation: enterItem

Postconditions:1. If a new sale, a newSale has been created...

Operation: makePayment

Postconditions:1. ...

Contracts

:POST

:POST

enterItem(upc, qty)

makePayment(amount)


Classes e instâncias

Links

Notação Básica

Sale :Sale s1: Sale

class instance named instance

1: addPayment(cashTendered):POST :Sale

msg1()

link line


Mensagens

Parâmetros

Notação Básica

1: message1()2: message2()3: message3()

:POST :Sale

msg1()

all messages flow on the same link

1: addPayment(amount: Money):POST :Sale

msg1()

parameters


Valor de retorno

Sintaxe alternativa

Notação Básica

1: tot := total(): Integer:POST :Sale

msg1()

return value type

return value name

1: addPayment(cashTendered):POST :Sale

msg1()

standard UMLmessage syntax

1: addPayment: cashTendered:POST :Sale

msg1

Smalltalk syntax


Mensagem para “self” ou “this”

Iteração

Notação Básica

:POST

msg1()

1: clear()

1*: li := nextLineItem(): SalesLineItem:POST :Sale

msg1()

iteration

recurrence values omitted


Cláusula de iteração

Iteração com múltiplas mensagens

Notação Básica

1*: [i := 1..10] li := nextLineItem(): SalesLineItem:POST :Sale

msg1()

iteration clause

1*: [i := 1..10] msg2():A myB :B

msg1()

note that iterationclauses are equal

myC :C2*: [i := 1..10] msg3()

msg1(){

for i := 1 to 10 { myB.msg2() myC.msg3()

}}


Criação de instância

Notação Básica

1: create(cashier):POST :Sale

msg1()

create message, withoptional initializingparameters

new created instance

«new»:Sale

"«new»" is optionallyallowed for emphasis


Seqüenciamento de mensagens

Notação Básica

:ClassAmsg1()

:ClassB1: msg2()

:ClassC

1.1: msg3()

not numbered

legal numbering


Seqüenciamento complexo de mensagens

Notação Básica

;ClassAmsg1()

:ClassB1: msg2()

:ClassC

1.1: msg3()

2.1: msg5()

2: msg4()

:ClassD

2.2: msg6()

first second

fourth

sixth

fifth

third


Mensagens condicionais

Notação Básica

1: [new sale] create():POST :Sale

:SalesLineItem

1.1: create()

msg1()

conditional message, with test


Caminhos condicionais mutuamente exclusivos

Notação Básica

1a: [test1] msg2()

:ClassA :ClassB

:ClassC

1a.1: msg3()

msg1()

:ClassD

1b: [not test1] msg4()

1b.1: msg5()

:ClassE

2: msg6()

unconditional aftereither msg2 or msg4 1a and 1b are mutually

exclusive conditional paths


Coleções (multiobjects)

Mensagens para uma coleção

Notação Básica

Salesales : Sale

multiobject

1: s := size() : int:Sale

SalesLineItem:SalesLineItem

msg1()

message sent to thecollection object itself


Mensagens para uma coleção e um elemento

Notação Básica

1: create():Sale sl: SalesLineItem


2: addElement(sl)

msg1()

2: print():Sale sl: SalesLineItem


1: sl := get(key)

msg1()


Mensagens para um objeto classe

Notação Básica

1: d1 := today(): Date:Sale Date

msg1()

not underlined,therefore a class

message to class


Responsabilidades e Métodos

Responsabilidade é “um contrato ou obrigação de um tipo ou classe” [Booch et al.’97]– Relacionada com o comportamento dos objetos

Dois tipos básicos:– De conhecer (alguma coisa)

Ex.: dados privados encapsulados, objetos relacionados, informação derivada ou calculada

– De fazer (alguma coisa)

Ex.: Fazer algo individualmente, iniciar uma ação em outros objetos, controlar ou coordenar atividades em outros objetos



Responsabilidade são atribuídas aos objetos do sistema durante o projeto OO– Exemplos:

“Uma Venda é responsável por imprimir a si própria” (de fazer)

“Uma Venda é responsável por conhecer sua data” (de conhecer)

Tradução 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 SGBD relacionais”



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 método específico

para cumprir a responsabilidade de impressão

– Esse método, por sua vez, pode precisar colaborar com outros objetos, possivelmente enviando mensagens de impressão para cada um dos objetos Item-de-Venda associados à Venda


Diagramas de interação ilustram decisões na atribuição de responsabilidades a objetos– Quais mensagens são enviadas para diferentes

classes e objetos?

Guias práticos para facilitar a tomada de decisões na atribuição de responsabilidades são oferecidos pelos padrões GRASP

Responsabilidades e Diagramas de Interação

:Saleprint() 2: print() sli:SalesLineItem

implies Sale objects have aresponsibility to printthemselves


1*: [for each] sli := next()


Padrões

Nome e descrição de um problema comum de domínio e sua respectiva solução– Expresso de modo que o padrão possas ser

aplicado a novos contextos e circunstâncias variadas

Capturam princípios fundamentais de engenharia de software

Podem oferecer guias de como responsabilidades devem ser atribuídas a objetos, dada uma categoria específica de problema


Padrões

Em geral, não contêm novas idéias nem soluções originais– Codificam soluções existentes comprovadas

Possuem nomes sugestivos– Suportam fácil incorporação ou abstração do

conjunto de conceitos representado pelo padão

Facilitam comunicação– Permitem a discussão de um princípio ou conceito

complexo através de um único nome


Padrões GRASP

Princípios gerais para atribuição de responsabilidades a objetos– Cruciais no POO

– Parte da criação de diagramas de interação

Cinco padrões mais comuns:– Especialista

– Criador

– Alta coesão

– Baixo acoplamento

– Controlador


Padrão Especialista

Problema– Qual é o princípio mais básico pelo qual

responsabilidades são atribuídas no POO? Solução

– Atribuir responsabilidade para o especialista na informação — a classe que tem a informação necessária para cumprir a responsabilidade.

Exemplo– Quem deve ser responsável por conhecer o total de

uma venda?

Informação necessária: conhecer todas as instâncias Item-de-Venda da Venda e o subtotal de cada uma delas.


Exemplo (cont.)– Pelo padrão, a classe Venda deve ser a responsável.

– Mas quem dever ser responsável por conhecer o subtotal de um Item-de-Venda?

Informação necessária: Item-de-Venda.quantidade e Especificação-Produto.preço


Sale

datetime

total()

:Salet := total()

New method


Exemplo (cont.)– Pelo padrão, a classe Item-de-Venda deve ser a

responsável.

– Porém, para cumprir essa responsabilidade um Item-de-Venda precisa conhecer o preço do Item.


Sale

datetime

total()

:Salet := total()

SalesLineItemsli:SalesLineItem

SalesLineItem

quantity

subtotal()

2: st := subtotal()

New method

:SalesLineItem



Exemplo (cont.)– Portanto, o Item-de-Venda deve mandar uma

mensagem para a Especificação-Produto para saber o preço do item.


Sale

datetime

total()

:Salet := total()

sli:SalesLineItemSalesLineItem

quantity

subtotal()

2: st := subtotal()

:ProductSpecification

2.1: p := price()

ProductSpecification

descriptionpriceUPC

price()New method




Exemplo (cont.)– Concluindo, para cumprir a responsabilidade de

conhecer e comunicar o total da venda, três responsabilidades foram atribuídas a três classes de objetos:


Classe

Venda conhece total da venda

Responsabilidade

Item-de-Venda conhece subtotal do item

Especificação-Produto conhecer preço do produto


Benefícios – Mantém encapsulamento (baixo acoplamento)

– Comportamento é distribuído através das classes que tem a informação necessária para cumprir a responsabilidade (alta coesão)

Também conhecido como– “Quem sabe, faz”

– “Faço eu mesmo”

– “Cada serviço com seus atributos”



Padrão Criador

Problema– Quem deve ser responsável por criar uma nova

instância de alguma classe? Solução

– Atribuir à classe B a responsabilidade de criar uma instância da classe A se:

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)

(*) Priorizar


Padrão Criador

Exemplo – Quem deve ser responsável por criar uma instância

de Item-de-Venda?

– Pelo padrão, Venda deve ser responsável.

Benefícios– Suporta baixo acoplamento.

Sale

datetime

makeLineItem()total()

:SalemakeLineItem(quantity)

:SalesLineItem

1: create(quantity) New method


Padrão Baixo Acoplamento

Problema– Como conseguir menor dependência (entre as

classes) e maior reuso? Solução

– Atribuir a responsabilidade de modo que o acoplamento (dependência entre classes) permaneça baixo.

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)


Exemplo (cont.)

– Uma solução melhor, (que preserva baixo acoplamento) é a própria Venda criar o Pagamento:


:POST p : Payment

:Sale

makePayment() 1: create()

2: addPayment(p)

:POST :Sale

:Payment

makePayment() 1: makePayment()

1.1. create()


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ão Alta Coesão

Problema– Como manter a complexidade (das classes) em um

nível “controlável”? Solução

– Atribuir a responsabilidade de modo que a coesão (força do relacionamento entre as responsabilidades de uma classe) permaneça alta.

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 sobrecarredado e incoeso.



Níveis de coesão– Muito baixa

Um classe tem muitas responsabilidades em áreas funcionais bastantes diferentes.

– BaixaUm classe é responsável por uma tarefa complexa de

uma única área funcional.

– ModeradaUm classe tem moderadas responsabilidades em uma

única área funcional e colabora com outras classes para cumprir suas tarefas.

– AltaUm classe tem responsabilidades leves apenas em

algumas áreas que estão logicamente relacionadas com o conceito da classe



Benefícios– Aumento da clareza e compreensão do projeto

– Simplificação de manutenção

– Baixo acoplamento

– Reuso facilitado


Padrão Controlador

Problema– Quem deve ser responsável por tratar um evento do

sistema? Solução

– Atribuir a responsabilidade de tratar um evento do sistema para uma classe “controladora” representando:

o sistema como um todo (facade controller)

o negócio ou organização com um todo (facade controller)

uma coisa ou papel de uma pessoa do mundo real envolvida diretamente com a tarefa (role controller)

um “tratador” (handler) artificial para todos os eventos de um caso de uso (use-case controller)


Padrão Controlador

Exemplo– No sistema POST, quem deve ser responsável por

tratar eventos como entrarItem, encerrarVenda, e fazerPagamento?

– Pelo padrão, as escolhas são:

:POSTenterItem(upc, quantity)

:StoreenterItem(upc, quantity)

:CashierenterItem(upc, quantity)

:BuyItemsHandlerenterItem(upc, quantity)


Padrão Controlador

Exemplo (cont.)– Pelos padrões Baixo Acoplamento e Alta Coesão, a

melhor escolha como controlador é POST

POST

...

endSale()enterItem()makePayment()

System

endSale()enterItem()makePayment()

system operationsdiscovered during systembehavior analysis

allocation of systemoperations during design,using the Controller pattern


Padrão Controlador

Benefícios– Maior chance de reuso– Melhor controle sobre o estado do caso de uso

Considerações– Não sobrecarregar controlador com um número

excessivo de eventos, responsabilidades ou atributosAdicionar mais controladores e/ou delegar

responsabilidades

– Evitar controladores representando papéis humanosRisco de baixa coesão; responsabilidades devem ser

delegadas para objetos contendo a informação necessária (padrão Especialista)


Padrão Controlador

Considerações (cont.)– Tratar eventos na camada de aplicação

Objetos da IU devem apenas receber eventos, não tratá-los! Object Store

Enter Item End Sale

UPC

Make Payment

Total

Quantity

Tendered Balance

:POST

Cashier

:POSTApplet

presses button

onEnterItem()

1: enterItem(upc, qty)

:Sale1.1: makeLineItem(upc, qty)

Presentation Layer(Java applet)

Domain Layer

system event message

controller

© Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV...

Documents

Transcript of © Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV...