Análise e Projeto
Orientados a Objeto
com UML e Padrões
Parte III
Análise (1)
Prof. Msc. Emerson Silas Dória
1
Construindo um Modelo
Conceitual
Plan. &
Elaboração
Ciclo de
Desenv. 1
Ciclo de
Desenv. 2
Refin.
Plano
Construção
Implantação
...
Sinc.
Artefatos
Análise
Projeto
Prof. Msc. Emerson Silas Dória
Impl.
Teste
2
Construindo um Modelo
Conceitual
Refin.
Plano
Sinc.
Artefatos
Análise
Projeto
Impl.
1. Definir Casos de
Uso Essenciais a
2. Refinar Diag.
Casos de Uso
3. Refinar Modelo
Conceitual
5. Definir Diag.
Seq.
6. Definir Contrat.
de Operação
7. Definir Diag.
Estado
Teste
4. Refinar
Glossário
b
c
Notas
a. se ainda não feito
b. contínuo
c. opcional
Prof. Msc. Emerson Silas Dória
3
Modelo Conceitual



Artefato mais importante da AOO
Representa conceitos relevantes (do ponto de
vista do projetista) do domínio do problema
Na UML, ilustrado com diagramas de
estruturas estáticas contendo:



Conceitos
Associações entre conceitos
Atributos de conceitos
Prof. Msc. Emerson Silas Dória
4
Modelo Conceitual Parcial para
o Sistema POST
Conceito
Item de Venda
Item
Registra-venda-de
quantidade
1
0..1
*
1..*
Associação
Armazenado-em
Contido-em
1
1
Venda
Atributos
data
hora
Depósito
endereço
nome
1
1
1
Aloja
Pago-por
1
1..*
POST
Capturado-no4
Pagamento
1
quantia
Prof. Msc. Emerson Silas Dória
5
Conceitos


Idéias, coisas, ou objetos do mundo
real
Não representam componentes de
software!
BancodeDados
Sale
data
hora
Artefato de software;
não faz parte do modelo
Classe de software ; não
faz parte do modelo
conceitual
imprime()
Prof. Msc. Emerson Silas Dória
6
Identificando Conceitos

Regras úteis:




É melhor especificar demais do que especificar de
menos
Não exclua conceitos simplesmente porque os
requisitos não indicam a necessidade de guardar
informações sobre eles (comum em projeto de
BD)
Comece fazendo uma lista de conceitos candidatos
a partir de uma lista de conceitos comuns
Considere os substantivos e frases nominais nas
descrições textuais do domínio do problema como
possíveis candidatos a conceitos ou atributos
Prof. Msc. Emerson Silas Dória
7
Conceitos Típicos
Categoria
Exemplos
Objetos físicos ou tangíveis
POST
Avião
Especificação de projetos ou
descrição de coisas
Especificação de produto
Descrição de vôo
Lugares
Loja
Aeroporto
Transações
Venda, Pagamento
Reserva
Itens de transação
Itens de venda
Papéis de pessoas
Operador
Piloto
Contêiner de outras coisas
Depósito, Armário, Aeronave
Prof. Msc. Emerson Silas Dória
8
Conceitos Típicos
Categoria
Exemplos
Coisas em um container
Item
Passageiro
Sistemas externos
Sistema de Autorização de
Crédito
Conceitos e substantivos
abstratos
Fome
Aerofobia
Organizações
Departamento de vendas
Companhia aérea
Eventos
Venda, Roubo, Reunião
Vôo, Decolagem
Regras e políticas
Política de reembolso
Política de cancelamento
Prof. Msc. Emerson Silas Dória
9
Identificando Conceitos e
Atributos em Descrições Textuais
Seqüência Típica de Eventos
Ação do Ator
1. Este caso de uso começa
quando um Cliente chega no
caixa (equipado com um POST)
com itens que deseja comprar.
2. O Operador registra o
identificador de cada item.
Se houver mais de um exemplar
do mesmo item, o Operador
também pode informar a
quantidade.

