modelagem-de-requisitos

Prévia do material em texto

Análise – 1 
 http://erinaldosn.wordpress.com 
Modelagem de Requisitos: Casos de 
Usos 
 
Um caso de uso é uma situação em que o sistema é usado para preencher um ou mais 
dos requisitos do seu usuário, um caso de uso captura um pedaço de funcionalidade que o 
sistema proporciona. Os casos de uso estão no centro do seu modelo, mostrado na figura 
abaixo, uma vez que eles afetam e guiam todos os outros elementos dentro da modelagem do 
seu sistema. 
 Os casos de uso são um excelente ponto de partida 
ara a faceta quase todos os desenvolvimento de sistema 
orientado a objetos, projeto, testes e documentação. Eles 
descrevem os requisitos de um sistema estritamente a partir 
do olhar de fora, eles especificam o valor que o sistema 
oferece aos usuários. Como os casos de uso são requisitos 
funcionais do sistema, que deve ser a primeira saída 
sério de seu modelo depois que um projeto é iniciado. 
Afinal, como você pode começar a desenhar um sistema 
se você não sabe o que vai ser obrigado a fazer? 
Os casos de uso especificar apenas o que seu 
sistema deve fazer, ou seja, os requisitos funcionais do sistema. Eles não especificam o que o 
sistema não deve fazer, ou seja, requisitos não-funcionais do sistema. Os requisitos não 
funcionais geralmente incluem metas de desempenho e linguagens de programação, etc. 
Quando você está trabalhando com os requisitos de um sistema, muitas vezes surgem 
perguntas como se o sistema tem uma exigência particular. Os casos de uso são um meio para 
trazer essas lacunas nos requisitos do usuário para o primeiro plano no início de um projeto. 
É ainda melhor quando a exigência é apresentada como um caso de uso e a parte 
interessada (stackholder) vê que a exigência tem pouco ou nenhum valor para o sistema. Se um 
stackholder pode descartar exigências desnecessárias, tanto dinheiro e tempo são poupados. 
Casos de uso podem ajudar a gerenciar a carga de trabalho de um projeto. Seus casos de 
uso podem ser atribuídos às equipes ou pessoas a serem implementadas e, uma vez que um caso 
de uso representa um valor usuário tangível, você pode acompanhar o andamento do projeto por 
casos de uso entregues. Se e quando um projeto tem problemas de cronogramas, casos de 
uso podem ser descartados ou atrasados para entregar o de valor mais alto mais rápido. 
Os casos de uso também ajudam construir os testes de para o seu sistema. Os casos de 
uso fornecem um excelente ponto de partida para a construção de seus casos de teste e 
procedimentos, porque precisamente capturaram os requisitos do usuário e critérios de sucesso. 
Capturando um requisito do sistema 
Os termos obrigação e deve tem um significado especial e exato quando se trata de 
requisitos. Um requisito obrigatório deve ser cumprido, se o recurso que implementa um 
requisito obrigatório não está no sistema final, então o sistema não atende a esse requisito. 
Um requisito que deveria existir implica que o requisito não é crítico para o funcionamento do 
sistema, mas ainda é desejável. Se o desenvolvimento de um sistema está funcionando 
com problemas que irá causar atrasos na entrega, então os requisitos que deveriam existir são 
muitas vezes sacrificados em primeiro lugar. 
Suponha que você está definindo requisitos para um sistema de gerenciamento de 
conteúdo weblog (SGC). 
2 – Modelagem de Requisitos: Casos de Uso 
 http://erinaldosn.wordpress.com 
