PARTE V Diagramas de Seqüência de Sistema

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 comportamento esperado do SSOO na realização de cada caso de uso. • Na análise, a especificação do comportamento do SSOO indica oque 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 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 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()

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çãoespecifica 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).

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

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álise Caso de Uso: Comprar Itens . . . 1. Este caso de uso começa... Comprar Itens – versão 1 :Sistema Caixa entrarItem(CUP, quantidade) Casos de Uso Sistema entrarItem() terminarVenda() entrarPagamento() terminarVenda() registrarPagamento(quantia) DSS´s Operações de sistema Operação: entrarItem . . . Pós-condições . . . Operação: terminarVenda . . . Pós-condições: . . . Catá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. 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

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: 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. 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 de instância f.a = formada uma associação m.a = modificação de atributo

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

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

26. 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. 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ância f.a = formada uma associação m.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çã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.cadastroincluding(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.cadastroexcluding(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.cadastroselect(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.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