Olá, aluno(a), seja muito bem-vindo(a) à mais uma lição. Nesta, você aprenderá a construir o Diagrama de Máquina de Estado (DME), que pode ser considerado um complemento para o diagrama de atividade (RUMBAUGH; JACOBSON; BOOCH, 1999). Pode-se dizer que um não faz sentido sem o outro. Você utilizará o diagrama de máquina de estado para fornecer maiores detalhes aos desenvolvedores sobre quais elementos (métodos) existentes no diagrama de classe serão utilizados nas atividades já documentadas no diagrama de atividades. Mas não é só isso! Detalharemos as características do DME nas próximas páginas desta lição. 

Lembre-se que, como já comentei em lições anteriores, os diagramas da UML são complementares, ou seja, um complementa o outro, de forma que não seja feito um único diagrama com muitas informações e fique ilegível. Apesar da proximidade conceitual entre o diagrama de atividade e o diagrama de máquina de estado, há diferenças na representação gráfica e no objetivo final do diagrama, como veremos nesta lição. Vamos lá!

Os diagramas da UML são organizados de forma que o projetista do sistema possa detalhar, parte por parte, as funcionalidades existentes. Inicia-se por uma visão macro das funcionalidades (casos de uso) e dos usuários (atores) envolvidos no sistema (Diagrama de Caso de Uso), passando por um detalhamento da estrutura estática de armazenamento dos dados (classes) e dos eventos funcionais (métodos) — Diagrama de Classe —, e finalizando com as modelagens unívocas dos casos de uso, em que cada uma das funcionalidades são apresentadas sob diferentes óticas na forma como funcionam (por exemplo, diagrama de sequência e diagrama de atividade).  

O diagrama de máquina de estado se apresenta como um complemento aos diagramas de sequência e de atividade, utilizando elementos de ambos na sua modelagem. O nosso desafio nesta lição é compreender como as informações dos diagramas de sequência e atividade poderão auxiliar na construção do diagrama de máquina de estado. Ademais, você deverá ter os fundamentos do diagrama de classe bem definidos para que possa compreender a “ligação” entre os métodos existentes nas classes e as atividades apresentadas no diagrama de atividade que serão “replicadas” no diagrama de máquina de estado. 

Apesar de parecer confuso, na verdade, é bastante simples. Nós, apenas, complementaremos, com mais informações, os elementos já modelados no projeto do software.

Imagine que você é o(a) técnico(a) responsável pelo projeto de um software e entregou para o desenvolvedor o Diagrama de Caso de Uso, o Diagrama de Classe e os Diagramas de Sequência e de Atividade para cada caso de uso. O desenvolvedor analisa os diagramas com cuidado, antes de iniciar a codificação, e lhe faz a seguinte pergunta: qual método da classe A eu uso na atividade do caso de uso B? Esse tipo de informação somente será encontrado no diagrama de máquina de estado, porque é onde você deixará claro para o desenvolvedor quais são os “estados” pelos quais as atividades do caso de uso passarão. Quando menciono o termo “estado”, estou me referindo à modelagem do que é executado quando uma atividade é iniciada no sistema.

A modelagem do diagrama de máquina de estado se difere do diagrama de atividade porque, pelo diagrama de atividade, não podemos responder à pergunta anterior, pelo simples fato de o diagrama de atividade não mencionar nada sobre as classes ou métodos dessas classes. Nesse momento, você pode me perguntar: mas e o diagrama de sequência? Ele não apresenta a instância da classe e o nome do método nas interações entre o controlador e a instância?  A resposta é sim! Contudo não podemos identificar, com bastante clareza, qual método é executado em qual atividade. Isso somente poderá ser feito quando você criar o diagrama de máquina de estado.

Em muitos momentos, pode parecer para você que há uma repetição na modelagem do projeto, mas tenha em mente que o objetivo é minimizar, ao máximo, as possíveis dúvidas que o desenvolvedor venha a ter durante a codificação. Essa situação se assemelha à de um mestre de obras ou pedreiro que está construindo uma casa, ou seja, pelo fato de o projeto ser superficial e com poucos detalhes, a todo momento, ele precisa consultar o engenheiro para entender o que deve ser feito. As chances de que algo saia errado nesse tipo de cenário é enorme.

O Diagrama de Máquina de Estado (DME) visa demonstrar o comportamento de um caso de uso por meio dos possíveis estados que podem ocorrer (GUEDES, 2011). O objetivo do diagrama de máquina de estados é deixar explícito o que é executado em cada momento de determinado caso de uso do sistema, não deixando dúvidas para o desenvolvedor sobre qual a sequência de execução das funcionalidades (métodos) e por quais estados essas podem passar.

Assim como os demais diagramas da UML, o DME tem as suas representações gráficas específicas. Assim como o diagrama de atividade, o DME tem o nó de início de estado, conforme Figura 1.

O próximo elemento gráfico do DME é a representação de um estado (Figura 2), que é bastante semelhante à representação gráfica de uma atividade no diagrama de atividade.

O próximo elemento gráfico do DME é a “nota”. Esse elemento é utilizado no DME para fornecer maiores detalhes sobre um estado. Assemelha-se a um post-it (papel que colamos na lateral do monitor, por exemplo).

Por fim, temos a representação gráfica do “estado final” (Figura 5), que se assemelha muito ao “nó final” do diagrama de atividade (Figura 4). Veja, a seguir, a diferença entre os dois símbolos:

Na Figura 5, pode-se observar o “estado final” de um DME, indicando que aquele diagrama está sendo finalizado. Trata-se do último estado que o caso de uso em modelagem alcança.

Após você conhecer todos os principais elementos gráficos do DME, chegou o momento de analisarmos um diagrama completo. Contudo, antes de apresentar um DME, reapresentarei um diagrama de atividade que foi usado na lição anterior para compreendermos as semelhanças e diferenças entre esses dois diagramas (Figura 6).

A Figura 6 apresenta um diagrama de atividade com dois atores (candidato e sistema) e cinco atividades. O diagrama modela um caso de uso fictício, chamado “realizar inscrição”. Na próxima figura, você observa o DME (Figura 7) associado ao diagrama de atividade anterior (Figura 6).

Observa-se, pelo diagrama da Figura 7, que o caso de uso “realizar inscrição” foi modelado conforme apresentado no diagrama de atividade. Contudo pode-se observar algumas diferenças e semelhanças. As semelhanças estão associadas aos elementos gráficos, conforme já foi discutido. As diferenças entre os dois diagramas (Atividade e Máquina de estado), por sua vez, são, principalmente, a ausência das barras de participação, pelo lado do diagrama de atividade, e a existência do nome do método dentro de cada estado, pelo lado do DME. Ademais, pode-se fazer maior uso das “notas” no diagrama de máquina de estado, apesar de o objetivo nota existir em outros diagramas da UML. 

Um outro elemento de destaque é o uso do verbo no gerúndio, e não mais no infinitivo, como no diagrama de atividade. No diagrama de atividade, o título da atividade é “selecionar concurso” e, no DME, “selecionando concurso”. Essa diferença é necessária porque, no diagrama de atividade, você está modelando uma ação enquanto, no DME, um estado (ao que está acontecendo naquele momento). Legal, né?!

O DME é um diagrama que permite ao projetista do software modelar o método existente nas classes que será usado em um momento específico (estado) em determinado caso de uso. Esse tipo de diagrama é bastante informativo para o desenvolvedor, porque permitirá que ele saiba exatamente qual nome dar aos métodos e onde esses deverão ser utilizados. Pode-se associar esse tipo de diagrama a um projeto de uma casa, em que o engenheiro(a) civil ou, mesmo, o arquiteto(a) apresenta para o mestre de obras qual será o tipo de material a ser usado em cada cômodo da casa. Concorda que isso pode evitar ou minimizar erros na construção e sair conforme planejado? A ideia é a mesma para um software.

Você tem estudado, ao longo das últimas lições, os diagramas da UML bem como seus elementos gráficos e sua aplicação em um projeto de software. Acredito que você já tenha percebido que não é difícil construir os diagramas da UML e, como objetivo final, o projeto de um software. Os elementos centrais para a construção de um bom projeto de software estão na observação da integração entre os diagramas para que eles sejam coerentes com as funcionalidades (casos de uso) estabelecidas.

O Diagrama de Máquina de Estado (DME), estudado nesta lição, pode ser seu grande aliado durante o projeto de um software para associar as funcionalidades do sistema em termos de códigos (métodos) e não funcionalidades abstratas (casos de uso). Lembrando que os métodos são aquelas partes da classe que estão no código do software. Esses métodos estarão no seu projeto distribuídos pelas classes e, por meio do DME, você pode dizer ao desenvolvedor o local em que cada um dos métodos existentes no seu diagrama de classe serão aplicados ao longo da execução de um caso de uso. Lembre-se que não faz sentido você definir um método no DME sem que, antes, ele exista no seu diagrama de classe. Pode acontecer de você perceber que há a necessidade de um método no DME, mas ele não foi apresentado no diagrama de classe ou no diagrama de sequência daquele caso de uso. Nesse caso, você deve voltar e retificar o diagrama de classe e o diagrama de sequência para que só então você modifique ou acrescente esse novo método no DME. Lembrando, também, que o Diagrama de Atividade NÃO possui método, e, sim, atividades, que, no DME, são associadas a métodos. Ok?! Não se esqueça disso!

Por fim, tenho recebido muitas dúvidas dos(as) alunos(as) sobre a necessidade, ou não, de existir código (programação) durante a criação dos diagramas da UML. Especialmente, quando digo que um método é parte do código, muitos alunos(as) acreditam que há essa necessidade de que já existam códigos associados aos métodos, mas isso NÃO é necessário. A ideia é exatamente o contrário. Você apenas define o projeto (a estrutura do software) e, na sequência, esse projeto é passado ao desenvolvedor. Lembre-se da associação que fazemos entre o(a) engenheiro(a) civil e o(a) arquiteto(a) — esses profissionais não “sobem” paredes, mas trabalham no projeto (o que deve ser feito), sendo que o mestre de obras é o responsável por subir as paredes, que, no nosso caso, seria o desenvolvedor.