Ps-Graduao em Cincia da Computao

BVCCoN-Tool Uma Ferramenta para Apoiar uma

Abordagem de Configurao de Processos de Negcio

Dinmicos

Por

Tarcsio Couto Pereira

Dissertao de Mestrado

Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br

www.cin.ufpe.br/~posgraduacao

RECIFE, 04/2014

Universidade Federal de Pernambuco

Centro de InformticaPs-graduao em Cincia da Computao

Tarcsio Couto Pereira

BVCCoN-Tool - Uma Ferramenta para Apoiar umaAbordagem de Configurao de Processos de Negcio

Dinmicos

Trabalho apresentado ao Programa de Ps-graduao em

Cincia da Computao do Centro de Informtica da Univer-

sidade Federal de Pernambuco como requisito parcial para

obteno do grau de Mestre em Cincia da Computao.

Orientador: Jaelson Freire Brelaz de CastroCo-Orientador: Fernanda Maria Ribeiro de Alencar

Recife, 15 de abril de 2014

Catalogao na fonte Bibliotecrio Jefferson Luiz Alves Nazareno, CRB 4-1758

Pereira, Tarcsio Couto. BVCCoN-Tool: uma ferramenta para apoiar uma abordagem de configurao de processos de negcio dinmicos./ Tarcsio Couto Pereira. Recife: O Autor, 2014. xxv, 125f. : fig.

Orientador: Jaelson Freire Brelaz de Castro. Dissertao (Mestrado) - Universidade Federal de Pernambuco. Cin. Cincia da computao , 2014. Inclui referncias e apndice.

1. Cincia da computao . 2. Engenharia de software. 3. Processos de negcio I. Castro, Jaelson Freire Brelaz.. (orientador). II. Ttulo.

004 (22. ed.) MEI 2014-46

Dissertao de Mestrado apresentada por Tarcsio Couto Pereira Ps-Graduao em

Cincia da Computao do Centro de Informtica da Universidade Federal de

Pernambuco, sob o ttulo BVCCoN-Tool - Uma Ferramenta para Apoiar uma

Abordagem de Configurao de Processos de Negcio Dinmicos orientada pelo

Prof. Jaelson Freire Brelaz de Castro e aprovada pela Banca Examinadora formada

pelos professores:

______________________________________________

Prof. Robson do Nascimento Fidalgo

Centro de Informtica / UFPE

______________________________________________

Prof. Gilberto Amado de Azevedo Cysneiros Filho

Departamento de Estatstica e Informtica / UFRPE

_______________________________________________

Profa. Jaelson Freire Brelaz de Castro

Centro de Informtica / UFPE

Visto e permitida a impresso.

Recife, 24 de fevereiro de 2014.

___________________________________________________

Profa. Edna Natividade da Silva Barros Coordenadora da Ps-Graduao em Cincia da Computao do

Centro de Informtica da Universidade Federal de Pernambuco.

Dedico esta dissertao especialmente aos meus pais Iran

Pereira Silva e Ana Maria Couto de Lucena Pereira, sem

vocs nada disso seria possvel.

Agradecimentos

Primeiramente agradeo a Deus por todas as benos, amor, proteo 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 vocs me porporcionaram. Obrigado por sempre meajudar a encontrar o caminho correto a seguir e por confiar em todas as decises quetomei. Amo vocs.

A minha noiva Luma Hannah, por todo o amor, companheirismo e dedicao duranteesses 4 anos que estamos juntos. Te agradeo por todo o apoio durante os ltimos 2 anose pela compreenso e pacincia nos momentos difceis que passei. Eu te amo! A minhaamada famlia por me proporcionar momentos de unio e felicidades. Apesar de muitasvezes longe um do outro, o amor e apoio sempre foi o mesmo.

Tambm agradeo aos meus amigos Jackson Raniel e Thiago Mendes pelas ideiascompartilhadas. Ao meu professor orientador Jaelson Castro, por me aceitar orientar e portoda contribuio e ensinamentos que resultaram neste trabalho. A todos meus amigos dogrupo LER (Laboratrio de Engenharia de Requisitos), em especial a Emanuel Santos,Paulo de Lima, Jssyka 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

Dont stop believin

Hold on to the feelin

Streetlights, people...

JOURNEY (Dont Stop Believin)

Resumo

Os processos esto se tornando cada vez mais complexos e heterogneos, inseridos emambientes onde as mudanas so constantes, sendo influenciados por fatores geogrficos,climticos, dentre outros. As empresas precisam manter seus processos atualizados efuncionando adequadamente, sem desprezar os requisitos de qualidade. Baseado nestecenrio, foi proposto na literatura uma abordagem de configurao de processos chamadaBVCCoN.

Esta abordagem possui como objetivo oferecer suporte a configurao de processosbaseada em NFRs e informaes contextuais. A abordagem possui trs perspectivasna configurao de processo de negcio: a descrio de variabilidade, os requisitosno-funcionais e o contexto. Durante as etapas desta abordagem, necessrio realizara modelagem destas trs perspectivas. Contudo, modelar as trs perspectivas umaatividade que requer tempo e que est propensa a erros.

Assim, esta dissertao prope o desenvolvimento de uma ferramenta que apoia amodelagem dos requisitos no-funcionais, da variabilidade e das regras de contexto. Paraconstruir a ferramenta, foi realizada a integrao de trs metamodelos, com algumasalteraes, sendo cada um referente a uma perspectiva da abordagem BVCCoN. Almdisso, foi utilizado o framework Epsilon e seu conjunto de linguagens integrado noambiente Eclipse para o desenvolvimento da ferramenta. Para ilustrar a utilizao daferramenta, foi realizado um estudo de caso em um cenrio de check-in em aeroporto, bemcomo uma avaliao de usabilidade com potenciais usurios, visando avaliar os seguintesfatores: satisfao geral, utilidade do sistema, qualidade da informao e qualidade dainterface.

Palavras-chave: bvccon. processos de negcio. requisitos no-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]. . . . . . . . . . . 32

2.2 Exemplo de modelo referncia com pontos de variao. Adaptado de [48]. 34

2.3 Exemplo de variantes e pontos de variao. Adaptado de [48]. . . . . . 36

2.4 Exemplo de decomposio de contexto. Adaptado de [48]. . . . . . . . 38

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

2.6 Exemplo de uma instncia de processo. Adaptado de [48]. . . . . . . . 42

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

2.8 Dashboard GMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1 Parte do Metamodelo BVCCoN . . . . . . . . . . . . . . . . . . . . . 58

3.2 Elementos Grficos x Metamodelo - Exemplo 1 . . . . . . . . . . . . . 59

3.3 Elementos Grficos x Metamodelo - Exemplo 2 . . . . . . . . . . . . . 59

3.4 Elementos Grficos x Metamodelo - Exemplo 3 . . . . . . . . . . . . . 60

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

3.6 Metamodelo Variability - BVCCoN . . . . . . . . . . . . . . . . . . . 63

3.7 Perspectiva Contexto [48] . . . . . . . . . . . . . . . . . . . . . . . . . 66

3.8 Metamodelo Contexto - BVCCoN-Tool . . . . . . . . . . . . . . . . . 68

3.9 Perspectiva RNF [48]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.10 Metamodelo RNF - BVCCoN . . . . . . . . . . . . . . . . . . . . . . . 72

3.11 Sintaxe concreta do Ponto de Variao. . . . . . . . . . . . . . . . . . . 76

3.12 Sintaxe concreta de uma Variante. . . . . . . . . . . . . . . . . . . . . 78

3.13 Sintaxe concreta de RNF. . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.14 Sintaxe concreta de Contexto. . . . . . . . . . . . . . . . . . . . . . . . 82

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

3.16 Menu de seleo da ferramenta . . . . . . . . . . . . . . . . . . . . . . 83

3.17 Modelo RNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3.18 Modelo RNF e Variabilidade . . . . . . . . . . . . . . . . . . . . . . . 84

3.19 Modelo de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.20 Modelo BVCCoN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.1 Processo de Referncia . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.2 Pontos de Variao no Processo de Referncia . . . . . . . . . . . . . . 92

4.3 Pontos de Variao e Variantes com partes de Processos de Negcio . . 94

4.4 Anlise de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

xvi

4.5 Requisitos No-Funcionais e Anlise de Contribuio . . . . . . . . . . 97

