Para iniciar este post, quero deixar muito claro minha posição sobre diagramas de sequência:
Eu acho que existem poucos recursos tão bons quanto um diagrama de sequência para ilustrar um conjunto de interações entre componentes de um sistema. Com todo respeito, aquele que pensa o contrário, ou não usou este recurso, ou usou sem saber usar, pois definitivamente não é algo banal…
Quem é ou já foi desenvolvedor de sistemas sabe o preço alto que se paga por um alinhamento errado, por pessoas de um mesmo grupo não se comunicarem corretamente, sobre alguém entender algo errado e desenvolver isso errado.
O Cone da Incerteza é um fato, seja em projetos com DevOps e entregas diárias, em projetos ágeis com Sprints de uma semana, ou projetos Waterfall de seis meses.
O custo de correção de um defeito é algo pesado. E em produção de software, um percentual grande de bugs de software tem como causa o alinhamento errado entre profissionais.
Alinhamento errado = “Paulo quer que seja feito A, especifica como é B, Marcelo desenvolve C, passando para Claudia homologar D“…
Software e troca de mensagens
Um software nada mais é que um conjunto de funcionalidades, que possuem uma relação lógica entre elas e interagem entre si através de troca de mensagens.
As funcionalidades de um software são compostas de “raciocínios aplicados”, que definem como elas (as funcionalidades) se comportarão diante das interações de atores (humanos ou não) com suas funções.
Atores são pessoas clicando em botões de telas, ou telas ou rotinas consumindo web services, acessando banco de dados etc.
Estes “raciocínios” é o que chamamos de algorítimo.
Quando falamos de algorítimos, estamos falando de um conjunto de instruções, sequenciadas, que tem como objetivo realizar alguma coisa específica.
E quando estamos pensando (concebendo ou analisando) um sistema, sua estrutura, suas funcionalidades, suas iterações, um excelente recurso que temos para demonstrar como estas “instruções sequenciadas” fazem uma funcionalidade ganhar vida, é o Diagrama de Sequência da UML.
O diagrama de sequência da UML é um recurso relativamente antigo, já tem muitos anos que existe. Mas é como um banco de dados relacional ou orientação a objetos: é antigo, mas super atual, e super útil!
Classes e Métodos
Softwares produzidos com linguagem de programação orientada a objetos (e isso se aplica hoje a 98% dos casos) são estruturados em classes.
Cada Classe possui um ou mais métodos (ou operações).
O escopo de cada um destes métodos são algorítimos. O uso coordenado destes algorítimos fazem uma funcionalidade “acontecer”, na vida real.
Por exemplo, quando usamos uma funcionalidade chamada “Cadastro de Clientes” e executamos a função “Pesquisar Cliente”, na realidade temos uma sequência de instruções que são executadas ha partir de um comando, tendo um objetivo claro.
Esta sequência possui uma ordem lógica para fazer a pesquisa pelo cliente (ainda neste post exemplifico este exemplo num diagrama de sequência).
Se fossemos representar textualmente a função Pesquisar Cliente, da funcionalidade Cadastro de Cliente, seria algo como:
- O usuário (ator) “Atendente” abre a página “Cadastro de Cliente”.
- O usuário (ator) “Atendente” digita o nome do cliente e clica no comando “Pesquisar”.
- A página “Cadastro de Cliente” aciona o método “CadastroClienteUI.PesquisarClientePorNome(…)” passando a expressão informada como termo de pesquisa.
- A página “Cadastro de Cliente”, através do método “CadastroClienteUI.PesquisarClientePorNome(…)”, instancia a classe de negócio e chama o método “ClienteNegocio.PesquisarClientePorNome(…)” passando a string com a expressão informada para pesquisa.
- O método “ClienteNegocio.PesquisarClientePorNome(…)” instancia a classe de dados e chama o método “ClienteDados.PesquisarClientePorNome(…)”.
- Método “ClienteDados.PesquisarClientePorNome(…)” retorna uma lista com os registros encontrados na busca.
- Método “ClienteNegocio.PesquisarClientePorNome(…)” recebe uma lista com os registros informados pelo método “ClienteDados.PesquisarClientePorNome(…)”.
- A página “Cadastro de Cliente”, através do método “CadastroClienteUI.PesquisarClientePorNome(…)” recebe uma lista com os registros informados pelo método “ClienteNegocio.PesquisarClientePorNome(…)”.
- A página “Cadastro de Cliente” exibe a lista de registros recebidos para o usuário chamador.
Mas escrever essa sequência lógica, textualmente, sempre que for necessário explicar a alguém o comportamento de uma funcionalidade no menor detalhe nem sempre é viável.
E, uma imagem vale por mil palavras, não? 🙂
UML e Agilidade
Agilidade não é produzir software com pressa, é produzir software com velocidade, entregando valor no menor espaço de tempo possível, e melhorando isso continuamente.
Para ser ágil, é fundamental ser eficiente.
Não é plausível falar em agilidade sem eficiência, com desperdício.
Em projetos de software, um dos maiores desafios é a boa comunicação.
Deixar claro o que se quer, o que será entregue, como será produzido etc. Isso não é simples quando produzimos software, devido à complexidade inerente a esta atividade.
Quando se entende um requisito do jeito errado, sempre há o custo de fazer errado, desfazer, e fazer certo. Obviamente, este tipo de desperdício custa 3 vezes mais que se tivéssemos feito certo da primeira vez.
E neste contexto, fica claro que o uso racional de diagramas UML com o objetivo de transmitir ideias entre membros de um mesmo time, é uma ferramenta que favorece muito uma cultura ágil.
Objetivos de utilização
Um diagrama de sequência tem como objetivo principal representar graficamente o comportamento de uma funcionalidade, considerando a interação entre todos os componentes de software relacionados ao seu uso.
Quando usar?
Não há restrições quanto a o que representar: pode ser desde o funcionamento de interfaces gráficas complexas, quanto lógicas de acesso a dados, consumo de serviços em barramentos de serviço, interação entre componentes de diferentes camadas arquiteturais, processos batch, processos assíncronos etc.
Considerando as possibilidades de aplicação do diagrama, este pode ser utilizado para diferentes finalidades no contexto de produção de software, destacando:
- Design (projeto de software): definir um modelo a ser seguido para um software que ainda não existe, especificando como uma funcionalidade será antes de efetivamente construir software executável (diminuindo o desperdício). Uma aplicação comum é para explicar templates arquiteturais, por exemplo.
- Engenharia Reversa e arqueologia de código: refletir a estrutura já existente de uma funcionalidade de um software onde, a partir do código fonte realiza-se a leitura automática (ou não) das classes e suas relações e se produz o diagrama (para compreensão da estrutura do software executável).
- Esboço de ideias: desenhar modelos comportamentais para troca de ideias e alinhamento entre analistas de sistemas, por exemplo. Neste caso utiliza-se muito as paredes “rabiscáveis” das empresas mais jovens ou papel e caneta mesmo. Não necessariamente deve-se usar uma ferramenta Case, por exemplo.
Como usar?
Na UML temos três conceitos necessários de entender: diagramas, elementos e relacionamentos.
As formas gráficas que compõe cada diagrama são chamadas “elementos“. Estes elementos são “o grande lance” da UML, é o que sustenta a ideia de “notação”, é a sintaxe contida nos diagramas.
Cada elemento possui um objetivo específico, e a combinação destes elementos torna-se o diagrama, que gera a semântica do respectivo modelo.
Como tudo na vida, na UML também aplica-se o Princípio de Pareto. Com 20% dos elementos fazemos 80% dos diagramas. Então, vou focar nos elementos mais utilizados do diagrama de sequência.
Actor (Ator) – É o usuário que inicia a interação, a troca de mensagens. Pode ser um ator humano (usuário de sistema), uma funcionalidade ou componente (usuário sistêmico, o sistema chamando algum componente).
Lifeline (Linha de Vida) – É a instância de um componente (veremos mais nos exemplos a seguir), onde chegam chamadas, e de onde partem chamadas (chamadas = mensagens).
Fragment (Fragmento) – É uma “caixa” que inserimos nos diagramas de sequência onde destacamos estruturas condicionais (if/else), loops (for/while), tratamentos de exceção etc.
Message (Mensagem) – E a mensagem “de fato”. Ligamos a “seta” nas lifelines (linhas de vida/instâncias dos componentes) contidas no diagrama (sempre na direção do fluxo das interações), definindo qual é o método usado (se um diagrama de projeto), parâmetros/valores passados nas mensagens. Se é um diagrama de esboço (para troca de ideias) então as mensagens são mais textuais (como podemos ver abaixo).
Exemplo de Uso
Como citamos, um diagrama de sequência tem como finalidade equalizar a comunicação entre profissionais que estão num mesmo contexto técnico (projeto, demanda, produto etc.).
Essa comunicação pode ter como objetivo apenas “esboçar” ideias, mostrar como uma determinada funcionalidade ocorre, como alguma integração ocorre.
Quando a finalidade é esta, utilizamos diagramas de sequência sem muito rigor com relação à notação, sem falar em especificação técnica, apenas para fazer o colega de trabalho entender como alguma funcionalidade “funciona” no sistema.
No diagrama acima temos um exemplo do uso com fins de esboço de ideias. Abaixo algumas observações sobre o diagrama acima:
- O Ator “Cliente” é quem inicia o processo. Não há detalhes sobre o elemento.
- Temos três “linhas de vida” (lifelines): Cadastro de Cliente (uma interface gráfica), Componente de Negócio (algo “abstrato” que trata a lógica de negócio) e Banco de Dados (representando o repositório das informações). Não há maiores detalhes sobre estes elementos.
- Há uma mensagem realizada pelo ator na linha de vida “Cadastro de Cliente” que desencadeia outras mensagens nos elementos posteriores, representando todo o fluxo, em nível esboço, da interação originada na inclusão de dados cadastrais do cliente.
- Não há qualquer menção sobre estruturas condicionais, validações etc. afinal, é um diagrama apenas para contextualizar o comportamento de uma funcionalidade, em nível superficial, e não para especificar tecnicamente esta funcionalidade no menor detalhe de suas premissas/restrições comportamentais.
Abaixo temos outro diagrama de sequencia para representar o mesmo contexto, mas não mais com a finalidade de esboço de ideias, e sim, com a finalidade de especificar tecnicamente o comportamento da funcionalidade (design), no menor detalhe.
No diagrama acima temos um exemplo do uso com fins de projeto (design). Abaixo algumas observações sobre o diagrama acima:
- O Ator “Cliente” é quem inicia o processo. Há detalhes sobre o elemento (não logado).
- Temos três “linhas de vida” (lifelines):
- CadastroCliente: uma interface gráfica, mas agora uma página .aspx, representada por uma instância sua (instância da classe da página), com estereótipo <<apresentacao>>, o que representa a camada em que a lifeline está, e com as mensagens literais para os métodos contidos no objeto (classe instanciada).
- ClienteNegocio: uma classe de negócio, representada por uma instância sua (instância da classe, um objeto do tipo), com estereótipo <<negocio>>, o que representa a camada em que a lifeline está, e com as mensagens literais para os métodos contidos no objeto (classe instanciada).
- ClienteDados: uma classe de acesso a dados, representada por uma instância sua (instância da classe, um objeto do tipo), com estereótipo <<dados>>, o que representa a camada em que a lifeline está, e com as mensagens literais para os métodos contidos no objeto (classe instanciada).
- Não há menção ao banco de dados, ficando a abstração no diagrama sobre qual é a fonte de dados (neste caso, imagine que isso é transparente para o desenvolvedor, ele só precisa saber qual/como objeto de acesso a dados precisa consumir).
Concluindo
O diagrama de sequência da UML é uma excelente ferramenta para ilustrar como as funções de uma funcionalidade interagem entre si (cliques de botão, validações internas, acessos entre camadas da aplicação etc.).
Usando na medida certa, seja como um artefato de um design rigoroso, ou como um rascunho num quadro de desenho, pode clarear muito as ideias dos desenvolvedores e analistas, proporcionando excelente entendimento do escopo.
Participe nos comentários, grande abraço!