Olá, estudante, seja muito bem-vindo(a) a mais uma lição. Aqui, aprofundaremos os nossos conhecimentos na criação do Diagrama de Caso de Uso da UML. O objetivo dele é modelar o comportamento externo do sistema em termos de funcionalidades oferecidas. Dentre todos os diagramas da UML, o Diagrama de Caso de Uso é o mais abstrato, mais flexível e informal. Geralmente, é utilizado no início da modelagem, principalmente nas etapas de levantamento e análise de requisitos.

O Diagrama de Caso de Uso pode passar por alterações ao longo de todo o desenvolvimento do sistema, mas é o primeiro a ser desenvolvido por você, como técnico(a). Um bom projeto de sistema possui um Diagrama de Caso de Uso e ele deve apresentar uma visão externa e geral das funcionalidades do sistema, sem se preocupar como elas serão implementadas (GUEDES, 2011).

Assim, nesta lição, conheceremos a fundo quais elementos gráficos compõem um Diagrama de Caso de Uso, em que situação usamos um ou outro desses elementos e como podemos ler/compreender este tipo de diagrama, se ele for desenvolvido por outro colega técnico em desenvolvimento de sistemas. 

Tenho certeza que esta lição despertará em você bastante interesse pela modelagem de sistemas computacionais, assim como te fornecerá conhecimentos suficientes para desenvolver os seus próprios diagramas. Vamos lá!

Ao longo dos nossos estudos, percebemos que o desenvolvimento de sistemas tende a seguir uma ordem. Primeiro, elicitamos/levantamos os requisitos, compreendemos o que o sistema deve fazer com a ajuda dos stakeholders e, depois, passamos à fase de modelagem do sistema (construir a “planta” dele, como se fosse uma casa). 

Para que possamos modelar sistemas computacionais, utilizamos uma linguagem, especificamente, criada para isso, a Linguagem de Modelagem Unificada (UML). Como vimos, a UML possui um grande número de diagramas, mas dois deles são especiais e devem ser desenvolvidos pelo técnico em desenvolvimento de sistemas: o Diagrama de Caso de Uso e o Diagrama de Classe. Nesta lição, focaremos, apenas, no primeiro, porque ele deve preceder o segundo, o qual será o foco da nossa próxima lição.

Imagine que você é um(a) construtor(a) e está construindo uma casa, mas não sabe, exatamente, quantos andares ela terá, quantas janelas ou quantos cômodos. A pessoa que está pagando você para a construir não te informou esses dados ou informou de forma superficial. O que poderia fazer para confirmar se essa moradia é, exatamente, da forma que você imagina ser, antes de a construir? Nesse exemplo, a melhor opção seria fazer uma planta da casa, não é mesmo? Você, com essa planta em mãos, poderia perguntar ao contratante se a casa ficou semelhante ao que ele quer ou se é necessária alguma mudança.

Você acha que o desenvolvimento de um Diagrama de Caso de Uso é semelhante à ideia anterior? Por quê? Pense nisso levando em consideração que, por meio desse diagrama, é possível definir “o que” o sistema fará e “quem” interagirá com ele. Essas informações são fundamentais para saber por onde começar o desenvolvimento do seu sistema. Você poderá perguntar ao stakeholder: o sistema terá essa funcionalidade? Ela depende dessa outra? Quem usa essa funcionalidade e quem usa aquela? Todas essas perguntas poderão ser direcionadas ao stakeholder, por meio do seu Diagrama de Caso de Uso.

Não desenvolver o Diagrama de Caso de Uso implicar, muitas vezes, a construção de um sistema sem ter certeza do que, exatamente, ele fará. Nesses casos, o sistema pode ser desenvolvido/programado e, após o início do seu uso, serão percebidas funcionalidades que não foram implementadas. Este é um problema sério porque implica grandes retrabalhos, assim, mesmo que o sistema o qual você esteja desenvolvendo seja pequeno, não deixe de fazer o Diagrama de Caso de Uso e validá-lo com o stakeholder.

