INF1404 MODELAGEM DE SISTEMAS

Transcrição

1 INF1404 MODELAGEM DE SISTEMAS Bacharelado em Sistemas de Informação Ivan Mathias Filho Programa Capítulo 2 Modelagem de Casos de Uso 1ª Parte

2 Programa Capítulo 2 Modelagem de Casos de Uso 1ª Parte Representa a Visão do Usiário O modelo de Casos de Uso é usado para representar os processos de negócios segundo a visão dos usuários de um sistema.

3 Modelagem de Casos de Uso (1) Os casos de uso são narrativas largamente usadas para elucidar e registrar os requisitos funcionais de um sistema; Eles influenciam muitos aspectos de um projeto, sendo utilizados na construção de vários artefatos ao longo do processo; Os casos de uso são centrados nos usuários; isto é, eles enfatizam os objetivos e as perspectivas dos usuários de um sistema. Modelagem de Casos de Uso (2) Informalmente, os casos de uso são narrativas textuais da interação entre um sistema um ator, que usa o sistema para atingir os seus objetivos. Por exemplo: Processa venda: um cliente chega um ponto de venda com alguns itens para comprar. O caixa usa um Terminal de Vendas para registrar cada item. O sistema exibe os detalhes de cada item e o total geral da venda. O cliente informa os dados para o pagamento, que são validados e registrados pelo sistema. O sistema atualiza os dados do estoque. O cliente recebe o seu recibo e vai embora com as suas compras.

4 Modelagem de Casos de Uso (3) Os casos de uso são documentos textuais, não são diagramas, e a modelagem de casos de uso é principalmente o ato de escrever várias narrativas, e não o de construir diagramas. Processa venda: um cliente chega um ponto de venda com alguns itens para comprar. O caixa usa um Terminal de Vendas para registrar cada item. O sistema exibe os detalhes de cada item e o total geral da venda. O cliente informa os dados para o pagamento, que são validados e registrados pelo sistema. O sistema atualiza os dados do estoque. O cliente recebe o seu recibo e vai embora com as suas compras. Modelagem de Casos de Uso (4) O conjunto de casos de uso define as diferentes maneiras de interação com o sistema; Os atores e os casos de uso são os principais componentes de um modelo de casos de uso. interação caso de uso ator

5 Ator (1) Um ator é uma entidade externa que interage com um dado sistema; Um ator não é necessariamente um ser humano. Ele pode ser também um equipamento ou outro sistema; Um ator não é uma pessoa específica (instância) e sim um papel (classe), que pode ser exercido por várias pessoas distintas; Ator (2) Um maneira de identificar atores é levantar as funções exercidas pelos usuários e sistemas externos; A identificação dos atores ajuda a delimitar a fronteira do sistema (contexto); Uma mesma pessoa pode representar diferentes atores de um sistema. Por exemplo, o caixa de um banco normalmente é também cliente do banco;

6 Ator (3) Um ator deve ter um nome que reflita o seu papel no sistema; Um caso de uso é normalmente iniciado por um ator do sistema. Ator (4) O seguinte questionário pode ser usado para identificar os atores de um sistema : Quem usará as funções principais do sistema? Quem precisará do sistema para executar suas tarefas diárias? Quem manterá e administrará o sistema? Quais os equipamentos que o sistema irá controlar? Com quais outros sistemas o SeC precisará interagir? Quem tem interesse nos resultados que o SeC irá produzir?

7 Tipos de Ator Ator primário tem as suas necessidades atendidas pelo Sistema em Construção (SeC). Por exemplo, o caixa; Ator de suporte provê serviços ao SeC. O Serviço de Autorização de Pagamento de uma administradora de cartões de crédito é um bom exemplo. Um ator de suporte é normalmente um outro sistema, mas pode ser um ser humano ou uma organização; Ator de bastidor tem interesse no comportamento de um caso de uso, mas não interage diretamente com o sistema. Por exemplo, os órgão governamentais de fiscalização. Representação de um Ator Ícone Nome do Ator Cliente

8 Sistema de Ponto de Vendas Atores Relacionamentos entre Atores Generalização Relacionamento hierárquico entre dois atores, indicando que o primeiro representa um conceito mais geral que o segundo. No exemplo, todas as propriedades válidas para um Cliente também são válidas para uma Pessoa Física ou uma Pessoa Jurídica. generalização

