Análise e Projeto

Orientados a Objeto
com UML e Padrões

Parte IV
Projeto (1B)

© Nabor C. Mendonça 2001 1

 Diagramas de Interação para o Sistema POST

Eventos de interesse :
– Caso de uso Comprar Itens: entrarItem,
encerrarVenda, fazerPagamento
– Caso de uso Inicializar: inicializar

enterItem() :POST 1: ???()

endSale() :POST 1: ???()

makePayment() :POST 1: ???()

startUp() :POST 1: ???()

© Nabor C. Mendonça 2001 2

 Diagrama de Interação — entrarItem

Criando uma nova Venda
– Pelo Criador, POST cria Venda, e Venda cria uma
coleção (vazia) para registrar objetos Item-de-Venda
by Controller by Creator

enterItem(upc, qty) 1: [new sale] create()

:POST :Sale

by Creator
An empty collection
that will eventually
hold SalesLineItem 1.1: create()
instances.

:SalesLineItem

© Nabor C. Mendonça 2001 3

 Diagrama de Interação — entrarItem

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
© Nabor C. Mendonça 2001 4
 Diagrama de Interação — entrarItem

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)
© Nabor C. Mendonça 2001 5
 Diagrama de Interação — entrarItem

Diagrama de colaboração parcial

by Creator

1: [new sale] create()

enterItem(upc, qty) 3: makeLineItem(spec, qty)
:POST :Sale

2: spec := specification(upc)
3.1: create(spec, qty)
1.1: create()
:Product 3.2: add(sl)
by Expert
Catalog

sl: SalesLineItem
2.1: spec := find(upc)

message to the
collection (container)
object itself :Product :SalesLineItem
Specification

© Nabor C. Mendonça 2001 6

 Diagrama de Interação — encerrarVenda

Definindo atributo [Link]

becomeComplete()
{
isComplete := true
}

endSale() :POST 1: becomeComplete() :Sale

by Controller by Expert

© Nabor C. Mendonça 2001 7

 Diagrama de Interação — encerrarVenda

Calculando total da venda

Sale--total()
{
tot := 0 1*: [for each] sli := next() SalesLineItem
for each SalesLineItem, sli :SalesLineItem
tot := tot + [Link]()
return tot
}

tot := total() 2: st := subtotal() sli:

:Sale
SalesLineItem

2.1: pr := price()
by Expert
by Expert
prodSpec:
ProductSpecification
SalesLineItem--subtotal()
{
return quantity * [Link]()
}

© Nabor C. Mendonça 2001 8

 Diagrama de Interação — fazerPagamento

Criando Pagamento
– Pelo Especialista, POST e Venda podem criar um
Pagamento
– Considerando também Alta Coesão e Baixo
Acoplamento, Venda é a melhor escolha

by Controller by Creator, Low Coupling

makePayment(cashTendered) 1: makePayment(cashTendered)
:POST :Sale

1.1: create(cashTendered)

:Payment

© Nabor C. Mendonça 2001 9

 Diagrama de Interação — fazerPagamento

Registrando a Venda
– Pelo Especialista, Loja adiciona a Venda à coleção
(log) de vendas completadas
by Controller by Creator, Low Coupling

makePayment(cashTendered) 1: makePayment(cashTendered)
:POST s :Sale

2: addSale(s) 1.1: create(cashTendered)

by Expert :Store :Payment

2.1: add(s)

completedSales: Sale

© Nabor C. Mendonça 2001 10

 Diagrama de Interação — fazerPagamento

Calculando troco
– Pelo Especialista, Venda e Pagamento podem
calcular troco
– Considerando Baixo Acoplamento, Venda é a melhor
escolha

Sale--balance()
{ return [Link]() - total() }

bal := balance() 1: amt := amount()

:Sale pmt: Payment

2: t := total()

© Nabor C. Mendonça 2001 11

 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 12
 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 13
 Diagrama de Interação — inicializar

Diagrama de colaboração parcial
Pass a reference to the
ProductCatalog to the
POST, so that it has
permanent visibility to it.

create() :Store 2: create(pc) :POST

by Creator

1: create()
1.1: create()

1.2.2*: add(ps)
pc: :Product
ProductCatalog Specification

1.2.1*: create(upc, price, description)

