Uma abordagem de verificação de conformidade para prover consistência e integridade nas diferentes percepções da arquitetura
Por Izabela Vanessa de Almeida Melo
(izabela@copin.ufcg.edu.br)
Existem várias formas de realizar a verificação de conformidade arquitetural, porém nenhuma delas leva em consideração os diferentes níveis de abstração para definir regras arquiteturais. Nesta edição saiba um pouquinho mais sobre a solução encontrada pela mestranda Izabela Vanessa com sua pesquisa desenvolvida no SPLab.


Existem diversas definições e visões diferentes para o termo “arquitetura de software”. Em nossa pesquisa, focamos na visão estrutural, onde arquitetura de software (Figura 1) envolve um conjunto de decisões e regras arquiteturais que estabelecem relações de dependências entre os componentes de uma aplicação [1]. Os componentes são os principais módulos, camadas, classes de um sistema. Considerando dois componentes hipotéticos A e B, um componente A depende de um componente B quando ele utiliza serviços (chamada de métodos, acesso a atributos, herança, etc) de B. Um exemplo de uma regra arquitetural é “A não pode depender de B” ou, ainda, “B não pode herdar A”.



Figura 1. Definição estrutural de arquitetura de software.


A arquitetura de software é um dos artefatos mais importantes no ciclo de vida de um sistema [2][3]. Ela interfere nos objetivos de negócios, objetivos funcionais e na qualidade do sistema. Na prática, todo sistema tem duas arquiteturas: planejada e concreta (implementada). A planejada é a arquitetura definida/documentada pela equipe responsável por tal atividade. Enquanto isso, a concreta é a arquitetura representada na implementação do código fonte do sistema. A tarefa de verificar se as decisões arquiteturais definidas na arquitetura planejada estão de acordo com a arquitetura concreta/implementada é conhecida como verificação de conformidade arquitetural [4]. Divergências entre as duas arquiteturas são chamadas de violações arquiteturais. Um exemplo de violação é apresentada na Figura 2, onde, hipoteticamente, existe a regra arquitetural “O componente Model não pode acessar o componente View”.


Figura 2. Exemplo de violação arquitetural para a regra “Model não pode acessar View”.



A verificação de conformidade arquitetural é importante para o entendimento do código, reuso e manutenibilidade do sistema [5]. Existem várias formas de realizar a verificação: manualmente ou utilizando técnicas e ferramentas auxiliares como DSM (Dependency Structure Matrix ou Matriz de Dependência Estrutural), modelos de reflexão, DCL (Dependency Constraint Language) ou testes de design. Nenhuma delas, contudo, leva em consideração os diferentes níveis de abstração para definir regras arquiteturais, como, por exemplo, os níveis mais descritivos (visão da equipe de arquitetura) e os níveis mais automáticos, testáveis (visão da equipe de desenvolvimento).


Nossa solução para este problema é a ferramenta ARTT (Architectural Representation Transformation Tool) que transforma automaticamente o nível de abstração da equipe de arquitetura no nível de abstração da equipe de desenvolvimento, permitindo uma comunicação mais rápida e consistente entre as equipes. Com ARTT, a equipe de arquitetura escreve as regras arquiteturais em uma linguagem declarativa, inspirada em DCL (Dependency Constraint Language) [6]. DCL é uma linguagem de domínio específico utilizada para representar arquiteturas de software. A sintaxe da linguagem utilizada em ARTT pode ser visualizada na Figura 3.



Figura 3. Sintaxe da linguagem utilizada em ARTT.


A equipe de desenvolvimento, por sua vez, utilizará uma representação arquitetural no formato de testes de design. Estes, podem ser incorporados ao conjunto de testes funcionais e são escritos em uma linguagem mais próxima da equipe de desenvolvimento (Java). Os testes de design utilizam a API DesignWizard [7] que dá suporte a análise estática de programas Java. A transformação automática proposta economiza tempo no processo de verificação de conformidade arquitetural e garante que cada equipe utilize seu próprio nível de abstração. Um exemplo de transformação pode ser visualizada no Algoritmo 1 (código gerado automaticamente a partir da regra “rule A cannot-access B”).



Algoritmo 1. Código da transformação automática, feita por ARTT, da regra “rule A cannot-access B”.


No momento, a pesquisa está na fase de validação. Algumas estratégias já foram traçadas e estão em processo de discussão e análise. As principais delas são: adicionar mutantes ao código fonte para verificar se os testes gerados por ARTT capturam essas violações; realizar um survey com arquitetos de software para avaliar a ferramenta; comparar os resultados obtidos pelos testes gerados por ARTT e testes escritos manualmente por um especialista em testes de design; gerar regras arquiteturais aleatórias, a partir do conjunto de relacionamentos de um sistema e verificar se as violações são capturadas pelos testes gerados por ARTT.


Essa pesquisa, nomeada de “Uma abordagem de verificação de conformidade para prover consistência e integridade nas diferentes percepções da arquitetura”, está sob orientação do professor doutor Dalton Dario Serey Guerrero (UFCG) e coorientação do professor doutor Marco Tulio de Oliveira Valente (UFMG).


Nesse mestrado, foi publicado o artigo “Verificação de Conformidade Arquitetural com Testes de Design - Um Estudo de Caso” no I Workshop Brasileiro de Visualização, Evolução e Manutenção de Software (VEM), evento que aconteceu dentro do CBSoft 2013. Neste ano, o artigo “Uma Ferramenta para Verificação de Conformidade Visando Diferentes Percepções de Arquiteturas de Software” foi aceito para publicação na Sessão de Ferramentas do CBSoft 2014.



Veja também:

Link para o artigo do VEM 2013.

Link para a página do VEM 2013.

Link para a página da Sessão de Ferramentas CBSoft 2014.



REFERÊNCIAS

[1] Jansen, A. and Bosch, J. (2005). Software architecture as a set of architectural design decisions. Proceedings of the 5th Working Conference on Software Architecture, pages 109–120.

[2] Jens Knodel, Dirk Muthig, Matthias Naab, and Mikael Lindvall. Static evaluation of software architectures. In 10th European Conference on Software Maintenance and Reengineering, pages 279{294, Bari, Italy, 2006.

[3] Jens Knodel and Daniel Popescu. A comparison of static architecture compliance checking approaches. In IEEE/IFIP Working Conference on Software Architecture, pages 44{53, Mumbai, India, 2007.

[4] Clements, P., Garlan, D., Little, R., Nord, R., and Stafford, J. (2003). Documenting software architectures: views and beyond. Proceedings of the 25th International Conference on Software Engineering, pages 740–741.

[5] Michael Eichberg, Sven Kloppenburg, Karl Klose and Mira Mezini. Defining and continuous checking os structural program dependencies. In 30th International Conference on Software Engineering, pages 391{400. Leipzig, Germany, 2008.

[6] Terra, R. and Valente, M. T. (2009). A dependency constraint language to manage object-oriented software architectures. Software: Practice and Experience, 32(12):1073–1094.

[7] Brunet, J., Guerrero, D., and Figueredo, J. (May 2009). Design Tests: An Approach to Programmatically Check you Code Against Design Rules. Proceedings of the 31st International Conference on Software Engineering (ICSE 2009), New Ideas and Emerging Results.


Editado por: Maria Letícia Leôncio Barbosa

Jornal PETNews - Edição: Julie Pessoa- Revisão: Lívia Sampaio e Gleyser Guimarães
Grupo PET Computação UFCG, 2014. All rights reserved.