Este problema da transforma¸c˜ao de c´odigo em modelos enquadra-se, como j´a referido, no ˆambito da MDA. De uma forma mais espec´ıfica centra-se na pro- blem´atica da transforma¸c˜ao autom´atica de modelos (em c´odigo fonte), neste caso inversa. O problema em causa assenta na funcionalidade de elevar o grau de abstrac¸c˜ao do software num processo por passos. O processo come¸ca pelo n´ıvel do c´odigo fonte (neste caso Java) que ser´a abstra´ıdo para um diagrama de classes (correspondente ao PSM). Este problema ocorre com alguma regu- laridade no desenvolvimento de software e representa a necessidade de abstrair um sistema complexo, desactualizado ou desconhecido (ou parte dele) para uma representa¸c˜ao mais ´util.
Quando este problema ´e abordado do ponto de vista da implementa¸c˜ao ´e necess´ario ter em conta v´arios factores, e permite concluir que se est´a perante um problema composto por trˆes principais itens. Esses trˆes itens correspondem `
a an´alise, representa¸c˜ao interm´edia e representa¸c˜ao visual do diagrama.
Figura 4.1: Representa¸c˜ao do processo de convers˜ao de c´odigo fonte para PSM.
1. O primeiro ponto do problema consiste na an´alise do projecto. Este pro- cesso prevˆe dois passos distintos: a an´alise da estrutura do projecto (an´alise da hierarquia de ficheiros) e a an´alise concreta de cada um dos ficheiros Java. A an´alise da estrutura do projecto (como conjunto de ficheiros) leva `
a necessidade de percorrer toda esta hierarquia, seleccionando os fichei- ros relevantes ao mesmo tempo que se ignoram os ficheiros irrelevantes ao problema em quest˜ao. A an´alise concreta de cada um dos ficheiros leva
4.2. ENQUADRAMENTO DO PROBLEMA 53 `
a necessidade de fazer uma an´alise semˆantica aos mesmos por via de um parser. Esta an´alise permite obter e extrair toda a informa¸c˜ao expressa textualmente nesses ficheiros. A implementa¸c˜ao da funcionalidade de ite- ra¸c˜ao dos ficheiros juntamente com a implementa¸c˜ao ou utiliza¸c˜ao de um parser para extrac¸c˜ao da informa¸c˜ao de cada um dos elementos s˜ao as tare- fas necess´arias para solucionar este problema. Este passo est´a representado do lado esquerdo na Figura 4.1, onde os ficheiros s˜ao analisados.
2. O segundo ponto deste problema ´e dependente do primeiro. Este consiste na problem´atica da representa¸c˜ao interm´edia da informa¸c˜ao analisada no passo anterior. Depois de analisado um projecto ´e necess´ario preservar os dados extra´ıdos de forma eficiente, onde n˜ao seja perdido nenhum de- talhe relevante. Para tal ´e necess´ario ter uma forma que seja adequada para essa representa¸c˜ao de informa¸c˜ao. A MDA prevˆe uma forma para o fazer por interm´edio de um metamodelo. Para solucionar este problema ´e necess´ario definir um metamodelo adequado n˜ao s´o `a linguagem Java mas tamb´em que suporte o processo MDA inverso. Os dados extra´ıdos no ponto anterior ser˜ao ent˜ao mapeados no metamodelo definido. Este metamodelo deve ser completo, concreto e preciso ao mesmo tempo que n˜ao deve estar sobrecarregado de informa¸c˜ao. Apesar de n˜ao ser necess´ario preservar toda a informa¸c˜ao, ´e importante que ele esteja preparado para tal. Se o metamodelo permitir representar alguma informa¸c˜ao que n˜ao ´e estritamente necess´aria (como por exemplo implementa¸c˜ao dos m´etodos) poder´a mais tarde permitir a extens˜ao da ferramenta (por exemplo a uma ferramenta de round-trip). Resumidamente, a resolu¸c˜ao deste problema necessita da defini¸c˜ao de um metamodelo adequado ao problema em causa (considerando possibilidades de expans˜ao). Necessita ainda de uma forma de mapear correctamente esses elementos no metamodelo. Na Figura 4.1 ao centro est´a representado este passo, que consiste no mapeamento no metamodelo.
3. O terceiro e ´ultimo ponto a considerar ´e dependente da resolu¸c˜ao dos an- teriores. Este ponto apresenta necessidade de fazer a representa¸c˜ao visual da informa¸c˜ao do projecto, j´a representada no metamodelo. O que isto significa ´e que os elementos do metamodelo s˜ao transformados em ele- mentos UML, ou seja, para cada elemento do metamodelo vai haver um elemento (visual) UML que ser´a representado visualmente ao utilizador. Nem todos os elementos do metamodelo possuir˜ao um mapeamento directo para UML o que levar´a `a necessidade de processar previamente esse me- tamodelo. Uma forma eficiente de auxiliar o processo de representa¸c˜ao ´e por adi¸c˜ao de informa¸c˜ao extra ao metamodelo. Esta informa¸c˜ao refere-se mais em espec´ıfico `a informa¸c˜ao visual para um elemento que cont´em a posi¸c˜ao, cor, dimens˜oes, entre outros. Apesar desta informa¸c˜ao n˜ao es- tar directamente relacionada com o metamodelo, por motivos de eficiˆencia ser´a considerado a inclus˜ao no mesmo. Este ponto fica apenas solucionado
quando for definido concretamente como s˜ao representados estes elemen- tos, isto ´e, de que modo ser˜ao apresentados ao utilizador. Um requisito essencial ´e que a representa¸c˜ao visual dos componentes seja interactiva (em que os elementos aparecem dispostos no ecr˜a e o utilizador interage, podendo at´e rearranjar os mesmos). Resta apenas decidir em que contexto ser˜ao apresentados: dentro de outra ferramenta (via plugin), de forma in- dependente (aplica¸c˜aoJava), num formato externo (imagem), entre outras representa¸c˜oes poss´ıveis. De uma forma mais concreta, depois de definido esse formato ´e necess´ario fazer uma travessia pelo metamodelo, ler a infor- ma¸c˜ao visual associada a cada elemento o pr´e processamento. Finalmente calcular uma disposi¸c˜ao para os elementos e proceder `a sua representa¸c˜ao. Resumidamente, este problema necessita que exista um mapeamento en- tre as entidades do metamodelo, as entidades UML, e uma forma visual de representa¸c˜ao. De seguida necessita de uma forma de ajustar as proprie- dades visuais de acordo com os elementos e fazer a sua disposi¸c˜ao (visual). Finalmente os elementos ser˜ao representados visualmente no formato es- colhido. Mostra-se este passo na Figura 4.1 `a direita, onde ´e exemplificada a representa¸c˜ao visual.