05 AulaExemplos Casos de USOS parte III

Prévia do material em texto

1
Parte III 
Análise (1)
Análise e Projeto Orientados a Objeto
com UML e Padrões
Construindo um Modelo Conceitual Atores
O diagrama de casos de uso concentra-se em dois itens principais: Atores e 
Casos de uso.
 Atores: representam os papéis desempenhados pelos diversos usuários 
que poderão utilizar, de alguma maneira, os serviços e funções do sistema.
 Eventualmente um ator pode representar algum hardware especial ou 
mesmo outro software que interaja com o sistema, como no caso de um 
sistema integrado.
 Assim, um ator pode ser qualquer elemento que interaja com o software.
 Os atores são representados por símbolos de “bonequinhos magros”;
 Exemplos de atores: 
Gerente Cliente Funcionário Sistemas
integrados
Construindo um Modelo ConceitualCasos de uso
Os casos de uso são utilizados para capturar os requisitos do sistema, ou seja,
referem-se aos serviços, tarefas ou funcionalidades identificadas como necessários
ao software e que podem ser utilizados de alguma maneira pelos atores que
interagem com o sistema, sendo usados para expressar e documentar os
comportamentos pretendidos para as funções do sistema.
Podem ser classificados em primário: quando se referem a um processo
importante. Exemplo: Realizar um saque ou emitir um extrato;
Secundário: Se refere a um processo periférico, como a manutenção de um
cadastro.
Exemplo de caso de uso: Abrir conta
Construindo um Modelo Conceitual Casos de uso
Os casos de uso costumam ser documentados, fornecendo instruções em linhas
gerais de como será seu funcionamento, quais atividades deverão ser executadas,
qual evento forçara sua execução, quais atores poderão utiliza-los e quais suas
possíveis restrições entre outras.
Construindo um Modelo Conceitual
Documentação de Casos de uso
A documentação de um caso de uso costumam descrever, por meio de uma
linguagem bastante simples, informações como a função em linhas gerais do caso
de uso, quais atores interagem com o sistema, quais etapas devem ser executadas
pelo ator e pelo sistema para que o caso de uso execute sua função, quais
parâmetros devem ser fornecidos e quais restrições e validações o caso de uso
deve ter.
Os casos de uso podem ser documentados através de diagrama, como o de
sequencia de máquina de estado ou atividade.
A seguir um exemplo de documentação do caso de uso abertura de conta bancária.
Construindo um Modelo ConceitualDocumentação de Casos de uso
Nome do caso de uso Abrir Conta
Caso de uso Geral
Ator principal: Cliente
Atores secundário Funcionário
Resumo Esse caso de uso descreve as etapas percorridas por um cliente para abrir uma conta 
corrente.
Pré condição O pedido de abertura precisa ter sido previamente aprovado
Pós condição É necessário realizar um saque inicial
Fluxo principal
Ações do ator Ações do sistema
1.Solicitar abertura de conta
2.Consultar cliente por seu CPF ou CNPJ
3. Informar a senha da conta
4. Abrir conta
5. Fornecer valor a ser 
depositado
6. Registrar depósito
7.Emitir cartão da conta
Construindo um Modelo ConceitualDocumentação de Casos de uso
Nome do caso de uso Abrir Conta
Restrições / validações 1. Para abri uma conta corrente é preciso ser maior de idade
2. O valor mínimo de depósito é de R$ 100,00
3. O cliente precisa fornecer algum comprovante de residência
Fluxo alternativo – Manutenção do cadastro de clientes
Ações do ator Ações do sistema
1. Se for necessário, executar caso de uso manter cliente, para gravar ou atualizar o cadastro 
do cliente
Fluxo de exceção – Cliente menor de idade
Ações do ator Ações do sistema
1. Comunicar ao cliente que este não possui a idade mínima para possuir uma conta corrente
2. Recusar o pedido
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
Modelo Conceitual para o Sistema POST
Diagrama parcial
POST
Item
Loja
endereço
nome
Venda
date
hora
Pagamento
Valor total
Vendas
Itens linha
quantidade
Abastecido em
*
Casas
1..*
Contido em
1..*
Registros de vendas
0..1
pagar
1
1
1
1
1
1
1
1
Enviado para 
Conceitos
Associação
Atributos
Ideias, coisas, ou objetos do mundo real
Não representam componentes de software!
Conceitos
Loja POST Venda
data
Hora
BDVendas software artefato; 
não faz parte
de modo conceitual
software classe;
Não faz parte
Do modelo conceitual
Venda
date
time
print()
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
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
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
Conceitos Típicos
Catálogo de produtos
Catálogo de peças
Recibo, Contrato de trabalho
Registro de manutenção
Manual do empregado
Manual de reparos
Linha de crédito
Ações
Catálogos
Registros de finança, trabalho, 
contrato, questões legais
Manuais, livros
Instrumentos e serviços financeiros
Categoria Exemplos
Identificando Conceitos e Atributos em 
Descrições Textuais
Usar com cuidado!
» Linguagens naturais: imprecisão e ambiguidade
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 andamento.
Mostra a descrição e o preço do item
corrente.
Conceitos Candidatos para o Sistema POST
Conceitos restritos ao caso de uso Comprar Itens -
Versão 1
LojaPOST VendaItem
Pagamento
Vendas
Items produto caixa Cliente Gerente
Produto
Catalogo
Produto
especificação
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
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çõesnecessá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
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
destino
ou... ?
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ção
preço
número serial
UPC
Especificação-Produto
Item
Número serial
Descreve
1 *
descrição
preço
UPC
pior melhor
Outro exemplo:
Conceitos de Especificação ou Descrição
pior
melhor
Vôo
data
número
hora
Aeroporto
nome
Voa-para
1*
Vòo
data
hora
Descrição-Vôo
número
Aeroporto
nome
Descreve-vôo-para
Descrito-por
1*
1
*
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 
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
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
VendaPOST Registros-correntes 
11
association name multiplicity
-“seta de direção leitura"
-Muitas vezes excluidos
Ele não tem qualquer relação, com exceção para
indicar a direção da leitura da etiqueta associada
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
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
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 
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
ItemLoja Estoque
*
Multiplicidade de papeis
1
O valor da multiplicidade depende do contexto
» Ex.: Pessoa Trabalha-para Empresa
Expressões de Multiplicidade 
zero ou mais;
“muitos"
Um ou mais
Um para 40
Exatamente cinco
T
T
T
T
*
1..*
1..40
5
T
3, 5, 8 Exatamente três,
Cinco ou oito
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
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
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
Conceitos e Associações Candidatos para o Sistema POST
POST
ItemLoja
Venda
Pagamento
Vendas
Items linha
CaixaCliente
Gerente
Produto
Catalogo
Produto
especificação
estoque
*
Casas
1..*
Uso
*
Contem
1..*
Descreve
*
Captura -no
Contido
1..*
Descrição
*
Registro de vendas
0..1
Inicia
Pago para Inicializa
Logs-
concluidos

