tarcísio couto pereira · dissertação de mestrado apresentada por tarcísio couto pereira à...

Pós-Graduação em Ciência da Computação

BVCCoN-Tool – Uma Ferramenta para Apoiar uma

Abordagem de Configuração de Processos de Negócio

Dinâmicos

Por

Tarcísio Couto Pereira

Dissertação de Mestrado

Universidade Federal de Pernambuco

[email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE, 05/2014

Universidade Federal de Pernambuco

Centro de InformáticaPós-graduação em Ciência da Computação

Tarcísio Couto Pereira

“BVCCoN-Tool - Uma Ferramenta para Apoiar umaAbordagem de Configuração de Processos de Negócio

Dinâmicos”

Trabalho apresentado ao Programa de Pós-graduação em

Ciência da Computação do Centro de Informática da Univer-

sidade Federal de Pernambuco como requisito parcial para

obtenção do grau de Mestre em Ciência da Computação.

Orientador: Jaelson Freire Brelaz de Castro

Co-Orientador: Fernanda Maria Ribeiro de Alencar

Recife, 28 de maio de 2014

Catalogação na fonte Bibliotecário Jefferson Luiz Alves Nazareno, CRB 4-1758

Pereira, Tarcísio Couto. BVCCoN-Tool: uma ferramenta para apoiar uma abordagem de configuração de processos de negócio dinâmicos./ Tarcísio Couto Pereira. – Recife: O Autor, 2014. xxv, 125f. : fig.

Orientador: Jaelson Freire Brelaz de Castro. Dissertação (Mestrado) - Universidade Federal de Pernambuco. Cin. Ciência da computação , 2014. Inclui referências e apêndice.

1. Ciência da computação . 2. Engenharia de software. 3. Processos de negócio I. Castro, Jaelson Freire Brelaz.. (orientador). II. Título.

004 (22. ed.) MEI 2014-46

Dissertação de Mestrado apresentada por Tarcísio Couto Pereira à Pós-Graduação em

Ciência da Computação do Centro de Informática da Universidade Federal de

Pernambuco, sob o título “BVCCoN-Tool - Uma Ferramenta para Apoiar uma

Abordagem de Configuração de Processos de Negócio Dinâmicos” orientada pelo

Prof. Jaelson Freire Brelaz de Castro 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

_______________________________________________

Profa. Jaelson Freire Brelaz de Castro

Centro de Informática / UFPE

Visto e permitida a impressão.

Recife, 24 de fevereiro de 2014.

___________________________________________________

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.

Dedico esta dissertação especialmente aos meus pais Iran

Pereira Silva e Ana Maria Couto de Lucena Pereira, sem

vocês nada disso seria possível.

Agradecimentos

Primeiramente agradeço a Deus por todas as bençãos, amor, proteção e por todas ascoisas boas e maravilhosas que fazes acontecer em minha vida.

Aos meus pais Iran Pereira Silva e Ana Maria Couto de Lucena Pereira, por todoamor, amizade e felicidade que vocês me porporcionaram. Obrigado por sempre meajudar a encontrar o caminho correto a seguir e por confiar em todas as decisões quetomei. Amo vocês.

A minha noiva Luma Hannah, por todo o amor, companheirismo e dedicação duranteesses 4 anos que estamos juntos. Te agradeço por todo o apoio durante os últimos 2 anose pela compreensão e paciência nos momentos difíceis que passei. Eu te amo! A minhaamada família por me proporcionar momentos de união e felicidades. Apesar de muitasvezes longe um do outro, o amor e apoio sempre foi o mesmo.

Também agradeço aos meus amigos Jackson Raniel e Thiago Mendes pelas ideiascompartilhadas. Ao meu professor orientador Jaelson Castro, por me aceitar orientar e portoda contribuição e ensinamentos que resultaram neste trabalho. A todos meus amigos dogrupo LER (Laboratório de Engenharia de Requisitos), em especial a Emanuel Santos,Paulo de Lima, Jéssyka Flavyanne e Monique Soares por todo apoio. Aos professoresFernanda Alencar, Robson Fidalgo e ao meu amigo Edson Alves por toda ajuda duranteo desenvolvimento deste trabalho. . . .

...Some will win, some will lose

Some were born to sing the blues

Oh, the movie never ends

It goes on and on and on and on

Strangers waiting

Up and down the boulevard

Their shadows searching in the night

Streetlights, people

Living just to find emotion

Hiding somewhere in the night

Don’t stop believin’

Hold on to the feelin’

Streetlights, people...

—JOURNEY (Don’t Stop Believin’)

Resumo

Os processos estão se tornando cada vez mais complexos e heterogêneos, inseridos emambientes onde as mudanças são constantes, sendo influenciados por fatores geográficos,climáticos, dentre outros. As empresas precisam manter seus processos atualizados efuncionando adequadamente, sem desprezar os requisitos de qualidade. Baseado nestecenário, foi proposto na literatura uma abordagem de configuração de processos chamadaBVCCoN.

Esta abordagem possui como objetivo oferecer suporte a configuração de processosbaseada em NFRs e informações contextuais. A abordagem possui três perspectivasna configuração de processo de negócio: a descrição de variabilidade, os requisitosnão-funcionais e o contexto. Durante as etapas desta abordagem, é necessário realizara modelagem destas três perspectivas. Contudo, modelar as três perspectivas é umaatividade que requer tempo e que está propensa a erros.

Assim, esta dissertação propõe o desenvolvimento de uma ferramenta que apoia amodelagem dos requisitos não-funcionais, da variabilidade e das regras de contexto. Paraconstruir a ferramenta, foi realizada a integração de três metamodelos, com algumasalterações, sendo cada um referente a uma perspectiva da abordagem BVCCoN. Alémdisso, foi utilizado o framework Epsilon e seu conjunto de linguagens integrado noambiente Eclipse para o desenvolvimento da ferramenta. Para ilustrar a utilização daferramenta, foi realizado um estudo de caso em um cenário de check-in em aeroporto, bemcomo uma avaliação de usabilidade com potenciais usuários, visando avaliar os seguintesfatores: satisfação geral, utilidade do sistema, qualidade da informação e qualidade dainterface.

Palavras-chave: bvccon. processos de negócio. requisitos não-funcionais. variabilidade.contexto. ferramenta. eclipse. epsilon. eugenia.

Abstract

Processes are becoming increasingly complex and heterogeneous, embedded in an envi-ronment where changes are constant, being influenced by geographic, climatic factors,among others. Companies need to keep the processes updated and working properly,without neglecting the quality requirements. Based on this scenario, it was proposed inthe literature a process configuration approach called BVCCoN.

The goal of this approach is to offer support for processes configuration based onNFRs and contextual information. The approach has three perspectives on businessprocess configuration: the variability description, the non-functional requirements andthe contextual information. During the steps of this approach, it is necessary perform themodeling of these three perspectives. However, modeling the three perspectives is anactivity that takes time and is error prone.

Thus, this dissertation proposes the development of a tool that supports the modelingof the non-functional requirements, variability and the context rules. In order to buildthe tool, the integration of the three metamodels was performed with some changes.Each metamodel is responsible for a perspective of the BVCCoN approach. In addition,the Epsilon Framework was used and its set of languages embedded in the Eclipsedevelopment environment. In order to illustrate the use of the tool, a case study in acheck-in scenario in an airport was performed, as well as an usability evaluation withpotential users to evaluate the following factors: overall satisfaction, system usefulness,quality of information and quality of interface.

Keywords: bvvcon. business process. non-functional requirements. variability. context.tool. eclipse. epsilon. eugenia.

Lista de Figuras

2.1 Processo da abordagem BVCCoN. Adaptado de [47]. . . . . . . . . . . 34

2.2 Exemplo de modelo referência com pontos de variação. Adaptado de [48]. 36

2.3 Exemplo de variantes e pontos de variação. Adaptado de [48]. . . . . . 38

2.4 Exemplo de decomposição de contexto. Adaptado de [48]. . . . . . . . 40

2.5 RNFs e Variantes. Adaptado de [48]. . . . . . . . . . . . . . . . . . . . 42

2.6 Exemplo de uma instância de processo. Adaptado de [48]. . . . . . . . 44

2.7 Infraestrutura Tradicional MDD. Adaptado de [3]. . . . . . . . . . . . . 47

2.8 Dashboard GMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.1 Parte do Metamodelo BVCCoN . . . . . . . . . . . . . . . . . . . . . 60

3.2 Elementos Gráficos x Metamodelo - Exemplo 1 . . . . . . . . . . . . . 61



3.5 Perspectiva de Variabilidade [48] . . . . . . . . . . . . . . . . . . . . . 63

3.6 Metamodelo Variability - BVCCoN . . . . . . . . . . . . . . . . . . . 65

3.7 Perspectiva Contexto [48] . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.8 Metamodelo Contexto - BVCCoN-Tool . . . . . . . . . . . . . . . . . 70

3.9 Perspectiva RNF [48]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.10 Metamodelo RNF - BVCCoN . . . . . . . . . . . . . . . . . . . . . . . 74

3.11 Sintaxe concreta do Ponto de Variação. . . . . . . . . . . . . . . . . . . 78

3.12 Sintaxe concreta de uma Variante. . . . . . . . . . . . . . . . . . . . . 80

3.13 Sintaxe concreta de RNF. . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.14 Sintaxe concreta de Contexto. . . . . . . . . . . . . . . . . . . . . . . . 84

3.15 Editor da Ferramenta BVCCoN-Tool . . . . . . . . . . . . . . . . . . . 85

3.16 Menu de seleção da ferramenta . . . . . . . . . . . . . . . . . . . . . . 85

3.17 Modelo RNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.18 Modelo RNF e Variabilidade . . . . . . . . . . . . . . . . . . . . . . . 86

3.19 Modelo de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.20 Modelo BVCCoN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.1 Processo de Referência . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.2 Pontos de Variação no Processo de Referência . . . . . . . . . . . . . . 94

4.3 Pontos de Variação e Variantes com partes de Processos de Negócio . . 96

4.4 Análise de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

xvi

4.5 Requisitos Não-Funcionais e Análise de Contribuição . . . . . . . . . . 99

A.1 Editor gráfico da ferramenta . . . . . . . . . . . . . . . . . . . . . . . 126A.2 Inclusão de um ponto de variação . . . . . . . . . . . . . . . . . . . . . 127A.3 Carregando modelo BPMN . . . . . . . . . . . . . . . . . . . . . . . . 127A.4 Procurando modelo BPMN . . . . . . . . . . . . . . . . . . . . . . . . 128A.5 Selecionando modelo BPMN . . . . . . . . . . . . . . . . . . . . . . . 129A.6 Finalizando o carregamento de um modelo BPMN . . . . . . . . . . . . 130A.7 Setando os atributos Begins e Ends de um ponto de variação . . . . . . . 131A.8 Setando os FlowElements de um ponto de variação . . . . . . . . . . . 131A.9 Setando os FlowElements de um ponto de variação . . . . . . . . . . . 132A.10 Variation Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133A.11 WorkflowPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134A.12 Ligações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135A.13 Links Requires e Excludes . . . . . . . . . . . . . . . . . . . . . . . . 135A.14 Criando NFRmodel e Softgoals . . . . . . . . . . . . . . . . . . . . . . 136A.15 Ligações entre Softgoals . . . . . . . . . . . . . . . . . . . . . . . . . 137A.16 Ligações entre Variants e Softgoals . . . . . . . . . . . . . . . . . . . . 138A.17 Ligação entre ContextExpression e Statement . . . . . . . . . . . . . . 138A.18 AndDecomposition e Fatos . . . . . . . . . . . . . . . . . . . . . . . . 139A.19 AndDecomposition e Fatos . . . . . . . . . . . . . . . . . . . . . . . . 139A.20 Variáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140A.21 Expressão de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . 141A.22 Exemplo das três visões: variabilidade, requisitos não-funcionais e infor-

mação contextual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

B.1 Processo de Referência . . . . . . . . . . . . . . . . . . . . . . . . . . 145B.2 Pedaço de um Processo de uma Variante . . . . . . . . . . . . . . . . . 146B.3 Modelo BVCCoN Completo . . . . . . . . . . . . . . . . . . . . . . . 149

Lista de Tabelas

2.1 Relação entre o tipo de representação de RNF e trabalhos selecionados [40]. 322.2 Sumarização dos Resultados . . . . . . . . . . . . . . . . . . . . . . . 322.3 Contribuição para os RNFs Confiança e Performance . . . . . . . . . . 432.4 Sumário de Critérios . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1 Contribuição dos RNFs . . . . . . . . . . . . . . . . . . . . . . . . . . 1004.2 Equipamentos utilizados para realização do teste . . . . . . . . . . . . . 1024.3 Respostas dos Participantes . . . . . . . . . . . . . . . . . . . . . . . . 1054.4 Satisfação Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.5 Utilidade do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084.6 Qualidade da Informação . . . . . . . . . . . . . . . . . . . . . . . . . 1094.7 Qualidade da Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Lista de Acrônimos

BPMN Business Process Management and Notation

BVCCoN Business Process Configuration with NFR and Context-Awareness

DSEL Domain Specific Embedded Language

DSL Domain Specific Language

DSML Domain Specific Modeling Language

EMF Eclipse Modeling Framework

EOL Epsilon Object Language

GMF Graphical Modeling Framework

GPL General Purpose Language

MOF Meta Object Facility

NFR Non-Functional Requirements

OMG Object Management Group

PSSUQ The Post-Study System Usability Questionnaire

XMI Metadata Interchange

Lista de Listagem

2.1 Metamodelo escrito em Emfatic . . . . . . . . . . . . . . . . . . . . . 532.2 Exemplo de Código EVL . . . . . . . . . . . . . . . . . . . . . . . . . 553.1 Metamodelo Variabilidade escrito em Emfatic . . . . . . . . . . . . . . 653.2 Metamodelo Contexto escrito em Emfatic . . . . . . . . . . . . . . . . 703.3 Metamodelo RNF escrito em Emfatic . . . . . . . . . . . . . . . . . . 743.4 Restrições EVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Sumário

1 Introdução 271.1 Motivação e Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.2 Objetivos da Investigação . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . 29

1.3 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2 Fundamentação Teórica e Trabalhos Relacionados 312.1 Revisão Sistemática da Literatura . . . . . . . . . . . . . . . . . . . . . 31

2.2 BVCCoN - Business Process Configuration with NFRs and Context-Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2.1 Elicitação da Variabilidade . . . . . . . . . . . . . . . . . . . . 34

2.2.2 Descrição da Variabilidade . . . . . . . . . . . . . . . . . . . . 34

2.2.3 Análise de Contexto . . . . . . . . . . . . . . . . . . . . . . . 39

2.2.4 Ligar Variantes & RNF . . . . . . . . . . . . . . . . . . . . . . 40

2.2.5 Realizar a Configuração . . . . . . . . . . . . . . . . . . . . . 43

2.2.6 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . 43

2.3 Meta-Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.3.1 UML - Unified Modeling Language . . . . . . . . . . . . . . . 47

2.3.2 DSML - Linguagem para Modelagem Específica de Domínio . . 48

2.4 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.4.1 Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . 50

2.4.2 Graphical Modeling Framework . . . . . . . . . . . . . . . . . 51

2.4.3 Epsilon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.4.4 Estudos que Desenvolveram Ferramentas de Modelagem . . . . 56

2.5 Considerações do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . 58

3 BVCCoN Tool 593.1 Modelo e Metamodelo BVCCoN . . . . . . . . . . . . . . . . . . . . . 59

3.1.1 Sintaxe Abstrata . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.1.1.1 Modelo BPMN . . . . . . . . . . . . . . . . . . . . . 62

3.1.1.2 Variabilidade . . . . . . . . . . . . . . . . . . . . . . 63

3.1.1.3 Contexto . . . . . . . . . . . . . . . . . . . . . . . . 67

3.1.1.4 Requisitos Não-Funcionais . . . . . . . . . . . . . . . 72

xxiv

3.1.2 Sintaxe Concreta . . . . . . . . . . . . . . . . . . . . . . . . . 77

3.1.2.1 Variabilidade . . . . . . . . . . . . . . . . . . . . . . 77

3.1.2.2 Requisitos Não-Funcionais . . . . . . . . . . . . . . . 80

3.1.2.3 Contexto . . . . . . . . . . . . . . . . . . . . . . . . 81

3.2 A Ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.3 Restrições EVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.4 Considerações do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . 89

4 Avaliação 914.1 Cenário: Check-In Aeroporto . . . . . . . . . . . . . . . . . . . . . . . 91

4.2 Exemplo de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.2.1 Processo de Referência . . . . . . . . . . . . . . . . . . . . . . 92

4.2.2 Elicitação da Variabilidade . . . . . . . . . . . . . . . . . . . . 92

4.2.3 Descrição da Variabilidade . . . . . . . . . . . . . . . . . . . . 92

4.2.4 Análise de Contexto . . . . . . . . . . . . . . . . . . . . . . . 97

4.2.5 Análise de Requisitos Não-Funcionais . . . . . . . . . . . . . . 97

4.3 Teste de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.3.1 The Post-Study System Usability Questionnaire . . . . . . . . . 100

4.3.2 Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.3.3 Equipamentos e Ambiente . . . . . . . . . . . . . . . . . . . . 102

4.3.4 Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.3.5 Processo de Coleta dos Dados . . . . . . . . . . . . . . . . . . 102

4.3.6 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.3.6.1 Satisfação Geral . . . . . . . . . . . . . . . . . . . . 106

4.3.6.2 Utilidade do Sistema . . . . . . . . . . . . . . . . . . 108

4.3.6.3 Qualidade da Informação . . . . . . . . . . . . . . . 108

4.3.6.4 Qualidade da Interface . . . . . . . . . . . . . . . . . 109

4.4 Ameaças à Validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4.5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

5 Conclusões e Trabalhos Futuros 1135.1 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

5.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Referências 117

Apêndice 122

A Manual de Usuário da Ferramenta BVCCoN-Tool 125A.1 Criação de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

B Avaliação da Usabilidade da Ferramenta BVCCoN-Tool - Tarefa do Usuário143

C The Post-Study System Usability Questionnaire (PSSUQ) 151

27

1Introdução

Este capítulo apresenta a motivação e os objetivos para a realização deste estudo, além deapresentar a estrutra da dissertação.

1.1 Motivação e Justificativa

Os processos estão se tornando cada vez mais complexos e heterogêneos, inseridos emambientes onde as mudanças são constantes, sendo influenciados por fatores geográficos,climáticos, dentre outros. As empresas precisam manter seus processos atualizados efuncionando adequadamente, sem desprezar os requisitos de qualidade. Abordagemdirigida à contexto foi projetada para cobrir essas lacunas através da capacidade depercepção contínua do ambiente do processo e decisões baseadas no controle do processo[47].

Processos de negócio dinâmicos são aqueles capazes de se adaptar a novas situações.Essas novas situações são impostas pelo ambiente em que o processo está inserido,afetando a maneira como os processos são realizados [42]. Para que os processos denegócios sejam flexíveis às mudanças no ambiente organizacional, é necessário lidar coma variabilidade de processos [49]. A variabilidade de processos representa a modelagemde caminhos alternativos que podem ser realizados para executar determinada atividade.Também pode incluir informações como: os recursos necessários e o responsável pelaexecução da atividade [27].

Considerar a qualidade de processos é essencial em futuros sistemas de software [23].As modelagens atuais de processos de negócio capturam atividades que representamaspectos funcionais de um sistema de informação. Enquanto os requisitos ditos dequalidade, restrições ou softgoals, os chamados Requisitos Não-Funcionais (RNFs),não são capturados, pois o foco, na modelagem de processos de negócio tem sido no

28

comportamento funcional [53] [39]. Os RNFs são importantes para as organizações,uma vez que estão relacionados a aspectos de restrição e qualidade, tais como tempo deexecução, segurança, usabilidade, manutenabilidade e confiabilidade.

Baseado na grande importância de RNFs e contexto em modelos de processos denegócio, Santos [47] propõe uma abordagem de configuração de processos que tem comoobjetivo oferecer suporte à sua configuração baseada em RNFs e informações contextuais.A abordagem possui três perspectivas na configuração de processo de negócio: a descriçãode variabilidade, os Requisitos Não-Funcionais e o contexto [47].

A primeira perspectiva tem como foco a descrição da variabilidade de modelos deprocessos de negócio e os mecanismos necessários para lidar com isto. Na segundaperspectiva, é utilizado RNFs para representar qualidades dos modelos de processosde negócio. Esta perspectiva aborda as preferências e interferências de atributos dequalidade nos modelos de processos. A perspectiva de contexto incorpora as influênciasdo ambiente no modelo de processo. Através da associação de informações monitoráveisaos modelos de processos, é possível oferecer capacidade de adaptação aos mesmos parapossíveis mudanças de ambiente.

Contudo, a abordagem de Santos [47] é complexa, envolvendo modelos de processosde negócio, de requisitos não-funcionais e de informações contextuais que estão inter-ligados, ou seja, existe uma dependência entre esses modelos. O usuário necessita tercomo produto destas fases, modelos que os represente. A falta de uma ferramenta, queauxilie o usuário a realizar as etapas de modelagem, torna o processo mais lento, difícilde entender e mais propenso a erros.

Com o propósito de solucionar estes problemas, o presente trabalho propõe a es-pecificação e o desenvolvimento de uma ferramenta que integre os diferentes modelos.Assim, deseja-se obter como produto final, uma ferramenta de modelagem que ofereçamais velocidade na execução do processo de modelagem, que facilite a compreensão dosmodelos e que evite erros.

1.2 Objetivos da Investigação

1.2.1 Objetivo Geral

O principal objetivo deste estudo é o desenvolvimento de uma ferramenta para apoiar oprocesso de modelagem da abordagem BVCCoN apresentada em [48].

29

1.2.2 Objetivos Específicos

Para alcançar o objetivo geral deste estudo, os seguintes objetivos específicos foramdefinidos:

• Planejar e executar uma revisão sistemática da literatura sobre requisitos não-funcionais, informações contextuais e modelos de processos de negócio;

• Desenvolver o metamodelo para a BVCCoN-Tool;

• Implementar a ferramenta de modelagem para a configuração de processos denegócio dinâmicos;

• Aplicar um exemplo de uso com o objetivo de avaliar a expressividade da ferra-menta;

• Definir, planejar, executar e interpretar uma avaliação de usabilidade com usuáriosreais.

1.3 Estrutura da Dissertação

O restante desta dissertação está organizada da seguinte maneira: Capítulo 2 apresenta obackground necessário para a compreensão deste trabalho. Neste capítulo, são descri-tas as etapas da abordagem BVCCoN, trabalhos relacionados, também são discutidosmetamodelagem e apresentadas as tecnologias utilizadas para o desenvolvimento daferramenta; Capítulo 3 descreve a ferramenta proposta, incluindo o metamodelo e asetapas de desenvolvimento; Capítulo 4 apresenta um exemplo de uso e também umaavaliação de usabilidade da ferramenta proposta; Por fim, capítulo 5 oferece um conjuntode conclusões discutindo nossas contribuições e diretrizes para trabalhos futuros.

31

2Fundamentação Teórica e Trabalhos

Relacionados

Neste capítulo, apresentamos o background necessário para a compreensão do trabalhoproposto. É importante ressaltar que não é o objetivo desta seção descrever todas asinformações necessárias para a execução da abordagem BVCCoN, mas sim, apresentarde forma sucinta as etapas da abordagem. Para conhecimento de todo o processo e formade execução da BVCCoN, consultar [48]. Também discutimos meta-modelagem e oframework Epsilon [12], que foi utilizado no desenvolvimento deste trabalho.

2.1 Revisão Sistemática da Literatura

Em [40], realizamos uma revisão sistemática da literatura com o intuito de identificarcomo os requisitos não-funcionais e as informações contextuais são representados nosmodelos de processos de negócios. Utilizando-se da busca às principais bases de dados,identificamos 1883 trabalhos, dentre os quais foram classificados e analisados 13 trabalhosque levam em conta RNFs na modelagem de processos e 14 que consideram contexto emBPM.

Realizamos uma leitura cuidadosa dos trabalhos e identificamos as linguagens demodelagens de processos que foram utilizadas para representar os RNFs e tambémrealizamos um mapeamento entre os tipos de representação de RNF e seus determinadosautores. Ao final desta primeira análise 8 trabalhos utilizaram a notação BPMN, 2 usaramdigrama de atividades, 2 fizeram uso da modelagem de processos de negócio orientadaa objetivos e apenas 1 trabalho usou a notação Stock and Flow Diagrams. A Tabela2.1 exibe o mapeamento entre os tipos de representação de RNFs e seus determinadosautores.

32

Tabela 2.1 Relação entre o tipo de representação de RNF e trabalhos selecionados [40].

Tipo de Representação | Trabalhos Selecionados [Bar

toni

li,20

12]

[Boc

ciar

elli,

2011

]

[Pav

lovs

ki,2

008]

[Sae

edi,2

010]

[San

tos,

2012

]

[Ser

rano

,200

9]

[Wol

ter,2

010]

[Xav

ier,2

00]

[Abu

rub,

2007

]

[Kha

luf,2

011]

[Ked

ad,2

011]

[Car

doso

,200

9]

[Lap

ouch

nian

,200

7]

RNF anotado textualmente nos elementos do modelo • • • •Associação textual entre RNF e elementos do modelo • •Extensão da notação BPMN com criação de artefatos •Representação externa do RNF ao modelo de negócio •

Criação de símbolos para representar os RNFs • • •NFR Framework ou derivados • •

Analisando a Tabela 2.1 percebe-se que o maior tipo de representação de RNF sedá anotando elementos de um modelo com o nome do RNF, 4 dos 13 trabalhos adotameste tipo de representação. Em seguida, 3 trabalhos representam os RNFs através dacriação de símbolos para representá-los. Um empate ocorre entre aqueles que fazemassociação textual entre RNF e elementos do modelo e os que utilizam o NFRFramework

para representar RNF, cada um com 2 trabalhos. Por fim, encontra-se 1 trabalho quepropõe a criação de novos artefatos e um outro que representa os RNFs externamente aomodelo de negócio.

Analisando os trabalhos referentes às informações de contexto identificamos itenscomo, por exemplo, se o trabalho é classificado como abordagem ou framework, sedescreve alguma ferramenta para apoiar o processo criado, se testes foram realizados como intuito de validar a proposta e até mesmo se os trabalhos discutem algumas estratégiasde adaptação de processos de negócio. A Tabela 2.2 apresenta a sumarização desses itens.

Tabela 2.2 Sumarização dos Resultados

[San

tos,

2012

]

[Xia

,200

8]

[Bal

abko

,200

3]

[Bor

n,20

09]

[Buc

chia

rone

,201

2]

[Var

a,20

10]

[Hal

lerb

ack,

2008

]

[Mej

ia,2

010]

[Plo

esse

r,200

9]

[Ros

eman

n,20

08]

[Sai

dani

,200

9]

[Zac

aria

s,20

05]

[Zer

ari,2

011]

[Bou

kadi

,200

9]

ItensTipo de Contribuição - Abordagem • • • • • • •Tipo de Contribuição - Framework • • • • • • •

Ferramentas de Suporte • •Testes da Abordagem/Framework • • • • • • • • • •Discute Estratégias de Adaptação • • •

Para fins de contagem, consideramos apenas os itens "Ferramenta de Suporte", "Testesda Abordagem/Framework"e "Discute Estratégias de Adaptação". Portanto, analisando aTabela 2.2, identificamos que 1 trabalho cobre os 3 itens citados anteriormente, 1 trabalho

33discute ferramenta de suporte e estratégias de adaptação, 1 trabalho trata de estratégiasde adaptação e 9 trabalhos realizam testes da abordagem/framework.

Durante o processo de extração dos dados e análise dos resultados, encontramos aabordagem BVCCoN. Esta foi a única abordagem que foi classificada tanto na análisedos requisitos não-funcionais quanto na de informação contextual. Portanto, BVCCoNé uma abordagem de configuração de processos de negócios que leva em consideraçãoRNFs e contexto no momento de realizar configurações. Informações de contexto sãoimportantes para obter flexibilidade e requisitos de qualidade segundo Saeedi [45], são ocaminho para alcançar performance e satisfação dos clientes.

Esta abordagem representa os RNF externamente ao modelo de negócio através doNFRFramework. Uma vez definido os RNFs, os mesmos são ligados às variantes doprocesso. Quanto às informações de contexto, a abordagem utiliza um conjunto de regraspara montar as informações contextuais e não possui uma ferramenta que apoie estasconstruções, assim como, também não possui uma ferramenta que realize a representaçãodos RNFs. Estas informações obtidas da revisão sistemática fortalece a inexistência deuma ferramenta que apoie as fases de modelagem da abordagem, tornando o processomais lento, difícil de entender e mais propenso a erros. A seção seguinte descreve asetapas da abordagem.

2.2 BVCCoN - Business Process Configuration with NFRsand Context-Awareness

A BVCCoN [48] é uma abordagem que visa a configuração de processos de negócioutilizando requisitos não-funcionais e informações contextuais. A abordagem é compostade cinco atividades: Elicitar Variabilidade, Descrever Variabilidade, Analisar Contexto,Ligar RNFs & Variantes e Realizar Configuração. As primeiras quatro etapas são realiza-das em design time (ver Figura 2.1). Enquanto a última etapa, Realizar Configuração érealizada em runtime. Nossa ferramenta de modelagem cobre as atividades Descrever

Variabilidade, Analisar Contexto e Ligar RNF & Variantes da abordagem. Para executara atividade Elicitar Variabilidade, não é necessário a utilização de uma ferramenta demodelagem, mas sim uma análise em cima dos elementos do modelo de negócio emBPMN. Nas próximas subseções são detalhadas as etapas do processo da abordagemBVCCoN apresentado na Figura 2.1.

34

Figura 2.1 Processo da abordagem BVCCoN. Adaptado de [47].

2.2.1 Elicitação da Variabilidade

Esta primeira etapa é responsável por identificar e descobrir possíveis variações em ummodelo de processo de negócio. O objetivo é descobrir diferentes maneiras de executarum processo, bem como os efeitos da inclusão, mudança ou exclusão de elementosdo modelo. Possui como entrada um processo de negócio inicial e como saída todainformação sobre variabilidade elicitada.

Para realizar esta atividade, é utilizado o information analysis framework [32] queexplora diferentes características da informação e obtém novos dados sobre as informa-ções. No contexto de modelos BPMN, este framework é utilizado para analisar tarefas,atividades e outros elementos do modelo para identificar novas informações sobre eles.Este framework é baseado em um conjunto de perguntas como:

• Agente (Quem irá executar a tarefa?)

• Dativo (Quem será afetado pela tarefa?)

• Objetivo (Quais são os objetos consumidos ou produzidos pela tarefa?)

• Extensão (Até que ponto a tarefa será executada?)

2.2.2 Descrição da Variabilidade

Por meio da elicitação de variabilidade, é possível analisá-la com o intuito de identificaro que pode ser modelado como pontos de variações e variantes. A partir desta seção,o modelo BVCCoN começa a ser construído incrementalmente por meio das próximasseções. Para ilustrar um exemplo, estamos utilizando um processo de emergência quanto

35a existência de fogo. Este processo é um caso clássico de um sistema sócio-técnico ondesoftware e humanos devem executar com segurança (ver Figura 2.2).

O processo é iniciado com a procura por fumaça ou fogo, caso identificado umadessas situações, é verificado o risco. Caso o risco não seja real, o processo é finalizado,porém, se o perigo for real, inicia-se a tarefa de resgatar as pessoas em perigo, seguidapor tocar alarme de incêndio, ligar para os serviços de segurança pública, abrir saídas

de emergência e Evacuar o prédio imediatamente.

Pontos de variações são pontos de mudanças definidos no modelo de processo denegócio que podem representar caminhos alternativos ou variáveis de realizar atividadesno processo. Para definir os pontos de variação, é necessário receber como entrada omodelo referência de processo de negócio e a informação elicitada. Baseado nesta entrada,o analista define o que será marcado como ponto de variação e quais tarefas farão partedo ponto de variação. O analista também deve definir onde o ponto de variação começa(begins) e termina (ends). A saída destas atividades é o modelo referência de processomarcado com os pontos de variações. Esta saída faz parte do processo de descrição devariabilidade.

A Figura 2.2 exibe um possível modelo de referência com os pontos de variações.Quatro pontos de variações foram identificados: PV1 associado a tarefa Procurar por

fumaça ou fogo, PV2 relacionado a tarefa Tocar alarme de incêndio, PV3 corresponde atarefa Ligar para os serviços de segurança pública e PV4 está ligado a tarefa Abrir saídas

de emergência. Após definir os pontos de variações e selecionar onde eles começam eterminam, a próximo passo é definir os elementos que serão parte das variantes.

As informações adquiridas durante a elicitação e os pontos de variação definidos ante-riormente são entradas para a definição de variantes. Variantes são objetos de mudanças,representando caminhos alternativos ou variáveis, ou seja, como as atividades do processopodem ser realizadas. Desta maneira, as variantes estão associadas a fragmentos deprocessos BPMN que irão expressar a maneira como um processo pode ser alterado parase adaptar a uma nova configuração de ambiente. Assim como os pontos de variações, asvariantes também são identificadas por um analista.

No exemplo de emergência de fogo, foram identificadas variantes que estão associadasao tipo de agente que executará algumas tarefas. Na tarefa Procurar por fogo e fumaça, épossível visualizar este caso, no qual a tarefa pode ser executada por uma pessoa ou umsensor. A descrição de variabilidade também pode afetar o comportamento das tarefas.Os padrões de work-flow descrevem comportamentos de atividades quando associadas aum ponto de variação. No modelo BVCCoN, a utilização de padrões work-flow ajuda

36

Figura 2.2 Exemplo de modelo referência com pontos de variação. Adaptado de [48].

a descrever como combinar as variantes e os pontos de variações, ou seja, os padrõesdescrevem como os elementos (neste caso BPMN) serão agrupados [52].

Os padrões básicos são sequence, parallel split, synchronization, exclusive choice esimple merge. O padrão sequence é aquele em que as tarefas são executas em sequencia, oparallel split as tarefas são executas em paralelo, o padrão synchronization precisa existiruma sincronia entre as tarefas do BPMN, ou seja, um conjunto de tarefas precisam serexecutadas para que o fluxo do processo BPMN continue. No padrão Exclusive Choice édado um conjunto de tarefas, mas apenas uma é executada, por fim, no padrão Merge édado um conjunto de tarefas em que apenas uma precisa ser executada para que o fluxodo processo seja continuado.

O próximo passo é associar os pontos de variações às variantes. Nesta etapa, énecessário definir algum operador lógico no ponto de variação para indicar como asvariantes estarão associadas. Na abordagem BVCCoN, é utilizado os termos AND, OR eXOR. Estes operadores podem influenciar os padrões de work-flow que estão associadosàs variantes. Por exemplo, um operador AND permite incluir como solução os padrões

37sequence e parallel split/synchronization.

A Figura 2.3 exibe as variantes associadas com seus respectivos pontos de variações.O ponto de variação VP1 possui duas variantes, var1 e var2, que são Procurar por fogo ou

fumaça automaticamente e Procurar por fogo ou fumaça pessoalmente respectivamente.Cada variante está associada a uma tarefa BPMN, var1 está associada com a tarefaProcurar por fogo ou fumaça automaticamente e var2 com a tarefa Procurar por fogo

ou fumaça. Os pontos de variações VP2, VP3 e VP4 também estão associados com suasrespectivas variantes e as variantes com as tarefas BPMN. Após concluir esta etapa, opróximo passo é executar a análise de contexto.

38

Figura 2.3 Exemplo de variantes e pontos de variação. Adaptado de [48].

39

2.2.3 Análise de Contexto

Segundo Ali [2], contexto pode ser definido como um estado do mundo que é relevantepara um objetivo de um ator. Nesta etapa, o modelo de processos de negócio é analisadopara identificar os contextos que podem afetar o modelo. Analisando o domínio, oscontextos podem ser identificados. Estados de sistemas e também usuários podem serdescritos como contexto. O contexto pode descrever:

• O que está acontecendo?

• Onde eles estão localizados?

• Quais são os recursos disponíveis para uso?

O contexto pode ser analisado através de um conjunto de fatos e statements que estãoconectados [2]. Fatos podem ser avaliados, já os statements não. Para que um statement

assuma um valor verdadeiro, deve existir um conjunto suficiente de evidências que realizea comprovação. Essas evidências são encontradas por meio das avaliações dos fatos [5].A decomposição termina quando é possível descrever todas as variáveis que permitemverificar se o contexto foi ativado. O objetivo é obter uma fórmula de fatos apoiados porvariáveis monitoráveis. Os seis passos abaixo são utilizados para obter o conjunto decontextos associados às variantes.

1. Selecionar uma variante do modelo de variabilidade a ser avaliado;

2. Identificar fatores que afetam a execução do fragmento de processo de negócio deuma variante;

3. Decompor os fatos e statements que apoiam o contexto;

4. Associar as variáveis monitoráveis aos fatos;

5. Validar a interferência com outros contextos;

6. Repetir os passos para outras variantes.

A Figura 2.4 exibe um exemplo de decomposição de contexto. Por exemplo, ocontexto Bombeiros serem chamados automaticamente é apoiado por três fatos: Alarme

de fogo está ativo, Fogo foi confirmado, e Serviços de rede está funcionando. Quando asvariáveis que estão associadas a este contexto atingem o valor especificado, o contexto éativado e a variante que está associada a este contexto pode fazer parte do processo.

40

Figura 2.4 Exemplo de decomposição de contexto. Adaptado de [48].

2.2.4 Ligar Variantes & RNF

Na abordagem BVCCoN, os requisitos não-funcionais são utilizados para representar aspreferências dos stakeholders. Nesta etapa, os RNFs que são importantes para o processosão identificados e também é definido o impacto de cada variante sobre os RNFs. Assim,os RNFs são ligados às variantes do processo de negócio que foram levantadas nos passosanteriores da abordagem.

Os RNFs que serão levados em consideração são identificados e então é feito umadescrição dos RNFs e variantes. Essa elicitação pode ser realizada entrevistando pessoasque estão envolvidas no processo de negócio. Em seguida, pode-se associar os RNFs comas variantes para representar as preferências dos stakeholders sobre a seleção de possíveisvariantes. RNFs representarão atributos de qualidade que os stakeholders esperam dosistema.

Uma vez identificados os RNFs, é permitido realizar as ligações entre estes e asvariantes do processo. A abordagem BVCCoN utiliza a escala qualitativa proposta peloNFRFramework [30] para realizar essas ligações. O impacto mais positivo sobre umrequisito não-funcional é chamado Make, um impacto parcialmente positivo Help, umimpacto parcialmente negativo é chamado de Hurt e um impacto mais negativo Break.Esses valores são mapeados respectivamente para, ++,+,-,– na escala da abordagemBVCCoN.

41A Figura 2.5 mostra uma versão simplificada de um modelo BVCCoN. As variantes

Tocar alarme de fogo manualmente e Tocar alarme de fogo automaticamente fazem partedo ponto de variação VP2, que possui o operador lógico XOR. Este operador lógico indicaque apenas uma das variantes pode ser selecionada. A variante Tocar alarme de fogo

automaticamente está relacionada com o contexto Serviços de backup estão funcionando,assim, esta variante só poderá ser selecionada se o contexto for verdadeiro. A Tabela2.3 apresenta as contribuições da Figura 2.5, permitindo uma melhor visualização. Osespaços em branco são compreendidos como EqualContribution (=).

42

Figura 2.5 RNFs e Variantes. Adaptado de [48].

43

Tabela 2.3 Contribuição para os RNFs Confiança e PerformanceVariante/RNF Confiança PerformanceProcurar por fogo ou fumaça automaticamente ++Procurar por fogo ou fumaça pessoalmente ++ -Tocar alarme de fogo manualmente + -Tocar alarme de fogo automaticamente ++Chamar os serviços de segurança pública automaticamente – ++Chamar os serviços de segurança pública por linha telefônica -Chamar os serviços de segurança pública por telefone móvel + +Abrir saídas de emergência manualmente ++Abrir saídas de emergência automaticamente ++

2.2.5 Realizar a Configuração

Existem duas maneiras de executar a configuração de um processo de negócio: a primeiraé selecionando as variantes e a segunda é priorizando algum requisito não-funcional.Existem diversas maneiras de analisar o impacto de cada configuração sobre os RNFs,por exemplo: análise top-down e bottom-up.

A top-down é feita selecionando um RNF que terá maior prioridade, e em seguida,derivado uma configuração de processo que maximiza o RNF selecionado. Ou seja, cadaponto de variação é avaliado para identificar a variante que melhor se ajusta ao requisitonão-funcional selecionado.

Na análise bottom-up, uma configuração de processo é definida selecionando umsub-conjunto de variantes e então, uma matriz de ligação é utilizada para calcular oimpacto da configuração sobre o requisito não-funcional. A Figura 2.6 apresenta umasolução de um processo priorizando o RNF Performance.

Para descrever os conceitos de ponto de variação, variantes, requisitos não-funcionaise informações contextuais, é utilizado um mecanismo chamado de metamodelagem.Assim, através de um metamodelo, é possível definir os elementos de modelagem e seusrespectivos relacionamentos [4].

2.2.6 Trabalhos Relacionados

A seguir, apresentamos uma comparação entre estudos que descrevem abordagens deconfiguração de modelos de processos de negócio em ambientes dinâmicos descritos naliteratura.

Trabalhos IdentificadosQuestionnaire based variability modeling for system configuration

44

Figura 2.6 Exemplo de uma instância de processo. Adaptado de [48].

La Rosa [28] propôs uma abordagem para capturar variabilidade de sistemas baseadaem modelos de questionário. Ela apoia a configuração com um processo e um modelo dequestionário. O modelo de questionário consiste de um gráfico que define as questões aserem respondidas. Questões são respondidas em sequencia, lidando para a identificaçãode ações que são realizadas pela configuração.

Os modelos de processos são representados por modelos de processos configuráveisescritos em Configurable Yet Another Workflow Language (C-YAWL). Esta linguagem éuma extensão que possui a característica de descrever os pontos de variação do processodentro do modelo de processo. O modelo de processo com a informação de variabilidadeestá alinhado com o modelo de questionário. A configuração do processo é realizada pelousuário respondendo questões que levam a um novo modelo de processo.

Requirements-driven design and configuration management of business processes

Lapouchnian et al. (2007) [29] apresenta uma abordagem que alinha processos denegócio com modelos de Goal. Modelos de Goal são usados para descrever os objetivosdo negócio e as preferências dos usuários. Através da decomposição dos modelos, épossível obter uma estrutura de goals [objetivos] do processo de negócio. O modelo degoals segue uma estrutura em formato de árvore na qual os goals são decompostos emsubgoals.

A descrição da informação de variabilidade é adicionada a estrutura do modelode goals. Por isso, as informações do processo está misturado com anotações. Asanotações que descrevem variabilidade são baseadas em IF-THEN-ELSE, regras assimcomo os operadores lógicos (AND, OR). Os requisitos não-funcionais são descritos comoSoftgoals e as contribuições para Softgoals representam as preferências dos usuários sobre

45possíveis escolhas. Os pontos de variação são os lugares onde existe uma decomposiçãoOR. Com o objetivo de obter um modelo de fluxo de processo, eles descrevem os passosdo começo da configuração com uma análise de Softgoal e seleção de variantes. Após aseleção, uma transformação gera o modelo de fluxo do processo em BPEL.

Business processes contextualisation via context analysis

De La Vara et al. (2010) [5] propôs uma metodologia para adicionar contextualizaçãoaos modelos de processos de negócio. A proposta é obter modelos de processos denegócio que são perceptíveis ao contexto. A metodologia descreve vários passos einclui anotações de contexto que é baseada na abordagem de [2], que apoia análisecontextual. Os contextos consistem de árvores com facts e statements que são avaliadospara identificar quando um contexto está ativo.

As informações contextuais são requeridas para ativar mudanças no fluxo dos pro-cessos. Com o objetivo de incluir contexto, eles estenderam a notação BPMN para tercontextos embarcados nos fluxos de sequência que ligam as atividades. A descrição davariabilidade é adicionada ao modelo de processo, onde o caminho alternativo no fluxodo trabalho representa as variantes.

Discussão

As abordagens de configuração de processos de negócio são complexas e consomemmuito esforço e tempo. A abordagem BVCCoN integra metamodelos de análise realizadosdurante os passos do processo BVCCoN, que foca em uma clara separação de interesses.De La Vara et al. (2010) [5] usa variabilidade de contexto para definir variabilidade deprocessos. Na BVCCoN, quando o contexto é aplicado, os pontos de variação e variantesjá estão definidos. Isto reduz a análise de contexto para apenas contextos relevantes,evitando problemas com a cobertura do modelo de processo e reduzindo a análise decontexto que não será utilizada.

Quando comparado com a abordagem proposta por Lapouchnian et al. (2007) [29],podemos ver que a integração de metamodelos também é uma vantagem. Observe que emBVCCoN, a análise de requisitos é realizada independemente da análise de variabilidade.Durante a construção do modelo BVCCoN, a análise de contribuição estabelece ligaçõesentre variantes e RNFs. Por isso, a análise de preferências pode ser refeita se uma varianteé adicionada ou removida. Ao contrário, a abordagem proposta por Lapouchnian et al.(2007) mistura as informações de processo com a descrição de variabilidade e softgoals.Quando uma variante é adicionada ou removida, todo o modelo deve ser revisado.

Diferente das outras duas abordagens, La Rosa [28] propôs compartilhar menos,similar a BVCCoN. É utilizado diferentes estratégias para lidar com variabilidade e confi-

46

guração. Por esta razão, La Rosa foca na redução da intervenção do usuário na realizaçãoda configuração, a abordagem BVCCoN tenta reduzir a necessidade da interação com ousuário durante os passos da configuração.

Algumas abordagens apresentaram ferramenta de suporte, porém, os benefíciospodem ser limitados devido a abrangência da ferramenta em relação as etapas das abor-dagens. A comparação foi baseada na avaliação de documentos, assim, as ferramentasde suporte não foram avaliadas. Mesmo compartilhando algumas características emcomum com as outras abordagens, a BVCCoN mostra mais vantagens que desvantagensquando considerado o cenário da configuração de processos dinâmicos. BVCCoN é umaabordagem mais completa, sua ferramenta permite modelar diferentes perspectivas relaci-onadas aos processos de negócio (requisitos não-funcionais, variabilidade e informaçõesde contexto), sem a necessidade de estender uma linguagem de modelagem existente ouutilizar uma linguagem apenas por cobrir alguma das perspectivas citadas anteriormente.A Tabela 2.4 mostra um sumário das abordagens em relação aos critérios discutidosanteriormente.

Tabela 2.4 Sumário de CritériosAbordagem Variabilidade Configuração Modelo de Processo FerramentaLa Rosa (2009) C-YAWL/YAWL Seleção de Nós Questionário e C-YAWL SimLapouchnian et al. (2007) Modelo de Goals/BPEL Transformação de modelos Modelo de goals SimDe La Vara et al. (2010) BPMN estendido Validação de contexto Modelo BPMN NãoBVCCoN BPMN Transformação de modelos Modelo BVCCoN Sim

2.3 Meta-Modelagem

A meta-meta-modelagem é responsável por definir uma linguagem para a especificaçãode metamodelos. A Object Management Group (OMG) definiu uma linguagem paraa especificação de metamodelo denominada Meta Object Facility (MOF) [37]. Estalinguagem oferece um framework para o gerenciamento de metadados e um conjunto deserviços de metadados para permitir o desenvolvimento e a interoperabilidade de modelose sistemas que utilizam metadados.

As tecnologias da OMG, incluindo UML (Unified Modeling Language), MOF, XMI1,dentre outras, usam MOF e tecnologias derivadas de MOF para a troca e manipulação demetadados [37].

A Figura 2.7 apresenta uma infraestrutura em 4 camadas da primeira geração detecnologias MDD, ou seja, UML e MOF. Esta infraestrutura apresenta uma hierarquia

1XMI é um formato de intercâmbio amplamente utilizado para o compartilhamento de modelos usandoXML [38].

47

Figura 2.7 Infraestrutura Tradicional MDD. Adaptado de [3].

divida por modelos. Cada modelo (exceto o M3) é caracterizado como uma instância donível acima.

O nível mais baixo, M0, é responsável por manipular os dados de usuário. Dadosreais em que softwares são projetados para manipular. O nível M1 representa o própriomodelo, ou seja, é designado para manipular um modelo dos dados de usuário M0. Opróximo nível, M2, é conhecido como metamodelo por ser um modelo de modelo. M2 éum modelo que mantém informações do modelo M1. Por último, M3 é um modelo deinformações em M2, e por isso é chamado de meta-metamodelo [3].

Neste estudo, é proposto o desenvolvimento de um metamodelo (nível M2) para aferramenta proposta. Sendo possível assim, gerar os níveis M1 e M0. O metamodeloa ser desenvolvido, será construído utilizando a tecnologia da UML, que é revisada napróxima seção.

2.3.1 UML - Unified Modeling Language

A UML é uma linguagem de modelagem proposta pela OMG, a qual é uma das maisusadas para especificação, construção e documentação de artefatos de software. É umalinguagem de modelagem de propósito geral, e pode ser usada para todos os domíniosde aplicações como saúde, espaço aéreo e telecomunicações. Contudo, podem existirsituações em que uma linguagem de um propósito tão geral e amplo não seja apropri-ado para a modelagem de aplicações de um domínio específico. Isto pode acontecerquando queremos expressar conceitos específicos de um determinado domínio, ou quando

48

queremos restringir ou customizar alguns dos elementos da UML.

A OMG discute duas abordagens possíveis para definir uma linguagem específicade domínio. A primeira é a criação de uma nova linguagem baseada nos mecanismosoferecidos pela própria OMG para definição de linguagens visuais. Assim, sintaxe esemântica dos elementos da nova linguagem precisam ser definidos de acordo com ascaracterísticas do domínio [20].

A segunda alternativa se concentra na especialização da UML. Alguns elementosda linguagem são especializados, impondo novas restrições sobre eles em relação aometamodelo UML. A semântica dos elementos UML não é alterada (as propriedades deuma classe UML, associações, atributos, etc, serão os mesmos). Um profile em UMLoferece mecanismos de extensões genéricos para a customização de modelos UML paradomínios e plataformas particulares. Profiles são definidos utilizando stereotypes, tag

definitions e constraints [20].

• Stereotypes: são definidos por um nome e um conjunto de elementos do metamo-delo que são anexados;

• Constraints: podem estar associadas a estereótipos, impondo restrições sobre oselementos do metamodelo correspondente;

• Tag definitions: é um meta-atributo adicional que é anexado a uma meta-classe deum metamodelo estendido por um Profile.

Para este estudo, foi utilizada a primeira abordagem para o desenvolvimento daferramenta. Portanto, é necessário construir uma linguagem de modelagem específica dedomínio para a abordagem BVCCoN.

2.3.2 DSML - Linguagem para Modelagem Específica de Domínio

Quando tratamos de um domínio específico, as linguagens de modelagem, como porexemplo, UML, BPMN e i*, podem não conter todos os elementos necessários pararealizar a modelagem. Assim, pode ser útil a criação de uma linguagem específica dedomínio, (do inglês DSL - Domain Specific Language) para descrever com maioresdetalhes as características mais importantes de um domínio específico.

Uma DSL é uma linguagem que está direcionada em um domínio particular deproblema, oferecendo um conjunto restrito de notações e abstrações apropriadas. Contudo,as DSLs contém uma linguagem de propósito geral (do inglês, GPL - General Purpose

49Language) incorporada como uma sub-linguagem. Assim, oferecem um poder expressivoespecífico do domínio em conjunto com o poder de expressividade de uma GPL [51].

Isto acontece quando DSLs são implementadas como linguagens embarcadas. Por-tanto, quando não é desejado criar uma linguagem de programação, é melhor herdartoda infraestrutura de alguma outra linguagem, adequando-a em formas especiais para odomínio de interesse. Assim, é possível adquirir uma Linguagem Embarcada Específicade domínio (do inglês, DSEL - Domain Specific Embedded Language) [22].

Já uma Linguagem para Modelagem Específica de Domínio (do inglês, DSML -

Domain Specific Modeling Languages) objetiva elevar o nível de abstração, especificandoa solução em uma linguagem que usa diretamente os conceitos e regras de um domíniode problema específico. A ideia é modelar produtos de software utilizando DSL e gerarprodutos finais em uma linguagem de programação escolhida ou em outras formas, comotexto, modelo, código, a partir das especificações de alto nível que foram definidas [24].

As DSLs são classificadas como interna, externa e não textuais. Uma DSL internaé aquela que usa toda infraestrutura de uma linguagem de programação existente paraconstruir semânticas específica de domínio sobre a mesma. Uma das mais popularesDSL interna é Rails [44], que é implementada em cima da linguagem de programaçãoRuby [43]. Escrevendo código Rails é a mesma coisa que programar em Ruby, só queutilizando a semântica que Rails implementa para o desenvolvimento de aplicações web[21].

Uma DSL externa é aquela que é desenvolvida similar à implementação de umanova linguagem de programação, possuindo sua própria sintaxe e semântica. Uma DSLnecessita ser uma representação do domínio, mas isto não implica que sua representaçãoprecisa ser apenas textual. DSL não textual é aquela que pode modelar o domínioutilizando formas gráficas [21]. Nesta dissertação foram utilizados formas gráficas paramodelar o domínio da configuração de processos de negócio dinâmicos.

Para definir uma DSL, é necessário desenvolver uma sintaxe concreta e abstrata,seguida de uma semântica projetada para definir o significado da linguagem. Umasintaxe abstrata de uma linguagem é definida a partir do método de meta-modelagem. Istosimplifica o desenvolvimento da linguagem, permitindo aos designers mapear diretamenteas classes da análise de domínio para classes no metamodelo, associações e herança quesão parte da definição da DSL.

A sintaxe abstrata descreve os conceitos da linguagem, as relações entre eles eas regras de estruturação que restringem a combinação de elementos do modelo deacordo com as regras de domínio. A partir do metamodelo, é construída a sintaxe

50

concreta. Ela especifica como os conceitos de domínio incluídos no metamodelo sãorepresentados, e é geralmente definido por um mapeamento entre o metamodelo e umanotação textual ou gráfica [26]. Durante o desenvolvimento da ferramenta, identificamosincompatibilidade entre sintaxe concreta e abstrata, portanto, realizamos alteraçõesnecessárias para solucionar o problema. Uma vez definido a linguagem específica dedomínio, foi necessário utilizar tecnologias para o desenvolvimento da ferramenta.

2.4 Tecnologias

Esta seção é responsável por apresentar alguns conceitos e tecnologias que foram uti-lizadas para o desenvolvimento da ferramenta de modelagem proposta neste estudo.Para o desenvolvimento da ferramenta proposta, foi utilizado um conjunto unificado deframeworks de modelagem, ferramentas e implementações de padrões encontrados nacomunidade Eclipse [11].

Dentre os frameworks de modelagem, destaca-se o EMF (Eclipse Modeling Fra-

mework) [10], que auxilia a especificação de metamodelos e provê funcionalidades para ageração automática do código Java respectivo, o GMF (Graphical Modeling Framework)[15], que é uma abordagem model-driven para o desenvolvimento de editores gráficosbaseados no eclipse e o Epsilon [12], [7], que é uma família de linguagens e ferramentasdestinadas à atividades de gerenciamento de metamodelos.

2.4.1 Eclipse Modeling Framework

O projeto EMF é um framework de modelagem e geração de código para a construção deferramentas baseado em um modelo de dados estruturado (modelo de domínio). A partirde um modelo de domínio especificado em XMI ou em outro formato suportado, o EMFfornece ferramentas e suporte runtime à produção de classes Java que implementam essemodelo. Assim como um conjunto de classes adapter que permite a edição e visualizaçãodo modelo através de código Java, e um editor básico.

O EMF é composto de 3 peças fundamentais. 1) Framework EMF Ecore, que incluium metamodelo Ecore para os modelos descritos e suporte runtime para os modelos, 2)EMF.Edit, que fornece um conjunto de classes genéricas reusáveis para a construção deeditores para modelos EMF, e por último, 3) EMF.Codegen, responsável por gerar todocódigo necessário para construir um editor completo para um modelo EMF [10].

