O processo de engenharia reversa de c´odigo e inferˆencia dos modelos ´e j´a objecto de estudo por v´arios autores. De seguida ser˜ao apresentadas algumas alterna- tivas a abordagens que j´a est˜ao a ser utilizadas. Tamb´em ser˜ao apresentadas ferramentas envolvidas no processo. A maioria das ferramentas foi criada em ambiente acad´emico, contudo existem ferramentas comercias de grande valor.
Existem dois tipos de abordagens de an´alise de c´odigo para a inferˆencia dos modelos: abordagem est´atica e abordagem dinˆamica. A primeira aborda- gem consiste na an´alise da informa¸c˜ao est´atica do c´odigo, permitindo recuperar informa¸c˜ao estrutural, como diagrama de classes e as suas rela¸c˜oes, bem como vari´aveis e m´etodos dispon´ıveis nessa classe. Este tipo de an´alise vai ser a prin- cipal preocupa¸c˜ao para a ferramenta proposta. Os resultados esperados desta abordagem s˜ao diagramas de classes, PIM e PSM. A segunda abordagem trata da informa¸c˜ao dinˆamica, analisando o comportamento do software. Consegue prever `a partida situa¸c˜oes problem´aticas e de erro. Esta abordagem ´e baseada no comportamento e interac¸c˜ao entre as classes por an´alise dos m´etodos. Nor- malmente produz diagramas de estado, de colabora¸c˜ao entre outros. Este tipo de abordagem pode se mostrar necess´ario para permitir a inferˆencia de deter- minados padr˜oes. A t´ıtulo de exemplo, Yann-Ga¨el Gu´eh´eneuc na sua tese [31] prop˜oe a an´alise est´atica para a inferˆencia de modelos a v´arios n´ıveis e utiliza apenas a an´alise dinˆamica para complementar a informa¸c˜ao est´atica no processo de identifica¸c˜ao dos padr˜oes. Face a este resultado a an´alise est´atica pode ser considerada uma boa abordagem para a inferˆencia de modelos.
a an´alise. Os elementos mais relevantes s˜ao extra´ıdos do c´odigo, que vai ajudar a gerar modelos abstractos e concisos. O c´odigo cont´em demasiados detalhes da implementa¸c˜ao, como vari´aveis (por exemplo) que n˜ao s˜ao necess´arios para os modelos abstractos e necessitam de ser exclu´ıdos de alguma forma [6]. A abordagem proposta consiste na recolha de tanta informa¸c˜ao quanto poss´ıvel do c´odigo fonte e model´a-la [50]. De seguida ´e processada a filtragem dessa informa¸c˜ao seleccionando apenas os elementos mais importantes [2], eliminando elementos irrelevantes. Nesta fase ´e onde a interac¸c˜ao com o utilizador se pode tornar importante, sendo que o utilizador vai decidir qual o n´ıvel de detalhe que o modelo deve ter e eliminar poss´ıveis componentes irrelevantes para a an´alise, mesmo que eles sejam importantes para o sistema em causa [74].
Existem v´arios problemas a ter em conta quando ´e feita a inferˆencia de modelos a partir de c´odigo fonte Java. O maior problema consiste na an´alise de informa¸c˜ao e rela¸c˜oes porque para conseguir um diagrama abstracto e preciso ´e necess´ario ter em conta v´arios factores [34]. Os classifiers a ter em conta s˜ao atributos, m´etodos p´ublicos abstractos, m´etodos p´ublicos e m´etodos overloaded. Estes elementos podem todos ser recuperados do c´odigo fonte. A mesma abor- dagem de an´alise de c´odigo fonte e extrac¸c˜ao dos componentes pode ser feita para classes, interfaces, bound elements, tipos de dados e enumera¸c˜oes.
A recupera¸c˜ao deste tipo de dados ´e a parte mais f´acil porque se baseia apenas na an´alise de c´odigo fonte. A parte complicada ´e a inferˆencia de rela¸c˜oes entre elementos (para al´em da componente comportamental). Essas rela¸c˜oes s˜ao elementos muito importantes definidos em UML para a an´alise abstracta de um modelo. A principal dificuldade na identifica¸c˜ao de rela¸c˜oes vem n˜ao s´o da falta de especifica¸c˜ao na implementa¸c˜ao (no c´odigo fonte), mas tamb´em da falta de algoritmos precisos de recupera¸c˜ao [34].
Tamb´em devem ser considerados v´arios tipos de rela¸c˜oes e dependˆencias, o que n˜ao facilita o processo [48]. Algumas t´ecnicas para identificar esses compo- nentes foram j´a objecto de estudo e ser˜ao apresentadas de seguida. A informa¸c˜ao relevante para as associa¸c˜oes bin´arias (existˆencia de uma invoca¸c˜ao entre duas classes) e alvo de associa¸c˜ao (representa¸c˜ao visual das associa¸c˜oes) pode ser ex- tra´ıda directamente do c´odigo fonte.
A multiplicidade por outro lado ´e especialmente complicada de inferir quando as instˆancias n˜ao s˜ao nem arrays nem colec¸c˜oes. Ent˜ao, a multiplicidade a consi- derar ser´a 0..∗. As associa¸c˜oes N-´arias, nomeadamente agrega¸c˜oes e composi¸c˜oes podem tamb´em ser recuperados do c´odigo fonte [34]. Nas rela¸c˜oes “uma para muitos” existem dois passos a ser considerados:
• Recuperar os elementos dispon´ıveis no c´odigo Java;
• Remover os detalhes n˜ao necess´arios para perceber as rela¸c˜oes (a UML apenas necessita de associa¸c˜oes simples) [27].
A informa¸c˜ao das dependˆencias para diagramas de classes UML n˜ao pode ser directamente extra´ıda do c´odigo fonte, tem de ser inferida de uma representa¸c˜ao
2.5. INFER ˆENCIA DE PADR ˜OES 27 simplificada [34, 45]. Os restantes elementos UML s˜ao: atributos, opera¸c˜oes (m´etodos no caso deJava) e tipos podem tamb´em ser directamente extra´ıdos do c´odigo fonte [45].
Uma grande parte dos elementos dos diagramas de classes UML podem ser extra´ıdos directamente do c´odigo fonte desde que todas as classes estejam presentes. Um diagrama de classes pode ser constru´ıdo apenas por an´alise do c´odigo. Contudo, nem todos os componentes ser˜ao recuperados. Por outro lado alguns dos componentes s˜ao praticamente imposs´ıveis de recuperar, enquanto que outros necessitam de um algoritmo eficiente para ser recuperados.
Para que se perceba a dificuldade da inferˆencia de diagramas completos, Yann-Ga¨el Gu´eh´eneuc [34] concluiu que a ferramenta mais precisa ´e Ptidej [32] com a capacidade de recuperar 62% dos constituintes UML, ap´os um estudo sobre as melhores ferramentas de inferˆencia de modelos.
Existe ainda outra decis˜ao que tem de ser tomada para decidir a forma como a inferˆencia de modelos vai ser feita: fazer uma an´alise baseada em c´odigo fonte ou bytecode. A decis˜ao ser´a sobre a primeira abordagem, por v´arios motivos. Primeiro o c´odigo fonte representa o sistema tal como ele ´e [2], sem optimiza- ¸c˜oes do compilador e contendo todas as rela¸c˜oes. Depois o bytecode representa c´odigo compilado, por isso necessita de trabalho extra de an´alise para perceber o funcionamento da Java virtual machine, e para perceber isso ´e necess´ario um estudo mais aprofundado da especifica¸c˜ao da mesma [52]. A an´alise baseada em bytecode poderia fornecer a possibilidade de usar Java reflection, contudo este m´etodo de an´alise de classes n˜ao permite (entre outras limita¸c˜oes) a an´alise do c´odigo fonte das classes. Esta limita¸c˜ao ´e bastante impeditiva para a an´alise de certos padr˜oes.
De seguida v˜ao ser apresentadas as metodologias mais comuns, baseado num estudo sobre trabalho feito na ´area. O primeiro passo consiste na an´alise do c´odigo (fonte ou bytecode), e extrac¸c˜ao da informa¸c˜ao relevante para construir uma representa¸c˜ao como ´arvore sint´actica [18, 85] ou um grafo direccionado, como proposto por Larry Barowski et al. [2]. A representa¸c˜ao obtida possui um n´ıvel de detalhe muito elevado e necessita de ser simplificado [6, 80] mantendo contudo os elementos mais importantes. Por fim e dependendo do diagrama pretendido, ´e necess´ario saber o que fazer com essa representa¸c˜ao. Neste caso espec´ıfico o pr´oximo passo consiste na inferˆencia de padr˜oes de concep¸c˜ao.