Upload
internet
View
114
Download
0
Embed Size (px)
Citation preview
© Nabor C. Mendonça 2001 1
Análise e Projeto Orientados a Objetocom UML e Padrões
Parte II
© Nabor C. Mendonça 2001 2
Diagramas de Colaboração para o Sistema TV
Eventos de interesse :– Caso de uso Processar Venda: entrarItem(),
encerrarVenda(), fazerPagamento()
Note que não existe a operação do sistema iniciarVenda()
– Caso de uso ProcessarVenda():TVentrarItem()
:TVterminarVenda()
:TVfazerPagto()
1: ???()
1: ???()
1: ???()
:POSTstartUp() 1: ???()
© Nabor C. Mendonça 2001 3
Criando uma nova Venda– Pelo Criador, TV cria Venda, e Venda cria uma
coleção (vazia) para registrar objetos Item-de-Venda
Diagrama de Colaboração — entrarItem()
1: [nova venda] create()entrarItem(upc, qte):TV :Venda
:LinhaDeVenda
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
– TV passa parâmetro quantidade para Venda, que o repassa para Item-de-Venda como parâmetro da mensagem create
– Pelo criador, TV 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 Colaboração — entrarItem()
© Nabor C. Mendonça 2001 5
Visibilidade para Catálogo-Produto– Catálogo-Produto é visível para TV pois ambas
instâncias são criadas e associadas durante o caso de uso Inicialização
– Assim, é TV 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)
Diagrama de Colaboração — entrarItem()
© Nabor C. Mendonça 2001 6
Diagrama de colaboração parcial
Diagrama de Colaboração — entrarItem()
2: [nova venda] create()
2.1: [velha venda]criarLV(spec, qte)entrarItem(upc, qte)
1: spec := especificacao(upc) 2.2: create(spec, qty)
1.1: spec := find(upc)
:TV :Venda
:CatalogoProduto
sl: LinhaDeVenda
:LinhaDeVenda:EspecificacaoProduto
2.3: add(sl)
by Creator
by Expert
message to thecollection (container)object itself
© Nabor C. Mendonça 2001 7
Definindo atributo Venda.completada
Diagrama de Colaboração — encerrarVenda()
:POSTendSale() :Sale1: becomeComplete()
by Expertby Controller
becomeComplete(){ isComplete := true}
© Nabor C. Mendonça 2001 8
Calculando total da venda
Diagrama de Colaboração — encerrarVenda()
:Vendatot := total() 2*: [i:=1..N] st := subtotal() sli:LinhaDeVenda
specprod:EspecificacaoProduto
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:LinhaDeVenda
1*: [i:=1..N] sli := next()
© Nabor C. Mendonça 2001 9
Criando Pagamento– Pelo Especialista, TV e Venda podem criar um
Pagamento
– Considerando também Alta Coesão e Baixo Acoplamento, Venda é a melhor escolha
Diagrama de Colaboração — fazerPagamento
1: fazerPagto(valor)
1.1: create(valor)
:TV :Venda
:Pagto
fazerPagto(valor)
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: addVenda(s)
2.1: add(s)
:Loja
vendaCompletada: Venda
by Expert
1: fazerPagto(valor)
1.1: create(valor)
:TV s :Venda
:Pagto
fazerPagto(valor)
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
:Vendatroc := troco(valor)
Sale--balance(){ return valor - t }
1: t := total()
© Nabor C. Mendonça 2001 12
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 13
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 14
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 15
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 16
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 17
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 18
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 19
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 20
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 21
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 22
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 23
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 24
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 25
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() troco()
© Nabor C. Mendonça 2001 26
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 27
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 28
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 29
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 30
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 31
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 32
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 33
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 34
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 35
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 36
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 37
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 38
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 39
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 40
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 41
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 42
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 43
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 44
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 45
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