Imagine que você é o(a) técnico(a) em desenvolvimento de sistemas de uma instituição de Ensino Superior e, após levantar os requisitos com os stakeholders, os seguintes requisitos funcionais foram identificados: 

[R1] Gerir usuários: cada pessoa deverá ter um usuário e senha únicos para acessar o sistema. As funcionalidades que cada usuário consegue ver devem estar de acordo com o seu perfil (ex.: coordenador de curso, professor, aluno, funcionário administrativo do setor de cobrança, funcionário administrativo do setor de atendimento ao aluno etc.)

[R2] Gerir cursos: o sistema deve permitir que usuários autorizados manipulem o cadastro de cursos, disciplinas, salas e professores.

[R3] Gerir quadro de horários: o sistema deve permitir que seja criado um quadro de horários de acordo com a disponibilidade dos professores e das disciplinas que eles ministram.

Você também identificou que o requisito funcional “Gerir quadro de horários” só pode ser utilizado por coordenadores dos cursos, o requisito funcional “Gerir usuários” pode ser usado por diferentes perfis de usuários, enquanto o requisito funcional “Gerir cursos” tem a autorização de ser usado/acessado só pelos funcionários do setor de Registro Acadêmico. 

Os stakeholders também te informaram que, opcionalmente, ao usar a funcionalidade “Gerir usuários”, o usuário poderá utilizar “Recuperar senha”. A funcionalidade “Gerir quadro de horários” sempre deverá ter um registro de log associado às manipulações dos horários, ou seja, sempre que alguém alterar, inserir, atualizar ou consultar algo nos horários, deverá ser registrado quem fez a manipulação dos dados de horário e em qual momento.

Toda essa descrição é bastante comum quando queremos desenvolver um Diagrama de Caso de Uso. Precisamos saber quais funcionalidades existem, quem utiliza qual funcionalidade e se as funcionalidades principais possuem funcionalidades secundárias associadas.

Para que tenhamos condições de modelar um Diagrama de Caso de Uso de acordo com os dados anteriores, precisamos conhecer a fundo os elementos que compõem esse tipo de diagrama e como os utilizar. Vamos lá!

Com o intuito de criar diagramas de caso de uso que seguem a nomenclatura gráfica proposta nas versões mais atuais da UML, é necessário usar um software de mercado, amplamente, utilizado por organizações de todo o mundo. 

Em nossos estudos, empregaremos o software Visual Paradigm na sua versão online e gratuita. Para acessar o software e criar os seus diagramas de caso de uso, acesse o seguinte endereço eletrônico:

https://online.visual-paradigm.com/app/diagrams/#diagram:proj=0&type=UseCaseDiagram&width=11&height=8.5&unit=inch

Vamos revisar alguns conceitos básicos, antes de criarmos um diagrama de caso de uso completo? O primeiro ponto a relembrar é que ele possui dois itens básicos: atores e casos de uso. Os atores são representados, na UML, por meio de bonecos, com uma breve descrição, logo abaixo deles, que os identificarão, conforme Figura 1.

O ator de um Diagrama de Caso de Uso pode ser um funcionário do setor de vendas, ou um operador de caixa ou um gerente-geral da empresa. Veremos, mais à frente, que, para evitarmos a inserção de muitos atores no Diagrama de Caso de Uso, devido aos diferentes perfis possíveis num determinado software, podemos utilizar o recurso de generalização/especialização.

Lembre-se que um ator é quem utiliza, diretamente, o sistema (GUEDES, 2011). Um ator também costuma ser um hardware ou outro software que envia ou recebe dados do sistema que está sendo modelado. Um leitor de código de barras ou um leitor de biometria pode ser um ator num determinado sistema e, de forma semelhante, outro sistema que envia ou recebe dados do seu sistema também é um ator. 

