Modelagem de Casos de Uso

Um diagrama de caso de uso  UML   é a principal forma de requisitos de sistema/software para um novo programa de software em desenvolvimento. Os casos de uso especificam o comportamento esperado (o que) de um sistema, e não o método exato de fazer isso acontecer (como). Um conjunto completo de casos de uso especifica todas as diferentes maneiras de usar o sistema e, portanto, define todo o comportamento exigido do sistema, limitando o escopo do sistema.

Um conceito chave da modelagem de caso de uso é que ela nos ajuda a projetar um sistema da perspectiva do usuário final. É uma técnica eficaz para comunicar o comportamento do sistema nos termos do usuário, especificando todo o comportamento do sistema visível externamente.

Resumo do Diagrama de Caso de Uso

Uma forma padrão de diagrama de caso de uso é definida na Unified Modeling Language, conforme mostrado no exemplo de diagrama de caso de uso abaixo:

O que é um Caso de Uso?

  • Um caso de uso é uma coleção de possíveis sequências de interações entre o sistema em discussão e seus atores externos relacionados a um objetivo específico.
  • Cada caso de uso é um curso completo de eventos no sistema da perspectiva do usuário.
  • Casos de uso, uma vez especificados, podem ser denotados por representação textual e visual (ou seja, diagrama de caso de uso).
  • Os casos de uso são o método preferido pela comunidade de componentes e objetos para especificar requisitos e, de fato, conduzir todo o processo de desenvolvimento de software.
  • Os casos de uso geralmente se limitam a tarefas bastante importantes; eles não precisam ser escritos para cada ação que o usuário pode realizar.

Benefícios da abordagem de caso de uso

Os casos de uso fornecem muitos benefícios além de definir os requisitos do usuário. Os casos de uso podem ser usados ​​para:

  • Ajuda de caso de uso para capturar os requisitos funcionais de um sistema.
  • Os casos de uso são rastreáveis.
  • Os casos de uso podem servir como base para o esforço de estimativa, programação e validação.
  • O caso de uso pode evoluir em cada iteração de um método de captura de requisitos para diretrizes de desenvolvimento para programadores, para um caso de teste e, finalmente, para a documentação do usuário.
  • Os caminhos alternativos de caso de uso capturam comportamento adicional que pode melhorar a robustez do sistema.
  • Os casos de uso provaram ser facilmente compreensíveis pelos usuários de negócios e, portanto, provaram ser uma excelente ponte entre desenvolvedores de software e usuários finais.
  • Identificar classes de domínio de negócios e seus associados

Ator

  • Alguém interage com o caso de uso (função do sistema).
  • Nomeado por substantivo.
  • Ator desempenha um papel no negócio
  • Semelhante ao conceito de usuário, mas um usuário pode desempenhar papéis diferentes
  • Por exemplo:
  • Um prof. pode ser instrutor e também pesquisador
  • desempenha 2 papéis com dois sistemas
  • O ator aciona o(s) caso(s) de uso.
  • O ator tem responsabilidade em relação ao sistema (entradas) e o ator tem expectativas em relação ao sistema (saídas).

Caso de uso

  • Função do sistema (processo — automatizado ou manual)
  • Nomeado por verbo + Substantivo (ou Frase Substantiva).
  • ou seja, fazer algo
  • Cada Ator deve estar vinculado a um caso de uso, enquanto alguns casos de uso podem não estar vinculados a atores.

Link de comunicação

  • A participação de um ator em um caso de uso é mostrada conectando um ator a um caso de uso por um link sólido.
  • Os atores podem ser conectados aos casos de uso por associações, indicando que o ator e o caso de uso se comunicam por meio de mensagens.

Limite do sistema

  • O limite do sistema é potencialmente todo o sistema conforme definido no documento de requisitos.
  • Para sistemas grandes e complexos, cada módulo pode ser o limite do sistema.
  • Por exemplo, para um sistema ERP para uma organização, cada um dos módulos, como pessoal, folha de pagamento, contabilidade, etc.
  • pode formar um limite do sistema para casos de uso específicos para cada uma dessas funções de negócios.
  • Todo o sistema pode abranger todos esses módulos representando o limite geral do sistema

Análise de Caso de Uso em 6 Etapas

Ao desenvolver casos de uso, você deve começar com uma partição funcional — uma lista das principais categorias funcionais do sistema de destino. Isso ajudará a identificar quais áreas precisam ser focadas.

