A maior rede de estudos do Brasil

Grátis
13 pág.
modelagem-de-requisitos

Pré-visualização | Página 2 de 5

conecta um ator e um caso 
de uso para mostrar o ator participa no caso de uso. 
Há potencial para ter qualquer número de atores 
envolvidos em um caso de uso. Não há limite teórico para o 
número de agentes que podem participar em um caso de uso. 
Para mostrar uma coleção de atores que 
participam em um caso de uso, tudo que você tem a 
fazer é traçar uma linha de comunicação de cada 
um dos atores que participam do oval caso de uso. 
O propósito de uma linha de comunicação é 
mostrar que o ator está simplesmente envolvido em 
um caso de uso, não implica uma troca de 
informações em qualquer direção em particular ou 
que o ator inicia o caso de uso. Esse tipo de informação está contida dentro descrição detalhada 
um caso de uso, portanto não faz sentido aplicar a navegação para as linhas de comunicação. 
Fronteiras do sistema 
Embora haja uma separação implícita entre os atores (externo ao seu sistema) e casos de 
uso (interno ao seu sistema) que marca limite do seu sistema, UML fornece outro pequeno 
pedaço de notação. 
Para mostrar o limite do seu sistema em um diagrama de caso de uso, desenhe uma 
caixa em torno de todos os casos de uso, mas mantenha os atores fora da caixa. É também uma 
boa prática nomear seu caixa depois que o sistema está em desenvolvimento. 
 
Descrição de casos de uso 
Um diagrama mostrando seus casos de uso e atores pode ser um bom ponto de partida, 
mas não fornece detalhes suficientes para analistas de sistema entender exatamente como os 
interesses do sistema serão cumpridos. Como pode um analista de sistema entender quem é o 
ator mais importante a partir da notação de caso de uso sozinho? Que passos estão envolvidos 
no caso de uso? A melhor maneira de exprimir essa informação importante é sob a forma de 
uma descrição de texto, cada caso de utilização deve ser acompanhado por uma. 
Alguns tipos de informações que você pode incluir em suas descrições de casos de uso: 
Detalhes da descrição do caso de uso O que o detalhe significa e porque é útil 
Requisitos relacionados Alguma indicação de que os requisitos neste caso 
de uso parcial ou totalmente cumpre. 
Objetivo no contexto O lugar do caso de uso dentro do sistema e por isso 
que este caso de uso é importante. 
Pré-condições O que precisa acontecer antes do caso de uso pode 
ser executado. 
Condição final com sucesso Qual deve ser o estado do sistema se o caso de uso 
executar com sucesso. 
Condição final com Falha Qual deve ser o estado do sistema se o caso de uso 
não executar com êxito. 
Atores Principais Os principais atores que participam do caso de uso. 
Muitas vezes, inclui os atores que desencadeiam 
(provocam) ou recebe informações diretamente de 
 Análise – 5 
 http://erinaldosn.wordpress.com 
Detalhes da descrição do caso de uso O que o detalhe significa e porque é útil 
execução de um caso de uso. 
Atores secundários Atores que participam, mas não são os ‘jogadores’ 
principais na execução de um caso de uso. 
Gatilho O evento é disparado por um ator que faz com que 
o caso de uso execute. 
Fluxo principal O local para descrever cada um dos passos 
importantes na execução normal de um caso de uso. 
Extensões Uma descrição de quaisquer passos alternativos a 
partir dos descritos no fluxo principal. 
A descrição completo do caso de uso para "Criar uma nova conta de Blog ". 
Detalhes da descrição do caso de uso O que o detalhe significa e porque é útil 
Requisitos relacionados Requisito 1 
Objetivo no contexto Um autor novo ou existente requisita uma nova 
conta de blog para o Administrador. 
Pré-condições O sistema é limitado para autores reconhecidos e 
então o autor precisa ter a prova adequada de 
identidade. 
Condição final com sucesso Uma nova conta de blog é criada para o autor. 
Condição final com Falha A aplicação para uma nova conta de blog é 
rejeitada. 
Atores Principais Administrador. 
Atores secundários Banco de dados de credenciais de autor. 
Gatilho O Administrador solicita ao CMS para criar uma 
nova conta de blog. 
Fluxo principal 1 O Administrador solicita ao sistema criar 
uma nova conta de blog 
 2 O Administrador seleciona um tipo de conta. 
 3 O Administrador entra com os detalhes do 