A.1 Editor grfico da ferramenta . . . . . . . . . . . . . . . . . . . . . . . 124A.2 Incluso de um ponto de variao . . . . . . . . . . . . . . . . . . . . . 125A.3 Carregando modelo BPMN . . . . . . . . . . . . . . . . . . . . . . . . 125A.4 Procurando modelo BPMN . . . . . . . . . . . . . . . . . . . . . . . . 126A.5 Selecionando modelo BPMN . . . . . . . . . . . . . . . . . . . . . . . 127A.6 Finalizando o carregamento de um modelo BPMN . . . . . . . . . . . . 128A.7 Setando os atributos Begins e Ends de um ponto de variao . . . . . . . 129A.8 Setando os FlowElements de um ponto de variao . . . . . . . . . . . 129A.9 Setando os FlowElements de um ponto de variao . . . . . . . . . . . 130A.10 Variation Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131A.11 WorkflowPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132A.12 Ligaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133A.13 Links Requires e Excludes . . . . . . . . . . . . . . . . . . . . . . . . 133A.14 Criando NFRmodel e Softgoals . . . . . . . . . . . . . . . . . . . . . . 134A.15 Ligaes entre Softgoals . . . . . . . . . . . . . . . . . . . . . . . . . 135A.16 Ligaes entre Variants e Softgoals . . . . . . . . . . . . . . . . . . . . 136A.17 Ligao entre ContextExpression e Statement . . . . . . . . . . . . . . 136A.18 AndDecomposition e Fatos . . . . . . . . . . . . . . . . . . . . . . . . 137A.19 AndDecomposition e Fatos . . . . . . . . . . . . . . . . . . . . . . . . 137A.20 Variveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138A.21 Expresso de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . 139A.22 Exemplo das trs vises: variabilidade, requisitos no-funcionais e infor-

mao contextual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

B.1 Processo de Referncia . . . . . . . . . . . . . . . . . . . . . . . . . . 143B.2 Pedao de um Processo de uma Variante . . . . . . . . . . . . . . . . . 144B.3 Modelo BVCCoN Completo . . . . . . . . . . . . . . . . . . . . . . . 147

Lista de Tabelas

2.1 Relao entre o tipo de representao de RNF e trabalhos selecionados [40]. 302.2 Sumarizao dos Resultados . . . . . . . . . . . . . . . . . . . . . . . 302.3 Contribuio para os RNFs Confiana e Performance . . . . . . . . . . 412.4 Sumrio de Critrios . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1 Contribuio dos RNFs . . . . . . . . . . . . . . . . . . . . . . . . . . 984.2 Equipamentos utilizados para realizao do teste . . . . . . . . . . . . . 1004.3 Respostas dos Participantes . . . . . . . . . . . . . . . . . . . . . . . . 1034.4 Satisfao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.5 Utilidade do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 1064.6 Qualidade da Informao . . . . . . . . . . . . . . . . . . . . . . . . . 1074.7 Qualidade da Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Lista de Acrnimos

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 . . . . . . . . . . . . . . . . . . . . . 512.2 Exemplo de Cdigo EVL . . . . . . . . . . . . . . . . . . . . . . . . . 533.1 Metamodelo Variabilidade escrito em Emfatic . . . . . . . . . . . . . . 633.2 Metamodelo Contexto escrito em Emfatic . . . . . . . . . . . . . . . . 683.3 Metamodelo RNF escrito em Emfatic . . . . . . . . . . . . . . . . . . 723.4 Restries EVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Sumrio

1 Introduo 251.1 Motivao e Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.2 Objetivos da Investigao . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.2.2 Objetivos Especficos . . . . . . . . . . . . . . . . . . . . . . . 27

1.3 Estrutura da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2 Fundamentao Terica e Trabalhos Relacionados 292.1 Reviso Sistemtica da Literatura . . . . . . . . . . . . . . . . . . . . . 29

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

2.2.1 Elicitao da Variabilidade . . . . . . . . . . . . . . . . . . . . 32

2.2.2 Descrio da Variabilidade . . . . . . . . . . . . . . . . . . . . 32

2.2.3 Anlise de Contexto . . . . . . . . . . . . . . . . . . . . . . . 37

2.2.4 Ligar Variantes & RNF . . . . . . . . . . . . . . . . . . . . . . 38

2.2.5 Realizar a Configurao . . . . . . . . . . . . . . . . . . . . . 41

2.2.6 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . 41

2.3 Meta-Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.3.1 UML - Unified Modeling Language . . . . . . . . . . . . . . . 45

2.3.2 DSML - Linguagem para Modelagem Especfica de Domnio . . 46

2.4 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.4.1 Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . 48

2.4.2 Graphical Modeling Framework . . . . . . . . . . . . . . . . . 49

2.4.3 Epsilon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

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

2.5 Consideraes do Captulo . . . . . . . . . . . . . . . . . . . . . . . . 56

3 BVCCoN Tool 573.1 Modelo e Metamodelo BVCCoN . . . . . . . . . . . . . . . . . . . . . 57

3.1.1 Sintaxe Abstrata . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.1.1.1 Modelo BPMN . . . . . . . . . . . . . . . . . . . . . 60

3.1.1.2 Variabilidade . . . . . . . . . . . . . . . . . . . . . . 61

3.1.1.3 Contexto . . . . . . . . . . . . . . . . . . . . . . . . 65

3.1.1.4 Requisitos No-Funcionais . . . . . . . . . . . . . . . 70

xxiv

3.1.2 Sintaxe Concreta . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.1.2.1 Variabilidade . . . . . . . . . . . . . . . . . . . . . . 75

3.1.2.2 Requisitos No-Funcionais . . . . . . . . . . . . . . . 78

3.1.2.3 Contexto . . . . . . . . . . . . . . . . . . . . . . . . 79

3.2 A Ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

3.3 Restries EVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.4 Consideraes do Captulo . . . . . . . . . . . . . . . . . . . . . . . . 87

4 Avaliao 894.1 Cenrio: Check-In Aeroporto . . . . . . . . . . . . . . . . . . . . . . . 89

4.2 Exemplo de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.2.1 Processo de Referncia . . . . . . . . . . . . . . . . . . . . . . 90

4.2.2 Elicitao da Variabilidade . . . . . . . . . . . . . . . . . . . . 90

4.2.3 Descrio da Variabilidade . . . . . . . . . . . . . . . . . . . . 90

4.2.4 Anlise de Contexto . . . . . . . . . . . . . . . . . . . . . . . 95

4.2.5 Anlise de Requisitos No-Funcionais . . . . . . . . . . . . . . 95

4.3 Teste de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

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

4.3.2 Usurios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.3.3 Equipamentos e Ambiente . . . . . . . . . . . . . . . . . . . . 100

4.3.4 Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.3.5 Processo de Coleta dos Dados . . . . . . . . . . . . . . . . . . 100

4.3.6 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.3.6.1 Satisfao Geral . . . . . . . . . . . . . . . . . . . . 104

4.3.6.2 Utilidade do Sistema . . . . . . . . . . . . . . . . . . 106

4.3.6.3 Qualidade da Informao . . . . . . . . . . . . . . . 106

4.3.6.4 Qualidade da Interface . . . . . . . . . . . . . . . . . 107

4.4 Ameaas Validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.5 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5 Concluses e Trabalhos Futuros 1115.1 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

5.2 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Referncias 115

Apndice 120

A Manual de Usurio da Ferramenta BVCCoN-Tool 123A.1 Criao de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

B Avaliao da Usabilidade da Ferramenta BVCCoN-Tool - Tarefa do Usurio141

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

25

1Introduo

Este captulo apresenta a motivao e os objetivos para a realizao deste estudo, alm deapresentar a estrutra da dissertao.

1.1 Motivao e Justificativa

Os processos esto se tornando cada vez mais complexos e heterogneos, inseridos emambientes onde as mudanas so constantes, sendo influenciados por fatores geogrficos,climticos, 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 atravs da capacidade depercepo contnua do ambiente do processo e decises baseadas no controle do processo[47].

Processos de negcio dinmicos so aqueles capazes de se adaptar a novas situaes.Essas novas situaes so impostas pelo ambiente em que o processo est inserido,afetando a maneira como os processos so realizados [42]. Para que os processos denegcios sejam flexveis s mudanas no ambiente organizacional, necessrio lidar coma variabilidade de processos [49]. A variabilidade de processos representa a modelagemde caminhos alternativos que podem ser realizados para executar determinada atividade.Tambm pode incluir informaes como: os recursos necessrios e o responsvel pelaexecuo da atividade [27].

Considerar a qualidade de processos essencial em futuros sistemas de software [23].As modelagens atuais de processos de negcio capturam atividades que representamaspectos funcionais de um sistema de informao. Enquanto os requisitos ditos dequalidade, restries ou softgoals, os chamados Requisitos No-Funcionais (RNFs),no so capturados, pois o foco, na modelagem de processos de negcio tem sido no

