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 IVProjeto (1B)


Projetando uma solução com Objetos e Padrões

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

Diagrama de Colaboração

ouSeqüência

:POST

EntrarItem(UPC,quantidade)

A partir dos Casos de Usos levanta-se os Eventos de Sistema

para o DSS


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.

:POSTEntrarItem 1:???( )

:POSTTerminarVenda 1:???( )

:POSTRegistrarPagamento 1:???( )

:POSTInicializar 1:???( )

A classe POST servirá de

controladora do eventos


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: RegistrarPagamento(quantia:numero)Responsabilidade: Registrar o pagamento, calcular o troco e imprimir recibo.Tipo: SistemaReferência Cruzada: Funções: R2.1

Caso de Uso: Comprar ItensNotas:

Exceções: Se a venda não está completa, indicar um erroSe a quantia for menor que o total da venda, indicar um erro

Saída:

Pré-condições:Pós-condições: 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).


Projetando uma solução com Objetos e Padrões 3º Passo: Considerar o Modelo Conceitual

POST

ItemLoja

Venda

Pagamento

Item Venda

OperadorCliente

Gerente

Catálogode Produtos

Especificaçãode Produto

estoca

*

possui

1..*

usado-por

*

contém1..*

descreve

*

capturada-por

contido-em

1..*

descrito-por

*

registra-venda-de

0..1

iniciado-por

paga-por iniciada-por

log-vendas realizadas

*

registra-venda-no

1

1

1

1

1

1

11

1

1

1

1

1

1

1

1 1

1

iniciada-por

1

1


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;

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.



Visibilidade para CatalogoDeProdutos 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

Buscando EspecificaçãoDeProduto no Banco de Dados

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



DI [Colaboração]EntrarItem

:POSTEntrarItem(UPC,QTD

)3:criar_iv(ESPEC, QTD)

:Venda

iv:ItemVenda

3.1:criar_iv(ESPEC, QTD )

1:[novavenda] criar( )

:ItemVenda

1.1:criar( )

3.2:adicionar(iv)

:CatalogoDeProdutos

:EspecificaçãoDeProduto

2:ESPEC:=especificação(UPC)

2.1:ESPEC:=encontrar(UPC)


Definindo atributo Venda.completada

DI [Colaboração]TerminarVenda

completar(){completada:=true}

:POSTTerminarVenda( ) 1:completar( )

v:Venda


Calculando o Total da Venda

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.

Um DI pode não ser iniciado por um

evento de sistema. 2.1:pr:=obter_preço( )

:Venda

iv:ItemVenda

:ItemVenda

pd:EspecificaçãoDeProduto

1:[para cada] iv:next( )

obter_total( ){total:=0para cada itemvenda, iv tot:=tot+iv.obter_subtotal( )return( )} classe Venda

2:st:=obter_subtotal( )

tot:obter_total( )

obter_subtotal( ){quantidade*pd.preço} classe ItemVenda


Criando Pagamento Pelo Especialista, POST e Venda podem criar

um Pagamento Considerando também Alta Coesão e Baixo

Acoplamento, Venda é a melhor escolha.

DI [Colaboração]RegistrarPagamento

:POST :Venda

Pagamento

1:registrarPagamento(df)registrarPagamento(df)

1.1:criar(df)


DI [Colaboração]Inicializar

Objeto inicial, mas não

responsável por assumir o

controle da aplicação. É criado pela camada de

apresentação.

:Loja :POST

cp:CatalogoDeProdutos

2:criar(cp)criar( )

:ItemVenda:EspecificaçãoDeProduto

ep:EspecificaçãoDeProduto

1:criar( )

1.2:carregaEspeProd( )

1.1:criar( )

1.2.2*:adicionar(ep)

1.2.1*:criar(UPC,PRECO,DESCRICAO)

Visibilidade permanente de Loja para POST.


Aplicações Multicamadas Conectando as camadas

de apresentação e lógica da aplicação

post : POST

Cashier

:POSTApplet

onEnterItem()

1: enterItem(upc, qty)

2: [no sale] sale := getSale() : Sale

Object Store

Enter Item End Sale

UPC

Make Payment

Total

Quantity

Tendered Balance

presses button

PresentationLayer

DomainLayer

sale : Sale

3: t := total() : Float

store :Store

1: create()

2: p := getPOST() : POST

:POSTAppletcreate()


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 método de A Visibilidade declarada localmente: B é declarado

como um objeto local em um método de A Visibilidade global : B é de algum modo visível

globalmente


VisibilidadeAtributo Existe de A para B quando B é um atributo de A

Permanente, persiste enquanto A e B existirem


)

cp:CatalogoDeProdutos


Class POST{private CatalagoDeProdutos cp;}

EntraItem(UPC, QTD){ESPEC = cp.especificacao(UPC)} classe POST


VisibilidadeParâ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



:Venda

iv:ItemVenda

3.1:criar_iv(ESPEC, QTD )


:CatalogoDeProdutos


criar_iv(EspecificacaoDeProduto ESPEC, int QTD){...} classe Venda


VisibilidadeDeclarada 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



:Venda


:CatalogoDeProdutos