1.2: loadProdSpecs()

ps:
ProductSpecification
Asterix in sequence number
indicates the message occurs in
a repeating section.

© Nabor C. Mendonça 2001 14

 Conectando as Camadas de Apresentação e
Lógica da Aplicação
1: create()

create() 2: p := getPOST() : POST

:POSTApplet store :Store

Object Store

UPC Quantity

Total

Tendered Balance

presses button
Enter Item End Sale Make Payment

Cashier
onEnterItem()

Presentation 3: t := total() : Float

:POSTApplet
Layer

1: enterItem(upc, qty)

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

Domain
post : POST sale : Sale
Layer

© Nabor C. Mendonça 2001 15

 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 16

 Visibilidade de Atributo

Existe de A para B quando B é um atributo de A
– Permanente — persiste enquanto A e B existirem

enterItem(upc, qty) class POST

:POST {
...
private ProductCatalog prodCatalog;
...
2: spec := specification(upc)
}

prodCatalog : ProductCatalog

POST--enterItem(upc, qty)
{
...
spec = [Link](upc)
...
}

© Nabor C. Mendonça 2001 17

 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()
enterItem(upc, qty)
:POST 3: makeLineItem(spec, qty) :Sale

2: spec := specification(upc)
3.1: create(spec, qty)

:Product
Catalog

sl : SalesLineItem
Sale--makeLineItem(ProductSpecification spec, int qty)
{
...
SalesLineItem--SalesLineItem(ProductSpecification spec, int qty)
sl = new SalesLineItem(spec, qty);
{
...
...
} productSpec = spec; // parameter to attribute visibility
...
}
© Nabor C. Mendonça 2001 18
 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()
enterItem(upc, qty)
:POST 3: makeLineItem(spec, qty) :Sale

2: spec := specification(upc)

POST--enterItem(upc, qty)
:Product {
Catalog ...
// local visibility via assignment of returning object
ProductSpecification spec = [Link](upc);
...
}
© Nabor C. Mendonça 2001 19
 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 20

 Notação de Visibilidade na UML

Uso opcional de “estereótipos” específicos

«association» is used for

attribute visibility

1: msg()
:A :B
«association»

2: msg()
:C
«parameter»

3: msg()
:D
«local»

4: msg()
:E
«global»

© Nabor C. Mendonça 2001 21

 Definindo Diagramas de Classe

Um Ciclo de Desenvolvimento Notas

a. em paralelo com
Refin. Sinc. diag. interação
Plano Artefatos Análise Projeto Impl. Teste b. ordem variada

1. Definir Casos de 2. Definir Rel. & IU 3. Refinar

Uso Reais Arquitetura b

4. Definir Diag. 5. Definir Diag. 6. Definir Esquema

Interação Classe a do BD

© Nabor C. Mendonça 2001 22

 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 23
 Diagramas de Classe

Diagrama parcial para as classes POST e Venda no
sistema POST:

Three section box for Navigability

class definition.

Sale
POST
Captures date
isComplete : Boolean
1 1 time
enterItem()
makeLineItem()

Methods Type information

© Nabor C. Mendonça 2001 24

 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 25

 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 26

 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
Sale
POST Captures
Conceptual Model date
1 1 isComplete : Boolean
time

Concept; abstraction

POST Sale
Design Class Diagram
Captures date
isComplete : Boolean
endSale() 1 1 time
enterItem()
makePayment() makeLineItem()

Software component

© Nabor C. Mendonça 2001 27

 Criando Diagramas de Classe para o Sistema
POST

Identificando classes e atributos

POST ProductCatalog ProductSpecification

quantity description
price
UPC

Store Sale SalesLineItem

address date quantity

name isComplete
time

Payment

amount

© Nabor C. Mendonça 2001 28

 Criando Diagramas de Classe para o Sistema
POST

Adicionando nomes de métodos
POST ProductCatalog ProductSpecification

description
price
endSale() specification() upc
enterItem()
makePayment()

Store Sale SalesLineItem

address date quantity

name isComplete
time subtotal()
addSale()
becomeComplete()
makeLineItem() Payment
makePayment()
total() amount

© Nabor C. Mendonça 2001 29

 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 30
 Criando Diagramas de Classe para o Sistema