26

comportamento funcional [53] [39]. Os RNFs so importantes para as organizaes,uma vez que esto relacionados a aspectos de restrio e qualidade, tais como tempo deexecuo, segurana, usabilidade, manutenabilidade e confiabilidade.

Baseado na grande importncia de RNFs e contexto em modelos de processos denegcio, Santos [47] prope uma abordagem de configurao de processos que tem comoobjetivo oferecer suporte sua configurao baseada em RNFs e informaes contextuais.A abordagem possui trs perspectivas na configurao de processo de negcio: a descriode variabilidade, os Requisitos No-Funcionais e o contexto [47].

A primeira perspectiva tem como foco a descrio da variabilidade de modelos deprocessos de negcio e os mecanismos necessrios para lidar com isto. Na segundaperspectiva, utilizado RNFs para representar qualidades dos modelos de processosde negcio. Esta perspectiva aborda as preferncias e interferncias de atributos dequalidade nos modelos de processos. A perspectiva de contexto incorpora as influnciasdo ambiente no modelo de processo. Atravs da associao de informaes monitorveisaos modelos de processos, possvel oferecer capacidade de adaptao aos mesmos parapossveis mudanas de ambiente.

Contudo, a abordagem de Santos [47] complexa, envolvendo modelos de processosde negcio, de requisitos no-funcionais e de informaes contextuais que esto inter-ligados, ou seja, existe uma dependncia entre esses modelos. O usurio necessita tercomo produto destas fases, modelos que os represente. A falta de uma ferramenta, queauxilie o usurio a realizar as etapas de modelagem, torna o processo mais lento, difcilde entender e mais propenso a erros.

Com o propsito de solucionar estes problemas, o presente trabalho prope a es-pecificao e o desenvolvimento de uma ferramenta que integre os diferentes modelos.Assim, deseja-se obter como produto final, uma ferramenta de modelagem que ofereamais velocidade na execuo do processo de modelagem, que facilite a compreenso dosmodelos e que evite erros.

1.2 Objetivos da Investigao

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].

27

1.2.2 Objetivos Especficos

Para alcanar o objetivo geral deste estudo, os seguintes objetivos especficos foramdefinidos:

Planejar e executar uma reviso sistemtica da literatura sobre requisitos no-funcionais, informaes contextuais e modelos de processos de negcio;

Desenvolver o metamodelo para a BVCCoN-Tool;

Implementar a ferramenta de modelagem para a configurao de processos denegcio dinmicos;

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

Definir, planejar, executar e interpretar uma avaliao de usabilidade com usuriosreais.

1.3 Estrutura da Dissertao

O restante desta dissertao est organizada da seguinte maneira: Captulo 2 apresenta obackground necessrio para a compreenso deste trabalho. Neste captulo, so descri-tas as etapas da abordagem BVCCoN, trabalhos relacionados, tambm so discutidosmetamodelagem e apresentadas as tecnologias utilizadas para o desenvolvimento daferramenta; Captulo 3 descreve a ferramenta proposta, incluindo o metamodelo e asetapas de desenvolvimento; Captulo 4 apresenta um exemplo de uso e tambm umaavaliao de usabilidade da ferramenta proposta; Por fim, captulo 5 oferece um conjuntode concluses discutindo nossas contribuies e diretrizes para trabalhos futuros.

29

2Fundamentao Terica e Trabalhos

Relacionados

Neste captulo, apresentamos o background necessrio para a compreenso do trabalhoproposto. importante ressaltar que no o objetivo desta seo descrever todas asinformaes necessrias para a execuo da abordagem BVCCoN, mas sim, apresentarde forma sucinta as etapas da abordagem. Para conhecimento de todo o processo e formade execuo da BVCCoN, consultar [48]. Tambm discutimos meta-modelagem e oframework Epsilon [12], que foi utilizado no desenvolvimento deste trabalho.

2.1 Reviso Sistemtica da Literatura

Em [40], realizamos uma reviso sistemtica da literatura com o intuito de identificarcomo os requisitos no-funcionais e as informaes contextuais so representados nosmodelos de processos de negcios. 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 tambmrealizamos um mapeamento entre os tipos de representao de RNF e seus determinadosautores. Ao final desta primeira anlise 8 trabalhos utilizaram a notao BPMN, 2 usaramdigrama de atividades, 2 fizeram uso da modelagem de processos de negcio orientadaa objetivos e apenas 1 trabalho usou a notao Stock and Flow Diagrams. A Tabela2.1 exibe o mapeamento entre os tipos de representao de RNFs e seus determinadosautores.

30

Tabela 2.1 Relao entre o tipo de representao de RNF e trabalhos selecionados [40].

Tipo de Representao | Trabalhos Selecionados [B

arto

nili,

2012

]

[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 Associao textual entre RNF e elementos do modelo Extenso da notao BPMN com criao de artefatos Representao externa do RNF ao modelo de negcio

Criao de smbolos para representar os RNFs NFR Framework ou derivados

Analisando a Tabela 2.1 percebe-se que o maior tipo de representao de RNF sed anotando elementos de um modelo com o nome do RNF, 4 dos 13 trabalhos adotameste tipo de representao. Em seguida, 3 trabalhos representam os RNFs atravs dacriao de smbolos para represent-los. Um empate ocorre entre aqueles que fazemassociao textual entre RNF e elementos do modelo e os que utilizam o NFRFrameworkpara representar RNF, cada um com 2 trabalhos. Por fim, encontra-se 1 trabalho queprope a criao de novos artefatos e um outro que representa os RNFs externamente aomodelo de negcio.

Analisando os trabalhos referentes s informaes 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 estratgiasde adaptao de processos de negcio. A Tabela 2.2 apresenta a sumarizao desses itens.

Tabela 2.2 Sumarizao 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 Contribuio - Abordagem Tipo de Contribuio - Framework

Ferramentas de Suporte Testes da Abordagem/Framework Discute Estratgias de Adaptao

Para fins de contagem, consideramos apenas os itens "Ferramenta de Suporte", "Testesda Abordagem/Framework"e "Discute Estratgias de Adaptao". Portanto, analisando aTabela 2.2, identificamos que 1 trabalho cobre os 3 itens citados anteriormente, 1 trabalho

31discute ferramenta de suporte e estratgias de adaptao, 1 trabalho trata de estratgiasde adaptao e 9 trabalhos realizam testes da abordagem/framework.

Durante o processo de extrao dos dados e anlise dos resultados, encontramos aabordagem BVCCoN. Esta foi a nica abordagem que foi classificada tanto na anlisedos requisitos no-funcionais quanto na de informao contextual. Portanto, BVCCoN uma abordagem de configurao de processos de negcios que leva em consideraoRNFs e contexto no momento de realizar configuraes. Informaes de contexto soimportantes para obter flexibilidade e requisitos de qualidade segundo Saeedi [45], so ocaminho para alcanar performance e satisfao dos clientes.

Esta abordagem representa os RNF externamente ao modelo de negcio atravs doNFRFramework. Uma vez definido os RNFs, os mesmos so ligados s variantes doprocesso. Quanto s informaes de contexto, a abordagem utiliza um conjunto de regraspara montar as informaes contextuais e no possui uma ferramenta que apoie estasconstrues, assim como, tambm no possui uma ferramenta que realize a representaodos RNFs. Estas informaes obtidas da reviso sistemtica fortalece a inexistncia deuma ferramenta que apoie as fases de modelagem da abordagem, tornando o processomais lento, difcil de entender e mais propenso a erros. A seo seguinte descreve asetapas da abordagem.

2.2 BVCCoN - Business Process Configuration with NFRsand Context-Awareness

A BVCCoN [48] uma abordagem que visa a configurao de processos de negcioutilizando requisitos no-funcionais e informaes contextuais. A abordagem compostade cinco atividades: Elicitar Variabilidade, Descrever Variabilidade, Analisar Contexto,Ligar RNFs & Variantes e Realizar Configurao. As primeiras quatro etapas so realiza-das em design time (ver Figura 2.1). Enquanto a ltima etapa, Realizar Configurao realizada em runtime. Nossa ferramenta de modelagem cobre as atividades DescreverVariabilidade, Analisar Contexto e Ligar RNF & Variantes da abordagem. Para executara atividade Elicitar Variabilidade, no necessrio a utilizao de uma ferramenta demodelagem, mas sim uma anlise em cima dos elementos do modelo de negcio emBPMN. Nas prximas subsees so detalhadas as etapas do processo da abordagemBVCCoN apresentado na Figura 2.1.

32

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

2.2.1 Elicitao da Variabilidade

Esta primeira etapa responsvel por identificar e descobrir possveis variaes em ummodelo de processo de negcio. O objetivo descobrir diferentes maneiras de executarum processo, bem como os efeitos da incluso, mudana ou excluso de elementosdo modelo. Possui como entrada um processo de negcio inicial e como sada todainformao sobre variabilidade elicitada.

Para realizar esta atividade, utilizado o information analysis framework [32] queexplora diferentes caractersticas da informao e obtm 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 informaes 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 so os objetos consumidos ou produzidos pela tarefa?)

