modelagem de requisitos: casos de usos · 2 – modelagem de requisitos: casos de uso requisito 1:...

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


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


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.



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



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


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.



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.



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.



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


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





Pré-condições O autor precisa ter a prova adequada de identidade.



rejeitada.


Atores secundários Nenhum


nova conta de blog.

Casos incluídos Examinar Identidade





autor.

4 Os detalhes do autor são verificados.




Inclui::Examinar Identidade




A descrição do caso de uso Criar um novo Wiki pessoal também recebe um adicional.



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.


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.


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.


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.



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


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.




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.


rejeitada.




nova conta de blog editorial que permitirá um

autor editar entradas em um conjunto de blogs.




Casos de Uso Base Criar uma nova conta de blog



2 O Administrador seleciona o tipo de conta

editorial.


autor.

4 O Administrador seleciona os blogs sobre

os quais a conta tem direitos editoriais.



6 A nova conta de blog editorial é criada.


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.





Pré-condições O autor precisa ter a prova adequada de identidade.



rejeitada.




Análise – 11



nova conta de blog.

Casos incluídos Examinar Identidade





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?



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


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

modelagem de requisitos: casos de usos · 2 – modelagem de requisitos: casos de uso requisito 1:...

Documents