Detecção de problemas de design em aplicações Model-Template-View

Universidade Federal do Rio Grande do Norte Instituto Metrópole Digital

Programa de Pós-graduação em Engenharia de Software

Mestrado Profissional em Engenharia de Software

Detecção de Problemas de Design em

Aplicações Model-Template-View

Renieri Rayron da Silva Correia

Natal-RN Dezembro de 2018

Renieri Rayron da Silva Correia

Detecção de Problemas de Design em Aplicações

Model-Template-View

Dissertação apresentada ao Programa de Pós-graduação em Engenharia de Software da Uni-versidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Engenharia de Software.

Universidade Federal do Rio Grande do Norte – UFRN Instituto Metrópole Digital – IMD

Programa de Pós-Graduação em Engenharia de Software

Orientador: Dr. Eiji Adachi Medeiros Barbosa

Natal/RN

2018

Correia, Renieri Rayron da Silva.

Detecção de problemas de design em aplicações Model-Template-View / Renieri Rayron da Silva Correia. - 2018.

100 f.: il.

Dissertação (mestrado profissional) - Universidade Federal do Rio Grande do Norte, Instituto Metrópole Digital, Programa de Pós-Graduação em Engenharia de Software. Natal, RN, 2018. Orientador: Prof. Dr. Eiji Adachi Medeiros Barbosa.

1. Arquitetura de Software - Dissertação. 2. Padrão

Arquitetural - Dissertação. 3. Problema de Design - Dissertação. 4. Django - Dissertação. 5. Model-Template-View - Dissertação. 6. SUAP - Dissertação. I. Barbosa, Eiji Adachi Medeiros. II. Título.

RN/UF/BCZM CDU 004.41

Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede

Agradecimentos

À Deus, autor e consumador da minha fé.

À minha família, com carinho especial a minha esposa e filha, e aos meus pais Ao Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte por viabilizar a realização do mestrado junto a um centro de excelência como o Instituto Metrópole Digital.

Ao professor Eiji Adachi pela orientação e partilha do saber que possibilitou a realização de um trabalho de qualidade.

Aos profissionais que colaboraram na validação do catálogo proposto. Aos colegas de trabalho do IFRN pelo apoio nesta caminhada.

Resumo

A arquitetura de software retrata um conjunto de decisões de design, geralmente tomadas antes da implementação do sistema, com o objetivo de alcançar níveis desejados de atributos de qualidade de software. Um padrão arquitetural fornece um conjunto de decisões de design específicas que são aplicáveis a problemas de design recorrentes. A quebra dessas decisões, além de impactar negativamente nos atributos de qualidade de software, podem levar o sistema a iniciar um processo de degradação arquitetural. O padrão arquitetural Model-Template-View (MTV), implementado pelo framework Django, contém um conjunto de decisões tomadas para incentivar o baixo acoplamento e a separação rigorosa entre as partes da aplicação. No entanto, no processo de evolução da aplicação, decisões de design podem ser quebradas. Nesse sentido, investigamos a detecção de problemas de design relacionados ao padrão arquitetural MTV com o objetivo de manter os níveis desejados de qualidade de aplicações MTV. As principais contribuições deste trabalho foram a elaboração de um catálogo de problemas de design específicos do padrão arquitetural MTV e a construção de uma ferramenta para detecção automatizada destes problemas através da análise estática. O catálogo e a ferramenta de detecção foram validados no contexto do Sistema Unificado de Administração Pública (SUAP) desenvolvido pelo Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte – IFRN.

Palavras-chave: Arquitetura de Software, Padrão Arquitetural, Problema de Design, Django, Model-Template-View, SUAP.

Abstract

The software architecture depicts a set of design decisions, usually taken before the system implementation, with the aim of reaching desired levels of software quality attributes. An architectural pattern provides a set of specific design decisions that are applicable to recurring design problems. The noncompliance with these decisions, besides negatively impacting the attributes of software quality, can lead the software to initiate a process of architectural degradation. The architectural Model-Template-View (MTV) pattern, implemented by Django framework, contains a set of decisions taken to encourage low coupling and strict separation between the parts of the application. However, in the process of application evolution, design decisions may be broken. In this sense, we investigate the detection of design problems related to the MTV architectural pattern with the aim of keeping the desired levels of quality of MTV applications. The main contributions of this work were the definition of a catalog of design problems specific to the MTV architectural pattern and the construction of a tool for automated detection of these problems based on static analysis. The catalog and the detection tool were validated in the context of the Sistema Unificado de Administração Pública (SUAP) developed by Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte – IFRN.

Keywords: Software Architecture, Architectural Pattern, Design Problem, Django,

Lista de ilustrações

Figura 1 – Padrão arquitetural MVC . . . 20

Figura 2 – MVC e MTV . . . 23

Figura 3 – Padrão arquitetural MTV . . . 24

Figura 4 – Exemplo de Meddling View . . . 26

Figura 5 – Exemplo de Meddling Model . . . 27

Figura 6 – Exemplo de Improper Use of Manager . . . 28

Figura 7 – Exemplo de Brain Repository Method . . . 29

Figura 8 – Exemplo de Laborious Repository Method . . . 31

Figura 9 – Diagrama de Componentes. . . 40

Figura 10 – Diagrama de Classes . . . 41

Figura 11 – Fluxo de Comunicação da MTVChecker . . . 42

Lista de tabelas

Tabela 1 – Perfil dos Participantes. . . 33

Tabela 2 – Impacto nos Atributos de Qualidade de Software . . . 36

Tabela 3 – Métodos de Visitação Implementados . . . 43

Tabela 4 – Lista de Operadores do SQL. . . 48

Tabela 5 – Tamanho dos Módulos Selecionados . . . 52

Tabela 6 – Problemas de Design Detectados Manualmente . . . 53

Tabela 7 – Problemas de Design Detectados Automaticamente . . . 53

Tabela 8 – Contagem de Falsos Positivos e Negativos . . . 54

Tabela 9 – Métricas Precision, Recall e F-measure . . . 56

Tabela 10 – Comparativo dos Catálogos . . . 60

Tabela 11 – Quartis das Complexidades dos Métodos . . . 63

Tabela 12 – Thresholds do Brain Repository Method . . . 64

Tabela 13 – Problemas de Design Detectados . . . 64

Lista de abreviaturas e siglas

ANTLR ANother Tool for Language Recognition

API Application Programming Interface

AST Abstract Syntax Tree

CSV Comma-Separated Values

HTML HyperText Markup Language

IDE Integrated Development Environment

IFRN Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte

MTV Model-Template-View

MVC Model-View-Controller

PyPI Python Package Index

SQL Structured Query Language

SUAP Sistema Unificado de Admnistração Pública

UML Unified Modeling Language

Sumário

3 PROBLEMAS DE DESIGN EM APLICAÇÕES MTV . . . 25

3.1 Catálogo . . . 25

3.1.1 Meddling View (Visão Intrometida) . . . 25

3.1.2 Meddling Model (Modelo Intrometido) . . . 26

3.1.3 Improper Use of Manager (Uso Indevido de Manager). . . 27

3.1.4 Brain Repository Method (Método de Repositório Complexo). . . 29

3.1.5 Laborious Repository Method (Método de Repositório Trabalhoso) . . . 30

3.2 Validação . . . 32

3.2.1 Metodologia . . . 32

3.2.2 Resultados . . . 33

3.2.3 Ameaças à Validade . . . 37

4 MTVCHECKER . . . 39

4.1 Levantamento do Estado da Prática . . . 39

4.2 Visão Arquitetural . . . 40

4.3 Implementação . . . 43

4.3.1 Meddling View . . . 43

4.3.2 Meddling Model . . . 44

4.3.4 Brain Repository Method . . . 47

4.3.5 Laborious Repository Method . . . 50