*
 Registro de vendas
1
1
1
1
1
1
11
1
1
1
1
1
1
1
1 1
1
Inicializa
1
1
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. 
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 
entendimentodo domínio
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
data
Hora inicio : hora
atributos
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”)
Caixa
name
atualPOST
Caixa
name
POST
numero
Uses
ruim
bom
Não é um simples atributo...
1 1
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
Produto
especificação
upc : UPC
Loja
endereco : ENDERECO
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. 
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 “/”
Vendas - itens
/quantidade
ItemRegistro de vendasf0..1 1..*
Atributo derivado do
Valor da multiplicidade
Modelo Conceitual Inicial do Sistema POST
POST
ItemLoja
Venda
Pagamento
Vendas
Items linha
CaixaCliente
Gerente
Produto
Catalogo
Produto
especificação
estoque
*
Casas
1..*
Uso
*
Contem
1..*
Descreve
*
Captura -no
Contido
1..*
Descrição
*
Registro de vendas
0..1
Inicia
Pago para Inicializa
Logs-
concluidos

*
 Registro de vendas
1
1
1
1
1
1
11
1
1
1
1
1
1
1
1 1
1
Inicializa
1
1
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) 
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
Definindo Diagramas de Seqüência
a. se ainda não feito
b. contínuo
c. opcional
2. Refinar Diag. 
Casos de Uso
3. Refinar Modelo
Conceitual
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 Teste
Refin.
Plano Impl.
Um Ciclo de Desenvolvimento 
Diagramas de Sequê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
IniciaItem(UPC, quantitdade)
:SistemaCaixa
fimVenda()
Repetir enquanto tiver 
items
EfetuarPagamento(montante)
Texto, exemplo para
Controle, logica, iteração,
etc.
Pode ser usada a partir do 
Caso de uso.
Ator
Comprar Items-version 1
Caixa preta
Eventos do sistema
Executa uma operação do sistema
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
Iniciatem(UPC, quantidade)
Caixa
Comprar Items-version 1
Evento sistema “IniciaItem"
Executa uma operação do sistema
Nomeado“IniciaItem"
:Sistema
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
Sistema
fimVenda()
IniciaItem()
EfetuaPagamento()
Definindo Diagramas de Sequê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. 
Definindo Diagramas de Sequência
Diagrama de seqüência para o sistema POST com 
(parte do) texto do caso de uso Compra Itens -
Versão 1:
IniciaItem(UPC, quatidade)
Caixa 
fimVenda()
efetuaPagamento(montante)
:Sistema
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
Definindo Contratos de Operação
a. se ainda não feito
b. contínuo
c. opcional
2. Refinar Diag. 
Casos de Uso
3. Refinar Modelo
Conceitual
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 Teste
Refin.
Plano Impl.
Um Ciclo de Desenvolvimento 
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:
Sistema
Funções: R1.1, R1.3, R1.9
Casos de uso: Comprar Itens
Contratos
Exemplo para operação entrarItem (cont.):
Notas:
Exceções:
Saída:
Usar acesso rápido ao BD
Se UPC inválido, indicarerro.
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).
Seções de um Contrato
Contrato:
Responsabilidades:
Nome e parâmetros da operação
Descriçã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 
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!)
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
Contratos e Outros Artefatos
Cashier System
enterItem
(upc,
quantity)
endSale()
makePayment
(amount)
USE CASE:
BUYING
ITEMS
Typical Course
Of Events
1. This use
case begins ...
Use Case System
Sequence
Diagram
Operation: enterItem
Postconditions:
1. If a new sale, a
new Sale has been
created...
Operation: endSale
Postconditions:
1. ...
Contracts
System
endSale()
enterItem()
makePayment()
System
Operations
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
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:
Sistema
Funçõ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! 
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:
Sistema
Funçõ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).
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).
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).