Extenso (At que ponto a tarefa ser executada?)

2.2.2 Descrio da Variabilidade

Por meio da elicitao de variabilidade, possvel analis-la com o intuito de identificaro que pode ser modelado como pontos de variaes e variantes. A partir desta seo,o modelo BVCCoN comea a ser construdo incrementalmente por meio das prximassees. Para ilustrar um exemplo, estamos utilizando um processo de emergncia quanto

33a existncia de fogo. Este processo um caso clssico de um sistema scio-tcnico ondesoftware e humanos devem executar com segurana (ver Figura 2.2).

O processo iniciado com a procura por fumaa ou fogo, caso identificado umadessas situaes, verificado o risco. Caso o risco no seja real, o processo finalizado,porm, se o perigo for real, inicia-se a tarefa de resgatar as pessoas em perigo, seguidapor tocar alarme de incndio, ligar para os servios de segurana pblica, abrir sadasde emergncia e Evacuar o prdio imediatamente.

Pontos de variaes so pontos de mudanas definidos no modelo de processo denegcio que podem representar caminhos alternativos ou variveis de realizar atividadesno processo. Para definir os pontos de variao, necessrio receber como entrada omodelo referncia de processo de negcio e a informao elicitada. Baseado nesta entrada,o analista define o que ser marcado como ponto de variao e quais tarefas faro partedo ponto de variao. O analista tambm deve definir onde o ponto de variao comea(begins) e termina (ends). A sada destas atividades o modelo referncia de processomarcado com os pontos de variaes. Esta sada faz parte do processo de descrio devariabilidade.

A Figura 2.2 exibe um possvel modelo de referncia com os pontos de variaes.Quatro pontos de variaes foram identificados: PV1 associado a tarefa Procurar porfumaa ou fogo, PV2 relacionado a tarefa Tocar alarme de incndio, PV3 corresponde atarefa Ligar para os servios de segurana pblica e PV4 est ligado a tarefa Abrir sadasde emergncia. Aps definir os pontos de variaes e selecionar onde eles comeam eterminam, a prximo passo definir os elementos que sero parte das variantes.

As informaes adquiridas durante a elicitao e os pontos de variao definidos ante-riormente so entradas para a definio de variantes. Variantes so objetos de mudanas,representando caminhos alternativos ou variveis, ou seja, como as atividades do processopodem ser realizadas. Desta maneira, as variantes esto associadas a fragmentos deprocessos BPMN que iro expressar a maneira como um processo pode ser alterado parase adaptar a uma nova configurao de ambiente. Assim como os pontos de variaes, asvariantes tambm so identificadas por um analista.

No exemplo de emergncia de fogo, foram identificadas variantes que esto associadasao tipo de agente que executar algumas tarefas. Na tarefa Procurar por fogo e fumaa, possvel visualizar este caso, no qual a tarefa pode ser executada por uma pessoa ou umsensor. A descrio de variabilidade tambm pode afetar o comportamento das tarefas.Os padres de work-flow descrevem comportamentos de atividades quando associadas aum ponto de variao. No modelo BVCCoN, a utilizao de padres work-flow ajuda

34

Figura 2.2 Exemplo de modelo referncia com pontos de variao. Adaptado de [48].

a descrever como combinar as variantes e os pontos de variaes, ou seja, os padresdescrevem como os elementos (neste caso BPMN) sero agrupados [52].

Os padres bsicos so sequence, parallel split, synchronization, exclusive choice esimple merge. O padro sequence aquele em que as tarefas so executas em sequencia, oparallel split as tarefas so executas em paralelo, o padro 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 padro Exclusive Choice dado um conjunto de tarefas, mas apenas uma executada, por fim, no padro Merge dado um conjunto de tarefas em que apenas uma precisa ser executada para que o fluxodo processo seja continuado.

O prximo passo associar os pontos de variaes s variantes. Nesta etapa, necessrio definir algum operador lgico no ponto de variao para indicar como asvariantes estaro associadas. Na abordagem BVCCoN, utilizado os termos AND, OR eXOR. Estes operadores podem influenciar os padres de work-flow que esto associadoss variantes. Por exemplo, um operador AND permite incluir como soluo os padres

35sequence e parallel split/synchronization.

A Figura 2.3 exibe as variantes associadas com seus respectivos pontos de variaes.O ponto de variao VP1 possui duas variantes, var1 e var2, que so Procurar por fogo oufumaa automaticamente e Procurar por fogo ou fumaa pessoalmente respectivamente.Cada variante est associada a uma tarefa BPMN, var1 est associada com a tarefaProcurar por fogo ou fumaa automaticamente e var2 com a tarefa Procurar por fogoou fumaa. Os pontos de variaes VP2, VP3 e VP4 tambm esto associados com suasrespectivas variantes e as variantes com as tarefas BPMN. Aps concluir esta etapa, oprximo passo executar a anlise de contexto.

36

Figura 2.3 Exemplo de variantes e pontos de variao. Adaptado de [48].

37

2.2.3 Anlise 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 negcio analisadopara identificar os contextos que podem afetar o modelo. Analisando o domnio, oscontextos podem ser identificados. Estados de sistemas e tambm usurios podem serdescritos como contexto. O contexto pode descrever:

O que est acontecendo?

Onde eles esto localizados?

Quais so os recursos disponveis para uso?

O contexto pode ser analisado atravs de um conjunto de fatos e statements que estoconectados [2]. Fatos podem ser avaliados, j os statements no. Para que um statementassuma um valor verdadeiro, deve existir um conjunto suficiente de evidncias que realizea comprovao. Essas evidncias so encontradas por meio das avaliaes dos fatos [5].A decomposio termina quando possvel descrever todas as variveis que permitemverificar se o contexto foi ativado. O objetivo obter uma frmula de fatos apoiados porvariveis monitorveis. Os seis passos abaixo so 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 execuo do fragmento de processo de negcio deuma variante;

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

4. Associar as variveis monitorveis aos fatos;

5. Validar a interferncia com outros contextos;

6. Repetir os passos para outras variantes.

A Figura 2.4 exibe um exemplo de decomposio de contexto. Por exemplo, ocontexto Bombeiros serem chamados automaticamente apoiado por trs fatos: Alarmede fogo est ativo, Fogo foi confirmado, e Servios de rede est funcionando. Quando asvariveis que esto 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.

38

Figura 2.4 Exemplo de decomposio de contexto. Adaptado de [48].

2.2.4 Ligar Variantes & RNF

Na abordagem BVCCoN, os requisitos no-funcionais so utilizados para representar aspreferncias dos stakeholders. Nesta etapa, os RNFs que so importantes para o processoso identificados e tambm definido o impacto de cada variante sobre os RNFs. Assim,os RNFs so ligados s variantes do processo de negcio que foram levantadas nos passosanteriores da abordagem.

Os RNFs que sero levados em considerao so identificados e ento feito umadescrio dos RNFs e variantes. Essa elicitao pode ser realizada entrevistando pessoasque esto envolvidas no processo de negcio. Em seguida, pode-se associar os RNFs comas variantes para representar as preferncias dos stakeholders sobre a seleo de possveisvariantes. RNFs representaro atributos de qualidade que os stakeholders esperam dosistema.

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

39A Figura 2.5 mostra uma verso simplificada de um modelo BVCCoN. As variantes

Tocar alarme de fogo manualmente e Tocar alarme de fogo automaticamente fazem partedo ponto de variao VP2, que possui o operador lgico XOR. Este operador lgico indicaque apenas uma das variantes pode ser selecionada. A variante Tocar alarme de fogoautomaticamente est relacionada com o contexto Servios de backup esto funcionando,assim, esta variante s poder ser selecionada se o contexto for verdadeiro. A Tabela2.3 apresenta as contribuies da Figura 2.5, permitindo uma melhor visualizao. Osespaos em branco so compreendidos como EqualContribution (=).

40

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

41

