Aula 8
Contratos
Atividades da Fase Analisar
Refinar
Plano
Sincronizar
artefatos
1. Definir Casos de
Uso Essenciais
Analisar
Projetar
2. Refinar Diagramas
de Casos de Uso
4. Definir Diagramas de
Seqüência do Sistema
6. Definir Diagramas de
Estado
Construir
Testar
3. Refinar o Modelo
Conceitual
5. Definir Contratos de
Operação
O que foi visto até agora
Casos de Uso
Completo Abstrato
(descrição textual)
O que já foi visto até agora
Casos de uso com
substantivos e verbos
sublinhados
Caso de Uso 1
Caso de Uso 2
.
.
.
Caso de Uso n
Comportamento do
Sistema (DSS)
• É uma especificação do que o sistema
faz sem explicar como ele o faz.
• O comportamento é definido como
uma “caixa preta”.
• O diagrama de seqüência é utilizado
para especificar parte do
comportamento.
• O comportamento é dependente dos
casos de uso.
Cenários ou Diagramas de
Seqüência do Sistema (DSS)
• Cenários ou DSS mostram um cenário
global do funcionamento do sistema,
dividindo o caso de uso em partes bem
definidas denominadas operações, que
são executadas em resposta aos
eventos
Cenários ou Diagramas de
Seqüência do Sistema (DSS)
• Processo Unificado: um DSS para
cada caso de uso relevante.
• Pode haver várias soluções para o
mesmo problema
O Diagrama de Seqüência
do Sistema (DSS)
• Mostra uma particular seqüência de
eventos dentro de um caso de uso, os
atores que interagem com o sistema, o
sistema (como uma caixa preta) e os
eventos de sistema que os atores geram.
• Deve ser feito para uma seqüência típica
eventos do caso de uso e, possivelmente,
outros DSSs podem ser criados para as
seqüências alternativas mais interessantes.
O Diagrama de Seqüência
do Sistema (cont.)
• O tempo corre no sentido de cima
para baixo.
• A ordem dos eventos deve seguir a
ordem no caso de uso.
Exemplo DSS para o caso de
uso Emprestar Livro
Outro Exemplo DSS para o UC
Emprestar Livro
Eventos e Operações de Sistema
• Um evento de sistema é um evento externo de
entrada para o sistema, gerado por um ator.
• Eventos de sistema podem incluir parâmetros.
• Um evento inicia uma operação de resposta do
sistema.
• Uma operação de sistema é uma operação
executada em resposta a um evento de sistema.
• Os eventos e operações também podem ser de
saída.
Evento de Entrada X Evento de
Saída
Contratos das
Operações
Atividades da Fase Analisar
Refinar
Plano
Sincronizar
artefatos
1. Definir Casos de
Uso Essenciais
Analisar
Projetar
2. Refinar Diagramas
de Casos de Uso
4. Refinar Glossário
6. Definir Contratos de
Operação
Construir
Testar
3. Refinar o Modelo
Conceitual
5. Definir Diagramas de
Seqüência do Sistema
7. Definir Diagramas de
Estado
Contratos das Operações
• É importante que as tarefas
atribuídas às operações sejam bem
documentadas, para evitar
redundâncias e inconsistências.
• Um contrato especifica o
comportamento esperado para cada
operação correspondente a um evento
do sistema.
Contratos das Operações
• Auxiliam a definir o comportamento
do sistema.
• Definem o efeito das operações
sobre o sistema  mudanças de
estado que ocorrem quando uma
operação é invocada
• Depende do modelo conceitual, dos
diagramas de seqüência e da
identificação das operações do
sistema.
Contratos das Operações (cont.)
• A especificação dos contratos segue um
estilo declarativo, enfatizando o que deve
ser feito, sem explicar como.
• Pode ser escrito de maneira informal ou
formal.
• Normalmente é expresso em termos de
pré-condições e pós-condições.
• Deve ser especificado um contrato para
cada operação do sistema (pelo menos
para as mais importantes ou abrangentes)
• Podem ser elaborados também para
métodos importantes e/ou complexos do
sistema.
Contratos das Operações
• Características típicas de um
contrato:
– Nome da operação e Parâmetros de
entrada
– Objetivos (ou responsabilidade)
– Tipo (responsável pela operação)
– Notas e Exceções
– Referências cruzadas
– Pré-condições
– Pós-condições
Pré-Condições
• Representam o estado do sistema
antes da invocação da operação.
• Não serão verificadas pela operação,
ou seja, assume-se que elas são
verdadeiras ao invocar a operação
Pós-Condições
• Representam o estado do sistema após a
invocação da operação, mostrando o que
mudou como conseqüência da sua execução.
• Para cada operação, analisar os conceitos
identificados no Modelo Conceitual e
definir, para cada possível objeto do
sistema, o que muda quando a operação é
invocada.
• Observar o DSS, para ter uma melhor idéia
do contexto em que a operação está
inserida e o contexto resultante.
Exemplo
• Encerrar Empréstimo
– Qual a responsabilidade desta operação?
– Em quais casos de uso ela aparece?
– O que ela considera como verdadeiro
para ser executada?
– O que muda no Modelo Conceitual após
sua invocação?
Exemplo
Operação: encerrarEmpréstimo()
Referências Cruzadas: Caso de Uso:
“Emprestar Livro”
Pré-Condições: um leitor apto ao emprestar
livros já foi identificado; pelo menos um
livro já foi identificado e está disponível
para ser emprestado.
Pós-Condições: um novo empréstimo foi
registrado; o novo empréstimo foi
relacionado ao leitor já identificado na
operação “iniciar o empréstimo”; a situação
dos livros emprestados foi alterada para
“emprestado”.
Caso de Uso:
Comprar Itens
Como fazer um contrato:
Relacionamento entre artefatos
...
1. Este caso de
uso começa...
Caixa
Comprar Itens –
versão 1
:Sistema
entrarItem(CUP, quantidade)
Casos de Uso
terminarVenda()
registrarPagamento(quantia)
Diagrama de Seqüência
do sistema
Sistema
entrarItem()
terminarVenda()
entrarPagamento()
Operações de sistema
Operação:
entrarItem
Operação:
terminarVenda
...
Pós-condições . . .
Pós-condições:
...
...
Contratos
Como fazer um contrato
• Identifique as operações do sistema
a partir dos diagramas de seqüência
do sistema.
• Para cada operação do sistema,
construa um contrato.
• Comece escrevendo a seção
Responsabilidade, descrevendo
informalmente a finalidade (objetivo)
da operação.
Como fazer um contrato
(cont.)
• Então, complete a seção Pós-condições,
descrevendo de forma declarativa as
mudanças de estado que ocorrem nos
objetos do modelo conceitual.
• Para descrever as pós-condições, use as
seguintes categorias:
– Criação e exclusão/instâncias.
– Modificação de atributos.
– Associações formadas e desfeitas.
Pós-condições
• A UML não restringe como as póscondições devem ser expressas.
• Deve ser declarativa e orientada a
mudanças de estado e não orientada a
ações.
• Por isso, usar o verbo no passado. Ex.
– Usar “uma Venda foi criada”, ao invés de
– “criar uma Venda”
• As cláusulas das p.c. estão associadas ao
modelo conceitual. Ao escrevê-las você
pode notar erros ou omissões no modelo
conceitual.
Pós-condições: quão
completas devem ser ?
• Não é provável, e mesmo necessário,
criar um conjunto de pós-condições
completo na fase de análise.
• Alguns detalhes serão descobertos
durante a fase de projeto.
• Isto segue o espírito do
desenvolvimento iterativo.
Estudo de Caso: Sistema
Terminal de Ponto de Vendas
Criação dos contratos das operações:
EntrarItem(codProd,quantidade)
TerminarVenda()
RegistrarPagamento(quantia)
Modelo conceitual para o domínio do PDV
Registra-venda-de
Descritos-por
1..1
Catálogo de Produtos
0..1
*
1..1
LinhadeItemdeVenda
quantidade
1..*
Contido-em
1..1
Venda
data
tempo
Usado-por
Descreve
1..1
*
Estoca
Item
1..1
*
1..1
*
Possui
1..*
Capturada-em
Iniciada-por
Pagamento
quantia
Especificação de Produto
descrição
preço
CUP
1..1
v
1..1 1..1
1..1
1..*
1..1
*
Loja
1..1
endereço
nome
Registra-Dados-da
1..1
Paga-por
Contém
TPV
1..1
Iniciado por
1..*
Gerente
1..1
1..1
1..1
Cliente
< Registra-Vendas-do
1..1
Caixa
Contrato
Nome:
Responsabilidade:
entrarItem(codProd:número, quantidade:inteiro)
Entrar(registrar) a venda de um item e
acrescentá-lo à venda.
Exibir a descrição e o preço do item.
Tipo:
Sistema
Referências cruzadas:Caso de Uso: Comprar Itens
Notas:
Use acesso super-rápido ao banco de dados
Exceções:
Se o codProd não for válido, indique o erro.c.i. = criação de
instância
Saída:
f.a = formada uma
Pré-condições:
O codProd existe (é conhecido do sistema) associação
m.a = modificação
Pós-condições:
de atributo
• Se for uma nova venda, uma Venda foi Criada (c.i.)
• Se for uma nova venda, a nova Venda foi associada ao TPV (f.a)
• Uma LinhadeItemdeVenda foi criada (c.i)
• A LinhadeItemdeVenda foi associada à Venda (f.a)
• LinhadeItemdeVenda.quantidade recebeu o valor de quantidade (m.a)
•A LinhadeItemdeVenda foi associada a um(a) (Especificaçãode)
Produto, com base no codProd (f.a)
Contrato
Nome:
terminarVenda()
Responsabilidades: Registrar que é o fim da entrada de itens de
Venda e exibir o total da venda.
Tipo:
Sistema
Refs cruzadas:
Caso de Uso: Comprar Itens
Exceções:
Se uma venda não está em andamento,
indicar o erro.
Problemas:
Saída:
a. Exibir o
total da
Pré-condições:
Uma venda deve ter sido iniciada
venda
Pós-condições:
pré•
Venda.estáCompleta recebeu o valor true (ma) b. Acondição
c.
No original
traduzido,
está escrito
“recebe” na
póscondição.
Mudanças no modelo
conceitual
• Existe um atributo sugerido no
contrato de terminarVenda que não
aparece no modelo conceitual.
Venda
estáCompleta:Booleano
data
hora
Contrato
Nome:
registrarPagamento(quantia:quantidade)
Responsabilidades: Registrar o pagamento, calcular o troco e
imprimir o recibo.
Tipo:
Sistema
Refs cruzadas:
Função do sistema: 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.
c.i. = criação de instância
Saída:
/ Pré-condições:
f.a = formada uma associação
m.a = modificação de atributo
Pós-condições:
• Um Pagamento foi criado (ci)
• Pagamento.quantiaFornecida recebeu o valor de quantia (ma)
• O Pagamento foi associado à Venda (fa)
•A Venda foi associada à Loja, para acrescentá-la ao registro
histórico de vendas completadas (fa)