4.4 Validação . . . 51 4.4.1 Resultados . . . 52 4.4.2 Ameaças à Validade . . . 56 5 TRABALHOS RELACIONADOS . . . 57 6 ESTUDO DE CASO . . . 62 6.1 Versionamento do SUAP . . . 62 6.2 Configuração da MTVChecker . . . 63 6.3 Thresholds . . . 63 6.4 Execução. . . 64 6.5 Refatoração . . . 65

6.5.1 Refatoração de um Meddling View . . . 65

6.5.2 Refatoração de um Meddling Model . . . 66

6.5.3 Refatoração de um Improper Use of Manager . . . 68

6.5.4 Refatoração de um Brain Repository Method . . . 69

6.5.5 Refatoração de um Laborious Repository Method . . . 72

7 CONSIDERAÇÕES FINAIS . . . 75

7.1 Principais Contribuições . . . 75

7.2 Trabalhos Futuros . . . 76

REFERÊNCIAS . . . 78

APÊNDICES

81

APÊNDICE B – RESPOSTAS DO QUESTIONÁRIO E TRANS-CRIÇÃO DOS ÁUDIOS DA ENTREVISTA . . . . 93

11

1 Introdução

A arquitetura de software retrata um conjunto de decisões de design tomadas sobre o sistema. (TAYLOR; MEDVIDOVIC; DASHOFY,2010). Estas decisões prescrevem como o software deve ser implementado para que atenda às necessidades dos seus stakeholders. Abrangendo diversos aspectos do sistema, decisões de design descrevem a estrutura da aplicação, o comportamento funcional, a interação entre elementos e decisões relacionadas a implementação e propriedades não-funcionais (TAYLOR; MEDVIDOVIC; DASHOFY,

2010).

Ao longo de sua evolução, a arquitetura do software pode decair devido à introdução de problemas de design. Um problema de design surge de uma ou mais decisões de design que, quando implementadas no código-fonte, afetam negativamente os atributos de qualidade de software (SOUSA et al.,2018). Atributos de qualidade de software são uma forma de mensurar objetivamente a qualidade de um sistema. Eles indicam o quanto a aplicação satisfaz as necessidades de seus stakeholders (CERVANTES; KAZMAN, 2016).

Na concepção da arquitetura de software, padrões arquiteturais são selecionados objetivando resolver problemas de design frequentes reconhecidos pela comunidade. Assim, padrão arquitetural é uma coleção de decisões de design que são aplicáveis a um problema de design recorrente, parametrizado para considerar diferentes contextos de desenvolvimento de software nos quais esse problema aparece (TAYLOR; MEDVIDOVIC; DASHOFY,2010). Apesar disto, decisões de design de padrões arquiteturais mal implementadas também podem resultar em problemas de design.

Problemas de design podem ser reconhecidos por meio da identificação de anomalias de código. Anomalias de código são estruturas de implementação que possivelmente indicam um problema de design (MACIA et al.,2012). Na literatura, anomalias de código também são chamadas de bad smell, code smell, architectural smell e anomalia de modularidade (LIPPERT; ROOCK,2006; MACIA et al., 2012; FOWLER, 1999; GARCIA et al., 2009).

Elas denotam um sintoma de projeto ou implementação deficiente que afeta negativamente as propriedades de um sistema de software e por vezes passam despercebidos pela equipe de desenvolvimento e, quando não detectados, podem inviabilizar a evolução do software.

1.1

Motivação

Reconhecer problemas de design presentes no código fonte e tratá-los contribui para a evolução do software de forma sustentável (RAJLICH; BENNETT,2000). Contudo, a cada alteração de código é possível que algum problema de design seja inserido na aplicação.

Capítulo 1. Introdução 12

Estes problemas podem ocorrer devido a vários fatores, entre eles: o desconhecimento dos programadores quanto às decisões arquiteturais; documentação da arquitetura desatu-alizada ou incompleta; requisitos conflitantes; prazos curtos; ou limitações tecnológicas (PASSOS et al.,2010; MIRANDA; VALENTE; TERRA, 2015).

O uso de catálogos que identificam problemas de design relacionados às decisões arquiteturais tem sido empregado para sanar estes problemas (MELO; SEREY; VA-LENTE, 2014; MIRANDA; VALENTE; TERRA, 2015; ANICHE et al., 2017; VELASCO-ELIZONDO et al., 2017). Mas, mesmo com estes catálogos disponíveis, a identificação manual é custosa e pouco eficiente. Além do mais, a identificação de um único problema de design pode se transformar rapidamente em uma tarefa muito complexa (SOUSA et al., 2018). Quando realizada manualmente através da simples leitura de código, estes problemas podem ser localizados com dificuldade ou até mesmo não serem percebidos. Logo, o uso de ferramentas de análise de código fonte são importantes no apoio à detecção de problemas de design já que, sem as devidas correções, o acúmulo destes problemas tendem a crescer com o passar do tempo, de modo que, a prevalência de problemas de design causem o redesenho ou mesmo a descontinuidade de sistemas de software (SOUSA et al., 2018).

Além disso, em pesquisa realizada no estado da arte não foram encontradas dis-cussões sobre problemas de design que afetam negativamente a qualidade de aplicações que utilizem o padrão arquitetural Model-Template-View – MTV. Alvo desta dissertação, este padrão, implementado pelo framework de desenvolvimento web Django na linguagem Python, carece de ferramentas arquiteturais que verifiquem nas aplicações a existência de problemas relacionados às decisões arquiteturais do padrão MTV.

1.2

Problema de Pesquisa

A presença de problemas de design é um indicativo de que a arquitetura de software pode estar sofrendo um processo de degradação. A degradação arquitetural ocorre quando a implementação não está em conformidade com as decisões de design retratadas na arquitetura de software (TAYLOR; MEDVIDOVIC; DASHOFY, 2010). A longevidade de uma aplicação em evolução depende em grande parte de sua resiliência aos sintomas de degradação da arquitetura (MACIA et al., 2012). Logo, atributos de qualidade de software em uma aplicação com arquitetura degradada podem se deteriorar e inviabilizar a continuidade do sistema. Por isso é importante dispor de mecanismos que identifiquem possíveis problemas de design.

O padrão arquitetural MTV prescreve um conjunto de decisões de design que, por exemplo, incentivam o fraco acoplamento e a separação rigorosa das responsabilidades da aplicação, com o intuito de promover maior reúso. No entanto, quando estas decisões são

Capítulo 1. Introdução 13

implementadas de forma inapropriada, os benefícios providos pelo padrão arquitetural são reduzidos podendo impactar negativamente na qualidade do sistema desenvolvido. Apesar deste padrão possuir regras bem definidas que devem ser seguidas pelos desenvolvedores, não encontramos na literatura estudo que catalogue problemas de design relativos à implementações inadequadas das suas decisões de design.

Portanto, no contexto desta dissertação, o primeiro problema de pesquisa investigado trata da falta de catálogos de problemas de design para o padrão arquitetural MTV. Catálogos que relatam problemas de implementação no padrão arquitetural MVC, a experiência do autor desta dissertação no desenvolvimento do SUAP, sistema implementado com Django, e o próprio código fonte do sistema serviram de inspiração na proposição de um catálogo para o padrão arquitetural MTV.

Apesar do padrão arquitetural MTV ser similar ao padrão arquitetural MVC, diferenças de como um padrão arquitetural é implementado por cada framework dificultam a reutilização de catálogos MVC.Aniche et al.(2017) apresentam um catálogo de problemas aplicados a projetos implementados com Spring MVC, framework MVC em Java. Velasco-Elizondo et al. (2017) apresentam outro catálogo de problemas MVC aplicados a projetos desenvolvidos com Yii, framework MVC em PHP. Ambos catálogos apresentam problemas e estratégias de detecção bem definidas para o contexto dos seus frameworks. Em nosso contexto, além de adaptações nas estratégias de detecção, algumas definições de problemas do padrão arquitetural MVC não são aplicáveis ao padrão arquitetural MTV, por exemplo, problemas relacionados à camada Controller. No contexto do padrão arquitetural MTV a reponsabilidade desta camada é executada pelo próprio framework Django. Mais detalhes dos padrões arquiteturais MVC e MTV serão apresentados no Capítulo2desta dissertação.

