prof. msc. emerson silas dória1 análise e projeto orientados a objeto com uml e padrões parte iv...

Prof. Msc. Emerson Silas Dória 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

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?


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


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


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


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


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


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


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); . . .


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;


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


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( )


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


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.


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)


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( )



Valor de Retorno

Mensagem para “self” ou “this”

:POST

msg1( )

1:clear( )

:POST

msg1( )

:Venda1:tot:=total( ):integer



Iteração

Cláusula de Iteração

:POST

msg1( )

:Venda1*:l:=proximaLinhaItem( )

:POST

msg1( )

:Venda1*[i:=1..10]:l:=proximaLinhaItem( )

* Expressa mensagem enviada repetidamente


Seqüenciamento de Mensagens


:ClasseA

msg1( )

:ClasseB1:msg2( )

:ClasseC

:ClasseD

2.1:msg5( )

1.1:msg3( )

2:msg4( )

2.2:msg6( )


Mensagens Condicionais


: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.


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

[].


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)


Mensagens para uma coleção e um elemento

Notação Básica

:Venda

msg1( )

iv:ItemVenda1:criar( )

:ItemVenda:ItemVenda

:ItemVenda2:additem(iv )


Mensagens para um objeto classe

Notação Básica

:Venda

msg1( )

Data1:d1:=today( ):Date

Expressa uma mensagem sendo enviada para uma classe


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”


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


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


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”


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.


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.


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.


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)


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.


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.


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.


:ItemVenda


iv:ItemVenda :ItemVenda

2:st:=obter_subtotal()

1*:[para cada]iv:next( ) Venda

datahora

obter_total( )


de responsabilidad

e.

ItemVenda

quantidade

obter_subtotal()


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.


:ItemVenda


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( )


de responsabilidad

e.

ItemVenda

quantidade

obter_subtotal()

EspecificaçãoProduto

descriçãopreçoUPC

obter_preço( )


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



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ã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.


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( )


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.


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)


Uma solução melhor, do ponto de vista do padrão, que preserva baixo acoplamento é a própria Venda criar o Pagamento:


:POST

RegistrarPagamento( )

:Venda1:RegistrarPagamento( )

:Pagamento

1.1:criar( )


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ã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)


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( )


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( )


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.


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


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ória1 análise e projeto orientados a objeto com uml e padrões parte iv...

Documents