Engenharia Reversa com UML em cores

Atualmente para 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 o qual 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 neste post vou falar um pouco mais sobre UML em cores e bem 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 facto 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 analise e bem como na perspectiva 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 analise é mapeado para classes e interfaces de implementação. O Modelo conceitual vem junto com os problemas do domínio em 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 modela-lo.

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 é essa:


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 de.

As Cores

São 4 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.


Post its

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

O Significado das Cores

Rosa(Momento/Intervalo): Essa cor 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(Pessoa/Lugar/Coisa/Objeto): Essa cor representa uma Pessoa/Lugar/Coisa/Objeto que seja tangível e unicamente identificável. Essa cor desempenha papel em uma evento, serviço ou momento, aqui podem aparecer cadastros e relatórios.

Amarelo(Papeis):Essa cor representa papéis. Esse papel é desempenhado pela cor verde normalmente. Essa cor é muito fácil de ser identificada, exemplos de uso da cor são: Funcionário, Fornecedor, Vendedor, Segurança, Atendente, etc.

Azul(Descrição): Essa cor representa as descrições. Pode ser um catálogo ou um conjunto de rótulos de um objeto. São os dados de referencias 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, a medida que achava um pacote colocava classes ali dentro, se já imaginava o que elas fazia colocava a cor adequada da UML em cores nela se não eu abria os fontes daquele pacote e tentava entender o que fazia, 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.Por que 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 por que 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 mapeie 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 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.


Popular posts from this blog

Kafka Streams with Java 15

Rust and Java Interoperability

HMAC in Java