O segundo problema de pesquisa investigado aborda como detectar automatica-mente estruturas de código definidas como problemáticas no catálogo proposto. Um modo de detectar problemas de design no código é através da identificação de estruturas de código que indicam problemas comuns relacionados a padrões arquiteturais (GARCIA et al., 2009; ANICHE et al., 2017; VELASCO-ELIZONDO et al., 2017). Para isso será realizada análise estática do código fonte. Além da proposição de um catálogo de problemas de design em aplicações que seguem o padrão arquitetural MTV é necessário automatizar a checagem do código em busca destes problemas.

1.3

Objetivos de Pesquisa

O objetivo de pesquisa geral deste trabalho é:

Apoiar a detecção de problemas de design que afetam negativamente atributos de qualidade de software em aplicações MTV.

Capítulo 1. Introdução 14

São ainda objetivos de pesquisa específicos deste trabalho:

• Identificar as decisões de design do padrão arquitetural MTV seguido pelo framework Django.

• Propor catálogo que defina problemas de implementação das decisões de design do padrão arquitetural MTV.

• Automatizar processo de detecção de problemas de design por meio da análise estática.

• Realizar análise situacional da implementação do SUAP quanto à existência dos problemas de design propostos.

1.4

Solução Proposta

Esta dissertação abordará a verificação do código fonte de aplicações que seguem o padrão arquitetural MTV em busca de problemas de design que possam afetar negati-vamente os atributos de qualidade de software. Avaliaremos o impacto nos atributos de qualidade definidos pela norma ISO/IEC 25010. Aplicações MTV, isto é, implementadas com o framework Django, serão analisadas e possíveis violações inseridas durante a sua evolução poderão ser reveladas aos membros da equipe. Para viabilizar tal análise foi proposto um catálogo de problemas de design característicos do MTV.

Este catálogo, que servirá de referência para a equipe de desenvolvimento, descreve os problemas de design, as estratégias de detecção e sugere como refatorar o código a fim de removê-los do sistema. Espera-se que com a realização sistemática de verificações no código seja exposto se, de fato, há problemas de design na implementação das decisões do padrão arquitetural MTV e onde eles estão localizados, desse modo, revelando os locais do sistema que podem estar prejudicando a qualidade do software.

1.5

Contribuições

Esta dissertação apresenta como principais contribuições:

• Um catálogo de problemas de design que afetam aplicações web desenvolvidas com o framework Django baseado no padrão arquitetural MTV.

• Estratégias de detecção para cada um dos problemas de design catalogados.

• Uma ferramenta chamada de MTVChecker para automatizar a detecção dos proble-mas de design catalogados.

Capítulo 1. Introdução 15

• Proposição de estratégias de refatoração a fim de sanar os problemas de design identificados.

• Resultado de um estudo empírico sobre a ocorrência dos problemas de design propostos no contexto de um sistema de larga escala.

1.6

Metodologia

Nesta seção são apresentados os procedimentos adotados para alcançar o objetivo geral deste trabalho.

Revisão da literatura. Para identificar as decisões de design do padrão

arqui-tetural MTV e investigar formas de análise estática em sistemas Python foi realizado revisão da literatura em busca de publicações que abordam o framework Django, o padrão arquitetural MTV e como ferramentas de análise de código realizam a verificação do código fonte. Também foi realizado revisão da literatura para identificar catálogos do padrão arquitetural MVC, padrão que possui regras semenhantes ao do padrão arquitetural MTV.

Questionário e Entrevista. Foi aplicado questionário e entrevista com

especia-listas da área para validar o catálogo proposto. A validação teve como objetivo validar os conceitos definidos no catálogo e verificar se os problemas de design catalogados impactam negativamente nos atributos de qualidade de software buscando identificar o grau de impacto em cada atributo de qualidade.

Estudo de caso. Para automatizar o processo de detecção de problemas de design do padrão arquitetural MTV e aplicá-la em sistemas reais foi realizado estudo de caso no SUAP. Para isso foi proposto uma ferramenta que realiza a verificação do código fonte por meio da análise estática em busca de violações do padrão arquitetural MTV no código implementado do SUAP. Para auxiliar a implementação da ferramenta foi utilizado o ambiente de desenvolvimento Eclipse e para realizar a análise estática do código fonte foi utilizado a biblioteca AST, nativa na linguagem Python. A ferramenta analisa as camadas do sistema e disponibiliza relatório informando o problema de design e sua localização.

1.7

Contexto

Desde 2016 o autor desta dissertação tem trabalhado na equipe de desenvolvimento do Sistema Unificado de Administração Pública – SUAP, que é desenvolvido pelo Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte – IFRN. Lançado em 2007, presente em 32 instituições em todo Brasil e em pleno desenvolvimento, o SUAP vem ao longo dos anos recebendo atualizações para resolução de falhas, adição de novas funcionalidades, melhorias de funcionalidades existentes além da criação de novos módulos para atender a processos que ainda não foram informatizados.

Capítulo 1. Introdução 16

Mantido por uma equipe de 20 desenvolvedores do IFRN e abrangendo aproxima-damente 230 mil linhas de código Python e mais de 100 mil linhas de código HTML, o SUAP possui 59 módulos distintos que gerenciam diversos processos nas áreas de gestão de pessoas, gestão acadêmica, gestão de contratos, gestão orçamentária, central de serviços e outros. De acordo com o Ministério do Planejamento, ele atende ou supera as expectativas em mais de 96% dos órgãos que o utilizam1.

A fim de manter o alto grau de satisfação de seus usuários, mecanismos de controle da qualidade de código são adotados pela equipe. No entanto, algumas características do ambiente de desenvolvimento do SUAP podem prejudicar a manutenção e evolução do sistema. Em um cenário em que a seleção da equipe se dá por meio de concurso público, sendo comum que novos desenvolvedores tenham pouco ou nenhum conhecimento sobre Python e Django (ambos utilizados no SUAP), somado a ausência de documentação que especifique as decisões arquiteturais do SUAP e a carência de um treinamento formal sobre os padrões arquiteturais e de projeto adotados no sistema favorecem a introdução de possíveis problemas de design.

A checagem do código é outro ponto crítico no SUAP. Atualmente, ela é realizada de forma manual por analistas experientes que revisam as alterações de código submetidas por outros desenvolvedores. No entanto, o número de analistas responsáveis pela inspeção não é suficiente para revisar todas as alterações. Desta forma, é comum que algumas alterações não sejam totalmente inspecionadas. Consequentemente, este tipo de análise pode ser falha e resultar na introdução de problemas de design no decorrer das manutenções.

A ausência de formas sistemáticas de checagem das decisões arquiteturais dificulta a identificação e remoção de problemas de design no código fonte. A baixa percepção da presença destes problemas podem afetar negativamente atributos de qualidade do sistema, potencialmente reduzindo sua vida útil. Portanto, para que o SUAP possa ser mantido e evoluído de maneira contínua, é necessário prover mecanismos de checagem do código fonte a fim de analisar se ele está em conformidade com os padrões adotados, desse modo, mantendo os níveis de qualidade desejados para a aplicação.

1.8

Estrutura do Documento

Os demais tópicos deste trabalho contemplam: Capítulo 2 - Referencial teórico contendo as definições necessárias para compreensão dos temas discutidos. Capítulo 3 -Catálogo proposto de problemas de design em aplicação MTV. Capítulo 4 - A MTVChecker, ferramenta desenvolvida para detecção dos problemas de design. Capítulo 5 - Trabalhos relacionados. Capítulo 6 Estudo de caso realizado no sistema SUAP. E Capítulo 7 -Considerações finais.

