View
108
Download
0
Category
Preview:
Citation preview
© Nabor C. Mendonça 2001 1
Análise e Projeto Orientados a Objetocom UML e Padrões
Parte III
Análise (1)
© Nabor C. Mendonça 2001 2
Construindo um Modelo Conceitual
a. se ainda não feitob. contínuoc. opcional
2. Refinar Diag. Casos de Uso
3. Refinar ModeloConceitual
4. Refinar Glossário b
6. Definir Contrat.de Operação
1. Definir Casos de Uso Essenciais a
5. Definir Diag.Seq.
7. Definir Diag.Estado c
Notas
Sinc.Artefatos Análise Projeto TesteRefin.
Plano Impl.
Um Ciclo de Desenvolvimento
© Nabor C. Mendonça 2001 3
Modelo Conceitual
Artefato mais importante da AOO
Representa conceitos relevantes (do ponto de vista do modelador) do domínio do problema
Na UML, ilustrado com diagramas de estruturas estáticas contendo:– Conceitos
– Associações entre conceitos
– Atributos de conceitos
© Nabor C. Mendonça 2001 4
Modelo Conceitual para o Sistema POST
Diagrama parcial
POST
Item
Store
addressname
Sale
datetime
Payment
amount
SalesLineItem
quantity
Stocked-in
*
Houses
1..*
Contained-in
1..*
Records-sale-of
0..1
Paid-by
1
1
1
1
1
1
1
1
Captured-on
Concept
Association
Attributes
© Nabor C. Mendonça 2001 5
Idéias, coisas, ou objetos do mundo real
Não representam componentes de software!
Conceitos
Store POST Sale
datetime
SalesDatabase software artifact; not partof conceptual modelavoid
software class; not partof conceptual model
Sale
datetime
print()
avoid
© Nabor C. Mendonça 2001 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
© Nabor C. Mendonça 2001 7
Conceitos Típicos
Categoria
Especificação, projeto, ou descrição de coisas
Especificação de produto
Descrição de vôo
Objeto físico ou tangível Terminal de ponto-de-venda
Avião
Lugares Loja
Aeroporto
Transações Venda, Pagamento
Reserva
Exemplos
Itens de transação Itens de venda
Parcelas de pagamento
Container de coisas Loja
Avião
Papéis de pessoas Operador
Piloto
© Nabor C. Mendonça 2001 8
Conceitos Típicos
Coisas em um container Item
Passageiro
Sistemas externos Serviço de crédito
Controle de tráfego aéreo
Nomes abstratos Fome
Aracnofobia
Eventos Venda, Assalto, Reunião
Vôo, Decolagem
Organizações Departamento de vendas
Companhia aérea
Regras e políticas Política de devolução
Política de cancelamento
Categoria Exemplos
© Nabor C. Mendonça 2001 9
Conceitos Típicos
Catálogos Catálogo de produtos
Catálogo de peças
Registros de finança, trabalho, contrato, questões legais
Recibo, Contrato de trabalho
Registro de manutenção
Manuais, livros Manual do empregado
Manual de reparos
Instrumentos e serviços financeiros Linha de crédito
Ações
Categoria Exemplos
© Nabor C. Mendonça 2001 10
Identificando Conceitos e Atributos em Descrições Textuais
Usar com cuidado!– Linguagens naturais: imprecisão e ambigüidade
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando um Cliente chega no caixa com itens para comprar.2. O Operador registra o identi-ficador de cada item.Se há mais de um do mesmo item, o Operador também pode informar a quantidade.
3. Determina o preço do item e adiciona informação sobre o item à transação de venda em anda-mento.Mostra a descrição e o preço do item corrente.
© Nabor C. Mendonça 2001 11
Conceitos Candidatos para o Sistema POST
Conceitos restritos ao caso de uso Comprar Itens - Versão 1
StorePOST SaleItem
Payment
SalesLineItem
Cashier Customer Manager
ProductCatalog
ProductSpecification
© Nabor C. Mendonça 2001 12
Conceitos de Relatório
Não incluir no modelo conceitual quando:– Toda informação contida no relatório é derivada de
outras fontes
Incluir no modelo conceitual quando:– Relatório tem um papel especial em termos das
regras de negócio
Ex.: Recibo de venda dá direito à devolução dos itens comprados
Incluir Recibo no modelo conceitual para o sistema POST?– Sim, mas apenas no ciclo de desenvolvimento que
trata do caso de uso Devolver Itens
© Nabor C. Mendonça 2001 13
Criando um Modelo Conceitual
Passos sugeridos:
1. Liste os conceitos candidatos para os casos de usos em questão usando a lista de categorias comuns e identificação textual de nomes.
2. Desenhe-os em um modelo conceitual.
3. Adicione as associações necessárias para registrar os relacionamentos para os quais é preciso preservar alguma memória (*)
4. Adicione os atributos necessários para cumprir os requisitos de informação. (*)
(*) A ser discutido
© Nabor C. Mendonça 2001 14
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
Criando um Modelo Conceitual
Vôo Aeroporto
nome
Vôo
destinoou... ?
© Nabor C. Mendonça 2001 15
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 é
deletado
– reduz informações redundantes ou duplicadas
Muito comum no domínio de produtos e vendas
Ex.:
Conceitos de Especificação ou Descrição
Item
descriçãopreçonúmero serialUPC
Especificação-ProdutoItem
Número serial
Descreve1 *
descriçãopreçoUPC
pior melhor
© Nabor C. Mendonça 2001 16
Outro exemplo:
Conceitos de Especificação ou Descrição
pior
melhor
Vôo
datanúmerohora
Aeroporto
nome
Voa-para
1*
Vòo
datahora
Descrição-Vôo
número
Aeroporto
nome
Descreve-vôo-para
Descrito-por
1*
1
*
© Nabor C. Mendonça 2001 17
Conceitos e a 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”
Os termos “tipo” e “interface” são usados para denotar especificações de classes de implementação
No âmbito do curso, o termo “conceito” denota entidades do mundo real, e “classe” denota componentes de software e suas especificações
© Nabor C. Mendonça 2001 18
Associações
Uma associação é um relacionamento entre conceitos que indica uma conexão significativa e interessante
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
© Nabor C. Mendonça 2001 19
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
SalePOST Records-current 11
association name multiplicity
-"direction reading arrow"-it has no meaning except to indicate direction of reading the association label-often excluded
© Nabor C. Mendonça 2001 20
Associações Típicas
Categoria
A é uma parte lógica de B (*) Item de Venda - Venda
Escala - Vôo
A é uma parte física de B (*) Gaveta - POST
Asa - Avião
A está fisicamente contido em B (*) POST - Loja
Passageiro - Avião
A está logicamente contido em B (*)
Descrição-Item - Catálogo
Vôo - Roteiro de Viagem
Exemplos
A é uma descrição de B Descrição-Item - Item
Descrição-Vôo - Vôo
A é conhecido/registrado/repor-tado/capturado em B (*)
Venda - POST
Reserva - Terminal de Reserva
A é um item de uma transação ou relatório B
Item de Venda - Venda
Opção de Reserva - Reserva
(*) Alta prioridade
© Nabor C. Mendonça 2001 21
Associações Típicas
Categoria
A é uma sub-unidade organizacional de B
Departamento - Loja
Manutenção - Companhia Aérea
A é um membro de B Operador - Loja
Piloto - Companhia Aérea
A usa ou gerencia B Operador - POST
Piloto - Avião
A se comunica com B Cliente - Operador
Agente de Reserva - Passageiro
Exemplos
A está relacionado com uma transação B
Cliente - Pagamento
Passageiro - Bilhete
A é possuído por B POST - Loja
Avião - Companhia Aérea
A é uma transação relacionada com outra transação B
Pagamento - Venda
Reserva - Cancelamento
© Nabor C. Mendonça 2001 22
Identificando Associações
Regras úteis:– Focar nas associações cujo conhecimento deve ser
preservado
– Usar nomes baseados em expressões verbais que façam sentido quando lidas no contexto do modelo
– Evitar mostrar associações deriváveis ou redundantes
– É mais importante identificar conceitos do que associações
– Associações demais tendem a confundir um modelo conceitual ao invés de iluminá-lo
© Nabor C. Mendonça 2001 23
Cada ponta de um associação é chamada de um “papel”
Um papel pode ter:– Nome
– Expressão de multiplicidade
– Navegabilidade
Papeis de Uma Associação
ItemStore Stocks
*
multiplicity of the role
1
© Nabor C. Mendonça 2001 24
O valor da multiplicidade depende do contexto– Ex.: Pessoa Trabalha-para Empresa
Expressões de Multiplicidade
zero or more;"many"
one or more
one to forty
exactly five
T
T
T
T
*
1..*
1..40
5
T3, 5, 8 exactly three,
five or eight
© Nabor C. Mendonça 2001 25
Adicionando Associações ao Modelo Conceitual do Sistema POST
Relacionamentos fundamentais– Venda Capturada-em POST
Para conhecer a venda corrente, calcular total e imprimir recibo
– Venda Paga-por Cliente
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
© Nabor C. Mendonça 2001 26
Aplicando a Lista de Associações Típicas
Categoria
A é uma parte lógica de B Item de Venda - Venda
A é uma parte física de B N.A.
A está fisicamente contido em B POST - Loja
Item - Loja
A está logicamente contido em B Especificação-Produto - Catálogo
Catálogo - Loja
Exemplos
A é uma descrição de B Especificação-Produto - Item
A é conhecido/registrado/repor-tado/capturado em B
Venda (corrente) - POST
Venda (completada) - Loja
A é um item de uma transação ou relatório B
Item de Venda - Venda
© Nabor C. Mendonça 2001 27
Aplicando a Lista de Associações Típicas
Categoria
A é uma sub-unidade organizacional de B
N.A.
A é um membro de B Operador - Loja
A usa ou gerencia B Operador - POST
Gerente - POST
A se comunica com B Cliente - Operador
Exemplos
A está relacionado com uma transação B
Cliente - Pagamento
Operador - Pagamento
A é possuído por B POST - Loja
A é uma transação relacionada com outra transação B
Pagamento - Venda
© Nabor C. Mendonça 2001 28
Conceitos e Associações Candidatos para o Sistema POST
POST
ItemStore
Sale
Payment
SalesLineItem
CashierCustomer
Manager
ProductCatalog
ProductSpecification
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Described-by
*
Records-sale-of
0..1
Started-by
Paid-by Initiated-by
Logs-completed
*
Records-sales-on
1
1
1
1
1
1
11
1
1
1
1
1
1
1
1 1
1
Initiated-by
1
1
© Nabor C. Mendonça 2001 29
Eliminando Associações Redundantes ou Desnecessárias
Associações cujo conhecimento não precisa ser preservado podem ser removidas do modelo:
Associação
Operador Registra-vendas-em POST Conhecimento não exigido nos requisitos.
Venda Iniciada-por Operador Conhecimento não exigido nos requisitos; derivável da associação Operador Registra-vendas-em POST.
POST Inicializado-por Gerente Conhecimento não exigido nos requisitos.
Venda Iniciada-por Cliente Conhecimento não exigido nos requisitos.
Consideração
Loja Armazena Item Conhecimento não exigido nos requisitos.
Item de Venda Registra-venda-de Item Conhecimento não exigido nos requisitos.
© Nabor C. Mendonça 2001 30
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– Ex.: 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!
Regra geral:– Enfatizar associações de conhecimento, mas
preservar associações que enriquecem o entendimento do domínio
© Nabor C. Mendonça 2001 31
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
Sale
datestartTime : Time
attributes
© Nabor C. Mendonça 2001 32
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”)
Cashier
namecurrentPOST
Cashier
name
POST
number
Uses
Worse
Better
not a "simple" attribute
1 1
© Nabor C. Mendonça 2001 33
Podem ser representados diretamente no modelo conceitual
Um atributo deve ser de tipo não-primitivo quando:– É composto de seções separadas
Ex.: endereço, data
– Precisa ser analisado ou validado
Ex.: CPF, número de matrícula
– Possui outros atributos
Ex.: Um preço promocional com prazo de validade
– É uma quantidade com uma unidade
Ex.: valores monetários, medidas
Atributos de Tipo Não-Primitivo
ProductSpecification
upc : UPC
Store
address : Address
© Nabor C. Mendonça 2001 34
Adicionando Atributos aos Conceitos Candidatos do Sistema POST
Conceito
Especificação-Produto 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.
Pagamento quantia—Para determinar se pagamento é suficiente e calcular troco.
Venda data, hora—Para imprimir no recibo e registrar no log de vendas.
Item de Venda quantidade—Para registrar a quantidade digitada quando há mais de um do mesmo item.
Atributos e justificativa
Loja nome, endereço—Para imprimir no recibo.
© Nabor C. Mendonça 2001 35
Atributo Derivado
Um atributo “derivado” é um atributo cujo valor pode ser deduzido a partir de outras informações– Ex.: quantidade em Item de Venda—pode ser
deduzido a partir da multiplicidade da associação entre Item de Venda e Item
Na UML, indicado com o símbolo “/”
SalesLineItem
/quantity
ItemRecords-sale-of0..1 1..*
derived attribute fromthe multiplicity value
© Nabor C. Mendonça 2001 36
Modelo Conceitual Inicial do Sistema POST
POST
ItemStore
addressname
Sale
date
time
Payment
amount
SalesLineItem
/quantity
CashierCustomer
Manager
ProductCatalog
ProductSpecification
descriptionpriceUPC
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Described-by
*
Records-sale-of
0..1
Started-by
Paid-by Initiated-by
Logs-completed
*
Records-sales-on
1
1
1
1
1
1..*
11
1
1
1
1
1
1
1
1 1
1
© Nabor C. Mendonça 2001 37
Registrando Termos no Glossário
Um glossário ou dicionário de modelo é um documento que define os termos (ou vocabulário) do domínio– Similar a um dicionário de dados usado na
modelagem de BD
Fundamental para garantir uma comunicação consistente e um entendimento compartilhado entre usuários e desenvolvedores
Também pode ser usado para registrar restrições de domínio e regras de negócio (não explorado no curso)
© Nabor C. Mendonça 2001 38
Glossário Parcial para o Sistema POST
Categoria
atributo Uma descrição sucinta de um item de venda.
caso de uso Descrição do processo de um cliente comprando itens numa loja.
tipo Um item à venda numa loja.
tipo Um pagamento em dinheiro.
Comentário
atributo O preço de um item de venda.
Termo
Especificação-Produto.descrição :Texto
Comprar Itens
Item
Pagamento
Especificação-Produto.preço :Quantidade
atributo A quantidade de um tipo particular de item comprado.
tipo Uma transação de venda.
tipo Um item particular comprado como parte de uma venda.
Item de Venda.quantidade :Inteiro
Venda
Item de Venda
© Nabor C. Mendonça 2001 39
Definindo Diagramas de Seqüência
a. se ainda não feitob. contínuoc. opcional
2. Refinar Diag. Casos de Uso
3. Refinar ModeloConceitual
4. Refinar Glossário b
6. Definir Contrat.de Operação
1. Definir Casos de Uso Essenciais a
5. Definir Diag.Seq.
7. Definir Diag.Estado c
Notas
Sinc.Artefatos Análise Projeto TesteRefin.
Plano Impl.
Um Ciclo de Desenvolvimento
© Nabor C. Mendonça 2001 40
Diagramas de Seqüência
Um diagrama de seqüência ilustra a ordem das interações dos atores externos com o sistema (representado como uma “caixa-preta”) e os eventos que eles geram
enterItem(UPC, quantity)
:SystemCashier
endSale()
Repeat until nomore items
makePayment(amount)
Text which clarifiescontrol, logic, iteration,etc.
May be taken from theuse case.
ActorBuy Items-version 1
system as black box
system event
it triggers a system operation
© Nabor C. Mendonça 2001 41
Eventos e Operações
Um evento de sistema é um evento externo de entrada gerado por um ator do sistema– Inicia uma operação de resposta de mesmo nome
Uma operação de sistema é uma operação do sistema que executa em resposta a um evento de sistema
enterItem(UPC, quantity)
Cashier
Buy Items-version 1
system event "enterItem"
it triggers a system operationlikewise named "enterItem"
:System
© Nabor C. Mendonça 2001 42
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)
encerrarVenda()
fazerPagamento(quantia)
Na UML, representado como operações de um tipo denominado Sistema:
Representando Operações
System
endSale()enterItem()makePayment()
© Nabor C. Mendonça 2001 43
Definindo Diagramas de Seqüência
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 os eventos de sistema que cada ator gera. Ilustrar os eventos no diagrama.
4. Opcionalmente, incluir o texto do caso de uso à esquerda do diagrama.
© Nabor C. Mendonça 2001 44
Definindo Diagramas de Seqüência
Diagrama de seqüência para o sistema POST com (parte do) texto do caso de uso Compra Itens -Versão 1:
For all items, the Cashier recordsthe UPC and quantity .
On completion of item entry, theCashier indicates to the POSTthat the sale is complete.
The Cashier tells the Customerthe total, and the Customer givesa payment to the Cashier.
The Cashier records the cashreceived amount.
enterItem(UPC, quantity)
Cashier
endSale()
makePayment(amount)
:System
© Nabor C. Mendonça 2001 45
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.: encerrarVenda em vez de pressionarTeclaEnter
– Expressar intenção no nível mais alto de abstração
Ex.: fazerPagamento em vez de entrarQuantia
enterItem(UPC, quantity)
enterKeyPressed(UPC, quantity)
Cashier
worse name
better name
:System
© Nabor C. Mendonça 2001 46
Definindo Contratos de Operação
a. se ainda não feitob. contínuoc. opcional
2. Refinar Diag. Casos de Uso
3. Refinar ModeloConceitual
4. Refinar Glossário b
6. Definir Contrat.de Operação
1. Definir Casos de Uso Essenciais a
5. Definir Diag.Seq.
7. Definir Diag.Estado c
Notas
Sinc.Artefatos Análise Projeto TesteRefin.
Plano Impl.
Um Ciclo de Desenvolvimento
© Nabor C. Mendonça 2001 47
Contratos
Um contrato é um documento que descreve os compromissos de uma operação – Estilo declarativo
– Pré e pós-condições de mudanças de estado
– Para métodos, classes, ou operações gerais de sistema
Exemplo para operação entrarItem:
Contrato:Responsabilidades:
entrarItem (upc :número, quantidade :inteiro)Registra venda de um item e o adiciona à venda corrente. Mostra descrição e preço do item.
Tipo:Referencia:
SistemaFunções: R1.1, R1.3, R1.9Casos de uso: Comprar Itens
© Nabor C. Mendonça 2001 48
Contratos
Exemplo para operação entrarItem (cont.):
Notas:Exceções:Saída:
Usar acesso rápido ao BDSe UPC inválido, indicar erro.
Pré-condições:Pós-condições:
UPC é conhecido do sistema
Se nova venda, uma Venda foi criada (criação de instância). Se nova venda, a nova Venda foi associada com um POST (formação de associação. Um Item-de-Venda foi criado (criação de instância). O Item-de-Venda foi associado à Venda (formação de associação). Item-de-Venda.quantidade foi definido para quantidade (modificação de atributo). O Item-de-Venda foi associado com uma Especificação-Produto, baseado no casamento de UPCs (formação de associação).
© Nabor C. Mendonça 2001 49
Seções de um Contrato
Contrato:Responsabilidades:
Nome e parâmetros da operaçãoDescrição informal das responsabilidades da operação
Tipo:Referencia:
Nome do tipo (conceito, classe, interface)Funções, casos de uso, etc.
Notas:Exceções:
Notas de projeto, algoritmos, etc.Casos excepcionais
Saída: Saídas não-IU, tais como mensagens ou registros enviados para fora do sistema
Pré-condições: Pré-suposições sobre o estado do sistema antes da execução da operação
Pós-condições:
O estado do sistema após a execução da operação
© Nabor C. Mendonça 2001 50
Como Fazer um Contrato
Regras úteis:
1. Identificar operações de sistema a partir dos diagramas de seqüência.
2. Para cada operação, construir 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 declarativamente as mudanças de estado que ocorrem aos objetos do modelo conceitual:
- Criação e remoção de instância
- Modificação de atributo
- Formação e quebra de associações (erro mais comum!)
© Nabor C. Mendonça 2001 51
Como Fazer um Contrato
Regras úteis (cont.):
5. Completar a seção Pré-condições, descrevendo as pré-suposições sobre o estado do sistema no início da operação:
- Coisas que devem ser testadas pelo sistema em algum ponto durante a execução da operação
- Coisas que não são testadas, mas sobre as quais depende fortemente o sucesso da operação
© Nabor C. Mendonça 2001 52
Contratos e Outros Artefatos
Cashier System
enterItem(upc,
quantity)
endSale()
makePayment(amount)
USE CASE:BUYINGITEMS
Typical CourseOf Events
1. This usecase begins ...
Use Case SystemSequenceDiagram
Operation: enterItem
Postconditions:1. If a new sale, anew Sale has beencreated...
Operation: endSale
Postconditions:1. ...
Contracts
System
endSale()enterItem()makePayment()
SystemOperations
© Nabor C. Mendonça 2001 53
Pós-condições: Palco e Cortina
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
© Nabor C. Mendonça 2001 54
Contratos para o Sistema POST
Operação encerrarVenda:
Contrato:Responsabilidades:
encerrarVenda ()Registra o fim da entrada de itens de venda, e mostra o total da venda.
Tipo:Referencia:
SistemaFunções: R1.2 Casos de uso: Comprar Itens
Notas:Exceções:Saída:
Se não há venda corrente, indicar erro.
Pré-condições:Pós-condições:
UPC é conhecido do sistema
Venda.Completada é definido para true (modificação de atributo). Note a necessidade de adicionar o atributo lógico Completada ao conceito Venda!
© Nabor C. Mendonça 2001 55
Contratos para o Sistema POST
Operação fazerPagamento:
Contrato:Responsabilidades:
fazerPagamento (quantia: Número ou Quantidade)Registra o pagamento, calcula troco, e imprime recibo.
Tipo:Referencia:
SistemaFunções: R1.2 Casos de uso: Comprar Itens
Notas:Exceções:
Saída:
Se a venda não completada, indicar erro.Se quantia menor que total, indicar erro.
Pré-condições:Pós-condições:
Um Pagamento foi criado (criação de instância). Pagamento.quantia foi definido para quantia (modificação de atributo).
© Nabor C. Mendonça 2001 56
Contratos para o Sistema POST
Operação fazerPagamento:
Pós-condições (cont.): Um Pagamento foi criado (criação de instância). O Pagamento foi associado com a Venda (formação de associação). A Venda foi associada com a Loja, para adicioná-la ao log de vendas completadas (formação de associação).
© Nabor C. Mendonça 2001 57
Contratos para o Sistema POST
Operação Inicializar:
Contrato:Responsabilidades:
Inicializar ()Inicializa o sistema.
Tipo:Referencia:
Sistema
Notas:Exceções:Saída:
Pré-condições:Pós-condições:
Loja, POST, Catálogo-Produto, e Especificação-Produto foram criados (criação de instância). POST foi associado com Loja, e Catálogo-Produto com Especificação-Produto, POST, e Loja (formação de associação).
Recommended