Diagramas de Casos de Uso Diagramas de Casos de Uso Além de introduzir casos de uso como elementos primários no desenvolvimento de software, Jacobson (1994) também introduziu um diagrama para visualizar casos de uso. O diagrama de casos de uso também faz parte agora da UML. Muitas pessoas acham este tipo de diagrama útil. No entanto, devo salientar que você não precisa desenhar um diagrama para usar casos de uso. Um dos projetos mais eficazes que eu conheço que usava 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 casos de uso de 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, Trader, Vendedor e Sistema de Contabilidade. (Sim, eu sei que seria melhor usar a palavra papel, mas, aparentemente, houve uma má tradução do sueco.) Provavelmente haverá muitos comerciantes na organização, 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 de um comerciante também pode ser um vendedor. Ao lidar com atores, é importante pensar sobre papéis em vez de pessoas ou títulos de cargos. Os atores realizam casos de uso. Um único ator pode executar muitos casos de uso inversamente, um caso de uso pode ter vários atores realizá-lo. Na prática, eu acho que os atores são mais úteis quando se tenta criar os casos de uso. Diante de um sistema grande, muitas vezes pode ser difícil chegar a uma lista de casos de uso. É mais fácil nessas situações chegar primeiro à lista de atores e, em seguida, tentar elaborar 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 casos de uso. Um ator também pode ser um sistema externo que necessita 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 cada sistema externo ou ator humano no diagrama de caso de uso 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 chamam de ator principal. No entanto, eu não tomar isso muito longe. Estou feliz em ver o sistema de contabilidade obter valor, sem tentar descobrir o ator humano que recebe valor do sistema de contabilidade que implicaria modelagem do sistema de contabilidade em si. Dito isto, você sempre deve questionar casos de uso com atores do sistema, descobrir quais são os objetivos reais do usuário e considerar maneiras alternativas de atingir esses objetivos. Quando estou trabalhando com atores e casos de uso, eu não me preocupo muito com o que os relacionamentos exatos estão entre eles. Na maioria das vezes, o que eu realmente estou procurando são os casos de uso que os atores são apenas uma maneira de chegar lá. Contanto que eu recebo todos os casos de uso, eu não estou preocupado com os detalhes dos atores. Existem algumas situações em que vale a pena acompanhar 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. Acompanhar quem quer casos de uso pode ajudá-lo a negociar prioridades entre vários atores. Alguns casos de uso não têm 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 específica solicita uma conta. A conta é enviada ao cliente, mas o wouldnt do cliente objeta se didnt acontecer. O melhor palpite em um ator aqui é o Departamento de Faturamento, na medida em que obtém valor do caso de uso. No entanto, o Faturamento normalmente não está envolvido no processo 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 de cada ator. Se isso acontecer, não se preocupe muito. 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ê quer 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 para reagir a 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 casos de uso. A relação 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 quer continuar copiando a descrição desse comportamento. Por exemplo, tanto Analisar Risco e Preço 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 eu spun off um caso de uso de Value Deal separado para esta situação e referi-lo a partir dos casos de uso originais. Você usa a generalização de caso de uso quando você tem um caso de uso que é semelhante a outro caso de uso, mas faz um pouco mais. Com efeito, isso nos dá uma outra maneira de capturar cenários alternativos. Em nosso exemplo, o caso de uso básico é Capture Deal. Este é o caso em que tudo vai bem. As coisas podem perturbar a captura suave de um negócio, no entanto. Um deles é quando um limite é excedido, por exemplo, o montante máximo que a organização comercial estabeleceu para um cliente em particular. Aqui nós não realizamos o comportamento usual associado com o caso de uso dado que realizamos uma alternativa. Poderíamos colocar essa variação no caso de uso do Capture Deal como uma alternativa, como no caso de uso do Buy a Product que descrevi anteriormente. No entanto, podemos sentir que esta alternativa é suficientemente diferente para merecer um caso de uso separado. Colocamos o caminho alternativo em um caso de uso especializado que se refere ao caso de uso base. O caso de uso especializado pode substituir qualquer parte do caso de uso de base, embora ainda deva ser sobre a satisfação da mesma meta essencial do usuário. Uma terceira relação, que eu não mostrei na Figura 3-2, é chamada de extensão. Essencialmente, isso é semelhante à generalização, mas com mais regras para ele. Com essa construção, o caso de uso de extensão pode adicionar comportamento ao caso de uso base, mas desta vez o caso de uso base deve declarar certos pontos de extensão eo caso de uso de extensão pode adicionar um comportamento adicional somente nesses pontos de extensão. (Veja Figura 3-3.) Figura 3-3. Estender relacionamento Um caso de uso pode ter muitos pontos de extensão e um caso de uso de extensão pode estender um ou mais desses pontos de extensão. Você indica quais na linha entre os casos de uso no diagrama. Tanto a generalização como a extensão permitem dividir um caso de uso. Durante a elaboração, eu costumo dividir qualquer caso de uso que está ficando muito complicado. Eu dividir durante a fase de construção do projeto se eu descobrir que eu não posso construir o caso de uso inteiro em uma iteração. Quando eu dividir, eu gosto de fazer o caso normal primeiro e as variações mais tarde. Aplique as regras a seguir. Use incluir quando você está se repetindo em dois ou mais casos de uso separados e você quer evitar a repetição. Use generalização quando você está descrevendo uma variação no comportamento normal e você deseja descrevê-lo casualmente. Use extend 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 de base. Exemplo de exemplo de caso de uso Exemplo Sites de redes sociais Projetos Diagramas UML Projeto de sites de redes sociais. Este exemplo foi criado no diagrama ConceptDraw PRO e software de desenho vetorial usando a biblioteca UML Use Case Diagram da Solução Rápida UML da área de Desenvolvimento de Software do ConceptDraw Solution Park. Este exemplo mostra o Facebook Socio-sistema de saúde e é usado na projeção e criação de sites de redes sociais. GET MY CONCEPTDRAW SOFTWARE Diagramas Circulares e Alvo Esta solução estende o software ConceptDraw PRO com amostras, modelos e biblioteca de elementos de design para desenhar o Diagrama Circular e Diagramas Circulares. Exemplo de Exemplo de Diagrama de Casos de Uso Sites de Rede Social Projetos Diagramas UML Projeto de Sites de Redes Sociais. Este exemplo foi criado no diagrama ConceptDraw PRO e software de desenho vetorial usando a biblioteca UML Use Case Diagram da Solução Rápida UML da área de Desenvolvimento de Software do ConceptDraw Solution Park. Este exemplo mostra o Facebook Socio-sistema de saúde e é usado na projeção e criação de sites de redes sociais. GET MY CONCEPTDRAW SOFTWARE Um cenário de exemplo é apresentado para demonstrar como um sistema de rastreamento de problemas comuns funcionaria: (1) Um técnico de atendimento ao cliente recebe uma chamada telefônica, e-mail ou outra comunicação de um cliente sobre um problema. Alguns aplicativos fornecem sistema de mensagens interno e relatórios de erros automáticos a partir de blocos de tratamento de exceção. (2) O técnico verifica que o problema é real, e não apenas percebido. O técnico também irá garantir que informações suficientes sobre o problema é obtido a partir do cliente. Essas informações geralmente incluem o ambiente do cliente, quando e como o problema ocorre e todas as outras circunstâncias relevantes. (3) O técnico cria o problema no sistema, inserindo todos os dados relevantes, conforme fornecidos pelo cliente. (4) Como o trabalho é feito sobre essa questão, o sistema é atualizado com novos dados pelo técnico. Qualquer tentativa de corrigir o problema deve ser observado no sistema de emissão. O status do ticket provavelmente será alterado de aberto para pendente. (5) Depois que o problema foi totalmente tratado, ele é marcado como resolvido no sistema de rastreamento de problemas. Se o problema não for totalmente resolvido, o ticket será reaberto assim que o técnico receber novas informações do cliente. Um processo de automação de livros de execução que implementa as práticas recomendadas para esses fluxos de trabalho e aumenta a efetividade do pessoal de TI está se tornando muito comum. Sistema de rastreamento de problemas. Wikipedia O exemplo de diagrama de casos de uso UML O sistema de processamento de tickets foi criado usando o diagrama ConceptDraw PRO e o software de desenho vetorial estendido com a solução Rapid UML da área de Desenvolvimento de Software do ConceptDraw Solution Park. Diagrama de casos de uso UML O padrão aberto aceito que é usado na engenharia de software e no design do sistema ao modelar sistemas orientados a objetos e processos de negócios é conhecido como UML (Unified Modeling Language). A UML foi criada para sistemas de software de definição, visualização, design e documentação. Não é uma linguagem de programação, mas na base do modelo UML pode ser gerado código. A UML usa um conjunto genérico de notações gráficas para criar um modelo abstrato do sistema chamado modelo UML. A notação UML permite representar visualmente requisitos, subsistemas, padrões estruturais e comportamentais, elementos lógicos e físicos, etc. A UML define 13 tipos de diagramas: Classe (Pacote), Caso de Uso, Seqüência, Objeto, Colaboração, Componente, Máquina de Estado, Estrutura Composta, Atividade e Implantação. Todos esses tipos de Diagramas UML podem ser criados com rapidez e facilidade com o poderoso software ConceptDraw PRO estendido com a solução especial Rapid UML da área de Desenvolvimento de Software do ConceptDraw Solution Park. Diagrama UML de Serviços. Sistema ATM. Este exemplo foi criado no diagrama ConceptDraw PRO e software de desenho vetorial usando a biblioteca UML Use Case Diagram da Solução Rápida UML da área de Desenvolvimento de Software do ConceptDraw Solution Park. Este exemplo mostra o esquema do serviço utilizando os ATMs (Automated Teller Machines) e é utilizado no funcionamento dos sistemas bancários ATM, na execução das operações bancárias. Este exemplo foi criado no diagrama ConceptDraw PRO e software de desenho vetorial usando a biblioteca UML Use Case Diagram da Solução Rápida UML da área de Desenvolvimento de Software do ConceptDraw Solution Park. Este exemplo mostra os tipos de interações de usuários com o sistema e é usado no registro e em trabalhar com o sistema de banco de dados. Este exemplo de banco ATM UML diagrama de atividade foi criado na base do diagrama de caso de uso UML de caixa eletrônico do curso Thinking in Java, 2a edição, Revisão 9 por Bruce Eckel publicado no site do Departamento de Ciência da Computação e Engenharia Elétrica de A Universidade de Maryland, Baltimore (UMBC). Se você está projetando um auto-teller, por exemplo, o caso de uso para um aspecto particular da funcionalidade do sistema é capaz de descrever o que o auto-teller faz em cada situação possível. Cada uma dessas situações é referida como um cenário e um caso de uso pode ser considerado um conjunto de cenários. Você pode pensar em um cenário como uma pergunta que começa com: O que o sistema faz se. Por exemplo, o que faz o auto-caixa se um cliente acaba de depositar um cheque dentro das últimas 24 horas e não há suficiente na conta sem o cheque ter desmarcada para fornecer uma retirada desejada Diagramas de caso de uso são intencionalmente simples para evitar que você De ficar atolado em detalhes de implementação do sistema prematuramente. Cada pessoa da vara representa um ator, que é tipicamente um ser humano ou algum outro tipo de agente livre. (Estes podem até ser outros sistemas de computador, como é o caso com ATM.) A caixa representa o limite do seu sistema. As elipses representam os casos de uso, que são descrições de trabalho valioso que pode ser realizado com o sistema. As linhas entre os atores e os casos de uso representam as interações. Não importa como o sistema é realmente implementado, enquanto ele se parece com isso para o usuário. Este exemplo de diagrama de casos de uso de UML de caixa automática (ATM) foi criado usando o diagrama ConceptDraw PRO e software de desenho vetorial estendido com a solução ATM UML Diagramas da área de Desenvolvimento de Software do ConceptDraw Solution Park. Bank ATM UML diagrama de seqüência A solução rápida UML da área de Desenvolvimento de Software do ConceptDraw Solution Park inclui 13 bibliotecas de stencils vetoriais para desenhar os diagramas UML 2.4 usando diagramação ConceptDraw PRO e software de desenho vetorial. Os diagramas de casos de uso são usados no desenvolvimento de software e sistemas para definição de requisitos de sistema funcional ou sistema de sistemas. O diagrama de caso de uso apresenta a consecução de ações de objetos (usuários ou sistemas) que são executadas para alcançar o resultado definido.
No comments:
Post a Comment