17

2 Referencial Teórico

Neste capítulo, serão apresentados os conceitos básicos que embasam a presente dissertação, são eles: Arquitetura de Software (seção 2.1); Qualidade de Software (seção

2.2); Padrão Arquitetural MVC (seção 2.3); Framework Django (seção 2.4); e Padrão Arquitetural MTV (seção 2.5).

2.1

Arquitetura de Software

A arquitetura de software retrata um conjunto de decisões fundamentais de design feitas sobre o sistema, ou em outras palavras, é o modelo para a construção e evolução de um sistema de software (TAYLOR; MEDVIDOVIC; DASHOFY, 2010). Em geral, ela envolve a descrição de elementos a partir dos quais os sistemas são construídos, interações entre esses elementos, padrões que orientam sua composição, e também, restrições a esses padrões (SHAW; GARLAN, 1996).

Considerada um dos artefatos mais importantes no ciclo de vida de uma aplicação, uma arquitetura bem projetada é fator importante na determinação do sucesso do software (SHAW; GARLAN,1996). Portanto, ao projetá-la, é desejado, por exemplo, que certos níveis de reusabilidade, interoperabilidade, escalabilidade e manutenibilidade sejam atingidos. Logo, garantir a aderência ao projeto arquitetural aumenta as chances do software de fato alcançar estes objetivos.

Design é um conjunto de decisões tomadas para satisfazer requisitos e restrições do sistema (CERVANTES; KAZMAN, 2016). O planejamento da arquitetura de software envolve decisões de design explícitas sobre a seleção de componentes, suas interações e as restrições relacionadas a eles. Na arquitetura de software, componente é definido como uma entidade que encapsula um subconjunto de funcionalidades que possui interfaces bem definidas como ponto único de acesso a elas (TAYLOR; MEDVIDOVIC; DASHOFY,

2010). O resultado deste planejamento é a criação da arquitetura pretendida.

Decisões de design, geralmente, tomadas antes da construção do sistema (SHAW; GARLAN, 1996) abrangem todos os aspectos do software em desenvolvimento (TAYLOR; MEDVIDOVIC; DASHOFY, 2010). Elas estão relacionadas com o domínio de aplicação, estilos e padrões arquiteturais, componentes e outras seleções de infraestrutura, além de outros aspectos necessários para satisfazer os requisitos do sistema. (JANSEN; BOSCH,

2005).

Influenciando diretamente os atributos de qualidade de software, decisões de de-sign não intencionais são a causa da maioria dos problemas de dede-sign (SOUSA et al.,

Capítulo 2. Referencial Teórico 18

2018). Problema de design é o resultado de uma ou mais decisões de design que, quando implementadas inadequadamente, impactam negativamente nos atributos de qualidade de software (SOUSA et al.,2018). Uma forma de mitigar estes problemas se dá por meio da adoção de padrões arquiteturais.

Padrão arquitetural é uma coleção de decisões de design arquiteturais que são aplicáveis a um problema de design recorrente, parametrizado para considerar diferentes contextos de desenvolvimento de software nos quais esse problema aparece (TAYLOR; MEDVIDOVIC; DASHOFY, 2010). Alguns padrões representam soluções conhecidas para problemas de desempenho, outros buscam resolver problemas ligados à segurança ou a alta disponibilidade. A escolha de um padrão arquitetural é frequentemente a primeira grande escolha de design do arquiteto (BASS; CLEMENTS; KAZMAN, 2003).

O sistema construído a partir das restrições e padrões impostos pela arquitetura de software, isto é, o código fonte gerado pela equipe de desenvolvimento corresponde à arquitetura implementada. Para de fato o software alcançar os objetivos traçados na concepção da arquitetura é desejado que a arquitetura implementada possa ser uma realização idêntica do que foi especificado na arquitetura pretendida.

2.2

Qualidade de Software

Sistemas de software são afetados por problemas comuns que impactam negativa-mente na sua qualidade, por exemplo, dificuldade para compreender e modificar o código, dificuldade no uso da aplicação ou dificuldade de integrá-la com outros sistemas (BOEHM; BROWN; LIPOW, 1976). A qualidade de software é medida pelo grau no qual o sistema satisfaz as necessidades declaradas e implícitas de seus vários stakeholders e, portanto, que fornece valor (ISO/IEC. . ., ). Como a qualidade tende a ser um conceito subjetivo em si, atributos de qualidade permitem que ela seja expressa de forma sucinta e objetiva.

Atributos de qualidade são definidos como sendo propriedades mensuráveis ou testáveis de um sistema que são usados para indicar o quanto o sistema satisfaz as necessi-dades de seus stakeholders (CERVANTES; KAZMAN, 2016). Um modelo de qualidade de software fornece um conjunto de atributos mensuráveis com o propósito de medir a qualidade do produto desenvolvido. A norma ISO/IEC 25010 define um modelo de quali-dade que classifica os atributos de qualiquali-dade em oito características. São elas: adequação funcional, compatibilidade, confiabilidade, eficiência de desempenho, manutenibilidade, portabilidade, segurança e usabilidade.

Adequação Funcional. Mede o grau em que um produto ou sistema fornece funções que atendem às necessidades declaradas e implícitas quando usadas sob condições especificadas.

Capítulo 2. Referencial Teórico 19

Compatibilidade. Mede o grau para o qual um produto, sistema ou componente

pode trocar informações com outros produtos, sistemas ou componentes e / ou executar suas funções necessárias, enquanto compartilha o mesmo ambiente de hardware ou software.

Confiabilidade. Mede o grau para o qual um sistema, produto ou componente

executa funções especificadas sob condições especificadas por um período de tempo especificado.

Eficiência de Desempenho. Mede o grau de desempenho em relação à quantidade

de recursos usados sob condições declaradas.

Manutenibilidade. Mede o grau de eficácia e eficiência com o qual um produto

ou sistema pode ser modificado para melhorá-lo, corrigi-lo ou adaptá-lo a mudanças no ambiente e nos requisitos.

Portabilidade. Mede o grau de eficácia e eficiência com o qual um sistema,

produto ou componente pode ser transferido de um hardware, software ou outro ambiente operacional ou de uso para outro.

Segurança. Mede o grau em que um produto ou sistema protege as informações e os dados para que as pessoas ou outros produtos ou sistemas tenham o grau de acesso aos dados adequado aos seus tipos e níveis de autorização.

Usabilidade. Mede o grau em que um produto ou sistema pode ser usado por

usuários específicos para atingir objetivos específicos com eficácia, eficiência e satisfação em um contexto específico de uso.

2.3

Padrão Arquitetural MVC

O Model-View-Controller – MVC – é um padrão arquitetural criado pela Xerox PARC nos anos 70. Caracterizado pelo baixo acoplamento, aumento da flexibilidade e da reutilização dos objetos (GAMMA,1994), ele é amplamente adotado como uma arquitetura para o projeto e a implementação de sistemas da web (VELASCO-ELIZONDO et al.,

2017).

Neste padrão, a aplicação é dividida em camadas. Elementos da camada Model contém as regras da aplicação, elementos da camada View representam a interface com o usuário e elementos da camada Controller definem a maneira como a interface com o usuário deve reagir à entrada de dados (GAMMA,1994).

Muito rígida sobre o que cada camada faz (RAVINDRAN, 2015), o padrão ar-quitetural MVC contém um conjunto de restrições para garantir a qualidade do código produzido (ANICHE; GEROSA,2015). Seu valor se baseia em duas regras essenciais: a se-paração entre modelo e apresentação; e a sese-paração entre visão e controlador (MADEYSKI; SOCHMIALEK,2005). A primeira permite que a interface do usuário seja alterada sem

