Olá, aluno(a)! Seja muito bem-vindo(a) à mais uma lição. Hoje, você aprenderá a construir os Diagramas de Sequência da UML. Pode-se dizer que o Diagrama de Sequência é o terceiro mais importante diagrama da UML, isso porque o primeiro seria o Diagrama de Caso de Uso, e o segundo, o Diagrama de Classe (RUMBAUGH; JACOBSON; BOOCH, 1999).

Sempre gosto de lembrar que a construção dos diagramas da UML é semelhante às plantas de uma casa ou prédio que são realizadas por engenheiros(as) civis ou arquitetos(as). O objetivo é fornecer à pessoa que construirá o produto o maior número de informações possíveis de forma que tudo saia como planejado no projeto. Isso evita retrabalho, perda de prazos, orçamentos ou erros graves que podem comprometer um projeto. No nosso caso, um projeto de software. Para que nós possamos criar o Diagrama de Sequência, antes, precisamos compreender o Diagrama de Caso de Uso e o Diagrama de Classe, porque necessitamos de informações de ambos. Assim, caso você ainda não tenha estudado ou compreendido bem as lições sobre esses diagramas, revise-as. Caso contrário, dê prosseguimento nesta lição.

O projeto de um software possui várias partes, não se limitando apenas à codificação. Assim, para que o desenvolvedor do software tenha em mãos as informações que ele, realmente, precisa e saiba exatamente o que fazer em cada parte do software, é preciso fornecer caminhos para ele. Esses caminhos são os diagramas da UML, que detalham, em formato gráfico, o que o desenvolvedor do software deve fazer.

Conforme comentei, o Diagrama de Sequência depende do Diagrama de Caso de Uso e do Diagrama de Classe, mas a pergunta é: por que há essa dependência? O motivo é bastante simples! Enquanto o Diagrama de Caso de Uso apresenta as funcionalidades principais do software e suas interações com atores externos ao sistema, o Diagrama de Classe apresenta a estrutura interna do sistema, a forma como os dados serão armazenados e inter-relacionados.

Assim, para compreendermos como cada caso de uso do Diagrama de Caso de Uso funciona internamente e quais elementos são usados ao longo de um caso de uso, necessitamos do Diagrama de Sequência. Vamos a um exemplo para ficar mais claro: caso eu tenha, no meu Diagrama de Caso de Uso, três casos de uso, chamados “gerir funcionários”, “gerir inscrições” e “gerir avaliações”, teremos, também, obrigatoriamente, três Diagramas de Sequência, um para cada caso de uso existente no Diagrama de Caso de Uso. “Usaremos” as classes e métodos já existentes no Diagrama de Classe com os casos de uso do Diagrama de Caso de Uso no nosso Diagrama de Sequência.

Até agora, porém, eu ainda não disse porquê o Diagrama de Sequência é importante. Vamos lá! O Diagrama de Sequência é importante porque permitirá que façamos a modelagem temporal de uma funcionalidade do sistema (caso de uso). Quando eu digo modelagem temporal, estou me referindo ao que acontece primeiro, o que acontece depois, e assim por diante; ou seja, é uma forma que eu tenho de mostrar ao desenvolvedor a sequência temporal dos “acontecimentos” dentro de uma funcionalidade/requisito funcional do meu software.

Para compreendermos, de forma mais profunda, como um Diagrama de Sequência é usado no projeto de um software, imagine a funcionalidade de um caixa eletrônico de um banco. Para que seja possível compreender quais são as etapas/passos que o desenvolvedor seguirá ao programar as funcionalidades do caixa eletrônico, precisamos desenvolver a sequência lógica e temporal desses passos. Vamos lá!

O primeiro passo é o dono da conta bancária informar os dados da conta ou o seu CPF na tela do caixa eletrônico. Nesse momento, estamos usando, por exemplo, o caso de uso chamado “autenticar usuário”. Na sequência, esses dados inseridos devem ser validados na base de dados. Nesse momento, estamos usando um método da classe chamada “cliente”, que possui o método “validarUsuario()”. Caso o usuário seja validado ou não, o método retorna à informação de que a autenticação ocorreu com sucesso ou não para a tela do usuário — a tela do usuário é representada aqui pelo elemento do diagrama de classe Interface do Usuário (veja a lição sobre Diagrama de Classe, caso não se lembre). 

Com o usuário autenticado, o nosso Diagrama de Sequência é finalizado, porque a funcionalidade foi completamente modelada. Na sequência da autenticação, o cliente do banco passa a ter acesso a outras funcionalidades do sistema, mas lembre-se que cada caso de uso deve ser representado por um Diagrama de Sequência. Assim, caso você queira referenciar uma outra funcionalidade (caso de uso), crie um novo Diagrama de Sequência e não misture as funcionalidades. 

O Diagrama de Sequência é um tipo de diagrama utilizado para representar o comportamento de um sistema, com o objetivo de estabelecer a ordem dos eventos que acontecem durante um processo específico. Ele permite identificar as mensagens que precisam ser enviadas entre os elementos envolvidos e a sequência em que elas devem ocorrer.

O Diagrama de Sequência tem como base o Diagrama de Caso de Uso, em que se tem, normalmente, um Diagrama de Sequência para cada caso de uso presente no Diagrama de Caso de Uso. Nesse sentido, um Diagrama de Sequência permite, também, documentar e validar um caso de uso específico. O Diagrama de Sequência possui uma relação bem próxima, também, com o Diagrama de Classe.

Para a construção do Diagrama de Sequência, é preciso conhecer os elementos que formam esse diagrama. Então, vamos lá! O primeiro elemento do Diagrama de Sequência é o ator com a sua linha de vida (Figura 1).

A Figura 1 representa o ator envolvido no caso de uso que está sendo modelado no Diagrama de Sequência. A sua linha de vida representa o tempo em que o ator interage no caso de uso. Pode haver mais de um ator em um Diagrama de Sequência. Nós conseguimos saber quantos atores existirão no Diagrama de Sequência por meio do Diagrama de Caso de Uso. 

O próximo elemento do Diagrama de Sequência são as mensagens, ou estímulos. As mensagens, no Diagrama de Sequência, são utilizadas para demonstrar a ocorrência de eventos, em que, na maioria das vezes, chama-se um método de um objeto envolvido no processo. Porém pode haver a comunicação entre atores, assim não haverá o disparo de nenhum método, como apresentado na Figura 2.

A Figura 2 demonstra como pode correr a comunicação entre dois atores em um Diagrama de Sequência, mas também podemos ter mensagens que “disparam” métodos das classes, conforme Figura 3.

A Figura 3 apresenta a modelagem da interação entre o controlador de um sistema bancário e a classe pessoa física. O nome “perfis1” representa a instância da classe pessoa física que está sendo utilizada na comunicação. O texto da seta, “consultar cliente”, representa o evento que está ocorrendo, e o texto “consCPF(long)” informa qual método da classe pessoa física que deverá ser utilizado. 

Na sequência, Figura 4, nós temos a modelagem de uma mensagem de retorno, após a execução do método que consulta o CPF, “consCPF()”. 

A seta tracejada da direita para a esquerda representa uma mensagem de retorno, após a execução do método. A princípio, todas as execuções de métodos terão algum tipo de retorno para o controlador, para que, na sequência, ocorra algo na tela do usuário. O Diagrama de Sequência, também, permite que sejam modeladas referências a casos de uso (fragmentos de interação). Com esse recurso, é possível referenciar, por meio da palavra Ref (Referred), outros casos de uso não detalhados no diagrama em desenvolvimento. Assim, pode-se montar diagramas mais complexos sem que fiquem ilegíveis ou incompreensíveis, devido à quantidade de elementos gráficos. Veja um exemplo desse recurso na Figura 5.

