Diagramas de Sequência e Contrato das Operações

UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Projeto e Desenvolvimento de Sistemas de informação Comportamento do Sistema: Diagramas de Sequência e Contrato das Operações

Atividades da Fase Analisar Refinar Plano Sincronizar artefatos Analisar Projetar Construir Testar 1. Definir Casos de Uso Essenciais 2. Refinar Diagramas de Casos de Uso 3. Refinar o Modelo Conceitual 4. Refinar Glossário 5. Definir Diagramas de Seqüência do Sistema 6. Definir Contratos de Operação

O que já foi visto até agora Casos de Uso Completo Abstrato(descrição textual) Caso de Uso: Emprestar Livro Ator Principal: Atendente Interessados e Interesses: - Atendente: deseja registrar que um ou mais livros estão em posse de um leitor, para controlar se a devolução será feita no tempo determinado. - Leitor: deseja emprestar um ou mais livros, de forma rápida e segura. - Bibliotecário: deseja controlar o uso dos livros, para que não se percam e para que sempre se saiba com que leitor estão no momento. Pré-Condições: O Atendente é identificado e autenticado. Garantia de Sucesso (Pós-Condições): Os dados do novo empréstimo estão armazenados no Sistema. Os livros emprestados possuem status emprestado Cenário de Sucesso Principal: 1. O Leitor chega ao balcão de atendimento da biblioteca e diz ao atendente que deseja emprestar um ou mais livros da biblioteca. 2. O Atendente seleciona a opção para realizar um novo empréstimo. 3. O Atendente solicita ao leitor sua carteira de identificação, seja de estudante ou professor. 4. O Atendente informa ao sistema a identificação do leitor. 5. O Sistema exibe o nome do leitor e sua situação. 6. O Atendente solicita os livros a serem emprestados. 7. Para cada um deles, informa ao sistema o código de identificação do livro. 8. O Sistema informa a data de devolução de cada livro. 9. Se necessário, o Atendente desbloqueia os livros para que possam sair da biblioteca. 10. O Leitor sai com os livros. Fluxos Alternativos: (1-8). A qualquer momento o Leitor informa ao Atendente que desistiu do empréstimo. 3. O Leitor informa ao Atendente que esqueceu a carteira de identificação. 1. O Atendente faz uma busca pelo cadastro do Leitor e pede a ele alguma informação pessoal para garantir que ele é mesmo quem diz ser. 4. O Leitor está impedido de fazer empréstimo, por ter não estar apto. 1.Cancelar a operação. 7a. O Livro não pode ser emprestado, pois está reservado para outro leitor. 1. O Atendente informa ao Leitor que não poderá emprestar o livro e pergunta se deseja reservá-lo. 2. Cancelar a operação (se for o único livro) 7b. O Livro não pode ser emprestado, pois é um livro reservado somente para consulta. 1. Cancelar a operação (se for o único livro)

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

Cenários ou Diagramas de Sequência do Sistema (DSS) Para dar prosseguimento à fase de análise, é desejável ter uma noção mais concreta do comportamento esperado do sistema diante dos eventos que fazem parte de cada caso de uso. 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

Operações Os DSSs mostram eventos do sistema, isto é, eventos de Entrada e Saída relativos ao sistema. Os eventos implicam que o sistema tenha operações de sistema para tratar os eventos do sistema, tal qual uma mensagem OO O conjunto completo de operações define a interface pública do sistema, como se fosse um único componente ou classe. Todo sistema pode ser representado na UML por um objeto de uma classe denominada, por exemplo, Sistema. 6

Cenários ou Diagramas de Sequência do Sistema (DSS) Processo Unificado: define-se um DSS para cada caso de uso relevante. Pode haver várias soluções para o mesmo problema. usar a sequência típica de eventos como base

O Diagrama de Sequência do Sistema (DSS) Mostra uma particular sequê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 sequência típica eventos do caso de uso e, possivelmente, outros DSSs podem ser criados para as sequências alternativas mais interessantes.

