Use diagramas de casos.
Use diagramas de casos.
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 agora 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 os casos de uso envolviam manter cada um em um cartão de índice e classificar os cartões em pilhas para mostrar o que precisava ser construído em cada iteração.
A Figura 3-2 mostra alguns dos casos de uso de um sistema de negociação financeira.
Figura 3-2. Diagrama de casos de uso.
Um ator é um papel que um usuário desempenha em relação ao sistema. Há quatro atores na Figura 3-2: Gerente de Negociação, Negociador, Vendedor e Sistema Contábil. (Sim, eu sei que seria melhor usar a palavra "papel", mas aparentemente havia uma tradução do sueco.)
Provavelmente haverá muitos comerciantes na organização dada, mas no que diz respeito ao sistema, todos desempenham o mesmo papel. Um usuário também pode desempenhar mais de uma função. Por exemplo, um operador sênior pode desempenhar o papel de Gerente de Negociação e também ser um operador regular; um comerciante também pode ser um vendedor. Ao lidar com atores, é importante pensar em papéis e não em pessoas ou cargos.
Atores executam casos de uso. Um único ator pode executar muitos casos de uso; Por outro lado, um caso de uso pode ter vários atores fazendo isso.
Na prática, acho que os atores são mais úteis quando tentam inventar os 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, em seguida, tentar descobrir os casos de uso de cada ator.
Os atores não precisam ser humanos, mesmo que os atores sejam representados como figuras 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 Contábil.
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 casos de uso; outros preferem mostrar o iniciador do caso de uso. Eu prefiro mostrar o ator que recebe valor do caso de uso, ao qual algumas pessoas se referem como o ator primário.
No entanto, eu não levo isso longe demais. Fico feliz em ver o sistema de contabilidade 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 isso, você deve sempre questionar casos de uso com agentes do sistema, descobrir quais são as metas reais do usuário e considerar formas alternativas de atingir essas metas.
Quando estou trabalhando com atores e casos de uso, não me preocupo muito com os relacionamentos exatos entre eles. Na maioria das vezes, o que eu realmente procuro são os casos de uso; os atores são apenas uma maneira de chegar lá. Contanto que eu tenha todos os casos de uso, não estou preocupado com os detalhes dos atores.
Existem algumas situações nas quais vale a pena rastrear os atores mais tarde.
O sistema pode precisar de configuração para vários tipos de usuários. Nesse caso, cada tipo de usuário é um ator e os casos de uso mostram o que cada ator precisa fazer.
Rastrear quem quer usar 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 dos casos de uso é Send Out Bill. Não é tão fácil identificar um ator associado, no entanto. Nenhum papel de usuário específico solicita uma fatura. A fatura é enviada ao cliente, mas o cliente não contestaria se isso não acontecesse. O melhor palpite para um ator aqui é o Departamento de Faturamento, pois ele 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 de cada ator. Se isso acontecer, não se preocupe muito. O importante é entender os casos de uso e as metas do usuário que eles satisfazem.
Uma boa fonte para identificar casos de uso é eventos externos. Pense em todos os eventos do mundo exterior aos quais você quer reagir. Um determinado evento pode causar uma reação do sistema que não envolva usuários ou pode causar uma reação principalmente dos usuários. Identificar os eventos para os quais 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 relacionamentos entre casos de uso.
O relacionamento de inclusão ocorre quando você tem um bloco de comportamento semelhante em mais de um caso de uso e não deseja continuar copiando a descrição desse comportamento. Por exemplo, tanto Análise de risco quanto Contrato de preço exigem que você valorize o negócio. Descrever a valoração do negócio envolve uma boa quantidade de textos, e eu odeio copiar e colar. Então eu cotei um caso de uso separado do Value Deal para essa situação e me referi a ele dos casos de uso originais.
Você usa a generalização de casos de uso quando tem um caso de uso semelhante a outro caso de uso, mas faz um pouco mais. Com efeito, isso nos dá outra maneira de capturar cenários alternativos.
Em nosso exemplo, o caso de uso básico é o Capture Deal. Este é o caso em que tudo corre bem. As coisas podem perturbar a boa captura de um acordo, no entanto. Uma é 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 ao caso de uso dado; nós realizamos uma alternativa.
Poderíamos colocar essa variação dentro do caso de uso do Capture Deal como uma alternativa, como no caso de uso Comprar um Produto que descrevi anteriormente. No entanto, podemos achar que essa 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 base, embora ainda deva 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 para isso.
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 determinados "pontos de extensão" e o caso de uso de extensão pode adicionar um comportamento adicional somente nesses pontos de extensão. (Veja a Figura 3-3.)
Figura 3-3. Estenda o 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 estão na linha entre os casos de uso no diagrama.
Tanto a generalização quanto a extensão permitem dividir um caso de uso. Durante a elaboração, costumo dividir qualquer caso de uso que esteja ficando complicado demais. Eu divido durante o estágio de construção do projeto se eu achar que não posso construir o caso de uso inteiro em uma iteração. Quando me separo, gosto de fazer primeiro o caso normal e as variações mais tarde.
Aplique as seguintes regras.
Use include quando estiver se repetindo em dois ou mais casos de uso separados e quiser evitar a repetição.
Use generalização quando estiver descrevendo uma variação no comportamento normal e desejar descrevê-lo casualmente.
Use extend quando estiver descrevendo uma variação no comportamento normal e desejar usar o formulário mais controlado, declarando seus pontos de extensão em seu caso de uso base.
Diagrama de casos de uso da UML - Sistema de processamento de tickets.
Diagrama de casos de uso da UML - Sistema de processamento de tickets.
(1) Um técnico de atendimento ao cliente recebe uma ligação telefônica, e-mail ou outra comunicação de um cliente sobre um problema. Alguns aplicativos fornecem sistema interno de mensagens e relatórios automáticos de erros de blocos de tratamento de exceções.
(2) O técnico verifica se o problema é real e não apenas percebido. O técnico também garantirá que informações suficientes sobre o problema sejam obtidas 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) Conforme o trabalho é feito nessa questão, o sistema é atualizado com novos dados pelo técnico. Qualquer tentativa de corrigir o problema deve ser anotada no sistema de problemas. O status do ticket provavelmente será alterado de aberto para pendente.
(5) Após o problema ter sido totalmente resolvido, 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 eficácia da equipe de TI está se tornando muito comum. "[Issue tracking system. Wikipedia]
O exemplo de diagrama de caso de uso UML "Sistema de processamento de tickets" foi criado usando o software de diagramação e desenho vetorial ConceptDraw PRO estendido com a solução Rapid UML da área de Desenvolvimento de Software do ConceptDraw Solution Park. Consulte Mais informação.
Diagrama de casos de uso da UML - Cenários de uso do sistema de negociação.
Uma classe especial de negociação algorítmica é a "negociação de alta frequência" (HFT), que geralmente é mais lucrativa durante os períodos de alta volatilidade do mercado. Durante os últimos anos, empresas como a Algorates empregaram estratégias de HFT, registrando altos lucros mesmo durante períodos em que os mercados registraram declínios acentuados. "[Algorithmic trading. Wikipedia]
O exemplo do diagrama de casos de uso da UML "Cenários de uso do sistema comercial" foi criado usando o software de diagramação e desenho vetorial ConceptDraw PRO estendido com a solução Rapid UML da área de Desenvolvimento de Software do ConceptDraw Solution Park. Consulte Mais informação.
Diagrama de Casos de Uso Jacobson.
Exemplo de diagrama de casos de uso da UML. Diagrama UML de serviços. Sistema ATM.
Diagrama de casos de uso de bancos ATM.
"Se você está projetando um caixa automático, por exemplo, o caso de uso para um aspecto particular da funcionalidade do sistema é capaz de descrever o que o auto-contador faz em todas as situações possíveis. Cada uma dessas" situações "é referida Como cenário, um caso de uso pode ser considerado uma coleção 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 o caixa automático faz se um cliente acabou de depositar um cheque nas últimas 24 horas, e não há o suficiente na conta sem que o cheque tenha sido liberado para fornecer uma retirada desejada? ”
Os diagramas de casos de uso são intencionalmente simples para evitar que você fique atolado nos detalhes de implementação do sistema prematuramente.
Cada palito representa um “ator”, que normalmente é um ser humano ou algum outro tipo de agente livre. (Estes podem até ser outros sistemas de computador, como é o caso de "ATM".) A caixa representa o limite do seu sistema. As elipses representam os casos de uso, que são descrições de trabalhos valiosos que podem ser executados 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, desde que seja assim para o usuário. "
Este exemplo de diagrama de caso de uso UML de caixa eletrônico (ATM) foi criado usando o software de diagramação e desenho vetorial ConceptDraw PRO estendido com a solução Diagrama UML ATM da área de Desenvolvimento de Software do ConceptDraw Solution Park. Consulte Mais informação.
Exemplos de Diagrama de Casos de Uso (UML) | Use modelos de diagrama de casos (UML).
Por Creately Templates.
Use o modelo de caso de um sistema ATM.
Tagged: caso de uso, diagrama de usecase, uml, uml caso de uso.
Atualizado: 6 meses atrás.
Por Creately Templates.
Use o modelo de diagrama de caso do sistema de pedidos de restaurante.
Tagged: caso de uso, caso de uso de restaurante, uso de ordem de restaurante, caso de uso do sistema de pedidos, modelos de casos de uso, modelo de uso, caso de uso de uml.
Atualizado: 6 meses atrás.
Por Creately Templates.
Use o modelo de caso de um sistema de agenciamento de viagens.
Tagged: caso de uso, diagrama de usecase, uml, uml caso de uso.
Atualizado: 6 meses atrás.
Por Indu Kandasamy.
Sistema de casos de uso de catálogos telefônicos.
Tagged: caso de uso, diagrama de usecase, uml, uml caso de uso.
Atualizado: 1 ano atrás.
Por Indu Kandasamy.
Este é um exemplo de um sistema de uso de folha de pagamento.
Tagged: caso de uso, diagrama de usecase, uml, uml caso de uso.
Atualizado: 2 anos atrás.
Por Indu Kandasamy.
Um exemplo de modelo de caso de uso.
Tagged: caso de uso, diagrama de usecase, uml, uml caso de uso.
Atualizado: 2 anos atrás.
Por Indu Kandasamy.
Use o modelo de caso para um sistema de hotel.
Tagged: caso de uso, diagrama de usecase, uml, uml caso de uso.
Atualizado: 2 anos atrás.
Por Indu Kandasamy.
Este é um exemplo de um sistema de casos de uso de locação de vídeo.
Tagged: caso de uso, diagrama de usecase, uml, uml caso de uso.
Atualizado: 2 anos atrás.
Por Indu Kandasamy.
Diagrama de casos de uso de um sistema de registro universitário.
Tagged: caso de uso, diagrama de usecase, uml, uml caso de uso.
Atualizado: 2 anos atrás.
Por Creately Templates.
Modelo de Exemplo de Diagrama de Casos de Uso do Sistema de RH Online.
Tagged: caso de uso hr sistema, caso de uso do sistema hr, sistema de hr online, caso de uso, diagrama de usecase, modelos de casos de uso.
Atualizado: 2 anos atrás.
Por Creately Templates.
Diagrama de caso de uso Modelo de rede celular Cenário fazendo e recebendo chamadas.
Tagged: usecase, caso, uml, tecnologia, software, caso de uso de rede móvel, caso de uso de rede celular, caso de uso de celular, caso de uso para celular, modelo de caso de uso, modelos de usecase, caso de uso, uml usecase.
Atualizado: 2 anos atrás.
Por Creately Templates.
Use o modelo de diagrama de caso do sistema de negociação financeira.
Tagged: caso de uso, caso de uso de negociação, usecase de negociação financeira, caso de uso de ordem financeira, modelo de caso de uso, modelos de uso.
Comments
Post a Comment