Resposta do Sistema
3. Determina o preço do item e
adiciona informação sobre o item
à transação de venda corrente.
Mostra a descrição e o preço do
item corrente.
Usar com cuidado!

Linguagens naturais: imprecisão e ambigüidade
Prof. Msc. Emerson Silas Dória
10
Conceitos Candidatos para o
Sistema POST

Post
Item
Loja
Venda
Item de
Venda
Operador
Cliente
Gerente
Pagamento
Catálogo
Produtos
Especificação
de Produtos
Conceitos restritos ao caso de uso Comprar
Itens - Versão expandida
Prof. Msc. Emerson Silas Dória
11
Criando um Modelo Conceitual

Passos sugeridos:




Liste os conceitos candidatos, usando a Lista de
Categorias de Conceitos e a identificação de
substantivos relacionados com os requisitos que
estão sendo considerados;
Desenhe-os em um modelo conceitual;
Acrescente as associações necessárias para
registrar os relacionamentos para os quais existe a
necessidade de preservar alguma memorização *
Acrescente os atributos necessários para
completar os requisitos de informação *
* serão apresentados posteriormente
Prof. Msc. Emerson Silas Dória
12
Criando um Modelo Conceitual

Estratégia do “fazedor de mapas”:




Usar nomes existentes no vocabulário do domínio
Incluir apenas conceitos pertinentes para os
requisitos (casos de uso) em questão
Excluir tudo que não há no domínio do problema
Erro comum: atributo em vez de conceito

Atributos normalmente correspondem a um texto
ou número no mundo real
Prof. Msc. Emerson Silas Dória
13
Conceitos de Especificação ou
de Descrição

A especificação ou descrição de um objeto
deve ser representada como um conceito em
separado



evita perda de informação quando o objeto é
excluído
reduz informações redundantes ou duplicadas
Muito comum no domínio de produtos e
vendas
Item
descrição
preço
número serial
UPC
pior
EspecificaçãoProduto
descrição
preço
UPC
melhor
Descreve
1
Prof. Msc. Emerson Silas Dória
Item
* Número serial
14
Conceitos de Especificação ou
de Descrição

outro exemplo:
Vôo
Data
Número
hora
1
*
Vôo
data
hora
Aeroporto
Voa-para
Descrição-Vôo
Descrito-por
*
1
pior
nome
melhor
número
*
Descreve-vôo-para
1
Aeroporto
nome
Prof. Msc. Emerson Silas Dória
15
Terminologia da UML

UML usa o termo genérico “classe” para
denotar tanto entidades do domínio da
aplicação quanto classes na POO

Uma classe na POO é chamada mais
especificamente de “classe de
implementação”
Prof. Msc. Emerson Silas Dória
16
Associações



Uma associação é um relacionamento entre
conceitos que indica uma conexão com
significado e interesse
Descritos na UML como “relacionamentos
estruturais entre objetos de tipos diferentes”
Indicam conhecimento de um relacionamento
que precisa ser preservado durante algum
tempo


Duração de milisegundos ou anos, dependendo do
contexto
Entre quais objetos necessitamos ter alguma
memória de um relacionamento?
Prof. Msc. Emerson Silas Dória
17
Associações

Notação na UML