Tabela 2.3 Contribuio para os RNFs Confiana e PerformanceVariante/RNF Confiana PerformanceProcurar por fogo ou fumaa automaticamente ++Procurar por fogo ou fumaa pessoalmente ++ -Tocar alarme de fogo manualmente + -Tocar alarme de fogo automaticamente ++Chamar os servios de segurana pblica automaticamente ++Chamar os servios de segurana pblica por linha telefnica -Chamar os servios de segurana pblica por telefone mvel + +Abrir sadas de emergncia manualmente ++Abrir sadas de emergncia automaticamente ++

2.2.5 Realizar a Configurao

Existem duas maneiras de executar a configurao de um processo de negcio: a primeira selecionando as variantes e a segunda priorizando algum requisito no-funcional.Existem diversas maneiras de analisar o impacto de cada configurao sobre os RNFs,por exemplo: anlise top-down e bottom-up.

A top-down feita selecionando um RNF que ter maior prioridade, e em seguida,derivado uma configurao de processo que maximiza o RNF selecionado. Ou seja, cadaponto de variao avaliado para identificar a variante que melhor se ajusta ao requisitono-funcional selecionado.

Na anlise bottom-up, uma configurao de processo definida selecionando umsub-conjunto de variantes e ento, uma matriz de ligao utilizada para calcular oimpacto da configurao sobre o requisito no-funcional. A Figura 2.6 apresenta umasoluo de um processo priorizando o RNF Performance.

Para descrever os conceitos de ponto de variao, variantes, requisitos no-funcionaise informaes contextuais, utilizado um mecanismo chamado de metamodelagem.Assim, atravs de um metamodelo, possvel definir os elementos de modelagem e seusrespectivos relacionamentos [4].

2.2.6 Trabalhos Relacionados

A seguir, apresentamos uma comparao entre estudos que descrevem abordagens deconfigurao de modelos de processos de negcio em ambientes dinmicos descritos naliteratura.

Trabalhos IdentificadosQuestionnaire based variability modeling for system configuration

42

Figura 2.6 Exemplo de uma instncia de processo. Adaptado de [48].

La Rosa [28] props uma abordagem para capturar variabilidade de sistemas baseadaem modelos de questionrio. Ela apoia a configurao com um processo e um modelo dequestionrio. O modelo de questionrio consiste de um grfico que define as questes aserem respondidas. Questes so respondidas em sequencia, lidando para a identificaode aes que so realizadas pela configurao.

Os modelos de processos so representados por modelos de processos configurveisescritos em Configurable Yet Another Workflow Language (C-YAWL). Esta linguagem uma extenso que possui a caracterstica de descrever os pontos de variao do processodentro do modelo de processo. O modelo de processo com a informao de variabilidadeest alinhado com o modelo de questionrio. A configurao do processo realizada pelousurio respondendo questes 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 denegcio com modelos de Goal. Modelos de Goal so usados para descrever os objetivosdo negcio e as preferncias dos usurios. Atravs da decomposio dos modelos, possvel obter uma estrutura de goals [objetivos] do processo de negcio. O modelo degoals segue uma estrutura em formato de rvore na qual os goals so decompostos emsubgoals.

A descrio da informao de variabilidade adicionada a estrutura do modelode goals. Por isso, as informaes do processo est misturado com anotaes. Asanotaes que descrevem variabilidade so baseadas em IF-THEN-ELSE, regras assimcomo os operadores lgicos (AND, OR). Os requisitos no-funcionais so descritos comoSoftgoals e as contribuies para Softgoals representam as preferncias dos usurios sobre

43possveis escolhas. Os pontos de variao so os lugares onde existe uma decomposioOR. Com o objetivo de obter um modelo de fluxo de processo, eles descrevem os passosdo comeo da configurao com uma anlise de Softgoal e seleo de variantes. Aps aseleo, uma transformao gera o modelo de fluxo do processo em BPEL.

Business processes contextualisation via context analysis

De La Vara et al. (2010) [5] props uma metodologia para adicionar contextualizaoaos modelos de processos de negcio. A proposta obter modelos de processos denegcio que so perceptveis ao contexto. A metodologia descreve vrios passos einclui anotaes de contexto que baseada na abordagem de [2], que apoia anlisecontextual. Os contextos consistem de rvores com facts e statements que so avaliadospara identificar quando um contexto est ativo.

As informaes contextuais so requeridas para ativar mudanas no fluxo dos pro-cessos. Com o objetivo de incluir contexto, eles estenderam a notao BPMN para tercontextos embarcados nos fluxos de sequncia que ligam as atividades. A descrio davariabilidade adicionada ao modelo de processo, onde o caminho alternativo no fluxodo trabalho representa as variantes.

Discusso

As abordagens de configurao de processos de negcio so complexas e consomemmuito esforo e tempo. A abordagem BVCCoN integra metamodelos de anlise realizadosdurante os passos do processo BVCCoN, que foca em uma clara separao 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 variao e variantesj esto definidos. Isto reduz a anlise de contexto para apenas contextos relevantes,evitando problemas com a cobertura do modelo de processo e reduzindo a anlise decontexto que no ser utilizada.

Quando comparado com a abordagem proposta por Lapouchnian et al. (2007) [29],podemos ver que a integrao de metamodelos tambm uma vantagem. Observe que emBVCCoN, a anlise de requisitos realizada independemente da anlise de variabilidade.Durante a construo do modelo BVCCoN, a anlise de contribuio estabelece ligaesentre variantes e RNFs. Por isso, a anlise de preferncias pode ser refeita se uma variante adicionada ou removida. Ao contrrio, a abordagem proposta por Lapouchnian et al.(2007) mistura as informaes de processo com a descrio de variabilidade e softgoals.Quando uma variante adicionada ou removida, todo o modelo deve ser revisado.

Diferente das outras duas abordagens, La Rosa [28] props compartilhar menos,similar a BVCCoN. utilizado diferentes estratgias para lidar com variabilidade e confi-

44

gurao. Por esta razo, La Rosa foca na reduo da interveno do usurio na realizaoda configurao, a abordagem BVCCoN tenta reduzir a necessidade da interao com ousurio durante os passos da configurao.

