• Nenhum resultado encontrado

CAPÍTULO 5 A FERRAMENTA F3T

6.5 Experimento 3: Ferramenta F3T

6.5.4 Ameaças à Validade do Experimento 3

Validade Interna:

• Diferenças entre as ferramentas: As ferramentas utilizadas no experimento geram artefatos diferentes. A Pure::variants gera um conjunto de modelos a partir do código-fonte de uma aplicação base e depois gera o código-fonte das variantes, que possuem um subconjunto das classes da aplicação base. Já a F3T gera o código- fonte e a DSL de um framework e depois gera o código-fonte das aplicações a partir de modelos criados com a DSL do framework. Apesar dessas diferenças, o objetivo final das duas ferramentas o desenvolvimento de aplicações com reúso;

• Nível de experiência dos participantes: os participantes possuiam diferentes níveis de conhecimento e isso poderia afetar os dados coletados. Para mitigar essa ameaça, os participantes foram divididos em dois blocos equilibrados, considerando o seu nível de conhecimento com base no Formulário de Caracterização de Participante

(Apêndice C). Além disso, todos os participantes possuiam experiência prévia no desenvolvimento de aplicações e foram previamente treinados para que soubessem utilizar a F3T e a Pure::variants;

• Produtividade sob avaliação: o resultado do experimento poderia ser influênciado, caso os participantes pensassem que estavam sendo avaliados e, por isso, precisavam desenvolver as aplicações com rapidez e sem erros. A fim de atenuar isso, foi explicado para os participantes que ninguém estava sendo avaliado e sua participação foi considerada anônima;

• Recursos utilizados durante o experimento: diferentes computadores e instalações poderiam afetar os tempos registrados. Assim, os indivíduos usaram a mesma configuração de hardware e de sistema operacional.

Validade Externa:

• Interação entre configuração e tratamento: Pode ser argumentado que a abordagem foi testada apenas no meio acadêmico, pois os participantes do experimento são estudantes. Contudo, o experimento foi realizado atendendo a todos os pontos evidenciados por seus autores, como ocorre em um ambiente industrial.

Validade da Construção:

• Expectativas da hipótese: os participantes poderiam saber previamente que uma das abordagens deveria ser melhor que a outra. Estas questões poderiam ter afetado os dados e ter feito com que a experiência tenha sido menos imparcial. A fim de manter a imparcialidade, foi informados aos participantes que o mais importante era obter um resultado que refletisse a realizade, independente da hipotese que fosse concretizada.

Validade da Conclusão:

• Confiabilidade das métricas: refere-se às métricas usadas para medir o esforço de desenvolvimento. Para atenuar essa ameaça, foi considerada uma métrica que reflete um ponto importante, como é o caso do tempo gasto no uso das ferramentas; • Baixa potência estatística: a capacidade de um teste estatístico em revelar dados

confiáveis. Para atenuar essa ameaça, foram aplicados os testes Paried T-Test e

Wilcoxon Signed-Rank Test, para analisar estatisticamente o tempo gasto para

6.6 Considerações Finais

Neste capítulo foram apresentados os experimentos realizados para avaliar as abordagens e a ferramenta desenvolvidas durante este doutorado. Esses experimentos foram previamente planejados com base nos objetivos pretendidos, nos recursos a serem utilizados, nos participantes e nas variáveis. Além disso, testes estatísticos foram aplicados para obter maior confiabilidade nos resultados obtidos. Um resumo dos resultados obtidos com os experimentos apresentados neste capítulo é mostrado no Quadro 6.10.

Quadro 6.10. Resultados dos experimentos.

Experimento Objetivo Resultado

1 Analisar o uso de DSLs para a instanciação de frameworks. O uso de DSLs torna o reúso de frameworks mais eficiente e resulta em aplicações com menor número de problemas do que os wizards.

2

Analisar o uso da abordagem F3 para o processo de

desenvolvimento de

frameworks.

O uso da abordagem F3 torna o reúso de frameworks mais eficiente e reduz o número de problemas encontrados nos frameworks desenvolvidos quando comparada ao uso de uma abordagem com modelagem e implementações tradicionais (ad hoc).

3 Analisar o uso da F3T nas fases de Engenharia de Domínio e Engenharia de Aplicação.

O uso da F3T é menos eficiente do que o uso da Pure::variants em relação a construção dos artefatos das fases de Engenharia de Domínio e Engenharia de Aplicação.

Os experimentos corroboraram com as vantagens preconizadas pelos conceitos aplicados nas abordagens desenvolvidas neste doutorado. No Experimento 1 foi visto que a DSL torna a instanciação de frameworks mais fácil e eficiente, pois, com a DSL, as informações requeridas pelo framework são definidas e validadas durante a modelagem das aplicações. Além disso, o uso de modelos gráficos para a modelagem de aplicações é mais vantajoso do que o uso de wizards. Contudo, o experimento também mostrou que, tanto com o uso de wizards quanto de DSLs, é necessário que o desenvolvedor possua conhecimento sobre os domínios e as estruturas fornecidas pelos frameworks para que possa relacionar corretamente os requisitos das aplicações às classes dos frameworks.

No Experimento 2 foi visto que a abordagem DSL facilita o desenvolvimento de frameworks, uma vez que os padrões que foram propostos quando da criação dessa abordagem guiam os desenvolvedores durante a implementação das unidades de código. Desse modo, o desenvolvimento dos frameworks também se torna mais eficiente, uma vez que os desenvolvedores precisam somente seguir as sugestões dos padrões da abordagem. Contudo, a responsabilidade sobre o entendimento e a modelagem do domínio ainda dependem das habilidades e da experiência dos desenvolvedores.

No Experimento 3 foi visto que a F3T e a Pure::variants são ferramentas distintas, mas que apoiam o desenvolvimento dos artefatos das fases de Engenharia do Domínio e

Engenharia de Aplicação. A Pure::variants mostrou-se mais eficiente e mais indicada quando existe uma aplicação base a partir da qual as aplicações desenvolvidas serão derivadas. Por outro lado, a F3T é mais indicada quando o desenvolvimento se inicia a partir dos requisitos do domínio e quando se deseja obter um software intermediário (um framework) que é reutilizado pelas aplicações.