View
104
Download
0
Category
Preview:
Citation preview
© Nabor C. Mendonça 2001 1
Análise e Projeto Orientados a Objetocom UML e Padrões
Parte IV
Projeto (1B)
© Nabor C. Mendonça 2001 2
Diagramas de Interação para o Sistema POST
Eventos de interesse :– Caso de uso Comprar Itens: entrarItem,
encerrarVenda, fazerPagamento
– Caso de uso Inicializar: inicializar
:POSTenterItem()
:POSTendSale()
:POSTmakePayment()
1: ???()
1: ???()
1: ???()
:POSTstartUp() 1: ???()
© Nabor C. Mendonça 2001 3
Criando uma nova Venda– Pelo Criador, POST cria Venda, e Venda cria uma
coleção (vazia) para registrar objetos Item-de-Venda
Diagrama de Interação — entrarItem
1: [new sale] create()enterItem(upc, qty):POST :Sale
:SalesLineItem
1.1: create()
by Controller by Creator
by CreatorAn empty collectionthat will eventuallyhold SalesLineIteminstances.
© Nabor C. Mendonça 2001 4
Criando um novo Item-de-Venda– Pelo Criador, Venda cria objetos Item-de-Venda
– POST passa parâmetro quantidade para Venda, que o repassa para Item-de-Venda como parâmetro da mensagem create
– Pelo criador, POST envia mensagem fazerItem-de-Venda para Venda, que então cria um novo Item-de-Venda e o adiciona à sua coleção de objetos Item-de-Venda
Encontrando uma Especificação-Produto– Pelo Especialista, Catálogo-Produto faz a busca
pela Especificação-Produto baseado em casamento de UPCs
Diagrama de Interação — entrarItem
© Nabor C. Mendonça 2001 5
Visibilidade para Catálogo-Produto– Catálogo-Produto é visível para POST pois ambas
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 Catálogo-Produto
Buscando Especificação-Produto no BD– Persistência ignorada nesse estágio (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 Separação Modelo-Visão)
Diagrama de Interação — entrarItem
© Nabor C. Mendonça 2001 6
Diagrama de colaboração parcial
Diagrama de Interação — entrarItem
1: [new sale] create()
3: makeLineItem(spec, qty)enterItem(upc, qty)
2: spec := specification(upc) 3.1: create(spec, qty)
2.1: spec := find(upc)
:POST :Sale
:ProductCatalog
sl: SalesLineItem
:SalesLineItem:ProductSpecification
1.1: create()
3.2: add(sl)
by Creator
by Expert
message to thecollection (container)object itself
© Nabor C. Mendonça 2001 7
Definindo atributo Venda.completada
Diagrama de Interação — encerrarVenda
:POSTendSale() :Sale1: becomeComplete()
by Expertby Controller
becomeComplete(){ isComplete := true}
© Nabor C. Mendonça 2001 8
Calculando total da venda
Diagrama de Interação — encerrarVenda
:Saletot := total() 2: st := subtotal() sli:SalesLineItem
prodSpec:ProductSpecification
2.1: pr := price()
by Expertby Expert
SalesLineItem--subtotal(){
return quantity * prodSpec.price()}
Sale--total(){ tot := 0
for each SalesLineItem, sli tot := tot + sli.subtotal()
return tot}
SalesLineItem:SalesLineItem
1*: [for each] sli := next()
© Nabor C. Mendonça 2001 9
Criando Pagamento– Pelo Especialista, POST e Venda podem criar um
Pagamento
– Considerando também Alta Coesão e Baixo Acoplamento, Venda é a melhor escolha
Diagrama de Interação — fazerPagamento
1: makePayment(cashTendered)
1.1: create(cashTendered)
:POST :Sale
:Payment
makePayment(cashTendered)
by Controller by Creator, Low Coupling
© Nabor C. Mendonça 2001 10
Registrando a Venda– Pelo Especialista, Loja adiciona a Venda à coleção
(log) de vendas completadas
Diagrama de Interação — fazerPagamento
2: addSale(s)
2.1: add(s)
:Store
completedSales: Sale
by Expert
1: makePayment(cashTendered)
1.1: create(cashTendered)
:POST s :Sale
:Payment
makePayment(cashTendered)
by Controller by Creator, Low Coupling
© Nabor C. Mendonça 2001 11
Calculando troco– Pelo Especialista, Venda e Pagamento podem
calcular troco
– Considerando Baixo Acoplamento, Venda é a melhor escolha
Diagrama de Interação — fazerPagamento
:Sale pmt: Payment1: amt := amount()bal := balance()
Sale--balance(){ return pmt.amount() - total() }
2: t := total()
© Nabor C. Mendonça 2001 12
Diagrama de Interação — inicializar
Criar por último, após todas as outras operações terem sido consideradas
Instancia objeto de domínio inicial, enviando-lhe uma mensagem create
Objeto inicial pode ou não tomar conta da execução– Em aplicações interativas, controle da execução
normalmente fica com a camada de Apresentação
– Se objeto inicial toma conta da execução, uma mensagem run (ou equivalente) pode ser enviada num segundo diagrama de colaboração
© Nabor C. Mendonça 2001 13
Diagrama de Interação — inicializar
Candidatos para objeto de domínio inicial:– Uma classe representando o sistema como um todo
Ex.: POST
– Uma classe representado o negócio ou organização como um todo
Ex.: Loja (melhor — uma Loja pode conter vários POSTs)
Instâncias de objetos persistentes– Se poucas, criar de uma vez, durante inicialização
– Se muitas, criar sob demanda, conforme são requisitadas
© Nabor C. Mendonça 2001 14
Diagrama de Interação — inicializar
Diagrama de colaboração parcial
:Store :POST
pc:ProductCatalog
create() 2: create(pc)
1: create()
1.2: loadProdSpecs()
:ProductSpecification
1.1: create()
1.2.2*: add(ps)
1.2.1*: create(upc, price, description)
ps:ProductSpecification
Asterix in sequence numberindicates the message occurs ina repeating section.
Pass a reference to theProductCatalog to thePOST, so that it haspermanent visibility to it.
by Creator
© Nabor C. Mendonça 2001 15
Conectando as Camadas de Apresentação e Lógica da Aplicação
store :Store
1: create()
2: p := getPOST() : POST:POSTAppletcreate()
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
© Nabor C. Mendonça 2001 16
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 para 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 objeto local de um método de A
– Visibilidade global — B é de algum modo visível globalmente
© Nabor C. Mendonça 2001 17
Visibilidade de Atributo
Existe de A para B quando B é um atributo de A– Permanente — persiste enquanto A e B existirem
enterItem(upc, qty)
2: spec := specification(upc)
:POST
prodCatalog : ProductCatalog
POST--enterItem(upc, qty){ ... spec = prodCatalog.specification(upc) ...}
class POST{ ... private ProductCatalog prodCatalog; ...}
© Nabor C. Mendonça 2001 18
Visibilidade de 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 de A (permanente se B é atribuído a um atributo de A)
1: [new sale] create()
3: makeLineItem(spec, qty)enterItem(upc, qty)
2: spec := specification(upc)3.1: create(spec, qty)
:POST :Sale
:ProductCatalog
sl : SalesLineItem
Sale--makeLineItem(ProductSpecification spec, int qty){ ... sl = new SalesLineItem(spec, qty); ...}
SalesLineItem--SalesLineItem(ProductSpecification spec, int qty){...productSpec = spec; // parameter to attribute visibility...}
© Nabor C. Mendonça 2001 19
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 de A (permanente se B é atribuído a um atributo de A)
– Duas maneiras comuns de alcançar:1. Criar nova instância e atribuir para variável local
2. Atribuir objeto de retorno de um método para variável local
1: [new sale] create()
3: makeLineItem(spec, qty)enterItem(upc, qty)
2: spec := specification(upc)
:POST :Sale
:ProductCatalog
POST--enterItem(upc, qty){...// local visibility via assignment of returning objectProductSpecification spec = prodCatalog.specification(upc);...}
© Nabor C. Mendonça 2001 20
Visibilidade Global
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 não recomendada) de
atingir é atribuir nova instância a uma variável global
Alternativa recomenda:– Padrão Singleton (GoF)
© Nabor C. Mendonça 2001 21
Notação de Visibilidade na UML
Uso opcional de “estereótipos” específicos
:A :B1: msg()
:C2: msg()
:D3: msg()
«association»
«parameter»
«local»
:E4: msg()
«global»
«association» is used forattribute visibility
© Nabor C. Mendonça 2001 22
Definindo Diagramas de Classe
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
© Nabor C. Mendonça 2001 23
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)
© Nabor C. Mendonça 2001 24
Diagramas de Classe
Diagrama parcial para as classes POST e Venda no sistema POST:
POST
enterItem()
Sale
dateisComplete : Booleantime
makeLineItem()
Captures
Type information
NavigabilityThree section box forclass definition.
1 1
Methods
© Nabor C. Mendonça 2001 25
Como Fazer um Diagrama de Classe
Regras úteis:
1. Identificar todas as classes participando na solução proposta pelos diagramas de interação.
2. Desenhe as classes num diagrama de classe.
3. Inclua os atributos identificados no modelo conceitual.
4. Adicione métodos tal como identificados nos diagramas de interação.
5. Adicione informação sobre o tipo dos atributos e métodos.
6. Adicione as associações necessária para permitir a visibilidade de atributos requisitada.
© Nabor C. Mendonça 2001 26
Como Fazer um Diagrama de Classe
Regras úteis (cont.):
7. Adicione setas de navegabilidade para indicar a direção da visibilidade de atributos.
8. Adicione relacionamentos de dependência para indicar outros tipos de visibilidade.
© Nabor C. Mendonça 2001 27
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
POST
endSale()enterItem()makePayment()
Sale
dateisComplete : Booleantime
makeLineItem()
Captures
Conceptual ModelPOST
Sale
dateisComplete : Booleantime
Captures
Design Class Diagram
Concept; abstraction
Software component
1 1
11
© Nabor C. Mendonça 2001 28
Criando Diagramas de Classe para o Sistema POST
Identificando classes e atributos
POST
Sale
dateisCompletetime
SalesLineItem
quantity
ProductCatalog
quantity
ProductSpecification
descriptionpriceUPC
Store
addressname
Payment
amount
© Nabor C. Mendonça 2001 29
Criando Diagramas de Classe para o Sistema POST
Adicionando nomes de métodos
SalesLineItem
quantity
subtotal()
ProductCatalog
specification()
ProductSpecification
descriptionpriceupc
Store
addressname
addSale()
Payment
amount
POST
endSale()enterItem()makePayment()
Sale
dateisCompletetime
becomeComplete()makeLineItem()makePayment()total()
© Nabor C. Mendonça 2001 30
Criando Diagramas de Classe para o Sistema POST
Métodos create– Métodos de instanciação (construtores) específicos
para cada linguagem de programação
– Normalmente omitidos no diagrama de classe Métodos de acesso
– get e set de atributos
– Omitidos no diagrama para reduzir ruído (2N métodos desinteressantes para cada N atributos)
Métodos de coleção (multiobjects)– Parte da definição da coleção (classes de biblioteca
do tipo container: Vetor, Hashtable, etc.)
– Omitidos no diagrama para reduzir ruído
© Nabor C. Mendonça 2001 31
Criando Diagramas de Classe para o Sistema POST
Adicionando informação sobre o tipo dos atributos– Opcional– Grau de detalhe dependente da audiência
SalesLineItem
quantity : Integer
subtotal() : Quantity
ProductCatalog
specification(upc: Integer) : ProductSpecification
ProductSpecification
description : Textprice : Quantityupc : UPC
Store
address : Addressname : Text
addSale(s : Sale)
Payment
amount : Quantity
POST
endSale()enterItem(upc : Integer, qty : Integer)makePayment(cashTendered : Quantity)
Sale
date : DateisComplete : Booleantime : Time
becomeComplete()makeLineItem(spec : ProdSpecification , qty : Integer)makePayment(cashTendered : Quantity)total() : Quantity
Return type of method void; no return value
© Nabor C. Mendonça 2001 32
Criando Diagramas de Classe para o Sistema POST
Adicionando associações, navegabilidade e dependências
SalesLineItem
quantity : Integer
subtotal()
ProductCatalog
specification()
ProductSpecification
description : Textprice : Quantityupc : UPC
Store
address : Addressname : Text
addSale()
Payment
amount : Quantity
Contains
1..*
Contains
1..*
POST
endSale()enterItem()makePayment()
Sale
date : DateisComplete : Booleantime : Time
becomeComplete()makeLineItem()makePayment()total()
Captures
Houses
Uses
Looks-in
Paid-by
Describes
1 1
1
1 1
1
11
1
1
1
1
1
*
Logs-completed *
1
© Nabor C. Mendonça 2001 33
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
Especificação Detalhada de Membros
Class Name
attributeattribute : typeattribute : type = initial valueclassAttribute/derivedAttribute...
method1()method2(parameter list) : return typeabstractMethod()+publicMethod()-privateMethod()#protectedMethod()classMethod()...
© Nabor C. Mendonça 2001 34
Projetando a Arquitetura do Sistema
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
© Nabor C. Mendonça 2001 35
Arquitetura Clássica em Três Camadas
Record sales
Presentation
ApplicationLogic
Authorizepayments
Storage
Database
Object Store
Enter Item End Sale
UPC
Make Payment
Total
Quantity
Tendered Balance
© Nabor C. Mendonça 2001 36
Arquitetura Multi-camadas
Decomposição da camada de Lógica da Aplicação:– Objetos de domínio (conceitos)
– Objetos de serviço (persistência, comunicação, segurança, etc.)
Payment
Presentation
ApplicationLogic
Sale
StorageDatabase
POSTApplet
DatabaseInterface
ReportGenerator
domainconcepts
services
© Nabor C. Mendonça 2001 37
Vantagens da Arquitetura Multi-camadas
Implantação em várias configurações
Isolamento da lógica da aplicação em componentes separados
Distribuição através de diferentes computadores e/ou processos
Alocação de desenvolvedores para camadas específicas
© Nabor C. Mendonça 2001 38
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:Domain Concepts
Core Elements Sales
© Nabor C. Mendonça 2001 39
Pacotes na Arquitetura 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
© Nabor C. Mendonça 2001 40
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.
© Nabor C. Mendonça 2001 41
Camadas e Partições
Uma arquitetura multi-camadas pode ser composta por divisões verticais (“camadas”) e horizontais (“partições”)– Partições decompõem uma camada em subsistemas
relativamente independentes
Relational DatabaseInterface
Communication ReportingObject Database
Interface
Services
Core Elements Sales Products
Domain
Vertical Layers
Horizontal Partitions
© Nabor C. Mendonça 2001 42
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 das classes representando um serviço particular.
– 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.
© Nabor C. Mendonça 2001 43
Interface para Pacotes de Serviço — O Padrão 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
© Nabor C. Mendonça 2001 44
Sem Visibilidade para Janelas — O Padrão Separação Modelo-Visão
Objetos do modelo (domínio) não devem ter conhecimento sobre ou estar diretamente acoplados a objetos da visão (apresentação)
Classes de domínio encapsulam qualquer informação e comportamento relacionados à lógica da aplicação
Classes de apresentação responsáveis apenas por operações de entrada/saída
© Nabor C. Mendonça 2001 45
Sem Visibilidade para Janelas — O Padrão Separação Modelo-Visão
: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
© Nabor C. Mendonça 2001 46
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
© Nabor C. Mendonça 2001 47
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
© Nabor C. Mendonça 2001 48
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
© Nabor C. Mendonça 2001 49
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
Recommended