EntrarItem(UPC, QTD){EspecificacaoDeProduto ESPEC =cp.especializacao (UPC);} classe POST


VisibilidadeGlobal Existe de A para B quando B é global

para A Permanente, persiste enquanto A e B

existirem Forma menos comum de visibilidade em

sistemas desenvolvidos utilizando OO Maneira mais comum (mas menos desejável)

de atingir é atribuir nova instância a uma variável global

Alternativa recomenda: Padrão Singleton (GoF)


Notação de Visibilidade na UML Uso opcional de “estereótipos”

específicos

:A :B

:E

:D

:C

1:msg( )

2:msg( )

3:msg( )

4:msg( )

<<atributo>>

<<parâmetro>>

<<local>>

<<global>>


Definindo Diagramas de Classe

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


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)


Diagramas de Classe Diagrama parcial para as classes

POST e Venda no sistema POST:

Venda

data, horastatus:boolean

obter_total( )

métodos

POST

entrarItem( )

navegabilidade

informações sobre tipos

captura1 1


Como Fazer umDiagrama 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.


Como Fazer umDiagrama de Classe Regras úteis (continuação):

7. Adicionar setas de navegabilidade para indicar a direção da visibilidade de atributos;

8. Adicionar relacionamentos de dependência para indicar outros tipos de visibilidade.


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

captura1 1

Venda


obter_total( )

POST

captura1 1

entrarItem( )

Diagrama de Classe

Modelo Conceitual


POSTCriando Diagramas de Classe Identificando classes e atributos

Observar os DI e Modelo Conceitual

POST CataladoDeProdutos

quantidade

EspecificacaoDeProduto

descricaoprecoUPC

Loja

nomeendereco

Venda

datahorastatus

ItemVenda

quantidade

Pagamento

quantia


Criando Diagramas de Classe para o Sistema POST Adicionando nomes aos métodos

Observe as mensagens dos DI

POST

TerminarVenda()EntrarItem()RegistrarPagamento()

CataladoDeProdutos

quantidade

Especificação()


descricaoprecoUPC

Loja

nomeendereco

Venda

datahorastatusCompletar()Criar_iv()RealizarPagamento()Obter_Total()

ItemVenda

quantidade

Obter_Subtotal()

Pagamento

quantia


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

datahorastatusCompletar()Criar_iv(ESPEC: EspecificacaoDeProduto; QTD:integer)RealizarPagamento()Obter_Total()


Criando Diagramas de Classe para o Sistema POST Adicionando associações e navegabilidade

Investigar os DI

As conexões envolvidas nos DI

estarão representadas como associações no Diagrama de Classes

Navegabilidade implica

visibilidade, geralmente

visibilidade de atributo.

POST

TerminarVenda()EntrarItem()RegistrarPagamento()

CataladoDeProdutos

quantidade

Especificação()


descricaoprecoUPC

Loja

nomeendereco

Venda

datahorastatusCompletar()Criar_iv()RealizarPagamento()Obter_Total()

ItemVenda

quantidade

Obter_Subtotal()

Pagamento

quantia

1

11

1

1

1

1

11

1 1..*

1

1 1..*

1

*

usa

busca_em

captura

pago_por

contém

contém

possui

descreve


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

Características dos Elementos de Classe

Class Name

attributeattribute : typeattribute : type = initial valueclassAttribute/derivedAttribute...

method1()method2(parameter list) : return typeabstractMethod()+publicMethod()-privateMethod()#protectedMethod()classMethod()...


Arquitetura do Sistema

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


Arquitetura MulticamadasApresentação

Lógica da Aplicação

Armazenamento

SGBD

Object Store

Enter Item End Sale

UPC

Make Payment

Total

Quantity

Tendered Balance

Venda Pagamento

BD Segurança

-> objetos de domínio

-> objetos de serviço

GartnerGroup, 95


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


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

ElementosCentrais

Venda


PacotesArquitetura de um Sistema de Informação

Presentation 1

Domain

Relational DatabaseInterface

Communication Reporting

Application Frameworks &Support Libraries 2

Low-levelServicesLayer(object andnon-object oriented)

Object DatabaseInterface

High-levelObject-orientedServicesLayer

Examples:1. Java Applets, MFC Documents and Views, VisualAge Visual Parts2. JDK, MFC, STL

RelationalDatabase

ObjectDatabase


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.


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.


Interface dos Pacotes de ServiçoPatterns: 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


Sem Visibilidade para JanelasPatterns: 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


:POST

Presentation (View) Layer(e.g., POSTApplet)

Domain (Model) Layer

Worse.

Messaging or coupling fromthe Model layer to the Viewlayer is not desirable.

Better.

Messages from View toModel layer. Supportsmodel-view separation.

:POST

1: enterItem(upc, qty) 1: displayMessage(msg)

Object Store

Enter Item End Sale

UPC

Make Payment

Total

Quantity

Tendered Balance

Sem Visibilidade para JanelasPatterns: Separação Modelo-Visão


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.


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


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


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 DatabaseInterface

Object Database Interface

RelationalDatabase

ObjectDatabase

Prof. Msc. Emerson Silas Dória1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV...

Documents

Transcript of Prof. Msc. Emerson Silas Dória1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV...