Identifying and analyzing software concerns from third-party components’ metadata

Abstract

Sistemas bem modularizados são mais fáceis de manter e evoluir. No entanto, não é fácil atingir uma boa modularidade. Sistemas devem ser modularizados sob diversas perspectivas e, frequentemente, existem interesses importantes que ficam espalhados ou entrelaçados entre vários módulos, os chamados interesses transversais. Logging, Acesso a Banco de Dados e Automação de Testes são exemplos de interesses transversais. Os estudos sobre interesses frequentemente recorrem à identificação manual dos mesmos. Infelizmente, a identificação manual tende a ser subjetiva e imprecisa, além de exigir muito esforço. Documentos de Requisitos de Software (DRSs) e Documentos de Arquitetura de Software (DASs) podem ser usados como recursos auxiliares na análise de interesses, mas eles não são comuns. Idealmente, os desenvolvedores precisam confiar em abordagens automáticas para identificar e processar informações sobre interesses a partir de código fonte. Nesse contexto, este trabalho utiliza a injeção de componentes em projetos de software para definir um método de localização de interesses. Em sistemas modernos, os desenvolvedores implementam módulos para lidar com as regras de negócios centrais, mas geralmente injetam componentes de terceiros na base de código para materializar interesses relacionados aos aspectos secundários do sistema. Por serem estes os tipos de interesse que mais se dispersam e se entrelaçam nos módulos dos sistemas, vimos a oportunidade de propor um método para apoiar a sua identificação e análise. Nosso método identifica interesses a partir dos metadados que os desenvolvedores usam para injetar componentes. Em seguida, ele avalia como estes interesses se espalham e evoluem ao longo do tempo na base de código. Desenvolvemos uma ferramenta chamada Architectural Knowledge Suite (AKS) para automatizar o método. Usamos essa ferramenta para conduzir um estudo de pesquisa-ação com a ajuda de especialistas em desenvolvimento de software para avaliar e refinar o método. Executamos três outros estudos para caracterizar e entender como os desenvolvedores implementam interesses no mundo real. Entre os resultados obtidos, destacamos que o método correspondeu moderadamente às expectativas dos especialistas. Notamos que é possı́vel otimizar a captura de interesses a partir do código fonte de sistemas, se eles forem agrupados considerando similaridades entre seus contextos de uso. Percebemos que, durante a evolução dos sistemas, artefatos de código tendem a não se dedicar à implementação de interesses especı́ficos. Identificamos oportunidades de adaptação do método para tornar possı́vel sua aplicação sob diferentes cenários de utilização de tecnologias de desenvolvimento.

Well-modularized systems are easier to maintain and evolve. However, it is difficult to achieve good modularity in software systems, because developers must keep systems modular with respect to several perspectives. This involves dealing with concerns that scatter and tangle through several modules, the crosscutting concerns. Logging, Database Access, and Testing Automation are examples of crosscutting concerns. Studies on concerns often resort to manual identification of interests. Unfortunately, manual identification tends to be subjective, imprecise, and effort-intensive. Software Requirement Documents (SRDs) and Software Architecture Documents (SADs) can be used as auxiliary resources to identify and analyze concerns, but they are not common assets. When they are available, there is no guarantee that they contain relevant information about concerns of particular interest. As consequence, ideally, developers should rely on automation to identify and process information about concerns over the source code. In this context, this work takes advantage of the injection of components in software projects to define a method for locating information about crosscutting concerns in software projects. On modern systems, developers implement modules to address central business rules, but they usually inject third-party components in the codebase to materialize concerns related to secondary aspects of the system. As these are the types of concern that tend to scatter and interrelate through systems’ modules, we saw an opportunity to propose a method to identify and analyzed them using injection data and metadata. Our method first identifies concerns from the metadata that developers use to inject third-party components in their systems. Then, it evaluates how those concerns spreads, and evolve through time, over the codebase. We developed a tool named Architectural Knowledge Suite (AKS) to automate the method. We used this tool to conduct an action research study with the help of software development specialists to evaluate the reliability of our method and to refine it. We also ran three other studies using our method to process real information systems’ source code, characterizing and analyzing how developers implement concerns in the real world. Among our findings, we highlight that our method met the expectations of the specialists to a moderate degree. We perceived that grouping software projects according to their contexts of use can optimize the identification and analyses of concerns. We noticed that developers tend to mix concerns by joining references to different components through the lines of source code artifacts, but we spotted some exceptional cases. We also saw opportunities to adapt our method to expand the identification of concerns toward varied contexts of adopted software development technologies.