Implementering av smartby i Stavanger kommune, i lys av fire alternative teorier

O trabalho de (Machado, 2010) apresenta o RiPLE-TE (do inglês RiSE

Product Line Engineering Testing) que se caracteriza como um processo de teste

para linhas de produto de software. Tal processo faz parte do RiPLE (RiSE Product

Line Engineering), uma espécie de framework para o desenvolvimento de LPSs que

reúne as seguintes disciplinas: escopo, requisitos, projeto, implementação, gerenciamento de evolução e testes. É importante destacar também que o RiPLE é um dos projetos relacionados ao RiSE Labs (Almeida et al., 2004).

O RiPLE-TE é um processo que se concentra em promover a redução de esforço na condução de atividades de teste em LPSs pela reutilização sistemática de artefatos de teste. Para alcançar tal finalidade, as similaridades presentes nos testes são exploradas, bem como é realizado o gerenciamento das variabilidades dos produtos da LPS. Além disso, o processo de teste se caracteriza por poder ser aplicado tanto no momento em que os artefatos núcleo da LPS são desenvolvidos (engenharia de domínio) como no instante em que os produtos específicos são construídos (engenharia de aplicação). Na engenharia de domínio é proposto o uso de testes de unidade e integração. Inicialmente, testes de unidade são empregados para saber se classes e métodos que formam um componente reusável funcionam corretamente. Depois, testes de integração são usados para verificar a interação entre interfaces de componentes e integração dos módulos da LPS. Na engenharia de aplicação, testes de integração são novamente usados, mas para analisar a

colaboração entre os diversos componentes que formam dado produto. Em seguida, é destacado o uso de testes de sistema para avaliar o funcionamento geral de determinado produto e, dessa forma, verificar se os requisitos definidos previamente para esse membro da LPS estão, de fato, sendo atendidos. Por fim, testes de aceitação são usados para saber se os produtos derivados funcionam de acordo com os requisitos estabelecidos pelos interessados e usuários de tais membros da linha.

Conforme descrito anteriormente, o RiPLE-TE abrange as duas fases principais de uma linha de produto, bem como usa testes referentes aos estágios (níveis) de unidade, integração, sistema e aceitação. Esse processo de teste também apresenta um conjunto de tarefas, documentos de entrada, artefatos de saída, papéis e diretrizes para o desenvolvimento e gerenciamento de artefatos de teste de uma LPS. Contudo, apesar de ser um processo bem completo, capaz de auxiliar os envolvidos nas atividades de teste de uma linha de produto, existe certa carência em demonstrar de forma mais precisa como o processo RiPLE-TE pode ser empregado concretamente em projetos de LPS. No trabalho de (Machado, 2010) são encontrados estudos experimentais, mas o foco está voltado para a avaliação do processo proposto e coleta de resultados que sirvam para melhorá-lo. Na abordagem de teste de LPS desta dissertação, por sua vez, além de evidenciar conceitualmente as características e forma de uso de tal abordagem, são apresentadas diretrizes explícitas e detalhadas de como empregá-la de forma prática durante a engenharia de domínio e aplicação de uma linha de produto. Além disso, o nosso trabalho possui um diferencial fundamental que é a proposta de extensão da ferramenta GenArch que oferece suporte a implementação, gerência e customização de artefatos de teste, assim como a derivação automática dos produtos com os seus respectivos testes automatizados.

7 Conclusão e Trabalhos Futuros

Esta dissertação de mestrado propõe uma abordagem sistemática para o teste de linhas de produto de software. A abordagem fornece estratégias que ajudam a direcionar os responsáveis pelo processo de teste (passo 1 da Figura 5), como também oferece uma visão clara de como os testes se manifestam nas fases de desenvolvimento de uma LPS. Foram propostas cinco estratégias efetivas de teste funcional que são: (i) testes de unidade do núcleo, (ii) teste de integração do núcleo, (iii) teste de sistema do núcleo, (iv) teste de unidade e integração de produtos e (v) teste de sistema de produtos. Para cada estratégia foram oferecidas diretrizes que apresentam concretamente como realizar a implementação dos testes (passo 2 da Figura 5) dos artefatos produzidos tanto na engenharia de domínio como na engenharia de aplicação de uma linha de produto.

A abordagem também permite a gerência e customização dos testes de uma LPS. Para dar suporte a essas atividades, bem como a elaboração dos testes referentes às estratégias citadas anteriormente, foi implementada uma extensão da ferramenta GenArch. Com o uso de tal ferramenta, os artefatos de teste são anotados para promover a gerência de tais artefatos (passo 3 da Figura 5). Especificamente, foi criada a anotação @Test para indicar: (i) a estratégia dos testes, ou seja, especificar se esses testes são exclusivamente para o núcleo ou para produtos da LPS; (ii) o estágio (unidade, integração, sistema) que o teste está relacionado; e (iii) o tipo (funcional) de teste que o artefato de teste pertence. Com o processamento de tais anotações, é possível identificar os elementos de teste da LPS, possibilitando a inclusão de elementos de teste nos modelos de arquitetura e configuração após a geração dos modelos da ferramenta GenArch (passo 4 da Figura 5), garantindo assim a possibilidade de carregar tais elementos de teste em contextos específicos de teste da LPS ou de um produto em particular. Com relação à customização dos testes, o trabalho descreve a utilização de templates para testes de integração e sistema que podem ser implementados de forma a conter código de teste que apresentam uma parte comum e partes variáveis a serem geradas de acordo com as variabilidades definidas para um produto da LPS (integra passo 2 da Figura 5).

Por fim, com os artefatos de teste devidamente anotados e com os modelos gerados e prontos para uso, a abordagem garante por meio da extensão do GenArch, a derivação de elementos de implementação que constituem determinado produto da LPS e geração de seus respectivos testes, de acordo com a estratégia (teste apenas do núcleo ou de produtos específicos da LPS) e estágio (unidade, integração e sistema) definidos pelo engenheiro da LPS em questão (passo 5 da Figura 5).