Modelagem de Requisitos: Casos de Usos

Transcrição

1 Modelagem de Requisitos: Casos de Usos Análise 1 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 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 A "coisa" é algo que eu posso real interagindo com o sistema? mudar no projeto do sistema? Sim Não A "coisa" provavelmente é

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

4 4 Modelagem de Requisitos: Casos 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: Requisitos relacionados Alguma indicação de que os requisitos neste caso de uso parcial ou totalmente cumpre. O lugar do caso de uso dentro do sistema e por isso que este caso de uso é importante. O que precisa acontecer antes do caso de uso pode ser executado. Qual deve ser o estado do sistema se o caso de uso executar com sucesso. Qual deve ser o estado do sistema se o caso de uso não executar com êxito. Os principais atores que participam do caso de uso. Muitas vezes, inclui os atores que desencadeiam (provocam) ou recebe informações diretamente de

5 Análise 5 execução de um caso de uso. Atores que participam, mas não são os jogadores principais na execução de um caso de uso. 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 Um autor novo ou existente requisita uma nova conta de blog para o Administrador. O sistema é limitado para autores reconhecidos e então o autor precisa ter a prova adequada de identidade. Uma nova conta de blog é criada para o autor. A aplicação para uma nova conta de blog é rejeitada. Administrador. Banco de dados de credenciais de autor. 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 6 Modelagem de Requisitos: Casos de Uso 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. Requisitos relacionados Requisito 2 Um novo autor ou já existente solicita um novo Wiki pessoal do administrador. O autor ter a prova adequada de identidade. Um novo Wiki pessoal é criado para o autor. O pedido de novo Wiki pessoal é rejeitado. Administrador. Banco de dados de credenciais de autor. 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 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.

7 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 >. Requisitos relacionados Requisito 1 Um autor novo ou existente requisita uma nova conta de blog para o Administrador. O autor precisa ter a prova adequada de identidade. Uma nova conta de blog é criada para o autor. A aplicação para uma nova conta de blog é rejeitada. Administrador. Nenhum 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 8 Modelagem de Requisitos: Casos de Uso 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. Requisitos relacionados Requisito 2 Um novo autor ou já existente solicita um novo Wiki pessoal do administrador. O autor ter a prova adequada de identidade. Um novo Wiki pessoal é criado para o autor. O pedido de novo Wiki pessoal é rejeitado. Administrador. Nenhum 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 para o autor. A descrição do caso de uso Examinar de Identidade contém passos reutilizáveis. Requisitos relacionados Requisito 1, Requisito 2 Detalhes de um autor devem ser examinados e verificadas como preciso. O autor que está sendo verificado ter adequada aprovação de identidade. Os detalhes são verificados. Os detalhes não são verificados. Banco de dados de credenciais de autor. Nenhum 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

9 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. Requisitos relacionados Requisito 1 Um autor novo ou existente requisita uma nova conta de blog editorial para o Administrador. O sistema é limitado para autores reconhecidos e então o autor precisa ter a prova adequada de identidade. Uma nova conta de blog editorial é criada para o autor. A aplicação para uma nova conta de blog é rejeitada. Administrador. Nenhum 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 10 Modelagem de Requisitos: Casos de Uso 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. Requisitos relacionados Requisito 1 Um autor novo ou existente requisita uma nova conta de blog para o Administrador. O autor precisa ter a prova adequada de identidade. Uma nova conta de blog é criada para o autor. A aplicação para uma nova conta de blog é rejeitada. Administrador. Nenhum O Administrador solicita ao CMS para criar uma

11 Análise 11 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 12 Modelagem de Requisitos: Casos de Uso 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

13 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