Capítulo 2. Referencial Teórico 20

modificar a lógica da aplicação. A segunda, viabiliza a existência de várias rotas para a mesma visão, por exemplo: um controle de cadastro e outro de edição podem utilizar a mesma visão.

A camada Model especifica os dados e o comportamento da aplicação. Elementos desta camada não tem conhecimento de nada sobre o que ocorre nas camadas View e Controller (MADEYSKI; SOCHMIALEK, 2005). Regras de negócio da aplicação devem

ser mantidas nesta camada.

A camada View é responsável apenas por exibir os dados para o usuário final (ANICHE; GEROSA, 2015). Ela deve assegurar que sua aparência reflita o estado do modelo (GAMMA, 1994). Sua implementação é fortemente acoplada às classes do modelo, pois ela deve estar ciente da especificidade dos dados apresentados ou dos resultados da operação (MADEYSKI; SOCHMIALEK,2005).

O padrão arquitetural MVC encapsula o mecanismo de resposta às interações do usuário em elementos da camada Controller (GAMMA, 1994). O Controller não deve conter regras de negócio, ele deve apenas controlar o fluxo entre as camadas Model e View (ANICHE; GEROSA,2015). Sua principal responsabilidade é reagir às ações dos usuários (MADEYSKI; SOCHMIALEK, 2005).

A Figura 1 exibe uma representação conceitual do padrão arquitetural MVC. Figura 1 – Padrão arquitetural MVC

Conforme visto na Figura1a camada controller encapsula a semântica de interação entre usuário e aplicação, isto é, ela recebe requisições do usuário e controla o fluxo de comunicação entre as camada model e view. A camada model encapsula os dados da aplicação, ou seja, entidades, regras de negócio, acesso à base de dados são realizadas nesta camada. A camada view possui a lógica de apresentação encapsulando as decisões de como os dados devem ser visualizados pelos usuários.

De forma resumida, no padrão arquitetural MVC as responsabilidades são dividas da sequinte forma:

Capítulo 2. Referencial Teórico 21

• View: Responsável pela apresentação dos dados (GAMMA, 1994). É a parte do sistema que seleciona quais dados exibir e como exibí-los (HOLOVATY; KAPLAN-MOSS,2009).

• Controller : Define a maneira como a interface do usuário deve reagir às ações dele (GAMMA, 1994). Ela refere-se à parte do sistema que decide qual visão usar acessando o modelo conforme necessário (HOLOVATY; KAPLAN-MOSS, 2009).

2.4

Framework Django

Listado entre os frameworks de alto nível mais populares (WEBFRAMEWORKS. . ., ), Django é um framework desenvolvido na linguagem Python projetado para incentivar o baixo acoplamento e a separação rigorosa entre partes de uma aplicação (HOLOVATY; KAPLAN-MOSS,2009). Para prover esses benefícios ele implementa um padrão arquite-tural chamado de Model-Template-View – MTV.

Visando proporcionar o rápido desenvolvimento de aplicações web, fornece au-tomaticamente uma poderosa API de abstração de banco de dados que permite criar, recuperar, atualizar e excluir objetos; fornece uma lógica de templates que separa a lógica da apresentação; desencoraja a redundância; e encoraja a simplicidade e as melhores práticas.

Apesar do padrão arquitetural MTV ser bastante similar ao padrão arquitetural MVC, o Django adotou o acrônimo MTV reforçando o fato de que a maior parte da codificação ocorre nas camadas Model, Template e View do referido framework. Além disso, o conceito de View definido pelo MVC sofre uma sutil variação no contexto do Django.

2.5

Padrão Arquitetural MTV

No contexto do padrão arquitetural MTV, a camada Model é responsável pelas regras de negócio e acesso a dados, ela contém todas as informações sobre estes dados: como acessá-los, como validá-los, seus comportamentos e relacionamentos entre si (HOLOVATY; KAPLAN-MOSS, 2009). Ela é uma abstração para estruturar e manipular os dados da aplicação web (DJANGO. . ., ) e implementa o padrão de projeto Active Record que encapsula o acesso ao banco de dados e adiciona lógica de domínio nesses dados (RAVINDRAN,2015;FOWLER, 2003).

As classes desta camada, chamadas de modelo, descrevem as tabelas do banco de dados e seus métodos mantém em um único lugar as regras de negócio da aplicação (HOLOVATY; KAPLAN-MOSS, 2009). Atributos de modelo, além de descrever as colunas das tabelas de banco de dados, podem representar conceitos de alto nível que o SQL necessariamente não controla. Por exemplo, a implementação interna de um atributo do

Capítulo 2. Referencial Teórico 22

tipo EmailField verifica se o valor preenchido é um e-mail válido antes de persistí-lo no banco de dados.

Embora seja possível escrever scripts de SQL para persistir ou consultar dados da aplicação, esta camada disponibiliza uma interface chamada manager que abstrai do desenvolvedor o uso de SQL, de modo que, operações básicas sejam executadas sem a necessidade de se escrever código SQL. Cada modelo tem um manager associado a ele por padrão. Porém, também é possível definir outros managers para criar consultas personalizadas de acesso a dados (HOLOVATY; KAPLAN-MOSS, 2009).

A camada Template descreve como a informação deve ser apresentada ao usuário. Ela contém texto estático, bem como uma sintaxe especial que descreve como o conteúdo dinâmico será inserido na saída desejada (DJANGO. . ., ). Normalmente são usadas para produzir texto em formato HTML, mas também podem gerar outros formatos baseado em texto como XML ou CSV (HOLOVATY; KAPLAN-MOSS, 2009).

Esta camada disponibiliza uma sintaxe amigável ao designer para renderizar a informação que será apresentada ao usuário (DJANGO. . ., ). Isso faz com que o desenvol-vedor frontend se preocupe apenas com a apresentação do sistema, ou seja, como exibir os dados. Desse modo, o layout da página é desacoplado do código Python. A lógica de quais dados mostrar é tratado pelo desenvolvedor backend na camada View.

A View é definida como uma chamada que aceita uma solicitação e retorna uma resposta (RAVINDRAN, 2015). Ela contém a lógica de acesso a elementos da camada Model e submete a resposta ao arquivo de template apropriado, ou seja, contém as regras de negócio para exibição da página (HOLOVATY; KAPLAN-MOSS, 2009). Elementos na camada View devem encapsular a lógica responsável pelo processamento do pedido de um usuário e pelo retorno da resposta (DJANGO. . ., ). Ela é a ligação entre Template e Model.

No padão arquitetural MTV a camada View, formada essencialmente por funções, descreve quais dados devem ser exibidos e normalmente delega para elementos da camada Template como esses dados devem ser exibidos para o usuário final. Enquanto que elementos da camada Model não devem ter conhecimento de quais dados ou como eles são exibidos. A Figura 2 relaciona as camadas do padrão arquitetural MVC com as camadas do padrão arquitetural MTV.

Capítulo 2. Referencial Teórico 23

Figura 2 – MVC e MTV

Conforme visto na Figura 2, o padrão arquitetural MTV é bem próximo do padrão arquitetural MVC. A camada Model de ambos padrões possuem responsabilidades equivalentes. A camada View do MVC, no padrão arquitetural MTV, é subdivido em Template (como exibir os dados) e View (quais dados exibir). A parte do Controller do padrão arquitetural MVC é manipulado pelo próprio framework Django. Dessa forma, para o desenvolvedor, a camada Controller está oculta e por isso o acrônimo MTV, que faz referência às camadas em que há maior esforço de programação, é adotado (HOLOVATY; KAPLAN-MOSS,2009).

De forma resumida o padrão arquitetural MTV diz que:

• Model: É a camada de acesso a dados. Ela contém tudo e qualquer coisa sobre os dados: como acessá-los, como validá-los, quais comportamentos ele possui e as relações entre os dados (HOLOVATY; KAPLAN-MOSS,2009).

