PARTE V
Diagramas de Seqüência de Sistema
1
Introdução
• Para dar prosseguimento à análise, é desejável ter
uma noção mais concreta do comportamento
esperado do SSOO na realização de cada caso de uso.
• Na análise, a especificação do comportamento do
SSOO indica o que ele faz sem explicar como.
– O comportamento é definido como uma “caixa preta”.
• O comportamento de um sistema é derivado de seu
modelo de casos de uso.
– fonte para encontrar conceitos para o modelo conceitual.
– fonte para para identificação dos eventos de sistema.
2
Eventos de Sistema
• Um evento de sistema é alguma ocorrência no ambiente do
sistema e para o qual este sistema deve realizar alguma ação
quando da ocorrência do evento.
• No contexto de casos de uso, eventos de sistema correspondem
às ações do ator no cenário de determinado caso de uso.
– No caso particular em que o ator é um ser humano e existe uma
interface gráfica, os eventos do sistema são resultantes de ações desse
ator sobre essa interface gráfica (objetos de fronteira).
• Devemos procurar nessa descrição os passos que correspondem
a ações em que o ator é o sujeito.
• O eventos do sistema são representados em diagramas de
seqüência de sistema (DSS).
3
Diagramas de Seqüência do Sistema
• O DSS é utilizado para especificar graficamente o
comportamento externamente visível de um caso de uso.
– Mostra os atores que interagem com o sistema, o sistema (como uma
caixa preta) e os eventos de sistema que os atores geram.
– Mostra a passagem do tempo de cima para baixo.
– Ilustra os eventos de sistema na ordem em que ocorrem no caso de uso.
• A construção dos DSS corresponde à continuação da
especificação do comportamento do sistema, iniciada no
modelagem de casos de uso.
• De acordo com o Processo Unificado, devemos criar um DSS
para cada fluxo de caso de uso relevante.
4
Exemplo de DSS
DSS para o caso de uso
Emprestar Livro
5
Operações de Sistema
• Um evento de sistema inicia uma operação de
sistema.
• Um evento e sua operação correspondente têm o
mesmo nome (assim como mensagens e métodos).
• Por exemplo, no DSS anterior, temos as seguintes
operações de sistema:
– iniciarEmprestimo(idLeitor)
– emprestarLivro (idLivro)
– encerrarEmprestimo()
6
Operações de Sistema
• O objeto “Sistema” é um artifício de modelagem.
– Na verdade, as operações de sistema são alocadas ao
controlador do caso de uso (categorização BCE, lembra?!).
– Mais sobre isso adiante (padrões GRASP).
• Há dois tipos de operação de sistema:
– Operações com parâmetros, que correspondem a eventos
informativos (e.g., emprestarLivro, iniciarEmprestimo).
– Operações sem parâmetros, que usualmente correspondem
a eventos de controle (e.g., encerrarEmprestimo).
7
Como construir um DSS
• Desenhe um objeto “Sistema” que representa o sistema como
uma caixa preta.
• Desenhe cada ator que participa do caso de uso e uma linha
vertical (linha de vida) para cada ator.
• No texto do caso de uso que descreve uma seqüência típica de
eventos (fluxo principal), identifique os eventos de sistema que
cada ator gera; ilustre-os no diagrama.
– Use um padrão e o bom senso para nomear eventos de sistema.
• Ilustre os eventos de saída, quando existirem.
• (Opcional) inclua o texto do caso de uso à esquerda do
diagrama.
8
PARTE VI
Contratos das Operações
9
Contratos das Operações
• As operações de sistema deve ser bem documentadas, para
evitar redundâncias e inconsistências.
• Um contrato de operação especifica textualmente o
comportamento esperado para uma operação de sistema.
• O catálogo de contratos corresponde a todos os contratos das
operações de sistema.
– Artefato componente do modelo de classes de análise.
• Sua construção parte dos seguintes artefatos:
– do modelo de classes conceitual,
– dos DSS (e da identificação das operações de sistema correspondentes).
10
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.
• 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 operações internas
importantes e/ou complexas do sistema.
11
Seções Típicas de um Contrato
•
•
•
•
•
•
Nome da operação e parâmetros de entrada
Responsabilidade (Objetivo)
Tipo (elemento responsável pela operação)
Notas (e.g., implementação)
Exceções
Referências cruzadas (para casos de uso, regras de
negócio, etc)
• Pré-condições
• Pós-condições
12
Pré-Condições e Pós-Condições
• Pré-Condições
– Representam o estado do sistema antes da invocação da
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.
– Declaram o efeito da operação sobre o sistema, i.e.,
mudanças no estado do sistema, que ocorrem quando a
operação é invocada.
13
Exemplo de Contrato
Operação: encerrarEmpréstimo()
Responsabilidade:
– Encerrar o registro de empréstimo a um leitor.
Referências Cruzadas:
– Caso de Uso “Emprestar Livro”
Pré-Condições:
– um leitor apto a 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”.
14
Como construir o catálogo de contratos
• Para construir o catálogo de contratos:
– Identifique as operações do sistema a partir dos diagramas
de seqüência do sistema.
– Para cada operação do sistema, construa um contrato.
• “OK, mas, como construo cada contrato em
particular?!”
15
Como construir um contrato
• Para construir o contrato de certa operação de sistema, pense
nas seguintes questões:
–
–
–
–
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?
• Comece pela seção Responsabilidade, que deve descrever
informalmente a finalidade (objetivo) da operação.
• Então, escreva a seção Pós-condições.
• Por fim, defina as demais seções.
16
Como construir um contrato (cont)
• Para descrever as cláusulas da seção pós-condições:
– Para cada operação, analise o Modelo Conceitual; para cada
classe desse modelo, defina o que muda quando a operação
de sistema é invocada.
– Observe o DSS, para ter uma melhor idéia do contexto em
que a operação está inserida e o contexto resultante.
• Uma pós-condição deve ser declarativa e orientada a
mudanças de estado, em vez de orientada a ações.
– e.g., “um novo empréstimo foi criado”, em vez de “criar um
empréstimo”.
17
Como construir um contrato (cont)
• As cláusulas da seção pós-condições de um contrato
devem descrever mudanças em objetos do modelo
conceitual
– (objetos de entidade na categorização BCE).
• Cada cláusula da seção pós-condições deve se
encaixar em uma das seguintes categorias:
–
–
–
–
–
Criação de objetos;
Exclusão de objetos;
Modificação do valor de um atributo;
Associação formada entre objetos;
Associação desfeita entre objetos.
18
Conclusões
• Ao escrever os contratos, podemos
– confirmar que o modelo conceitual está correto, ou
– notar erros ou omissões no modelo conceitual.
• Não é provável (nem mesmo necessário) que se crie
um conjunto de contratos completo na fase de análise.
– Alguns detalhes serão descobertos durante a fase de
projeto.
– Isso segue o espírito do desenvolvimento iterativo.
19
Resumo do relacionamento entre artefatos da análise
Caso de Uso:
Comprar Itens
...
1. Este caso de
uso começa...
Caixa
Comprar Itens –
versão 1
:Sistema
entrarItem(CUP, quantidade)
Casos de Uso
terminarVenda()
registrarPagamento(quantia)
DSS´s
Sistema
entrarItem()
terminarVenda()
entrarPagamento()
Operações de sistema
Operação:
entrarItem
Operação:
terminarVenda
...
Pós-condições . . .
Pós-condições:
...
...
Catálogo de contratos
20
Estudo de Caso: PDV
(Livro do Craig Larman)
• DSS para o caso de uso Comprar Itens
• Criação dos contratos das operações:
–entrarItem(CUP,quantidade)
– terminarVenda()
– registrarPagamento(quantia)
21
DSS para o caso de uso Comprar Itens
:Sistema
Caixa
entrarItem(CUP, quantidade)
nome do produto, valor total do item
*[para cada item]
terminarVenda()
registrarPagamento(quantia)
recibo
22
Nome:
Responsabilidade:
entrarItem(CUP: 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: Funções do sistema: R1.1, R1.3,R1.9
Caso de Uso: Comprar Itens
Notas:
Use acesso super-rápido ao banco de dados
Exceções:
Se o CUP não for válido, indique o erro. c.i. = criação de
Saída:
instância
f.a = formada uma
Pré-condições:
O CUP existe (é conhecido do sistema)
associação
Pós-condições:
m.a = modificação
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)
23
Produto, com base no CUP (f.a)
Nome:
terminarVenda()
Responsabilidades: Registrar que é o fim da entrada de itens de
Venda e exibir o total da venda.
Tipo:
Sistema
Refs cruzadas:
Função do sistema: 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:
Uma venda deve ter sido iniciada
Pós-condições:
• Venda.estáCompleta recebeu o valor true (ma)
24
Mudanças no modelo conceitual
• Existe um atributo sugerido no contrato de terminarVenda que
deve ser definido no modelo conceitual.
Venda
estáCompleta: Booleano
data
hora
25
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
Pós-condições:
m.a = modificação de atributo
• 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)
26
Estudo de Caso SCA
• Fornecer Grade de Disponibilidades (CSU03)
• Sumário: Professor fornece a sua grade de
disponibilidade (disciplinas que deseja lecionar,
juntamente com dias e horários em que está disponível)
para o próximo semestre letivo.
• Ator Primário: Professor
27
Estudo de Caso SCA (cont.)
• Fluxo Principal
– 1. Professor indica o desejo de fornecer sua grade de
disponibilidades para o próximo semestre letivo.
– 2. Sistema apresenta a lista de disciplinas disponíveis (conforme
RN04).
– 3. Professor preenche a grade com as disciplinas que deseja
lecionar no próximo semestre letivo.
– 4. Sistema apresenta a lista dias da semana e de horários do
semestre letivo seguinte.
– 5. Professor define dias da semana e horários disponíveis para
o próximo semestre letivo.
– 6. Professor solicita ao sistema que registre sua grade.
– 7. Sistema registra a grade fornecida e apresenta comprovante.
28
Estudo de Caso SCA (cont.)
• Formulário (objeto de fronteira) do caso de uso
29
Estudo de Caso SCA (cont.)
• Nesse caso de uso, há os seguintes eventos de
sistema:
– solicitação de validação de matrícula de professor;
– solicitação de adição de uma disciplina à grade;
– solicitação de adição de um item de disponibilidade (dia,
hora inicial e hora final) à grade;
• As operações de sistema correspondentes são:
–
–
–
–
validarProfessor(matrícula);
adicionarDisciplina(nomeDisciplina);
adicionarItemDisponibilidade(dia, horaInicial, horaFinal).
registrarGrade()
30
Referências
•
Utilizando UML e Padrões, 3º Ed, CRAIG LARMAN
•
Análise e Projetos de Sistemas de Informação Orientados a Objetos, RAUL WAZLAWICK
•
Object-Oriented Software Construction, Second Edition, BERTRAND MEYER
31
Nomenclatura para eventos de sistema
• Eventos não devem ser nomeados em termos dos
meios físicos da entrada de dados ou dos elementos
da interface.
• Em vez disso, devem capturar a intenção do evento.
– Tente enfatizar o objetivo da operação de sistema
correspondente.
• Comece o nome com um verbo na forma infinitiva.
• E.g., o nome “encerraEmprestimo” é melhor que o
nome “botaoEncerrarEmprestimoPressionado”
32
Exemplos de Pós-condições
• Criação de uma instância e sua associação com outra
instância preexistente
– exemplo: “foi criado um Cliente e associado à Videolocadora por
‘cadastra’”
– ou ainda, fazendo referência ao papel e não à associação, “um novo
Cliente foi adicionado em cadastro”.
– em OCL : self.cadastroincluding(Cliente.new).
33
Exemplos de Pós-condições
• Destruição de uma instância
– exemplo: “foi destruído um Cliente cujo nome é igual a nomeCliente”.
– Presume-se que quando uma instância é destruída, todas as associações
ligadas a ela também o sejam.
– em OCL: self.cadastroexcluding(nome=nomeCliente)
– Deve-se tomar cuidado com questões estruturais (associações
obrigatórias) quando um objeto é destruído.
34
Exemplos de Pós-condições
• Criação de uma associação entre duas instâncias
– exemplo: “foi criada uma associação ‘atende’ entre a Videolocadora e o
Cliente cujo nome é igual a nomeCliente”
– ou, fazendo referência ao papel da associação, “o Cliente cujo nome é
igual a nomeCliente foi tornado clienteCorrente”.
– em OCL: self.clienteCorrente=self.cadastro
select(nome=nomeCliente).
35
Exemplos de Pós-condições
• Destruição de uma associação
– exemplo: “foi destruída a associação atende”
– em OCL: “self.clienteCorrentesize=0”
• Modificação do valor de um atributo de uma instância
– exemplo: “O debito do clienteCorrente foi alterado para 50,00”
– em OCL: self.clienteCorrente.debito=50,00
36