Diagramas de casos de uso Diagramas de casos de uso Além de introduzir casos de uso como elementos principais no desenvolvimento de software, Jacobson (1994) também introduziu um diagrama para visualizar casos de uso. O diagrama de caso de uso também faz parte da UML. Muitas pessoas acham esse tipo de diagrama útil. No entanto, devo enfatizar que você não precisa desenhar um diagrama para usar casos de uso. Um dos projetos mais eficazes que conheço que usaram casos de uso envolveu manter cada um em um cartão de índice e classificar os cartões em pilhas para mostrar o que precisava construir em cada iteração. A Figura 3-2 mostra alguns dos casos de uso para um sistema de negociação financeira. Figura 3-2. Diagrama de caso de uso Um ator é um papel que um usuário desempenha em relação ao sistema. Existem quatro atores na Figura 3-2: Gerente de Negociação, Comerciante, Vendedor e Sistema de Contabilidade. (Sim, eu sei que seria melhor usar o papel da palavra, mas, aparentemente, houve uma tradução errada do sueco.) Provavelmente haverá muitos comerciantes na organização dada, mas, no que diz respeito ao sistema, todos eles jogam O mesmo papel. Um usuário também pode desempenhar mais de uma função. Por exemplo, um comerciante sênior pode desempenhar o papel de Gerente de Negociação e também ser um comerciante regular, um Trader também pode ser um Vendedor. Ao lidar com atores, é importante pensar sobre papéis e não sobre pessoas ou cargos. Os atores executam casos de uso. Um único ator pode realizar muitos casos de uso ao invés, um caso de uso pode ter vários atores a realizá-lo. Na prática, acho que os atores são mais úteis ao tentar chegar aos casos de uso. Diante de um sistema grande, muitas vezes pode ser difícil encontrar uma lista de casos de uso. É mais fácil, nessas situações, chegar à lista de atores primeiro e depois tentar resolver os casos de uso para cada ator. Os atores não precisam ser humanos, mesmo que os atores sejam representados como figuras de vara dentro de um diagrama de caso de uso. Um ator também pode ser um sistema externo que precisa de algumas informações do sistema atual. Na Figura 3-2, podemos ver a necessidade de atualizar as contas do Sistema de Contabilidade. Existem várias variações sobre o que as pessoas mostram como atores. Algumas pessoas mostram todo sistema externo ou ator humano no diagrama de caso de uso que outros preferem mostrar o iniciador do caso de uso. Eu prefiro mostrar ao ator que obtém valor do caso de uso, que algumas pessoas se referem como o principal ator. No entanto, eu não levo isso longe demais. Estou feliz em ver o sistema contábil obter valor, sem tentar descobrir o ator humano que obtém valor do sistema contábil que implicaria a modelagem do próprio sistema contábil. Dito isto, você sempre deve questionar os casos de uso com os atores do sistema, descobrir quais são os objetivos dos usuários reais e considerar formas alternativas de atingir esses objetivos. Quando estou trabalhando com atores e casos de uso, não me preocupo muito com o relacionamento exato entre eles. Na maioria das vezes, o que eu realmente aprendo são os casos de uso, os atores são apenas uma maneira de chegar lá. Enquanto eu tiver todos os casos de uso, não estou preocupado com os detalhes dos atores. Existem algumas situações em que pode valer a pena seguir os atores mais tarde. O sistema pode precisar de configuração para vários tipos de usuários. Neste caso, cada tipo de usuário é um ator, e os casos de uso mostram o que cada ator precisa fazer. Seguir quem quer casos de uso pode ajudá-lo a negociar prioridades entre vários atores. Alguns casos de uso não possuem links claros para atores específicos. Considere uma empresa de serviços públicos. Claramente, um de seus casos de uso é Send Out Bill. Não é tão fácil identificar um ator associado, no entanto. Nenhuma função de usuário particular solicita uma conta. A conta é enviada ao cliente, mas o cliente não se oporia se não acontecesse. O melhor palpite de um ator aqui é o Departamento de cobrança, na medida em que obtém valor do caso de uso. Mas o faturamento geralmente não está envolvido na execução do caso de uso. Esteja ciente de que alguns casos de uso não aparecerão como resultado do processo de pensar sobre os casos de uso para cada ator. Se isso acontecer, não se preocupe demais. O importante é entender os casos de uso e os objetivos do usuário que eles satisfazem. Uma boa fonte para identificar casos de uso são eventos externos. Pense em todos os eventos do mundo exterior ao qual você deseja reagir. Um determinado evento pode causar uma reação do sistema que não envolve usuários, ou pode causar uma reação principalmente dos usuários. Identificar os eventos que você precisa reagir irá ajudá-lo a identificar os casos de uso. Relacionamentos de casos de uso Além dos links entre atores e casos de uso, você pode mostrar vários tipos de relações entre os casos de uso. O relacionamento de inclusão ocorre quando você tem um pedaço de comportamento que é semelhante em mais de um caso de uso e você não deseja continuar copiando a descrição desse comportamento. Por exemplo, tanto Analyze Risk e Price Deal exigem que você valorize o negócio. Descrever a avaliação do negócio envolve um pedaço justo de escrita, e eu odeio copiar e colar. Então, tirei um caso de uso de Value Deal separado para esta situação e referi-lo a partir dos casos de uso originais. Você usa generalização de casos de uso quando você possui um caso de uso que é semelhante a outro caso de uso, mas faz um pouco mais. Com efeito, isso nos dá outra maneira de capturar cenários alternativos. No nosso exemplo, o caso básico de uso é Capture Deal. Este é o caso em que tudo funciona sem problemas. As coisas podem prejudicar a captura suave de um acordo, no entanto. Um é quando um limite é excedido por exemplo, o valor máximo que a organização comercial estabeleceu para um determinado cliente. Aqui não realizamos o comportamento usual associado ao caso de uso dado, realizamos uma alternativa. Poderíamos colocar essa variação dentro do caso de uso do Capture Deal como alternativa, como no caso de uso do Buy a Product que eu descrevii anteriormente. No entanto, podemos achar que esta alternativa é suficientemente diferente para merecer um caso de uso separado. Nós colocamos o caminho alternativo em um caso de uso especializado que se refere ao caso de uso básico. O caso de uso especializado pode substituir qualquer parte do caso de uso básico, embora ainda seja sobre como satisfazer o mesmo objetivo essencial do usuário. Um terceiro relacionamento, que não mostrei na Figura 3-2, é chamado de extensão. Essencialmente, isso é semelhante à generalização, mas com mais regras. Com esta construção, o caso de uso extensivo pode adicionar comportamento ao caso de uso básico, mas desta vez o caso de uso básico deve declarar certos pontos de extensão e o caso de uso extensivo pode adicionar comportamento adicional somente nesses pontos de extensão. (Figura 3-3.) Figura 3-3. Estender o relacionamento Um caso de uso pode ter muitos pontos de extensão e um caso de uso prolongado pode estender um ou mais desses pontos de extensão. Você indica quais na linha entre os casos de uso no diagrama. A generalização e a extensão permitem que você divida um caso de uso. Durante a elaboração, costumo dividir qualquer caso de uso que seja muito complicado. Eu dividi durante o estágio de construção do projeto se eu achar que eu não posso construir todo o caso de uso em uma iteração. Quando eu dividir, gosto de fazer o caso normal primeiro e as variações mais tarde. Aplica as seguintes regras. Use incluir quando você está se repetindo em dois ou mais casos de uso separados e você deseja evitar a repetição. Use a generalização quando descreve uma variação no comportamento normal e deseja descrevê-la de forma casual. Use estender quando você está descrevendo uma variação no comportamento normal e você deseja usar o formulário mais controlado, declarando seus pontos de extensão em seu caso de uso base. UML Exemplos de Diagrama de Caso de Uso Exemplos de diagramas de casos de uso comercial Registro de aeroporto e negócios de triagem de segurança Modelo Propósito. Um exemplo de um diagrama de caso de uso comercial para o check-in do aeroporto e triagem de segurança. Resumo. Os casos de uso comercial são Check-in individual, check-in de grupo (para grupos de turistas), Detecção de segurança, etc. - representando funções ou processos de negócios que ocorrem em um aeroporto e que atendem às necessidades dos passageiros. Modelo comercial do restaurante Propósito. Dois exemplos alternativos de diagrama de caso de uso comercial para um restaurante - visão de negócios externa e interna de um restaurante. Resumo. Vários atores empresariais que têm algumas necessidades e objetivos relacionados aos casos de uso de restaurantes e negócios que expressam expectativas dos atores do negócio. Exemplos de diagramas de casos de uso do sistema Máquina de venda automática de bilhetes Finalidade. Mostre que a máquina de venda automática de bilhetes permite que os viajantes viajem para comprar bilhetes. Resumo. O objetivo final de um Viajante em relação à nossa máquina de venda de bilhetes é comprar um ingresso. Temos um único caso de compra do Ticket de Compra, já que esta máquina de venda automática não oferece outros serviços. A máquina de venda automática de bilhetes é um assunto do exemplo de diagrama de caso de uso. O viajante e o banco são nossos atores. Ambos participando do caso de uso do Ticket de Compra. Exemplo de diagramas de casos de uso de ATM ATM ATM Propósito. Descreva os casos de uso que um caixeiro automático (ATM) ou a bancária automática (ABM) fornece aos clientes do banco. Resumo. O Cliente usa um caixa eletrônico do banco para verificar os saldos de suas contas bancárias, depositar fundos, retirar dinheiro e / ou transferir fundos (casos de uso). O técnico de ATM fornece manutenção e reparos ao caixa eletrônico. Terminal de ponto de venda (POS) Finalidade. Um exemplo de casos de uso para um Terminal de Ponto de Venda (POS) ou Checkout em um supermercado. Resumo. O caso de uso do Check-out envolve atores do Cliente, do Contratado e do Serviço de Pagamento de Crédito e inclui itens de varredura, cálculo total e impostos, e casos de uso de pagamento. Este é um exemplo de um caso de uso grande e complexo dividido em vários casos de uso menores. Catálogo de acesso público on-line e-Library (OPAC) Objetivo. Liste os casos de uso de nível superior para o catálogo de acesso público on-line da e-Library. Resumo. Os clientes de uma biblioteca podem pesquisar catálogo de bibliotecas on-line para localizar vários recursos - livros, periódicos, materiais de áudio e visual, ou outros itens sob controle da biblioteca. Os clientes podem reservar ou renovar item, fornecer feedback e gerenciar sua conta. Diagramas de casos de uso de compras on-line Objetivo. Forneça casos de uso de nível superior para um cliente da web fazendo compras on-line. Resumo. O ator do cliente da Web usa algum site para fazer compras on-line. Casos de uso de nível superior são itens de visualização. Faça Compra e Registro de Cliente. Sistema de processamento de cartão de crédito Finalidade. Defina os principais casos de uso para um sistema de processamento de cartão de crédito (gateway de pagamento de cartão de crédito). Resumo. O comerciante envia um pedido de transação de cartão de crédito para o gateway de pagamento de cartão de crédito em nome de um cliente. O banco que emitiu o cartão de crédito dos clientes é ator que pode aprovar ou rejeitar a transação. Se a transação for aprovada, os fundos serão transferidos para a conta bancária dos comerciantes. Administração do site Objetivo. Gerenciamento de sites ou administração de exemplo de diagramas de casos de uso UML. Resumo. O ator do administrador do site pode gerenciar grupos de usuários, usuários, sessões de usuários e logs. A equipe da mesa de ajuda usa um subconjunto de funções disponíveis para o administrador do site. Gerenciamento hospitalar Objetivo: descrever os principais serviços (funcionalidade) fornecidos pela recepção dos hospitais. Resumo. Este exemplo de diagrama de casos de uso UML mostra casos de ator e uso para uma recepção hospitalar. Subsistema ou módulo de recepção hospitalar suporta alguns dos muitos deveres de trabalho de um recepcionista hospitalar. O recepcionista agende a consulta dos pacientes e a admissão no hospital, coleta informações do paciente por telefone e a chegada dos pacientes ao hospital. Para o paciente que permanecerá no hospital (paciente internado), ele ou ela deve ter uma cama alocada em uma enfermaria. Os recepcionistas também podem receber pagamentos de pacientes, gravá-los em um banco de dados e fornecer recibos, reivindicações de seguro de arquivo e relatórios médicos. Relatório de diagnóstico de radiologia Exemplo de diagrama de caso de uso de UML Propósito: Relatórios de diagnóstico de radiologia Exemplo de diagrama de caso de uso de UML para o Perfil de Integração de Radiologia IHE (Simple Image e Numeric Report). Resumo. Na fase inicial do relatório de diagnóstico, um médico de leitura registra um diagnóstico gerando um projeto de objeto estruturado DICOM Structured Report (SR). O ator Report Creator transmite esse objeto DICOM SR para o Report Manager. Repositório de relatório externo O ator de acesso é um gateway para obter outros relatórios de departamento corporativo, como Laboratório e Patologia, dentro do departamento de Imagem. Proteção e licenciamento de software Objetivo: o exemplo do exemplo de exemplo de exemplo mostra uma visão simplificada dos casos de uso de licenciamento de software suportados pelo aplicativo Sentinel EMS. Resumo. O Kit de Desenvolvimento de Licença do Sentinel (Sentinel LDK) é uma solução de Gerenciamento de Direitos Digitais (DRM) pela SafeNet Inc. que oferece proteção de cópia forte, proteção para Propriedade Intelectual (IP) e licenciamento seguro e flexível. O aplicativo Sentinel EMS lida com três grandes fluxos de trabalho - planejamento de licenças, processamento e produção de pedidos e ativação de software de teste. Observe um erro de ortografia Selecione o texto usando o mouse e pressione Ctrl Enter. Este documento descreve UML 2.5 e é baseado na especificação OMGtrade Unified Modeling Languagetrade (OMG UMLreg) 2.5 especificação UML 2.5 FTF - Beta 1. Todos os diagramas UML foram criados no Microsoft Visio 2007 ou 2018 utilizando os modelos UML 2.2. Você pode enviar seus comentários e sugestões para o webmaster em webmasteruml-diagrams. org. Copyright copie 2009-2017 uml-diagrams. org. Todos os direitos reservados. Por favor, ative o JavaScript para visualizar os comentários alimentados por Disqus.
No comments:
Post a Comment