Uma linha entre dois conceitos mais um nome
Inerentemente bidirecional
Pode conter um seta de direção de leitura
Pontas podem conter expressões de
cardinalidade
EspecificaçãoProduto
Descrição
Preço
UPC
Item
descreve
1
*
Númeroserial
Prof. Msc. Emerson Silas Dória
18
Associações Típicas
Categoria
Exemplos
A é uma parte física de B (*)
Gaveta - POST
Asa – Avião
A é uma parte lógica de B (*)
Item de Venda - Venda
Escala – Vôo
A está fisicamente contido
em/sobre B (*)
POST - Loja
Passageiro – Avião
A está logicamente contido em
B (*)
Descrição-Item - Catálogo
Vôo - Roteiro de Viagem
A é uma descrição de B
Descrição-Item - Item
Descrição-Vôo – Vôo
A é um item de uma transação
ou relatório B
Item de Venda - Venda
Opção de Reserva – Reserva
A é conhecido/registrado/reportado/capturado em B (*)
Venda - POST
Reserva - Terminal de Reserva
Prof. Msc. Emerson Silas Dória
(*) alta prioridade
19
Associações Típicas
Categoria
Exemplos
A é um membro de B
Operador - Loja
Piloto - Companhia Aérea
A é uma sub-unidade
organizacional de B
Departamento - Loja
Manutenção - Companhia
Aérea
A usa ou gerencia B
Operador - POST
Piloto – Avião
A se comunica com B
Cliente - Operador
Agente de Reserva –
Passageiro
A está relacionado com uma
transação B
Cliente - Pagamento
Passageiro – Bilhete
A é uma transação relacionada
com outra transação B
Pagamento - Venda
Reserva – Cancelamento
A é possuído por B
POST - Loja
Avião - Companhia Aérea
Prof. Msc. Emerson Silas Dória
(*) alta prioridade
20
Identificando Associações

Regras úteis:



Focaliza-se naquelas associações para as
quais o conhecimento do relacionamento
necessita ser preservado por algum tempo;
É mais importante identificar conceitos do
que identificar associações;
O excesso de associações tende a tornar
um modelo conceitual confuso, em vez de
esclarecê-lo.
Prof. Msc. Emerson Silas Dória
21
Papéis de uma Associação


Cada ponta de um associação é
chamada de um “papel”
Um papel pode ter:



Nome
Expressão de multiplicidade
Navegabilidade
Estoca
Loja
1
Item
*
Prof. Msc. Emerson Silas Dória
22
Adicionando Associações ao
Modelo Conceitual do POST

Relacionamentos fundamentais

Venda Capturada-em POST


Venda Paga-por Cliente


Para conhecer a venda corrente, calcular total e imprimir
recibo
Para saber se a venda foi paga, calcular troco, e imprimir
recibo
Catálogo-Produto Contém Especificação-Item

Para obter a especificação de um item, dado um UPC
Prof. Msc. Emerson Silas Dória
23
Aplicando a lista de
Associações Típicas
Categoria
Sistema POST
A é uma parte física de B (*)
Não aplicável
A é uma parte lógica de B (*)
Item de Venda – Venda
A está fisicamente contido em/sobre B POST – Loja
(*)
Item – Loja
A está logicamente contido em B (*)
EspecificaçãoProduto –
CatálogoProdutos
CatálogoProdutos – Loja
A é uma descrição de B
EspecificaçãoProduto – Item
A é um item de uma transação ou
relatório B
ItemVenda – Venda
A é conhecido/registrado/reportado/capturado em B (*)
Venda (corrente) – POST
Vendas (completada) – Loja
Prof. Msc. Emerson Silas Dória
24
Aplicando a lista de
Associações Típicas
Categoria
Sistema POST
A é um membro de B
Operador - Loja
A é uma sub-unidade organizacional
de B
Não aplicável
A usa ou gerencia B
Operador – POST
Gerente – POST
A se comunica com B
Cliente – Operador
A está relacionado com uma
transação B
Cliente – Pagamento
Operador – Pagamento
A é uma transação relacionada com
outra transação B
Pagamento – Venda
A é possuído por B
POST – Loja
Prof. Msc. Emerson Silas Dória
25
Conceitos e Associações candidatos para
o POST
registra-venda-de
descrito-por
1
Especificação
de Produto
Catálogo
de Produtos
contém
1..*
1
1
0..1
usado-por
*
descreve
*
Item Venda
*
Loja
Item
estoca
1
1
1..*
1
Venda
1
log-vendas
realizadas
6
contido-em
*
1
*
possui
1..*
POST
1
Gerente
iniciado-por
capturada-por
1
1
1
1
1
paga-por
1
Pagamento
1
1
iniciada-por
3registra-venda-no
1
Cliente
1
iniciada-por
1
Prof. Msc. Emerson Silas Dória
Operador
26
Eliminando associações
redundantes ou desnecessárias