Hoje em dia, é muito comum os sistemas de empresas diferentes se comunicarem. Um sistema de pagamento, por exemplo, se comunica com o sistema dos operadores de cartão de crédito. Se esses elementos forem importantes ao sistema o qual você está projetando, eles devem aparecer no Diagrama de Caso de Uso como um ator.

A seguir, apresento algumas dicas para você identificar um ator no seu projeto:

• Quem usará as funcionalidades centrais do sistema que você está projetando?  

• Existe funcionalidade para administrar e manter o sistema? Quem executará tais atividades? 

• Algum dispositivo de hardware inicializa alguma funcionalidade ou interage, de alguma forma, com o sistema? 

• O sistema interagirá com outros sistemas? 

Outro elemento central em um Diagrama de Caso de Uso é o próprio caso de uso. Na Figura 2, é apresentada a representação gráfica dele na UML.

Os casos de uso são utilizados para representar os requisitos funcionais do sistema, ou seja, devem representar serviços, tarefas ou funcionalidades que o sistema precisa realizar (RUMBAUGH; JACOBSON; BOOCH, 1999). Eles podem ser primários ou secundários. 

Os casos de uso primários são aqueles que representam funcionalidades principais do sistema (GUEDES, 2011). Por exemplo, se estamos projetando um sistema de venda de açaí na praia, as funcionalidades principais desse sistema seriam “Realizar venda” e “Receber pagamento”, entre outros. Os casos de uso secundários são auxiliares ou complementam os primários. No nosso exemplo, um caso de uso secundário poderia ser “Realizar cadastro do cliente”, apesar de não ser uma funcionalidade central, ela existe no sistema. 

De qualquer forma, atente-se, sempre, aos casos de uso principais (requisitos funcionais principais). Também se lembre que o nome dos casos de uso devem seguir aquela regra que discutimos em lições anteriores: iniciar por um verbo no infinitivo e ser seguido de um substantivo (caso não se lembre dessa regra, consulte a nossa lição sobre Especificação de Requisitos de Software na Prática). Em algumas situações, podemos associar um caso de uso a um formulário do sistema, porém essa não é uma regra, uma vez que, em um único formulário, é possível ter diversos casos de uso (exemplo: um formulário de cadastrar vendas apresentar casos de uso secundários, isto é, validar CPF do cliente, verificar endereço ou consultar endereço, consultar CPF nos órgãos de proteção de crédito, entre outros).

Tipos de interações, comunicações e associações em Diagramas de Caso de Uso

Um Diagrama de Caso de Uso, muitas vezes, tem vários casos de uso e vários atores (RUMBAUGH; JACOBSON; BOOCH, 1999). Para compreendermos o que o sistema faz e quem usa qual funcionalidade, precisamos utilizar os recursos de interação, comunicação e associação do Diagrama de Caso de Uso. 

Destacaremos três elementos que compõem as interações, comunicações e associações nesse diagrama, sendo eles:

• Inclusão (include): a interação do tipo include modela que um determinado caso de uso executará, obrigatoriamente, o caso de uso que é “incluído”. O include refere-se a uma relação de dependência, na qual sempre que um caso de uso for executado, o outro também será. 

Observe, a seguir, a Figura 3.

A Figura 3 apresenta o caso de uso “Realizar Venda” e inclui (include) o caso de uso “Consultar CPF”, mas o que isso quer dizer? A modelagem significa o seguinte: sempre que o usuário utilizar o caso de uso “Realizar Venda”, o caso de uso “Consultar CPF” será executado também. Essa é uma forma de modelarmos relações de dependência obrigatória entre funcionalidades (casos de uso) de um sistema. 

• Extensão (extend): a interação/comunicação entre casos de uso por meio do extend (extensão) sugere uma exceção, algo que pode acontecer ou não, ou seja, trata-se de comunicação opcional no sistema. 

Observe, a seguir, a Figura 4.

A Figura 4, ao contrário da Figura 3 (uso do include), modela que a execução do caso de uso “Consultar CPF” é opcional quando o caso de uso “Realizar Venda” for executado.