O metamodelo Ecore é composto pelos componentes Eclass, utilizado para represen-tar uma metaclasse; EAttribute, para representar um atributo de uma Eclass; EReference,

51utilizado para descrever associações entre classes; e EEnum, usado para descrever enume-rações. EMF possui três níveis de geração de código: 1) Modelo, oferece interface Java eimplementação de classes para todas as classes descritas no metamodelo da ferramentaCASE a ser construída, 2) Adaptadores, capazes de gerar classes de implementação queadaptam as metaclasses do modelo para visualização e edição, 3) Editor, produz umaestrutura do modelo que poderá ser visualizada na fase de criação do editor gráfico [1].

2.4.2 Graphical Modeling Framework

GMF é um framework para a construção de editores gráficos a partir de metamodelosbaseado em EMF. Para a construção de editores gráficos utilizando o GMF, é necessárioseguir um processo bem definido. Para facilitar a execução deste processo, o desenvolve-dor pode contar com a ajuda de um painel chamado GMF Dashboard. Este painel servecomo um guia durante o desenvolvimento. O GMF Dashboard está ilustrado na Figura2.8 [15].

Figura 2.8 Dashboard GMF

A geração de um editor gráfico GMF consiste na criação e manipulação de algunsarquivos.

1. Domain Model - representa o metamodelo utilizado para criar o editor gráfico. Énecessário importar o metamodelo de domínio definido em Ecore;

