Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software

Tamanho: px

Começar a partir da página:

Download "Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software"

Benedicto Zagalo Weber
8 Há anos
Visualizações:

1 Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software Gabriela Guedes de Souza, Jaelson Castro e Carla Silva ggs@cin.ufpe.br, jbc@cin.ufpe.br, carla@dce.ufpb.br DEPARTAMENTO DE CIÊNCIAS EXATAS CENTRO DE CIÊNCIAS APLICADAS E EDUCAÇÃO UNIVERSIDADE FEDERAL DA PARAÍBA 1

ufpe.br, jbc@cin.ufpe.br, carla@dce.ufpb.

2 Agenda Contexto Problema Ideia Principal Resultados Preliminares Considerações Finais Trabalhos Futuros 2

3 Linha de Produtos de Software Linha de Produtos de Software (LPS) é um grupo de produtos de software com características comuns e variáveis, que também pode ser chamado de família de produtos. As características de uma LPS precisam ser documentadas explicitamente para possibilitar o reuso estratégico dos seus artefatos. 3

4 Engenharia de Requisitos (ER) É a fase do desenvolvimento de sistemas de software responsável pela identificação dos objetivos do sistema pretendido, pela operacionalização de tais objetivos em requisitos funcionais e requisitos não-funcionais e pela atribuição da responsabilidade dos requisitos resultantes a agentes, tais como humanos, hardware e software. 4 Lamsweerde, A. Requirements Engineering in the Year 00: A Research Perspective. 22nd Proc. of International Conf. on Software Engineering, Limerick, Ireland, 2000.

da responsabilidade dos requisitos resultantes a agentes, tais como humanos, hardware e software. 4 Lamsweerde, A.

5 Engenharia de Requisitos para LPS A Engenharia de Requisitos para especificar uma LPS é responsável por: capturar as suas variabilidades; relacionar os diferentes tipos de requisitos; manter o rastreamento entre eles. 5

capturar as suas variabilidades; relacionar os

6 Modelo de Features Usa-se o modelo de features para capturar as variabilidades. 6 Kang, K., Cohen, S., Hess, J., Novak, W., Peterson, A. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Software Engineering Institute, Technical report, CMU/SEI- 90-TR-021, 1990.

7 Limitações do Modelo de Features Modelos de features não permitem estabelecer um relacionamento entre as features de um produto de software e os objetivos dos stakeholders. Não há uma forma sistemática para descobrir: quais features farão parte da LPS; quais features serão opcionais, obrigatórias ou alternativas; quais features farão parte de um produto da LPS. 7

Não há uma forma sistemática para descobrir: quais features farão parte da LPS; quais