Etapa 1 — identificar os Atores: Identifique quem usará o sistema diretamente. Esses são os atores.

  • Um dos principais componentes do desenvolvimento de casos de uso são os atores.
  • Um ator é um papel específico desempenhado por um usuário do sistema e representa uma categoria de usuários que demonstra comportamentos semelhantes ao usar o sistema.
  • Os atores podem ser pessoas ou sistemas de computador.
  • Um ator primário é aquele que tem um objetivo que requer a assistência do sistema.
  • Um ator secundário é aquele do qual o sistema precisa de assistência para satisfazer seu objetivo.
  • Um dos atores é designado como o sistema em discussão.
  • Uma pessoa pode desempenhar vários papéis e, assim, representar vários atores, como operador de sistema de computador ou usuário final.

Passo 2: Escolha um desses atores.

  • Para identificar o caso de uso de um sistema de destino, identificamos os atores do sistema.
  • Um bom ponto de partida é verificar o design do sistema e identificar quem ele deve ajudar.

Passo 3 — Identificar Casos de Uso: Defina o que aquele Ator quer fazer com o sistema. Cada uma dessas coisas que o ator quer fazer com o sistema se torna um Caso de Uso.

  • As coisas que os atores querem fazer com o sistema tornam-se metas.
  • O objetivo é o resultado final das ações do usuário. Existem dois tipos de objetivos. O primeiro tipo é uma meta rígida.
  • Este objetivo deve ser completamente satisfeito e descreve o requisito mínimo de um sistema de destino.
  • Para identificar casos de uso, podemos ler a especificação de requisitos da perspectiva de um ator e realizar discussões com os usuários que atuarão como atores.
  • Ao definir tudo o que cada ator poderá fazer na interação com o sistema, define-se a funcionalidade completa do sistema.

Etapa 4 — Identifique o Cenário de Caso de Uso Normal: Para cada um desses Casos de Uso, decida o curso mais usual quando esse Ator estiver usando o sistema. O que normalmente acontece.

  • Um caso de uso tem um curso básico e vários cursos alternativos.
  • O curso básico é o curso mais simples, aquele em que um pedido é entregue sem nenhuma dificuldade.
  • Pode haver cursos alternativos que descrevam variantes do curso básico e os erros que podem ocorrer.
  • Estes são documentados como extensões para o caso de uso.

Etapa 5 — Desenvolver a descrição do caso de uso: Descreva esse curso básico na descrição do caso de uso.

  • O cenário de uso é escrito a partir da perspectiva do usuário em uma linguagem de fácil compreensão.
  • As etapas necessárias para atingir o objetivo identificado são escritas, conhecidas como fluxo de eventos.

Etapa 6 — Desenvolva caminhos alternativos de caso de uso: Quando estiver satisfeito com o curso básico, considere as alternativas e adicione-as como casos de uso estendidos.

Cenários alternativos de um caso de uso

Um caso de uso também descreve como o sistema deve responder quando as coisas  não  dão certo ou  dão  certo, mas  não  da maneira que descrevemos no cenário de sucesso principal. Chamamos essas situações  de extensões .

  • Existem duas variedades:  exceções  e  alternativas .
  • As exceções são condições de falha (algo deu errado).
  • Os suplentes são simplesmente uma maneira diferente de as coisas darem certo.

Níveis de detalhes dos casos de uso

A granularidade do caso de uso refere-se à maneira como as informações são organizadas dentro das especificações do caso de uso e, até certo ponto, ao nível de detalhe no qual elas são escritas. Alcançar o nível certo de granularidade de caso de uso facilita a comunicação entre as partes interessadas e os desenvolvedores e melhora o planejamento do projeto.

Alastair Cockburn em  Writing Effective Use Cases  nos dá uma maneira fácil de visualizar diferentes níveis de nível de meta pensando em termos de mar:

Observe que:

  • Embora um caso de uso em si possa se aprofundar em muitos detalhes sobre todas as possibilidades, um diagrama de casos de uso geralmente é usado para uma visão de nível superior do sistema como blueprints.
  • É benéfico escrever casos de uso em um nível mais grosseiro de granularidade com menos detalhes quando não for necessário.

Espero que você possa responder “o que é diagrama de caso de uso” agora e possa aplicar o caso de uso em seu projeto. Se você quiser saber mais sobre outros tipos de diagramas UML, consulte o guia UML:  Visão geral dos 14 tipos de diagramas UML .

Referências

Leave a Reply

O seu endereço de email não será publicado.