UMA ABORDAGEM PARA RECUPERAÇÃO DA ARQUITETURA DINÂMICA DE SISTEMAS DE SOFTWARE

Reverse engineering techniques are usually applied to extract concrete architecture models. However, these techniques usually extract diagrams that just reveal static architectures, such as class diagrams. On the other hand, the extraction of dynamic architecture models can be particularly useful for an initial understanding of how a system works or to evaluate the impact of a possible maintenance task. This paper describes an approach to extract hierarchical object graphs from running systems. The proposed graphs have several features that – when combined – make them valuable when compared to similar approaches, including: (a) support to the hierarchization of objects in domains, (b) support to the full spectrum of relations and entities that are common in object-oriented systems, (c) support to multithreading systems, (d) support to a language to alert about expected (or unexpected) relations between extracted objects. We also describe the design and implementation of a tool for visualizing the proposed object graphs. Finally, we show how our approach can contribute for understanding the running architecture of two systems. Resumo—Técnicas de engenharia reversa são frequentemente usadas para extrair uma representação da arquitetura implementada de um sistema. No entanto, essas técnicas normalmente permitem a extração apenas de diagramas que revelam a arquitetura estática de um sistema, tais como diagramas de classe. Por outro lado, o estudo da arquitetura dinâmica de um sistema pode ser particularmente útil quando se deseja formar um primeiro entendimento do funcionamento de um sistema ou avaliar o impacto de uma possı́vel manutenção no mesmo. Sendo assim, descreve-se neste artigo uma abordagem que permite a recuperação de um grafo de objetos a partir da execução de um sistema existente. O grafo proposto possui diversas caracterı́sticas que – quando combinadas – o distinguem de outras abordagens semelhantes, incluindo: (a) suporte a grupos de objetos de maior granularidade, chamados domı́nios; (b) suporte aos diversos tipos de relacionamentos e entidades que podem existir em sistemas orientados por objetos; (b) suporte a sistemas multithread; (c) suporte a uma linguagem para definição de alertas associados a relacionamentos que são esperados (ou que não são esperados) em um sistema. Adicionalmente, descreve-se o projeto e a implementação de uma ferramenta para visualização dos grafos de objetos propostos. Por fim, apresenta-se um estudo de caso que mostra como essa ferramenta pode auxiliar na compreensão da arquitetura dinâmica de dois sistemas. I. INTRODUÇÃO Arquitetura de software se preocupa em descrever os componentes principais de um sistema, bem como em especificar os relacionamentos possı́veis entre esses componentes [12], [6], [18]. Assim, a definição da arquitetura de um sistema envolve um conjunto de decisões que são crı́ticas para seu sucesso e que não poderão ser facilmente revertidas nas fases seguintes de seu desenvolvimento. No entanto, apesar de sua inegável importância, componentes e abstrações com valores arquiteturais não existem para a maioria dos sistemas ou, quando existem, eles não mais refletem a implementação atual desses sistemas [14], [8], [17]. Assim, técnicas de engenharia reversa são frequentemente usadas para extrair uma representação da arquitetura de um sistema [9], [24]. Normalmente, essas técnicas permitem a extração de diagramas que revelam a arquitetura estática de um sistema, tais como diagramas de classes [11], diagramas de pacotes [11] e matrizes de dependência estrutural [19]. Esses diagramas têm como principal vantagem o fato de serem recuperados diretamente do código fonte do sistema (isto é, sem a necessidade de execução). No entanto, eles apresentam uma versão parcial dos relacionamentos que são estabelecidos durante a execução de um sistema [1], [7], [13]. Por exemplo, diagramas estáticos não revelam relacionamentos estabelecidos por meio de polimorfismo e de chamada dinâmica de métodos, nem relacionamentos por meio do uso de reflexão computacional. Além disso, exatamente por serem estáticos, eles não possuem nenhuma informação sobre a ordem com que os diversos relacionamentos modelados foram de fato estabelecidos, o que é crucial para facilitar o entendimento por parte de usuários que não tenham familiaridade com os sistemas recuperados. Em outras palavras, para a compreensão de um sistema por meio de diagramas estáticos, desenvolvedores frequentemente têm a sensação de não saber por onde começar. Por fim, diagramas estáticos não fazem diferenças entre relacionamentos estabelecidos por diferentes threads, o que dificulta o entendimento de sistemas concorrentes (os quais têm se tornado cada vez mais comum em qualquer domı́nio de aplicação e não mais apenas na área de software básico). Por outro lado, existem técnicas de engenharia reversa que visam a extração de diagramas que revelam a arquitetura dinâmica de um sistema, tais como diagramas de objetos e de sequência [11]. Como principal vantagem, essas alternativas permitem expressar o fluxo de execução de um sistema, capturando inclusive relacionamentos decorrentes de chamadas dinâmicas e de reflexão computacional [20], [26]. No entanto, esses diagramas normalmente não são escaláveis, apresentando milhares de objetos mesmo para sistemas de pequeno porte [1], [2]. Além disso, modelos dinâmicos normalmente não fazem distinção entre objetos de mais baixo nı́vel (exemplo: java.util.Date) e objetos de maior valor arquitetural (exemplo: uma coleção de objetos do tipo Customer). As soluções propostas para melhorar a escalabilidade de diagramas dinâmicos se baseiam em um mesmo princı́pio: agrupar objetos em unidades de maior granularidade (normalmente denominadas domı́nios [1], componentes [15], clusters [4] etc), de forma a permitir uma visão hierarquizada do diagrama. No nı́vel mais alto dessa visão, são representados apenas grupos de objetos de maior valor arquitetural. Pode-se então expandir os grupos de uma visão de mais alto nı́vel, de forma a fornecer mais detalhes sobre seus elementos. Esse processo pode ser repetido sucessivas vezes, até se chegar a um grafo de objetos totalmente plano, onde cada elemento representado corresponde a um objeto do programa base. Basicamente, existem duas propostas de soluções para agrupar objetos em unidades de maior granularidade: soluções automáticas (por exemplo, usando algoritmos de clusterização [5], [4]) e soluções manuais (por exemplo, por meio de anotações no código [1], [2]). Usualmente, soluções automáticas têm a desvantagem de não gerar grupos de objetos semelhantes àqueles que seriam definidos pelo arquiteto do sistema. Por outro lado, soluções via anotações são invasivas, requerem um conhecimento prévio do sistema e uma inspeção detalhada no código para anotar cada classe com marcações indicando seu papel na arquitetura do sistema (exemplo: classes da camada de visão seriam anotadas com uma marcação View). Neste artigo, descreve-se uma abordagem que permite a recuperação de um grafo de objetos a partir da execução de um sistema existente. O grafo proposto possui diversas caracterı́sticas que o distinguem de outras abordagens semelhantes, incluindo: (a) suporte a grupos de objetos de maior granularidade, chamados domı́nios, os quais são definidos de forma não-invasiva, por meio de uma linguagem de expressões regulares; (b) suporte aos diversos tipos de relacionamentos e entidades que podem existir em um sistema orientado por objetos, incluindo relacionamentos devido a chamadas dinâmicas, reflexão computacional e relacionamentos entre objetos e campos estáticos de classes; (c) suporte a sistemas multi-thread por meio do uso de cores para diferenciar objetos criados por threads diferentes; (d) suporte a uma linguagem para definição de alertas associados a relacionamentos que são esperados (ou que não são esperados) em um sistema. Adicionalmente, descreve-se o projeto e a implementação de uma ferramenta para visualização dos grafos de objetos propostos. Essa ferramenta foi projetada de forma que ela pode ser “acoplada” a um sistema existente, permitindo assim a visualização do grafo de objetos proposto à medida que o programa base está sendo executado (ou seja, diferentemente de outras abordagens, não é preciso executar o sistema, para gerar um arquivo com o rastro da execução, que somente então será exibido para os usuários finais). Por fim, apresenta-se um estudo de caso que demonstra como a ferramenta pode auxiliar na compreensão da arquitetura dinâmica de dois sistemas. O restante deste artigo está organizado conforme descrito a seguir. Na Seção II, descrevem-se o grafo de objetos proposto, incluindo uma descrição de seus principais elementos e alguns exemplos. Na Seção III, descreve-se a linguagem de alertas, usada para notificar os arquitetos sobre o estabelecimento de relacionamentos que são desejados (ou que não são desejados) em um sistema. Em seguida, a Seção IV descreve a ferramenta para visualização dos grafos de objetos propostos, bem como de eventuais alertas definidos pelos arquitetos. A Seção V apresenta um estudo de caso, envolvendo o uso da ferramenta para visualizar e compreender dois sistemas construı́dos segundo o padrão arquitetural MVC (ModelView-Controller). A Seção VI discute trabalhos relacionados e a Seção VII conclui o artigo, resumindo as principais contribuições dos grafos de objetos propostos e delineando possı́veis linhas de trabalhos futuros. II. GRAFO DE OBJETOS Um OG (Object Graph) é um grafo direcionado que representa o comportamento dinâmico dos objetos de um sistema. Os vértices de um OG representam todos os objetos e algumas das classes de um sistema. As arestas representam os possı́veis relacionamentos entre os vértices do grafo. Detalhes sobre os vértices e arestas de um OG são fornecidos a seguir. Vértices: Um OG admite dois tipos principais de vértices. Vértices na forma de um cı́rculo são usados para representar objetos. Vértic