INF1404 – MODELAGEM DE SISTEMAS - inf.puc-rio.brivan/PROMINP/NotasAula/MS-CAP-02.pdf · e...
Transcript of INF1404 – MODELAGEM DE SISTEMAS - inf.puc-rio.brivan/PROMINP/NotasAula/MS-CAP-02.pdf · e...
INF1404 – MODELAGEM DE SISTEMAS
Bacharelado em Sistemas de Informação
Ivan Mathias Filho
© 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.