USANDO CONTEXTOS E REQUISITOS NÃO-FUNCIONAIS PARA CONFIGURAR MODELOS DE OBJETIVOS, MODELOS DE FEATURES E
CENÁRIOS PARA LINHAS DE PRODUTOS DE SOFTWARE
Por
JEAN POUL VARELA Dissertação de Mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE, 2015
USANDO CONTEXTOS E REQUISITOS NÃO-FUNCIONAIS PARA CONFIGURAR MODELOS DE OBJETIVOS, MODELOS DE FEATURES E CENÁRIOS PARA
LINHAS DE PRODUTOS DE SOFTWARE
ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO
DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.
ORIENTADOR: CARLA TACIANA LIMA LOURENÇO SILVA SCHUENEMANN
RECIFE, 2015
título “Usando Contextos e Requisitos Não-Funcionais para Configurar Modelos de
Objetivos, Modelos de Features e Cenários para Linhas de Produto de Software”,
orientada pela Profa. Carla Taciana Lima Lourenço Silva Schuenemann e aprovada pela Banca Examinadora formada pelos professores:
______________________________________________ Prof. Robson do Nascimento Fidalgo
Centro de Informática/UFPE
______________________________________________ Prof. Gilberto Amado de Azevedo Cysneiros Filho Departamento de Estatística e Informática / UFRPE
_______________________________________________ Prof. Rodrigo Bonifacio de Almeida
Departamento de Ciência da Computação / UnB
_________________________________________________ Profa. Carla Taciana Lima Lourenço Silva Schuenemann Centro de Informática / UFPE
Visto e permitida a impressão. Recife, 23 de fevereiro de 2015.
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.
O processo GS2SPL (Goals and Scenarios to Software Product Lines) visa obter, de maneira sistemática, o modelo de features e a especificação de cenários de caso de uso, a partir de modelos de objetivos de uma linha de produto de software (LPS). Além disso, esse processo permite realizar a configuração desses artefatos de requisitos para um produto da LPS, com base no atendimento de requisitos não-funcionais (RNFs). Contudo, essa configuração é realizada sem considerar o estado do contexto do ambiente no qual a aplicação gerada será implantada. Isso é uma limitação, pois uma configuração pode não atender as necessidades do stakeholders. Por outro lado, o processo E-SPL (Early Software Product Line) permite configurar o modelo de objetivos de um produto visando maximizar o atendimento de RNFs e levando em consideração o estado do contexto. Para superar a limitação do processo GS2SPL, o presente trabalho propõe uma extensão do processo GS2SPL para incorporar a atividade de configuração do E-SPL. O novo processo é chamado de GSC2SPL (Goals, Scenarios and Contexts to Software Product Lines), o qual possibilita a obtenção do modelo de features e cenários de caso de uso, a partir de modelos de objetivos contextuais. O processo também permite realizar a configuração desses artefatos de requisitos com base nas informações sobre o contexto e visando aumentar o atendimento dos requisitos não-funcionais. O processo é apoiado pela ferramenta GCL-Tool (Goal and Context for Product Line - Tool). O processo foi aplicado à especificação de duas LPS: o Media@ e o Smart Home.
Palavras-Chave: Engenharia de Requisitos. Linha de Produto de Software. Modelo
GS2SPL (Goals and Scenarios to Software Product Lines) is a process aimed at systematically obtaining a feature model and the specification of use case scenarios from goal models of a Software Product Line (SPL). Moreover, this process allows configuring specific applications of an SPL based on the fulfillment of non-functional requirements (NFRs). However, this configuration is performed without considering the context state in which the system will be deployed. This is a limitation because a configuration may not meet the needs of stakeholders. On the other hand, E-SPL (Early Software Product Line) is a process that allows configuring a product aimed maximizing the fulfillment of NFRs and taking into account the context state. To overcome the limitation of the GS2SPL process, in this work we propose extension of the GS2SPL process, to incorporate the configuration activity of the E-SPL. The new process is called GSC2SPL (Goals, Scenarios and Contexts to Software Product Lines), which allows obtaining a feature model and use case scenarios from contextual goal models. The process will also allow the configuration of such requirements artifacts based on the information about the context and aiming to maximize the fulfillment of non-functional requirements. The process is supported by the GCL-Tool (Goal and Context for Product Line - Tool). The process was applied to the specification of two LPS: Media@ and the Smart Home.
Keywords: Requirements Engineering. Software Produtct Line. Goal Modeling.
Figura 1. Framework de Linha de Produto de Software ... 23
Figura 2. Modelo de Features da LPS Target... 25
Figura 3. Diagrama BPMN do processo E-SPL ... 32
Figura 4. Modelo i*-ortogonal intencional inicial do Mobile Media ... 33
Figura 5. Modelo i*-Ortogonal Intencional Final para a LPS Mobile Media ... 35
Figura 6. Contexto C1 - Salvar Manualmente... 36
Figura 7. Modelo i*-Ortogonal para o Mobile Media ... 38
Figura 8. Modelo i*-wiki para o produto configurado a partir da variante V2 ... 42
Figura 9. Modelo BPMN do Processo GS2SPL ... 44
Figura 10. Modelo SR obtido na atividade 1 do GS2SPL ... 45
Figura 11. Modelo SR do Mobile Media com os elementos candidatos a features destacados ... 48
Figura 12. Modelo de Feature do Mobile Media ... 50
Figura 13. Variante V1 do Mobile Media ... 59
Figura 14. Variante V2 do Mobile Media ... 59
Figura 15. Modelo de Configuração ... 61
Figura 16. Modelo i*-wiki ... 61
Figura 17. Processo GSC2SPL na notação BPMN ... 69
Figura 18. Modelo i*-ortogonal Intencional para a LPS Medi@ ... 73
Figura 19. Contextos descobertos para a LPS Medi@ ... 75
Figura 20. Modelo i*-ortogonal contextual para a LPS Mobile Media ... 76
Figura 21. Modelo i*-ortogonal da LPS Medi@ ... 78
Figura 22. Modelo de Features da LPS Medi@ ... 82
Figura 23. Modelo de features refinado ... 84
Figura 24. Variante V1 da LPS Mobile Media ... 100
Figura 25. Variante V2 da LPS Mobile Media ... 100
Figura 26. Modelo i*-wiki do produto gerado da LPS Media Shop ... 107
Figura 27. Modelo de configuração para o produto gerado da LPS Medi@ ... 107
Figura 28. Arquitetura da Ferramenta GCL-Tool ... 112
Figura 32. Painel de propriedades da FeatureGroup ... 115
Figura 33. Editor i*-Ortogonal ... 115
Figura 34.Detalhamento do menu do editor i*-ortogonal ... 116
Figura 35. Editor i*-wiki ... 116
Figura 36. Editor de cenários de caso de uso ... 117
Figura 37. Módulo de Engenharia de Domínio ... 118
Figura 38. Módulo de Engenharia de Aplicação ... 119
Figura 39. Modelo i*-ortogonal intencional da LPS Smart Home ... 132
Figura 40. Modelo de contexto para a LPS Smart Home ... 135
Figura 41. Painel para gerar os contextos ... 135
Figura 42. Painel de Expressão Contextual ... 136
Figura 43. Painel de propriedades do relacionamento Means End... 136
Figura 44. Relacionamento com o contexto C1 ... 136
Figura 45. Modelo i*-ortogonal contextual para a LPS Smart Home ... 137
Figura 46. Painel de propriedades da tarefa Controlar Janela ... 138
Figura 47. Tarefa Controlar Janela com cardinalidade ... 138
Figura 48. Modelo i*-ortogonal para a LPS Smart Home ... 139
Figura 49. Painel para execução do Processo ... 140
Figura 50. Seleção do ator que representa a LPS ... 140
Figura 51. Tabela Goal2Feature obtida através da transformação ... 141
Figura 52. Modelo de Features obtido a partir da transformação ... 142
Figura 53. Tabela Goal2Feature refinada... 143
Figura 54. Modelo de Features refinado para a LPS Smart Home ... 144
Figura 55. Criando a tabela de variantes ... 159
Figura 56. Tabela de Variantes criada ... 159
Figura 57. Criando uma variante ... 160
Figura 58. Criando a variante ... 160
Figura 59. Tabela de Variantes com todas as variantes ... 161
Figura 60. Priorizando os requisitos não funcionais ... 161
Figura 63. Tabela de variante com as prioridades ... 163
Figura 64. Exportando os contextos ... 163
Figura 65. Escolha de requisito opcional ... 164
Figura 66. Escolha de requisito presente em um grupo ... 165
Figura 67. Modelo i*-wiki obtido através da configuração ... 166
Figura 68. Modelo de features configurado ... 167
Figura 69. Metamodelo do editor de Contexto ... 187
Figura 70. Metamodelo modelo de features proposto por CZARNECK; HELSEN.; EISENECKER (2004) ... 191
Figura 71. Metamodelo proposto para o modelo de features ... 192
Figura 72. Metamodelo original da linguagem i*-ortogonal ... 195
Figura 73. Metamodelo do i*-ortogonal ... 196
Figura 74. Metamodelo do i*-wiki ... 204
Figura 75. Elemento Fronteira ... 210
Figura 76. Relacionamento de dependência no modelo i*-ortogonal... 219
Figura 77. Modelo i*-ortogonal intencional no teste de usabilidade ... 242
Figura 78. Contexto Auxilio Polícia ... 243
Figura 79. Modelo i*-wiki configurado ... 248
Tabela 1. Semântica dos pontos de variação contextuais ... 28
Tabela 2. Pontos de Variação Contextuais ... 29
Tabela 3. Valor percentual dos links de contribuição ... 40
Tabela 4. Tabela de rastreamento objetivos-feature ... 49
Tabela 5. Template para documentação de caso de uso ... 52
Tabela 6. Descrição do Caso de Uso Adicionar Foto ... 57
Tabela 7. Cenário do Caso de Uso Adicionar Foto configurado ... 62
Tabela 8. Níveis de satisfação utilizados para a comparação ... 64
Tabela 9. Comparação dos trabalhos relacionados ... 65
Tabela 10. Tabela Goal2Feature... 78
Tabela 11. Tabela Goal2Feature da LPS Media Shop ... 81
Tabela 12. Tabela Goal2Feature refinada ... 83
Tabela 13. Template para a documentação de cenários de caso de uso ... 86
Tabela 14. Caso de Uso Carrinho de Compra – Informações Características ... 87
Tabela 15. Caso de Uso Carrinho de Compra - Inicial ... 91
Tabela 16. Caso de Uso Carrinho de Compra - Cenário Principal ... 92
Tabela 17. Caso de Uso Carrinho de Compra... 95
Tabela 18. Caso de uso Carrinho de Compra refinado ... 96
Tabela 19. Tabela de Variantes ... 99
Tabela 20. Variante para a LPS Medi@ ... 99
Tabela 21. Fator de ponderação das ligações de contribuição ... 102
Tabela 22. Valor das prioridades dos softgoals ... 103
Tabela 23. Tabela de variantes com o valor das prioridades... 105
Tabela 24. Cenário do Caso de Uso Carrinho de Compra ... 108
Tabela 25. Respostas do questionário ... 122
Tabela 26. Dados sobre a utilidade do sistema ... 124
Tabela 27. Dados referentes à qualidade da informação ... 124
Tabela 28. Dados referentes a qualidade da interface ... 125
Tabela 29. Caso de Uso Controle de Segurança - primeira versão obtida ... 145
Tabela 33. Caso de Uso Configurar Segurança ... 150
Tabela 34. Caso de uso Configurar Alarme ... 151
Tabela 35. Caso de Uso Ativar Alarme ... 152
Tabela 36. Caso de Uso Detecção de Intrusos ... 153
Tabela 37. Caso de Uso Controle de Segurança – Cenário decomposto ... 153
Tabela 38. Caso de Uso Controle de Segurança - Refinado ... 154
Tabela 39. Caso de Uso Configurar Segurança - Refinado ... 155
Tabela 40. Caso de uso Configurar Alarme - Refinado ... 156
Tabela 41. Cenário de Caso de Uso Ativar Alarme - Refinado ... 157
Tabela 42. Caso de Uso Detecção de Intrusos - Refinado ... 158
Tabela 43. Caso de Uso Controle de Segurança - Configurado ... 167
Tabela 44. Caso de Uso Configurar Segurança - Configurado ... 168
Tabela 45. Caso de uso Configurar Alarme - Configurado ... 169
Tabela 46. Caso de uso Ativar Alarme - Configurado... 170
Tabela 47. Caso de Uso Detecção de Intrusos - Configurado ... 170
Tabela 48. Comparativo entre os processos ... 175
Tabela 49. Sintaxe abstrata do editor de contexto ... 188
Tabela 50. Sintaxe abstrata do editor de modelo de features... 193
Tabela 51. Sintaxe abstrata do editor de i*-ortogonal ... 198
Tabela 52. Sintaxe abstrata do editor i*-wiki ... 206
Listagem 2. Restrição Relationship ... 189
Listagem 3. Retrição relacionamento implica ... 190
Listagem 4. Restrição relacionamento suporta... 190
Listagem 5. Restrição hasName para o modelo de feature ... 193
Listagem 6. Restrição cardinalidade válida ... 194
Listagem 7. Restrição para que o modelo i*-ortogonal possua nome ... 200
Listagem 8. Restrição Relationship ... 200
Listagem 9. Restrição source contribution link ... 201
Listagem 10. Restrição Feature Group... 201
Listagem 11. Restrição Dependency Link ... 201
Listagem 12. Restrição relacionamento ISA ... 202
Listagem 13. Restrição IsPartOf... 202
Listagem 14. Restrições da cardinalidade ... 203
Listagem 15. Restrição para que o modelo i*-ortogonal possua nome ... 207
Listagem 16. Restrição relationship i*-wiki ... 208
Listagem 17. Restrição ISA - editor i*-wiki ... 208
Listagem 18. Restrição IsPartOf - i*-wiki ... 208
Listagem 19. Regra de criação da feature root... 209
Listagem 20. Transformação Resource para Feature ... 210
Listagem 21. Transformação TasktoFeature ... 211
Listagem 22. Transformação FeatureGroup ... 212
Listagem 23. Transformação de TaskDecomposition ... 212
Listagem 24. Transformação MeansEndLink em Relationship ... 213
Listagem 25. Transformação MeansEndtoRelationshipFeatureGroup ... 214
Listagem 26. Transformação entre dependências ... 214
Listagem 27. Criação da feature root na tabela Goal2Feature ... 216
Listagem 28. Transformação Goal2Feature ... 216
Listagem 29. Tranformação para obter os atores de caso de uso ... 219
Listagem 30. Transformação para obter a informações gerais do caso de uso ... 220
Listagem 33. Transformação para obter os passos a partir de relacionamentos
TaskDecompositionLink ... 222
Listagem 34. Transformação para obter passos a partir de RelationshipFeatureGroup ... 223
Listagem 35. Transformação para obter passos a partir de DependencyLink ... 224
Listagem 36. Configuração do Actor ... 226
Listagem 37. Configuração de Agent ... 226
Listagem 38. Configuração do elemento Role ... 226
Listagem 39. Configuração do elemento Position ... 227
Listagem 40. Transformação do relacionamento IsPartOf ... 227
Listagem 41. Transformação do relacionamento ISA ... 228
Listagem 42. Transformação do relacionamento PLAYS ... 228
Listagem 43. Transformação do relacionamento COVERS ... 229
Listagem 44. Transformação do relacionamento OCCUPIES ... 229
Listagem 45. Transformação do relacionamento INS ... 229
Listagem 46. Transformação do elemento Goal ... 230
Listagem 47. Transformação do elemento Resource ... 230
Listagem 48. Transformação do elemento Softgoal ... 231
Listagem 49. Transformação do elemento Task ... 232
Listagem 50. Tranformação DependencyLinktoDependencyLink ... 232
Listagem 51. Configuração do relacionamento ContributionLink ... 234
Listagem 52. Transformação do relacionamento TaskDecompositionLink ... 234
Listagem 53. Configuração de Feature ... 235
Listagem 54. Configuração do Relationship ... 235
BPMN Business Process Modeling Notation COVAMOF ConIPF Variability Modeling Framework CVV COVAMOF Variability View
E-SPL Early Software Product Line
ELPS Engenharia de Linha de Produto de Software
FODA Feature Oriented Domain Analysis G2SPL Goal to Software Product Line
GCL-Tool Goal and Context for Product Line - Tool; GMF Graphical Modeling Framework
GORE Goal Oriented Requirements Engineering
GORE-SPL Goal Oriented Requirements Engineering for Software Product Lines GS2SPL Goals and Scenarios to Software Product Line
GSC2SPL Goal, Scenários and Contexts to Software Produtct Line i*-c i* with cardinality
LPS Linha de Produto de Software
MSVCM Modeling Scenario Variability as Crosscutting Mechanisms OCL Object Constraint Language
OVM Orthogonal Variability Model PC Presence Condition
PSSUQ Post-Study System Usability Questionnaire SD Strategic Dependency
1.1. Problema e Motivação ... 18
1.2. Questão de Pesquisa e Objetivos ... 18
1.3. Metodologia ... 19
1.4. Organização do Trabalho ... 20
2 REFERENCIAL TEÓRICO ... 22
2.1. Engenharia de Linha de Produto de Software ... 22
2.1.1. Modelo de Features ... 24
2.2. Engenharia de Requisitos Orientada a Objetivos ... 26
2.2.1. Modelo de Contexto ... 27 2.2.2. Processos ... 31 2.2.2.1E-SPL ... 31 2.2.2.2 GS2SPL ... 42 2.3. Trabalhos Relacionados ... 63 2.4. Considerações Finais ... 65
3 GOALS, SCENARIOS and CONTEXTS to SOFTWARE PRODUCT LINE - GSC2SPL ... 67
3.1. Engenharia de Domínio ... 70
3.2. Engenharia de Aplicação ... 98
3.3. Considerações Finais ... 109
4 FERRAMENTA GCL-Tool E TESTE DE USABILIDADE ... 111
4.1. Visão geral da ferramenta ... 111
4.2. Ferramenta ... 113
4.2.1. Editor de Contextos ... 113
4.2.2. Editor de Modelo de Features ... 113
4.2.3. Editor i*-ortogonal ... 115
4.2.4. Editor i*-wiki ... 116
4.2.5. Editor de Cenário de Caso de Uso ... 117
4.2.6. Módulo de Engenharia de Domínio ... 118
4.2.7. Módulo de Engenharia de Aplicação ... 118
4.3. Teste de Usabilidade... 120
4.3.4. Execução do teste ... 121 4.3.5. Resultados ... 122 4.4. Considerações Finais ... 126 5 EXEMPLO DE APLICAÇÃO ... 129 5.1. Engenharia de Domínio ... 131 5.2. Engenharia de Aplicação ... 159 5.3. Considerações Finais ... 171
6 CONCLUSÕES E TRABALHOS FUTUROS ... 173
6.1. Conclusões ... 173
6.2. Contribuições ... 175
6.3. Limitações ... 178
6.4. Trabalhos Futuros ... 179
REFERÊNCIAS ... 180
A Detalhes do Editor de Contexto ... 187
B Detalhes do Editor de Modelo de Features ... 191
C Detalhes do Editor i*-Ortogonal ... 195
D Detalhes do Editor i*-wiki ... 204
E Transformações ... 209
F The Post-Study System Usability Questionnaire (PSSUQ) ... 237
1
INTRODUÇÃO
A engenharia de requisitos tem como objetivo descobrir as reais necessidades dos stakeholders1. A engenharia de requisitos engloba as atividades de descoberta, documentação e manutenção de um conjunto de requisitos para um sistema computacional. Essas atividades são importantes no desenvolvimento de software, pois as mesmas tornam do mesmo mais sistemático e disciplinado, consequentemente, reduzem os riscos de falhas no desenvolvimento (KOTONYA; SOMMERVILLE, 1998).
A Engenharia de Requisitos Orientada a Objetivos (do inglês, Goal Oriented Requirements Engineering ou GORE) pode ser utilizada para representar os objetivos dos stakeholders em modelos de objetivos (LAMSWEERDE, 2001). Entre as diversas abordagens GORE que têm recebido destaque nos últimos anos, pode-se citar o framework i* (YU, 1995). Segundo YU (1995), o framework i* possui uma estrutura conceitual rica, capaz de representar motivações, intenções e raciocínios sobre as características do sistema.
Por outro lado, o desenvolvimento baseado em Linha de Produto de Software (LPS) é um paradigma que tem sido reconhecido como uma abordagem eficiente para o reuso de software (BOSCH et al., 2002). Segundo CLEMENTS e NORTHROP (2002), uma LPS é “um conjunto de sistemas de software que compartilham um conjunto gerenciado de features para satisfazer as necessidades específicas de um segmento de mercado”. A grande diferença entre o desenvolvimento de sistemas através dos processos de engenharia de software habituais e os processos de desenvolvimento de software a partir de uma LPS, é a definição explícita de variabilidade (BUHNE; LAUENROTH; POHL, 2005 apud LIMA, 2011).
1 Stakeholders: são indivíduos que usam, solicitam e desenvolvem o sistema, que se interessam para que ele sejadesenvolvido (por exemplo: analistas, clientes, investidores e usuários) (KOTONYA e SOMMERVILLE, 1998)
Segundo POHL, BOCKLE e VAN DER LINDEN (2005), a engenharia de requisitos tanto pode ser aplicada para desenvolver produtos de software únicos, como para desenvolver uma LPS. Na engenharia de requisitos para LPS, o modelo de features é utilizado para capturar as similaridades e variabilidades dos seus produtos (KANG et al., 1990). Mas segundo SILVA, BORBA e CASTRO (2011), é um grande desafio estabelecer um relacionamento entre as features de um produto de software e os objetivos dos stakeholders. Além disso, o modelo de features não permite justificar porque um determinado conjunto de features foi selecionado para configurar um produto específico na LPS (GUEDES et al., 2012).
Nesse caso, abordagens GORE para LPS (ou ainda, GORE-SPL – Goal Oriented Requirements Engineering for Software Product Lines) podem ser usadas de forma efetiva para capturar tanto os objetivos dos stakeholders como os requisitos de um software único ou de uma LPS, de modo que o software a ser desenvolvido corresponda ao que realmente os stakeholders desejam (LAMSWEERDE, 2001 apud GUEDES, 2012). Entre essas abordagens pode-se citar o modelo de objetivos (YU et al., 2008), i* Aspectual (SILVA, et al., 2008), PL-AOVGraph (SANTOS; SILVA; BATISTA, 2011), G2SPL (BORBA, 2009), GS2SPL (GUEDES, 2012), mapeamento objetivos-features (ASADI et al., 2011) e E-SPL (LIMA, 2011).
Por outro lado, modelos GORE-SPL não possibilitam representar os aspectos comportamentais da LPS. Nesse sentido, cenários de caso de uso são utilizados para descrever os aspectos comportamentais da LPS. Existem trabalhos referentes a adaptações de cenários de caso de uso para o contexto de LPS. Dentre esses trabalhos, pode-se citar o PLUS (GOMAA, 2004), PLUC (BERTOLINO et al., 2006), PLUSS (ERIKSSON; BÖRSTLER; BORG, 2009) e o MSVCM (BONIFÁCIO; BORBA, 2009).
Além da necessidade de especificar o comportamento da LPS. Também é necessário considerar o estado do contexto no qual o produto da LPS será implantado. Assim, elaborar modelos de objetivos sem levar em consideração informações contextuais é um problema, pois segundo ALI; DALPIAZ; GIORGINI (2010) o contexto pode influenciar os objetivos do usuário e a satisfação de suas
necessidades. Por exemplo, uma tarefa que utiliza algum serviço online apenas poderá será satisfeita se o contexto do ambiente possuir acesso a internet.
Tendo em vista esse fato, trabalhos têm explorado o uso de contextos para configurar o sistema de forma que seus requisitos atendam as necessidades dos stakeholders, dos quais podemos citar (SOUZA; MYLOPOULOS, 2009), (DALPIAZ; GIORGINI; MYLOPOULOS, 2009); (ALI; DALPIAZ; GIORGINI, 2010), (LAPOUCHNIAN; MYLOPOULOS, 2009).
Segundo VIEIRA et al. (2009), o termo contexto possui várias definições. Em BAZIRE; BRÉZILLON (2005), há cerca de 150 definições relacionadas a diversos domínios e os autores concluíram principalmente que (i) o contexto representa um conjunto de restrições que exerce influência sobre o comportamento de um sistema "embutido em uma dada tarefa", e que (ii) a definição de contexto está vinculada à área de conhecimento à qual pertence.
Analisando algumas definições de contexto, percebeu-se que a definição de ALI; DALPIAZ; GIORGINI (2010) é a que mais se relaciona a este trabalho. Segundo esses autores, “contexto é um estado parcial do mundo, que é relevante para os objetivos de um ator”. No entanto, nota-se que essa definição é um pouco genérica e, por isso, esse trabalho define contexto como “o conjunto de recursos físicos e estados do mundo, que podem estar presentes ou ocorrer no ambiente em que a aplicação será implantada e exerce influência no comportamento de um sistema para alcançar os objetivos dos stakeholders”. Com essa definição é possível expressar, em tempo de projeto (design time), quais são os recursos físicos que estarão presentes no ambiente, quais são os possíveis estados do mundo relacionados ao ambiente da aplicação e como eles influenciarão o comportamento de um sistema.
No restante deste capítulo será apresentado o problema, a motivação, os objetivos, a metodologia e a estrutura da dissertação.
1.1. Problema e Motivação
O processo GS2SPL (Goals and Scenarios to Software Product Line) (GUEDES, 2012) tem como objetivo modelar a LPS em um modelo de objetivos i*-c (do inglês, i* with cardinality) (BORBA, 2009), e a partir desse, obter o modelo de features e os cenários de caso de uso. Esse processo também possui um subprocesso de configuração de produto, o qual leva consideração a priorização de requisitos não funcionais (RNFs).
Através da priorização de RNFs, o subprocesso de configuração consegue estimar qual a configuração que melhor irá satisfazer os RNFs desejados pelo usuário. Em contrapartida, nesse subprocesso, não é levado em consideração o estado do contexto em que a aplicação gerada será implantada. Isso é um problema, pois a não consideração de informações contextuais pode resultar na configuração de artefatos de requisitos que não corresponde ao que o stakeholder deseja. Também se percebe a ausência de um suporte ferramental para auxiliar na execução das atividades do processo.
Com base nesses problemas, na próxima subseção serão apresentadas as questões de pesquisa e os objetivos deste trabalho.
1.2. Questão de Pesquisa e Objetivos
A questão de pesquisa que se deseja responder neste trabalho é: É possivel realizar a configuração do modelo de features e cenários de caso de uso obtidos a partir de modelo de objetivos, levando em consideração os requisitos não-funcionais e as informações sobre o contexto aonde a aplicação gerada será inserida?
Além da questão que diz respeito ao processo, foram elaboradas duas questões de pesquisa secundárias, que dizem respeito à ausência de suporte ferramental.
É possível obter o modelo de features e os cenários de caso de uso a partir de modelo objetivos de uma LPS usando transformação de modelos?
É possível configurar o modelo de objetivos, o modelo de features e os cenários de caso de uso para um produto da LPS usando transformação de modelos?
Para responder a pergunta de pesquisa principal, foi traçado o seguinte objetivo:
I. Estender o processo GS2SPL para que o mesmo realize a atividade de configuração levando em consideração o contexto com base nas atividades de configuração do processo E-SPL. Como resultado dessa extensão, será criado o processo GSC2SPL (Goal, Scenarios and Contexts to Software Product Line).
Para responder as questões de pesquisas secundárias foram traçados os seguintes objetivos:
I. Desenvolver a ferramenta GCL-TOOL (Goal and Context for Product
Line - Tool);
I. Desenvolver editores gráficos para modelar o modelo i*-ortogonal, o modelo de features, o modelo de contextos e também o modelo i*-wiki; II. Desenvolver um editor para manipular os cenários de caso de uso; III. Elaborar transformações entre modelos para auxiliar a execução do
processo.
1.3. Metodologia
No contexto de Engenharia de Software, pode-se classificar os métodos de pesquisa em quatro tipos: científico, da engenharia, empírico, analítico (WOHLIN, et al., 2000 apud TRAVASSOS, 2002). Este trabalho foi desenvolvido utilizando o método da engenharia que consiste em estudar as soluções existentes, identificar seus problemas e propor mudanças ou uma nova solução.
Inicialmente foi realizado um levantamento bibliográfico a respeito de Engenharia de Linha de Produto de Software e Engenharia de Requisitos Orientada a Objetivos. Também foi realizada a procura de trabalhos relacionados, sendo que
essa procura foi feita de maneira informal, ou seja, não foi realizada uma revisão sistemática. Para os trabalhos encontrados, realizou-se um estudo minucioso nos trabalhos que apresentam os processos GS2SPL e E-SPL, pois o presente trabalho é uma extensão do GS2SPL e também considera as atividades de configuração do E-SPL.
Paralelamente ao levantamento bibliográfico, foi estudado sobre metamodelagem, transformação de modelos e os frameworks Graphical Modeling Framework (GMF) (GMF, 2014) e Epsilon (EPSILON, 2014) utilizados no desenvolvimento da ferramenta GCL-Tool.
Posteriormente foi elaborada a extensão no processo GS2SPL, a qual foi chamada de GSC2SPL (Goal, Scenarios and Contexts to Software Produtct Line). Essa extensão tem como objetivo alterar o subprocesso de configuração do GS2SPL.
Após a elaboração do processo GSC2SPL e o desenvolvimento da ferramenta, foi realizada uma exemplificação do processo com a utilização da ferramenta. Neste momento foi possível demonstrar a execução do processo de forma detalhada, bem como a utilização da ferramenta. Também foi realizado um teste de usabilidade na ferramenta.
Por fim, as conclusões do trabalho foram realizadas, incluindo uma breve comparação entre o processo GSC2SPL e os processos GORE-SPL existentes.
1.4. Organização do Trabalho
O restante desta dissertação encontra-se estruturado da seguinte forma:
Capítulo 2 – Fundamentação Teórica – apresenta os principais conceitos de
Engenharia de Linha de Produto de Software, Engenharia de Requisitos Orientada a Objetivos. Também são apresentados alguns processos GORE-SPL relacionados a este trabalho.
Capítulo 3 – Goal, Scenarios and Contexts to Software Product Line -GSC2SPL - apresenta o processo -GSC2SPL (Goal, Scenários and Contexts to Software Product Line), o qual tem por objetivo auxiliar a fase de requisitos dos
subprocessos de Engenharia de Domínio e Engenharia de Aplicação. O processo é exemplificado com a LPS Medi@ (ANTONIO, 2008).
Capítulo 4 – Ferramenta GCL-Tool e Teste de Usabilidade - apresenta uma
visão geral da ferramenta GCL-Tool. Também apresenta o teste de usabilidade relizado na ferramenta.
Capítulo 5 – Exemplo de Aplicação – apresenta uma exemplificação do
processo GSC2SPL com a utilização da ferramenta GCL-Tool. Para essa exemplificação é utilizada a LPS Smart Home (SIMÃO, 2010).
Capítulo 6 – Conclusões e Trabalho Futuros – apresenta as conclusões
deste trabalho. É apresentado um comparativo entre o processo proposto e os trabalhos relacionados. As contribuições, limitações e trabalhos futuros são descritos.
2
REFERENCIAL TEÓRICO
Nesse capítulo, os conceitos necessários para o entendimento do trabalho são apresentados. Na subseção 2.1 os conceitos de Engenharia de Linha de Produto de Software são apresentados, evidenciando os subprocessos de engenharia de dominio e engenharia de aplicação. Também é apresentado e exemplificado o modelo de features. Na subseção 2.2 os conceitos da Engenharia de Requisitos Orientada a Objetivos são apresentados. Também é apresentado o modelo de contextos. Por fim, os processos E-SPL e GSC2SPL, são apresentados e exemplificados. Na subseção 2.3 outros processos relacionados são brevemente apresentados. Ainda na subseção 2.3 é realizada uma comparação entre todos os processos apresentados anteriormente. Por fim, na subseção 2.4 as considerações finais do capítulo são realizadas.
2.1. Engenharia de Linha de Produto de Software
Uma LPS é um conjunto de sistemas de software que compartilham um conjunto comum e gerenciado de features. Uma feature pode ser vista como uma propriedade do sistema ou funcionalidade que é relevante para alguns stakeholders (CZARNECKI; EISENECKER, 2000). Além de feature, a LPS pode compartilhar a arquitetura, decisões de projeto, código, artefatos de testes, linguagens, entre outras características de produto e do processo de desenvolvimento (BONIFÁCIO, 2010).
Segundo NASCIMENTO (2008), as principais vantagens da utilização de uma LPS são o aumento da qualidade, redução do esforço de manutenção, redução dos custos de desenvolvimento e também a redução do tempo para o produto chegar ao mercado.
Para a construção de uma LPS POHL; BÖCKLE e VAN DER LINDEN (2005), definiram a Engenharia de Linha de Produto de Software (ELPS), que é um paradigma para desenvolver sistemas de software usando plataformas de customização em massa. Os mesmos autores também propuseram um framework
que separa a ELPS em dois subprocessos, engenharia de domínio e engenharia de aplicação. Os subprocessos são apresentados na Figura 1.
Figura 1. Framework de Linha de Produto de Software
Fonte: POHL, BOCKLE e VAN DER LINDEN (2005)
O subprocesso de engenharia de domínio (Domain Engineering) tem como objetivo a construção do core assets2. As atividades deste subprocesso são as seguintes: o Gerenciamento de Produto (Product Management) que visa definir o que irá fazer parte ou não do escopo da LPS; Engenharia de Requisitos de Domínio (Domain Requirements Engineering) engloba todas as atividades de elicitação, análise, documentação e validação de requisitos da LPS; Realização de Domínio (Domain Realisation) é responsável por definir a arquitetura de referência da LPS; Teste de Domínio (Domain Testing) consiste em validar e verificar os componentes reutilizáveis.
2
Por outro lado, o subprocesso de engenharia de aplicação (Application Engineering) é responsável por derivar as aplicações da LPS. Ela utiliza o core assets estabelecido na engenharia de domínio. As atividades deste subprocesso são as seguintes: Engenharia de Requisitos de Aplicação (Application Requirements Engineering) tem como objetivo gerar a documentação de um produto especifico; Projeto de Aplicação (Application Design) está relacionado à configuração da arquitetura de referência, além da inclusão de adaptações específicas ao produto; Realização de Aplicação (Application Realisation) tem por objetivo realizar a seleção e configuração dos componentes de software reutilizáveis, bem como a implementação das características específicas da aplicação (POHL, BOCKLE e VAN DER LINDEN, 2005); Testes de Aplicação (Application Testing) é responsável por validar e verificar a aplicação gerada.
A possibilidade de gerar diversos produtos no subprocesso de engenharia de aplicação é devido à variabilidade da LPS. Segundo POHL; BÖCKLE e VAN DER LINDEN (2005), a variabilidade em uma LPS possibilita o desenvolvimento de aplicações customizadas através do reuso de artefatos predefinidos e ajustáveis.
Foram propostas diversas abordagens para a representação da variabilidade de uma LPS, tais como: o Modelo de Visão da Variabilidade de COVAMOF (COVAMOF Variability View - CVV) (SINNEMA et al., 2004); (ii) o Modelo de Features (Feature Model – FM) (KANG et al., 1990); (CZARNECKI; EISENECKER, 2000); o Modelo Ortogonal de Variabilidade (Orthogonal Variability Model – OVM) (POHL; BÖCKLE; VAN DER LINDEN, 2005). Nesta dissertação será utilizado o modelo de features para representar a variabilidade, pois no processo GS2SPL é proposto um mapeamento entre o modelo de objetivos e o modelo de features. O modelo de features é apresentado a seguir.
2.1.1. Modelo de Features
O modelo de features é utilizado para capturar as similaridades e variabilidades de uma LPS (KANG, et al., 1990). O modelo de features foi proposto por KANG, et al (1990), como parte integrante da metodologia FODA (Feature Oriented Domain Analysis). Como mencionado em LIMA (2011), em trabalhos posteriores a notação e os conceitos do modelo de features sofreram diversos
aprimoramentos, onde se destacam: (i) cardinalidade de features (CZARNECKI et al., 2002); (ii) grupo de cardinalidades (RIEBISCH; STREITFERDT; PASHOV, 2004); (iii) referências/atributos em modelos de features (CZARNECK; HELSEN.; EISENECKER, 2004, 2005). Nessa dissertação será utilizada a notação do modelo de features de CZARNECK; HELSEN.; EISENECKER (2005).
O modelo de features é um gráfico hierárquico que representa o relacionamento entre features. Uma feature, por sua vez, pode ser classificada em obrigatória (todos os produtos da família devem contê-la) ou opcional (os produtos podem contê-la ou não). As features também podem ser reunidas em grupos, os quais podem ser do tipo Ou-Exclusivo (os produtos devem conter exatamente uma feature de um grupo) ou Ou-Inclusivo (os produtos devem conter pelo menos uma feature de um grupo).
Para melhor exemplificar, será apresentado o modelo de features da LPS TaRGeT (TARGET, 2011). Essa LPS tem como objetivo gerar suítes de testes automaticamente, a partir de documentos de requisitos. Cada suíte de testes gerada é formada por vários casos de teste que são criados de maneira independente. O seu modelo de features parcial é apresentado na Figura 2, e logo em seguida, será descrito.
Figura 2. Modelo de Features da LPS Target
A feature TaRGet representa a LPS a feature root. A ligação entre a feature Target e a feature Editor de Caso de Uso indica que feature Target é pai da feature Editor de Caso de uso. A feature Editor de Caso de Uso está com um circulo aberto, assim representando que a mesma é uma feature opcional. A feature Fazer Upload de Documento possui um circulo fechado, assim representado que a mesma é uma feature obrigatória. As features Word, Excel e XML fazem parte de um grupo do tipo ou-inclusivo, indicando que no mínimo uma feature que no maxímo três feature podem ser selecionadas. Já as features Português e Inglês fazem parte de um grupo do tipo or-exclusive, indicando que apenas uma das features devem ser selecionadas.
O modelo de features não permite expressar os objetivos do usuário em relação a uma determinada feature. Também não há uma maneira sistemática para construir o modelo de features. Visando solucionar esses problemas, abordagens GORE-SPL tem procurado obter de maneira sistemática o modelo de features a partir de modelos de objetivos, assim possibilitando estabelecer um relacionamento entre features e objetivos dos stakeholders (ANTONIO, 2009).
2.2. Engenharia de Requisitos Orientada a Objetivos
Segundo LAMSWEERDE (2001), um objetivo é aquilo que o sistema deverá atingir. A Engenharia de Requisitos Orientada a Objetivos (LAMSWEERDE, 2001) visa elaborar modelos de objetivos para representar os requisitos do sistema com base nos objetivos dos stakeholders, de modo que o software a ser desenvolvido corresponda ao que realmente os stakeholders desejam.
Existem diversas linguagens GORE para especificação de requisitos, tais como i* (YU, 1995), i*-Wiki (GRAU, et al., 2008), Tropos (CASTRO; KOLP; MYLOPOULOS, 2002) (BRESCIANI et al., 2004), i*-Aspectual (ALENCAR et al., 2008), KAOS (LAMSWEERDE, 2003); V-graph (YU et al., 2008), framework NFR (CHUNG, et al., 2000), e modelo de objetivos (YU, et al., 2008). No contexto de GORE-SPL, existem as linguagens c (i* with cardinality) (BORBA, 2009), i*-ortogonal (LIMA, 2011).
No contexto LPS também existem diversos processos GORE para SPL, os quais possuem como intuito auxiliar o desenvolvimento da LPS a partir da utilização
de modelos de objetivos. Entre esses processos é possivel citar a variabilidade em Modelos de Objetivos por (YIJUN YU et al., 2008) (YU, 2008); iStar-LPS (ANTÓNIO, ARAÚJO e SILVA, 2009); G2SPL (BORBA, 2009); PL-AOVGraph (SILVA, et al., 2011); (SANTOS, SILVA e BATISTA, 2011), Mapeamento goal-feature (ASADI, et al., 2011).GS2SPL (GUEDES, 2012), E-SPL(LIMA, 2011).
Além de representar a variabilidade em modelos de objetivos, também é necessário associar contextos aos requisitos, pois um contexto pode influenciar um requisito (LIMA, 2011). Nesse sentido, abordagens tem procurado representar contextos em modelos de objetivos. Nessa dissertação será utilizado o framework de ALI; DALPIAZ; GIORGINI (2010) para realizar a modelagem dos contextos. Esse framework foi escolhido, pois com ele é possível antecipar a análise de variabilidade, adotando uma ontologia intencional sobre modelos de objetivos (LIMA, 2011).
A seguir será apresentado o framework de modelagem de contexto. Logo após serão apresentados os processos E-SPL e GS2SPL.
2.2.1. Modelo de Contexto
No framework de ALI; DALPIAZ; GIORGINI (2010), duas definições são importantes: (i) ator, é uma entidade que possui objetivo e pode decidir de maneira autonôma como alcança-los, e; (ii) contexto, é um estado parcial do mundo que é relevante para satisfazer os objetivos dos atores.
Segundo ALI; DALPIAZ; GIORGINI (2010), o contexto pode ser definido por fatos (facts – F) e declarações (statements – S). Segundo os mesmos autores, fato é uma sentença que pode ser verificada, de maneira que é possível capturar os dados necessários para determinar se o mesmo é verdadeiro. Já uma declaração é uma sentença que não pode ser verificada, seja pela falta de informação inerente aos dados necessários para determinar se a mesma é verdadeira, seja pela natureza abstrata da declaração. Por sua vez, as declarações podem ser sustentadas por um conjunto de fatos ou ainda por outras declarações.
A análise do contexto pode ser realizada através da decomposição de fatos e declarações. A semântica dos elementos desse modelo é apresentada na Tabela 1.
Tabela 1. Semântica dos pontos de variação contextuais
Elemento Representação Visual
1 Contexto 2 Fato Fato 3 Declaração Declaração 4 E(AND) – obrigatório 5 OU(OR) – opcional 6 Implica 7 Suporta
Fonte: ALI, DALPIAZ e GIORGINI (2010)
De acordo com ALI, DALPIAZ e GIORGINI (2010), Contexto é o elemento root; Fato (Fact) é uma sentença verificável; Declaração (Statement) é uma sentença não-verificável; AND é um relacionamento entre fatos, declarações ou fatos e declarações, de natureza obrigatória (ou seja, todas as sentenças devem ser avaliadas); OR é um relacionamento entre fatos, declarações ou fatos e declarações, de natureza alternativa (ou seja, uma única ou algumas sentenças podem ser avaliadas); Implica é o relacionamento em que o contexto (root) tem com um fato ou com um relacionamento de obrigatoriedade (AND); Suporta é
relacionamento em que uma declaração tem com relacionamentos AND/OR e com o fato, a fim de justificar (ou eliminar a natureza não-verificável da declaração). Um detalhe interessante nesta análise é que uma declaração nunca poderá ser nó filho da árvore de análise de contexto, de forma que sempre que existir uma declaração, deverá existir um relacionamento de suporta, para que sejam inseridos fatos que “concretizem” a declaração.
Também é possível anotar os contextos elaborados em modelos de objetivos contextuais, a fim de representar se um objetivo depende de um ou mais contextos. Para realizar a associação, foram propostos pontos de variação contextuais, os quais são apresentados na Tabela 2.
Tabela 2. Pontos de Variação Contextuais
Pontos de Variação Contextual Sintaxe Visual
1 1 Root Goal ( 2 OR-Decomposition ( 3 AND- Decomposition ( 4 Mean-End ( 5 Actor Dependency ( 6 Softgoal Contribution Fonte: LIMA (2011)
Sendo Gi o root goal, Gi apenas é ativado se o contexto C1 for verdadeiro, como apresentado na linha 1. A tarefa Ti é alcançado através da tarefa Tj caso o contexto C1 seja verdadeiro, como apresentado na linha 2. O objetivo Gj auxilia a satisfação do objetivo Gi caso o contexto C1 seja verdadeiro, como apresentado na
verdadeiro, como apresentado na linha 4. O ator A pode alcançar o objetivo Gi através da atribuição deste objetivo para o ator B se o contexto C1 for verdadeiro, como apresentado na linha 5. O objetivo Gi contribui positivamente para o softgoal SGi se o contexto C1 for verdadeiro e contribui negativamente se o contexto C2 for verdadeiro, como apresentado na linha 6.
Também é possível realizar a priorização de softgoals para verificar qual é a variante que melhor satisfaz os requisitos não-funcionais do stakeholders em relação ao sistema.
A priorização de softgoal adotada é baseada na priorização de softgoal proposta em ASADI et al., (2011). A prioridade segundo ALI, DALPIAZ e GIORGINI (2009) é obtida a partir da seguinte fórmula:
priority(v) = ∑ percentPos(v, sg) × priority(sg) sg ∈ v − ∑ percentNeg(v, sg) × priority(sg) sg∈v (1) Onde: 𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑃𝑜𝑠(𝑣, 𝑠𝑔) = 𝑛𝑢𝑚𝐶𝑜𝑛𝑡𝑃𝑜𝑠(𝑠𝑔) 𝑛𝑢𝑚𝐶𝑜𝑛𝑡𝑃𝑜𝑠𝑇𝑜𝑡𝑎𝑙 (2) 𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑁𝑒𝑔(𝑣, 𝑠𝑔) = 𝑛𝑢𝑚𝐶𝑜𝑛𝑡𝑁𝑒𝑔(𝑠𝑔) 𝑛𝑢𝑛𝐶𝑜𝑛𝑡𝑁𝑒𝑔𝑇𝑜𝑡𝑎𝑙 (3)
A variável priority(sg) é o valor de prioridade que o usuário atribui a um determinado softgoal e ela pode estar no intervalo de [0,n]. Segundo ALI, DALPIAZ e GIORGINI (2009) a prioridade 0 corresponde a “usuário não se preocupa com o softgoal”, já a prioridade n diz que “o usuário considera o softgoal muito importante”. A variável percentPos(v,sg) refere-se a percentagem de contribuições positivas de uma variante v a um determinado softgoal sg em relação número total de contribuições positivas da variante v. Já a variável percentNeg(v,sg) refere-se a
percentagem de contribuições negativas de uma variante v a um determinado softgoals sg em relação do número total de contribuições negativas da variante v.
2.2.2. Processos 2.2.2.1E-SPL
O processo E-SPL (do inglês, Early Software Product Line) (LIMA, 2011) tem como objetivo auxiliar os subprocessos de engenharia de domínio e engenharia de aplicação através do gerenciamento de variabilidade em modelos de objetivos. A representação de variabilidade é realizada através da linguagem i*-ortogonal (LIMA, 2011). Além da representação da variabilidade, esse processo também permite realizar a configuração do produto em nível de modelo de objetivos. Na configuração é levada em consideração a priorização de requisitos não funcionais e o contexto onde a aplicação gerada será implantada.
A Figura 3 mostra uma visão geral do processo E-SPL descrita utilizando a notação BPMN (do inglês, Business Process Modeling Notation) (2014). As atividades do processo são agrupadas nos subprocessos de engenharia de domínio e engenharia de aplicação.
Engenharia de Domínio
Esse subprocesso tem como objetivo gerar o modelo i*-ortogonal da LPS. No entanto, para questão de entendimento, o modelo i*-Ortogonal foi classificado nas seguintes categorias: (i) intencional, é aquele que possui informações básicas de variabilidade identificadas nos requisitos do sistema/organização (pontos de variação, variantes e relacionamentos de variabilidade); (ii) contextual, é aquele onde os contextos de variabilidade são associados aos relacionamentos de variabilidade; e, (iii) ortogonal, que é aquele onde as noções de variabilidade mais avançadas são introduzidas (cardinalidades, agrupamentos com cardinalidades).
Figura 3. Diagrama BPMN do processo E-SPL
Fonte: LIMA (2011)
A seguir, as atividades do subprocesso de engenharia de domínio são apresentadas e exemplificadas.
Atividade 1 - Especificar os requisitos em modelo de objetivos
Nessa atividade é criado o modelo i*-ortogonal intencional, sendo que esse modelo é classificado em inicial e final. O modelo i*-ortogonal intencional inicial tem como objetivo modelar os atores e os relacionamentos entre os mesmos. Já o modelo i*-ortogonal intencional final tem como objetivo detalhar as atividades do ator que representa a LPS.
Passo 1 - Criar o modelo i*-Ortogonal Intencional inicial: é realizada a
modelagem dos atores e as dependências entre os mesmos. Para alcançar tais objetivos as seguintes regras devem ser seguidas:
Regra 1 - Atores: todo sujeito que realiza alguma atividade ou que dependa de algum outro indivíduo para realização da sua atividade.
Regra 2 - Dependências entre atores: é a atividade compartilhada por dois sujeitos dentro do contexto organizacional.
Exemplo: após a realização das regras desse passo, é gerado o modelo
i*-ortogonal intencional inicial, o modelo gerado é apresentado na Figura 4. Através da regra 1 são descobertos os atores Mobile Media e Usuário. Através das regras 2 são descobertos os seguintes relacionamentos: o ator Usuário depende do ator Mobile Media para ter o softgoal Integridade [Fotos] satisfeito, bem como para alcançar o objetivo Adição de Foto e também obter o recurso Álbum. Já o ator Mobile Media depende do ator Usuário para obter os recursos: Local, Foto e Nome, bem como para ter o softgoal Precisão [Local] satisfeito.
Figura 4. Modelo i*-ortogonal intencional inicial do Mobile Media
Fonte: LIMA (2011)
Passo 2 - Criação do modelo i*-Ortogonal Intencional final: é realizado o
detalhamento das atividades atribuídas ao ator principal. Opcionalmente, os atores secundários também poderão ser detalhados. Para alcançar tal objetivo as seguintes regras devem ser seguidas:
Regra 3 - Modelagem do objetivo do ator: é a atividade de análise da documentação oriunda do sistema, a fim de identificar os objetivos do ator que está sendo analisado;
Regra 4 - Modelagem das tarefas e suas decomposições: é a atividade de análise da documentação oriunda do sistema, a fim de identificar a tarefa e as subtarefas realizadas por determinado ator.
Regra 5 - Identificação/Modelagem das tarefas que consomem/produzem recursos: são identificados os recursos derivados da realização das tarefas. Os recursos, por sua vez, podem ser físicos (concretos) ou informacionais (abstratos).
Regra 6 - Modelagem de tarefas alternativas: alguns objetivos podem ser satisfeitos a partir da execução de uma ou mais tarefa, assim é necessário realizar a modelagem das alternativas para a satisfação de uma tarefa.
Regra 7 - Modelagem de aspectos não-funcionais do ator (ou dependência): para cada requisito não-funcional relacionado ao próprio ator, deve ser criado um softgoal dentro do mesmo ou como uma dependência.
Regra 8 - Modelagem de aspectos não-funcionais das tarefas: para cada requisito não-funcional relacionado a uma função específica, não relacionado a uma característica não-funcional do ator ou sua dependência, deve ser criado um softgoal na decomposição da tarefa relacionada à função específica.
Exemplo: após a execução desse passo é criado o modelo i*-Ortogonal
Intencional final, o qual é apresentado na Figura 5. Através da Regra 3 são criados os objetivos Salvar Foto, Gerenciamento de mídia, Álbum Selecionado e Atualização de Lista de Fotos. Através da Regra 4 são identificadas as tarefas Gerenciamento de Mídia, Adicionar Foto, Armazenar Foto, Salvar Automaticamente, Salvar Pelo Usuário. Ao aplicar a Regra 5 percebe-se que os recursos Local, Foto e Nome já foram modelados, assim apenas é necessário apenas relacionar os mesmo as tarefas que os consomem/produzem. É criado um relacionamento entre a tarefa Armazenar Foto e os recursos Local e Álbum, esses relacionamentos indicam que a realização da tarefa é necessário informações sobre o Local e o Álbum. Ainda aplicando a diretriz 5, é criado um relacionamento entre a tarefa Salvar pelo Usuário e o recursos Nome. Aplicando a Regra 6 é criado um relacionamento meio fim entre o objetivo Salvar Foto e as tares Salvar Automaticamente e Salvar Pelo Usuário. Aplicando a Regra 8 é criado o softgoal Rapidez [Armazenamento].
Figura 5. Modelo i*-Ortogonal Intencional Final para a LPS Mobile Media
Fonte: LIMA (2011)
Atividade 2 - Especificar o modelo de contextos
Esta atividade tem por objetivo documentar os diferentes contextos existentes no ambiente no qual o sistema está inserido. Para este fim, serão utilizados os conceitos expressos por Ali, Dalpiaz e Giorgini (2009). Além de documentar os contextos, também será realizada a associação dos contextos com os objetivos do modelo ortogonal intencional. Como artefato de saída será gerado o modelo i*-ortogonal contextual. Para a elaboração dos contextos e associação dos mesmos ao modelo de objetivos, as seguintes diretrizes devem ser seguidas.
Passo 1 - Criação do modelo de contextos, para criar os modelos de
contexto deve-se realizar a seguinte regra:
Regra 9 - criar o modelo de contextos através da modelagem da árvore de fatos, declarações e decomposições.
Exemplo: analisando a especificação de requisitos da LPS foi identificado o
verdadeiro se a declaração S1: O usuário deseja realizar o salvamento de suas fotos de maneira manual for suportada pelo fato F1: O sistema disponibiliza função para salvamento manual.
Figura 6. Contexto C1 - Salvar Manualmente
Fonte: LIMA (2011)
Passo 2 - Enriquecendo o modelo i*-Ortogonal Intencional com informações contextuais. Para anotar os contextos no modelo i*-ortogonal
intencional, as seguintes regras devem ser seguidas:
Regra 10 – caso o dependee/subelemento de um relacionamento (meio-fim, dependência ou contribuição) dependa de algum contexto, então o contexto deve ser associado ao respectivo relacionamento.
Exemplo: o modelo i*-ortogonal com a representação do contexto é
apresentado na Figura 7. Para executar a tarefa Salvar pelo Usuário é necessário que o contexto C1 seja verdadeiro, assim é inserido o contexto C1 na ligação meio-fim entre o objetivo Salvar Foto e a tarefa Salvar Pelo Usuário.
Atividade 3 - Representar a variabilidade
Esta atividade tem por objetivo documentar a variabilidade da LPS no modelo de objetivos i*-ortogonal contextual. Como saída dessa atividade é gerado o modelo i*-ortogonal.
Passo 1 - Definição das cardinalidades, nesta etapa o modelo i*-ortogonal
contextual é enriquecido com a cardinalidade. Para esse fim, as seguintes regras devem ser seguidas:
Regra 11 - inserir cardinalidade nos objetivos que são pontos de variação externos ao ator. O objetivo pode possuir cardinalidade obrigatória (1..1) ou opcional (0..1);
Regra 12 - inserir cardinalidade nos objetivos que são pontos de variação internos ao ator. O objetivo pode possuir cardinalidade obrigatória (1..1) ou opcional (0..1);
Regra 13 - inserir cardinalidade nos elementos do tipo Tarefa e Recurso que são internos ou externos ao ator. A cardinalidade pode ser obrigatória (1..1) ou opcional (0..1);
Regra 14 - modelar a cardinalidade nos agrupamentos internos ao ator. A cardinalidade pode ser obrigatória – cardinalidade [1..1],[1..n], opcional – cardinalidade [0..1],[0..n] ou alternativa – cardinalidade [m..n].
Regra 15 - modelar a cardinalidade nos agrupamentos externos ao ator. A cardinalidade pode ser obrigatória – cardinalidade [1..1],[1..n], opcional – cardinalidade [0..1],[0..n] ou alternativa – cardinalidade [m..n]).
Exemplo: na Figura 7 é apresentado o modelo i*-ortogonal com a
cardinalidade representada. Aplicando a regra 11, é inserida a cardinalidade obrigatória no objetivo Adição de Foto. Aplicando a regra 12, é inserida cardinalidade opcional nos objetivos, Atualização de Lista de Fotos e Álbum Selecionado. Já os objetivos Gerenciamento de Mídia e Salvar Foto possuem cardinalidade obrigatória. Aplicando a regra 13, é inserida cardinalidade obrigatória nas tarefas Gerenciamento de Mídia, Adicionar Foto e Armazenar Foto. Aplicando a regra 14, as tarefas Salvar Automaticamente e Salvar pelo Usuário são colocadas em um grupamento com cardinalidade [1..1].
Passo 2 - Definição das restrições, para modelar as restrições requires e excludes entre os elementos, as seguintes regras devem ser seguidas:
Regra 16 - caso um elemento requeiram a presença de outro elemento, então deve ser criado um relacionamento do tipo requires entre esses elementos;
Regra 17 - caso dois elementos sejam conflitantes, então deve ser criado um relacionamento do tipo excludes entre os mesmos.
Exemplo: Esse exemplo não contém restrições.
Figura 7. Modelo i*-Ortogonal para o Mobile Media
Fonte: LIMA (2011)
Engenharia de Aplicação (AE)
Esse subprocesso tem como objetivo configurar o modelo i*-wiki para uma determinada aplicação. Para realizar a configuração do modelo i*-wiki, primeiramente é criado uma ou mais variantes. Em LIMA (2011), o termo ‘variante’ é utilizado para se referir a uma possível configuração. A elaboração das variantes pode ser realizada de maneira ad-hoc ou através da utilização de contextos. Quando a elaboração das variantes é realizada através da utilização do contexto, também é realizada a priorização de variantes.
Atividade 4 - Escolher a configuração específica contextual (opcional)
A criação de uma variante levando em consideração os contextos pode ser obtida a partir do uso da técnica de enunciação de predicados de ALI, DALPIAZ e GIORGINI (2009). Essa técnica propõe que uma variante seja definida por V, a qual é composta por um conjunto de elementos avaliados em blocos (delimitados por parênteses) e relacionados através de sentenças lógicas de primeira ordem “e”, “ou”, “negação” – ou seja, and (˄), or (˅), not (¬), a fim de definir uma variante elegível para a etapa de configuração do modelo i*-Wiki. Assim sendo, a variante é composta de contextos (Context), isolados ou agrupados em sentenças lógicas (and, or, not), como apresentado na equação 4:
𝑉 = 𝐶𝑜𝑛𝑡𝑒𝑥𝑡𝑜| (𝐶𝑜𝑛𝑡𝑒𝑥𝑡𝑜)˄(𝐶𝑜𝑛𝑡𝑒𝑥𝑡𝑜)| (𝐶𝑜𝑛𝑡𝑒𝑥𝑡𝑜)˅(𝐶𝑜𝑛𝑡𝑒𝑥𝑡𝑜)|¬(𝐶𝑜𝑛𝑡𝑒𝑥𝑡𝑜) (4)
Exemplo: para o exemplo aqui apresentado foram elaboradas as variantes V1
e V2. A variante V1 diz que o contexto C1 é verdadeiro (V1 = C1) e a variante V2 diz que o contexto C1 é falso (V2 = ¬C1).
Atividade 5 – Escolher a configuração específica ad-hoc (opcional)
Esta atividade tem como intuito escolher os elementos de forma manual, ou seja, o stakeholder/analista apenas escolhe os elementos que o mesmo deseja que estejam contidos na aplicação gerada.
Exemplo: Esta atividade não será exemplificada, pois a mesma consiste em
apenas escolher os elementos de maneira manual.
Atividade 6 - Priorização de Variantes
A priorização de variantes serve para estimar qual a variante que melhor atende a satisfação dos RNFs. A priorização é realizada através da análise de softgoals. Para o cálculo da prioridade das variantes, foi adaptada a fórmula de priorização proposta por ALI, DALPIAZ e GIORGINI (2009). A adaptação ocorreu no cálculo do valor de percentPos e percentNeg. Em E-SPL foi adicionado ao cálculo desses valores o fator percentual tipoDeContPos/tipoDeContNeg. Os novos cálculos de percentPos e percentNeg são apresentado nas fórmulas 6 e 7. A fórmula do
cálculo da prioridade (fórmula 5) é apresentada novamente apenas para facilitar o entendimento.
priority(v) = ∑ percentPos(v, sg) × priority(sg) sg ∈ v − ∑ percentNeg(v, sg) × priority(sg) sg∈v (5) Onde: 𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑃𝑜𝑠(𝑣, 𝑠𝑔) = 𝑛𝑢𝑚𝐶𝑜𝑛𝑡𝑃𝑜𝑠(𝑠𝑔) 𝑛𝑢𝑚𝐶𝑜𝑛𝑡𝑃𝑜𝑠𝑇𝑜𝑡𝑎𝑙× 𝑡𝑖𝑝𝑜𝐷𝑒𝐶𝑜𝑛𝑡𝑃𝑜𝑠(𝑠𝑔) (6) 𝑝𝑒𝑟𝑐𝑒𝑛𝑡𝑁𝑒𝑔(𝑣, 𝑠𝑔) = 𝑛𝑢𝑚𝐶𝑜𝑛𝑡𝑁𝑒𝑔(𝑠𝑔) 𝑛𝑢𝑛𝐶𝑜𝑛𝑡𝑁𝑒𝑔𝑇𝑜𝑡𝑎𝑙× 𝑡𝑖𝑝𝑜𝐷𝑒𝐶𝑜𝑛𝑡𝑁𝑒𝑔(𝑠𝑔) (7)
A variável percentPos(v,sg), refere-se ao percentual de contribuições positivas de uma variante v a um determinado softgoal (sg). Por outro lado, a variável percentNeg(v,sg), refere-se ao percentual de contribuições negativas de uma variante v a um determinado softgoal (sg).
O numContPosTotal e o numContNegTotal referem-se, respectivamente, ao número de contribuições positivas e negativas no modelo de objetivos. O numContPos(sg) é o número de contribuições positivas e o tipoDeContPos(sg) leva em consideração um fator percentual para os tipos de contribuição positivas, o valor do fator percentual é definido na Tabela 3. Analogamente, numContNeg(sg) é o número de contribuições negativas e o tipoDeContINeg(sg) leva em consideração um fator percentual para os tipos de contribuição negativas definidas, o valor do fator percentual é definido na Tabela 3.
Tabela 3. Valor percentual dos links de contribuição
Contribuição Make Break Help Hurt Some + Some - Unknown
Valor 1,00 0,75 0,50 0,25
Exemplo: primeiramente é necessário definir o valor de priority. O valor de priority para o RNF Rapidez [Armazenamento] (RA) é igual a 10, assim o valor das prioridades são os seguintes:
Valor da prioridade da variante V1:
priority(v1) = −𝑛𝑢𝑛𝐶𝑜𝑛𝑡𝑁𝑒𝑔𝑇𝑜𝑡𝑎𝑙𝑛𝑢𝑚𝐶𝑜𝑛𝑡𝑁𝑒𝑔(𝑠𝑔)×𝑡𝑖𝑝𝑜𝐷𝑒𝐶𝑜𝑛𝑡𝑁𝑒𝑔(𝑠𝑔) ×𝑝𝑟𝑖𝑜𝑟𝑖𝑡𝑦(𝑅𝐴)
priority(v) = 0 − 1
1× 0,75 × 10 = 0 − 7,5 = −7,5 Valor da prioridade da variante V2:
priority(v2) = 𝑛𝑢𝑚𝐶𝑜𝑛𝑡𝑃𝑜𝑠𝑇𝑜𝑡𝑎𝑙𝑛𝑢𝑚𝐶𝑜𝑛𝑡𝑃𝑜𝑠(𝑅𝐴) ×𝑡𝑖𝑝𝑜𝐷𝑒𝐶𝑜𝑛𝑡𝑃𝑜𝑠(𝑠𝑔)× priority(RA)
priority(v) = 1
1× 0,75 × 10 = 7,5
Analisando o valor das prioridades, nota-se que a variante V2 possui o maior valor e consequentemente, essa é a variante que melhor irá satisfazer os requisitos não funcionais desejados pelo stakeholders.
Atividade 7 - Selecionar a configuração específica
Esta atividade tem como intuito configurar o modelo i*-ortogonal da variante selecionada. Após realizar a configuração é obtido o modelo i*-Wiki. Isso é possível realizando as seguintes ações:
Passo 1 - Realização das restrições: para realizar as restrições devem ser
seguidas as seguintes regras:
Regra 18 - é a atividade de efetivação das restrições do tipo requires, no sentido de inserir toda a árvore de elementos dela derivados.
Regra 19 - é a atividade de efetivação das restrições do tipo excludes, no sentido de excluir toda a árvore de elementos conflitantes.
Exemplo: este passo não é realizado, pois no modelo não existe ligações de
Passo 2. Remover a cardinalidade dos elementos com variabilidade e dos
agrupamentos. Caso persista algum agrupamento de elementos em que a quantidade de elementos é maior que a cardinalidade máxima, então é necessária a intervenção do stakeholder para realizar a escolha de quais elemento irão fazer para do produto configurado.
Exemplo: tendo em vista que a maior prioridade é a da variante V2 então essa
será utilizada para a configuração. Após realizar a configuração, o modelo i*-Wiki obtido é apresentado na Figura 8.
Figura 8. Modelo i*-wiki para o produto configurado a partir da variante V2
Fonte: LIMA (2011)
Através desse processo foi possível configurar o modelo i*-wiki para um produto da LPS. A partir da configuração, foi possível obter o modelo de objetivos com base no contexto. Porém, esse processo não permite obter o comportamento dinâmico e nem o modelo de features da LPS.
2.2.2.2 GS2SPL
O processo GS2SPL (do inglês, Goals and Scenarios to Software Product Lines) (Guedes, 2012), é um processo GORE-SPL que tem como intuito representar
a variabilidade da LPS em modelos de objetivos i*-c e obter o modelo de features e os cenários de caso de uso descrito em PLUSS. Esse processo também realiza a configuração do modelo de objetivos, modelo de features e os cenários de caso de uso. As atividades do processo são apresentadas na Figura 9.
Figura 9. Modelo BPMN do Processo GS2SPL
