Há algum tempo (três anos, acredito eu) assisti uma palestra de algumas horas sobre metodologias de desenvolvimento e documentação de softwares. O palestrante era pesquisador do SEI, e seu foco de pesquisa no momento era a utilização de WIKIs como forma de documentação ágil de sistemas.
Independentemente de seu foco de pesquisa, o palestrante procurou enfatizar a importância da utilização de uma notação adequada ao documentar uma arquitetura. Mas o que poderia eventualmente significar “notação adequada” ? Pois bem, aí é que começa a bagunça.
Quem nunca se deparou com um “diagrama” recheado de círculos e/ou quadrados, com setas ou traços ligando os elementos? Isso é o que mais vemos todos os dias, como por exemplo nesta imagem do site da SUN, contida dentro de um artigo sobre a VM java e como ela se relaciona com linguagens de script:
(http://java.sun.com/developer/technicalArticles/scripting/languages/images/scriptingengine.gif)
O exemplo acima traduz claramente o que o palestrante quis dizer. Na grande maioria das vezes as pessoas optam por expressar suas arquiteturas ou idéias, através de notações próprias e que muitas vezes não querem dizer nada para nenhuma pessoa além dela mesma. Isto é um problema? É e não é.
Não é um problema porque o objetivo é e sempre será expressar idéias, planos ou implementações da melhor forma possível. Além de que, não são todas as pessoas (eliminando os desenvolvedores (será?)) que conhecem notações como a UML por exemplo. Muitos de nossos superiores não conhecem ou não julgam ser adequado em determinados momentos, utilizar a notação UML. Isto é um fato que não podemos simplesmente desprezar, nem nos tornarmos xiitas a ponto de dizer que se não for assim não será feito. Essas pessoas geralmente julgam círculos, quadrados, setas e desenhos contendo servidores como algo muito mais intuitivo, mesmo que não possuam uma notação extremanente formal a ser seguida nem sequer uma metodologia (por exemplo: círculos indicarem processos e retângulos armazenamentos). Mas aí é que a coisa se torna um problema…
Esse tipo de diagramação torna-se um problema a partir do momento em que não definimos o que cada símbolo representa no contexto expresso. No exemplo acima retirado do site da própria SUN, esta definição não foi feita. A não ser que tentemos adivinhar o que cada um dos símbolos representa, não conseguimos afirmar com propriedade que os quadrados representam os módulos da VM e as setas uma possível comunicação entre eles (pelo menos é o que me parece). Mas e se não for isso? E se o autor quis dizer uma outra coisa completamente diferente como por exemplo, indicar que as setas fechadas são chamadas de bibliotecas nativas e e as abertas são chamadas entre classes java? Não iremos saber, de forma alguma…
O que é importante ressaltar é que não é incorreto utilizar sua própria forma de expressar uma arquitetura ou idéia. O importante é descrever em qual notação ela foi feita, ou até mesmo dizer que não é uma notação definida, sendo que neste caso, a legenda contendo a indicação de cada um dos símbolos bem como o que significam deve estar presente. No caso de uma notação mundialmente conhecida ao menos seu nome precisamos referenciar, obrigatóriamente. Caso apresentemos um diagrama de classes UML por exemplo, devemos sempre colocar próximo a ele ou em um rodapé, mesmo soando redundante para nós , o dizer: NOTAÇÃO UML.
O exemplo da SUN de forma mais correta portanto, seria algo do tipo (não sei se está certo, se eles tivessem colocado uma legenda, não me induziriam ao erro! )
É isto! Parece ser uma bobeira tremenda e até mesmo causar certo espanto, mas quanto mais formos claros em relação à documentar ou apresentar uma idéia ou arquitetura, teremos menos desentendimentos e dores de cabeça em nossos projetos!!