Algumas abordagens apresentaram ferramenta de suporte, porm, os benefciospodem ser limitados devido a abrangncia da ferramenta em relao as etapas das abor-dagens. A comparao foi baseada na avaliao de documentos, assim, as ferramentasde suporte no foram avaliadas. Mesmo compartilhando algumas caractersticas emcomum com as outras abordagens, a BVCCoN mostra mais vantagens que desvantagensquando considerado o cenrio da configurao de processos dinmicos. BVCCoN umaabordagem mais completa, sua ferramenta permite modelar diferentes perspectivas relaci-onadas aos processos de negcio (requisitos no-funcionais, variabilidade e informaesde 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 sumrio das abordagens em relao aos critrios discutidosanteriormente.

Tabela 2.4 Sumrio de CritriosAbordagem Variabilidade Configurao Modelo de Processo FerramentaLa Rosa (2009) C-YAWL/YAWL Seleo de Ns Questionrio e C-YAWL SimLapouchnian et al. (2007) Modelo de Goals/BPEL Transformao de modelos Modelo de goals SimDe La Vara et al. (2010) BPMN estendido Validao de contexto Modelo BPMN NoBVCCoN BPMN Transformao de modelos Modelo BVCCoN Sim

2.3 Meta-Modelagem

A meta-meta-modelagem responsvel por definir uma linguagem para a especificaode metamodelos. A Object Management Group (OMG) definiu uma linguagem paraa especificao de metamodelo denominada Meta Object Facility (MOF) [37]. Estalinguagem oferece um framework para o gerenciamento de metadados e um conjunto deservios 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 manipulao demetadados [37].

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

1XMI um formato de intercmbio amplamente utilizado para o compartilhamento de modelos usandoXML [38].

45

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

divida por modelos. Cada modelo (exceto o M3) caracterizado como uma instncia donvel acima.

O nvel mais baixo, M0, responsvel por manipular os dados de usurio. Dadosreais em que softwares so projetados para manipular. O nvel M1 representa o prpriomodelo, ou seja, designado para manipular um modelo dos dados de usurio M0. Oprximo nvel, M2, conhecido como metamodelo por ser um modelo de modelo. M2 um modelo que mantm informaes do modelo M1. Por ltimo, M3 um modelo deinformaes em M2, e por isso chamado de meta-metamodelo [3].

Neste estudo, proposto o desenvolvimento de um metamodelo (nvel M2) para aferramenta proposta. Sendo possvel assim, gerar os nveis M1 e M0. O metamodeloa ser desenvolvido, ser construdo utilizando a tecnologia da UML, que revisada naprxima seo.

2.3.1 UML - Unified Modeling Language

A UML uma linguagem de modelagem proposta pela OMG, a qual uma das maisusadas para especificao, construo e documentao de artefatos de software. umalinguagem de modelagem de propsito geral, e pode ser usada para todos os domniosde aplicaes como sade, espao areo e telecomunicaes. Contudo, podem existirsituaes em que uma linguagem de um propsito to geral e amplo no seja apropri-ado para a modelagem de aplicaes de um domnio especfico. Isto pode acontecerquando queremos expressar conceitos especficos de um determinado domnio, ou quando

46

queremos restringir ou customizar alguns dos elementos da UML.

A OMG discute duas abordagens possveis para definir uma linguagem especficade domnio. A primeira a criao de uma nova linguagem baseada nos mecanismosoferecidos pela prpria OMG para definio de linguagens visuais. Assim, sintaxe esemntica dos elementos da nova linguagem precisam ser definidos de acordo com ascaractersticas do domnio [20].

A segunda alternativa se concentra na especializao da UML. Alguns elementosda linguagem so especializados, impondo novas restries sobre eles em relao aometamodelo UML. A semntica dos elementos UML no alterada (as propriedades deuma classe UML, associaes, atributos, etc, sero os mesmos). Um profile em UMLoferece mecanismos de extenses genricos para a customizao de modelos UML paradomnios e plataformas particulares. Profiles so definidos utilizando stereotypes, tagdefinitions e constraints [20].

Stereotypes: so definidos por um nome e um conjunto de elementos do metamo-delo que so anexados;

Constraints: podem estar associadas a esteretipos, impondo restries 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, necessrio construir uma linguagem de modelagem especfica dedomnio para a abordagem BVCCoN.

2.3.2 DSML - Linguagem para Modelagem Especfica de Domnio

Quando tratamos de um domnio especfico, as linguagens de modelagem, como porexemplo, UML, BPMN e i*, podem no conter todos os elementos necessrios pararealizar a modelagem. Assim, pode ser til a criao de uma linguagem especfica dedomnio, (do ingls DSL - Domain Specific Language) para descrever com maioresdetalhes as caractersticas mais importantes de um domnio especfico.

Uma DSL uma linguagem que est direcionada em um domnio particular deproblema, oferecendo um conjunto restrito de notaes e abstraes apropriadas. Contudo,as DSLs contm uma linguagem de propsito geral (do ingls, GPL - General Purpose

47Language) incorporada como uma sub-linguagem. Assim, oferecem um poder expressivoespecfico do domnio em conjunto com o poder de expressividade de uma GPL [51].

Isto acontece quando DSLs so implementadas como linguagens embarcadas. Por-tanto, quando no desejado criar uma linguagem de programao, melhor herdartoda infraestrutura de alguma outra linguagem, adequando-a em formas especiais para odomnio de interesse. Assim, possvel adquirir uma Linguagem Embarcada Especficade domnio (do ingls, DSEL - Domain Specific Embedded Language) [22].

J uma Linguagem para Modelagem Especfica de Domnio (do ingls, DSML -Domain Specific Modeling Languages) objetiva elevar o nvel de abstrao, especificandoa soluo em uma linguagem que usa diretamente os conceitos e regras de um domniode problema especfico. A ideia modelar produtos de software utilizando DSL e gerarprodutos finais em uma linguagem de programao escolhida ou em outras formas, comotexto, modelo, cdigo, a partir das especificaes de alto nvel que foram definidas [24].

As DSLs so classificadas como interna, externa e no textuais. Uma DSL interna aquela que usa toda infraestrutura de uma linguagem de programao existente paraconstruir semnticas especfica de domnio sobre a mesma. Uma das mais popularesDSL interna Rails [44], que implementada em cima da linguagem de programaoRuby [43]. Escrevendo cdigo Rails a mesma coisa que programar em Ruby, s queutilizando a semntica que Rails implementa para o desenvolvimento de aplicaes web[21].

Uma DSL externa aquela que desenvolvida similar implementao de umanova linguagem de programao, possuindo sua prpria sintaxe e semntica. Uma DSLnecessita ser uma representao do domnio, mas isto no implica que sua representaoprecisa ser apenas textual. DSL no textual aquela que pode modelar o domnioutilizando formas grficas [21]. Nesta dissertao foram utilizados formas grficas paramodelar o domnio da configurao de processos de negcio dinmicos.

Para definir uma DSL, necessrio desenvolver uma sintaxe concreta e abstrata,seguida de uma semntica projetada para definir o significado da linguagem. Umasintaxe abstrata de uma linguagem definida a partir do mtodo de meta-modelagem. Istosimplifica o desenvolvimento da linguagem, permitindo aos designers mapear diretamenteas classes da anlise de domnio para classes no metamodelo, associaes e herana queso parte da definio da DSL.

A sintaxe abstrata descreve os conceitos da linguagem, as relaes entre eles eas regras de estruturao que restringem a combinao de elementos do modelo deacordo com as regras de domnio. A partir do metamodelo, construda a sintaxe

48

concreta. Ela especifica como os conceitos de domnio includos no metamodelo sorepresentados, e geralmente definido por um mapeamento entre o metamodelo e umanotao textual ou grfica [26]. Durante o desenvolvimento da ferramenta, identificamosincompatibilidade entre sintaxe concreta e abstrata, portanto, realizamos alteraesnecessrias para solucionar o problema. Uma vez definido a linguagem especfica dedomnio, foi necessrio utilizar tecnologias para o desenvolvimento da ferramenta.

2.4 Tecnologias

Esta seo responsvel 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 implementaes de padres encontrados nacomunidade Eclipse [11].

Dentre os frameworks de modelagem, destaca-se o EMF (Eclipse Modeling Fra-mework) [10], que auxilia a especificao de metamodelos e prov funcionalidades para agerao automtica do cdigo Java respectivo, o GMF (Graphical Modeling Framework)[15], que uma abordagem model-driven para o desenvolvimento de editores grficosbaseados no eclipse e o Epsilon [12], [7], que uma famlia de linguagens e ferramentasdestinadas atividades de gerenciamento de metamodelos.

2.4.1 Eclipse Modeling Framework

O projeto EMF um framework de modelagem e gerao de cdigo para a construo deferramentas baseado em um modelo de dados estruturado (modelo de domnio). A partirde um modelo de domnio especificado em XMI ou em outro formato suportado, o EMFfornece ferramentas e suporte runtime produo de classes Java que implementam essemodelo. Assim como um conjunto de classes adapter que permite a edio e visualizaodo modelo atravs de cdigo Java, e um editor bsico.

O EMF composto de 3 peas 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 genricas reusveis para a construo deeditores para modelos EMF, e por ltimo, 3) EMF.Codegen, responsvel por gerar todocdigo necessrio 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,

49utilizado para descrever associaes entre classes; e EEnum, usado para descrever enume-raes. EMF possui trs nveis de gerao de cdigo: 1) Modelo, oferece interface Java eimplementao de classes para todas as classes descritas no metamodelo da ferramentaCASE a ser construda, 2) Adaptadores, capazes de gerar classes de implementao queadaptam as metaclasses do modelo para visualizao e edio, 3) Editor, produz umaestrutura do modelo que poder ser visualizada na fase de criao do editor grfico [1].

2.4.2 Graphical Modeling Framework

GMF um framework para a construo de editores grficos a partir de metamodelosbaseado em EMF. Para a construo de editores grficos utilizando o GMF, necessrioseguir um processo bem definido. Para facilitar a execuo 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 gerao de um editor grfico GMF consiste na criao e manipulao de algunsarquivos.

1. Domain Model - representa o metamodelo utilizado para criar o editor grfico. necessrio importar o metamodelo de domnio definido em Ecore;

2. Domain GenModel - arquivo .genmodel usado para gerar cdigo do domain model;

3. Graphical Def Model - arquivo .gmfgraph responsvel por definir os elementosgrficos que representaro cada um dos objetos que foram definidos no arquivoEcore do Domain Model.

50

4. Tooling Def Model - arquivo com terminao .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 grfico e aoselementos do modelo ferramental.

6. Diagram Editor GenModel - o GMF fornece um modelo de gerador para gerar ocdigo executvel do editor grfico.

2.4.3 Epsilon

Epsilon uma famlia de linguagens e ferramentas destinadas atividades de gerencia-mento de metamodelos. Essas atividades so: gerao de cdigo, transformao modelopara modelo, validao de modelo, comparao, migrao e refactoring de modelos [12].Dentre as linguagens e ferramentas da famlia 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 gerao de editores grficos em GMF,diminuindo a complexidade imposta pelo mesmo [13]. EuGENia gera ferramentasgrficas a partir de um metamodelo Ecore com anotaes 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, enumeraes, 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, possvel gerar um modelo Ecore (arquivo .ecore),