Associações cujo conhecimento não precisa ser
preservado podem ser removidas do modelo:
Associação
Consideração
Venda iniciada-por Operador
Conhecimento não exigido nos
requisitos; derivável da associação
Operador registra-vendas-em POST.
Operador registra-vendas-em POST
Conhecimento não exigido nos
requisitos.
POST inicializado-por Gerente
Conhecimento não exigido nos
requisitos.
Venda iniciada-por Cliente
Conhecimento não exigido nos
requisitos.
Loja armazena Item
Conhecimento não exigido nos
requisitos.
ItemVenda registra-venda-de Item
Conhecimento não exigido nos
requisitos.
Prof. Msc. Emerson Silas Dória
27
Preservando Associações de
Compreensão

Preservar apenas associações de
conhecimento pode resultar num modelo que
não transmite um completo entendimento do
domínio:

Exemplo: venda iniciada-por cliente



Remoção deixa de fora um aspecto importante do
domínio - o fato de que um cliente gera uma venda
Modelo conceitual é um artefato de
comunicação ou informação;
Regra geral é enfatizar associações de
conhecimento, mas preservar associações
que enriquecem o entendimento do domínio
Prof. Msc. Emerson Silas Dória
28
Atributos


Um atributo é um dado lógico de um objeto
do domínio
Definidos para conceitos cujos requisitos
(casos de uso) sugerem a necessidade de
preservar algum tipo de informação


Ex.: atributos data e hora para o conceito Venda
Notação na UML
Venda
Atributos
Prof. Msc. Emerson Silas Dória
data
hora:data
29
Identificando Atributos

Atributos devem preferencialmente representar tipos
primitivos de dados ou de valores simples


Ex.: Data, Número, Texto, Hora, Endereço, etc.
Atributos não devem ser usados para:


Representar um conceito complexo
Relacionar conceitos (atributo “chave-estrangeira”)
pior
melhor
Operador
nome
POSTcorrente
Operador
1
usa
1
nome
Prof. Msc. Emerson Silas Dória
POST
número
30
Atributos Não-Primitivos

Podem ser representados diretamente no modelo
conceitual
Especificação de
Produto
upc : UPC

Loja
endereço:Endereço
Um atributo deve ser de tipo não-primitivo quando:

É composto de seções separadas


Precisa ser analisado ou validado


Ex.: CPF, número de matrícula
Possui outros atributos


Ex.: endereço, data
Ex.: Um preço promocional com prazo de validade
É uma quantidade com uma unidade

Ex.: valores monetários, medidas
Prof. Msc. Emerson Silas Dória
31
Adicionando Atributos aos Conceitos
Candidatos do Sistema POST
Conceito
Pagamento
EspecificaçãoProduto
Atributos e justificativa
quantia - Para determinar se
pagamento é suficiente e calcular
troco.
descrição - Para mostrar na tela e
imprimir no recibo.
UCP - Para localizar especificação do
item.
preço - Para calcular o total da venda.
Venda
data, hora - Para imprimir no recibo e
registrar no log de vendas.
ItemVenda
quantidade - Para registrar a
quantidade digitada quando há mais de
um do mesmo item.
Loja
nome, endereço - Para imprimir no
recibo.
Prof. Msc. Emerson Silas Dória
32
Atributo Derivado

Um atributo derivado é um atributo cujo valor
pode ser deduzido a partir de outras
informações