Requisito 1: O sistema de gerenciamento de conteúdo deve permitir que um 
administrador crie uma nova conta de blog, desde que os dados pessoais do novo blogueiro 
sejam verificados usando o banco de dados de credenciais de autor. 
Não há realmente uma "melhor maneira" específica para começar a analisar um 
requisito, mas é útil em um primeiro passo olhar para as coisas que interagem com o sistema. 
Em casos de uso, essas coisas externas são chamadas de atores. 
Atores 
Um ator é desenhado em notação UML usando um "homem vara" ou uma caixa 
estereotipada e é rotulado com um nome apropriado. 
O requisito contém um ator Administrador que 
interage com o sistema para criar uma conta de blog. O 
administrador interage com o sistema e não faz parte do 
sistema e, portanto, o administrador é definido como um ator. 
Os atores não têm que ser pessoas reais. Enquanto 
um ator pode ser uma pessoa, ela também poderia ser um sistema de terceiros. Pense em um 
ator como uma caixa preta: você não pode mudar um ator e você não está interessado em saber 
como ele funciona, mas ele deve interagir com o sistema. 
Nem todos os atores são sistemas externos ou pessoas óbvias que interagem com o 
sistema. Um exemplo de um ator comum complicado é o relógio do sistema. O nome por si 
só implica que o relógio faz parte do sistema, mas é realmente? 
É difícil determinar se o relógio do sistema é um ator, porque o relógio não está 
claramente fora do seu sistema. Como se vê, o relógio do sistema é frequentemente descrito 
como um ator, porque não é algo que você pode influenciar. Além disso, descrevendo o 
relógio como um ator vai ajudar ao demonstrar que o sistema precisa realizar uma tarefa com 
base no tempo atual. 
 
Aqui estão algumas perguntas a perguntar-se quando se tenta identificar um ator: 
Identidade uma "coisa" de um de seus requisitos 
A "coisa" é uma pessoa 
real interagindo com o sistema? 
A "coisa" é algo que eu posso 
mudar no projeto do sistema? 
 
Sim Não A "coisa" provavelmente é 
 Análise – 3 
 http://erinaldosn.wordpress.com 
um ator. Tenha cuidado 
quando se trata de pessoas, 
algumas pessoas podem ser 
consideradas parte de seu 
sistema. 
Não Sim A "coisa" provavelmente não 
é um ator. Qualquer coisa 
que você pode afetar e ter 
algum controle sobre ao 
projetar seu sistema é 
susceptível de ser considerada 
uma parte do seu sistema. 
Se você focar apenas os usuários óbvias de seu sistema, então você pode esquecer de 
outras pessoas, tais como auditores, instaladores, mantenedores, atualizadores, e assim por 
diante. Esses atores podem ter poder de veto ou eles podem ter de cumprir importantes 
requisitos não-funcionais, como uma atualização em uma janela de tempo de inatividade de 10 
minutos do sistema e uma atualização sem desligar o sistema, etc. Se estes atores são ignorados, 
estas funções importantes do seu sistema não serão documentadas, e corre o risco de acabar 
com um sistema inútil. 
Alguns atores estão relacionados uns aos outros. 
 
Casos de uso 
Depois de ter capturado um conjunto inicial de atores que interagem com seu sistema, 
você pode montar o modelo exato dessas interações. O próximo passo é encontrar casos onde o 
sistema está sendo usado para completar um trabalho específico para um ator. Os casos de uso 
podem ser identificados a partir dos requisitos do usuário. 
Um caso de uso, ou trabalho, pode ser tão simples como permitir que o usuário efetue 
login ou tão complexo como a execução de uma transação distribuída em vários bancos de 
dados globais. A coisa importante a lembrar é que um caso de uso, a partir da perspectiva do 
usuário, é um uso completo do sistema, haver alguma interação com o sistema, bem como 
alguns resultados dessa interação. 
Um caso de uso em UML é desenhado como uma forma oval com um 
nome que descreve a interação que ele representa. O caso de uso é 
provavelmente a única construção mais poderosa em UML para garantir que o 
sistema faz o que é previsto fazer. 
Há uma regra que pode ser usada para especificar um bom caso de uso: 
Um caso de uso é algo que dá algum resultado mensurável para o usuário ou um 
sistema externo. 
Qualquer parte do comportamento do sistema que atende a esse teste simples é provável 
que seja um bom candidato para um caso de uso. 
4 – Modelagem de Requisitos: Casos de Uso 
 http://erinaldosn.wordpress.com 
Linhas de comunicação 
Vamos mostrar que o ator Administrador participa do caso de uso Criar uma nova Conta 
de Blog usando linhas de comunicação. 
A linha de comunicaçãoconecta 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, ouuma web-Wiki. 
 Análise – 7 
 http://erinaldosn.wordpress.com 