51o inverso tambm possvel. A partir do metamodelo .emf construdo, necessrioenriquec-lo com anotaes em EuGENia, que definir os artefatos concretos a serrepresentado no editor grfico. Assim, possvel definir em Emfatic quais metaclasses sons ou links, definir a figura (retngulo, elipse) de um n que sero 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 verso anotada do metamodelo. Em particular, asanotaes representam o seguinte:

Linha 5: o elemento diagram representa o objeto raiz do metamodelo. Apenas umaEclass no 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 (associao) entre seus arquivossource e target. A representao grfica do link atravs de uma linha pontilhada;

Linha 31: cada arquivo representado no diagrama como um retngulo 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 ;

52

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 inmeras anotaes alm das que foram exibidas na Listagem 2.1. Em [14], apresentado a listagem completa de todas as anotaes que o Eugenia oferece paraserem inseridas em um modelo que foi criado utilizando a linguagem Emfatic.

EOL uma linguagem de programao imperativa para criar, consultar e modificarmodelos EMF. Fornece caractersticas imperativas habituais como presena de variveis,comandos sequenciais, estruturas de controle e de desvio condicional, alm de outrascaractersticas. Outras linguagens da famlia Epsilon como EVL, podem incorporarpores cdigo EOL em suas estruturas de cdigo [7].

EVL uma linguagem de validao que pode ser utilizada para adicionar validaese fazer pequenos ajustes no editor grfico GMF [18]. As restries em EVL so similaress OCL2, porm, EVL suporta dependncia entre constraints (se uma constraint A falha,a constraint B no ser avaliada). Mensagens de erro customizadas podem ser exibidasaos usurios e um mecanismo de conserto pode ser ativado pelos usurios para repararinconsistncias[7].

Em EVL, as especificaes de validao so organizadas em mdulos. A Listagem2.2 exibe um trecho de cdigo escrito em EVL e os itens abaixo apresentam os mdulosEVL. Em seguida, indicado as linhas da Listagem 2.2 em que determinado mduloaparece.

Context - um contexto especifica o tipo de instncia que as invariantes sero2OCL uma linguagem formal utilizada para descrever expresses sobre modelos UML [35]

53aplicadas (Linhas 1 e 8);

Invariant - cada invariante EVL define um nome e uma verificao (check). Umainvariante tambm pode definir uma mensagem que ser exibida ao usurio casoalguma restrio falhe. Para apoiar o conserto semiautomtico de elementos, umainvariante pode definir um nmero de fix (Linhas 4 e 12);

Guard - Guards so usados para limitar a aplicabilidade de invariantes. Um guardlimita a aplicabilidade de todas as invariantes do contexto, enquanto a nvel deinvariant, guard limita a aplicabilidade de uma invariante especfica (Linha 10);

Fix - Fix determina aes a serem realizadas para corrigir uma inconsistncia. Aparte de cdigo "do"encontrada na Listagem 2.2, definida usando a linguagemEOL e responsvel pela correo da funcionalidade;

Constraint - Constraints so usadas para capturar erros crticos que invalidam omodelo (Linha 2);

Critique - ao contrrio de constraints, critiques so usadas para capturar situaesque no invalidam o modelo, mas que devem ser levadas em considerao pelousurio para melhorar a qualidade do modelo (Linha 9).

Pre and Post - um mdulo EVL pode definir um nmero de blocos chamados pree post que so escritos em EOL e executados antes ou depois de uma invariante seravaliada respectivamente.

Listagem 2.2 Exemplo de Cdigo 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 upperc a s e l e t t e r

54

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 transformaes de modelos (model-to-model).Mais especificamente, ETL pode ser usado para transformar um nmero arbitrrio de mo-delos de entrada para um nmero arbitrrio de modelos de sada de diferentes linguagensde modelagem e tecnologias em um alto nvel de abstrao [17]. EGL uma linguagemmodel-to-text. A partir de um metamodelo construdo em Ecore, pode-se obter cdigoexecutvel, relatrios HTML, documentao, imagens (usando pontos) e outros artefatostextuais [25] [7].

Transformaes de atualizao so aes que automaticamente cria, atualiza oudeleta elementos do modelo baseado na seleo de elementos existentes no modelo e nasinformaes fornecidas pelo usurio (atravs de dados de entrada). EWL a linguagemda famlia 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 tambm foramutilizadas nesta dissertao, como o Framework Eclipse em conjunto com os pluginsEMG/GMF e tambm o Framework Epsilon.

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

gem i*. Um novo metamodelo desenvolvido para a nova verso do i* e um processo dedesenvolvimento para obter uma ferramenta grfica de modelagem.

Para o desenvolvimento da ferramenta, foi adotado o GMF Framework, que permite amodelagem do domnio e a gerao automtica de cdigo para representar os elementosgrficos que faro parte do modelo. O metamodelo foi criado a partir do FrameworkEMF e escrito em Ecore.

A partir de um guia i* (contendo guidelines e boas prticas), o autor definiu umconjunto de restries que foram escritas utilizando a linguagem de restrio OCL. Um

55exemplo de restrio que um elemento no pode se ligar a ele mesmo. Uma segundarestrio que a utilizao do link de associao s permitida para ns do tipo ator.

Aps o desenvolvimento da ferramenta, a mesma foi aplicada em diferentes cenrios,visando exemplificar seu uso e tambm realizar uma verificao para ver se as restriesque foram definidas anteriormente estavam sendo executadas corretamente. A conclusoobtida foi que a ferramenta se comportou de maneira apropriada.

Uma Linguagem Especfica do Domnio 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 possvel guardar elementos especficos pertencentes aquela caixa. Estascaixas possuem uma caracterstica de colapso, em que a partir de um clique possvelapresentar ou omitir pores do diagrama.

A ferramenta apresentada nesta dissertao tambm possui este conceito de compar-timento. Assim, possvel esconder ou apresentar pedaos do modelo, obtendo umamelhor escalabilidade e diminuindo a complexidade visual. Visto que a capacidade decolapso facilita a leitura dos modelos.

Para projetar o editor grfico, 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 avaliao de usabilidade.

A avaliao de usabilidade consistiu de um questionamento sobre a sintaxe da lin-guagem, facilidade de utilizao da ferramenta e nveis de satisfao da ferramenta. Emgeral, os utilizadores mostraram grande aceitao da ferramenta. Ficaram satisfeitos e aacharam fcil de utilizar.

AGILE: Uma Abordagem para Gerao Automtica de Linguagens i*Em [4], o autor definiu uma abordagem automatizada para a definio estrutural de

linguagens baseadas no i* e a gerao automtica de ferramentas CASE de modelagemcorrespondentes utilizando os conceitos de linhas de produtos de software.

