Em um projeto que estou trabalhando, tive a necessidade
básica de entender o que o código fazia. Então, simplesmente olhar
código a código não achei uma boa idéia. Eu tinha que entender um
framework SOA que estou ajudando a construir e um protótipo. Resolvi
aplicar o método de UML em cores do Peter Coad. Peter foi
um dos criadores da OOAD
e um dos caras que mais falam de FDD.

Bom, vamos ver aqui um pouco mais sobre UML em cores e também como usei o
método para ajudar no meu mini-projeto de Engenharia Reversa, então, sem
mais delongas vamos falar primeiro de UML e de OOAD.

UML é um
linguagem de modelagem mundialmente aceita no mercado de desenvolvimento
de software. Mas não se engane, UML não é um método, essa é uma grande
confusão que o pessoal faz com a Análise
Estruturada Moderna. Na Análise Estruturada existia um método, coisa
que a UML não propõe. Logo, existiu e de fato ainda existe um gap para
então saber como fazer as atividades de análise e design.

Object Oriented Analysis
Design

Essa abordagem é focada em como modelar um
sistema tanto na perspectiva de análise como na de
design. Essa modelagem é basicamente reconhecida pela preocupação com a
classe, estado e comportamento dos objetos. Tudo isso pode ser
representado com UML.

Neste método, o modelo conceitual de análise
é mapeado para classes e interfaces de implementação. O modelo
conceitual vem junto com os problemas do domínio que estamos tentando
resolver. Esse método ainda foca no uso de Design
Patterns, como os do GOF e outros.

OBS: A questão do modelo conceitual e depois o modelo
físico existe também na analise estruturada. O problema é que muitas
vezes o pessoal quer cair direto no modelo físico, querendo saber logo
das tabelas. Esse é um erro comum, pensar direto na solução sem entender
o problema e o modelar.

A UML
em Cores

Como se fosse um tipo de extensão da UML que foca
em estereótipos, mas não através da notação comum da UML, que é esta:

Aqui os
estereótipos apareceriam em cima do nome da classe assim: <>

Assim, eu estaria dizendo que a classe Estudante é uma entidade. Os
Estereótipos nos ajudam muito a identificar o papel das classes, mas não
são muito visuais; nesse sentido que a UML em cores atacou.

Através
das cores da UML em cores conseguimos classificar o domínio e, com isso,
tirar proveito dessa situação pois, além de um fácil entendimento,
conseguimos prever possíveis métodos e possíveis relacionamentos entre
as classes ou até mesmo a falta disso.

As Cores

São quatro cores: Rosa,
Verde, Amarelo e Azul. Não sei se na época o pessoal pensou nisso, deve
ter pensado, mas essas são as cores padrão dos post-its.

Se
você já usa métodos ágeis para o desenvolvimento de software, como Scrum, XP e FDD, já deve ter esse tipo de material. A minha
engenharia reversa foi feita com a ferramenta de UML chamada JUDE, mas
você pode ser mais ágil e fazer isso com post it.

O Significado das Cores

• Rosa:
  representa um momento ou intervalo. Aqui você pode colocar
  atividades, eventos, serviços ou coisas que precisam ser registradas. Uma venda, um objeto que guarda outro por um tempo, como Sessão, são exemplos
  do uso da cor Rosa.
• Verde: representa uma Pessoa/Lugar/Coisa/Objeto que seja tangível e
  unicamente identificável. Essa cor desempenha papel em um evento,
  serviço ou momento, aqui podem aparecer cadastros e relatórios. 
• Amarelo: são os papéis. Esse
  papel é desempenhado pela cor verde, normalmente. Essa cor é muito fácil
  de ser identificada. Exemplos do seu uso são: Funcionário,
  Fornecedor, Vendedor, Segurança, Atendente etc. 

• Azul:
  representa as descrições. Pode ser um catálogo ou um conjunto
  de rótulos de um objeto. São os dados de referências que utilizamos em
  combos, lookups e lists. São objetos que não mudam o comportamento do
  sistema. Por exemplo, se a escolaridade do aluno não muda suas opções em
  um sistema de universidade, essa escolaridade deve ser azul.

A Engenharia Reversa

Então fiz
a minha engenharia reversa, tanto de um framework quanto de um protótipo
funcional que se aproximava de um sistema convencional. O que fiz foi
usar o diagrama de classes da UML utilizando a notação da UML em cores.

Comecei
mapeando os pacotes que achava, à medida que achava um pacote colocava
classes ali dentro. Se já imaginava o que elas faziam, colocava a cor
adequada da UML em cores nela; se não, eu abria as fontes daquele pacote e
tentava entender, isso fazia com que eu alterasse as cores
do modelo.

Nota:Infelizmente
nem todo mundo tem muita preocupação com nomes. Eu me preocupo muito
com isso, porque, como sempre digo, não consigo chamar um mouse de
cadeira. Esse tipo de coisa só dificulta o entendimento do código e a
sua melhoria. A UML em cores me ajudou nesses casos, porque o nome não
refletia com veracidade o que a classe era.

Assim fui indo até o
fim de todos os pacotes. No final olhei todas as classes e mapeei todos
os pacotes e responsabilidades de todas a classes, bem como suas relações
com outras classes. Na verdade esse passo seria um dos primeiros, se a
solução tivesse sido concebida com FDD; a diferença é que não existiria
código e o modelo teria mais forma do que conteúdo.

Um detalhe
importante da minha mini Engenharia Reversa foi que eu não escrevi os
métodos das classes e muito menos os atributos; eu realmente foquei nas
responsabilidades e nos relacionamentos das classes. Isso ajudou meu
modelo a ficar muito simples e fácil de ler.

Uma coisa que utilizei
bastante foram as notas da UML, que ajudaram a colocar os pontos fracos
do modelo e o que poderia ser melhorado, desta forma tinha apreendido o
modelo, sabia como ele funcionava e o que poderia ser melhorado.

Abraços
e até a próxima.