Modelagem de Casos de Uso (1)

(1)

INF1404 – MODELAGEM DE SISTEMAS

Bacharelado em Sistemas de Informação

Ivan Mathias Filho [email protected]

Programa – Capítulo 2

• Modelagem de Casos de Uso – 1ª Parte

(2)

© LES/PUC-Rio

Programa – Capítulo 2

• Modelagem de Casos de Uso – 1ª Parte

O modelo de Casos de Uso é usado para representar os processos de negócios segundo a visão dos usuários de um sistema.

Representa a Visão do Usiário

(3)

© LES/PUC-Rio

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.

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:

Modelagem de Casos de Uso (2)

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)

© LES/PUC-Rio 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.

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

Modelagem de Casos de Uso (3)

caso de uso ator

interação

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

Modelagem de Casos de Uso (4)

(5)

© LES/PUC-Rio

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

(6)

© LES/PUC-Rio

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.

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

Ator (4)

(7)

© LES/PUC-Rio

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

Tipos de Ator

Cliente

Ícone

Nome do Ator

Representação de um Ator

(8)

© LES/PUC-Rio

Sistema de Ponto de Vendas – Atores

generalização

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.

Relacionamentos entre Atores

(9)

© LES/PUC-Rio

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:

Associações entre Atores

Não PODEMOS relacionar atores através de associações!!!

Processa Venda

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

Caso de Uso (1)

(10)

© LES/PUC-Rio

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

A frase “resulta em algo observável e de valor para um ator em particular” sugere o seguinte, segundo Ivar Jacobson:

Caso de Uso (2)

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

Caso de Uso (3)

Alistair Cockburn in Writing Effective Use Cases

(11)

© LES/PUC-Rio

• 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 – Características

Ícone

Nome do Caso de Uso

Processa Venda

Caso de Uso – Representação

(12)

© LES/PUC-Rio

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

Diagramas de Caso de Uso

Diagrama – Exemplo

(13)

© LES/PUC-Rio

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

Associação “Caso de Uso – Ator”

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)

© LES/PUC-Rio

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.

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?

Definição dos Atores (3)

(15)

© LES/PUC-Rio

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

(16)

© LES/PUC-Rio

A definição dos atores primários depende dos limites (contexto) do sistema em desenvolvimento.

Definição dos Atores (6)

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

Descrição dos Casos de Uso (1)

(17)

© LES/PUC-Rio

• (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 dos Casos de Uso (2)

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

Descrição – Nível de detalhamento (1)

(18)

© LES/PUC-Rio

• 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 – Nível de detalhamento (2)

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

Descrição Completa (1)

(19)

© LES/PUC-Rio

Descrição Completa (2)

Descrição Completa (3)

(20)

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

Escopo e Nível

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

Requisitos Especiais (1)

(21)

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

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

Requisitos especiais (3)

(22)

Descrição Completa – Exemplo (1)

Descrição Completa – Exemplo (2)

(23)

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

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

Fluxo Principal (2)

(24)

Fluxo Principal – Exemplo

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

Extensões

(25)

Extensões – Exemplo (1)

Uma extensão pode ser usada também para expressar falhas ou exceções:

Extensões – Exemplo (2)

(26)

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:

Extensões – Exemplo (3)

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

Como Encontrar Casos de Uso

(27)

Bibliografia

• Bezerra, E. Princípios de Análise e Projeto de Sistemas com UML. 1ª edição, Campus, 2006.

• Larman, C. Utilizando UML e Padrões. 3ª edição, Bookman, 2007.

• Leffingwell, D., Widrig, D. Managing Software Requirements: A Use Case Approach. 2nd edition, Addison-Wesley, 2003.