Verificação de Conformação de Regras de Design

Márcio Souza

Laércio Germano

Conceitos

• Arquitetura de software

• Conformação arquitetural

• Regras de design

Arquitetura de Software

“É geralmente definida como um conjunto de decisões de projeto que tem impacto em cada aspecto da construção e evolução de sistemas de software.

Isso inclui como sistemas são estruturados em componentes e restrições sobre como tais componentes devem interagir.”

(VILLELA, 2009)

Podemos dividi-la em dois tipos:

Arquitetura prescritiva: Prescreve como o software deve ser feito (comportamento, comunicação, divisão em módulos e etc).

Arquitetura Descritiva: Descreve o que foi feito (Código fonte do sistema).

Conformação Arquitetural

“Define-se conformação arquitetural como uma medida do grau de aderência da arquitetura implementada em código fonte de um sistema em relação à

sua arquitetura planejada”.

(VILLELA, 2009)

Regra de Design

“Definem padrões arquitetônicos que devem ser rigorosamente seguidas em todas as fasesdo ciclo de vida do software.”

(JÚNIOR; COELHO, 2011)

“Expressam restrições sobre o comportamento e a estrutura do programa.”

(MORGAN; VOLDER; WOHLSTADER, 2007)

Verificação de conformação de regras de design

• Consiste em verificar o sistema à procura de inconformidades entre as arquiteturas descritiva e prescritiva.

• Existe duas linhas de atuação de verificação de conformação:

• Estáticas: não requerem a execução do sistema e nem acesso a base de dados e cobre propriedade estruturais, isto é, baseadas em código.

• Dinâmicas: requerem a execução dos sistemas, acesso a base de dados e cobrem somente os caminhos acessados nas execuções dos sistemas.

O Problema

• Apesar de sua inquestionável importância, a arquitetura documentada de um sistema, se disponível, geralmente não reflete a sua implementação atual.

• Desvios em relação à arquitetura planejada são comuns:

• Desconhecimento por parte dos desenvolvedores;

• Requisitos conflitantes;

• Dificuldades técnicas , etc.

• No entanto, na maioria dos casos, os desenvolvedores são os maiores culpados pelos desvios, pois decidem ignorar o projeto existente e criam meios alternativos para a solução do problema.

Uma possível solução

Verificações constantes são um meio de “colocar nos trilhos”, aqueles desenvolvedores que ignoram decisões de

projeto.

Não seguir o projeto me traz algum problema?

• Os principais benefícios proporcionados por um projeto de arquitetura seriam anulados.

• Manutenibilidade;

• Reusabilidade;

• Portabilidade;

• Etc...

• E mais....

Degradação Arquitetural

Degradação Arquitetural

• Degradação arquitetural: é o grau de discrepância existente entre as arquiteturas prescritiva e descritiva do sistema.

• Degradação pode ser causada por desvios ou erosões arquiteturais:

• Desvio arquitetural: é a introdução na arquitetura descritiva do sistema, de decisões principais de projeto que: Não estão incluídas na arquitetura prescritiva ou não são implicações dela, mas não violam nenhuma das decisões de projeto da arquitetura prescritiva.

• Erosão arquitetural: é a introdução, na arquitetura descritiva do sistema, de decisões principais de projeto que violam decisões da arquitetura prescritiva.

Crescimento de desvios a cada versão do sistema

24 8 16

32

64

0

10

20

30

40

50

60

70

1 2 3 4 5 6

Desvio Arquitetural

Versões

Por que mesmo com um projeto bem construído, os desenvolvedores ainda tendem a ignorá-lo e inserir

desvios no código?

É mais fácil colocar a especificação de acordo com o programa, que vice-versa.

Como realizar a verificação de conformação de regras das design?

Que ferramentas existem?

• DCL

• LDM

• .QL

• Design Wizard (DW)

• Design Rules For Exception Handling (DR4EH)

• PMD

• FindBugs

DCL, LDM e .QL

• DCL

• É uma linguagem de domínio especifico, declarativa e estaticamente verificável que permite a definição de restrições de dependências entre módulos.

• LDM

• É uma ferramenta de conformação e visualização arquitetural que utiliza DSMs para representar e gerenciar dependências inter-classes em sistemas orientados objetos.

• .QL

• É uma linguagem de consulta em código fonte que provê suporte a uma ampla gama de tarefas de desenvolvimento de software, tais como verificação de convenções de código, procura por erros, cálculo de métricas de engenharia de software, detecção de oportunidades de refatoração, etc.

PMD e FindBugs

• PMD e FindBugs são ferramentas de verificação estática de código, elas permitem definição de regras que são verificadas no sistema de maneira automatizada.

• São consideradas ferramentas de verificação pois possuem arquivos de configuração onde são definidas regras que devem ser obedecidas para o sucesso da verificação.

DW e DR4EH

• Design Wizard

• É uma biblioteca que fornece uma poderosa API Java que oferece serviços para adquirir informações sobre a estrutura do código fonte.

• Design For Exception Handling

• A Design Rules For Exception Handling é uma API Java para verificação de conformação de Regras de design de tratamento de exceção que possibilita a verificação automatizada em código fonte Java.

Referências

• VILLELA, Ricardo Terra Nunes Bueno. Conformação Arquitetural utilizando Restrições de Dependência entre Módulos. 2009. 87 f. Dissertação (Mestrado) - Pontifícia Universidade Católica de Minas Gerais, Belo Horizonte, 2009.

• SALES JÚNIOR, Ricardo J.; COELHO, Roberta. Preserving the Exception Handling Design Rules in Software Product Line Context: A Practical Approach. In: DEPENDABLE COMPUTING WORKSHOPS (LADCW), 2011 FIFTH LATIN-AMERICAN SYMPOSIUM ON, 5., 2011, Sao Jose Dos Campos. Preserving the Exception Handling Design Rules in Software Product Line Context: A Practical Approach. [S. l.]: Ladcw, 2011. p. 9 - 16.

• MORGAN, Clint; VOLDER, Kris De; WOHLSTADTER, Eric. A Static Aspect Language for Checking Design Rules. In: PROCEEDINGS OF THE 6TH INTERNATIONAL CONFERENCE ON ASPECT-ORIENTED SOFTWARE DEVELOPMENT, 6., 2007, [S. l.]. A Static Aspect Language for Checking Design Rules. [S. l.]: Aosd, 2007. p. 63 - 72.

• NOBRE, Márcio de Souza. VERIFICAÇÃO DE CONFORMAÇÃO DE REGRAS DE DESIGN DO TRATAMENTO DE EXCEÇÃO EM JAVA. 2014. 50 f. TCC (Graduação) - Curso de Engenharia de Software, Universidade Federal do Ceará, Quixadá, 2014.