9 Associações entre Atores Os atores são, por definição, externos ao sistema e, por tanto, as trocas de informações entre eles está fora do escopo do sistema. Logo: Não PODEMOS relacionar atores através de associações!!! Caso de Uso (1) Definição: Um conjunto de instâncias de caso de uso, onde cada instância é uma seqüência de ações realizadas por um sistema que resulta em algo observável e de valor para um ator em particular. Processa Venda

10 Caso de Uso (2) A frase resulta em algo observável e de valor para um ator em particular sugere o seguinte, segundo Ivar Jacobson: Escreva os caso de uso com os atores (ou usuários) em mente, questionando sobre os seus objetivos; Atente para o que um ator (ou usuário) considera um resultado de valor. Caso de Uso (3) O sistema opera um contrato entre os seus interessados, sendo os casos de uso os responsáveis pelo detalhamento da parte comportamental deste contrato... Os casos de uso, vistos como um contrato de comportamento, representam apenas os comportamentos que satisfaçam os interesses dos interessados de um sistema. Alistair Cockburn in Writing Effective Use Cases

11 Caso de Uso Características Um caso de uso é uma classe e não uma instância; Chamamos de cenário a uma instância de um caso de uso; Um caso de uso define um funcionalidade atômica; ou seja, deve ser visto como uma descrição completa do diálogo de um ou mais atores com um sistema; Não devemos decompor um caso de uso em outros casos de uso mais elementares; A execução de um caso de uso não estará terminada até que o valor final seja produzido, ou que uma exceção seja levantada. Caso de Uso Representação Ícone Processa Venda Nome do Caso de Uso

12 Diagramas de Caso de Uso Apresenta uma visão externa e integrada das funcionalidades de um sistema; Representa graficamente os atores, os casos de uso e os relacionamentos entre tais elementos; Pode ser visto como um diagrama de contexto, uma vez que ele apresenta os elementos externos ao sistema e a maneira como eles interagem com o mesmo; É preciso ter em mente, entretanto, que a principal tarefa da modelagem de casos de uso é a descrição textual dos mesmos. Diagrama Exemplo

13 Associação Caso de Uso Ator Indica que há comunicação entre o caso de uso e o ator; Um ator pode se comunicar com vários casos de uso; O uso de seta de direcionamento (opcional) na associação indica quem iniciou o caso de uso; Cuidado!!! As setas de direcionamento NÃO representam fluxos de informação; Elas indicam apenas quem iniciou um caso de uso, e isto é tudo. O mais comum é que haja informação fluindo nos dois sentidos. Definição dos Atores (1) Pergunta: Em um sistema de informação de uma locadora de vídeo usual, quem são os atores primários do caso de uso de registro do empréstimo?

14 Definição dos Atores (2) O atendente da locadora, pois o cliente não interage diretamente com o sistema. Lembre-se de que todo o diálogo entre o atendente e o cliente está fora do contexto do sistema. Definição dos Atores (3) Pergunta: No sistema de ponto de venda de um supermercado, quem são os atores primários do caso de uso de registro da venda?

15 Definição dos Atores (4) O caixa e o cliente. Lembre-se de que o sistema foi projetado para que o cliente controle visualmente o registro dos itens. Definição dos Atores (5) Além disso, o próprio cliente pode ser o responsável pela entrada dos dados relativos ao seu cartão de crédito.

16 Definição dos Atores (6) A definição dos atores primários depende dos limites (contexto) do sistema em desenvolvimento. Descrição dos Casos de Uso (1) O principal meio de descrição de um caso de uso é através de texto estruturado; A descrição deverá conter as seguintes informações: Uma descrição simples e consistente sobre o modo como o caso de uso e os atores interagem; O objetivo do caso de uso; Como o caso de uso é iniciado; O fluxo das mensagens entre os atores e o caso de uso; Os fluxos alternativos e as condições de exceção;

17 Descrição dos Casos de Uso (2) (continuação) Como o caso de uso termina e o que ele produz em benefício do ator. A descrição textual deve ter as seguintes características adicionais: Concentrar-se no comportamento externo do sistema e ignorar como as tarefas são executadas internamente; Ser clara, de modo que todos os participantes possam compreendê-la facilmente. Descrição Nível de detalhamento (1) Breve uma descrição concisa de um único parágrafo, usualmente o cenário de sucesso (fluxo principal). Quando - dever ser utilizado nos estágio iniciais da análise de requisitos, para que se obtenha um rápido conhecimento do assunto e do escopo do SeC. Casual Múltiplos parágrafos informais que cobrem vários cenários possíveis. Quando o mesmo válido para o formato Breve.

