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.

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). O conceito de evento de sistema não é novo...já era utilizado na metodologia estruturada para a construção do modelo ambiental do sistema.

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. De acordo com o Processo Unificado, devemos criar um DSS para cada caso de uso relevante. Deve ser criado um DSS para o fluxo principal do caso de uso em questão. Possivelmente, outros DSSs são criados para as seqüências alternativas mais interessantes.

Exemplo de DSS DSS para o caso de uso Emprestar Livro

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() “Pode-se dizer que as operações [...] de sistema, em conjunto, correspondem à totalidade das funções possíveis do sistema, ou seja, à funcionalidade efetiva total do sistema.” --Raul Waslawick

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

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.

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). Os contratos de todas as operações de um sistema definem o comportamento do mesmo.

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.

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

Pré-Condições e Pós-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.

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

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

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.

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”. Cada uma das cláusulas de pós-condição de um contrato deve declarar as mudanças de estado nos objetos do modelo conceitual.

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.

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.

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 terminarVenda() Sistema entrarItem() terminarVenda() entrarPagamento() 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

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) PDV: Sistema Terminal de Ponto de Vendas

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

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

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)

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

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

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

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.

Estudo de Caso SCA (cont.) Formulário (objeto de fronteira) do caso de uso

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

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

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”

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

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.

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

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