• Generalização: a interação do tipo generalização, também chamada de generalização/especialização, significa que um ator se difere do outro em poucos elementos, isto é, um ator possui uma herança em termos de características e herda do outro ator algumas características que são semelhantes em ambos. 

Observe, a seguir, a Figura 5.

A Figura 5 modela a generalização/especialização de funcionário para gerente, mas o que isso quer dizer? Isso significa que a generalização é o ator funcionário (mais geral) e o ator gerente é a especialização. Ou seja, um gerente possui as mesmas características de um funcionário porque, antes de ser um gerente, ele é, também, um funcionário, mas por ser um gerente, tem particularidades que o diferem de um funcionário “normal”.

Analisaremos, agora, um Diagrama de Caso de Uso completo que aplica todas essas nomenclaturas gráficas (Figura 6).

A Figura 6 modela o Diagrama de Caso de Uso de um sistema de vendas que possui quatro casos de uso e dois atores. O diagrama informa que o ator “Funcionário” só tem acesso à funcionalidade “Realizar Venda”, enquanto o ator “Gerente” tem acesso à funcionalidade “Gerar Relatórios de Vendas”. Por herança e considerando o conceito de generalização/especialização, o ator “Gerente” também tem acesso ao caso de uso “Realizar Venda” que possui um include para o caso de uso “Consultar CPF”. Isso significa que a consulta do CPF de um cliente sempre será realizada durante a realização de uma venda. O extend entre o caso de uso “Realizar Venda” e “Validar E-mail” informa que a validação do e-mail da pessoa que estiver comprando, poderá ser verificada, opcionalmente.

Nesta lição, aprofundamos os nossos conhecimentos na construção de um Diagrama de Caso de Uso. Compreendemos que ele é um dos elementos centrais num projeto de software e que, por meio dele, podemos modelar as principais funcionalidades do sistema (ex.: casos de uso), assim como as principais relações externas que o sistema terá (ex.: atores). 

Aluno(a), não deixe de criar o Diagrama de Caso de Uso do seu software antes de iniciar a codificação.

Você, como técnico(a) em desenvolvimento de sistemas, deve ser capaz de criar bons Diagramas de Caso de Uso, uma vez que ele é o primeiro diagrama da UML a ser criado durante o projeto de um sistema. O Diagrama de Caso de Uso possibilita que as funcionalidades do sistema proposto sejam documentadas bem como define quais relações externas (atores) o sistema terá. Trata-se de um elemento fundamental na etapa de Projeto de Sistemas. 

Você deve dedicar um tempo na criação do seu Diagrama de Caso de Uso, pois erros nesse diagrama costumam acarretar outros erros no projeto e no próprio sistema a ser desenvolvido, ou seja, ocorre uma reação em cascata. Lembre-se que um Diagrama de Caso de Uso deve ser de fácil entendimento e conter, apenas, as principais funcionalidades do sistema, não tente apresentar, no diagrama, todas as funcionalidades, validações e pequenas implementações, pois esses itens estarão modelados em outros diagramas da UML. Você pode documentar os casos de uso do seu sistema em um documento à parte (ex.: documento-texto), mas, graficamente, apresente só aqueles requisitos funcionais que são chave no sistema. 

De posse do seu Diagrama de Caso de Uso, muitas aplicações práticas poderão ser realizadas. Você terá a oportunidade de o utilizar para validar requisitos com os stakeholders ou anexá-lo na sua Especificação de Requisitos de Software (ERS.) Em algumas metodologias para medir o software, o Diagrama de Caso de Uso é usado para obter uma métrica do tamanho do software e o seu possível custo. 

Enfim, o Diagrama de Caso de Uso é um elemento central na Análise e Projeto de Sistemas. Não deixe de aprofundar os seus conhecimentos acerca desse diagrama porque ele fará parte do seu cotidiano como técnico(a) em desenvolvimento de sistemas.