Upload
truongtu
View
216
Download
0
Embed Size (px)
Citation preview
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ção 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 Wiki1 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 uma 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 sistema criar
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