• Template: É a camada de apresentação. Ela contém decisões relacionadas à apresen-tação, isto é, como algo deve ser exibido ao usuário (HOLOVATY; KAPLAN-MOSS,

2009).

• View: É a camada que contém a lógica de apresentação. Ela define quais dados devem ser apresentados (DJANGO. . ., ).

Capítulo 2. Referencial Teórico 24

Figura 3 – Padrão arquitetural MTV

Conforme visto na Figura3a partir de um requisição web, o framework Django, no papel de controller, seleciona a função da view que irá tratar a requisição do usuário. Esta função consulta classes de modelo – responáveis pela lógica de negócio e acesso à base de dados – e encaminha ao template apropriado os dados que devem ser exibidos. Por fim, o template formata como esses dados serão apresentados e a resposta é renderizada na tela do usuário.

25

3 Problemas de Design em Aplicações MTV

Os trabalhos deAniche et al. (2017) eVelasco-Elizondo et al. (2017), bem como a experiência do autor deste trabalho no desenvolvimento de aplicações baseadas no framework Django serviram de base para a proposição do catálogo de problemas de design relacionados ao padrão arquitetural MTV. Os trabalhos citados acima serão detalhados no Capítulo 5.

Nas seções a seguir, será apresentado o catálogo de problemas de design proposto nesta dissertação (Seção 3.1), bem como o processo de validação realizado (Seção 3.2).

3.1

Catálogo

O catálogo proposto nesta dissertação contém os seguintes problemas de design: Meddling View, Meddling Model, Improper Use of Manager, Brain Repository Method e Laborious Repository Method. Cabe relembrar que nesta dissertação, um problema de design é resultado de uma ou mais decisões de design que, quando implementadas inadequadamente, impactam negativamente nos atributos de qualidade de software. Nas seções a seguir, cada um destes problemas de design será apresentado em detalhes. Em particular, para cada problema de design, será apresentado sua definição conceitual, uma estratégia de detecção que operacionaliza a definição do problema e uma sugestão de refatoração para mitigar o problema de design descrito.

3.1.1

Meddling View (Visão Intrometida)

Definição. Uma visão que implementa funcionalidades de persistência.

No padrão arquitetural MTV espera-se que a camada de visão seja responsável por invocar classes e métodos da camada de modelo e definir quais dados devem estar disponíveis para apresentação na camada de template. Um Meddling View ocorre quando um elemento da camada de visão implementa funcionalidades de persistência, as quais deveriam ser responsabilidade de elementos da camada de modelo.

Consultas diretas ao banco de dados, seja através da implementação direta de SQLs, ou através de chamadas a APIs de persistência são considerados funcionalidades de persistência. Elementos da camada de visão devem conter apenas a lógica necessária para seleção dos dados que devem ser exibidos ao usuário final. Consultas SQL ou acesso a alguma API de persistência devem existir somente na camada de modelo. A Figura 4

Capítulo 3. Problemas de Design em Aplicações MTV 26

Figura 4 – Exemplo de Meddling View

A Figura4 apresenta um exemplo de uma função que pertence a camada de visão. De acordo com este exemplo, uma função na camada de visão implementa uma consulta de SQL e a executa. Tanto a elaboração do SQL quanto a execução da consulta deveriam ser realizadas na camada de modelo e não na camada de visão.

Atributos de qualidade mais impactados. Manutenibilidade, portabilidade e

compatibilidade.

Estratégia de detecção. Identificar a escrita de instruções SQL ou chamadas à

API de persistência do Django (django.db) nos elementos da camada de visão. A existência de pelo menos uma ocorrência de SQL ou uso da API nesta camada caracteriza a presença de Meddling View.

Sugestão de refatoração. Mover para a camada de modelo o código que faz

referência ao acesso a banco de dados.

3.1.2

Meddling Model (Modelo Intrometido)

Definição. Um modelo que contém regras de apresentação.

No padrão arquitetural MTV espera-se que a camada de modelo seja responsável pela manipulação dos dados da aplicação, isto é, a definição dos relacionamentos entre os dados, como eles devem ser persistidos e as regras de negócio devem estar nesta camada. Funcionadlidades relacionadas à forma como os dados serão apresentados não devem existir nesta camada, pois estas são responsabilidade da camada de template.

Um Meddling Model ocorre quando, na camada de modelo, houver algum elemento que implemente funcionalidades de apresentação. No contexto do Django, funcionalidades de apresentação são caracterizadas pela presença de elementos que manipulam ou retornam texto em formato HTML ou em outra linguagem de apresentação. A Figura 5 exibe um exemplo deste problema.

Capítulo 3. Problemas de Design em Aplicações MTV 27

Figura 5 – Exemplo de Meddling Model

A Figura 5 apresenta um exemplo de um método de uma classe que pertence à camada de modelo. De acordo com este exemplo, um método de uma classe na camada de modelo retorna uma texto com formatação HTML. Idealmente, este método deveria retornar um objeto, ou até mesmo uma string sem formatação, pois a responsabilidade de preparar/formatar os dados para apresentação é da camada de template, não da camada de modelo.

Atributos de qualidade mais impactados. Manutenibilidade, portabilidade, compatibilidade e segurança.

Estratégia de detecção. Localizar o uso de marcadores HTML no corpo dos

métodos, por exemplo, <html>, <body>, <table>, <p>, <div> e outros. Pelo menos uma ocorrência de marcadores HTML caracteriza a presença de Meddling Model.

Sugestão de refatoração. Modificar o código movendo para fora da camada de

modelo os fragmentos que utilizam marcadores HTML, preferencialmente, movendo-os para um arquivo da camada de template.

3.1.3

Improper Use of Manager (Uso Indevido de Manager)

Definição1. Um modelo que lida com managers de outros modelos não relacionados a ele.

Em aplicações web em camadas (ANICHE et al., 2017) usualmente toda a lógica de acesso a dados, isto é, operações de persistência e recuperação de dados são isoladas em uma camada de repositório. No entanto, no Django, não existe uma separação explícita de elementos que fazem parte desta camada, de modo que, o acesso a dados ocorre por meio de interfaces chamadas de managers.

No contexto do Django, Manager é a interface através da qual operações de consulta ao banco de dados são fornecidas aos modelos do padrão arquitetural MTV. Toda classe

1 _{Este problema de design foi apresentado como Excessive Manager Use na validação do catálogo. No} entanto, foi renomeado para Improper Use of Manager após correções da banca avaliadora.

Capítulo 3. Problemas de Design em Aplicações MTV 28

da camada de modelo possui pelo menos um manager associado a ela. Comumente, classes de modelo executam chamadas a um ou mais managers na construção dos dados durante o processamento da lógica de negócio.

Portanto, a fim de manter a alta coesão, a classe de modelo deve acessar apenas os seus próprios managers ou os managers de outras classes que se relacionam de forma direta com ela. Quando isso não acontece, a classe de modelo pode estar assumindo responsabilidades que não deveriam ser executadas por ela. Um Improper Use of Manager ocorre quando um elemento da camada de modelo acessa managers sem relação direta com ela própria, isto é, uma classe de modelo que lida com managers de outros modelos não relacionados a ela. A ocorrência de Improper Use of Manager indica que, apesar do código estar na camada correta, parte dele pode estar sendo executado na classe errada. A Figura 6exibe um exemplo deste problema.

Figura 6 – Exemplo de Improper Use of Manager