Note que temos alguma redundância entre as duas descrições de casos de uso. Ambas 
necessitam verificar as credenciais do candidato. Nesse momento, este comportamento é 
simplesmente repetido entre as duas descrições de casos de uso. 
Este comportamento repetitivo compartilhado entre os dois casos de uso é melhor 
separado e capturado dentro de um caso de uso totalmente novo. Este novo caso de uso pode ser 
reutilizado pela relação dos casos de uso criar uma nova conta de blog e criar um novo wiki 
pessoal usando o <<include>>. 
 
O relacionamento << include >> declara que o caso de uso na outra ponta da seta 
pontilhada reutiliza completamente todos os passos do caso de uso que está sendo incluído. 
Você também pode ver na figura acima que o caso de uso Examinar Identidade não está 
diretamente ligado ao ator Administrador, ele pega essa conexão a partir dos casos de uso que o 
incluem. No entanto, a conexão com o banco de dados de Credenciais de Autor é agora 
propriedade exclusiva do caso de uso Examinar Identidade. A vantagem dessa mudança é que 
ele enfatiza que o caso de uso Examinar Identidade é o único que depende diretamente de uma 
conexão com o ator banco de dados Credenciais de Autor. 
Para mostrar o relacionamento << include >> nas descrições de casos de uso, você 
precisa remover os passos redundantes das descrições dos casos de uso Criar uma nova conta de 
blog e Criar novo Wiki pessoal e usar o campo Casos Incluídos e incluir :: < nome do caso de 
uso > sintaxe para indicar o caso de uso, onde os passos reutilizados residem. 
A tabela mostra << include >> em uma descrição de caso de uso usando casos incluídos 
e inclui :: < nome do caso de use >. 
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 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 Nenhum 
Gatilho O Administrador solicita ao CMS para criar uma 
nova conta de blog. 
Casos incluídos Examinar Identidade 
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. 
8 – Modelagem de Requisitos: Casos de Uso 
 http://erinaldosn.wordpress.com 
Detalhes da descrição do caso de uso O que o detalhe significa e porque é útil 
 Inclui::Examinar Identidade 
 5 A nova conta de blog é criada. 
 6 Um resumo dos detalhes da nova conta de 
blog é emitido para o autor. 
A descrição do caso de uso Criar um novo Wiki pessoal também recebe um adicional. 
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 Nenhum 
Gatilho O Administrador solicita ao CMS para criar um 
novo Wiki pessoal. 
Casos incluídos Examinar Identidade 
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. 
 Incluído::Examinar Identidade 
 4 O novo Wiki pessoal é criado. 
 5 Um resumo dos detalhes do novo wiki 
pessoal são enviadas via e-mail para o autor. 
A descrição do caso de uso Examinar de Identidade contém passos reutilizáveis. 
Detalhes da descrição do caso de uso O que o detalhe significa e porque é útil 
Requisitos relacionados Requisito 1, Requisito 2 
Objetivo no contexto Detalhes de um autor devem ser examinados e 
verificadas como preciso. 
Pré-condições O autor que está sendo verificado ter adequada 
aprovação de identidade. 
Condição final com sucesso Os detalhes são verificados. 
Condição final com Falha Os detalhes não são verificados. 
Atores Principais Banco de dados de credenciais de autor. 
Atores secundários Nenhum 
Gatilho Credenciais de um autor são fornecidos para o 
sistema de verificação. 
Fluxo principal 1 Os detalhes são fornecidos ao sistema. 
 2 O banco de dados Credenciais de Autor 
verifica os detalhes. 
 3 Os detalhes são retornados como verificado 
pelo banco de dados de credenciais do autor. 
Extensões 2.1 O banco de dados de credenciais do autor 
não verifica os detalhes do autor. 
 2.2 Os detalhes retornam como não verificado. 
Casos especiais 
Às vezes você vai se deparar com um caso de uso, cujo comportamento, quando você 
começa a analisar com mais cuidado, pode ser aplicado a diversos casos diferentes, mas 
com pequenas alterações. 
Vamos que o Sistema de Gerenciamento de Conteúdo contém um caso de uso Criar 
uma nova conta de blog que descreve os passos necessários para criar uma conta, mas que o 
 Análise – 9 
 http://erinaldosn.wordpress.com 