8 Engenharia de Requisitos Orientada a Objetivos Para solucionar estes problemas, pode-se usar uma abordagem de Engenharia de Requisitos Orientada a Objetivos (Goal Oriented Requirements Engineering - GORE), que visa: capturar objetivos dos stakeholders; capturar requisitos do sistema. G2SPL (Goals to Software Product Lines) 8 Silva, C., Borba, C. and Castro, J. A Goal Oriented Approach to Identify and Configure Feature Models for Software Product Lines. In: Workshop on Requirements Engineering (WER'2011), Rio de Janeiro, 2011.

capturar requisitos do sistema. G2SPL (Goals to Software Product Lines) 8 Silva, C., Borba, C. and Castro, J.

9 G2SPL (Goals to Software Product Lines) É baseado no framework i*; O i* permite a construção de duas visões de modelos: modelo de Dependência Estratégica (SD): fornece uma descrição das relações de dependências externas entre os atores da organização; modelo de Razão Estratégica (SR): fornece uma análise de como os objetivos e as dependências podem ser cumpridas através das contribuições dos atores modelados anteriormente. 9 Yu, E. Modeling Strategic Relationships for Process Reengineering. In: Yu, E., Giorgini, P., Maiden, N., Mylopoulos, J. (eds). Social Modeling for Requirements Engineering. 1 st Ed., MIT Press, Chapter 2, pp

objetivos e as dependências podem ser cumpridas através das contribuições dos atores modelados anteriormente. 9 Yu, E.

10 Modelos do i* 10 Figura 1. Modelo SD (a) e Modelo SR (b)

11 Cenários Os modelos do i* fornecem apenas uma visão estática do software. O comportamento dinâmico do software pode ser descrito através de uma técnica de especificação de cenários; Vantagens dos cenários: descrevem o comportamento das funcionalidades do sistema; são muito utilizados na ER de sistemas, pois são de fácil compreensão por parte dos stakeholders. MSVCM (Modeling Scenario Variability as Crosscutting Mechanisms) 11

Vantagens dos cenários: descrevem o comportamento das funcionalidades do sistema; são muito utilizados na

12 MSVCM (Modeling Scenario Variability as Crosscutting Mechanisms) É um dos trabalhos que se preocupam com a separação de interesses transversais na especificação de cenários; Os interesses transversais são requisitos cujo comportamento pode ter impacto em múltiplos módulos ou componentes do sistema; MSVCM também propõe a separação entre o comportamento variável e comum da LPS. 12 Bonifácio, R. and Borba, P. Modeling Scenario Variability as Crosscutting Mechanisms. In: AOSD 09, Charlottesville, Virginia, USA, March 2 6, 2009.

múltiplos módulos ou componentes do sistema; MSVCM também propõe a separação entre o comportamento variável e comum da LPS.

13 Problema Não há um processo de ER para LPS que integre uma abordagem GORE e uma técnica de especificação de cenários com separação de interesses transversais 13

14 Ideia Principal A ideia é aproveitar as vantagens que a orientação a objetivos e a especificação de cenários têm de melhor. O principal objetivo deste trabalho é: Definir um processo de ER para LPS, integrando a abordagem G2SPL uma abordagem GORE e a técnica MSVCM de especificação de cenários de caso de uso com separação de interesses transversais. 14

O principal objetivo deste trabalho é: Definir um processo de ER para LPS, integrando a

15 Resultados Preliminares A abordagem será desenvolvida através de um estudo de caso com o projeto TARGET da Motorola. A TARGET (Test And Requirement GEneration Tool) é uma LPS, cujos produtos obtidos são ferramentas de geração de casos de teste com características variáveis. Os primeiros modelos SD sobre as motivações e objetivos dos stakeholders foram feitos usando i*, que é uma técnica usada no G2SPL. 15 Test Research Project (Motorola Brazil Test Center (BTC), CIn-UFPE/Brazil and UFCG/Brazil). TARGET (Test And Requirement GEneration Tool). último acesso em Março de 2011.

Os primeiros modelos SD sobre as motivações e objetivos dos stakeholders foram feitos usando i*, que é uma técnica usada no G2SPL.

16 Resultados Preliminares 16 Figura 2 - Modelo SD mais atual do TARGET

17 Considerações Finais As etapas iniciais para o estudo de caso que irá ser tomado como base para desenvolver a abordagem já estão sendo realizadas. Foram modeladas, utilizando o framework i*, as motivações para o desenvolvimento da ferramenta. Porém, ainda não se concluiu a documentação da variabilidade da LPS TARGET, que está sendo feita utilizando a linguagem i*-c (i* com cardinalidade). 17

Foram modeladas, utilizando o framework i*, as motivações para o desenvolvimento da ferramenta.

18 Trabalhos Futuros Executar as etapas seguintes do processo G2SPL: Modelar as variabilidades da LPS TARGET; Construir o modelo de features sistematicamente; Integrar G2SPL à técnica MSVCM Adaptar o processo G2SPL para incluir a especificação de cenários com separação de interesses com a técnica MSVCM 18

sistematicamente; Integrar G2SPL à técnica MSVCM Adaptar o processo G2SPL

19 Uma Abordagem de Engenharia de Requisitos Para Linhas de Produtos de Software Gabriela Guedes de Souza, Jaelson Castro e Carla Silva ggs@cin.ufpe.br, jbc@cin.ufpe.br, carla@dce.ufpb.br DEPARTAMENTO DE CIÊNCIAS EXATAS CENTRO DE CIÊNCIAS APLICADAS E EDUCAÇÃO UNIVERSIDADE FEDERAL DA PARAÍBA 19

Documentos relacionados

Linhas de Produtos de Software. Professor: Uirá DIMAp / UFRN, 2009.2

Linhas de Produtos de Software Professor: Uirá DIMAp / UFRN, 2009.2 Aula 4: Modelagem de Variabilidades em Requisitos Modelagem de Requisitos Documentação textual Não limita a expressividade dos requisitos