A Figura 6 apresenta um exemplo da classe Model_A que pertence a camada de modelo. Esta classe possui relacionamento com a classe Model_B, mas o método my_method acessa o manager (objetcs) da classe Model_C que não é um relacionamento de Model_A. Situações como esta podem ocasionar alguns problemas, por exemplo, forte acoplamento entre modelos (de forma desnecessária), duplicação da lógica de acesso a dados e baixa rastreabilidade dos impactos nas mudanças dos atributos de modelo, pois regras de acesso a dados, que deveriam estar concentradas no modelo original ou no conjunto de relacionamentos deste modelo, estão espalhadas em vários outros modelos.

Atributos de qualidade mais impactados. Manutenibilidade.

Estratégia de detecção. Identificar instâncias de Manager utilizadas pela classe de modelo e verificar a existência de algum manager que não foi definido pela própria classe de modelo ou por algum de seus relacionamentos de forma direta ou reversa. A ocorrência de pelo menos uma instância de Manager nesta situação caracteriza este problema de design.

Sugestão de refatoração. Mover parte da lógica que faz uso do manager

Capítulo 3. Problemas de Design em Aplicações MTV 29

mais próxima.

3.1.4

Brain Repository Method (Método de Repositório Complexo)

Definição. Um método que combina estruturas complexas de SQL e lógica de

negócio complexa.

Espera-se que as funcionalidades providas pela API de persistência do Django supram as necessidades básicas do desenvolvedor. Em situações em que estas funcionali-dades básicas não suprem necessifuncionali-dades específicas de uma aplicação, faz-se necessária a construção de scripts SQLs específicos. Tais scripts devem ser implementados em métodos da camada de modelo. Os métodos desta camada são responsáveis pela implementação da lógica de negócio da aplicação e, por este motivo, tendem a ser mais complexos. Por isso, métodos com comportamento explícito de repositório, isto é, que executam scripts SQL, podem conter lógica complexa. Desse modo, estruturas complexas de SQL podem se misturar à complexidade estrutural do próprio código e, consequentemente, tornar sua compreensão e manutenção mais difícil.

Um Brain Repository Method é encontrado em métodos que possuem estruturas de SQL. Ele ocorre quando essas estruturas são consideradas complexas e a própria lógica de negócio presente no método também é complexa. A Figura 7 exibe um exemplo deste problema.

Figura 7 – Exemplo de Brain Repository Method

A Figura7simula um exemplo de método que constrói uma estrutura complexa de SQL e também apresenta uma complexidade estrutural na implementação do seu código com vários caminhos independentes.

Capítulo 3. Problemas de Design em Aplicações MTV 30

Atributos de qualidade mais impactados. Manutenibilidade, portabilidade,

compatibilidade e segurança.

Estratégia de detecção. A complexidade de um método com comportamento de

repositório é calculada pela combinação de duas métricas. A primeira analisa a comple-xidade estrutural do método como um todo e a segunda métrica mede a complecomple-xidade estrutural do SQL.

Para determinar a complexidade estrutural do código utilizamos a métrica de complexidade ciclomática de McCabe. Ela mede a quantidade de caminhos de execução independentes que um código possui. Devida a falta de suporte de ferramentas e ausência de métricas na literatura que indiquem a complexidade estrutural de um SQL realizamos uma adaptação das métricas de Halstead.

De acordo com as métricas de Halstead, a quantidade de esforço necessária para gerar um programa pode ser derivada a partir da contagem simples de operadores (n1) e operandos (n2) distintos e do total de frequências destes operadores (N1) e operandos (N2) (CURTIS et al., 1979). Uma das métricas de Halstead visa medir a dificuldade do código; tal métrica é definida pela fórmula “n1/2 * N2/n2 ”. Esta métrica está relacionada com a dificuldade para escrever ou entender o código de um programa.

No nosso trabalho, adaptamos esta métrica para representar a dificuldade para escrever ou entender uma estrutura de SQL. Para isso definimos os operadores e operandos do SQL. Classificamos como operadores as palavras reservadas do SQL, por exemplo, select, update, join e union. O grupo dos operandos é formado pelas demais palavras presentes na estrutura SQL, por exemplo, nome de tabelas e colunas. A fórmula abaixo ilustra a estratégia de detecção de um problema do tipo Brain Repository Method.

[ (CS > MEDIA e CC > ALTA) ou (CS > ALTA e CC > MEDIA) ]

CSrepresenta a complexidade do SQL, CC representa a complexidade do código,

ALTA representa faixa de valores considerados de alta complexidade e MEDIA representa

faixa de valores considerados de média complexidade. Os valores de ALTA e MEDIA serão definidos empiricamente através da avaliação do código fonte e da análise da equipe responsável pela aplicação. Isto será apresentado e discutido em detalhes no Capítulo 4.

Sugestão de refatoração. Quebrar o método em métodos menores separando a

parte do código responsável pela construção ou execução do SQL do restante da lógica.

3.1.5

Laborious Repository Method (Método de Repositório Trabalhoso)

Idealmente, um método deve executar apenas uma ação explícita de repositório. No contexto do padrão arqutietural MTV definimos uma ação explícita de repositório

Capítulo 3. Problemas de Design em Aplicações MTV 31

como sendo a execução de scripts de banco de dados. A chamada aos métodos raw2 _e

execute3 _{caracterizam uma ação explícita de repositório.}

Um Laborious Repository Method ocorre quando uma função ou método contém mais do que uma ação explícita de repositório, isto é, quando executam mais de uma vez métodos provenientes de APIs de persistência que foram previamente definidos como ações de repositório. Métodos com várias ações de repositório podem ser considerados muito complexos, desse modo, dificultando o seu entendimento ou pouco coesos, isto é, assumindo responsabilidades que poderiam ser delegadas a outros métodos. A Figura 8

exibe um exemplo deste problema.

Figura 8 – Exemplo de Laborious Repository Method

A Figura 8apresenta um exemplo de método em que existe mais de uma execução de consulta SQL. Idealmente, o método deveria ter apenas uma execução de SQL. Apesar de, ser possível implementar o método de modo que apenas uma das consultas SQLs seja executada, em atividades de manutenção, o programador precisará compreender cada um dos fluxos individuais para manter o código, o que é consistente com a definição que considera a presença de scripts no mesmo método, independente de estarem no mesmo fluxo de execução ou não problemática.

Atributos de qualidade mais impactados. Manutenibilidade, portabilidade,

compatibilidade, segurança e eficiência de desempenho.

Estratégia de detecção. Deve haver apenas uma execução de raw ou execute por

método. Se houver mais do que um então o método é considerado um Laborious Repository Method.

2 _{implementação de Manager} 3 _{implementação da API django.db}

Capítulo 3. Problemas de Design em Aplicações MTV 32

Sugestão de refatoração. Modificar o método dividindo-o em métodos menores,

de modo que, cada um contenha apenas uma ação explícita de repositório.

3.2

Validação

Após a definição do catálogo, realizamos uma etapa de validação com especialistas em desenvolvimento de aplicações Django. Esta validação teve como objetivo averiguar a clareza das definições expostas, compreender, de acordo com a avaliação dos especialistas, os impactos dos problemas de design nos atributos de qualidade de software, além de, coletar a experiência dos especialista em situações reais destes problemas de design, assim como, coletar a sugestão de outros problemas de design relacionados ao padrão arquitetural MTV que não foram abordados no catálogo.

3.2.1

Metodologia

Ao validarmos o catálogo, buscamos obter resposta para as seguintes questões de pesquisa:

Q01. As definições dos problemas de design catalogados foram apresentadas com clareza?

Q02. Os problemas de design catalogados já foram percebidos em projetos reais? Q03. Quais atributos de qualidade são mais impactados pelos problemas de design? Q04. Algum outro problema de design não abrangido por este catálogo poderia ser adicionado a ele?

Para responder a estas questões e validar o catálogo proposto, consideramos essencial a participação de pessoas experientes, para isso, buscamos por profissionais com grande experiência no desenvolvimento de aplicações com o framework Django. Por este motivo, a seleção da amostra do estudo foi feita com base na rede de contatos dos pesquisadores. Os instrumentos empregados para coleta de dados na validação foram questionário, seguido de entrevista semi-estruturada. Estes dois instrumentos foram aplicados em momentos distintos.