O Diagrama de Sequência do Sistema (cont.) ATOR. SISTEMA O tempo corre no sentido de cima para baixo. A ordem dos eventos deve seguir a ordem no caso de uso...

Ex: Caso de Uso Essencial Emprestar Livro Sequência Típica de Eventos Ação do Ator 1. O Leitor chega ao balcão de atendimento da biblioteca e diz ao atendente que deseja emprestar um ou mais livros da biblioteca, entregando a ele a sua carteirinha. 2. O Atendente seleciona a opção para realizar um novo empréstimo. 3. O Atendente informa ao sistema a identificação do leitor. 5. O Atendente solicita os livros a serem emprestados. Resposta do Sistema 4. O Sistema exibe o nome do leitor e sua situação 10

Ex: Caso de Uso Essencial Emprestar Livro Sequência Típica de Eventos (cont.) Ação do Ator 6. Para cada livro, o atendente informa ao sistema o seu código de identificação. 8. O atendente encerra o empréstimo de livros Resposta do Sistema 7. O Sistema informa a data de devolução de cada livro. 9. O sistema registra o empréstimo realizado 10. Se necessário, o Atendente desbloqueia os livros para que possam sair da biblioteca. 11. O leitor sai com os livros. 11

Exemplo DSS para o caso de uso Emprestar Livro

Exemplo DSS alternativo para o caso de uso 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 dois têm o mesmo nome (assim como mensagens e métodos). Os eventos e operações também podem ser de saída.

Evento de Entrada X Evento de Saída

Construção do Diagrama de Para cada Caso de Uso: Sequência Desenhe uma linha vertical representando o sistema como uma caixa preta. Identifique cada ator que opera diretamente sobre o sistema e desenhe uma linha vertical para cada ator. No texto do caso de uso que descreve uma sequência típica de eventos, identifique os eventos de sistema que cada ator gera; ilustre-os no diagrama. Opcionalmente, inclua o texto do caso de uso à esquerda do diagrama.

TPV: Caso de Uso Essencial Comprar Itens Versão 1 Ação do Ator 1. Este caso de uso começa quando um cliente chega a um ponto de pagamento equipado com um TPV, com vários itens que deseja comprar Sequência Típica de Eventos Resposta do Sistema 2. O caixa registra cada item e, 3. O sistema determina o preço do caso seja mais que um item do cada item e acrescenta informação mesmo produto, registra também a sobre o item à transação de vendas quantidade. em andamento. A descrição e o preço do item são apresentados. 3. No término da entrada de itens, o caixa indica para o TPV que a entrada de itens está completa 5. O caixa informa ao cliente o total da venda. 4. O Sistema calcula e apresenta o total da venda 17

TPV: Caso de Uso Essencial Comprar Itens Versão 1 Sequência Típica de Eventos (cont.) Ação do Ator 6. O cliente dá um pagamento em dinheiro. O valor fornecido é possivelmente maior que o total da venda. 7. O Caixa registra a quantia fornecida. Resposta do Sistema 8. O sistema calcula e apresenta o troco devido ao cliente 9. O caixa deposita o dinheiro recebido e retira o troco devido 11. O caixa dá o troco e o recibo ao cliente. 12. O cliente sai com as compras 10. O sistema registra a venda completada e imprime o recibo 18

Estudo de Caso: Diagrama de Sequência do Sistema para o Caixa loop Caso de Uso Comprar Itens Comprar Itens versão 1 :Sistema entraritem(cup, quantidade) terminarvenda() registrarpagamento(quantia)

Operações do sistema O conjunto das operações é definido pelos eventos dos sistema. entraritem(cup, quantidade) terminarvenda() registrarpagamento(quantia) Na UML: TipoX Sistema Operação1() Operação2() entraritem() terminarvenda() registrarpagamento()

Operações do Sistema: onde devem ser especificadas? O conceito (classe) sistema, sugerida no slide anterior é um tanto abstrata, não fazendo parte do mundo real pode ser considerada uma solução de projeto. As operações poderiam ser alocadas aos conceitos (tipos) já existentes no modelo conceitual (um passo mais adiante...)