As tecnologias utilizadas para desenvolver uma ferramenta que automatize a definiode metamodelos de linguagens i* e a gerao automtica de editores grficos foram oEMF/GMF, baseadas no Eclipse. O autor definiu um metamodelo ncleo (escrito em

56

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

A ferramenta proposta auxilia o usurio a projetar a estrutura de uma nova linguagemi* utilizando apenas uma interface grfica, reduzindo consideravelmente alteraes ma-nuais e direta em toda estrutura GMF. Com o propsito de testar a ferramenta, o autorrealizou um estudo de caso em que foi aplicado a ferramenta AGILE Tool na criaodo metamodelo da linguagem i* Aspectual, assim como a gerao de seu editor demodelagem grfica.

Metamodeling the Enhanced Entity-Relationship ModelO estudo descrito em [19] apresenta uma viso detalhada e prtica sobre como

formalizar o modelo EER (Enhanced Entity-Relationship)3 atravs de um metamodelo.Para comprovar a viabilidade, expressividade e utilidade do metamodelo proposto, osautores desenvolveram uma ferramenta CASE e a testaram com exemplos prticos 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 tambmforam utilizadas para desenvolver a ferramenta proposta nesta dissertao. O metamodelofoi escrito em Ecore, as validaes foram implementadas em EVL e, alm disso, osautores utilizaram a linguagem EGL para transformar modelo em cdigo SQL/DDL.

2.5 Consideraes do Captulo

Nesta seo, foi apresentada a reviso sistemtica da literatura sobre requisitos no-funcionais e informaes contextuais em modelos de processos de negcio. Relatamoso processo da abordagem BVCCoN, Elicitar Variabilidade, Descrever Variabilidade,Analisar Contexto, Ligar RNF & Variantes e Realizar Configurao, 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 grficas de modelagem.

3Linguagem de modelagem padro para o projeto conceitual de banco de dados.

57

3BVCCoN Tool

Este captulo trata da especificao da ferramenta proposta, incluindo as etapas de desen-volvimento e a criao de um metamodelo para a ferramenta da abordagem BVCCoN.Sero apresentadas as 3 diferentes vises do metamodelo, uma viso referente aos Requi-sitos No-Funcionais, uma segunda viso relacionada s informaes de contexto e porltimo, ser apresentada a viso de variabilidade. Estas vises sero exibidas por meio dasintaxe abstrata e concreta da linguagem.

3.1 Modelo e Metamodelo BVCCoN

A abordagem BVCCoN cobre trs perspectivas na configurao de processos de negcio:a descrio da variabilidade, os Requisitos No-Funcionais, e as informaes de con-texto. Estas trs perspectivas e seus conceitos so descritos atravs de seus respectivosmetamodelos em [48].

Da maneira como foi dividido, torna-se invivel a construo de uma ferramenta demodelagem que suporte estes trs nveis, uma vez que abrange 3 diferentes metamodelos.Isto acontece devido a uma restrio da tecnologia EuGENia utilizada neste estudo, jque a mesma gera ferramentas grficas a partir de um metamodelo [13]. Portanto, este um problema que precisa ser resolvido.

A soluo encontrada foi realizar uma integrao dos trs metamodelos em apenas um,ao invs de um metamodelo importar outro, existe apenas um metamodelo que contmtodos os elementos dos outros, assim como seus relacionamentos. Assim, o problema solucionado e o desenvolvimento de uma ferramenta que cobre as 3 perspectivas possvel.

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

58

determinada viso, sem a interferncia das outras duas perspectivas. Quando conclumosas trs vises, realizamos a integrao. Em outras palavras, os trs 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 RequisitosNo-Funcionais. A segunda possui os elementos de contexto. Assim, deixamos bemseparadas as vises de RNF, contexto e variabilidade dentro de um nico metamodelo.Os elementos referentes variabilidade (VariationPoint, Variant, VariantsRelationship eWorkflowPattern) esto conectados diretamente com o elemento Model.

Variant o elemento principal da modelagem, ele possui ligaes com os elementosNFRSoftgoal, referente aos requisitos no-funcionais e ContextExpression referente sinformaes de contexto.

Figura 3.1 Parte do Metamodelo BVCCoN

Durante a modelagem, inconsistncias podem acontecer. Elementos definidos nasintaxe abstrata no sendo representados na sintaxe concreta da linguagem ou elementosdefinidos na sintaxe concreta no 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 grficos (quadrado, crculo, tringulo elosango), sendo que o losango no est representado no metamodelo. O caso inversoacontece na Figura 3.3, o elemento losango est representado no metamodelo porm sua

59representao no existe na sintaxe concreta. A Figura 3.4 apresenta um caso em que asintaxe concreta e abstrata esto compatveis. Os elementos do domnio representadosem uma tambm est presente na outra.

Figura 3.2 Elementos Grficos x Metamodelo - Exemplo 1

Figura 3.3 Elementos Grficos x Metamodelo - Exemplo 2

Durante o desenvolvimento da ferramenta proposta neste estudo, foi possvel iden-tificar os casos da Figura 3.2 e 3.3. Em seguida, so descritas as trs perspectivas daabordagem BVCCoN e tambm sero expostos os problemas identificados quanto aomapeamento entre sintaxe abstrata e concreta e qual a soluo adotada.

3.1.1 Sintaxe Abstrata

Nesta seo, ser detalhado os conceitos e relacionamentos do modelo BVCCoN. Estasdefinies esto agrupadas em quatro partes: modelo de processos de negcio, modelosde requisitos no-funcionais, modelo de descrio 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,

60

Figura 3.4 Elementos Grficos x Metamodelo - Exemplo 3

ser comentado as alteraes realizadas e apresentado o metamodelo final resultado dopresente estudo.

Nossa contribuio neste caso, ser a integrao de todos os metamodelos em apenasum, o metamodelo BVCCoN. Realizando os ajustes necessrios para que a integraoseja feita de maneira correta, preservando as caractersticas dos modelos j definidos esempre buscando um desenvolvimento integrado da sintaxe abstrata com a concreta.

Os metamodelos obtidos em [48] esto escritos atravs 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 atravs dalinguagem Emfatic [16] (ver subseo 2.4.3). O Epsilon possui um mecanismo onde tanto possvel transformar metamodelos Ecore para metamodelos escritos em Emfatic, comoo inverso. Portanto, transformamos os metamodelos em Ecore para Emfatic e seguimoscom os ajustes necessrios.

3.1.1.1 Modelo BPMN

BPMN (Business Process Modeling and Notation) uma linguagem de modelagem deprocessos de negcio definida pela OMG [36]. O objetivo do BPMN oferecer umanotao que seja de fcil compreenso por todos os usurios do negcio, dos analistasde negcio que criam os rabiscos iniciais dos processos, at o desenvolvedor tcnicoresponsvel por implementar a tecnologia que ir executar o processo. Por fim, as pessoasdo negcio que iro gerenciar e monitorar esses processos [36].

A abordagem BVCCoN utiliza o BPMN para modelar os processos de negcio.O metamodelo BPMN acessvel a qualquer desenvolvedor [36], j est validado epossui muitas ferramentas de suporte. Possui diferentes tipos de modelos como: modelo

61de workflow, modelos de coreografia, dentre outros. A abordagem utiliza modelos deworkflow para modelar processos de negcio. Est fora do escopo desta dissertaodiscutir em detalhes o metamodelo BPMN. Para maiores informaes, consultar [36].

3.1.1.2 Variabilidade

Os principais conceitos para representar variabilidade so: VariationPoint e Variants. Oprimeiro indica qual ponto no modelo de processo de negcio pode mudar, e o segundo soas partes do processo que podem ser acionadas para fazer parte do modelo de processo.Os VariationPoints e as Variants so representadas como elementos de processos denegcio (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 dependncia de variabilidade utilizado o atributo Operator, que pode ser OR, AND e XOR.

Associado com esses operadores, encontra-se os patterns, que so informaes quedizem como as variantes estaro posicionadas nos modelos de processos de negcio.Os WorkFlowPatterns podem representar, sequncia, paralelismo, comportamento op-cional, dentre outros. As Variants so associadas com os VariationPoints por meio dePatterns. As Variants so representadas por pedaos de processos de negcio por meiodo BusinessProcessPart.

62

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

At aqui foi descrito o metamodelo da perspectiva de variabilidade da abordagemBVCCoN [48]. Os prximos pargrafos detalha as alteraes que foram realizadas nometamodelo com o intuito de construir uma ferramenta de modelagem grfica, semprebuscando o alinhamento entre sintaxe abstrata e concreta.

Da maneira como o metamodelo foi construdo, seria necessrio que BusinessProces-sPart funcionasse como um n durante a modelagem, o que no estava de acordo coma sintaxe concreta. A sintaxe abstrata possuia o elemento BusinessProcessPart que noera refletido na sintaxe concreta, ou seja, no existia elemento grfico 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 intermedirio.

Tambm criamos os relacionamentos de source e target dos links excludes e requires,o que antes no estava representado no metamodelo. Assim, conseguimos deixar asintaxe abstrata e concreta compatvel, ou seja, os elementos grficos da sintaxe concretaesto 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 anotaes representam o seguinte:

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

Linhas 6 e 7: Variant possui um link chamado varPoints que responsvel porligar uma variante a um ponto de variao. Esse link representado por uma linhapreta contnua;

Linhas 14 a 18: ContextExpressionLink um link tracejado que possui como sourceuma variante e como target uma expresso de contexto (ContextExpression);

Linhas 19 a 27: cada ponto de variao (varPoints) representado por um retngulocinza que possui os atributos id, name e operator. O atributo operator uma

63enumerao que possui as opes AND, OR e XOR. Assim como uma variante, oponto de variao tambm possui apontamentos para um modelo BPMN externo;

Linhas 37 e 38: o link variantSource um link representado por uma seta fechadano elemento target. Responsvel por ligar um WorkflowPattern a uma variante;

Linhas 53 a 56: cada Requires representado como um link entre duas variantes.A representao grfica do link atravs de uma linha contnua com um pequenoquadrado no elemento target;

Linhas 57 a 60: cada Excludes representado como um link entre duas variantes.A representao grfica do link atravs de uma linha contnua 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 ;

64

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 ="