SGC suporta vários tipos diferentes de contas de blog, e os passos necessários para criar cada 
uma dessas contas difere muito ligeiramente a partir do caso de uso original. Você 
quer descrever o comportamento geral para a criação de uma conta de blog – capturado no caso 
de uso Criar uma nova conta Blog e, em seguida, definir os casos de uso especializados no 
qual a conta que está sendo criada é de um tipo específico, como uma conta regular com 
um blog ou uma conta editorial que pode fazer alterações em entradas em um conjunto 
de blogs. 
Este é onde o caso de uso de generalização ocorre. Uma maneira mais comum de se 
referir a generalização é usando o termo herança. Herança de caso de uso é útil quando 
você quer mostrar que um caso de uso é um tipo especial de outro caso de uso. Para mostrar a 
herança do caso de uso, use a seta de generalização para ligar o caso de uso mais geral, ou pai, 
para o caso de uso mais específico. 
 
Dois tipos de conta de blog, regulares e editoriais, podem ser criadas pelo Sistema de 
Gestão. 
Olhando mais atentamente a descrição do caso de uso especializado Criar uma nova de 
conta blog editorial, você pode ver como a maior parte do comportamento do caso de uso 
mais geral Criar uma nova conta de blog é reutilizado. Apenas os detalhes que são específicos 
para a criação de uma nova conta editorial precisam ser adicionados. 
Você pode mostrar que um caso de uso é um caso especial de um caso de uso mais 
geral dentro da descrição detalhada usando o campo Casos de Uso Base. 
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 editorial 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 editorial é 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 Nenhum 
Gatilho O Administrador solicita ao CMS para criar uma 
nova conta de blog editorial que permitirá um 
autor editar entradas em um conjunto de blogs. 
10 – Modelagem de Requisitos: Casos de Uso 
 http://erinaldosn.wordpress.com 
Detalhes da descrição do caso de uso O que o detalhe significa e porque é útil 
Casos de Uso Base Criar uma nova conta de blog 
Fluxo principal 1 O Administrador solicita ao sistemacriar 
uma nova conta de blog 
 2 O Administrador seleciona o tipo de conta 
editorial. 
 3 O Administrador entra com os detalhes do 
autor. 
 4 O Administrador seleciona os blogs sobre 
os quais a conta tem direitos editoriais. 
 5 Os detalhes do autor são verificados. 
 Inclui::Examinar Identidade 
 6 A nova conta de blog editorial é criada. 
 7 Um resumo dos detalhes da nova conta de 
blog editorial é enviado para o autor. 
Extensões 5.1 O autor não está autorizado a editar 
os blogs indicados. 
 5.2 A aplicação conta de blog editorial é 
rejeitada. 
 5.3 A rejeição do aplicativo é registrada como 
parte do histórico do autor. 
Herança de caso de uso é uma forma poderosa de reutilizar um caso de uso de modo 
que você só tem que especificar os passos adicionais que são necessários nos casos de uso mais 
específicos. 
Mas tenha cuidado, usando a herança: 
 Cada passo no caso de uso geral deve ocorrer nos casos de uso especializados. 
 Todas as relações que o caso de uso geral tem com atores externos ou casos de uso, também 
devem fazer sentido nos casos de uso mais especializados. 
O relacionamento <<extend>> 
O relacionamento de caso de uso << extend >> parece um pouco como o 
relacionamento << include >>, mas isso é onde terminam as semelhanças. 
 
O significado de <<extend >> entre casos de uso é um meio para você mostrar que um 
caso de uso pode reutilizar completamente o comportamento de outro caso de uso, semelhante 
ao relacionamento << include >>, mas que essa reutilização era opcional e dependente, quer em 
um tempo de execução ou decisão de implementação do sistema. 
A partir do exemplo SGC, o caso de uso Criar uma nova Conta de Blog pode 
querer registrar que um novo autor pediu a conta e foi rejeitado, acrescentando essa informação 
para o histórico do autor de aplicação. Passos extras podem ser adicionados a descrição do caso 
de uso Criar uma nova conta de Blog para mostrar esse comportamento opcional. 
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 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 Nenhum 
Gatilho O Administrador solicita ao CMS para criar uma 
 Análise – 11 
 http://erinaldosn.wordpress.com 
