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

Seminário que descreve um problema comum no desenvolvimento de software, que é o caso da degradação arquitetural, e os seus principais fatores, citando como o principal deles, a escolha do desenvolvedor de tomar decisões próprias durante o processo de implementação. O seminário também um sugere uma possível solução que une processo e ferramentas, criando uma nova metodologia de verificação de software.

Transcript

1. Verificação de Conformação de Regras de Design Márcio Souza Laércio Germano
2. Conceitos •Arquitetura de software •Conformação arquitetural •Regras de design
3. 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).
4. 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)
5. Regra de Design “Definem padrões arquitetônicos que devem ser rigorosamente seguidas em todas as fases do ciclo de vida do software.” (JÚNIOR; COELHO, 2011) “Expressam restrições sobre o comportamento e a estrutura do programa.” (MORGAN; VOLDER; WOHLSTADER, 2007)
6. 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.
7. 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.
9. Uma possível solução Verificações constantes são um meio de “colocar nos trilhos”, aqueles desenvolvedores que ignoram decisões de projeto.
10. 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....
11. Degradação Arquitetural
12. 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.
13. Crescimento de desvios a cada versão do sistema 2 4 8 16 32 64 0 10 20 30 40 50 60 70 1 2 3 4 5 6 Desvio Arquitetural Versões
14. Por que mesmo com um projeto bem construído, os desenvolvedores ainda tendem a ignorá-lo e inserir desvios no código?
15. É mais fácil colocar a especificação de acordo com o programa, que vice-versa.
16. Como realizar a verificação de conformação de regras das design?
17. Que ferramentas existem? • DCL • LDM • .QL • Design Wizard (DW) • Design Rules For Exception Handling (DR4EH) • PMD • FindBugs
18. 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.
19. 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.
20. 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.
21. 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.