Consertar o que não se conhece?
Imagine a seguinte situação: você trabalha em uma grande empresa de e-commerce, que vende 800 produtos por minuto, e em algum dia de alta temporada de vendas, o sistema para de fazer vendas, porque não consegue concluir os pagamentos (por algum problema no sistema).
Você trabalha na equipe de sustentação (equipe de desenvolvimento que mantém o sistema no ar, faz o suporte nível 2 e 3) do sistema de vendas.
Mas não é um simples sistema, é uma solução complexa.
Possui integrações com bancos, operadoras de cartão de crédito, SAP (ERP), Sales Force (CRM), e com um barramento de serviços onde tem APIs diversas, e estas APIs conectando a três banco de dados diferentes.
E para entender a causa do bug, você precisa rastrear uma transação ponta a ponta.
Mas você não conhece todos os elementos do contexto, conhece apenas o servidor onde o sistema está instalado, o pool do servidor web e tem o usuário deste pool.
A cada minuto que o sistema fica parado a empresa perde R$ 800 mil reais. O chamado (ticket) caiu para você.
E você não consegue nem sair do lugar.
Não conhece os componentes do sistema, não sabe onde os componentes estão e como eles estão instalados, e como se comunicam.
Por incrível que pareça, isso acontece todos os dias, em empresas de portes e segmentos diversos, no mundo inteiro.
Pelo desconhecimento de todos as partes (hardware/software/infra) de uma solução, onde estão instalados componentes, como se comunicam etc. profissionais ficam na mão para resolver problemas, gerando prejuízos milionários.
E quem já foi analista responsável por sustentação de sistemas (ou é atualmente), sabe o sufoco que é estar em situações como essas.
“Quando lidamos com soluções complexas, gigantes, em empresas grandes, qualquer “escorregão” pode gerar impacto de milhões. E por incrível que pareça, em empresas gigantes as pessoas não tem 100% de conhecimento sobre tudo que precisam “consertar” ou “ajustar”. Este tipo de erro, que poderia ser evitado facilmente em muitos casos, realmente ocorre toda hora, e gera prejuízos materiais colossais.”
Para diminuir este este ponto de dor (Pain Points) tão comum nas áreas de sistemas e operações das empresas, o Diagrama de Instalação da UML é uma excelente ferramenta.
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.
Um detalhe interessante, principalmente em contextos ágeis (onde as pessoas interagem muito): muitas vezes várias pessoas conversam frequentemente sobre um mesmo contexto, onde todos assumem “implicitamente” estarem entendendo 100% do contexto debatido. Muitas das vezes, dúvidas sobre a estrutura da instalação de uma aplicação preexistem, existem e existirão, pois detalhes costumam ser ignorados. E bugs, code smell etc. são “mantidos vivos” pela ignorância, onde um diagrama de instalação bem feito, bem detalhado, poderia resolver…
Software ou Solução?
Este é um blog que fala sobre Engenharia de Software. Logo, sempre falamos sobre produção de software.
A razão de ser de um software é materializar soluções para problemas. Por isso costumamos chamar software de solução.
Mas quase nunca um único software é a solução para um problema. No mundo empresarial atual, isso é quase regra.
Para fazer uma venda, uma compra, uma reserva, um pagamento, a solução tecnológica sempre envolve vários softwares trabalhando em conjunto.
Em função disso, é fundamental pensar holisticamente a solução pois, para resolver bugs, evoluir uma arquitetura, fazer manutenção em um software que é uma parte de um todo, temos que enxergar o todo, e suas partes conectadas.
Objetivos de utilização
O Diagrama de Instalação da UML tem como objetivo principal representar a arquitetura física de um sistema/solução, como os componentes estão distribuídos, a relação física e lógica entre os seus componentes.
Ou seja: quais são os componentes do sistema/solução, onde os componentes estão instalados e como estão conectados.
Quando usar?
O diagrama é bem versátil quanto às possibilidades de aplicação prática.
É possível desenhar (tornar gráfico) estruturas simples como uma contida em um só servidor (onde se tenha banco de dados, servidor web, outros sistemas etc.), geralmente aplicável a empresas menores.
É possível desenhar estruturas complexas de sistemas que rodam em empresas globais, por exemplo, considerando a complexidade da economia das APIs que hoje faz tanta parte da nossa realidade.
O importante é entender o contexto no qual o diagrama será aplicado, para usá-lo da melhor forma.
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 um modelo antes de efetivamente construir software executável (diminuindo o desperdício).
- Documentação de instalação existente: refletir a instalação já existente de um software, construído e distribuído.
- Esboço de ideias: desenhar modelos arquiteturais/de implantação 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. Sempre há os outros 80% dos elementos, mas realmente, quase nunca usamos. E para uma aplicação pragmática dos diagramas, gerando valor de fato, 20% é o suficiente.
Então, vou focar nos elementos mais utilizados do diagrama de instalação.
Exemplo de Uso
No contexto acima, temos um desenho simples, sem rigor quanto à identificação dos componentes, mas que já elucida muita coisa para quem precisa entender mais sobre os componentes do sistema.
Temos uma caixa (estereótipo “device” – dispositivo), representando uma estação de trabalho, onde o sistema é acessado por um atendente de Call Center.
Temos três servidores ao qual, direta/indiretamente, o software citado se conecta (servidor de aplicação do sistema web, servidor de aplicação de API, e servidor de banco de dados, com o repositório de dados).
Website SAC, API Clientes e BD SAC são representados por componentes, que ficam dentro dos nós (servidores). Entre eles temos “setas” que são os links entre os componentes.
Temos ainda uma nota explicativa com informações sobre as conexões entre os componentes, para facilitar a compreensão do diagrama.
Este exemplo aplica-se bem quando precisamos esboçar ideias, seja em papel, parede de desenho, apresentações etc.
O exemplo abaixo já é mais detalhado, vejamos.
Estamos representando o mesmo cenário do contexto anterior, entretanto, com rigor e nível de detalhe muito alto.
Para cada nó temos o nome de domínio do servidor, o sistema operacional, versão de servidor web e servidor de banco de dados.
Para cada componente temos o nome lógico do website, nome lógico da API, e nome lógico do banco de dados.
Temos ainda detalhes sobre o protocolo de comunicação usado para cada link entre os componentes, inclusive com a porta utilizada na comunicação.
E na nota explicativa, detalhes sobre como as comunicações se dão, com rigor técnico, para dar o máximo de clareza a quem for interpretar o diagrama.
Este exemplo aplica-se bem quando precisamos documentar arquiteturas físicas de sistemas, elaborar projetos que demandem disciplina para serem seguidos etc.
Geralmente utiliza-se ferramenta case ou algum aplicativo que permita elaborar o diagrama.
Concluindo
Sempre devemos buscar o equilíbrio.
Nem documentação desnecessária, nem ausência da documentação necessária.
Nós, Analista de Sistemas, temos o hábito de achar que “já entendemos tudo”, seja por falta de paciência, por imaturidade, por arrogância, ou por todos estes fatores juntos.
Mas eu adoro uma frase: “entendeu ou quer que desenha?”. 🙂
Abraço!