1

PARTE VDiagramas de Seqüência de Sistema

2

Introdução

• Para dar prosseguimento à análise, é desejável ter uma noção mais concreta do comportamentocomportamento esperado do SSOO na realização de cada caso de uso.

• Na análise, a especificação do comportamentocomportamento do SSOO indica oo queque 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.

3

Eventos de Sistema

• Um evento de sistemaevento 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).

4

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.

5

Exemplo de DSS

DSS para o caso de uso Emprestar Livro

6

Operações de Sistema

• Um evento de sistema inicia uma operação de operação de sistemasistema.

• 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()

7

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).

8

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.

9

PARTE VIContratos das Operações

10

Contratos das Operações

• As operações de sistema deve ser bem documentadas, para evitar redundâncias e inconsistências.

• Um contrato de operaçãocontrato de operação especifica textualmente o comportamento esperado para uma operação de sistema.

• O catálogo de contratoscatá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).

11

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.

12

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

13

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 sistemaefeito da operação sobre o sistema, i.e., mudanças no estado do sistema, que ocorrem quando a operação é invocada.

14

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”.

15

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?!”

16

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 ResponsabilidadeResponsabilidade, que deve descrever informalmente a finalidade (objetivo) da operação.

• Então, escreva a seção Pós-condiçõesPós-condições.

• Por fim, defina as demais seções.

17

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”.

18

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.

19

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.

20

Resumo do relacionamento entre artefatos da análiseCaso de Uso: Comprar Itens

. . .1. Este caso de uso começa...

:SistemaCaixa

Comprar Itens – versão 1

entrarItem(CUP, quantidade)

terminarVenda()

registrarPagamento(quantia)

Sistema

entrarItem()

terminarVenda()

entrarPagamento()

Operação: entrarItem

. . .Pós-condições. . .

Operação: terminarVenda

. . .Pós-condições: . . .

Casos de UsoCasos de Uso

DSS´sDSS´s

Operações de sistemaOperações de sistema

Catálogo de contratosCatálogo de contratos

21

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)

22

:Sistema

Caixa

entrarItem(CUP, quantidade)

terminarVenda()

registrarPagamento(quantia)

recibo

nome do produto, valor total do item

DSS para o caso de uso Comprar Itens

*[para cada item]

23

Nome: entrarItem(CUP: número, quantidade: inteiro) Responsabilidade: Entrar(registrar) a venda de um item e

acrescentá-lo à venda. Exibir a descrição e o preço do item.

Tipo: SistemaReferências cruzadas: Funções do sistema: R1.1, R1.3,R1.9 Caso de Uso: Comprar ItensNotas: Use acesso super-rápido ao banco de dadosExceções: Se o CUP não for válido, indique o erro.Saída:Pré-condições: O CUP existe (é conhecido do sistema)Pós-condições: • 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 CUP (f.a)

c.i. = criação deinstânciaf.a = formada umaassociaçãom.a = modificaçãode atributo

24

Nome: terminarVenda()Responsabilidades: Registrar que é o fim da entrada de itens de Venda e exibir o total da venda.Tipo: SistemaRefs cruzadas: Função do sistema: R1.2 Caso de Uso: Comprar ItensNotas: ---Exceções: Se uma venda não está em andamento, indicar o erro.Saída: ---Pré-condições: Uma venda deve ter sido iniciadaPós-condições:

• Venda.estáCompleta recebeu o valor true (ma)

25

Mudanças no modelo conceitual

• Existe um atributo sugerido no contrato de terminarVenda que deve ser definido no modelo conceitual.

Venda

estáCompleta: Booleanodatahora

26

Nome: registrarPagamento(quantia:quantidade)Responsabilidades: Registrar o pagamento, calcular o troco e imprimir o recibo.Tipo: SistemaRefs cruzadas: Função do sistema: R2.1 Caso de Uso: Comprar ItensNotas: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: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)

c.i. = criação de instânciaf.a = formada uma associaçãom.a = modificação de atributo

27

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

28

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.

29

Estudo de Caso SCA (cont.)

• Formulário (objeto de fronteira) do caso de uso

30

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()

31

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

32

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çãointençã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”

33

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.cadastroincluding(Cliente.new).

34

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.cadastroexcluding(nome=nomeCliente)

– Deve-se tomar cuidado com questões estruturais (associações obrigatórias) quando um objeto é destruído.

35

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.cadastroselect(nome=nomeCliente).

36

Exemplos de Pós-condições

• Destruição de uma associação – exemplo: “foi destruída a associação atende”

– em OCL: “self.clienteCorrentesize=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