autor. 
 4 Os detalhes do autor são verificados usando 
o banco de dados de credenciais de autor. 
 5 A nova conta de blog é criada. 
 6 Um resumo dos detalhes da nova conta de 
blog é emitido para o autor. 
Extensões 4.1 O banco de dados de credenciais do autor 
não verifica os detalhes do autor. 
 4.2 O autor da nova conta de blog é rejeitado. 
A descrição na tabela é razoavelmente simples, mas algo não está certo quando você 
compara a descrição do diagrama original de casos de uso. A descrição do caso de uso 
identificou um novo ator, o autor de banco de dados de credenciais. Produza o diagrama de caso 
de uso em sincronia com a descrição do caso de uso, adicionando o ator Banco de Dados de 
Credenciais de Autor. 
 
Não há regra definida para o número de casos de uso que o seu modelo de caso de uso 
deve conter para um determinado sistema. O número de casos de uso depende das tarefas que o 
sistema tem que fazer de acordo com os requisitos. 
6 – Modelagem de Requisitos: Casos de Uso 
 http://erinaldosn.wordpress.com 
Relacionamentos de casos de uso 
Um caso de uso descreve a forma como o sistema se comporta para atender a uma 
exigência. Ao preencher as descrições dos casos de uso, você vai notar que existe alguma 
semelhança entre as etapas em diferentes casos de uso. Você também pode achar que alguns 
casos de uso trabalham em vários modos diferentes ou casos especiais. Finalmente, você 
também pode encontrar um caso de uso com múltiplos fluxos ao longo de sua execução, e que 
seria bom para mostrar casos importantes opcionais em seus diagramas de caso de uso. 
O relacionamento <<include>> 
Os casos de uso normalmente trabalham com atores para capturar uma exigência. As 
relações entre casos de uso são mais uma quebra de procedimentos do seu sistema em pedaços 
manejáveis do que acrescentar algo de novo ao seu sistema. O propósito das relações de caso de 
uso é fornecer designers do seu sistema com alguma orientação arquitetural para que eles 
possam eficientemente quebrar interesses do sistema em partes gerenciáveis dentro do projeto 
de sistema detalhado. 
Suponha que outro requisito é adicionado ao Sistema de Gerenciamento de Conteúdo. 
Requisito 2: O sistema de gerenciamento de conteúdo deve permitir que um 
administrador crie um novo Wiki
1
 pessoal, desde que os dados pessoais do autor da aplicação 
sejam verificados usando o banco de dados Credenciais de Autor. 
 
Detalhes da descrição do caso de uso O que o detalhe significa e porque é útil 
Requisitos relacionados Requisito 2 
Objetivo no contexto Um novo autor ou já existente solicita um novo 
Wiki pessoal do administrador. 
Pré-condições O autor ter a prova adequada de identidade. 
Condição final com sucesso Um novo Wiki pessoal é criado para o autor. 
Condição final com Falha O pedido de novo Wiki pessoal é rejeitado. 
Atores Principais Administrador. 
Atores secundários Banco de dados de credenciais de autor. 
Gatilho O Administrador solicita ao CMS para criar um 
novo Wiki pessoal. 
Fluxo principal 1 O Administrador solicita ao sistema criar um 
novo Wiki pessoal. 
 2 O Administrador entra detalhes do autor. 
 3 Os detalhes do autor são verificados usando 
o banco de dados Credenciais de Autor. 
 4 O novo Wiki pessoal é criado. 
 5 Um resumo dos detalhes do novo wiki 
pessoal são enviadas via e-mail para o autor. 
Extensões 3.1 O banco de dados de credenciais do autor 
não verifica os detalhes do autor. 
 3.2 O autor da nova aplicação Wiki pessoal é 
rejeitado. 
 
1
 Um mecanismo popular para manter documentos. Permitem que os autores on-line criem, editem e 
vinculem páginas da web em conjunto para criar uma rede de conteúdo relacionado, ou