INF1404 – MODELAGEM DE SISTEMAS

Bacharelado em Sistemas de Informação

Ivan Mathias Filho

ivan@inf.puc-rio.br

© LES/PUC-Rio

Programa – Capítulo 2

• Modelagem de Casos de Uso – 1ª Parte

© LES/PUC-Rio

Programa – Capítulo 2

• Modelagem de Casos de Uso – 1ª Parte

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

Representa a Visão do Usiário

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

© LES/PUC-Rio

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.

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

© LES/PUC-Rio

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)

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

© LES/PUC-Rio

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;

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

© LES/PUC-Rio

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

© 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

© LES/PUC-Rio

Cliente

Ícone

Nome doAtor

Representação de um Ator

© LES/PUC-Rio

Sistema de Ponto de Vendas – Atores

© LES/PUC-Rio

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

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

© LES/PUC-Rio

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)

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

© LES/PUC-Rio

“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

© 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

© LES/PUC-Rio

Ícone

Nome do Caso de Uso

Processa Venda

Caso de Uso – Representação

© 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

© LES/PUC-Rio

Diagrama – Exemplo

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

© LES/PUC-Rio

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?

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

© LES/PUC-Rio

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)

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

© LES/PUC-Rio

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.

© LES/PUC-Rio

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

Definição dos Atores (6)

© LES/PUC-Rio

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

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

© LES/PUC-Rio

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

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

© LES/PUC-Rio

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

© LES/PUC-Rio

Descrição Completa (2)

© LES/PUC-Rio

Descrição Completa (3)

© LES/PUC-Rio

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

© LES/PUC-Rio

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

© LES/PUC-Rio

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

© LES/PUC-Rio

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

© LES/PUC-Rio

Descrição Completa – Exemplo (1)

© LES/PUC-Rio

Descrição Completa – Exemplo (2)

© LES/PUC-Rio

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

© LES/PUC-Rio

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

© LES/PUC-Rio

Fluxo Principal – Exemplo

© LES/PUC-Rio

• 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

© LES/PUC-Rio

Extensões – Exemplo (1)

© LES/PUC-Rio

Uma extensão pode ser usada também para expressar

falhas ou exceções:

Extensões – Exemplo (2)

© LES/PUC-Rio

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)

© LES/PUC-Rio

• 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

© LES/PUC-Rio

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.