A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

1 PARTE V Diagramas de Seqüência de Sistema. 2 Introdução comportamentoPara dar prosseguimento à análise, é desejável ter uma noção mais concreta do comportamento.

Apresentações semelhantes


Apresentação em tema: "1 PARTE V Diagramas de Seqüência de Sistema. 2 Introdução comportamentoPara dar prosseguimento à análise, é desejável ter uma noção mais concreta do comportamento."— Transcrição da apresentação:

1 1 PARTE V Diagramas de Seqüência de Sistema

2 2 Introdução comportamentoPara 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. comportamento o queNa 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.

3 3 Eventos de Sistema evento de sistemaUm 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 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 5 Exemplo de DSS DSS para o caso de uso Emprestar Livro

6 6 Operações de Sistema operação de sistemaUm 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( i dLeitor) –emprestarLivro (idLivro) –encerrarEmprestimo()

7 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 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 9 PARTE VI Contratos das Operações

10 10 Contratos das Operações As operações de sistema deve ser bem documentadas, para evitar redundâncias e inconsistências. contrato de operaçãoUm contrato de operação especifica textualmente o comportamento esperado para uma operação de sistema. catálogo de contratosO 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 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 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 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. efeito da operação sobre o sistema –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 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 LivroEmprestar 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 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 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? ResponsabilidadeComece pela seção Responsabilidade, que deve descrever informalmente a finalidade (objetivo) da operação. Pós-condiçõesEntão, escreva a seção Pós-condições. Por fim, defina as demais seções.

17 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 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 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 20 Resumo do relacionamento entre artefatos da análise Caso de Uso: Comprar Itens Este caso de uso começa... :Sistema Caixa 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 Uso DSS´s Operações de sistema Catálogo de contratos

21 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 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 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 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 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 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 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 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 29 Estudo de Caso SCA (cont.) Formulário (objeto de fronteira) do caso de uso

30 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 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 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. intençãoEm 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 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 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 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 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


Carregar ppt "1 PARTE V Diagramas de Seqüência de Sistema. 2 Introdução comportamentoPara dar prosseguimento à análise, é desejável ter uma noção mais concreta do comportamento."

Apresentações semelhantes


Anúncios Google