Nota: porque os itens não foram exibidos no monitor de vídeo e o recibo não foi impresso? Como esses eventos de saída poderiam ser especificados? Veremos mais adiante o que acontece com o contrato associado às operações deste diagrama de sequência.

Diagrama de Sequência do Sistema para o Caso de Uso Comprar Itens (mostra os eventos de saída) Caixa loop Comprar Itens versão2 entraritem(cup, quantidade) exibiritem terminarvenda() registrarpagamento(quantia) emitirrecibo :Sistema

A fronteira do Sistema Quem é o ator no caso de uso Comprar Itens: o Caixa ou o Cliente? A fronteira sempre pode ser estendida para A fronteira sempre pode ser estendida para incluir operações manuais. Exemplo: O evento abrir a carteira deve ser incluído no escopo do sistema?

Diagrama de Sequência do Sistema para o Caso de Uso Comprar Itens Caixa loop Comprar Itens versão 1 entraritem(cup, quantidade) :Sistema terminarvenda() registrarpagamento(quantia)

Como dar nome aos eventos do sistema? Os eventos não devem ser nomeados em termos dos meios físicos da entrada de dados(teclados, leitores, etc.) ou dos elementos da interface. Devem capturar a intenção da operação. Começar o nome com um verbo na forma infinitiva. terminarvenda é melhor que chavedeentradapressionada

Comportamento do Sistema: Contratos das Operações

Atividades da Fase Analisar Refinar Plano Sincronizar artefatos Analisar Projetar Construir Testar 1. Definir Casos de Uso Essenciais 2. Refinar Diagramas de Casos de Uso 3. Refinar o Modelo Conceitual 4. Refinar Glossário 5. Definir Diagramas de Sequência do Sistema 6. Definir Contratos de Operação 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 é chamada. Depende do modelo conceitual, dos diagramas de sequê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.

Contrato das Operações Sistema entraritem() terminarvenda() registrarpagamento() Os contratos são escritos para cada operação do sistema

Contratos das Operações Características típicas de um contrato: Nome da operação Parâmetros de entrada Objetivos (ou responsabilidade) da operação Referências cruzadas (requisitos e/ou casos de uso) Pré-condições Pós-condições

Pré-Condições Representam o estado do sistema antes da chamada da operação. São os pré-requisitos para que a operação aconteça. Não serão verificadas pela operação, ou seja, assume-se que sejam verdadeiras antes da chamada da operação. Elas devem ter sido verificadas em alguma operação anterior.

Pós-Condições Representam o estado do sistema após a chamada da operação, mostrando o que mudou como consequência da sua execução. Para cada operação, deve-se analisar os conceitos identificados no Modelo Conceitual e definir, para cada possível objeto do sistema, o que muda quando a operação é chamada. Deve-se observar o DSS, para se ter uma melhor idéia do contexto em que a operação está inserida e o contexto resultante.

Pós-Condições Importante: Não são as ações a serem executadas sobre as operações. Ao contrário, são observações sobre objetos do Ao contrário, são observações sobre objetos do modelo conceitual que se tornam verdadeiras ao término das operações

Pós-Condições Categorias usuais de pós condições: Criar objetos Excluit objetos Modificar o valor de um atributo Criar associações entre objetos Excluir associações entre objetos

Observação Deve-se fazer um contrato para cada operação relevante Uma operação pode aparecer em vários DSSs Ex: tanto ao emprestar quanto ao devolver um livro, em algum momento o Atendente informará o ISBN do livro e o sistema deverá fazer uma busca. Assim uma operação buscarlivro(isbn) seria comum aos DSSs com somente um contrato para descrevê-la, mas com referências cruzadas aos dois casos de uso.

Exemplo Sistema Biblioteca iniciaremprestimo() emprestarlivro(id_livro) Encerrar Empréstimo() Qual a responsabilidade de cada 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 Sistema Biblioteca loop

