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

© Nabor C. Mendonça 2001 1

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

Parte II


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


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.


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



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 parcial


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


Definindo atributo Venda.completada

Diagrama de Colaboração — encerrarVenda()

:POSTendSale() :Sale1: becomeComplete()

by Expertby Controller

becomeComplete(){ isComplete := true}


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


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


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


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


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


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


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


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


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)


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


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


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:

POST

enterItem()

Sale

dateisComplete : Booleantime

makeLineItem()

Captures

Type information

NavigabilityThree section box forclass definition.

1 1

Methods


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.


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.


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


makeLineItem()

Captures

Conceptual ModelPOST

Sale


Captures

Design Class Diagram

Concept; abstraction

Software component

1 1

11


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



Adicionando nomes de métodos

SalesLineItem

quantity

subtotal()

ProductCatalog

specification()


descriptionpriceupc

Store

addressname

addSale()

Payment

amount

POST


Sale

dateisCompletetime

becomeComplete()makeLineItem()makePayment()

total() troco()



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



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


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



Adicionando associações, navegabilidade e dependências

SalesLineItem

quantity : Integer

subtotal()

ProductCatalog

specification()


description : Textprice : Quantityupc : UPC

Store

address : Addressname : Text

addSale()

Payment

amount : Quantity

Contains

1..*

Contains

1..*

POST


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


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


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


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


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


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


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


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


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.


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


Communication ReportingObject Database

Interface

Services

Core Elements Sales Products

Domain

Vertical Layers

Horizontal Partitions


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.


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


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


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


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


Object Database Interface

RelationalDatabase

ObjectDatabase