Ex.: quantidade em Item Venda - pode ser
deduzido a partir da multiplicidade da associação
entre Item Venda e Item
Na UML, indicado com o símbolo “/”
Prof. Msc. Emerson Silas Dória
33
Modelo Conceitual Inicial do
POST
Records-sale-of
Described-by
1
Product
Specification
Product
Catalog
Contains
1
Um item da venda pode
estar associado a vários
itens, portanto,
quantidade pode ser
obtida através da
multiplicidade do
relacionamento ItemVenda
e Item
1..*
1
0..1
description
price
UPC
Used-by
*
Describes
*
Sales
LineItem
*
Store
Item
Stocks
/quantity
1
address
name
1
1..*
*
1..*
Logscompleted
6
Contained-in
1
*
Sale
1
Houses
1..*
POST
time
Paid-by
1
Payment
1
Manager
Started-by
date
1
1
Captured-on
1
1
Initiated-by
1
1
3 Records-sales-on
1
Customer
1
Cashier
amount
Prof. Msc. Emerson Silas Dória
34
Definindo Diagramas de
Seqüência (Comportamento do Sistema)
Refin.
Plano
Sinc.
Artefatos
Análise
Projeto
Impl.
1. Definir Casos de
Uso Essenciais a
2. Refinar Diag.
Casos de Uso
3. Refinar Modelo
Conceitual
5. Definir Diag.
Seq.
6. Definir Contrat.
de Operação
7. Definir Diag.
Estado
Teste
4. Refinar
Glossário
b
c
Notas
a. se ainda não feito
b. contínuo
c. opcional
Prof. Msc. Emerson Silas Dória
35
Comportamento do Sistema



Um diagrama de seqüência do sistema é uma figura
que mostra, para o particular cenário de uso, os
eventos que os atores externos geram, sua ordem e
os eventos entre sistemas;
Todos os sistemas são tratados com uma caixa-preta;
a ênfase do diagrama está nos eventos que
atravessam a fronteira do sistema entre atores e
outros sistemas;
Um diagrama de seqüência do sistema deve ser feito
para a seqüência típica de eventos do caso de uso.
Prof. Msc. Emerson Silas Dória
36
Diagrama de Seqüência do
Sistema (Comportamento do Sistema)
O sistema como uma
caixa-preta
Comprar Itens – versão 1
Ator
:Sistema
Operador
Repetir até não
ter mais itens
EntrarItem(UPC,quantidade)
TerminarVenda()
Texto que esclarece o
controle, a lógica, a
iteração, etc.
Pode se obtido do
caso de uso.
RegistrarPagamento(quantia)
Evento de sistema dispara
uma operação de sistema.
Prof. Msc. Emerson Silas Dória
37
Eventos e Operações

Um evento de sistema é um evento externo
de entrada gerado por um ator para um
sistema



Inicia uma operação de resposta do sistema
Uma operação de sistema é uma operação
executada em resposta a um evento de
sistema
O nome do evento e da operação são
idênticos; evento é o estimulo nomeado, e a
operação é a resposta
Prof. Msc. Emerson Silas Dória
38
Eventos e Operações
Comprar Itens – versão 1
:Sistema
Operador
EntrarItem(UPC,quantidade)
evento de sistema “EntrarItem”
ele dispara uma operação de sistema, da
mesma maneira, chamada “EntrarItem”
Prof. Msc. Emerson Silas Dória
39
Representando Operações

O conjunto necessário de operações de
sistema é determinado através da
identificação dos eventos de sistema

Exemplos de operações para o sistema POST:




EntrarItem(UPC, quantidade)
TerminarVenda()
RegistrarPagamento(quantia)
Sistema
EntrarItem(UPC, quantidade)
TerminarVenda()
RegistrarPagamento(quantia)
Na UML, representado como operações de
um tipo denominado Sistema
Prof. Msc. Emerson Silas Dória
40
Definindo Diagramas de
Seqüência (Comportamento do Sistema)