Modelo Conceitual Biblioteca ^ faz * * Reserva período situacao 1 0..1 corresponde a Atendente nome 1 registra * 1 Leitor nome tipo 1 faz * Empréstimo/Devolução data do empréstimo situação corresponde a 0..1 refere-se a > 1 Bibliotecaria nome registra 1 * 1 Livro titulo autor ano ISBN editora tipo LinhaDoEmpréstimo data_prevista_devolução data_entrega_real 1 1..* refere-se a 1 possui * CopiaDoLivro nro sequencial situacao liberadoparaemprestimo 1 41

Exemplo do Contrato para encerrarempréstimo() Operação: encerrarempréstimo() 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.

Como fazer um contrato: Relacionamento entre artefatos Caso de Uso: Comprar Itens... 1. Este caso de uso começa... Casos de Uso Comprar Itens versão 1 Caixa entraritem(cup, quantidade) terminarvenda() :Sistema Sistema registrarpagamento(quantia) Diagrama de Sequência do sistema Operação: entraritem... Pós-condições... Contratos Operação: terminarvenda... Pós-condições:... entraritem() terminarvenda() registrarpagamento() Operações de sistema

Como fazer um contrato Identifique as operações do sistema a partir dos diagramas de sequê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.) Complete a seção Pós-condições, descrevendo de forma declarativa as mudanças de estado que ocorrem aos objetos do modelo conceitual. Para descrever as pós-condições, use as seguintes categorias de mudança de estados de conceitos (futuros objetos) Criação e exclusão/destruição de instâncias. Modificação de atributos. Associações formadas e/ou associações desfeitas.

Pós-condições Deve ser usadas categorias de mudanças de estado. 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ós-condições 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(CUP,quantidade) TerminarVenda() RegistrarPagamento(quantia)

TPV: Relacionamento entre os artefatos gerados Caso de Uso: Comprar Itens... 1. Este caso de uso começa... Casos de Uso Comprar Itens versão 1 Caixa entraritem(cup, quantidade) terminarvenda() :Sistema Sistema registrarpagamento(quantia) Diagrama de Sequência do sistema entraritem() terminarvenda() registrarpagamento() Operação: entraritem... Pós-condições... Operação: terminarvenda... Pós-condições:... Contratos Operação: registrarpagamento... Pós-condições:... Operações de sistema

CONTRATO 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. c.i. = criação de 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ção de) Produto, com base no CUP (f.a) instância f.a = formada uma associação m.a = modificação de atributo

0..1 1..* Modelo conceitual para o domínio do TPV * LinhadeItemdeVenda quantidade Contido-em 1 1 1 Paga-por Venda data tempo 1 Pagamento quantia * 1 1 Iniciada-por Registra-Dados-da v Cliente Registra-venda-de Catálogo de Produtos Usado-por Capturada-em 1 Descritos-por 1 * 1 Loja endereço nome Possui 1 TPV 1..* 1 1 1 1..* Contém 1..* Estoca Iniciado por 1 1 < Registra-Vendas-do * 1 Especificação de Produto descrição preço CUP * Descreve Item Gerente Caixa 1 1

CONTRATO 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 Notas: Exceções: Caso de Uso: Comprar Itens 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)

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

CONTRATO Nome: Iniciar Responsabilidades: Iniciar o sistema. Tipo: Sistema Refs cruzadas: Notas: Exceções: Saída: Pré-condições: Pós-condições: Uma Loja, TPV, CatálogodeProdutos e (Especificaçãode)Produto foram criadas (ci) c.i. = criação de instância f.a = formada uma associação m.a = modificação de atributo CatálogodeProdutos foi associado a EspecificaçãodeProduto (fa) Loja foi associada a CatálogodeProdutos (fa) Loja foi associada a TPV (fa) TPV foi associado a Gerente (fa)

Próximo Tópico Refinar Plano Sincronizar artefatos Analisar Projetar Construir Testar 1. Definir Casos de Uso Reais 2. Refinar a arquitetura do sistema 4. Definir Diagramas de Classes de Projeto 3. Definir diagramas de interação 5. Definir o Esquema Do Banco de Dados