2. Domain GenModel - arquivo .genmodel usado para gerar código do domain model;

3. Graphical Def Model - arquivo .gmfgraph responsável por definir os elementosgráficos que representarão cada um dos objetos que foram definidos no arquivoEcore do Domain Model.

52

4. Tooling Def Model - arquivo com terminação .gmftool utilizado para definir oselementos da paleta de ferramentas.

5. Mapping Model - o arquivo do modelo de mapeamento .gmfmap é criado pararelacionar os elementos do metamodelo aos elementos do modelo gráfico e aoselementos do modelo ferramental.

6. Diagram Editor GenModel - o GMF fornece um modelo de gerador para gerar ocódigo executável do editor gráfico.

2.4.3 Epsilon

Epsilon é uma família de linguagens e ferramentas destinadas à atividades de gerencia-mento de metamodelos. Essas atividades são: geração de código, transformação modelopara modelo, validação de modelo, comparação, migração e refactoring de modelos [12].Dentre as linguagens e ferramentas da família Epsilon, as seguintes se destacam:

• EuGENia

• Emfatic

• EOL (Epsilon Object Language)

• EVL (Epsilon Validation Language)

• ETL (Epsilon Transformation Language)

• EGL (Epsilon Generation Language)

• EWL (Epsilon Wizard Language)

EuGENia é uma ferramenta que facilita a geração de editores gráficos em GMF,diminuindo a complexidade imposta pelo mesmo [13]. EuGENia gera ferramentasgráficas a partir de um metamodelo Ecore com anotações escritas na linguagem Emfatic[16]. Emfatic é uma linguagem que foi projetada para representar modelos Ecore EMFde maneira textual simples e compacta, similar à linguagem Java. Esta linguagempermite definir metaclasses, atributos de metaclasses, enumerações, relacionamentosentre metaclasses, dentre outros elementos do modelo EMF Ecore.

A partir de um arquivo escrito em Emfatic (arquivo .emf), que representa a sintaxeabstrata da linguagem de modelagem, é possível gerar um modelo Ecore (arquivo .ecore),

53o inverso também é possível. A partir do metamodelo .emf construído, é necessárioenriquecê-lo com anotações em EuGENia, que definirá os artefatos concretos a serrepresentado no editor gráfico. Assim, é possível definir em Emfatic quais metaclasses sãonós ou links, definir a figura (retângulo, elipse) de um nó que serão exibidos graficamente,definir a origem (source) e o destino (target) de um link. Tudo o que é definido no arquivoEmfatic é gerado um metamodelo Ecore de EMF. A partir do arquivo Ecore gerado,EuGENia gera os modelos EMF e GMF.

A Listagem 2.1 demonstra uma versão anotada do metamodelo. Em particular, asanotações representam o seguinte:

• Linha 5: o elemento diagram representa o objeto raiz do metamodelo. Apenas umaEclass não abstrata deverá ser anotada como gmf.diagram;

• Linha 16: cada pasta tem um compartimento onde sub-componentes podem seralocados;

• Linha 25: cada Sync é representado como um link (associação) entre seus arquivossource e target. A representação gráfica do link é através de uma linha pontilhada;

• Linha 31: cada arquivo é representado no diagrama como um retângulo que possuium nome dentro.

Listagem 2.1 Metamodelo escrito em Emfatic

1 @namespace ( u r i =" f i l e s y s t e m " , p r e f i x =" f i l e s y s t e m " )2 @gmf3 package f i l e s y s t e m ;4

5 @gmf . d iagram6 c l a s s F i l e s y s t e m {7 v a l Drive [ * ] d r i v e s ;8 v a l Sync [ * ] s y n c s ;9 }

10

11 c l a s s Dr ive ex tends F o l d e r {12

13 }14

15 c l a s s F o l d e r ex tends F i l e {16 @gmf . compar tment17 v a l F i l e [ * ] c o n t e n t s ;

54

18 }19

20 c l a s s S h o r t c u t ex tends F i l e {21 @gmf . l i n k ( t a r g e t . d e c o r a t i o n =" ar row " , s t y l e =" dash " )22 r e f F i l e t a r g e t ;23 }24

25 @gmf . l i n k ( s o u r c e =" s o u r c e " , t a r g e t =" t a r g e t " , s t y l e =" d o t " , w id th = " 2 " )26 c l a s s Sync {27 r e f F i l e s o u r c e ;28 r e f F i l e t a r g e t ;29 }30

31 @gmf . node ( l a b e l = " name " )32 c l a s s F i l e {33 a t t r S t r i n g name ;34 }

Existem inúmeras anotações além das que foram exibidas na Listagem 2.1. Em [14],é apresentado a listagem completa de todas as anotações que o Eugenia oferece paraserem inseridas em um modelo que foi criado utilizando a linguagem Emfatic.

EOL é uma linguagem de programação imperativa para criar, consultar e modificarmodelos EMF. Fornece características imperativas habituais como presença de variáveis,comandos sequenciais, estruturas de controle e de desvio condicional, além de outrascaracterísticas. Outras linguagens da família Epsilon como EVL, podem incorporarporções código EOL em suas estruturas de código [7].

EVL é uma linguagem de validação que pode ser utilizada para adicionar validaçõese fazer pequenos ajustes no editor gráfico GMF [18]. As restrições em EVL são similaresàs OCL2, porém, EVL suporta dependência entre constraints (se uma constraint A falha,a constraint B não será avaliada). Mensagens de erro customizadas podem ser exibidasaos usuários e um mecanismo de conserto pode ser ativado pelos usuários para repararinconsistências[7].

Em EVL, as especificações de validação são organizadas em módulos. A Listagem2.2 exibe um trecho de código escrito em EVL e os itens abaixo apresentam os módulosEVL. Em seguida, é indicado as linhas da Listagem 2.2 em que determinado móduloaparece.

• Context - um contexto especifica o tipo de instância que as invariantes serão

2OCL é uma linguagem formal utilizada para descrever expressões sobre modelos UML [35]

55aplicadas (Linhas 1 e 8);

• Invariant - cada invariante EVL define um nome e uma verificação (check). Umainvariante também pode definir uma mensagem que será exibida ao usuário casoalguma restrição falhe. Para apoiar o conserto semiautomático de elementos, umainvariante pode definir um número de fix (Linhas 4 e 12);

• Guard - Guards são usados para limitar a aplicabilidade de invariantes. Um guard

limita a aplicabilidade de todas as invariantes do contexto, enquanto a nível deinvariant, guard limita a aplicabilidade de uma invariante específica (Linha 10);

• Fix - Fix determina ações a serem realizadas para corrigir uma inconsistência. Aparte de código "do"encontrada na Listagem 2.2, é definida usando a linguagemEOL e é responsável pela correção da funcionalidade;

• Constraint - Constraints são usadas para capturar erros críticos que invalidam omodelo (Linha 2);

• Critique - ao contrário de constraints, critiques são usadas para capturar situaçõesque não invalidam o modelo, mas que devem ser levadas em consideração pelousuário para melhorar a qualidade do modelo (Linha 9).

• Pre and Post - um módulo EVL pode definir um número de blocos chamados pre

e post que são escritos em EOL e executados antes ou depois de uma invariante seravaliada respectivamente.

Listagem 2.2 Exemplo de Código EVL

1 c o n t e x t F i l e {2 c o n s t r a i n t HasName {3 check : s e l f . name . i s D e f i n e d ( )4 message : ’ Unnamed ’ + s e l f . e C l a s s ( ) . name + ’ n o t a l lowed ’5 }6 }7

8 c o n t e x t F o l d e r {9 c r i t i q u e N a m e S t a r t s W i t h C a p i t a l {

10 guard : s e l f . s a t i s f i e s ( ’ HasName ’ )11 check : s e l f . name . f i r s t T o U p p e r C a s e ( ) = s e l f . name12 message : ’ F o l d e r ’ + s e l f . name +13 ’ s h o u l d s t a r t w i th an upper−c a s e l e t t e r ’

56

14 f i x {15 t i t l e : ’ Rename t o ’ + s e l f . name . f i r s t T o U p p e r C a s e ( )16 do {17 s e l f . name := s e l f . name . f i r s t T o U p p e r C a s e ( ) ;18 }19 }20 }21 }

O objetivo da linguagem ETL é realizar transformações de modelos (model-to-model).Mais especificamente, ETL pode ser usado para transformar um número arbitrário de mo-delos de entrada para um número arbitrário de modelos de saída de diferentes linguagensde modelagem e tecnologias em um alto nível de abstração [17]. EGL é uma linguagemmodel-to-text. A partir de um metamodelo construído em Ecore, pode-se obter códigoexecutável, relatórios HTML, documentação, imagens (usando pontos) e outros artefatostextuais [25] [7].

Transformações de atualização são ações que automaticamente cria, atualiza oudeleta elementos do modelo baseado na seleção de elementos existentes no modelo e nasinformações fornecidas pelo usuário (através de dados de entrada). EWL é a linguagemda família Epsilon que oferece esse suporte [7].

2.4.4 Estudos que Desenvolveram Ferramentas de Modelagem

A seguir, apresentamos estudos que realizaram pesquisa na área de desenvolvimento deferramentas de modelagem. Estes estudos utilizaram tecnologias que também foramutilizadas nesta dissertação, como o Framework Eclipse em conjunto com os pluginsEMG/GMF e também o Framework Epsilon.

IStar Tool - Uma Proposta de Ferramenta para Modelagem i*O estudo descrito em [46] propõe o desenvolvimento de uma ferramenta de modela-

gem i*. Um novo metamodelo é desenvolvido para a nova versão do i* e um processo dedesenvolvimento para obter uma ferramenta gráfica de modelagem.

Para o desenvolvimento da ferramenta, foi adotado o GMF Framework, que permite amodelagem do domínio e a geração automática de código para representar os elementosgráficos que farão parte do modelo. O metamodelo foi criado a partir do Framework

EMF e escrito em Ecore.

A partir de um guia i* (contendo guidelines e boas práticas), o autor definiu umconjunto de restrições que foram escritas utilizando a linguagem de restrição OCL. Um

57exemplo de restrição é que um elemento não pode se ligar a ele mesmo. Uma segundarestrição é que a utilização do link de associação só é permitida para nós do tipo ator.

Após o desenvolvimento da ferramenta, a mesma foi aplicada em diferentes cenários,visando exemplificar seu uso e também realizar uma verificação para ver se as restriçõesque foram definidas anteriormente estavam sendo executadas corretamente. A conclusãoobtida foi que a ferramenta se comportou de maneira apropriada.

Uma Linguagem Específica do Domínio para uma Abordagem Orientada a Ob-jetivos Baseada em KAOS

O estudo apresentado em [6], demonstra um novo metamodelo da linguagem KAOSbaseado em um previamente existente. A partir deste metamodelo, uma ferramentaé desenvolvida. Para lidar com problemas de escalabilidade, os autores utilizaram oconceito de Compartimento.

Para implementar este conceito, o metamodelo foi estendido com caixas (Comparti-mentos) em que é possível guardar elementos específicos pertencentes aquela caixa. Estascaixas possuem uma característica de colapso, em que a partir de um clique é possívelapresentar ou omitir porções do diagrama.

A ferramenta apresentada nesta dissertação também possui este conceito de compar-timento. Assim, é possível esconder ou apresentar pedaços do modelo, obtendo umamelhor escalabilidade e diminuindo a complexidade visual. Visto que a capacidade decolapso facilita a leitura dos modelos.

Para projetar o editor gráfico, os autores utilizaram o Framework Eclipse em conjuntocom os plugins EMF/GMF. Estenderam o metamodelo Ecore já existente e definiramno metamodelo o que irá representar os conceitos da linguagem KAOS. Para validar aferramenta os autores realizaram um estudo de caso e uma avaliação de usabilidade.

A avaliação de usabilidade consistiu de um questionamento sobre a sintaxe da lin-guagem, facilidade de utilização da ferramenta e níveis de satisfação da ferramenta. Emgeral, os utilizadores mostraram grande aceitação da ferramenta. Ficaram satisfeitos e aacharam fácil de utilizar.

AGILE: Uma Abordagem para Geração Automática de Linguagens i*Em [4], o autor definiu uma abordagem automatizada para a definição estrutural de

linguagens baseadas no i* e a geração automática de ferramentas CASE de modelagemcorrespondentes utilizando os conceitos de linhas de produtos de software.

As tecnologias utilizadas para desenvolver uma ferramenta que automatize a definiçãode metamodelos de linguagens i* e a geração automática de editores gráficos foram oEMF/GMF, baseadas no Eclipse. O autor definiu um metamodelo núcleo (escrito em

58

Ecore) com base nos construtores comuns das linguagens i* com suporte para a inserçãode variabilidade existente nas diversas linguagens baseadas no i*.

A ferramenta proposta auxilia o usuário a projetar a estrutura de uma nova linguagemi* utilizando apenas uma interface gráfica, reduzindo consideravelmente alterações ma-nuais e direta em toda estrutura GMF. Com o propósito de testar a ferramenta, o autorrealizou um estudo de caso em que foi aplicado a ferramenta AGILE Tool na criaçãodo metamodelo da linguagem i* Aspectual, assim como a geração de seu editor demodelagem gráfica.

Metamodeling the Enhanced Entity-Relationship ModelO estudo descrito em [19] apresenta uma visão detalhada e prática sobre como

formalizar o modelo EER (Enhanced Entity-Relationship)3 através de um metamodelo.Para comprovar a viabilidade, expressividade e utilidade do metamodelo proposto, osautores desenvolveram uma ferramenta CASE e a testaram com exemplos práticos quecobrem os construtores da linguagem.

Para desenvolver a ferramenta, os autores utilizaram tecnologias Eclipse, como oEMF/GMF e o Framework Epsilon e suas linguagens. Essas mesmas tecnologias tambémforam utilizadas para desenvolver a ferramenta proposta nesta dissertação. O metamodelofoi escrito em Ecore, as validações foram implementadas em EVL e, além disso, osautores utilizaram a linguagem EGL para transformar modelo em código SQL/DDL.

2.5 Considerações do Capítulo

Nesta seção, foi apresentada a revisão sistemática da literatura sobre requisitos não-funcionais e informações contextuais em modelos de processos de negócio. Relatamoso processo da abordagem BVCCoN, Elicitar Variabilidade, Descrever Variabilidade,Analisar Contexto, Ligar RNF & Variantes e Realizar Configuração, discutimos trabalhosrelacionados, apresentamos conceitos de metamodelagem, UML, DSML e as tecnologiasutilizadas para o desenvolvimento da ferramenta proposta e, por fim, relatamos algunstrabalhos que desenvolveram ferramentas gráficas de modelagem.

3Linguagem de modelagem padrão para o projeto conceitual de banco de dados.

59

3BVCCoN Tool

Este capítulo trata da especificação da ferramenta proposta, incluindo as etapas de desen-volvimento e a criação de um metamodelo para a ferramenta da abordagem BVCCoN.Serão apresentadas as 3 diferentes visões do metamodelo, uma visão referente aos Requi-sitos Não-Funcionais, uma segunda visão relacionada às informações de contexto e porúltimo, será apresentada a visão de variabilidade. Estas visões serão exibidas por meio dasintaxe abstrata e concreta da linguagem.