Regras úteis
1. Desenhar uma linha vertical representando o
sistema como uma caixa-preta.
2. Identificar os atores que operam diretamente com
o sistema. Desenhar uma linha vertical
representando cada um desses atores.
3. A partir da descrição das seqüências típicas de
eventos dos casos de uso, identificar e ilustrar os
eventos de sistema que cada ator gera.
4. Opcionalmente, incluir o texto do caso de uso à
esquerda do diagrama.
Prof. Msc. Emerson Silas Dória
41
Definindo Diagramas de
Seqüência (Comportamento do Sistema)
1. Este caso de uso começa quando um Cliente
chega no caixa (equipado com um POST) com
itens que deseja comprar.
2. O Operador registra o identificador de cada
item.
Se houver mais de um exemplar do mesmo
item, o Operador também pode informar a
quantidade.
Comprar Itens – versão 1
:Sistema
Operador
EntrarItem(UPC,quantidade)
TerminarVenda()
4. Após processar o último item, o Operador
indica ao POST que a entrada de itens terminou.
RegistrarPagamento(quantia)
6. O Operador informa o total ao Cliente.
Registre as operações de sistema
requeridas.
Identifique os eventos do sistema
que cada ator gera.
Prof. Msc. Emerson Silas Dória
42
Nomeando Eventos e
Operações

Regras úteis:


Começar com um verbo
Enfatizar “intenção” em vez do meio físico de
entrada ou componente gráfico da interface com o
usuário


Ex.: TerminarVenda em vez de PressionarTeclaEnter
Expressar intenção no nível mais alto de abstração

Ex.: RegistrarPagamento em vez de EntrarQuantia
Prof. Msc. Emerson Silas Dória
43
Definindo Contratos de
Operação
Refin.
Plano
Sinc.
Artefatos
Análise
Projeto
Impl.
1. Definir Casos de
Uso Essenciais a
2. Refinar Diag.
Casos de Uso
3. Refinar Modelo
Conceitual
5. Definir Diag.
Seq.
6. Definir Contrat.
de Operação
7. Definir Diag.
Estado
Teste
4. Refinar
Glossário
b
c
Notas
a. se ainda não feito
b. contínuo
c. opcional
Prof. Msc. Emerson Silas Dória
44
Contratos

Um contrato é um documento que
descreve o que uma operação se
compromete a atingir:



Estilo declarativo
Pré e pós-condições de mudanças de
estado
Para métodos, classes, ou operações gerais
de sistema
Prof. Msc. Emerson Silas Dória
45
Contratos

Exemplo para operação EntrarItem
Contrato:
EntrarItem (UCP:número, quantidade:inteiro)
Responsabilidade:
Registra venda de um item e o adiciona à venda
corrente. Mostra descrição e preço do item
Tipo:
Sistema
Referência Cruzada: Funções: R1.1, R1.3, R1.9
Caso de Uso: Comprar Itens
Usar acesso rápido ao BD
Notas:
Exceções:
Se UPC inválido, indicar erro
Saída:
Pré-condições:
UPC é conhecido do sistema
Prof. Msc. Emerson Silas Dória
46
Contratos

Exemplo para operação EntrarItem
Pós-condições:
Se for uma nova venda, uma Venda foi criada
(criação de instância);
 Se for uma nova venda, a nova Venda foi associada
ao POST (formada uma associação);
 Um ItemVenda foi criado (criação de instância);
 O ItemVenda foi associado à Venda (formada uma
associação);
 ItemVenda.quantidade recebeu o valor de quantidade
(modificação de atributo);
 O ItemVenda foi associado a uma
EspecificaçãoDeProduto, baseada numa
correspondência com o UPCs (formada uma
associação).

Prof. Msc. Emerson Silas Dória
47
Seções de um Contrato
Contrato:
Nome e parâmetros da operação
Responsabilidade:
Descrição informal das responsabilidades da operação
Tipo:
Nome do tipo (conceito, classe, interface)
Referência Cruzada: Número de referência de funções, casos de uso, etc.
Notas:
Notas de projeto, algoritmos, etc.
Exceções:
Casos excepcionais
Saída:
Saídas não-IU, tais como mensagens ou registros
enviados para fora do sistema
Hipóteses e assertivas sobre o estado do sistema
antes da execução da operação
Pré-condições:
Prof. Msc. Emerson Silas Dória
48
Como Fazer um Contrato