18 Descrição Nível de detalhamento (2) Completo todos os passos e variações são registrados com detalhes. Existem também seções de suporte, tais como precondições e pós-condições. Quando após vários casos de uso terem sido identificados e descritos brevemente, alguns poucos casos de uso (mais ou menos 10%), os mais significativos em termos arquiteturais e de valor para o sistema, serão escritos com este nível de detalhe Descrição Completa (1) A UML não define nenhum padrão para a descrição textual de um caso de uso; Vários modelos foram propostos desde que os casos de uso passaram a ser usados em grande escala; O modelo usado neste curso está baseado na proposta feita por Alistair Cockburn em Writing Effective Use Cases; Cada empresa deve adotar o modelo mais adequado à sua cultura e processo de desenvolvimento.

19 Descrição Completa (2) Descrição Completa (3)

20 Escopo e Nível Escopo: o escopo estabelece os limites (contexto) do SeC; Vários modelos foram propostos desde que os casos de uso passaram a ser usados em grande escala; Nível: Primário: descreve os cenários que atendem as necessidades dos usuários. Secundário: é normalmente criado para fatorar comportamentos comuns a vários casos de uso. O caso de uso secundário é então compartilhado por vários outros casos de uso, evitando esforço duplicado. A classificação acima não faz parte da especificação da UML. Requisitos Especiais (1) Este item está relacionado à descrição dos requisitos não funcionais aplicáveis ao caso de uso em questão. Entre eles podemos citar: Confiabilidade: é a habilidade de um sistema de software de executar suas tarefas de modo correto, como foi definido na sua especificação; Robustez: é a habilidade de um sistema de software de reagir apropriadamente a condições de exceção; Segurança: é a capacidade que um sistema de software tem em impedir que pessoas mal intencionadas ou não autorizadas usem o sistema;

21 Requisitos especiais (2) (Continuação) Performance: é a habilidade que um sistema de software tem em produzir resultados corretos mediante restrições de tempo de resposta e consumo de recursos computacionais; Usabilidade: está relacionada ao grau de facilidade que pessoas com diferentes qualificações têm em usar um sistema de software; Reusabilidade: está relacionada à capacidade de reutilização de componentes de software em diferentes aplicações e contextos; Requisitos especiais (3) (Continuação) Extensibilidade: está relacionada à facilidade que um sistema de software tem em incorporar mudanças nas suas especificações; Portabilidade: está relacionada à facilidade que um sistema de software tem em ser adaptado para operar em diferentes plataformas de hardware e software; Disponibilidade: está relacionada ao tempo máximo tolerável que um sistema pode ficar indisponível para uso.

22 Descrição Completa Exemplo (1) Descrição Completa Exemplo (2)

23 Fluxo Principal (1) Descreve o cenário de sucesso de um caso de uso; Embora não seja errado ou ilegal, o fluxo principal não deve conter condições ou desvios; As condições e os desvios devem ser representados na seção de Extensões. Fluxo Principal (2) As ações, ou passos, que compõem um caso de uso podem ser de três tipos: Interações entre os atores e o sistema; Validações geralmente feitas pelo sistema; Mudanças de estado realizadas pelo sistema por exemplo, registrar ou modificar algo.

24 Fluxo Principal Exemplo Extensões Formam normalmente a maioria do texto que descreve um caso de uso; Descrevem todos os outros cenários possíveis, tanto os de sucesso como os de falha; As extensões representam desvios em relação ao fluxo principal; Dessa forma, a notação usada deve permitir que uma extensão referencie claramente o passo do fluxo principal do qual ela é uma alternativa.

25 Extensões Exemplo (1) Extensões Exemplo (2) Uma extensão pode ser usada também para expressar falhas ou exceções:

26 Extensões Exemplo (3) Podemos representar uma extensão que corresponda a um evento passível de ocorrer durante a execução de qualquer passo de um caso de uso. Exemplo: Como Encontrar Casos de Uso Entrevistas (estruturadas ou não) com os interessados; Observação das rotinas de trabalho dos usuários e da utilização dos sistemas existentes; Estudo da especificação do problema; Estudo de documentos e de bibliografia de referência; Identificação dos diálogos utilizando uma abordagem gráfica (storyboards); As técnicas acima podem e devem ser usadas de forma complementar.

27 Bibliografia Bezerra, E. Princípios de Análise e Projeto de Sistemas com UML. 1ª edição, Campus, Larman, C. Utilizando UML e Padrões. 3ª edição, Bookman, Leffingwell, D., Widrig, D. Managing Software Requirements: A Use Case Approach. 2nd edition, Addison-Wesley, 2003.