Detalhes da descrição do caso de uso O que o detalhe significa e porque é útil 
nova conta de blog. 
Casos incluídos Examinar Identidade 
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. 
 Inclui::Examinar Identidade 
 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 autor não tem permissão para criar um 
novo blog. 
4.2 O aplicativo rejeita conta de blog. 
4.3 A rejeição do aplicativo é registrada como 
parte do histórico do autor. 
O mesmo comportamento capturado no passo 4.3 também seria útil se o cliente tivesse 
uma conta recusada por algum motivo durante a execução do caso de uso Criar um novo Wiki 
pessoal. De acordo com os requisitos, este comportamento reutilizável é opcional em ambos os 
casos; você não quer registrar uma rejeição se o pedido para uma conta de blog ou um wiki 
pessoal foi aceito. O relacionamento << extend >> é ideal neste tipo de situação de reutilização. 
 
O novo caso de uso de Registrar falha de aplicativo captura todo o comportamento 
associado com o registro de falha de uma aplicação de autor seja para um wiki pessoal ou 
para um tipo específico de conta de blog. Usando a relação << extend >>, o comportamento 
do caso de uso Registrar falha de aplicativo é opcionalmente reutilizado pelos casos de uso 
Criar uma conta de blog novo e Criar um novo wiki pessoal se um pedido for rejeitado. 
Exercícios 
1. Responda: 
a) Qual é a notação da UML para um caso de uso? 
b) Qual é a notação da UML para um ator? 
c) Qual é a notação utilizada na UML para o relacionamento de generalização? 
12 – Modelagem de Requisitos: Casos de Uso 
 http://erinaldosn.wordpress.com 
d) Defina o que significa um ator. 
e) Quais são os objetivos dos diagramas de casos de uso? 
2. Complete a tabela abaixo indicando os tipos de relacionamentos que pode haver entre: 
 Atores Casos de Uso Ator e 
Caso de Uso 
Comunicação 
Inclusão 
Extensão 
Generalização 
3. Construa um modelo de casos de uso para a seguinte situação: 
Estamos criando um serviço de entregas. Nossos clientes podem nos requisitar a entrega de 
volumes. Alguns volumes são considerados de maior valor por nossos clientes, e, portanto, 
eles querem ter tais volumes segurados durante o transporte. Contratamos uma companhia 
de seguro para segurar volumes de valor. 
4. Identifique os atores e elabore os diagramas de casos de uso para o sistema de controle de 
uma biblioteca descrito a seguir: 
Um sistema de suporte para uma biblioteca. A biblioteca empresta livros e revistas para 
clientes, que são registrados no sistema, no qual também estão registrados os livros e as 
revistas. A biblioteca controla a compra de novos títulos. Um cliente pode reservar um livro 
ou revista que não está disponível no momento na biblioteca, de forma que quando ele for 
devolvido ou comprado pela biblioteca, o cliente é avisado. A reserva é cancelada quando o 
cliente retira o livro ou revista, ou através de um processo exclusivo de cancelamento. A 
biblioteca pode facilmente criar, atualizar e apagar informações sobre seus títulos, clientes, 
empréstimos e reservas no sistema. O sistema pode rodar em todos os ambientes (UNIX, 
Linux, Windows, etc.) e tem uma interface gráfica (GUI) moderna. O sistema deve ser 
facilmente estendido com novas funcionalidades. 
5. Identifique os atores e elabore o diagrama de casos de uso para um sistema de controle de 
uma máquina que vende refrigerante, descrito a seguir: 
Um sistema de venda de refrigerante em máquina automatizada. O sistema deve estar 
preparado para receber e conferir o dinheiro colocado pelo cliente, inclusive dar o troco. 
Deve controlar a recarga de refrigerantes pelo técnico, bem como o recolhimento do 
dinheiro da máquina. 
6. Considere a seguinte narrativa do caso de uso Realizar Saque. Identifique os erros existentes 
na narrativa. Construa uma nova versão deste caso de uso que não contenha os erros 
encontrados. 
A operação de um caixa eletrônico tem início a partir de uma sessão em que o cliente 
seleciona a opção de realizar saque. O cliente então escolhe uma quantia a ser retirada, a 
partir de um conjunto de opções de quantia disponíveis. 
O sistema verifica se a conta correspondente tem saldo suficiente para satisfazer a 
requisição. Senão, uma mensagem adequada é reportada, o que acarreta na execução da 
extensão. Se há dinheiro suficiente, os números da conta e da agência do cliente são 
enviados ao bando, que aprova ou desaprova a transação. Se a transação á aprovada, a 
máquina libera a quantia correspondente e emite um recibo. Se a transação é desaprovada, 
a extensão informar falha é executada. 
O banco é notificado, independentemente de uma transação aprovada ter sido completada 
ou não pela máquina. Se a transação é completada, o banco realiza o débido na conta do 
cliente. 
7. Construa o modelo de casos de uso para a seguinte situação. Tente identificar também 
regras de negócio que se apliquem à situação, de acordo com o texto fornecido. 
Uma rede de televisão está requisitando um sistema para gerenciar informações sobre uma 
de suas produções televisivas(por exemplo, uma minissérie ou uma novela). 
Uma produção televisiva tem uma verba e é composta de cenas. Cenas são escolhidas em 
uma determinada seqüência. Cada cena tem uma duração em minutos e é gravada em uma 
ou mais fitas. Cada fita possui um número de série e uma capacidade (medida em minutos 
que podem ser gravados na mesma). Deseja-se saber em que fita(s) se encontra uma 
 Análise – 13 
 http://erinaldosn.wordpress.com 