3.1 Modelo e Metamodelo BVCCoN

A abordagem BVCCoN cobre três perspectivas na configuração de processos de negócio:a descrição da variabilidade, os Requisitos Não-Funcionais, e as informações de con-texto. Estas três perspectivas e seus conceitos são descritos através de seus respectivosmetamodelos em [48].

Da maneira como foi dividido, torna-se inviável a construção de uma ferramenta demodelagem que suporte estes três níveis, uma vez que abrange 3 diferentes metamodelos.Isto acontece devido a uma restrição da tecnologia EuGENia utilizada neste estudo, jáque a mesma gera ferramentas gráficas a partir de um metamodelo [13]. Portanto, este éum problema que precisa ser resolvido.

A solução encontrada foi realizar uma integração dos três metamodelos em apenas um,ao invés de um metamodelo importar outro, existe apenas um metamodelo que contémtodos os elementos dos outros, assim como seus relacionamentos. Assim, o problemaé solucionado e o desenvolvimento de uma ferramenta que cobre as 3 perspectivas épossível.

A Figura 3.1 apresenta o metamodelo reduzido da ferramenta proposta. As alteraçõesdos metamodelos foram realizadas de maneira independente. Por isso, o foco estava em

60

determinada visão, sem a interferência das outras duas perspectivas. Quando concluímosas três visões, realizamos a integração. Em outras palavras, os três metamodelos queantes estavam separados, agora fazem parte de apenas um metamodelo, o bvccontool.emf.

Dentro do nosso metamodelo, criamos uma classe chamada NFRModel e uma outrachamada ContextModel. A primeira possui todos os elementos relacionados à RequisitosNão-Funcionais. A segunda possui os elementos de contexto. Assim, deixamos bemseparadas as visões de RNF, contexto e variabilidade dentro de um único metamodelo.Os elementos referentes à variabilidade (VariationPoint, Variant, VariantsRelationship eWorkflowPattern) estão conectados diretamente com o elemento Model.

Variant é o elemento principal da modelagem, ele possui ligações com os elementosNFRSoftgoal, referente aos requisitos não-funcionais e ContextExpression referente àsinformações de contexto.

Figura 3.1 Parte do Metamodelo BVCCoN

Durante a modelagem, inconsistências podem acontecer. Elementos definidos nasintaxe abstrata não sendo representados na sintaxe concreta da linguagem ou elementosdefinidos na sintaxe concreta não existindo na sintaxe abstrata. O ideal é que ocorra umdesenvolvimento integrado de ambos artefatos [26]. A Figura 3.2 apresenta um caso emque a sintaxe concreta possui quatro elementos gráficos (quadrado, círculo, triângulo elosango), sendo que o losango não está representado no metamodelo. O caso inversoacontece na Figura 3.3, o elemento losango está representado no metamodelo porém sua

61representação não existe na sintaxe concreta. A Figura 3.4 apresenta um caso em que asintaxe concreta e abstrata estão compatíveis. Os elementos do domínio representadosem uma também está presente na outra.

Figura 3.2 Elementos Gráficos x Metamodelo - Exemplo 1


Durante o desenvolvimento da ferramenta proposta neste estudo, foi possível iden-tificar os casos da Figura 3.2 e 3.3. Em seguida, são descritas as três perspectivas daabordagem BVCCoN e também serão expostos os problemas identificados quanto aomapeamento entre sintaxe abstrata e concreta e qual a solução adotada.

3.1.1 Sintaxe Abstrata

Nesta seção, será detalhado os conceitos e relacionamentos do modelo BVCCoN. Estasdefinições estão agrupadas em quatro partes: modelo de processos de negócio, modelosde requisitos não-funcionais, modelo de descrição de variabilidade e modelo de contexto.Algumas dessas perspectivas já possuem metamodelos definidos na literatura, comoBPMN e RNF. Os modelos restantes foram definidos por [48]. Em cada uma dessasperspectivas, primeiro será apresentado o metamodelo descrito em [48] e, em seguida,

62


será comentado as alterações realizadas e apresentado o metamodelo final resultado dopresente estudo.

Nossa contribuição neste caso, será a integração de todos os metamodelos em apenasum, o metamodelo BVCCoN. Realizando os ajustes necessários para que a integraçãoseja feita de maneira correta, preservando as características dos modelos já definidos esempre buscando um desenvolvimento integrado da sintaxe abstrata com a concreta.

Os metamodelos obtidos em [48] estão escritos através de uma linguagem de me-tamodelagem que faz parte do EMF [10], chamada Ecore. O framework Epsilon [12]que utilizamos no desenvolvimento da ferramenta, descreve metamodelos através dalinguagem Emfatic [16] (ver subseção 2.4.3). O Epsilon possui um mecanismo onde tantoé possível transformar metamodelos Ecore para metamodelos escritos em Emfatic, comoo inverso. Portanto, transformamos os metamodelos em Ecore para Emfatic e seguimoscom os ajustes necessários.

3.1.1.1 Modelo BPMN

BPMN (Business Process Modeling and Notation) é uma linguagem de modelagem deprocessos de negócio definida pela OMG [36]. O objetivo do BPMN é oferecer umanotação que seja de fácil compreensão por todos os usuários do negócio, dos analistasde negócio que criam os rabiscos iniciais dos processos, até o desenvolvedor técnicoresponsável por implementar a tecnologia que irá executar o processo. Por fim, as pessoasdo negócio que irão gerenciar e monitorar esses processos [36].

A abordagem BVCCoN utiliza o BPMN para modelar os processos de negócio.O metamodelo BPMN é acessível a qualquer desenvolvedor [36], já está validado epossui muitas ferramentas de suporte. Possui diferentes tipos de modelos como: modelo

63de workflow, modelos de coreografia, dentre outros. A abordagem utiliza modelos deworkflow para modelar processos de negócio. Está fora do escopo desta dissertaçãodiscutir em detalhes o metamodelo BPMN. Para maiores informações, consultar [36].

3.1.1.2 Variabilidade

Os principais conceitos para representar variabilidade são: VariationPoint e Variants. Oprimeiro indica qual ponto no modelo de processo de negócio pode mudar, e o segundo sãoas partes do processo que podem ser acionadas para fazer parte do modelo de processo.Os VariationPoints e as Variants são representadas como elementos de processos denegócio (ver Figura 3.5).

Figura 3.5 Perspectiva de Variabilidade [48]

Os links begins e ends acessam o metamodelo do BPMN para um relacionamentocom os artefatos FlowElements. As Variants podem ser associadas à um ou mais Va-

riationPoints. Para representar os relacionamentos de dependência de variabilidade éutilizado o atributo Operator, que pode ser OR, AND e XOR.

Associado com esses operadores, encontra-se os patterns, que são informações quedizem como as variantes estarão posicionadas nos modelos de processos de negócio.Os WorkFlowPatterns podem representar, sequência, paralelismo, comportamento op-cional, dentre outros. As Variants são associadas com os VariationPoints por meio dePatterns. As Variants são representadas por pedaços de processos de negócio por meiodo BusinessProcessPart.

64

Cada BusinessProcessPart se refere aos FlowElements do metamodelo BPMN epossui os links begins e ends assim como nos VariationPoints. As Variants possuemalgumas restrições como por exemplo: requires e excludes. A primeira requer a presençade outra variant e a segunda exclui uma variant. Todas essas informações podem servistas na Figura 3.5.

Até aqui foi descrito o metamodelo da perspectiva de variabilidade da abordagemBVCCoN [48]. Os próximos parágrafos detalha as alterações que foram realizadas nometamodelo com o intuito de construir uma ferramenta de modelagem gráfica, semprebuscando o alinhamento entre sintaxe abstrata e concreta.

Da maneira como o metamodelo foi construído, seria necessário que BusinessProces-

sPart funcionasse como um nó durante a modelagem, o que não estava de acordo coma sintaxe concreta. A sintaxe abstrata possuia o elemento BusinessProcessPart que nãoera refletido na sintaxe concreta, ou seja, não existia elemento gráfico que representasseBusinessProcessPart. Portanto, para que a sintaxe abstrata e concreta estivessem deacordo uma com a outra, transferirmos os atributos de BusinessProcessPart e aloca-mos em Variant. Desta maneira, Variant pode acessar diretamente os FlowElements dometamodelo BPMN sem a necessidade de um outro nó como intermediário.

Também criamos os relacionamentos de source e target dos links excludes e requires,o que antes não estava representado no metamodelo. Assim, conseguimos deixar asintaxe abstrata e concreta compatível, ou seja, os elementos gráficos da sintaxe concretaestão representados na sintaxe abstrata e o que está sendo representado no metamodelo érefletido na sintaxe concreta (ver Figura 3.6). A Listagem 3.1 apresenta o metamodelo devariabilidade escrito na linguagem Emfatic. As anotações representam o seguinte:

• Linhas 1 a 5: cada Variante é representada como uma Elipse cinza com bordaspretas tracejadas. Possui os atributos name, id e isDefault. Também possui umapontamento para um modelo BPMN externo, representado pelas linhas 10, 11 e12;

• Linhas 6 e 7: Variant possui um link chamado varPoints que é responsável porligar uma variante a um ponto de variação. Esse link é representado por uma linhapreta contínua;

• Linhas 14 a 18: ContextExpressionLink é um link tracejado que possui como source

uma variante e como target uma expressão de contexto (ContextExpression);

• Linhas 19 a 27: cada ponto de variação (varPoints) é representado por um retângulocinza que possui os atributos id, name e operator. O atributo operator é uma

65enumeração que possui as opções AND, OR e XOR. Assim como uma variante, oponto de variação também possui apontamentos para um modelo BPMN externo;

• Linhas 37 e 38: o link variantSource é um link representado por uma seta fechadano elemento target. Responsável por ligar um WorkflowPattern a uma variante;

• Linhas 53 a 56: cada Requires é representado como um link entre duas variantes.A representação gráfica do link é através de uma linha contínua com um pequenoquadrado no elemento target;

• Linhas 57 a 60: cada Excludes é representado como um link entre duas variantes.A representação gráfica do link é através de uma linha contínua com um pequenoquadrado de cor preta no elemento target;

Figura 3.6 Metamodelo Variability - BVCCoN

Listagem 3.1 Metamodelo Variabilidade escrito em Emfatic