POST

Adicionando informação sobre o tipo dos atributos
– Opcional
– Grau de detalhe dependente da audiência
POST ProductCatalog ProductSpecification

description : Text
price : Quantity
endSale() specification(upc: Integer) : ProductSpecification upc : UPC
enterItem(upc : Integer, qty : Integer)
makePayment(cashTendered : Quantity)

Store Sale SalesLineItem

address : Address date : Date quantity : Integer

name : Text isComplete : Boolean
time : Time subtotal() : Quantity
addSale(s : Sale)
becomeComplete()
makeLineItem(spec : ProdSpecification , qty : Integer) Payment
makePayment(cashTendered : Quantity)
total() : Quantity amount : Quantity

Return type of method void; no return value

© Nabor C. Mendonça 2001 31

 Criando Diagramas de Classe para o Sistema
POST

Adicionando associações, navegabilidade e
dependências
Store Uses
1 address : Address 1
1
name : Text
ProductSpecification
ProductCatalog
addSale()
description : Text
Contains
price : Quantity
1 Looks-in 1 1 1.. * upc : UPC
specification()

Houses
1
1 1 Describes
Sale
POST date : Date
*
isComplete : Boolean SalesLineItem
Captures time : Time Contains
quantity : Integer
endSale() 1 1 1 1..*
becomeComplete()
enterItem() subtotal()
makeLineItem()
makePayment()
makePayment()
total()

1
Logs-completed  * Paid-by
Payment

amount : Quantity
1

© Nabor C. Mendonça 2001 32

 Especificação Detalhada de Membros

UML oferece notação rica para descrever
características como visibilidade, valores iniciais,
etc.
Class Name

attribute
attribute : type
attribute : type = initial value
classAttribute
/derivedAttribute
...

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


No sistema POST: todos os atributos são privados
e todos os métodos são públicos

© Nabor C. Mendonça 2001 33

 Projetando a Arquitetura do Sistema

Um Ciclo de Desenvolvimento Notas

a. em paralelo com
Refin. Sinc. diag. interação
Plano Artefatos Análise Projeto Impl. Teste b. ordem variada

1. Definir Casos de 2. Definir Rel. & IU 3. Refinar

Uso Reais Arquitetura b

4. Definir Diag. 5. Definir Diag. 6. Definir Esquema

Interação Classe a do BD

© Nabor C. Mendonça 2001 34

 Arquitetura Clássica em Três Camadas

Object Store

UPC Quantity

Total
Presentation Tendered Balance

Enter Item End Sale Make Payment

Application Authorize
Record sales
Logic payments

Storage
Database

© Nabor C. Mendonça 2001 35

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

Presentation POSTApplet

Payment Sale domain

concepts
Application
Logic
Database
ReportGenerator services
Interface

Storage
Database

© Nabor C. Mendonça 2001 36

 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 37

 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 38

 Pacotes na Arquitetura de um Sistema de
Informação
Presentation 1

Domain

High-level
Relational Database Object Database
Object- Communication Reporting
Interface Interface
oriented
Services
Layer

Examples:
1. Java Applets,
Application Frameworks &
MFC Documents and Views,
Support Libraries 2
VisualAge Visual Parts
2. JDK, MFC, STL
Low-level
Services
Layer
(object and
non-object
oriented)
Relational Object
Database Database

© Nabor C. Mendonça 2001 39

 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 40

 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

Domain

Core Elements Sales Products

Vertical Layers

Services

Relational Database Object Database

Communication Reporting
Interface Interface

Horizontal Partitions

© Nabor C. Mendonça 2001 41

 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 42

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 43
 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 44

 Sem Visibilidade para Janelas — O Padrão
Separação Modelo-Visão
Object Store

UPC Quantity

Total
Presentation (View) Layer Tendered Balance
(e.g., POSTApplet)
Enter Item End Sale Make Payment

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

Domain (Model) Layer :POST :POST

Better. Worse.

Messages from View to Messaging or coupling from

Model layer. Supports the Model layer to the View
model-view separation. layer is not desirable.

© Nabor C. Mendonça 2001 45

 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 46
 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 47

 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 48

 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 Database
Object Database Interface
Interface

Relational Object
Database Database

© Nabor C. Mendonça 2001 49