Regras úteis:
1. Identificar operações de sistema a partir dos diagramas de
seqüência do sistema;
2. Para cada operação construa um contrato;
3. Começar escrevendo a seção Responsabilidades,
descrevendo informalmente o propósito da operação;
4. Completar a seção Pós-condições, descrevendo de forma
declarativa as mudanças de estado que ocorrem aos objetos
do modelo conceitual;
5. Para descrever as Pós-condições considere as seguintes
categorias:



Criação e remoção de instâncias
Modificação de atributos
Associações formadas e desfeitas (erro mais comum!)
Prof. Msc. Emerson Silas Dória
49
Contratos e Outros Artefatos
Caso de Uso:
Comprar Itens
Sequência
Tipica de
Eventos
1. Este caso de
uso começa...
Caso de Uso
:Sistema
Operador
EntrarItem(UPC,quantidade)
Sistema
Operação: EntrarItem
Pós-Condições:
1. Se tSe for uma nova
venda, uma Venda foi
criada (criação de
instância);
EntrarItem(UPC, quantidade)
TerminarVenda()
TerminarVenda()
RegistrarPagamento(quantia)
RegistrarPagamento(quantia)
DSS
Operações do Sistema
Prof. Msc. Emerson Silas Dória
Operação:
TerminarVenda
Pós-Condições:
1. Venda.Completada
recebe o valor...
Contratos
50
Pós-condições


Pós-condições devem ser expressas no
passado, enfatizando mudanças de estado já
ocorridas
Analogia: Palco e Cortina





Imagine os objetos do sistema no palco de um
teatro
Antes da operação, fotografe o palco
Feche a cortina e execute a operação
Abra a cortina e fotografe o palco novamente
Compare as duas fotos, e então expresse como
pós-condições as mudanças no estado do palco
Prof. Msc. Emerson Silas Dória
51
Contratos para o POST

Operação TerminarVenda
Contrato:
TerminarVenda()
Responsabilidade:
Registrar que é o fim da entrada de itens de venda e
exibir o total da venda
Tipo:
Sistema
Referência Cruzada: Funções: R1.2
Caso de Uso: Comprar Itens
Notas:
Exceções:
Se uma venda não está em andamento, indicar o erro
Saída:
Pré-condições:
UPC é conhecido do sistema
Prof. Msc. Emerson Silas Dória
52
Contratos para o POST

Operação TerminarVenda
Pós-condições:
Venda.Completada recebe o valor true (modificação
de atributos).

Prof. Msc. Emerson Silas Dória
53
Contratos para o POST

Operação RegistrarPagamento:
Contrato:
RegistrarPagamento(quantia:numero)
Responsabilidade:
Registrar o pagamento, calcular o troco e imprimir
recibo.
Tipo:
Sistema
Referência Cruzada: Funções: R2.1
Caso de Uso: Comprar Itens
Notas:
Exceções:
Se a venda não está completa, indicar um erro
Se a quantia for menor que o total da venda, indicar
um erro
Saída:
Pré-condições:
Prof. Msc. Emerson Silas Dória
54
Contratos para o POST

Operação RegistrarPagamento:
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).

Prof. Msc. Emerson Silas Dória
55
Contratos para o POST

Operação Inicializar
Contrato:
Inicializar()
Responsabilidade:
Inicializar o sistema
Tipo:
...
Sistema
...
Pós-condições:

Uma Loja, CatálogodeProdutos,
EspecificaçõesDeProdutos foram criadas (criação de
instâncias);
 CatálogodeProdutos foi associado a
EspecificaçõesDeProdutos (associação formada);
 Loja foi associada a CatálogodeProdutos (associação
formada);
Prof. Msc. Emerson Silas Dória
56
Contratos para o POST

Operação Inicializar
Pós-condições:
Loja foi associada POST (associação formada);
 POST associado a CatálogodeProdutos (associação
formada).

Prof. Msc. Emerson Silas Dória
57
Diagrama da UML

Consulte na página
www2.unoeste.br/~emerson
documentos específicos com os
detalhes sintáticos da UML.
Prof. Msc. Emerson Silas Dória
58