1 @gmf . node ( f i g u r e =" e l l i p s e " , b o r d e r . s t y l e =" dash " , l a b e l . p l a c e m e n t ="i n t e r n a l " , l a b e l . i c o n =" f a l s e " , l a b e l ="name " , b o r d e r . c o l o r = " 0 , 0 , 0 " ,

c o l o r ="143 ,148 ,152" , s i z e = " 6 0 , 6 0 " )2 c l a s s V a r i a n t {3 a t t r S t r i n g [ 1 ] name ;

66

4 i d a t t r S t r i n g [ 1 ] ~ i d ;5 a t t r b o o l e a n [ 1 ] i s D e f a u l t ;6 @gmf . l i n k ( s o u r c e . d e c o r a t i o n =" none " , t a r g e t . d e c o r a t i o n =" none " , c o l o r

= " 0 , 0 , 0 " )7 r e f V a r i a t i o n P o i n t [ * ] # v a r i a n t s v a r P o i n t s ;8 r e f W o r k f l o w P a t t e r n [ * ] # v a r i a n t S o u r c e p a t t e r n ;9 / / Os a t r i b u t o s a b a i x o s e r i a m de B u s i n e s s P r o c e s s P a r t

10 r e f bpmn2 . FlowElement [ 1 ] b e g i n s ;11 r e f bpmn2 . FlowElement [ 1 ] ends ;12 r e f bpmn2 . FlowElement [ * ] f l o w E l e m e n t s ;13 }14 @gmf . l i n k ( s t y l e =" dash " , c o l o r = " 0 , 0 , 0 " , s o u r c e =" s o u r c e " , t a r g e t =" t a r g e t

" , incoming =" t r u e " )15 c l a s s C o n t e x t E x p r e s s i o n L i n k {16 r e f V a r i a n t s o u r c e ;17 r e f C o n t e x t E x p r e s s i o n t a r g e t ;18 }19 @gmf . node ( l a b e l . p l a c e m e n t =" i n t e r n a l " , l a b e l . i c o n =" f a l s e " , l a b e l ="name

" , b o r d e r . c o l o r = " 0 , 0 , 0 " , c o l o r = " 1 4 3 , 1 4 8 , 1 5 2 " )20 c l a s s V a r i a t i o n P o i n t {21 i d a t t r S t r i n g [ 1 ] ~ i d ;22 a t t r S t r i n g [ 1 ] name ;23 a t t r V a r i a t i o n P o i n t O p e r a t o r [ 1 ] o p e r a t o r ;24 r e f bpmn2 . FlowElement [ 1 ] b e g i n s ;25 r e f bpmn2 . FlowElement [ 1 ] ends ;26 r e f bpmn2 . FlowElement [ * ] f l o w E l e m e n t s ;27 }28 enum V a r i a t i o n P o i n t O p e r a t o r {29 AND = 0 ;30 OR = 1 ;31 XOR = 2 ;32 }33 @gmf . node ( f i g u r e =" r e c t a n g l e " , b o r d e r . s t y l e =" dash " , l a b e l . p l a c e m e n t ="

i n t e r n a l " , l a b e l . i c o n =" f a l s e " , l a b e l =" w f P a t t e r n " , b o r d e r . c o l o r= " 0 , 0 , 0 " , s t y l e =" d o t " )

34 c l a s s W o r k f l o w P a t t e r n {35 a t t r Workf lowPa t t e rnType w f P a t t e r n ;36 i d a t t r S t r i n g [ 1 ] ~ i d ;37 @gmf . l i n k ( s o u r c e . d e c o r a t i o n =" none " , t a r g e t . d e c o r a t i o n =" c l o s e d a r r o w " ,

c o l o r = " 0 , 0 , 0 " )38 r e f V a r i a n t [ 1 ] # p a t t e r n v a r i a n t S o u r c e ;39 }40 enum Workf lowPa t t e rnType {

6741 SEQUENCE = 0 ;42 PARALLEL_SPLIT = 1 ;43 SYNCHRONISATION = 2 ;44 EXCLUSIVE_CHOICE = 3 ;45 SIMPLE_MERGE = 4 ;46 MULTIPLE_CHOICE = 5 ;47 }48 c l a s s V a r i a n t s R e l a t i o n s h i p {49 r e f V a r i a n t [ 1 ] r e l a t i o n s h i p S o u r c e ;50 r e f V a r i a n t [ 1 ] r e l a t i o n s h i p T a r g e t ;51 i d a t t r S t r i n g [ 1 ] ~ i d ;52 }53 @gmf . l i n k ( s o u r c e . d e c o r a t i o n =" none " , t a r g e t . d e c o r a t i o n =" s q u a r e " , c o l o r

= " 0 , 0 , 0 " , s o u r c e =" r e l a t i o n s h i p S o u r c e " , t a r g e t =" r e l a t i o n s h i p T a r g e t" , incoming =" t r u e " )

54 c l a s s R e q u i r e s ex tends V a r i a n t s R e l a t i o n s h i p {55 a t t r S t r i n g [ 1 ] name=" r e q u i r e s " ;56 }57 @gmf . l i n k ( s o u r c e . d e c o r a t i o n =" none " , t a r g e t . d e c o r a t i o n =" f i l l e d s q u a r e " ,

c o l o r = " 0 , 0 , 0 " , s o u r c e =" r e l a t i o n s h i p S o u r c e " , t a r g e t ="r e l a t i o n s h i p T a r g e t " , incoming =" t r u e " )

58 c l a s s E x c l u d e s ex tends V a r i a n t s R e l a t i o n s h i p {59 a t t r S t r i n g [ 1 ] name=" e x c l u d e s " ;60 }

3.1.1.3 Contexto

O metamodelo de contexto definido por [48] foi baseada na avaliação de linguagem pararepresentar contexto proposta por [2]. Ela é baseada na decomposição de contexto emuma fórmula de facts e statements.

Um statement é um predicado do mundo que não pode ser verificado por um atordentro do contexto. Um statement pode ser decomposto em outros statements ou facts.Além disso, facts podem ser verificados e associados à variáveis. A Figura 3.7 apresentaa perspectiva de Contexto da abordagem BVCCoN.

A classe BVCCoNContext é responsável por representar as informações contextuais.Um contexto é composto por uma ContextExpression que é composta por uma fórmula dePredicates. Um Predicate pode ser um statement, um fact ou um PredicateDecomposition.Um statement descreve uma expressão que não pode ser validada sozinha. Por isso, éapoiado por um outro Predicate. Predicates podem ser decompostos por outros predicates

68

Figura 3.7 Perspectiva Contexto [48]

utilizando os operadores AND, OR e NOT. Facts podem ser avaliados e validados. Estãoassociados à variables, que expressam os valores avaliados pela fórmula de predicados.

Analisando a perspectiva de Contexto, foi necessário realizar algumas alterações paraque a sintaxe abstrata e concreta mantenham-se alinhadas. Primeiramente, no metamodeloda Figura 3.7 não existe nenhuma classe para representar os links que irão realizar osrelacionamentos entre as classes nós. Por isso, criamos três classes para representar oslinks: ContextExpressionLink, PredicateLink e CELink. Estas classes podem ser vistas naFigura 3.8.

Na Figura 3.8, Variants precisam de um relacionamento com ContextExpression. Aclasse ContextExpressionLink é responsável por garantir este relacionamento. O link pararelacionamentos entre Predicates é o PredicateLink. Por último, CELink realiza apenasligação entre um Predicate e uma ContextExpression.

A nível de desenvolvimento de ferramenta, mudamos a maneira como a classeBVCCoNContext está inserida no metamodelo. Da forma como está representada, serianecessário que BVCCoNContext fosse um nó para que realmente ela pudesse ser expressano momento da modelagem. O que, de certa forma, não era compatível com a sintaxeconcreta. Na sintaxe concreta, BVCCoNContext não existe, por isso, resolvemos mantê-lano metamodelo da ferramenta apenas como uma classe abstrata a qual ContextExpression

herda, não perdendo totalmente a característica do metamodelo anterior.

Da maneira como o metamodelo estava desenvolvido, no momento da modelagempara inserir um OrDecomposition, AndDecomposition ou NotDecomposition seria ne-

69cessário inserir um nó chamado PredicateDecomposition e relacionar com a classeque representa o Or, And ou Not. Porém, PredicateDecomposition é uma classe quenão é representada durante a modelagem. Então, decidimos excluir a classe chamadaDecompositionType, e fazer a herança dos operadores lógicos diretamente com Predicate-

Decomposition. Desta maneira, conseguimos resolver o problema existente.

Como a complexidade do metamodelo de Contexto aumentou, também decidimoscriar uma classe Nó e uma Link, com o intuito de deixar bem claro e separado quaisas classes "Nós"e quais as classes "Links"dentro do metamodelo. A Figura 3.8 exibe ometamodelo de Contexto da ferramenta proposta nesta dissertação. Todas as alteraçõespodem ser conferidas e comparadas com o metamodelo da Figura 3.7. A Listagem 3.2apresenta o metamodelo de Contexto escrito na linguagem Emfatic. Os itens abaixoapresentam as anotações.

• Linha 1: ContextModel é representado através de um retângulo com as bordasarredondadas;

• Linha 4: um ContextModel é um compartimento onde sub-componentes podem seralocados;

• Linha 14: cada ContextExpression é representado no diagrama como uma Elipse.Possui os atributos id e name;

• Linha 22: os Statements são representados por um retângulo com uma descrição.Seus atributos são id e a própria description;

• Linha 30: cada CELink é representado como um link entre um Predicate e umaContextExpression. A representação gráfica do link é através de uma seta fechada;

• Linha 35: cada PredicateLink representa um link entre os Predicates. A representa-ção gráfica do link é através de uma seta fechada com a cor preta;

• Linha 40: os Facts são representados no diagrama por um retângulo com a bordapontilhada. Os atributos valid, description e name fazem parte deste elemento;

• Linha 45: os Facts possuem um link chamado de variables que realiza ligaçõesentre fatos e variáveis. A representação gráfica é uma linha pontilhada;

• Linha 48: uma Variable é representado por um retângulo amarelo com bordasarredondadas. Os atributos pertencentes são: name, type e value;

70

• Linha 58 e 62: são as decomposições AND e OR de contexto. O símbolo gráfico éum losango com o label AND ou OR;

• Linha 56: NotDecomposition é um link cuja representação gráfica é uma flechafechada com o label NOT.

Figura 3.8 Metamodelo Contexto - BVCCoN-Tool

Listagem 3.2 Metamodelo Contexto escrito em Emfatic

1 @gmf . node ( l a b e l ="name " , l a b e l . p l a c e m e n t =" i n t e r n a l " , l a b e l . i c o n =" f a l s e" , f i g u r e =" rounded " , b o r d e r . c o l o r = " 0 , 0 , 0 " , s i z e = " 5 0 0 , 2 0 0 " )

2 c l a s s ContextModel {3 a t t r S t r i n g [ 1 ] name=" C o n t e x t Model " ;4 @gmf . compar tment5 v a l Node [ * ] nodes ;6 v a l Link [ * ] l i n k s ;7 }8 c l a s s Node{9

10 }

7111 a b s t r a c t c l a s s BVCCoNContext {12

13 }14 @gmf . node ( f i g u r e =" e l l i p s e " , l a b e l . i c o n =" f a l s e " , l a b e l ="name " , l a b e l .

p l a c e m e n t =" i n t e r n a l " , b o r d e r . c o l o r = " 0 , 0 , 0 " , b o r d e r . s t y l e =" s o l i d " ,c o l o r = " 1 5 3 , 1 5 3 , 1 5 3 " )

15 c l a s s C o n t e x t E x p r e s s i o n ex tends BVCCoNContext , Node{16 a t t r S t r i n g [ 1 ] name = "C " ;17 i d a t t r S t r i n g [ 1 ] ~ i d ;18 }19 a b s t r a c t c l a s s P r e d i c a t e ex tends Node{20

21 }22 @gmf . node ( f i g u r e =" r e c t a n g l e " , l a b e l . p l a c e m e n t =" i n t e r n a l " , l a b e l ="

d e s c r i p t i o n " , l a b e l . i c o n =" f a l s e " , s i z e ="100 ,60" , b o r d e r . c o l o r= " 0 , 0 , 0 " , b o r d e r . s t y l e =" s o l i d " )

23 c l a s s S t a t e m e n t ex tends P r e d i c a t e {24 i d a t t r S t r i n g [ 1 ] ~ i d ;25 a t t r S t r i n g [ 1 ] d e s c r i p t i o n = "S : S t a t e m e n t " ;26 }27 c l a s s Link {28

29 }30 @gmf . l i n k ( s o u r c e . d e c o r a t i o n =" none " , t a r g e t . d e c o r a t i o n =" c l o s e d a r r o w " ,

c o l o r = " 0 , 0 , 0 " , s o u r c e =" s o u r c e " , t a r g e t =" t a r g e t " )31 c l a s s CELink ex tends Link {32 r e f P r e d i c a t e [ 1 ] s o u r c e ;33 r e f C o n t e x t E x p r e s s i o n [ 1 ] t a r g e t ;34 }35 @gmf . l i n k ( s o u r c e . d e c o r a t i o n =" none " , t a r g e t . d e c o r a t i o n ="

f i l l e d c l o s e d a r r o w " , c o l o r = " 0 , 0 , 0 " , s o u r c e =" s o u r c e " , t a r g e t =" t a r g e t" , incoming =" t r u e " )

36 c l a s s P r e d i c a t e L i n k ex tends Link {37 r e f P r e d i c a t e [ 1 ] s o u r c e ;38 r e f P r e d i c a t e [ 1 ] t a r g e t ;39 }40 @gmf . node ( f i g u r e =" r e c t a n g l e " , l a b e l . p l a c e m e n t =" i n t e r n a l " , l a b e l ="

d e s c r i p t i o n " , l a b e l . i c o n =" f a l s e " , s i z e ="100 ,60" , b o r d e r . c o l o r= " 0 , 0 , 0 " , b o r d e r . s t y l e =" d o t " )

41 c l a s s F a c t ex tends P r e d i c a t e {42 a t t r b o o l e a n [ 1 ] v a l i d ;43 a t t r S t r i n g [ 1 ] d e s c r i p t i o n = "F : F a c t " ;44 i d a t t r S t r i n g [ 1 ] name ;

72

45 @gmf . l i n k ( s o u r c e . d e c o r a t i o n =" none " , t a r g e t . d e c o r a t i o n =" none " , c o l o r= " 0 , 0 , 0 " , s t y l e =" d o t " , incoming =" t r u e " )

46 r e f V a r i a b l e [ * ] v a r i a b l e s ;47 }48 @gmf . node ( l a b e l . p l a c e m e n t =" i n t e r n a l " , l a b e l . i c o n =" f a l s e " , l a b e l ="name

" , s i z e ="100 ,30" , b o r d e r . c o l o r = " 0 , 0 , 0 " , c o l o r = " 2 5 5 , 2 5 5 , 1 0 2 " )49 c l a s s V a r i a b l e ex tends Node{50 a t t r S t r i n g [ 1 ] name ;51 a t t r S t r i n g [ 1 ] t y p e ;52 a t t r S t r i n g [ 1 ] v a l u e ;53 }54 a b s t r a c t c l a s s P r e d i c a t e D e c o m p o s i t i o n ex tends P r e d i c a t e {55

56 }57 @gmf . node ( f i g u r e =" org . e c l i p s e . e p s i l o n . e u g e n i a . b v c c o n t o o l . d iagram .

f i g u r e s . DiamondFigure " , l a b e l ="name " , s i z e = " 1 0 0 , 6 0 " )58 c l a s s OrDecompos i t ion ex tends P r e d i c a t e D e c o m p o s i t i o n {59 i d a t t r S t r i n g [ 1 ] name = "OR" ;60 }61 @gmf . node ( f i g u r e =" org . e c l i p s e . e p s i l o n . e u g e n i a . b v c c o n t o o l . d iagram .

f i g u r e s . DiamondFigure " , l a b e l ="name " , s i z e = " 1 0 0 , 6 0 " )62 c l a s s AndDecomposi t ion ex tends P r e d i c a t e D e c o m p o s i t i o n {63 i d a t t r S t r i n g [ 1 ] name = "AND" ;64 }65 @gmf . l i n k ( s o u r c e . d e c o r a t i o n =" none " , t a r g e t . d e c o r a t i o n ="

f i l l e d c l o s e d a r r o w " , c o l o r = " 0 , 0 , 0 " , s o u r c e =" s o u r c e " , t a r g e t =" t a r g e t" , s t y l e =" dash " , incoming =" t r u e " )

66 c l a s s NotDecompos i t ion ex tends P r e d i c a t e D e c o m p o s i t i o n , P r e d i c a t e L i n k {67 i d a t t r S t r i n g [ 1 ] name = "NOT" ;68 }

3.1.1.4 Requisitos Não-Funcionais

O metamodelo adotado por [48] em sua abordagem é baseado no NFRFramework [30],porém, com algumas alterações. O autor adaptou o metamodelo do NFRFramework

para que ficasse de acordo com a abordagem proposta, assim, alguns conceitos foramremovidos e outros adaptados. A Figura 3.9 apresenta a perspectiva RNF adaptada.

Os principais conceitos são o NFRSoftgoal e o NFRSoftgoalContribution, que são oselementos principais do NFRFramework. São empregados para descrever os catálogos deRNF, as decomposições dos RNF, e para representar as contribuições entre RNF e dasVariants para os RNFs. Os relacionamentos de contribuição representados pelo NFRSoft-

73

Figura 3.9 Perspectiva RNF [48].

goalContribution possui vários sub-tipos como: BreakContribution, HurtContribution,EqualContribution, HelpContribution e MakeContribution, que varia respectivamente doimpacto mais negativo ao impacto mais positivo.

Contribuições como OrContribution e AndContribution são usadas para decompor osRNFs durante a definição do catálogo de RNFs. Os relacionamentos de contribuição sãoutilizados para representar preferências entre as Variants (que é um elemento concreto).A classe para representar esse ideia é a NFROperationalization.

Durante a análise da perspectiva RNF (ver Figura 3.9), verificamos que todos oslinks da classe NFRSoftgoalContribution poderiam ser utilizados para realizar ligaçõesentre RNFs, ligações de decomposição entre NFRSoftgoal com NFROperationalization

e vice-versa, o que de acordo com as especificações, não é permitido. Em [48], o autorutiliza regras OCL para restringir as ligações entre de contribuição entre NFRSoftgoal

como source e Variant como target. Assim como as decomposições OR e AND só podemser feitas entre NFRSoftgoals.

Da maneira como as restrições foram utilizadas, não impedirá o usuário de realizarrelacionamentos incorretos. A ferramenta iria acusar um erro de relacionamento, masmesmo assim as ligações ainda seriam permitidas. Para impedir o usuário de cometererros relacionados a esses aspectos, decidimos alterar o metamodelo (ver Figura 3.10).

Mantemos a classe NFRSoftgoalContribution com apenas dois links, OrContribution

e AndContribution. Esses links só podem ligar apenas NFRSoftgoal. Criamos umanova classe chamada NFRSoftgoalContributionalOperational, que contém os links decontribuição BreakContribution, HurtContribution, EqualContribution, HelpContribu-

tion e MakeContribution. Esses links possuem como source uma Variant (que estárepresentando o NFROperationalization) e como target um NFRSoftgoal.

Desta maneira, conseguimos impedir os usuários de realizar ligações incorretas pelopróprio metamodelo. Assim, regras OCL ou EVL (fornecida pelo framework Epsilon)

74

Figura 3.10 Metamodelo RNF - BVCCoN

não são necessárias. No momento de realizar a modelagem, a ferramenta impedirá açõeserrôneas. A Listagem 3.3 apresenta o metamodelo de RNF escrito na linguagem Emfatic.Em particular, as anotações representam o seguinte:

• Linha 2: NFRModel é representado através de um retângulo com as bordas arre-dondadas;

• Linha 4: um NFRModel é um compartimento onde sub-componentes podem seralocados;

• Linhas 15 a 18: cada NFRSoftgoal é representado no diagrama como um retângulocom bordas tracejadas que possui os atributos id, name e NFRSoftgoalPriority;

• Linha 38 e 43: representam os links de contribuição OR e AND entre NFRSoftgoals.Sua representação gráfica é uma linha contínua preta com os labels OR ou AND;

• Linhas 48, 53, 58, 63 e 68: representam os links de contribuição Break, Make, Equal,

Hurt e Help entre variantes e NFRSoftgoals respectivamente. Sua representaçãográfica é uma linha continua preta com os labels - -, ++, =, - ou +.

Listagem 3.3 Metamodelo RNF escrito em Emfatic

1 @gmf . node ( l a b e l ="name " , l a b e l . p l a c e m e n t =" i n t e r n a l " , l a b e l . i c o n =" f a l s e" , f i g u r e =" rounded " , b o r d e r . c o l o r = " 0 , 0 , 0 " , s i z e = " 5 0 0 , 2 0 0 " )

752 c l a s s NFRModel{3 a t t r S t r i n g [ 1 ] name="NFR Model " ;4 @gmf . compar tment5 v a l NFRElement [ * ] n f r e l e m e n t s ;6 v a l N F R S o f t g o a l C o n t r i b u t i o n [ * ] c o n t r i b u t i o n s ;7 v a l N F R S o f t g o a l C o n t r i b u t i o n O p e r a t i o n a l [ * ]

c o n t r i b u t i o n s O p e r a t i o n a l s ;8 }9

10 c l a s s NFRElement{11 ! o r d e r e d a t t r S t r i n g [ 1 ] name ;12 i d a t t r S t r i n g [ 1 ] ~ i d ;13 }14

15 @gmf . node ( l a b e l . p l a c e m e n t =" i n t e r n a l " , l a b e l . i c o n =" f a l s e " , l a b e l ="name" , s i z e ="100 ,30" , b o r d e r . c o l o r = " 0 , 0 , 0 " , b o r d e r . s t y l e =" dash " )

16 c l a s s NFRSoftgoal ex tends NFRElement{17 ! o r d e r e d a t t r E B i g I n t e g e r [ 1 ] N F R S o f t g o a l P r i o r i t y = " 0 " ;18 }19

20 c l a s s N F R O p e r a t i o n a l i z a t i o n ex tends NFRElement{21 }22

23 c l a s s NFRLink {24

25 }26

27 c l a s s N F R S o f t g o a l C o n t r i b u t i o n ex tends NFRLink {28 ! o r d e r e d r e f NFRSoftgoal [ 1 ] s o u r c e ;29 ! o r d e r e d r e f NFRSoftgoal [ 1 ] t a r g e t ;30 }31

32

33 c l a s s N F R S o f t g o a l C o n t r i b u t i o n O p e r a t i o n a l ex tends NFRLink{34 ! o r d e r e d r e f V a r i a n t [ 1 ] s o u r c e ;35 ! o r d e r e d r e f NFRSoftgoal [ 1 ] t a r g e t ;36 }37

38 @gmf . l i n k ( s o u r c e . d e c o r a t i o n =" none " , t a r g e t . d e c o r a t i o n =" none " , s o u r c e ="s o u r c e " , t a r g e t =" t a r g e t " , c o l o r = " 0 , 0 , 0 " )

39 c l a s s O r C o n t r i b u t i o n ex tends N F R S o f t g o a l C o n t r i b u t i o n {40 a t t r S t r i n g name="OR" ;41 }

76

42

43 @gmf . l i n k ( s o u r c e . d e c o r a t i o n =" none " , t a r g e t . d e c o r a t i o n =" none " , s o u r c e ="s o u r c e " , t a r g e t =" t a r g e t " , c o l o r = " 0 , 0 , 0 " )

44 c l a s s A n d C o n t r i b u t i o n ex tends N F R S o f t g o a l C o n t r i b u t i o n {45 a t t r S t r i n g name="AND" ;46 }47

48 @gmf . l i n k ( t a r g e t . d e c o r a t i o n =" ar row " , s o u r c e . d e c o r a t i o n =" none " , t a r g e t .d e c o r a t i o n =" none " , s o u r c e =" s o u r c e " , t a r g e t =" t a r g e t " , c o l o r= " 0 , 0 , 0 " )

49 c l a s s B r e a k C o n t r i b u t i o n ex tends N F R S o f t g o a l C o n t r i b u t i o n O p e r a t i o n a l {50 a t t r S t r i n g name="−−";51 }52


54 c l a s s M a k e C o n t r i b u t i o n ex tends N F R S o f t g o a l C o n t r i b u t i o n O p e r a t i o n a l {55 a t t r S t r i n g name ="++" ;56 }57


59 c l a s s E q u a l C o n t r i b u t i o n ex tends N F R S o f t g o a l C o n t r i b u t i o n O p e r a t i o n a l {60 a t t r S t r i n g name = " = " ;61 }62


64 c l a s s H u r t C o n t r i b u t i o n ex tends N F R S o f t g o a l C o n t r i b u t i o n O p e r a t i o n a l {65 a t t r S t r i n g name ="−";66 }67


69 c l a s s H e l p C o n t r i b u t i o n ex tends N F R S o f t g o a l C o n t r i b u t i o n O p e r a t i o n a l {70 a t t r S t r i n g name = " + " ;71 }

77

3.1.2 Sintaxe Concreta

Na seção anterior, nós descrevemos a sintaxe abstrata da linguagem de modelagem. Ana-lisamos as três visões da abordagem BVCCoN, identificamos alterações no metamodeloe realizamos essas alterações. Sempre buscando a coerência entre a sintaxe abstrata econcreta. Nesta seção, iremos descrever a sintaxe concreta para as visões citadas anteri-ormente. O modelo de processo de negócio já possui uma sintaxe concreta definida nometamodelo BPMN 2.0, por isso, não será necessário descrever a sintaxe concreta doBPMN.

3.1.2.1 Variabilidade

Os principais conceitos relacionados à variabilidade, são os VariationPoints e as Variants.Os VariationPoints estão associados aos elementos de fluxo do BPMN, indicam ondeo ponto de variação começa, onde termina e quais são os elementos pertencentes aoponto de variação. Estas informações são armazenas pelos atributos Begins, Ends eFlowElements do ponto de variação. Na sintaxe concreta, definimos que a notação gráficade VariationPoint armazenará informações como Id, Name, os operadores lógicos AND,

OR e XOR e as variantes que fazem parte do ponto de variação.

O operador lógico de um ponto de variação está relacionado com as variantes, porexemplo, o operador AND indica que todas as variantes daquele ponto de variação podemser selecionadas. Analisando a Figura 3.11, o ponto de variação VP0 possui o operadorAND, portanto, as variantes Realizar Verificação de Segurança e Realizar Verificação

Extra de Segurança podem ser selecionadas simultaneamente. Interessante observar queexiste um link chamado Requires entre a variante Realizar Verificação Extra de Segurança

e a variante Realizar Verificação de Segurança. Isto indica que a presença de Realizar

Verificação Extra de Segurança requer obrigatoriamente a presença da variante Realizar

Verificação de Segurança.

Para identificar os pontos de início e fim de um ponto de variação e os elementosque farão parte do mesmo, é necessário importar um modelo de processo de negócio naferramenta. Assim, o ponto de variação terá acesso aos elementos de fluxo do processoque foi modelado. O processo de referência importado é o da Figura 4.1, que apresentaas atividades para realizar check-in em um aeroporto.

A Figura 3.11 também apresenta os elementos da sintaxe concreta (a) e abstrata(b). Observe que VariationPoint (1) está conectado aos FlowElements (2) representadospelas tarefas Realizar Verificação de Segurança e Realizar Embarque e está associado

78

com as Variants (3) Realizar Verificação de Segurança e Realizar Verificação Extra de

Segurança.

Figura 3.11 Sintaxe concreta do Ponto de Variação.

A associação entre um VariationPoint e uma Variant é feito através de um link, ondeo source é a variante e o target o ponto de variação. Similar a um VariationPoint, umaVariant possui elementos de fluxo modelados em BPMN. Essa associação ocorre atravésda indicação sobre onde a variante começa, onde termina e quais os elementos de fluxo

79pertencentes àquela variante. Assim, importa-se o modelo BPMN e a variante terá totalacesso aos elementos que foram modelados.

As variantes também podem se relacionar entre si. Isto ocorre com os links Requires

e Excludes. O primeiro, quando uma variante está presente, requer que a outra tambémesteja. A segunda é o inverso, quando determinada variante está presente, a outra éexcluída. Para informar em como uma Variant será alocada em um novo processo, énecessário associá-la a um WorkflowPattern, que pode ser: Sequence, Parallel, dentreoutros. Uma variante também está associada a um ou mais contextos.

A Figura 3.12 mostra um exemplo utilizando um processo de emergência quantoa existência de fogo. Este processo foi descrito na seção 2.2.2 e pode ser encontradona Figura 2.2. A próxima tarefa do processo após Verificar Risco e Resgatar qualquer

pessoa em perigo é Tocar o alarme de Incêndio. O ponto de variação da Figura 3.12 estáapontando para tarefa Tocar o alarme de Incêndio e possui duas variantes associadas,Tocar Alarme de Fogo Manualmente e Tocar Alarme de Fogo Automaticamente.

A Figura 3.12 mostra duas Variants associadas a um VariationPoint. Observe que aVariant Tocar Alarme de Fogo Automaticamente (1), está conectada ao VariationPoint VP0

(5) e está associada ao FlowElement (3) Tocar Alarme de Fogo Automaticamente. Tambémestá conectada ao WorkflowPattern (4) EXCLUSIVE_CHOICE. (2) são as propriedadesda variante Tocar Alarme de Fogo Automaticamente. Esta variante está apontando seusatributos Begins e Ends para uma tarefa BPMN também chamada Tocar Alarme de

Fogo Automaticamente. Como os atributos Begins e Ends apontam para uma únicatarefa, o atributo FlowElements só contém uma tarefa. A Variante Tocar Alarme de Fogo

Automaticamente está relacionada com o contexto ServiçosDeBackupEstãoFuncionando,portanto, esta variante só poderá ser selecionada quando este contexto estiver ativo.

O atributo IsDefault quer dizer que se não existir outra variante válida esta será aescolhida, a ideia é deixar sempre um caminho possível. No caso da variante Tocar

Alarme de Fogo Automaticamente, este atributo é falso. O tipo de WorkflowPattern

associado a esta variante é o EXCLUSIVE_CHOICE, indicando que os elementos defluxo BPMN da variante serão incluídos no processo através de uma escolha exclusiva. Oatributo Var Points indica a qual ponto de variação a variante pertence. O número 3 é umelemento de fluxo BPMN, uma tarefa que faz parte da variante e, por fim, número 4 é oWorkFlowPattern que está associado a variante.

80

Figura 3.12 Sintaxe concreta de uma Variante.

3.1.2.2 Requisitos Não-Funcionais

A perspectiva de Requisitos Não-Funcionais foi adaptada do NFRFramework [30]. Deacordo com este framework, os NFRSoftgoals são nós em formatos de nuvens que sãoassociados por NFRSoftgoalContribution e pelos links NFRSoftgoalCorrelation. Sim-plificamos a notação visual trocando o símbolo da nuvem por um retângulo com bordas

81tracejadas e vértices arredondados, afim de que a ferramenta desenhe adequadamente,além de otimizar o tempo no desenvolvimento da mesma.

Quando dois NFRSoftgoals são conectados, são utilizados os links AndContribution eOrContribution. Ambos são representados por um link com um label AND e OR respec-tivamente. Por outro lado, quando NFRSoftgoals conectam NFROperationalization, ascontribuições são MakeContribution, HelpContribution, EqualContribution, HurtContri-

bution e BreakContribution. Representados graficamente por links com os respectivoslabels: ++, +, =, - e - -.

No NFRFramework, NFROperationalization possui a mesma representação de NFR-

Softgoal, uma nuvem, porém, com bordas mais sólidas. Em nosso caso, o que irárepresentar as operacionalizações são as Variants. A representação gráfica das variantespodem ser encontradas na seção 3.1.2.1.

A Figura 3.13 apresenta um exemplo levando em consideração o processo de check-in

em aeroporto (ver Figura 4.1), mais especificamente a tarefa Realizar Verificação de

Segurança do processo. O requisito não-funcional que é levado em consideração é oSegurança, que é decomposto em outros RNFs. A variante Realizar Verificação Extra de

Segurança e suas ligações de contribuições com os Softgoals também são exibidas.

Neste caso, se a variante Realizar Verificação Extra de Segurança for ativada eos elementos de fluxo BPMN pertencentes a esta variante forem inclusos no processoprincipal, ela irá contribuir positivamente para a Confidencialidade e Controle de Acesso,gerando Segurança para o processo de negócio.

A Figura 3.13 descreve os elementos da sintaxe concreta (a) e a sintaxe abstrata(b). O compartimento NFRModel (1) é responsável por armazenar os NFRSoftgoals, ouseja, a visão de requisitos não-funcionais e suas associações estarão presentes dentrodeste compartimento. O NFRSoftgoal (2) com o label Confidencialidade está conectadoaos NFRSoftgoals Confidencialidade Interna e Confidencialidade Externa por meio dolink AndContribution (3). O NFRSoftgoal Confidencialidade Interna está recebendo umMakeContribution (4) da Variant Realizar Verificação Extra de Segurança. Por último,(5) exibe as propriedades do Softgoal, Id, Name e a prioridade, que deverão ser definidaspelo analista.

3.1.2.3 Contexto

Uma expressão de contexto é composta por uma fórmula de predicados. Os predicadossão: Statement, Fact e PredicateDecomposition. A representação gráfica de um Statement

pode ser ligado a uma ContextExpression para indicar que a mesma é a raiz da análise.

82

Figura 3.13 Sintaxe concreta de RNF.

Essa ligação é realizada através de um link chamado CELink que significa ContextEx-

pressionLink. Os atributos de um Statement são um Id e um texto para descrever oelemento.

Um Statement pode receber links de Facts ou de outros PredicateDecomposition. Otipo de link que realiza ligações entre PredicateDecomposition é o PredicateLink. OsFacts estão associados às Variables, que contém informações que podem ser monitoradas

83durante a configuração do processo de negócio. Quando necessário decompor a expressãode contexto, pode-se utilizar os operadores AndDecomposition, OrDecomposition eNotDecomposition.

Uma das maneiras de realizar check-in para embarcar em um avião é fazê-lo online.A Figura 3.14 apresenta informações de contexto para avaliar se o check-in online estádisponível. O contexto C_0 está implicito pelo Statement S0: check-in online está

disponível. O Statement é apoiado por uma decomposição que termina fatos. Os fatosInternetEstáOn e Sistema de Checkin Está Funcionando podem ser avaliados comoverdadeiro ou falso e o Statement apoiado por estes fatos podem ser validados.

A Figura 3.14 descreve o modelo de contexto apresentando a sintaxe gráfica concreta(a) e a sintaxe abstrata (b). Os números marcados indicam a ContextExpression (1), oStatement (2) representado pela forma S0: check-in online está disponível, um Predicate-

Decomposition (3) com o operador AND, os Facts (4) com as descrições InternetEstáOn

e Sistema de check-in está funcionando e por último, as Variables (5) InternetEstáOn eSistema de check-in está funcionando.

3.2 A Ferramenta

Nesta seção apresentamos uma visão geral da ferramenta, visto que os detalhes encontram-se disponíveis no apêndice A.

A Figura 3.15 apresenta o editor da ferramenta BVCCoN-Tool. É composta por umaárea de trabalho onde serão criados os modelos de requisitos não-funcionais, variabi-lidade e informação contextual e à direita um menu, onde encontram-se os elementosnecessários para a realização da modelagem: Variability Nodes, Variability Links, Models,ContextNodes, Context Links, NFR Node e NFR Links. A Figura 3.16 exibe o menu deseleção com mais detalhe.

Os modelos que serão exibidos em seguida são de exemplos citados anteriormente,portanto, dispensa apresentações, com exceção do modelo de contexto.

A Figura 3.17 exibe um compartimento NFR Model com 5 NFRSoftgoals inseridos.Eles estão relacionados através do link de contribuição AndContribution. A Figura 3.18apresenta o mesmo modelo da Figura 3.17, com a diferença que existe a inclusão domodelo de variabilidade.

Neste outro modelo, um ponto de variação e duas variantes são inseridas. Os links decontribuição MakeContribution e HelpContribution são utilizados para realizar as ligaçõesentre Variants e NFRSoftgoal. O padrão de WorkflowPattern que está associado com as

84

Figura 3.14 Sintaxe concreta de Contexto.

variantes é o comportamento SEQUENCE. Por último, as variantes estão associadas como ponto de variação.

O modelo da Figura 3.19 apresenta um exemplo de informação de contexto paraavaliar se o alerta de segurança está alto. O Contexto C_0 está implícito pelo Statement

85

Figura 3.15 Editor da Ferramenta BVCCoN-Tool

Figura 3.16 Menu de seleção da ferramenta

S0: Alerta de Segurança Está Alta. Este Statement é apoiado pelo fato F0: Alerta de

Segurança, que pode ser avaliado como verdadeiro ou falso. Caso esta informação decontexto seja verdadeira, a variante Realizar Verificação Extra de Segurança é ativada e

86

os elementos de fluxo BPMN pertencentes a esta variante são inseridos no modelo deprocesso de negócio principal de forma sequencial, já que o WorkflowPattern associadoé o SEQUENCE. Por fim, a Figura 3.20 apresenta um modelo BVCCoN com todasas informações representadas, requisitos não-funcionais, variabilidade e informaçõescontextuais.

Figura 3.17 Modelo RNF

Figura 3.18 Modelo RNF e Variabilidade

87

Figura 3.19 Modelo de Contexto

Figura 3.20 Modelo BVCCoN

3.3 Restrições EVL

Além das restrições impostas pelo metamodelo, também criamos algumas restrições EVLao nível de algumas ligações entre elementos. A Listagem 3.4 apresenta as restriçõesEVL que foram utilizadas.

• Linha 2, 10, 17 e 35: essas restrições foram utilizadas com o objetivo de evitarligações de um elemento (Softgoal, Predicados e Variantes) para ele próprio. Paraisto, a expressão EVL if(self.source = self.target) return false; foi utilizada, ou seja,

88

o ponto inicial e o final de uma ligação não podem ocorrer no mesmo elemento;

• Linha 26: esta restrição foi realizada com o intuito de evitar que mais de um linksaia do elemento PredicateDecomposition, deixando a semântica da linguagemcorreta. A Expressão EVL foi a seguinte: if(PredicateLink.allInstances()->select(p

| p.source = self)->size()>1) return false;. É analisado cada instância do elementoe verificado a quantidade de links que partem dele.

Listagem 3.4 Restrições EVL

1 c o n t e x t A n d C o n t r i b u t i o n {2 c o n s t r a i n t notTheSameTargetAndSource {3 check {4 i f ( s e l f . s o u r c e = s e l f . t a r g e t ) r e t u r n f a l s e ;5 e l s e r e t u r n t r u e ;6 }7 message : ’ Th i s k ind o f l i n k i s n o t a l l o w e d . ’8 }}9 c o n t e x t O r C o n t r i b u t i o n {

10 c o n s t r a i n t notTheSameTargetAndSource {11 check {12 i f ( s e l f . s o u r c e = s e l f . t a r g e t ) r e t u r n f a l s e ;13 e l s e r e t u r n t r u e ;14 }15 message : ’ Th i s k ind o f l i n k i s n o t a l l o w e d . ’16 }}17 c o n t e x t P r e d i c a t e L i n k {18 c o n s t r a i n t notTheSameTargetAndSource {19 check {20 i f ( s e l f . s o u r c e . i sKindOf ( P r e d i c a t e D e c o m p o s i t i o n

) and s e l f . t a r g e t . i sKindOf (P r e d i c a t e D e c o m p o s i t i o n ) ) r e t u r n t r u e ;

21 i f ( s e l f . s o u r c e . t y p e = s e l f . t a r g e t . t y p e ) r e t u r nf a l s e ;

22 e l s e r e t u r n t r u e ;23 }24 message : ’ Th i s k ind o f l i n k i s n o t a l l o w e d . ’25 }}26 c o n t e x t P r e d i c a t e D e c o m p o s i t i o n {27 c o n s t r a i n t onlyOneLeavingTheShape {28 check {29 i f ( P r e d i c a t e L i n k . a l l I n s t a n c e s ( )−> s e l e c t ( p | p .

s o u r c e = s e l f )−> s i z e ( ) >1) r e t u r n f a l s e ;

8930 e l s e r e t u r n t r u e ;31 }32 message : ’ Only one P r e d i c a t e L i n k can l e a v e t h i s shape

’33 }34 }35 c o n t e x t V a r i a n t s R e l a t i o n s h i p {36 c o n s t r a i n t NotTheSameSourceAndTarget {37 check {38 i f ( s e l f . r e l a t i o n s h i p S o u r c e = s e l f .

r e l a t i o n s h i p T a r g e t ) r e t u r n f a l s e ;39 e l s e r e t u r n t r u e ;40 }41 message : ’ Th i s k ind o f r e l a t i o n s h i p i s n o t a l lowed ’42 }43 }

3.4 Considerações do Capítulo

Nesta seção, foi apresentado o metamodelo da ferramenta BVCCon-Tool, assim comoa sintaxe concreta e abstrata da linguagem de modelagem. Apresentamos as visões derequisitos não-funcionais, variabilidae e informação contextual da abordagem BVCCoNatravés de metamodelos UML e também na linguagem Emfatic. Por fim, apresentamosa ferramenta e algumas restrições EVL que foram utilizadas a nível de ligações entreelementos.

91

4Avaliação

Nesta seção, descrevemos o teste de usabilidade que foi realizado com o intuito de avaliara ferramenta proposta nesta dissertação e também um exemplo de uso, com o objetivo deverificar a expressividade da ferramenta, se a sintaxe abstrata definida no metamodelo semantinha nos modelos criados com a ferramenta.

4.1 Cenário: Check-In Aeroporto

O cenário utilizado para realizar o exemplo de uso e a avaliação de usabilidade, foi oprocesso de Check-In em aeroportos, o mesmo que foi usado em [48] para avaliar aabordagem BVCCoN proposta. Check-In, geralmente é o primeiro procedimento que érealizado por um passageiro quando ele chega em um aeroporto. As companhias aéreasrequerem que o passageiro realize o check-in um certo tempo antes do horário do vôo,que pode durar entre 30 minutos a 4 horas, dependendo do destino e da companhia aérea.

Muitas atividades relacionadas ao processo de check-in são úteis e relevantes para adefinição de um modelo de processo de negócio. Por exemplo: políticas de check-in eprocedimentos de segurança, movimentação de passageiros e validação da documentação.As opções de check-in e procedimentos podem variar de acordo com a companhia aérea,algumas possuem certas restrições que outras não.

Ocasionalmente a mesma companhia em diferentes aeroportos podem ter diferentesprocedimentos de check-in. Este tipo de processo é realizado em um ambiente altamentedinâmico, que pode ser afetado por diversos fatores como a quantidade de passageiros,políticas de segurança, clima, dentre outros. No cenário descrito acima, poderia ser útilconfigurar o processo de acordo com as mudanças de contexto, levando em consideraçãoas preferências de qualidade associadas com o processo de check-in.

92

4.2 Exemplo de Uso

4.2.1 Processo de Referência

A Figura 4.1 apresenta o processo de referência que servirá de apoio para as etapasseguintes. O processo de check-in começa quando um passageiro chega em um aeroportoe dirige-se ao gabinete da companhia. A equipe da companhia aérea começa identificandoo passageiro e o voo. Depois disso, o check-in é realizado e um cartão de embarque éimpresso.

Se existir bagagem para ser enviada ao compartimento de carga da aeronave, é feito oenvio nesta etapa. Em seguida, o passageiro pode ir ao posto de segurança, onde a equipeverificará seus dados. Finalmente, o passageiro é conduzido para o portão de embarque.

Figura 4.1 Processo de Referência

Para as próximas seções assumimos que o leitor conhece a abordagem BVCCoN [48]e focaremos apenas nos aspectos de modelagem, que é o objetivo deste estudo.

4.2.2 Elicitação da Variabilidade

Esta etapa começa a partir da análise do processo de referência, com o objetivo deidentificar através de uma série de perguntas as variantes do processo. Logo, é possívelencontrar algumas variações na maneira como o processo é executado. A partir dos dadosencontrados nesta etapa, eles serão analisados e então representados como pontos devariações e variantes.

4.2.3 Descrição da Variabilidade

Um ponto de variação indica em qual parte do processo de negócio as mudanças podemacontecer. Os termos begins e ends são usados para indicar onde o ponto de variaçãocomeça e onde termina. A Figura 4.2 mostra a representação gráfica produzida por nossaferramenta dos pontos de variações no processo de referência. Por exemplo, o ponto devariação VP1 começa na tarefa Verificar Informação de Voo e termina na tarefa Emitir

93Cartão de Embarque, o VP2 começa e termina na tarefa Realizar Embarque e o VP3começa e termina ta tarefa Realizar Verificação de Segurança.

Então, todos os elementos localizados entre essas tarefas incluindo elas mesmas,podem ser substituídas por variantes. Nossa ferramenta não permite que o processo denegócio representado na Figura 4.2 seja modelado. Ele é importado na ferramenta eatravés de um apontamento conseguimos setar os atributos begins e ends. No Apêndice Aé explicado o passo a passo dessa importação e de como acessar as tarefas do modeloBPMN.

94

Figura 4.2 Pontos de Variação no Processo de Referência

95Cada ponto de variação possui variantes associadas. O ponto de variação VP1 que

corresponde as tarefas de Check-In possui três variantes, Realizar Check-In, Realizar

Check-In Manualmente e Realizar Check-In Online. O ponto de variação VP2 corres-ponde a tarefa Realizar Embarque e também possui três variantes associadas, Embarcar

usando escada, Embarcar usando ponte e Atrasar embarque. Por último, o ponto devariação VP3 que corresponde a tarefa Realizar verificação de segurança possui duas vari-antes associadas, Executar verificação de segurança e Executar verificação de segurança

extra.A Figura 4.3 exibe as associações entre variantes e os fragmentos de processos de

negócio que serão incluídos no processo principal caso a variante seja ativada. Comopode ser visto, variantes podem apontar para apenas uma tarefa, como em var4, ou paraum conjunto de elementos de processos, como em var1. Em alguns casos, uma variantepode requerer ou excluir a presença de outra variante. De acordo com a Figura 4.3 avariante var8 Realizar Verificação de Segurança Extra requer a presença da variante var7Realizar Verificação de Segurança, pois existe uma ligação entre as duas com o linkRequires.

96

Figura 4.3 Pontos de Variação e Variantes com partes de Processos de Negócio

97

4.2.4 Análise de Contexto

Após realizar a descrição de variabilidade, a próxima etapa é descrever as informaçõescontextuais e associá-las às variantes do processo. A Figura 4.4 exibe três árvores decontexto e suas associações com as variantes. O contexto C0 está ligado com as variantesvar1 (Realizar Check-In) e var3 (Realizar Check-In Online), o contexto C1 com a variantevar3 e, por último, o contexto C2 com a variante var6 (Embarcar usando ponte). Osseguintes contextos foram mapeados:

• Check-In Online está Disponível: Em alguns casos o check-in pode estar indispo-nível. A companhia pode optar por fazer o check-in de maneira manual. Mesmose os serviços de internet e os quiosques não estiverem funcionando, o passageiroainda será capaz de realizar o check-in no balcão da companhia. Para que estecontexto seja ativado, é necessário que os fatos InternetEstáOn e SistemaDeChec-

kinFuncionando sejam avaliados como verdadeiros.

• Internet e Quiosque estão funcionando: Algumas companhias permitem a reali-zação do check-in através da internet ou oferencendo quiosques para os passageiros.Este contexto é ativado quando os fatos InternetEstáOn e QuiosqueDoAeroporto-

EstáOn forem verdadeiros.

• Ponte está Disponível: Alguns aeroportos possuem pontes que permite os passa-geiros embarquem no portão sem a necessidade de ir diretamente até a aeronave.Essas pontes permitem um embarque mais rápido, porém, não estão disponíveis emtodos os aeroportos. Este contexto é ativado quando o fato PonteEstáDisponível éverdadeiro.

Quando um contexto é verdadeiro, a ou as variantes que estão relacionadas com ocontexto são ativadas e os elementos de fluxo BPMN pertencentes as variantes podem serinseridos no processo de negócio principal. A maneira como os elementos são inseridosdependem do padrão de Workflow que foi determinado anteriormente.

4.2.5 Análise de Requisitos Não-Funcionais

A última etapa da fase de modelagem é a associação das variantes com os atributos dequalidade. Eles são utilizados para expressar como as variantes podem afetar a confi-guração do processo. A Figura 4.5 mostra a análise de contribuição para Performance,Confiabilidade e Segurança.

98

Figura 4.4 Análise de Contexto

O RNF Performance é decomposto em outros dois, Espaço de Performance e Tempo

de Performance, que por sua vez é decomposto em mais dois RNFs, Throughput e Tempo

de Resposta. Confiança é o RNF que é decomposto em Disponibilidade, Precisão eTolerância à falhas, por último, o RNF Segurança é decomposto em Controle de Acesso eConfidencialidade. Este é decomposto em Confidencialidade Interna e Confidencialidade

Externa.

99

Figura 4.5 Requisitos Não-Funcionais e Análise de Contribuição

100

Tabela 4.1 Contribuição dos RNFsNFR var1 var2 var3 var4 var5 var6 var7 var8Throughput + – ++ + ++ - –Tempo de Resposta ++ – ++ – - –Disponibilidade + + ++ + -Precisão + + ++Controle de Acesso + ++Confidencialidade Interna + ++Confidencialidade Externa + ++

A variante Executar verificação de segurança contribui positivamente para Controle

de Acesso, reduzindo o acesso de pessoas que não deveriam entrar na área de embarque.Contudo, esta mesma variante contribui negativamente para Performance, já que reduz avelocidade do processo. A Tabela 4.1 apresenta as contribuições da Figura 4.5, permitindouma melhor visualização. Os espaços em branco são compreendidos como EqualCon-

tribution (=). Uma possível melhoria na ferramenta BVCCoN-Tool seria permitir ousuário realizar as ligações de contribuições diretamente em uma tabela (ver Tabela 4.1),e assim, na medida que as informações forem inseridas, as ligações seriam realizadasautomaticamente na forma gráfica (ver Figura 4.5). Desta maneira, a usabilidade daferramenta seria melhorada, assim como a visualização das informações.

4.3 Teste de Usabilidade

4.3.1 The Post-Study System Usability Questionnaire

O estudo proposto por [31] apresenta quatro métodos para avaliar a usabilidade desistemas. O método The After-Scenario Questionnaire - (ASQ) é baseado em cenários, ouseja, os usários devem executar um cenário e em seguida responder a três questões, assimpor diante, até a quantidade de cenários acabar.

O The Printer-Scenario Questionnaire - (PSQ) é uma versão antiga do ASQ. Tambémé baseada em cenários e possui um questionário com apenas três questões. O terceirométodo é o The Computer System Usability Questionnaire - (CSUQ) e é indicado paraquando o estudo de usabilidade é em um ambiente que não seja em laboratório.

O último método é o PSSUQ (The Post-Study System Usability Questionnaire). Estemétodo permite calcular quatro diferentes fatores a partir das respostas obtidas do questi-onário de avaliação. Os 4 fatores são: satisfação geral, utilidade do sistema, qualidade da

101informação e qualidade da interface. Optamos escolher este método (Apêndice C) por sero que está de acordo com nosso contexto, ele é baseado em um conjunto de tarefas com ousuário respondendo o questionário após a execução de todas as tarefas. É indicado paratestes de usabilidade em ambientes laboratoriais e possui quatro fatores que podem seravaliados, permitindo uma avaliação de usabilidade mais ampla.

O questionário do método PSSUQ é composto por dezenove índices, organizada emsete itens de resposta que estão em uma escala gráfica de 7 pontos, que varia de "Discordototalmente"com valor 7 e "Concordo totalmente"com valor 1.

A partir deste método, adotamos apenas o questionário, já que permite uma avaliaçãode usabilidade mais ampla abrangendo quatro diferentes fatores, contudo, fizemos umaadaptação em virtude de sabermos que quanto maior a escala, mais difícil dos participan-tes a interpretarem [50]. Por esta questão e também pela quantidade dos participantes naavaliação da usabilidade, optamos reduzir para uma escala Likert de cinco níveis: con-cordo fortemente, concordo, neutro, discordo e discordo totalmente. Também poderíamoselaborar nosso próprio questionário, incluindo nossas próprias perguntas, porém, váriosdesafios seriam encontrados, por exemplo:

• Utilizar linguagem apropriada para a população;

• Cada pergunta deve cobrir exatamente um conceito;

• Evitar respostas vagas e ambíguas;

• Balancear as perguntas positivas e negativas.

Além disso, o questionário deve ser validado antes de sua utilização. Segundo [8], omelhor é utilizar instrumentos de outras pessoas, visto que já foram validados e, alémdisso, torna mais fácil a análise dos resultados da pesquisa. Por esta razão, decidimosescolher um questionário que já foi validado e amplamente utilizado.

4.3.2 Usuários

Os usuários que participaram do teste de usabilidade são alunos de pós-graduação emCiência da Computação da instituição Universidade Federal de Pernambuco. Eles estavamcursando a disciplina de Engenharia de Requisitos e, portanto, possuiam algum contatocom ferramentas de modelagem. Ao todo, 15 foram os usuários que participaram doteste.

102

4.3.3 Equipamentos e Ambiente

Os equipamentos utilizados na realização do teste de usabilidade estão descritos na Tabela4.3.3.

Tabela 4.2 Equipamentos utilizados para realização do teste

Equipamento CaracterísticasComputador Pessoal Os componentes de hardware do teste foram computadores

pessoais (monitor, gabinete, teclado e mouse).Softwares Básicos Windows 7, 64 bits, 8GB Ram, Processador AMD Phenom

(tm) II X4 B97 3.20 GHz, eclipse KleperBuild id:20130614-0229

Um ambiente real foi utilizado para a realização do teste: o laboratório de computado-res do Centro de Informática da Universidade Federal de Pernambuco. Os computadoresforam previamente configurados com a versão do eclipse Kepler, a qual foi utilizada paradesenvolver a ferramenta. Assim, possíveis erros de compatibilidade foram evitados,deixando o usuário focado apenas nas tarefas do teste de usabilidade.

4.3.4 Tarefas

Para esta avaliação, os usuários tiveram que realizar uma sequência de tarefas cujoobjetivo era a construção de parte do cenário de check-in de um aeroporto, visto que ocenário completo exige mais tempo para a execução do teste. Este cenário foi escolhidovisando explorar a utilização do máximo de recursos que a ferramenta oferece.

As tarefas envolvem a modelagem de ponto de variação, variantes, relacionamentoentre o ponto de variação e variante, a definição do WorkflowPattern, que representaa maneira como as variantes serão alocadas em um novo processo, a importação demodelos BPMN, a modelagem de requisitos não-funcionais e informações contextuais eos relacionamentos entre os requisitos e informações de contexto com uma variante. Astarefas de usuário que foram utilizadas para o teste podem ser consultadas no ApêndiceB.

4.3.5 Processo de Coleta dos Dados

Devido a complexidade da abordagem BVCCoN, no dia 26/11/2013 foi apresentado umseminário com o objetivo de deixar os usuários cientes do teste. A abordagem foi breve-

103mente apresentada, assim como uma introdução da ferramenta e suas funcionalidades.

A coleta de dados foi realizada no dia 29/11/2013 das 10:00h às 12:00h. Inicialmente,cada usuário foi direcionado para um computador onde o eclipse Kleper já estava abertoe pronto para a inicialização do teste. Também foi entregue para cada usuário a lista detarefas a serem realizadas (Apêndice B) e um manual da ferramenta (Apêndice A).

Em seguida, foram apresentadas aos usuários as seguintes regras para a realização doteste usabilidade:

1. Seguir a lista de tarefas, executando-as em sequência;

2. Em caso de dúvida na realização de alguma tarefa, consultar o manual da ferra-menta;

3. Se a dúvida persistir, tentar executar a tarefa da maneira que achar que está correto;

4. Se a tentativa anterior fracassar, pedir auxílio ao monitor;

5. Após finalizar o teste, acessar o formulário online disponível em: http:goo.glQ5eoB0e respondê-lo de acordo com as tarefas que foram executadas (o formulárioencontra-se no Apêndice C);

6. Após a conclusão destas etapas, o teste foi finalizado.

O teste é iniciado após o instrutor autorizar a inicialização.

4.3.6 Resultados

Para analisar os dados coletados no questionário, utilizamos o método proposto por [34].Visto que nosso objetivo não é escolher o melhor método para avaliar os dados coletados,não fizemos comparações entre métodos.

O método descrito em [34] visa analisar resultados obtidos em questionários na formade escala de Likert. A Tabela 4.3 apresenta os dados coletados do questionário. Asrespostas foram dadas por 15 participantes (A-O) a um questionário de 19 itens. Aparte direita da tabela é exibido a soma da quantidade de respostas de cada participanteagrupadas pelos pontos da escala Likert [33], ou seja, demonstra quantas vezes cadaparticipante escolheu 5, 4, 3, 2, e 1 como resposta.

Para identificar o número que corresponderá a "sem opinião", calculamos a médiacomo se todas as respostas para todos os índices fossem 3. Ou seja, Media = (19 ∗ 3)

104

onde 19 é o total de itens e 3 é o número que corresponde a neutro, "sem opinião". Nestecaso, o resultado é 57.

Analisando a Tabela 4.3, o participante K atingiu o total de 58 pontos, muito pró-ximo do número 57, que corresponde a "sem opinião". Ainda analisando a Tabela 4.3,identificamos que o participante L não mostrou coerência em suas respostas, marcando"concordo totalmente"para os 19 itens do questionário, tornando um viés para a pes-quisa. Por isso, ele foi excluído das próximas análises. O restante dos participantes queresponderam o questionário mostraram coerência em suas respostas.

De acordo com método utilizado para analisar os dados [34], é importante observarque a identificação de participantes que não mostram coerência em suas respostas érealizada de forma manual, fazendo comparações com as respostas de outros participantes.Por isso, pode ocorrer certo viés durante a análise manual, tornando um ponto negativodo método usado.

105

Tabela 4.3 Respostas dos Participantes1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Total 5 4 3 2 1

A 5 4 5 4 4 4 5 4 3 3 5 4 5 5 4 5 5 5 4 83 9 8 2 0 0B 4 4 5 5 5 4 4 4 3 3 3 4 4 4 4 4 5 4 5 78 5 11 3 0 0C 4 3 4 5 5 3 4 3 3 3 5 5 3 5 5 4 3 4 4 75 6 6 7 0 0D 4 4 4 3 3 4 4 2 3 3 3 4 4 4 4 4 2 3 3 65 0 10 7 2 0E 5 5 5 5 5 4 4 5 5 5 3 3 4 4 4 4 4 4 5 83 9 8 2 0 0F 4 4 4 3 4 4 4 2 3 3 4 3 3 3 3 4 4 4 4 67 0 11 7 1 0G 4 4 4 4 4 3 4 4 3 3 4 4 4 4 4 4 4 4 4 73 0 16 3 0 0H 4 4 4 4 3 4 4 4 3 4 4 4 4 3 4 4 4 4 4 73 0 16 3 0 0I 4 4 5 5 3 4 4 4 4 3 3 4 4 4 4 4 4 4 4 75 2 14 3 0 0J 5 5 5 4 5 4 4 3 1 2 4 3 5 4 5 4 4 3 4 74 6 8 3 1 1K 2 3 4 2 3 1 3 2 3 4 4 4 3 3 4 4 3 3 3 58 0 6 9 3 1L 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 95 19 0 0 0 0M 4 4 2 4 4 3 3 2 4 4 4 4 4 4 4 4 3 4 4 69 0 14 3 2 0N 3 3 4 3 4 3 4 4 2 3 4 3 4 4 4 3 3 3 3 64 0 8 10 1 0O 4 4 3 4 3 4 4 4 3 4 4 4 4 3 4 3 4 4 4 71 0 14 5 0 0

106

4.3.6.1 Satisfação Geral

A Tabela 4.4 apresenta os dados com o participante L já excluído, assim, podemoscontinuar com a análise. Utilizando a Tabela 4.4, calculamos a média de todas as respostasobtidas. Somamos os dados da coluna "Total"e dividimos pelo total de participantes.Assim sendo: Media = (1008/14), cujo resultado é 72. Portanto, a média de todos osparticipantes é superior a média 57 ("sem opinião"), implicando que de uma maneirageral nossa ferramenta foi bem aceita pelos participantes. Desta forma, o primeiro fatorque queremos calcular (satisfação geral) foi respondido.

O próximo passo é criar os grupos dos participantes que são "favoráveis"e os que são"desfavoráveis"ao tema em questão. Para isto, fizemos uma comparação da média querepresenta "sem opinião", neste caso 57 com o total obtido por cada participante (Coluna"Total"). Os participantes com um total inferior a 57 entrariam no grupo dos que são"desfavoráveis"e aqueles com um total superior a 57 no grupo dos "favoráveis".

Não foi possível criar os dois grupos, visto que todos os participantes são "favorá-veis", ou seja, estão no grupo dos que concordam que nossa ferramenta possui uma boausabilidade. Também somamos as respostas das colunas, visando identificar os índicescujas respostas de uma maneira geral foram positivas, negativas, ou os participantesnão possuem opinião sobre a mesma. Para realizar esta tarefa, calculamos a média derespostas de cada índice individualmente e comparamos com a média se todas as respostaspara um índice fossem 3 ("sem opinião"). Assim, Media = 3∗14 onde 3 é o número quecorresponde a neutro, "sem opinião"e 14 é o número de participantes. Obtemos comoresposta o número 42.

De acordo com a Tabela 4.4, a média de todas os itens foram superiores ao número42. Porém, a média do item número 9 (média 43) se aproxima muito do número 42,que corresponde a "sem opinião". Portanto, de uma maneira geral, os participantes nãopossuem opinião sobre o item The system gave error messages that clearly told me how

to fix problems..

107

Tabela 4.4 Satisfação Geral1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Total 5 4 3 2 1

A 5 4 5 4 4 4 5 4 3 3 5 4 5 5 4 5 5 5 4 83 9 8 2 0 0B 4 4 5 5 5 4 4 4 3 3 3 4 4 4 4 4 5 4 5 78 5 11 3 0 0C 4 3 4 5 5 3 4 3 3 3 5 5 3 5 5 4 3 4 4 75 6 6 7 0 0D 4 4 4 3 3 4 4 2 3 3 3 4 4 4 4 4 2 3 3 65 0 10 7 2 0E 5 5 5 5 5 4 4 5 5 5 3 3 4 4 4 4 4 4 5 83 9 8 2 0 0F 4 4 4 3 4 4 4 2 3 3 4 3 3 3 3 4 4 4 4 67 0 11 7 1 0G 4 4 4 4 4 3 4 4 3 3 4 4 4 4 4 4 4 4 4 73 0 16 3 0 0H 4 4 4 4 3 4 4 4 3 4 4 4 4 3 4 4 4 4 4 73 0 16 3 0 0I 4 4 5 5 3 4 4 4 4 3 3 4 4 4 4 4 4 4 4 75 2 14 3 0 0J 5 5 5 4 5 4 4 3 1 2 4 3 5 4 5 4 4 3 4 74 6 8 3 1 1

K 2 3 4 2 3 1 3 2 3 4 4 4 3 3 4 4 3 3 3 58 0 6 9 3 1M 4 4 2 4 4 3 3 2 4 4 4 4 4 4 4 4 3 4 4 69 0 14 3 2 0N 3 3 4 3 4 3 4 4 2 3 4 3 4 4 4 3 3 3 3 64 0 8 10 1 0O 4 4 3 4 3 4 4 4 3 4 4 4 4 3 4 3 4 4 4 71 0 14 5 0 0

5 3 2 5 4 4 0 1 1 1 1 2 1 2 2 2 1 2 1 24 9 9 7 6 5 9 11 7 2 4 8 9 9 8 11 11 7 9 9 Média3 1 3 1 3 5 4 2 2 9 8 4 4 3 4 1 2 4 4 3 722 1 0 1 1 0 0 0 4 1 1 0 0 0 0 0 0 1 0 01 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0

Total 56 55 58 55 55 49 55 47 43 47 54 53 55 54 57 55 52 53 55

108

Tabela 4.5 Utilidade do Sistema1 2 3 4 5 6 7 8 Total 5 4 3 2 1

A 5 4 5 4 4 4 5 4 35 3 5 0 0 0B 4 4 5 5 5 4 4 4 35 3 5 0 0 0C 4 3 4 5 5 3 4 3 31 2 3 3 0 0D 4 4 4 3 3 4 4 2 28 0 5 2 1 0E 5 5 5 5 5 4 4 5 38 6 2 0 0 0F 4 4 4 3 4 4 4 2 29 0 6 1 1 0G 4 4 4 4 4 3 4 4 31 0 7 1 0 0H 4 4 4 4 3 4 4 4 31 0 7 1 0 0I 4 4 5 5 3 4 4 4 33 2 5 1 0 0J 5 5 5 4 5 4 4 3 35 4 3 1 0 0K 2 3 4 2 3 1 3 2 20 0 1 3 3 1M 4 4 2 4 4 3 3 2 26 0 4 2 2 0N 3 3 4 3 4 3 4 4 28 0 4 4 0 0O 4 4 3 4 3 4 4 4 30 0 6 2 0 0

4.3.6.2 Utilidade do Sistema

Nesta seção, analisamos os itens que correspondem a utilidade do sistema. Neste caso, ositens são aqueles que estão entre 1 e 8. Realizamos todos os procedimentos que foramdescritos na seção 4.3.6.1 e encontramos os resultados obtidos na Tabela 4.5.

• Média para todas as respostas com pontuação 3 ("sem opinião"): 24;

Comparando o número 30,71 que corresponde a média de todos os itens de todos osparticipantes com o número 24 que é a média se todas as respostas fossem 3 ("sem opi-nião"), concluímos que nossa ferramenta foi considerada útil pelos usuários na realizaçãodas tarefas que a mesma se propõe a fazer.

Para este caso específico (utilidade do sistema), apenas um participante (o K) fazparte do grupo dos que são "desfavoráveis". Ou seja, sua média de respostas foi inferiora média "sem opinião". Assim, os 13 participantes restantes fazem parte do grupo dos"favoráveis".

4.3.6.3 Qualidade da Informação

Nesta seção, analisamos os itens correspondentes a qualidade da informação fornecidapela ferramenta assim como a documentação. Os itens analisados são aqueles entre 9 e15. Os procedimentos realizados na seção 4.3.6.1 foram repetidos para este caso e osresultados são encontrados na Tabela 4.6.

• Média para todas as respostas com pontuação 3 ("sem opinião"): 21;

109

Tabela 4.6 Qualidade da Informação9 10 11 12 13 14 15 Total 5 4 3 2 1

A 3 3 5 4 5 5 4 29 3 2 2 0 0B 3 3 3 4 4 4 4 25 0 4 3 0 0C 3 3 5 5 3 5 5 29 4 0 3 0 0D 3 3 3 4 4 4 4 25 0 4 3 0 0E 5 5 3 3 4 4 4 28 2 3 2 0 0F 3 3 4 3 3 3 3 22 0 1 6 0 0G 3 3 4 4 4 4 4 26 0 5 2 0 0H 3 4 4 4 4 3 4 26 0 5 2 0 0I 4 3 3 4 4 4 4 26 0 5 2 0 0J 1 2 4 3 5 4 5 24 2 2 1 1 1K 3 4 4 4 3 3 4 25 0 4 3 0 0M 4 4 4 4 4 4 4 28 0 7 0 0 0N 2 3 4 3 4 4 4 24 0 4 2 1 0O 3 4 4 4 4 3 4 26 0 5 2 0 0

Comparando o número 25,93 que corresponde a média de todos os itens de todosos participantes com o número 21 que é a média se todas as respostas fossem 3 ("semopinião"), concluímos que nossa ferramenta foi considerada pelos usuários como ofertantede boa qualidade de informação visual, bem como em documentação na realização dastarefas.

Para este caso específico (qualidade da informação), apenas a média do participanteF (média 22) ficou muito próximo da média "sem opinião"(média 21). Ou seja, apenasuma pessoa não possuiu uma opinião bem definida sobre a qualidade da informação daferramenta.

4.3.6.4 Qualidade da Interface

Para analisar a qualidade da interface, os itens relacionados são os 16, 17 e 18. Mais umavez repetimos os procedimentos da seção 4.3.6.1 para encontrarmos os dados relacionadosa qualidade da informação. A Tabela 4.7 apresenta os resultados que foram alcançados.

• Média para todas as respostas com pontuação 3 ("sem opinião- linhas): 9;

Comparando o número 11,43 que corresponde a média de todos os itens de todosos participantes com o número 9 que é a média se todas as respostas fossem 3 ("semopinião"), podemos concluir que nossa ferramenta possui uma boa qualidade da interfacee que é agradável sua utilização.

Quando comparamos a média individual de cada participante com a média "semopinião", identificamos que os participantes D e N possuem a mesma média (média 9).

110

Tabela 4.7 Qualidade da Interface16 17 18 Total 5 4 3 2 1

A 5 5 5 15 3 0 0 0 0B 4 5 4 13 1 2 0 0 0C 4 3 4 11 0 2 1 0 0D 4 2 3 9 0 1 1 1 0E 4 4 4 12 0 3 0 0 0F 4 4 4 12 0 3 0 0 0G 4 4 4 12 0 3 0 0 0H 4 4 4 12 0 3 0 0 0I 4 4 4 12 0 3 0 0 0J 4 4 3 11 0 2 1 0 0K 4 3 3 10 0 1 2 0 0M 4 3 4 11 0 2 1 0 0N 3 3 3 9 0 0 3 0 0O 3 4 4 11 0 2 1 0 0

Também identificamos que a média do participante K (média 10) se aproxima muito damédia "sem opinião".

A partir destas informações, podemos concluir que 11 participantes (79%) concordamque a ferramenta possui uma boa qualidade de interface e que 3 participantes (21%) nãopossuem uma opinião bem definida sobre esta questão.

4.4 Ameaças à Validade

Algumas ameaças à validade foram identificadas durante a execução de nossa avaliação. Amaioria está relacionada com os seres humanos, como por exemplo: rivalidade, motivação,interação entre os participantes, conhecimento da abordagem BVCCoN, dentre outros.Acreditamos que o último item seja a principal ameaça à validade na validação de nossaferramenta.

Os participantes não conheciam a abordagem e um pequeno treinamento de 1 horafoi realizado três dias antes do teste. Para que os participantes adquirissem certo conheci-mento sobre a abordagem, seria necessário dominar 4 áreas do conhecimento. A primeiraé a de requisitos não-funcionais, mais especificamente o NFRFramework, que envolve adecomposição de Softgoals e as contribuições entre Softgoals.

A segunda é sobre SPL (Software Product Lines) [41], entender os conceitos depontos de variação e variantes. A terceira é domínio sobre a modelagem de processos denegócio, especialmente a notação BPMN. Por último, seria necessário entender comoconstruir as árvores de contexto.

111Por este possível desconhecimento nestas áreas, as tarefas de usuário (Apêndice B)

foram descritas em um nível de detalhe muito alto. Desta maneira, os participantes segui-ram um tutorial bastante detalhado para atingir o resultado esperado. Assim, possíveisfalhas podem ter sido evitadas, levando os participantes a executarem corretamente astarefas de usuário e consequentemente a responder o questionário (Apêndice C) comrespostas positivas (Seção 4.3.6).

4.5 Considerações Finais

A ferramenta BVCCoN-Tool, modelada e descrita no capítulo 3 desta dissertação segundoo Framework Epsilon [12] e seu conjunto de linguagens, foi avaliada neste capítulo. Aferramenta BVCCoN-Tool tem como objetivo permitir a modelagem das três visões daabordagem proposta por [48] sobre configuração de processos de negócio dinâmicos.Essas visões são a de requisitos não-funcionais, variabilidade e descrição das informaçõesde contexto.

O objetivo foi apresentar a utilização da ferramenta visando avaliar sua expressividadee também realizar um teste de usabilidade com usuários reais. Na aplicação do exemplode uso e no teste de usabilidade, a ferramenta se comportou de forma apropriada. Noexemplo de uso, a ferramenta conseguiu representar as informações necessárias, enquantona avaliação de usabilidade, a ferramenta mostrou possuir uma boa usabilidade em todosos aspectos: satisfação geral, utilidade do sistema, qualidade da informação e qualidadeda interface.

113

5Conclusões e Trabalhos Futuros

Esta seção apresenta as conclusões finais do estudo desta dissertação, resumindo todosos passos realizados para o desenvolvimento da ferramenta. Também apresentamos aprincipais contribuições deste estudo e listamos possíveis trabalhos futuros.

5.1 Considerações Finais

No capítulo 1 foi apresentado a justificativa da pesquisa, os objetivos geral e específicos,a relevância do estudo e a estrutura do trabalho.

No capítulo 2 foi apresentado brevemente a abordagem de configuração de processosde negócio dinâmicos a qual este estudo propôs e desenvolveu uma ferramenta. Nestecapítulo, realizamos uma revisão sistemática da literatura sobre a representação derequisitos não-funcionais e informações contextuais nos modelos de processos de negócio.Ao final da análise, identificamos 13 trabalhos que representam RNF em seus modelosde processos. A abordagem BVCCoN representa RNFs externamente ao modelo denegócio através de uma matriz, já que é uma solução escalável para representar este tipode informação [48]. Quanto às informações de contexto, 14 trabalhos foram identificados,portanto, RNF e contexto estão sendo considerados na modelagem dos processos. Aotérmino da análise, a abordagem BVCCoN foi a única classificada nos dois itens.

Em relação à configuração de processos de negócio, La Rosa [28] propõe uma abor-dagem que captura variabilidade de processos, Lapouchnian et al. [29] considera modelode goals para representar RNF e variabilidade e De La Vara [5] adiciona contextualizaçãoaos modelos de processos de negócio para guiar a variabilidade, portanto, BVCCoNé uma abordagem mais completa em relação à configuração de processos de negóciodinâmicos, visto que considera variabilidade, RNF e contexto.

Ainda no capítulo 2 foi discutido metamodelagem, DSML (Linguagem para Mode-

114

lagem Específica de Domínio) e sua classificação em interna, externa e não textual etambém foram inseridas noções de sintaxe concreta e abstrata. Foram apresentados osconceitos e tecnologias utilizados para o desenvolvimento da ferramenta de modelagem.Foram discutidos o EMF e GMF (Eclipse Modeling Framework e Graphical Modeling

Framework respectivamente) e também o Framework Epsilon, que é uma família de lin-guagens e ferramentas destinadas à atividades de gerenciamento de metamodelos. Grandeparte de suas linguagens foram utilizadas no processo de desenvolvimento da ferramenta.São elas: EuGENia, Emfatic, EOL (Epsilon Object Language) e EVL (Epsilon Validation

Language).

No capítulo 3 foi apresentado o metamodelo da ferramenta desenvolvida neste estudo.Também foi discutida a sintaxe concreta e abstrata e ao mesmo tempo exemplos demodelos foram exibidos. Além disso, uma visão geral da ferramenta foi demonstrada,assim como as restrições escritas em EVL.

Em seguida, no capítulo 4 foi descrito o teste de usabilidade que foi realizado com ointuito de avaliar a ferramenta proposta nesta dissertação e também um exemplo de uso,com o objetivo de avaliar a expressividade da ferramenta.

Com a BVCCoN-Tool, é possível modelar as três visões (requisitos não-funcionais,variabilidade e informação contextual) necessárias para a configuração de processos denegócio dinâmicos da abordagem encontrada em [48]. O exemplo de uso realizado em umcenário real, mostra que sua utilização é viável e prática para ser utilizada em ambientesreais, como evidenciado pela avaliação de usabilidade.

A avaliação de usabilidade mostrou que a ferramenta permitiu a construção dastrês visões com sucesso. A análise dos dados coletados indicam que os quatro fatores(satisfação geral, utilidade do sistema, qualidade da informação e qualidade da interface)fossem alcançados com sucesso, possuindo uma aceitação geral por todos os usuários.

5.2 Contribuições

A pesquisa apresentada nesta dissertação possibilitou as seguintes contribuições:

• Uma revisão sistemática da literatura atualizada sobre requisitos não-funcionais einformações de contexto em modelos de processos de negócio;

• O desenvolvimento de um metamodelo que integra quatro diferentes perspectivas:modelos de processos de negócio, modelos de requisitos não-funcionais, modelode descrição de variabilidade e modelo de contexto;

115• Uma ferramenta de modelagem para a configuração de processos de negócio

dinâmicos;

• A aplicação de um exemplo de uso visando validar a expressividade da ferramenta;e

• A definição, planejamento, operação e interpretação de um teste de usabilidadecom objetivo de avaliar a usabilidade da ferramenta proposta.

5.3 Trabalhos Futuros

Alguns problemas ainda estão em aberto e outros surgiram a partir dos resultados al-cançados. Desta maneira, os seguintes itens devem ser levados em consideração comotrabalhos futuros:

• Realizar outros exemplos de uso com a ferramenta proposta. Para que sejapossível identificar falhas da ferramenta, a apresentação de outros exemplos de usoé de fundamental importância;

• Realizar outra avaliação de usabilidade. Realizar um treinamento profundo daabordagem BVCCoN [48] com os usuários, permitindo diminuir o nível de detalhesem que a descrição das tarefas de usuário foram escritas. Desta forma, possíveisfalhas poderiam ser identificadas;

• Melhoria contínua da ferramenta. Caso a abordagem BVCCoN evolua, podeser possível criar novas formas geométricas de novos elementos que venham surgirou excluir elementos que tornem desnecessários. Também é possível adicionarfuncionalidades que porventura tornem-se necessárias;

• Integração com o editor gráfico BPMN. A ferramenta proposta nesta dissertaçãojá possui uma integração com o BPMN2 Modeler [9] (plugin para realizar modela-gem BPMN no Eclipse). Porém, ao invés de selecionar os atributos begins e ends

através de um combobox como demonstrado na Figura A.7, seria interessante aousuário visualizar o desenho do processo de negócio e selecionar esses atributosatravés de um simples clique em cima do elemento correspondente.

• Extensão da BVCCoN-Tool. Extender a ferramenta BVCCoN-Tool para que amesma seja possível de realizar a configuração de processos de negócio automati-camente.

116

• Compilação de modelos. Para continuar o ciclo da abordagem BVCCoN, apróxima etapa é realizar uma compilação dos modelos gerados para que possamservir de entrada para alguma plataforma de execução de processos que venha serintegrada com a abordagem.

117

Referências Bibliográficas

[1] EMF: Eclipse Modeling Framework (2nd Edition), volume 1. Addison-WesleyProfessional, 2008.

[2] Raian Ali, Fabiano Dalpiaz, and Paolo Giorgini. A goal-based framework for contex-tual requirements modeling and analysis. Requirements Engineering, 15(4):439–458,2010.

[3] Colin Atkinson and Thomas Kuhne. Model-driven development: a metamodelingfoundation. Software, IEEE, 20(5):36–41, 2003.

[4] Josias Paes da Silva Junior. Agile: Uma abordagem para geração automáticade linguagens i*. Master’s thesis, Universidade Federal de Pernambuco, Recife,Pernambuco, Brasil, 2011.

[5] Jose Luis de la Vara, Raian Ali, Fabiano Dalpiaz, Juan Sánchez, and Paolo Giorgini.Business processes contextualisation via context analysis. In Conceptual Modeling–

ER 2010, pages 471–476. Springer, 2010.

[6] Ana Cristina de Freitas Dias. Uma linguagem específica do domínio para umaabordagem orientada aos objectivos baseada em kaos. Master’s thesis, UniversidadeNova de Lisboa, Lisboa, Portugal, 2009.

[7] Antonio García Richard Paige Dimitris Kolovos, Louis Rose. The Epsilon Book,volume 1. Eclipse Public License, 2013.

[8] Steve Easterbrook, Janice Singer, Margaret-Anne Storey, and Daniela Damian. Se-lecting empirical methods for software engineering research. In Guide to advanced

empirical software engineering, pages 285–311. Springer, 2008.

[9] Eclipse. BPMN2 Modeler, 2013. http://eclipse.org/bpmn2-modeler/. Último acessoem Dezembro/2013.

[10] Eclipse. Eclipse Modeling Framework Project (EMF), 2013.http://www.eclipse.org/modeling/emf/. Último acesso em Outubro/2013.

[11] Eclipse. Eclipse Modeling Project, 2013. http://www.eclipse.org/modeling/. Últimoacesso em Outubro/2013.

118

[12] Eclipse. Epsilon, 2013. http://www.eclipse.org/epsilon/. Último acesso em Outu-bro/2013.

[13] Eclipse. EuGENia, 2013. http://www.eclipse.org/epsilon/doc/eugenia/. Últimoacesso em Outubro/2013.

[14] Eclipse. EuGENia, 2013. http://www.eclipse.org/epsilon/doc/articles/eugenia-gmf-tutorial/. Último acesso em Dezembro/2013.

[15] Eclipse. Graphical Modeling Project (GMP), 2013.http://www.eclipse.org/modeling/gmp/. Último acesso em Outubro/2013.

[16] Epsilon. Emfatic, 2013. http://www.eclipse.org/epsilon/doc/articles/emfatic/. Úl-timo acesso em Outubro/2013.

[17] Epsilon. Epsilon Transformation Language, 2013.http://www.eclipse.org/epsilon/doc/etl/. Último acesso em Janeiro/2014.

[18] Epsilon. Epsilon Validation Language, 2013.http://www.eclipse.org/epsilon/doc/evl/. Último acesso em Outubro/2013.

[19] Robson N Fidalgo, Edson Alves, Sergio España, Jaelson Castro, and Oscar Pastor.Metamodeling the enhanced entity-relationship model. Journal of Information and

Data Management, 4(3):406, 2013.

[20] Lidia Fuentes-Fernández and Antonio Vallecillo-Moreno. An introduction to umlprofiles. UML and Model Engineering, 2, 2004.

[21] Debasish Ghosh. DSLs in action. Manning Publications Co., 2010.

[22] Paul Hudak. Building domain-specific embedded languages. ACM Comput. Surv.,28(4es):196, 1996.

[23] Zoubida Kedad and Pericles Loucopoulos. Considering quality factors for businessprocesses during requirement engineering. In Research Challenges in Information

Science (RCIS), 2011 Fifth International Conference on, pages 1–9. IEEE, 2011.

[24] Steven Kelly and Juha-Pekka Tolvanen. Domain-specific modeling: enabling full

code generation. Wiley. com, 2008.

[25] Dimitriois Kolovos. An extensible platform for specification of integrated languages

for model management. Doutorado, The University of York, 2008.

119[26] Holger Krahn, Bernhard Rumpe, and Steven Völkel. Integrated definition of abstract

and concrete syntax for textual languages. In Model Driven Engineering Languages

and Systems, pages 286–300. Springer, 2007.

[27] Marcello La Rosa. Managing variability in process-aware information systems.2009.

[28] Marcello La Rosa, Wil MP van der Aalst, Marlon Dumas, and Arthur HM ter Hofs-tede. Questionnaire-based variability modeling for system configuration. Software

& Systems Modeling, 8(2):251–274, 2009.

[29] Alexei Lapouchnian, Yijun Yu, and John Mylopoulos. Requirements-driven de-sign and configuration management of business processes. In Business Process

Management, pages 246–261. Springer, 2007.

[30] Eric Yu John Mylopoulos Lawrence Chung, Brian A. Nixon. Non-Functional

Requirements in Software Engineering. Kluwer Academic Publishers, 2000.

[31] James R Lewis. Ibm computer usability satisfaction questionnaires: psychometricevaluation and instructions for use. International Journal of Human-Computer

Interaction, 7(1):57–78, 1995.

[32] Sotirios Liaskos, Alexei Lapouchnian, Yijun Yu, Eric Yu, and John Mylopoulos.On goal-based variability acquisition and analysis. In Requirements Engineering,

14th IEEE International Conference, pages 79–88. IEEE, 2006.

[33] Rensis Likert. A technique for the measurement of attitudes. Archives of psychology,1932.

[34] John A.G. McClelland. Técnica de questionário para pesquisa. Revista Brasileira

de Física, 1(1):93–101, 1976.

[35] OMG. Omg object constraint language (ocl). Technical report, OMG - ObjectManagement Group, January 2012.

[36] OMG. Documents Associated With Business Process Model And Notation (BPMN)Version 2.0, 2013. http://www.omg.org/spec/BPMN/2.0/. Último acesso em No-vembro/2013.

[37] OMG. Omg meta object facility (mof) core specification. Technical report, OMG -Object Management Group, June 2013.

120

[38] OMG. Omg mof 2 xmi mapping specification. Technical report, OMG - ObjectManagement Group, June 2013.

[39] Christopher J Pavlovski and Joe Zou. Non-functional requirements in businessprocess modeling. In Proceedings of the fifth Asia-Pacific conference on Conceptual

Modelling-Volume 79, pages 103–112. Australian Computer Society, Inc., 2008.

[40] Tarcisio C Pereira, Fernanda Alencar, Jackson Silva, and Jaelson Castro. Requisitosnão-funcionais em modelos de processos de negócio: Uma revisão sistemática. IX

Simpósio Brasileiro de Sistemas de Informação, 1:37–48, 2013.

[41] Klaus Pohl, Günter Böckle, and Frank J. van der Linden. Software Product Line

Engineering: Foundations, Principles and Techniques. Springer-Verlag New York,Inc., Secaucus, NJ, USA, 2005.

[42] Michael Rosemann, Jan Recker, and Christian Flender. Contextualisation of businessprocesses. International Journal of Business Process Integration and Management,3(1):47–60, 2008.

[43] Ruby. A Programmer’s Best Friend, 2013. https://www.ruby-lang.org/pt/. Últimoacesso em Outubro/2013.

[44] RubyOnRails. Web development that doesn’t hurt, 2013. http://rubyonrails.org/.Último acesso em Outubro/2013.

[45] K. Saeedi, Liping Zhao, and P.R.F. Sampaio. Extending bpmn for supportingcustomer-facing service quality requirements. In Web Services (ICWS), 2010 IEEE

International Conference on, pages 616–623, 2010.

[46] Bárbara Siqueira Santos. Istar tool - uma proposta de ferramenta para modelagem i*.Master’s thesis, Universidade Federal de Pernambuco, Recife, Pernambuco, Brasil,2008.

[47] Emanuel Santos, João Pimentel, Jaelson Castro, and Anthony Finkelstein. On thedynamic configuration of business process models. In Enterprise, Business-Process

and Information Systems Modeling, pages 331–346. Springer, 2012.

[48] Emanuel Batista Santos. Business Process Configuration with NFRs and Context-

Awareness. Doutorado, Universidade Federal de Pernambuco, 2013.

121[49] Arnd Schnieders and Frank Puhlmann. Variability mechanisms in e-business process

families. BIS, 85:583–601, 2006.

[50] Andrew Sears and Julie A Jacko. The human-computer interaction handbook:

fundamentals, evolving technologies and emerging applications. CRC Press, 2007.

[51] Arie van Deursen, Paul Klint, and Joost Visser. Domain-specific languages: anannotated bibliography. SIGPLAN Not., 35(6):26–36, June 2000.

[52] Petia Wohed, Wil MP van der Aalst, Marlon Dumas, Arthur HM ter Hofstede,and Nick Russell. Pattern-based analysis of bpmn. Technical report, QueenslandUniversity of Technology, 2005.

[53] Christian Wolter and Christoph Meinel. An approach to capture authorisationrequirements in business processes. Requirements engineering, 15(4):359–373,2010.

123

Apêndice

125

AManual de Usuário da Ferramenta

BVCCoN-Tool

A.1 Criação de Modelos

Nesta seção, apresentamos a forma de utilização do editor da ferramenta para a criaçãode modelos.

A ferramenta apresenta um espaço onde os elementos serão inseridos e do lado direitoapresenta um menu de seleção onde são exibidos os elementos necessários (nós, linkse compartments) para construção dos modelos. A Figura A.1 apresenta o espaço demodelagem, representado pelo número 1 e o menu de seleção pelo número 2.

O menu de seleção apresenta 7 tipos de elementos: Variability Nodes (onde estãorepresentados os elementos referentes a descrição de variabilidade), Variability Links

(representam os diferentes tipos de links que são utilizados para fazer as ligações dosnós de variabilidade), Models (onde estão representados os compartimentos NFRModel

e Context Model, onde são armazenados os elementos de requisitos não-funcionais econtexto respectivamente).

Context Nodes (apresenta os elementos referentes a descrição das informações contex-tuais), Context Links (exibem os diferentes links utilizados para montar as informações decontexto), NFRNode (apresenta o elemento que representa um requisito não-funcional) epor último NFRLinks (representa os links de contribuições entre requisitos não-funcionaise também entre uma variante e um RNF).

Para realizar uma modelagem de um caso, seja ele qual for, é necessário modelaras três visões que a ferramenta oferece. A de requisitos não-funcionais, variabilidadee informação contextual. Ao longo deste tutorial, será criado exemplos para ilustrar asetapas necessárias para a construção destas visões.

126

Figura A.1 Editor gráfico da ferramenta

1. Criar VariationPoint: Para iniciar a modelagem, é necessário incluir algum ele-mento no diagrama, poderia ser qualquer um, porém, por questões de melhorcompreensão e visualização, optamos por começar inserindo um ponto de variação.Exitem duas maneiras de criação: a primeira é ir ao menu de seleção chamado Vari-

ability Nodes e escolher o elemento VariationPoint (retângulo vermelho); a segundamaneira é na janela de edição, quando aparecem quais os elementos disponíveis(retângulo verde), escolher o elemento Variation Point.

Após inserir o ponto de variação, definimos os atributos id, name e operator. Opróximo passo é carregar um modelo .bpmn e setar no ponto de variação os atributosbegins, ends e flow elements. Até então, pode ser conferido a execução destespassos na Figura A.2.

2. Carregar Modelo BPMN: Para carregar um modelo BPMN, é necessário clicarcom o botão direito dentro da área de modelagem, em seguida clicar em Load

Resource. Clicando em Load Resource, irá aparecer uma janela onde é necessárionavegar até o caminho em que o arquivo .bpmn está. Pode-ser navager através deBrowse Workspace, que irá procurar dentro dos projetos do eclipse ou Browse File

System, procurando em todas as pastas do computador. Após encontrar o arquivoBPMN, o selecione e clique em OK e em seguida em OK novamente para finalizar.As Figuras A.3, A.4, A.5 e A.6 apresentam as atividades desta etapa.

3. Associando um VariationPoint ao processo de negócio: Agora que já carregamos

127

Figura A.2 Inclusão de um ponto de variação

Figura A.3 Carregando modelo BPMN

128

Figura A.4 Procurando modelo BPMN

o processo de negócio, precisamos setar os atributos restantes do ponto de variação.Ou seja, precisamos definir onde o ponto de variação começa e onde termina nomodelo de processo de negócio. Para fazer isso, vamos na aba Properties e clicamosdentro do campo Begins. Irá aparecer um ComboBox com todos os elementos doprocesso de negócio que foi importado. Neste momento, basta selecionar ondeo ponto de variação começa. A mesma coisa deve ser feita para o campo Ends,indicando onde o ponto de variação termina (ver Figura A.7).

Em seguida, precisamos adicionar todos os elementos que fazem parte do intervalodo ponto de variação. Portanto, clicamos no campo FlowElements e adicionamosos elementos de fluxo pertencentes a determinado ponto de variação (ver FigurasA.8 e A.9). A Figura A.10 apresenta um ponto de variação com os atributos setados.Os elementos de fluxo são os elementos BPMN que fazem parte do processo denegócio, incluindo os links.

4. Criar Variant: Exitem duas maneiras de criação: a primeira é ir ao menu de seleçãochamado Variability Nodes e escolher o elemento Variant; a segunda maneira éna janela de edição, quando aparecem quais os elementos disponíveis, escolhero elemento Variant. Após inserir a variante, definimos os atributos id e name. O

129

Figura A.5 Selecionando modelo BPMN

130

Figura A.6 Finalizando o carregamento de um modelo BPMN

131

Figura A.7 Setando os atributos Begins e Ends de um ponto de variação

Figura A.8 Setando os FlowElements de um ponto de variação

132

Figura A.9 Setando os FlowElements de um ponto de variação

133

Figura A.10 Variation Point

134

Figura A.11 WorkflowPattern

próximo passo é carregar um modelo .bpmn e setar na variante os atributos begins,

ends e flow elements. Estes passos são iguais aos descritos no ponto de variação.Uma variante precisa possuir um WorkflowPattern, que indicará como os elementosdo processo pertencentes a variante irão ser alocadas no processo principal. Apróxima etapa indica como fazer isto.

5. Criando um WorkFlowPattern: Exitem duas maneiras de criação: a primeira é irao menu de seleção chamado Variability Nodes e escolher o elemento WorkflowPat-

tern; a segunda maneira é na janela de edição, quando aparecem quais os elementosdisponíveis, escolher o elemento WorkflowPattern. Após inserir o elemento, énecessário definir seu id e o tipo de Pattern. Figura A.11 exibe esta etapa.

6. Ligando WorkflowPattern a uma variante: Para realizar este tipo de ligação, énecessário ir até a seção Variability Links, selecionar o link VariantSource e realizara ligação entre o WorkflowPattern e a variante (ver Figura A.12).

7. Ligando uma variante a um ponto de variação: Esta ligaçao é feita indo naseção Variability Links, selecionando o link VarPoints e realizando a ligação entrea variante e o ponto de variação (ver Figura A.12).

135

Figura A.12 Ligações

Figura A.13 Links Requires e Excludes

8. Links Requires e Excludes: Uma variante pode requerer ou excluir a presençade outra variante. Os links responsáveis por este tipo de ligação são o Requires

e Excludes respectivamente. Ambos são encontrados na seção Variability Links.Este tipo de ligação é feita selecionando uma variante como source e ligando a umaoutra variante que será o target. A Figura A.13 apresenta estes dois tipos de links.O número 1 é referente ao link Require e o número 2 ao link Excludes.

9. Criar NFRModel e Softgoals: Antes de incluir os Softgoals, é necessário incluirum compartimento chamado NFRModel, encontrado na seção Models. Apósconcluir esta etapa, é permitido incluir os elementos Softgoals. Para isto, bastair na seção NFR Node, selecionar o elemento NFRSoftgoal e incluí-lo dentro do

136

Figura A.14 Criando NFRmodel e Softgoals

compartimento que foi criado. Após incluir o Softgoal, precisamos definir o id,

name e o nfr softgoal priority. A Figura A.14 apresenta o NFRModel e doisSoftgoals.

10. Ligações entre Softgoals: São dois, os tipos de ligações que podem ser feitas deSoftgoal para Softgoal. São elas: AndContribution e OrContribution, ambas sãoencontradas na seção NFRLinks. Para realizar este tipo de ligação basta escolheruma das contribuições, selecionar um Softgoal como source e um outro Softgoal

como target (ver Figura A.15).

11. Ligações entre Variants e Softgoals: Cinco tipos de ligações são permitidas entreVariants e Softgoals. Exemplo: BreakContribution, MakeContribution, EqualCon-

tribution, HurtContribution e HelpContribution. Para realizar estas ligações decontribuições, basta ir na seção NFRLinks, escolher um tipo de ligação e efetuar aligaçao propriamente dita entre uma Variant desejada e um Softgoal desejado. A

137

Figura A.15 Ligações entre Softgoals

Figura A.16 ilustra este caso.

12. Criar Context Model e as Informações de Contexto: Antes de montar as infor-mações de contexto, é necessário incluir um compartimento chamado Context

Model, encontrado na seção Models. Este compartimento é onde as informaçõesde contextos irão ser montadas. Feito isso, é permitido incluir todos os elementosda seção Context Nodes e os links da seção Context Links, que são utilizados paramontar as informações contextuais.

13. Inserindo ContextExpression e Statement: Primeiro passo para iniciar a monta-gem de uma informação contextual é incluir um elemento chamado ContextExpres-

sion. Após incluir este elemento, precisamos definir seu id. Em seguida, inserimosum elemento chamado Statement, que é uma descrição do contexto. Tambémprecisamos definir seu id e uma descrição sobre o que aquela expressão de contextoestá representando. O próximo passo é realizar uma ligação entre o Statement eo ContextExpression. O link que faz esta ligação é o CELink. As etapas até aquidescritas podem ser encontradas na Figura A.17.

14. Decomposição e Fatos: Statement pode ser decomposto em um ou mais fatos.Quando existem mais de um fato, é necessário utilizar os elementos OrDecomposi-

tion ou AndDecomposition para realizar a decomposição. No exemplo que estamosutilizando, optamos por usar o AndDecomposition, então incluimos o elementoque o representa e em seguida adicionamos 2 fatos. Após adicionar os dois fatos,setamos o nome do fato e uma breve descrição (atributos name e description) (ver

138

Figura A.16 Ligações entre Variants e Softgoals

Figura A.17 Ligação entre ContextExpression e Statement

139

Figura A.18 AndDecomposition e Fatos

Figura A.18).

15. Ligações entre fatos, decomposições e statement: Todos estes elementos sãoconectados através do link PredicateLink. Selecionamos o AndDecomposition

como source e o Statement como target. Em seguida selecionamos os fatos comosource e o AndDecomposition como target (ver Figura A.19).

16. Fatos e Variáveis: Todo fato precisa estar conectado com uma variável. Umavariável representa os dados que serão monitorados para o ativamento ou não de um

Figura A.19 AndDecomposition e Fatos

140

Figura A.20 Variáveis

contexto. Após incluir as variáveis, é necessário inserir seu nome, o tipo de dadoque será monitorado e o valor do dado a ser monitorado. A Figura A.20 apresentaestas informações.

17. Ligações entre variáveis e fatos: O link responsável por fazer esta ligação é oVariables. Este link possui como source o fato, e como target uma variável. AFigura A.21 apresenta a informação de contexto montada e pronta para utilização.A próxima e última etapa é associar uma variante a uma expressão de contexto.

18. Associar uma variante com uma expressão de contexto: Para realizar esta tarefa,basta selecionar o link Contexts na seção Variability Links, escolher uma Variant

como source e uma ContextExpression como target. A Figura A.22 apresenta estaligação e também um pequeno exemplo completo de todas as visões, variabilidade,requisitos não-funcionais e informação contextual.

141

Figura A.21 Expressão de contexto

Figura A.22 Exemplo das três visões: variabilidade, requisitos não-funcionais e informaçãocontextual

143

BAvaliação da Usabilidade da Ferramenta

BVCCoN-Tool - Tarefa do Usuário

Pesquisa realizada pelo grupo LER (Laboratório de Engenharia de Requisitos) da Univer-sidade Federeal de Pernambuco, para a elaboração de um relatório de usabilidade de umaferramenta de modelagem.

Objetivo: Utilizar a ferramenta BVCCoN-Tool para realizar a modelagem deuma parte de um cenário de Check-In em um aeroporto.

Obs: Para validar o modelo, clicar dentro do espaço destinado para modelagem, irao Menu Edit -> Validate.

Passos da tarefa:

1. Criação do Projeto: Para se criar um projeto ir a File -> New -> Project. Na janelaque aparece ir a General -> Project. Clicar em Next, escrever o nome do projeto eclicar em Finish. Após a criação do projeto, deve-se criar o espaço de edição dosmodelos. Para isso ir a File -> New -> Example e seleciona-se BvccontoolDiagram.Clica-se em Next, clica-se em Next novamente e em seguida clica-se em Finish. Noprojeto criado anteriormente aparecem dois arquivos, um com extensão .bvccontoole outro com a extensão .bvccontool_diagram. O que vai ser usado na criação demodelos é o segundo.

2. Inserindo Modelos BPMN Dentro do Projeto: Acessar o link(http://goo.gl/J2n82r). Se tiver conectado à internet, os modelos serão baixadosautomaticamente em um arquivo .rar. Ir até onde este arquivo .rar foi baixado e

144

extrair em um local de preferência. Em seguida copiar todos os arquivos .bpmn ecolar dentro do projeto que foi criado anteriormente.

3. Criando um Ponto de Variação: Para criar um ponto de variação ir na Paleta deelementos, que fica localizada do lado direito, seção Variability Nodes, seleciona-seo elemento VariationPoint e o insere dentro da área destinada para modelagem. Iraté a aba Properties e definir seu nome como VP01, seu id como 1 e o operadorcomo OR. Obs: Se a aba Properties não estiver visível, ir até o menu Window ->ShowView -> Other -> General -> Properties -> OK.

4. Importar Modelo de Referência: Clicar com o botão direito na área de modela-gem, clicar em Load Resource, em seguida clicar em Browse Workspace, navegarno projeto que foi criado, selecionar o arquivo reference_process.bpmn, clicar emOK e em seguida em OK novamente.

5. Definir Begins, Ends e Flow Elements do Ponto de Variação: Com o ponto devariação selecionado, ir até a aba Properties e definir os atributos begins, ends eflow elements. A Figura B.1 apresenta o processo referência, a tarefa que representao atributo Begins (Verify Flight Information), a tarefa que representa o atributoends (Emit Boarding Pass) e dentro da caixa vermelha os elementos para sereminseridos no atributo Flow Elements (Verify Flight Information, Sequence Flow 4,

Perform Check-In, Sequence Flow 5 e Emit Boarding Pass).

6. Criando uma Variante: Para criar uma variante ir na Paleta de elementos quefica localizada do lado direito, seção Variability Nodes, seleciona-se o elementoVariant e o insere dentro da área destinada para modelagem. Ir até a aba Properties

e definir seu nome como Perform Online Check-in, seu id como 2.

7. Importando Modelo BPMN Para a Variante: Clicar com o botão direito na áreade modelagem, clicar em Load Resource, em seguida clicar em Browse Workspace,navegar no projeto que foi criado, selecionar o arquivo variant_process.bpmn,clicar em OK e em seguida em OK novamente.

8. Definir Begins, Ends e Flow Elements da Variante: Com a variante selecionada,ir até a aba Properties e definir os atributos begins, ends e flow elements. AFigura B.2 apresenta um pedaço de processo que faz parte da variante, incluindoa tarefa que representa o atributo Begins (Verify Flight Information Online), atarefa que representa o atributo ends (Perform Check-In Online) e dentro da caixa

145

Figura B.1 Processo de Referência

146

Figura B.2 Pedaço de um Processo de uma Variante

vermelha os elementos para serem inseridos no atributo Flow Elements (Verify

Flight Information Online, Variant_SF_Um e Perform Check-in Online).

9. Inserir WorkflowPattern e Conectá-lo a Variante: Para criar um WorkflowPattern

ir na Paleta de elementos que fica localizada do lado direito, seção Variability Nodes,seleciona-se o elemento WorkflowPattern e o insere dentro da área destinada paramodelagem. Em seguida, define o atributo Wt Pattern como SEQUENCE e oid como 3. Para realizar a ligação entre o WorkflowPattern e a variante criadaanteriormente ir na Paleta de elementos, seção Variability Links e seleciona-seo link VariantSource. Em seguida, efetuar a ligação do WorkflowPattern para avariante.

10. Ligar a Variante a um Ponto de Variação: Para realizar a ligação entre a variantee um ponto de variação ir na Paleta de elementos, seção Variability Links e seleciona-se o link VarPoints. Em seguida, efetuar a ligação da variante para o ponto devariação.

11. Criar NFRModel e Softgoals: Para criar um NFRModel ir na Paleta de elementosque fica localizada do lado direito, seção Models, seleciona-se o elemento NFRMo-

del e o insere dentro da área destinada para modelagem. Em seguida adiciona-seum Softgoal dentro do NFRModel. Para fazer este passo ir na seção NFR Node,seleciona NFRSoftgoal e o insere dentro do compartimento NFRModel.

Em seguida, ir até a aba Properties e definir seu id como 4, nome como Time

Performance e seu NFR Softgoal Priority como 0.

Inserir outro Softgoal e definir seu id como 5, nome como Throughput e seu NFR

Softgoal Priority como 1.

147Inserir mais um Softgoal e definir seu id como 6, nome como Response Time e seuNFR Softgoal Priority como 2.

12. Ligar Softgoals: Ir até a Paleta de elementos que fica localizada do lado direito,seção NFR Links, selecionar o link AndContribution e realizar uma ligação doSoftgoal Time Performance para o Softgoal Throughput. Também realizar o mesmotipo de ligação do Softgoal Time Performance para o Softgoal Response Time.

13. Ligar Variante e Softgoal: Ir até a Paleta de elementos que fica localizada dolado direito, seção NFR Links, selecionar o link MakeContribution e realizar umaligação da Variante para o Softgoal Throughput. Também realizar o mesmo tipo deligação da Variante para o Softgoal Response Time.

14. Criar ContextModel: Para criar um ContextModel ir na Paleta de elementos quefica localizada do lado direito, seção Models, seleciona-se o elemento ContextModel

e o insere dentro da área destinada para modelagem.

15. Criar ContextExpression: Agora que já foi inserido o compartimento Context-

Model, pode-se começar a montar as expressões de contexto. Ir até a Paleta deelementos que fica localizada do lado direito, seção Context Nodes, selecionar oelemento Context Expression e o inserir dentro do ContextModel. Em seguida,definir seu id como 7.

16. Criar Statement e ligar com a ContextExpression: Para criar um Statement, irna Paleta de elementos que fica localizada do lado direito, seção ContextNodes,seleciona-se o elemento Statement e o insere dentro da área destinada para mode-lagem. Definir seu id como 8 e sua descrição como on-line check-in is available.Para ligar o elemento Statement, ir na Paleta de elementos, seção ContextLinks,selecionar o link CELink e realizar a ligação do Statement que foi criado nesteetapa para a ContextExpression que foi criada na etapa anterior.

17. Decompor a Expressão de Contexto: Para decompor a expressão de contexto irna Paleta de elementos que fica localizada do lado direito, seção ContextNodes,seleciona-se o elemento AndDecomposition e o insere dentro da área destinadapara modelagem.

18. Ligar o AndDecomposition ao Statement: Ir até a Paleta de elementos que ficalocalizada do lado direito, seção Context Links, selecionar o link PredicateLink erealizar uma ligação do AndDecomposition para o Statement.

148

19. Criar Fatos: Para criar um Fato, ir na Paleta de elementos que fica localizada dolado direito, seção ContextNodes, seleciona-se o elemento Fact e o insere dentro daárea destinada para modelagem. Repita o procedimento para inserir mais um fato,no total 2. Para o primeiro fato, defir seu nome como fact1 e sua descrição comoInternetIsOn. Para o segundo fato, definir seu nome como fact2 e sua descriçãocomo CheckinSystemIsWorking.

20. Ligar os Fatos ao AndDecomposition: Ir até a Paleta de elementos que ficalocalizada do lado direito, seção Context Links, selecionar o link PredicateLink erealizar uma ligação do Fato para o AndDecomposition. Realizar este procedimentopara os dois fatos que foram inseridos na etapa anterior.

21. Criar Variáveis: Para criar uma Variável, ir na Paleta de elementos que ficalocalizada do lado direito, seção ContextNodes, seleciona-se o elemento Variable

e o insere dentro da área destinada para modelagem. Repita o procedimento parainserir mais uma variável, no total 2. Para a primeira variável, definir seu nomecomo InternetIsOn, seu tipo como Boolean e seu valor como true. Para a segundavariável, definir seu nome como CheckinSystemIsWorking, seu tipo como Boolean

e seu valor como true.

22. Ligar Variáveis aos Fatos: Ir até a Paleta de elementos que fica localizada do ladodireito, seção Context Links, selecionar o link Variables e realizar uma ligação doFato InternetIsOn para a variável InternetIsOn. Realizar o mesmo procedimentopara selecionar o link Variables e realizar uma ligação do Fato CheckinSystemIsWor-

king para a variável CheckinSystemIsWorking.

23. Ligar Variante ao ContextExpression: Ir até a Paleta de elementos que ficalocalizada do lado direito, seção Variability Links, selecionar o link Contexts erealizar uma ligação da Variável Perform Online Check-in para o ContextExpression

C que foi definido no compartimento ContextModel.

24. Preencher Questionário Online: Acessoar o site http://goo.gl/3wNpKf e preen-cher o questionário PSSUQ (The Post-Study System Usability Questionnaire).

Ao final do teste, pretende-se ter construído o modelo da Figura B.3.

Fim do teste! Obrigado pela participação!

Figura B.3 Modelo BVCCoN Completo

151

CThe Post-Study System Usability

Questionnaire (PSSUQ)

This questionnaire gives you an opportunity to tell us your reactions to the systemyou used. Your responses will help us understand what aspects of the system you areparticularly concerned about and the aspects that satisfy you.

To as great a degree as possible, think about all the tasks that you have done with thesystem while you answer these questions. Please read each statement and indicate howstrongly you agree or disagree with the statement.

Thank you.

1. Overall, I am satisfied with how easy it is to use this system.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree

(e) Strongly Disagree

2. It was simple to use this system.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


152

3. I could effectively complete the tasks and scenarios using this system.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


4. I was able to complete the tasks and scenarios quickly using this system.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


5. I was able to efficiently complete the tasks and scenarios using this system.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


6. I felt comfortable using this system.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


7. It was easy to learn to use this system.

(a) Strongly Agree

153(b) Agree

(c) Neutral

(d) Disagree


8. I believe I could become productive quickly using this system.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


9. The system gave error messages that clearly told me how to fix problems.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


10. Whenever I made a mistake using the system, I could recover easily and quickly.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


11. The information (such as on-line help, on-screen messages and other documenta-tion) provided with this system was clear.

(a) Strongly Agree

(b) Agree

(c) Neutral

154

(d) Disagree


12. It was easy to find the information I needed.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


13. The information provided for the system was easy to understand.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


14. The information was effective in helping me complete the tasks and scenarios.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


15. The organization of information on the system screens was clear.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


155Note: The interface includes those items that you use to interact with the system.

For example, some components of the interface are the keyboard, the mouse, the

screens (including their use of graphics and language).

16. The interface of this system was pleasant.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


17. I liked using the interface of this system.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


18. This system has all the functions and capabilities I expect it to have.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree


19. Overall, I am satisfied with this system.

(a) Strongly Agree

(b) Agree

(c) Neutral

(d) Disagree