O diagrama da Figura 5 modela que o cliente solicita, fisicamente, a um funcionário do banco que a sua conta seja encerrada. O funcionário do banco acessa a interface do sistema bancário e utiliza a funcionalidade “emitir saldo”. Essa consulta ao saldo é necessária, porque a conta só pode ser encerrada se o cliente não tiver dinheiro na conta, ou não possuir algum valor devido. Contudo a funcionalidade “emitir saldo” é um outro caso de uso e não há como modelá-lo dentro do Diagrama de Sequência referente ao caso de uso “encerrar conta”. Assim, usamos o recurso de referência (ref) a um outro caso de uso. Dessa forma, o nosso Diagrama de Sequência fica menos “poluído” do que se tivesse que misturar casos de uso num único diagrama.

Na sequência, veremos um Diagrama de Sequência completo referente ao caso de uso realizar saque:

A Figura 6 apresenta um Diagrama de Sequência completo referente ao caso de uso realizar saque e demonstra, passo a passo e temporalmente, cada uma das atividades que ocorrem no caso de uso. Inicialmente, o cliente do banco insere o cartão no caixa eletrônico, representado no diagrama pelo elemento “interface banco”, o cartão é lido e o evento de consulta da conta associada ao cartão é iniciado. A conta é consultada na classe “contaComum” e, caso exista, é retornado para o controlador que a conta existe. O controlador, então, habilita, na tela do caixa eletrônico, a tela para inserção de senha.

O cliente informa a senha na tela do caixa eletrônico, que, por sua vez, passa pelo processo de validação na classe “contaComum”. Após a validação da senha, o controlador habilita, no caixa eletrônico, a tela para solicitar o valor que será sacado. O cliente do banco informa o valor na tela do caixa eletrônico, e esse valor é usado como argumento para executar o método “sacarValor(valor)” e será debitado da conta do cliente na classe “contaComum”. Após o débito, é retornado para o controlador a confirmação que habilita a emissão das notas no caixa eletrônico. Por fim, é executado o caso de uso “registrar movimento” como forma de gerar um “log” dessa transação.

Considero o Diagrama de Sequência um importante elemento que deve compor o projeto de um software. A possibilidade de modelar cada funcionalidade/caso de uso de um software numa sequência temporal permite que o desenvolvedor tenha uma visão clara daquela funcionalidade e de como ela funcionará. Contudo há desafios que você terá pela frente ao desenvolver o seu Diagrama de Sequência. O primeiro desafio é desenvolver, de forma consistente, o Diagrama de Caso de Uso e, depois, o Diagrama de Classe. Caso você não consiga criar esses dois diagramas com bastante solidez e livre de imperfeições, certamente, você enfrentará dificuldades na criação dos seus Diagramas de Sequência. Para facilitar a superação desse primeiro desafio, sugiro que você estude, com bastante vontade e intensidade, as lições que envolvem os Diagramas de Caso de Uso e de Classe. 

O outro desafio está associado ao número de Diagramas de Sequência que podem existir em um projeto de software. Como já comentei, para cada caso de uso do Diagrama de Caso de Uso, deve existir um Diagrama de Sequência correspondente. Caso o seu Diagrama de Caso de Uso tenha 30 casos de uso, você terá 30 Diagramas de Sequência. Esse número pode assustar no início, mas, com a ajuda de softwares que permitem o projeto de software por meio da UML, como o Visual Paradigm (https://online.visual-paradigm.com/), a criação desses diagramas é facilitada, e, após os primeiros diagramas, você perceberá maiores dinâmica e fluidez nos próximos.

Por fim, esteja sempre atento(a) à coerência entre os diagramas da UML. Eles não são independentes, pelo contrário, eles estão e devem estar interligados para que haja coesão no seu projeto. O maior benefício que você perceberá, ao projetar um software usando a UML, é a satisfação em ver um software sendo desenvolvido, do início ao fim, com pouco ou nenhum retrabalho e atendendo aos requisitos dos stakeholders.