determinada cena. Cada cena pode ter sido gravada muitas vezes (futuramente, na edição 
da obra, o produtor selecionará uma dessas tomadas de cena para compor a versão final 
da produção televisiva). Deve-se manter o registro de todas as cenas filmadas, de quais 
atores e dublês participaram de cada cena. Deseja-se saber também, que dublê substituiu 
que ator em cada cena. 
Para uma produção televisiva como um todo, deseja-se manter a informação de quais 
outros funcionários, os chamados funcionários de apoio, participaram das filmagens. Esses 
funcionários podem ser de diversos tipos (câmeras, iluminadores, contra-regras etc.). Além 
disso, pode haver funcionários de apoio que exerçam mais de uma função na mesma 
produção televisiva. 
Atores e dublês negociam seus salários individualmente, em cada produção televisiva em 
que participam. Os demais funcionários têm um salário fixo por função. É necessário 
também armazenar essas informações para ter uma idéia do consumo de recursos em 
relação à verba. 
Após o término de uma obra, o sistema deve produzir um relatório com o valor a ser pago 
para cada funcionário. O sistema também deve produzir um relatório de informações sobre 
as cenas de uma obra televisiva, e sobre que atores, dublês e demais funcionários 
participaram dessa obra televisiva. 
8. Desenvolva um diagrama de use cases (casos de uso) para um sistema de Locadora de 
Vídeo, equivalente ao módulo de Locação de Mídias de Vídeo, levando em conta os 
seguintes fatos: 
Quando o cliente (sócio) solicitar uma locação ao atendente, o sistema inicialmente 
verifica o cadastro de clientes para levantar sua situação. No caso de não estar cadastrado, 
o cliente deve ser informado de como proceder para tornar-se sócio e, eventualmente ser 
cadastrado. Caso esteja apto a realizar a locação (inclusive com nenhuma mídia por 
devolver, pois caso haja alguma, a locação será recusada), o cliente deverá informar o 
nome do filme ao atendente, neste momento o sistema deverá consultar o cadastro das 
mídias, caso tenha uma mídia disponível o sistema deverá passar para o registro de 
locação onde deverá ser entregue a mídia ao cliente. O atendente ainda será responsável 
pelos casos de uso “Cadastro de Mídia”, “Cadastro de Clientes” e “Manutenção de 
Mídias”, onde para acessá-los é necessário realizar a validação do usuário. 
Bibliografia 
Learning UML 2.0 
Miles, Russ; Hamilton, Kim 
USA: O’Reilly Media, 2006