Inicialmente, os participantes foram convidados por email. Após confirmação do aceite do convite, aplicamos primeiro o questionário. Para isso, enviamos um documento contendo: termo de consentimento; formulário para caracterização do participante; definição de conceitos importantes para compreensão do catálogo proposto; o catálogo proposto; e o questionário.

Uma vez respondidos os questionários, foi realizada uma análise comparativa dos dados coletados por este instrumento com o propósito de identificar possíveis convergência

Capítulo 3. Problemas de Design em Aplicações MTV 33

e divergências nas respostas dos participantes. Com base na análise desses dados e nas questões levantadas para validação do catálogo foi elaborado o roteiro da entrevista. As entrevistas foram agendadas por email e realizadas por vídeo conferência. Seu objetivo foi compreender melhor as razões que levaram os participantes às suas respostas no questionário, buscar resposta para os questionamentos da validação e também esclarecer alguma dúvida gerada pelo participante.

Antes da aplicação dos questionários e das entrevistas foi realizado um teste piloto com um colega de trabalho que compõe a equipe que desenvolve o SUAP no IFRN. O teste serviu para verificar se o formato das questões e se seu conteúdo estava coerente com o propósito da validação. Após aplicação do teste piloto não foi necessário realizar mudanças significativas nos documentos elaborados para a validação.

O termo de consentimento, o formulário de caracterização do participante, as definições de conceitos importantes, a versão do catálogo apresentada no questionário, o questionário e o roteiro da entrevista estão disponibilizasdas no ApêndiceAdeste trabalho.

3.2.2

Resultados

Para realizar a validação do catálogo proposto buscou-se identificar perfis com experiência no desenvolvimento de aplicações que utilizam o framework Django. Durante aplicação do questionário foram coletadas as experiências dos participantes conforme apresentado na tabela 1.

Tabela 1 – Perfil dos Participantes

Participante Origem Experiência (anos)

Django Python Geral

P1 Interno 9 11 12

P2 Externo 7 9 10

De acordo com os dados expostos na Tabela1foram selecionados dois participantes. O participante P1 atua na mesma instituição e faz parte da equipe de desenvolvimento na qual o autor desta dissertação trabalha. Por este motivo, este participante foi classificado como de origem interna. Enquanto que o participante P2 trabalha em outra organização, portanto, não faz parte do ambiente de trabalho do autor desta dissertação. Por isso P2 foi classificado como de origem externa.

Líderes de equipe e também desenvolvedores, os participantes trabalham em projetos de grande porte implementados em Python com o framework Django. O participante P1 possui 12 anos de experiência no desenvolvimento de sistemas, sendo que a 9 anos trabalha com o framework Django. O participante P2 trabalha há 10 anos no desenvolvimento de sistemas e possui 7 anos de experiência com o referido framework.

Capítulo 3. Problemas de Design em Aplicações MTV 34

O questionário respondido e a transcrição dos áudios das entrevistas estão disponí-veis no Apêndice B. A seguir são apresentadas as respostas obtidas por meio da aplicação do questionário e da entrevista.

Q01. As definições dos problemas de design catalogados foram apresen-tadas com clareza?

Ambos participantes concordaram que os problemas de design estavam bem descri-tos. No entanto, o participante P2 afirmou que a adição de exemplos tornaria a compreensão mais fácil.

A fim de favorecer um entendimento mais claro para o leitor foram adicionados exemplos de código que representem os problemas de design catalogados. O catálogo apresentado na seção anterior desta dissertação já contém as modificações sugeridas. A versão do catálogo apresentada aos participantes durante o questionário encontra-se no Apêndice A desta dissertação.

Q02. Os problemas de design catalogados já foram percebidos em pro-jetos reais?

Os participantes relataram que nos projetos em que trabalham alguns problemas de design catalogados são mais recorrentes do que outros. O participante P2 afirmou que, em algum momento da vida do sistema no qual trabalha, todos os problemas já ocorreram e que apesar de alguns deles terem sido inseridos em uma fase mais antiga da implementação, ainda não foram refatorados. O participante P1 afirmou que já vivenciou os problemas relatados.

O Meddling Model foi citado por P1 como o problema mais grave entre os catalo-gados. Ele relatou que esse problema já repercutiu negativamente em alguns projetos em que trabalhou. Ele citou um exemplo: “ao se construir uma API para expor alguns dados da aplicação são encontrados métodos na camada de modelo com resposta amarrada a um tipo de visualização específica, geralmente texto HTML, e é apenas nesses momentos que se percebe que aquilo não faz sentido e que está no lugar no errado”.

O Brain Repository Method foi considerado pelo participante P1 como tendo grande potencial para causar problemas. De acordo com P1, além da “chatice” de ter que ficar concatenando strings, o que pode levar ao erro, caso os dados de entrada não sejam muito bem tratados, também pode causar risco de segurança, por exemplo, um SQL Injection. Um SQL complexo aliado à própria estrutura complexa do código como um todo pode encobrir esse tipo de problema.

Ocorrências de Brain Repository Method e Laborious Repository Method resul-taram em problemas na manutenção em um sistema de grande porte coordenado pelo participante P2. Além destes dois problemas, P2 também relatou que o Improper Use of Manager também ocorre com certa frequência e que existe uma força tarefa para refatorar

Capítulo 3. Problemas de Design em Aplicações MTV 35

esses códigos, mas devido a outras prioridades, por exemplo, implementação de novas funcionalidades, acaba sendo adiado pois, apesar de reconhecer que a refatoração gera benefícios técnicos, não tem impacto relevante na percepção do usuário final.

Todos os participantes concordaram que o Meddling View representa um problema de design, mas não relataram situações reais das complicações decorrente deste problema. P1 afirmou que Meddling View pode ter alto impacto negativo em um sistema, mas acredita que a probalidade desse impacto acontecer é baixa devido a algumas limitações providas pelo Django.

Q03. Quais atributos de qualidade são mais impactados pelos problemas de design?

De modo geral, houve um resultado muito semelhante na avaliação dos participantes. Grande parte das respostas foram iguais e outras tiveram classificação bastante próxima. No entanto é importante observar que uma resposta dada pelos participantes teve um grau maior de divergência.

A discordância nas respostas ocorreu na avaliação do impacto do Meddling View no atributo de qualidade confiabilidade. Após análise das entrevistas percebemos que o participante P1 considerou que este problema ocorria apenas nos arquivos de template, no entanto, na nossa avaliação, esse problema ocorre principalmente nas funções da visão. Logo, acreditamos que a diferença na interpretação do participantes do local onde ocorre o Meddling View foi a causa da divergência mais acentuada neste atributo de qualidade. Os participantes avaliaram os graus de impacto dos problemas de design nos atributos de qualidade de software da seguinte forma:

Meddling View. Manutenibilidade é altamente impactado; confibialidade e segurança possuem impacto moderado; adequação funcional possui baixo impacto; e usabilidade não é afetado. Compatibilidade e portabilidade foram considerados com impacto moderado a alto e eficiência de desempenho foi considerado com impacto nenhum a baixo.

Meddling Model. Compatibilidade, manutenibilidade e portabilidade são altamente impactados; e eficiência de desempenho e usabilidade não são afetados. Adequação funcional e confiabilidade foram considerados com impacto baixo a moderado e segurança com impacto moderado a alto.

Improper Use of Manager. Manutenibilidade é altamente impactado; portabilidade possui impacto moderado; adequação funcional e segurança possuem baixo impacto; e eficiência de desempenho e usabilidade, nenhum impacto. Compatibilidade foi considerado com baixo a moderado impacto e confiabilidade foi considerado com impacto nenhum a baixo.