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 Informtica Ps-graduao em Cincia da Computao

Tarcsio Couto Pereira

BVCCoN-Tool - Uma Ferramenta para Apoiar uma Abordagem de Congurao de Processos de Negcio Dinmicos

Trabalho apresentado ao Programa de Ps-graduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para obteno do grau de Mestre em Cincia da Computao.

Orientador: Jaelson Freire Brelaz de Castro Co-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 as coisas boas e maravilhosas que fazes acontecer em minha vida. Aos meus pais Iran Pereira Silva e Ana Maria Couto de Lucena Pereira, por todo amor, amizade e felicidade que vocs me porporcionaram. Obrigado por sempre me ajudar a encontrar o caminho correto a seguir e por conar em todas as decises que tomei. Amo vocs. A minha noiva Luma Hannah, por todo o amor, companheirismo e dedicao durante esses 4 anos que estamos juntos. Te agradeo por todo o apoio durante os ltimos 2 anos e pela compreenso e pacincia nos momentos difceis que passei. Eu te amo! A minha amada famlia por me proporcionar momentos de unio e felicidades. Apesar de muitas vezes longe um do outro, o amor e apoio sempre foi o mesmo. Tambm agradeo aos meus amigos Jackson Raniel e Thiago Mendes pelas ideias compartilhadas. Ao meu professor orientador Jaelson Castro, por me aceitar orientar e por toda contribuio e ensinamentos que resultaram neste trabalho. A todos meus amigos do grupo LER (Laboratrio de Engenharia de Requisitos), em especial a Emanuel Santos, Paulo de Lima, Jssyka Flavyanne e Monique Soares por todo apoio. Aos professores Fernanda Alencar, Robson Fidalgo e ao meu amigo Edson Alves por toda ajuda durante o 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 nd 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 em ambientes onde as mudanas so constantes, sendo inuenciados por fatores geogrcos, climticos, dentre outros. As empresas precisam manter seus processos atualizados e funcionando adequadamente, sem desprezar os requisitos de qualidade. Baseado neste cenrio, foi proposto na literatura uma abordagem de congurao de processos chamada BVCCoN. Esta abordagem possui como objetivo oferecer suporte a congurao de processos baseada em NFRs e informaes contextuais. A abordagem possui trs perspectivas na congurao de processo de negcio: a descrio de variabilidade, os requisitos no-funcionais e o contexto. Durante as etapas desta abordagem, necessrio realizar a modelagem destas trs perspectivas. Contudo, modelar as trs perspectivas uma atividade que requer tempo e que est propensa a erros. Assim, esta dissertao prope o desenvolvimento de uma ferramenta que apoia a modelagem dos requisitos no-funcionais, da variabilidade e das regras de contexto. Para construir a ferramenta, foi realizada a integrao de trs metamodelos, com algumas alteraes, sendo cada um referente a uma perspectiva da abordagem BVCCoN. Alm disso, foi utilizado o framework Epsilon e seu conjunto de linguagens integrado no ambiente Eclipse para o desenvolvimento da ferramenta. Para ilustrar a utilizao da ferramenta, foi realizado um estudo de caso em um cenrio de check-in em aeroporto, bem como uma avaliao de usabilidade com potenciais usurios, visando avaliar os seguintes fatores: satisfao geral, utilidade do sistema, qualidade da informao e qualidade da interface. 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 environment where changes are constant, being inuenced 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 in the literature a process conguration approach called BVCCoN. The goal of this approach is to offer support for processes conguration based on NFRs and contextual information. The approach has three perspectives on business process conguration: the variability description, the non-functional requirements and the contextual information. During the steps of this approach, it is necessary perform the modeling of these three perspectives. However, modeling the three perspectives is an activity that takes time and is error prone. Thus, this dissertation proposes the development of a tool that supports the modeling of the non-functional requirements, variability and the context rules. In order to build the 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 Eclipse development environment. In order to illustrate the use of the tool, a case study in a check-in scenario in an airport was performed, as well as an usability evaluation with potential 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 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9

Processo da abordagem BVCCoN. Adaptado de [47]. . . . . . . . . . . Exemplo de variantes e pontos de variao. Adaptado de [48]. . . . . . Exemplo de decomposio de contexto. Adaptado de [48]. . . . . . . . RNFs e Variantes. Adaptado de [48]. . . . . . . . . . . . . . . . . . . . Exemplo de uma instncia de processo. Adaptado de [48]. . . . . . . . Infraestrutura Tradicional MDD. Adaptado de [3]. . . . . . . . . . . . . Dashboard GMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parte do Metamodelo BVCCoN . . . . . . . . . . . . . . . . . . . . . Elementos Grcos x Metamodelo - Exemplo 1 . . . . . . . . . . . . . Elementos Grcos x Metamodelo - Exemplo 2 . . . . . . . . . . . . . Elementos Grcos x Metamodelo - Exemplo 3 . . . . . . . . . . . . . Perspectiva de Variabilidade [48] . . . . . . . . . . . . . . . . . . . . . Metamodelo Variability - BVCCoN . . . . . . . . . . . . . . . . . . . Perspectiva Contexto [48] . . . . . . . . . . . . . . . . . . . . . . . . . Metamodelo Contexto - BVCCoN-Tool . . . . . . . . . . . . . . . . . Perspectiva RNF [48]. . . . . . . . . . . . . . . . . . . . . . . . . . . .

32 36 38 40 42 45 49 58 59 59 60 61 63 66 68 71 72 76 78 80 82 83 83 84 84 85 85 90 92 94 96

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

3.10 Metamodelo RNF - BVCCoN . . . . . . . . . . . . . . . . . . . . . . . 3.11 Sintaxe concreta do Ponto de Variao. . . . . . . . . . . . . . . . . . . 3.12 Sintaxe concreta de uma Variante. . . . . . . . . . . . . . . . . . . . . 3.13 Sintaxe concreta de RNF. . . . . . . . . . . . . . . . . . . . . . . . . . 3.14 Sintaxe concreta de Contexto. . . . . . . . . . . . . . . . . . . . . . . . 3.15 Editor da Ferramenta BVCCoN-Tool . . . . . . . . . . . . . . . . . . . 3.16 Menu de seleo da ferramenta . . . . . . . . . . . . . . . . . . . . . . 3.17 Modelo RNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.18 Modelo RNF e Variabilidade . . . . . . . . . . . . . . . . . . . . . . . 3.19 Modelo de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.20 Modelo BVCCoN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 4.2 4.3 4.4 Processo de Referncia . . . . . . . . . . . . . . . . . . . . . . . . . . Pontos de Variao no Processo de Referncia . . . . . . . . . . . . . . Pontos de Variao e Variantes com partes de Processos de Negcio . . Anlise de Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xvi 4.5 Requisitos No-Funcionais e Anlise de Contribuio . . . . . . . . . . 97 124 125 125 126 127 128 129 129 130 131 132 133 133 134 135 136 136 137 137 138 139 139

A.1 Editor grco da ferramenta . . . . . . . . . . . . . . . . . . . . . . . A.2 Incluso de um ponto de variao . . . . . . . . . . . . . . . . . . . . . A.3 Carregando modelo BPMN . . . . . . . . . . . . . . . . . . . . . . . . A.4 Procurando modelo BPMN . . . . . . . . . . . . . . . . . . . . . . . . A.5 Selecionando modelo BPMN . . . . . . . . . . . . . . . . . . . . . . . A.6 Finalizando o carregamento de um modelo BPMN . . . . . . . . . . . . A.7 Setando os atributos Begins e Ends de um ponto de variao . . . . . . . A.8 Setando os FlowElements de um ponto de variao . . . . . . . . . . . A.9 Setando os FlowElements de um ponto de variao . . . . . . . . . . . A.10 Variation Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.11 WorkowPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.12 Ligaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.13 Links Requires e Excludes . . . . . . . . . . . . . . . . . . . . . . . . A.14 Criando NFRmodel e Softgoals . . . . . . . . . . . . . . . . . . . . . . A.15 Ligaes entre Softgoals . . . . . . . . . . . . . . . . . . . . . . . . . A.16 Ligaes entre Variants e Softgoals . . . . . . . . . . . . . . . . . . . . A.17 Ligao entre ContextExpression e Statement . . . . . . . . . . . . . . A.18 AndDecomposition e Fatos . . . . . . . . . . . . . . . . . . . . . . . . A.19 AndDecomposition e Fatos . . . . . . . . . . . . . . . . . . . . . . . . A.20 Variveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.21 Expresso de contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . A.22 Exemplo das trs vises: variabilidade, requisitos no-funcionais e informao contextual . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Lista de Tabelas

2.1 2.2 2.3 2.4 4.1 4.2 4.3 4.4 4.5 4.6 4.7

Relao entre o tipo de representao de RNF e trabalhos selecionados [40]. Sumarizao dos Resultados . . . . . . . . . . . . . . . . . . . . . . . Contribuio para os RNFs Conana e Performance . . . . . . . . . . Sumrio de Critrios . . . . . . . . . . . . . . . . . . . . . . . . . . . Contribuio dos RNFs . . . . . . . . . . . . . Equipamentos utilizados para realizao do teste Respostas dos Participantes . . . . . . . . . . . Satisfao Geral . . . . . . . . . . . . . . . . . Utilidade do Sistema . . . . . . . . . . . . . . Qualidade da Informao . . . . . . . . . . . . Qualidade da Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 30 41 44 98 100 103 105 106 107 108

Lista de Acrnimos

BPMN BVCCoN DSEL DSL DSML EMF EOL GMF GPL MOF NFR OMG PSSUQ XMI

Business Process Management and Notation Business Process Conguration with NFR and Context-Awareness Domain Specic Embedded Language Domain Specic Language Domain Specic Modeling Language Eclipse Modeling Framework Epsilon Object Language Graphical Modeling Framework General Purpose Language Meta Object Facility Non-Functional Requirements Object Management Group The Post-Study System Usability Questionnaire Metadata Interchange

Lista de Listagem

2.1 2.2 3.1 3.2 3.3 3.4

Metamodelo escrito em Emfatic . . . . . . . Exemplo de Cdigo EVL . . . . . . . . . . . Metamodelo Variabilidade escrito em Emfatic Metamodelo Contexto escrito em Emfatic . . Metamodelo RNF escrito em Emfatic . . . . Restries EVL . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

51 53 63 68 72 86

Sumrio

1 Introduo 1.1 1.2 Motivao e Justicativa . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos da Investigao . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 1.2.2 1.3 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos Especcos . . . . . . . . . . . . . . . . . . . . . . .

25 25 26 26 27 27 29 29 31 32 32 37 38 41 41 44 45 46 48 48 49 50 54 56 57 57 59 60 61 65 70

Estrutura da Dissertao . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Fundamentao Terica e Trabalhos Relacionados 2.1 2.2 Reviso Sistemtica da Literatura . . . . . . . . . . . . . . . . . . . . . BVCCoN - Business Process Conguration with NFRs and ContextAwareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.3 2.3.1 2.3.2 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.5 Elicitao da Variabilidade . . . . . . . . . . . . . . . . . . . . Descrio da Variabilidade . . . . . . . . . . . . . . . . . . . . Anlise de Contexto . . . . . . . . . . . . . . . . . . . . . . . Ligar Variantes & RNF . . . . . . . . . . . . . . . . . . . . . . Realizar a Congurao . . . . . . . . . . . . . . . . . . . . . Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . UML - Unied Modeling Language . . . . . . . . . . . . . . . DSML - Linguagem para Modelagem Especca de Domnio . . Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . Graphical Modeling Framework . . . . . . . . . . . . . . . . . Epsilon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estudos que Desenvolveram Ferramentas de Modelagem . . . .

Meta-Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Consideraes do Captulo . . . . . . . . . . . . . . . . . . . . . . . .

3 BVCCoN Tool 3.1 Modelo e Metamodelo BVCCoN . . . . . . . . . . . . . . . . . . . . . 3.1.1 Sintaxe Abstrata . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1.1 3.1.1.2 3.1.1.3 3.1.1.4 Modelo BPMN . . . . . . . . . . . . . . . . . . . . . Variabilidade . . . . . . . . . . . . . . . . . . . . . . Contexto . . . . . . . . . . . . . . . . . . . . . . . . Requisitos No-Funcionais . . . . . . . . . . . . . . .

xxiv 3.1.2 Sintaxe Concreta . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2.1 3.1.2.2 3.1.2.3 3.2 3.3 3.4 Variabilidade . . . . . . . . . . . . . . . . . . . . . . Requisitos No-Funcionais . . . . . . . . . . . . . . . Contexto . . . . . . . . . . . . . . . . . . . . . . . . 75 75 78 79 81 85 87 89 89 90 90 90 90 95 95 98 98 99

A Ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restries EVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consideraes do Captulo . . . . . . . . . . . . . . . . . . . . . . . .

4 Avaliao 4.1 4.2 Cenrio: Check-In Aeroporto . . . . . . . . . . . . . . . . . . . . . . . Exemplo de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 Processo de Referncia . . . . . . . . . . . . . . . . . . . . . . Elicitao da Variabilidade . . . . . . . . . . . . . . . . . . . . Descrio da Variabilidade . . . . . . . . . . . . . . . . . . . . Anlise de Contexto . . . . . . . . . . . . . . . . . . . . . . . Anlise de Requisitos No-Funcionais . . . . . . . . . . . . . . The Post-Study System Usability Questionnaire . . . . . . . . . Usurios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Teste de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . .

Equipamentos e Ambiente . . . . . . . . . . . . . . . . . . . . 100 Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Processo de Coleta dos Dados . . . . . . . . . . . . . . . . . . 100 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.3.6.1 4.3.6.2 4.3.6.3 4.3.6.4 Satisfao Geral . . . . . . . . . . . . . . . . . . . . 104 Utilidade do Sistema . . . . . . . . . . . . . . . . . . 106 Qualidade da Informao . . . . . . . . . . . . . . . 106 Qualidade da Interface . . . . . . . . . . . . . . . . . 107

4.4 4.5

Ameaas Validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 111

5 Concluses e Trabalhos Futuros 5.1 5.2 5.3

Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 115

Referncias

Apndice

120

A Manual de Usurio da Ferramenta BVCCoN-Tool 123 A.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

1
Introduo
Este captulo apresenta a motivao e os objetivos para a realizao deste estudo, alm de apresentar a estrutra da dissertao.

1.1

Motivao e Justicativa

Os processos esto se tornando cada vez mais complexos e heterogneos, inseridos em ambientes onde as mudanas so constantes, sendo inuenciados por fatores geogrcos, climticos, dentre outros. As empresas precisam manter seus processos atualizados e funcionando adequadamente, sem desprezar os requisitos de qualidade. Abordagem dirigida contexto foi projetada para cobrir essas lacunas atravs da capacidade de percepo 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 de negcios sejam exveis s mudanas no ambiente organizacional, necessrio lidar com a variabilidade de processos [49]. A variabilidade de processos representa a modelagem de caminhos alternativos que podem ser realizados para executar determinada atividade. Tambm pode incluir informaes como: os recursos necessrios e o responsvel pela execuo 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 representam aspectos funcionais de um sistema de informao. Enquanto os requisitos ditos de qualidade, 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 de execuo, segurana, usabilidade, manutenabilidade e conabilidade. Baseado na grande importncia de RNFs e contexto em modelos de processos de negcio, Santos [47] prope uma abordagem de congurao de processos que tem como objetivo oferecer suporte sua congurao baseada em RNFs e informaes contextuais. A abordagem possui trs perspectivas na congurao de processo de negcio: a descrio de variabilidade, os Requisitos No-Funcionais e o contexto [47]. A primeira perspectiva tem como foco a descrio da variabilidade de modelos de processos de negcio e os mecanismos necessrios para lidar com isto. Na segunda perspectiva, utilizado RNFs para representar qualidades dos modelos de processos de negcio. Esta perspectiva aborda as preferncias e interferncias de atributos de qualidade nos modelos de processos. A perspectiva de contexto incorpora as inuncias do ambiente no modelo de processo. Atravs da associao de informaes monitorveis aos modelos de processos, possvel oferecer capacidade de adaptao aos mesmos para possveis mudanas de ambiente. Contudo, a abordagem de Santos [47] complexa, envolvendo modelos de processos de negcio, de requisitos no-funcionais e de informaes contextuais que esto interligados, ou seja, existe uma dependncia entre esses modelos. O usurio necessita ter como produto destas fases, modelos que os represente. A falta de uma ferramenta, que auxilie o usurio a realizar as etapas de modelagem, torna o processo mais lento, difcil de entender e mais propenso a erros. Com o propsito de solucionar estes problemas, o presente trabalho prope a especicao e o desenvolvimento de uma ferramenta que integre os diferentes modelos. Assim, deseja-se obter como produto nal, uma ferramenta de modelagem que oferea mais velocidade na execuo do processo de modelagem, que facilite a compreenso dos modelos e que evite erros.

1.2
1.2.1

Objetivos da Investigao
Objetivo Geral

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

27

1.2.2

Objetivos Especcos

Para alcanar o objetivo geral deste estudo, os seguintes objetivos especcos foram denidos: Planejar e executar uma reviso sistemtica da literatura sobre requisitos nofuncionais, informaes contextuais e modelos de processos de negcio; Desenvolver o metamodelo para a BVCCoN-Tool; Implementar a ferramenta de modelagem para a congurao de processos de negcio dinmicos; Aplicar um exemplo de uso com o objetivo de avaliar a expressividade da ferramenta; Denir, planejar, executar e interpretar uma avaliao de usabilidade com usurios reais.

1.3

Estrutura da Dissertao

O restante desta dissertao est organizada da seguinte maneira: Captulo 2 apresenta o background necessrio para a compreenso deste trabalho. Neste captulo, so descritas as etapas da abordagem BVCCoN, trabalhos relacionados, tambm so discutidos metamodelagem e apresentadas as tecnologias utilizadas para o desenvolvimento da ferramenta; Captulo 3 descreve a ferramenta proposta, incluindo o metamodelo e as etapas de desenvolvimento; Captulo 4 apresenta um exemplo de uso e tambm uma avaliao de usabilidade da ferramenta proposta; Por m, captulo 5 oferece um conjunto de concluses discutindo nossas contribuies e diretrizes para trabalhos futuros.

29

2
Fundamentao Terica e Trabalhos Relacionados
Neste captulo, apresentamos o background necessrio para a compreenso do trabalho proposto. importante ressaltar que no o objetivo desta seo descrever todas as informaes necessrias para a execuo da abordagem BVCCoN, mas sim, apresentar de forma sucinta as etapas da abordagem. Para conhecimento de todo o processo e forma de execuo da BVCCoN, consultar [48]. Tambm discutimos meta-modelagem e o framework 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 identicar como os requisitos no-funcionais e as informaes contextuais so representados nos modelos de processos de negcios. Utilizando-se da busca s principais bases de dados, identicamos 1883 trabalhos, dentre os quais foram classicados e analisados 13 trabalhos que levam em conta RNFs na modelagem de processos e 14 que consideram contexto em BPM. Realizamos uma leitura cuidadosa dos trabalhos e identicamos as linguagens de modelagens de processos que foram utilizadas para representar os RNFs e tambm realizamos um mapeamento entre os tipos de representao de RNF e seus determinados autores. Ao nal desta primeira anlise 8 trabalhos utilizaram a notao BPMN, 2 usaram digrama de atividades, 2 zeram uso da modelagem de processos de negcio orientada a objetivos e apenas 1 trabalho usou a notao Stock and Flow Diagrams. A Tabela 2.1 exibe o mapeamento entre os tipos de representao de RNFs e seus determinados autores.

30
Tabela 2.1 Relao entre o tipo de representao de RNF e trabalhos selecionados [40].
[Bocciarelli,2011] [Lapouchnian,2007] [Pavlovski,2008] [Bartonili,2012] [Santos,2012] [Cardoso,2009] [Boukadi,2009] [Serrano,2009] [Aburub,2007] [Khaluf,2011] [Zacarias,2005] [Saeedi,2010] [Wolter,2010] [Kedad,2011] [Zerari,2011] [Xavier,200] [Rosemann,2008]

Tipo de Representao | Trabalhos Selecionados 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 se d anotando elementos de um modelo com o nome do RNF, 4 dos 13 trabalhos adotam este tipo de representao. Em seguida, 3 trabalhos representam os RNFs atravs da criao de smbolos para represent-los. Um empate ocorre entre aqueles que fazem associao textual entre RNF e elementos do modelo e os que utilizam o NFRFramework para representar RNF, cada um com 2 trabalhos. Por m, encontra-se 1 trabalho que prope a criao de novos artefatos e um outro que representa os RNFs externamente ao modelo de negcio. Analisando os trabalhos referentes s informaes de contexto identicamos itens como, por exemplo, se o trabalho classicado como abordagem ou framework, se descreve alguma ferramenta para apoiar o processo criado, se testes foram realizados com o intuito de validar a proposta e at mesmo se os trabalhos discutem algumas estratgias de adaptao de processos de negcio. A Tabela 2.2 apresenta a sumarizao desses itens.
Tabela 2.2 Sumarizao dos Resultados
[Bucchiarone,2012] [Hallerback,2008] [Balabko,2003] [Ploesser,2009] [Saidani,2009] [Santos,2012] [Mejia, 2010] [Born,2009] [Vara,2010] [Xia,2008]

Itens Tipo de Contribuio - Abordagem Tipo de Contribuio - Framework Ferramentas de Suporte Testes da Abordagem/Framework Discute Estratgias de Adaptao

Para ns de contagem, consideramos apenas os itens "Ferramenta de Suporte", "Testes da Abordagem/Framework"e "Discute Estratgias de Adaptao". Portanto, analisando a Tabela 2.2, identicamos que 1 trabalho cobre os 3 itens citados anteriormente, 1 trabalho

31 discute ferramenta de suporte e estratgias de adaptao, 1 trabalho trata de estratgias de adaptao e 9 trabalhos realizam testes da abordagem/framework. Durante o processo de extrao dos dados e anlise dos resultados, encontramos a abordagem BVCCoN. Esta foi a nica abordagem que foi classicada tanto na anlise dos requisitos no-funcionais quanto na de informao contextual. Portanto, BVCCoN uma abordagem de congurao de processos de negcios que leva em considerao RNFs e contexto no momento de realizar conguraes. Informaes de contexto so importantes para obter exibilidade e requisitos de qualidade segundo Saeedi [45], so o caminho para alcanar performance e satisfao dos clientes. Esta abordagem representa os RNF externamente ao modelo de negcio atravs do NFRFramework. Uma vez denido os RNFs, os mesmos so ligados s variantes do processo. Quanto s informaes de contexto, a abordagem utiliza um conjunto de regras para montar as informaes contextuais e no possui uma ferramenta que apoie estas construes, assim como, tambm no possui uma ferramenta que realize a representao dos RNFs. Estas informaes obtidas da reviso sistemtica fortalece a inexistncia de uma ferramenta que apoie as fases de modelagem da abordagem, tornando o processo mais lento, difcil de entender e mais propenso a erros. A seo seguinte descreve as etapas da abordagem.

2.2

BVCCoN - Business Process Conguration with NFRs and Context-Awareness

A BVCCoN [48] uma abordagem que visa a congurao de processos de negcio utilizando requisitos no-funcionais e informaes contextuais. A abordagem composta de cinco atividades: Elicitar Variabilidade, Descrever Variabilidade, Analisar Contexto, Ligar RNFs & Variantes e Realizar Congurao. As primeiras quatro etapas so realizadas em design time (ver Figura 2.1). Enquanto a ltima etapa, Realizar Congurao realizada em runtime. Nossa ferramenta de modelagem cobre as atividades Descrever Variabilidade, Analisar Contexto e Ligar RNF & Variantes da abordagem. Para executar a atividade Elicitar Variabilidade, no necessrio a utilizao de uma ferramenta de modelagem, mas sim uma anlise em cima dos elementos do modelo de negcio em BPMN. Nas prximas subsees so detalhadas as etapas do processo da abordagem BVCCoN 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 identicar e descobrir possveis variaes em um modelo de processo de negcio. O objetivo descobrir diferentes maneiras de executar um processo, bem como os efeitos da incluso, mudana ou excluso de elementos do modelo. Possui como entrada um processo de negcio inicial e como sada toda informao sobre variabilidade elicitada. Para realizar esta atividade, utilizado o information analysis framework [32] que explora diferentes caractersticas da informao e obtm novos dados sobre as informaes. No contexto de modelos BPMN, este framework utilizado para analisar tarefas, atividades e outros elementos do modelo para identicar 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 identicar o 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 prximas sees. Para ilustrar um exemplo, estamos utilizando um processo de emergncia quanto

33 a existncia de fogo. Este processo um caso clssico de um sistema scio-tcnico onde software e humanos devem executar com segurana (ver Figura 2.2). O processo iniciado com a procura por fumaa ou fogo, caso identicado uma dessas situaes, vericado o risco. Caso o risco no seja real, o processo nalizado, porm, se o perigo for real, inicia-se a tarefa de resgatar as pessoas em perigo, seguida por tocar alarme de incndio, ligar para os servios de segurana pblica, abrir sadas de emergncia e Evacuar o prdio imediatamente. Pontos de variaes so pontos de mudanas denidos no modelo de processo de negcio que podem representar caminhos alternativos ou variveis de realizar atividades no processo. Para denir os pontos de variao, necessrio receber como entrada o modelo referncia de processo de negcio e a informao elicitada. Baseado nesta entrada, o analista dene o que ser marcado como ponto de variao e quais tarefas faro parte do ponto de variao. O analista tambm deve denir onde o ponto de variao comea (begins) e termina (ends). A sada destas atividades o modelo referncia de processo marcado com os pontos de variaes. Esta sada faz parte do processo de descrio de variabilidade. A Figura 2.2 exibe um possvel modelo de referncia com os pontos de variaes. Quatro pontos de variaes foram identicados: PV1 associado a tarefa Procurar por fumaa ou fogo, PV2 relacionado a tarefa Tocar alarme de incndio, PV3 corresponde a tarefa Ligar para os servios de segurana pblica e PV4 est ligado a tarefa Abrir sadas de emergncia. Aps denir os pontos de variaes e selecionar onde eles comeam e terminam, a prximo passo denir os elementos que sero parte das variantes. As informaes adquiridas durante a elicitao e os pontos de variao denidos anteriormente so entradas para a denio de variantes. Variantes so objetos de mudanas, representando caminhos alternativos ou variveis, ou seja, como as atividades do processo podem ser realizadas. Desta maneira, as variantes esto associadas a fragmentos de processos BPMN que iro expressar a maneira como um processo pode ser alterado para se adaptar a uma nova congurao de ambiente. Assim como os pontos de variaes, as variantes tambm so identicadas por um analista. No exemplo de emergncia de fogo, foram identicadas variantes que esto associadas ao 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 um sensor. A descrio de variabilidade tambm pode afetar o comportamento das tarefas. Os padres de work-ow descrevem comportamentos de atividades quando associadas a um ponto de variao. No modelo BVCCoN, a utilizao de padres work-ow 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 padres descrevem como os elementos (neste caso BPMN) sero agrupados [52]. Os padres bsicos so sequence, parallel split, synchronization, exclusive choice e simple merge. O padro sequence aquele em que as tarefas so executas em sequencia, o parallel split as tarefas so executas em paralelo, o padro synchronization precisa existir uma sincronia entre as tarefas do BPMN, ou seja, um conjunto de tarefas precisam ser executadas para que o uxo do processo BPMN continue. No padro Exclusive Choice dado um conjunto de tarefas, mas apenas uma executada, por m, no padro Merge dado um conjunto de tarefas em que apenas uma precisa ser executada para que o uxo do processo seja continuado. O prximo passo associar os pontos de variaes s variantes. Nesta etapa, necessrio denir algum operador lgico no ponto de variao para indicar como as variantes estaro associadas. Na abordagem BVCCoN, utilizado os termos AND, OR e XOR. Estes operadores podem inuenciar os padres de work-ow que esto associados s variantes. Por exemplo, um operador AND permite incluir como soluo os padres

35 sequence 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 ou fumaa automaticamente e Procurar por fogo ou fumaa pessoalmente respectivamente. Cada variante est associada a uma tarefa BPMN, var1 est associada com a tarefa Procurar por fogo ou fumaa automaticamente e var2 com a tarefa Procurar por fogo ou fumaa. Os pontos de variaes VP2, VP3 e VP4 tambm esto associados com suas respectivas variantes e as variantes com as tarefas BPMN. Aps concluir esta etapa, o prximo 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 denido como um estado do mundo que relevante para um objetivo de um ator. Nesta etapa, o modelo de processos de negcio analisado para identicar os contextos que podem afetar o modelo. Analisando o domnio, os contextos podem ser identicados. Estados de sistemas e tambm usurios podem ser descritos 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 esto conectados [2]. Fatos podem ser avaliados, j os statements no. Para que um statement assuma um valor verdadeiro, deve existir um conjunto suciente de evidncias que realize a comprovao. Essas evidncias so encontradas por meio das avaliaes dos fatos [5]. A decomposio termina quando possvel descrever todas as variveis que permitem vericar se o contexto foi ativado. O objetivo obter uma frmula de fatos apoiados por variveis monitorveis. Os seis passos abaixo so utilizados para obter o conjunto de contextos associados s variantes. 1. Selecionar uma variante do modelo de variabilidade a ser avaliado; 2. Identicar fatores que afetam a execuo do fragmento de processo de negcio de uma 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, o contexto Bombeiros serem chamados automaticamente apoiado por trs fatos: Alarme de fogo est ativo, Fogo foi conrmado, e Servios de rede est funcionando. Quando as variveis que esto associadas a este contexto atingem o valor especicado, 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 as preferncias dos stakeholders. Nesta etapa, os RNFs que so importantes para o processo so identicados e tambm denido o impacto de cada variante sobre os RNFs. Assim, os RNFs so ligados s variantes do processo de negcio que foram levantadas nos passos anteriores da abordagem. Os RNFs que sero levados em considerao so identicados e ento feito uma descrio dos RNFs e variantes. Essa elicitao pode ser realizada entrevistando pessoas que esto envolvidas no processo de negcio. Em seguida, pode-se associar os RNFs com as variantes para representar as preferncias dos stakeholders sobre a seleo de possveis variantes. RNFs representaro atributos de qualidade que os stakeholders esperam do sistema. Uma vez identicados os RNFs, permitido realizar as ligaes entre estes e as variantes do processo. A abordagem BVCCoN utiliza a escala qualitativa proposta pelo NFRFramework [30] para realizar essas ligaes. O impacto mais positivo sobre um requisito no-funcional chamado Make, um impacto parcialmente positivo Help, um impacto parcialmente negativo chamado de Hurt e um impacto mais negativo Break. Esses valores so mapeados respectivamente para, ++,+,-, na escala da abordagem BVCCoN.

39 A Figura 2.5 mostra uma verso simplicada de um modelo BVCCoN. As variantes Tocar alarme de fogo manualmente e Tocar alarme de fogo automaticamente fazem parte do ponto de variao VP2, que possui o operador lgico XOR. Este operador lgico indica que apenas uma das variantes pode ser selecionada. A variante Tocar alarme de fogo automaticamente est relacionada com o contexto Servios de backup esto funcionando, assim, esta variante s poder ser selecionada se o contexto for verdadeiro. A Tabela 2.3 apresenta as contribuies da Figura 2.5, permitindo uma melhor visualizao. Os espaos em branco so compreendidos como EqualContribution (=).

40

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

41
Tabela 2.3 Contribuio para os RNFs Conana e Performance

Variante/RNF Procurar 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

Conana ++ + + ++

Performance ++ ++ ++ + ++

2.2.5

Realizar a Congurao

Existem duas maneiras de executar a congurao 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 congurao 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 congurao de processo que maximiza o RNF selecionado. Ou seja, cada ponto de variao avaliado para identicar a variante que melhor se ajusta ao requisito no-funcional selecionado. Na anlise bottom-up, uma congurao de processo denida selecionando um sub-conjunto de variantes e ento, uma matriz de ligao utilizada para calcular o impacto da congurao sobre o requisito no-funcional. A Figura 2.6 apresenta uma soluo de um processo priorizando o RNF Performance. Para descrever os conceitos de ponto de variao, variantes, requisitos no-funcionais e informaes contextuais, utilizado um mecanismo chamado de metamodelagem. Assim, atravs de um metamodelo, possvel denir os elementos de modelagem e seus respectivos relacionamentos [4].

2.2.6

Trabalhos Relacionados

A seguir, apresentamos uma comparao entre estudos que descrevem abordagens de congurao de modelos de processos de negcio em ambientes dinmicos descritos na literatura. Trabalhos Identicados Questionnaire based variability modeling for system conguration

42

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

La Rosa [28] props uma abordagem para capturar variabilidade de sistemas baseada em modelos de questionrio. Ela apoia a congurao com um processo e um modelo de questionrio. O modelo de questionrio consiste de um grco que dene as questes a serem respondidas. Questes so respondidas em sequencia, lidando para a identicao de aes que so realizadas pela congurao. Os modelos de processos so representados por modelos de processos congurveis escritos em Congurable Yet Another Workow Language (C-YAWL). Esta linguagem uma extenso que possui a caracterstica de descrever os pontos de variao do processo dentro do modelo de processo. O modelo de processo com a informao de variabilidade est alinhado com o modelo de questionrio. A congurao do processo realizada pelo usurio respondendo questes que levam a um novo modelo de processo. Requirements-driven design and conguration management of business processes Lapouchnian et al. (2007) [29] apresenta uma abordagem que alinha processos de negcio com modelos de Goal. Modelos de Goal so usados para descrever os objetivos do negcio e as preferncias dos usurios. Atravs da decomposio dos modelos, possvel obter uma estrutura de goals [objetivos] do processo de negcio. O modelo de goals segue uma estrutura em formato de rvore na qual os goals so decompostos em subgoals. A descrio da informao de variabilidade adicionada a estrutura do modelo de goals. Por isso, as informaes do processo est misturado com anotaes. As anotaes que descrevem variabilidade so baseadas em IF-THEN-ELSE, regras assim como os operadores lgicos (AND, OR). Os requisitos no-funcionais so descritos como Softgoals e as contribuies para Softgoals representam as preferncias dos usurios sobre

43 possveis escolhas. Os pontos de variao so os lugares onde existe uma decomposio OR. Com o objetivo de obter um modelo de uxo de processo, eles descrevem os passos do comeo da congurao com uma anlise de Softgoal e seleo de variantes. Aps a seleo, uma transformao gera o modelo de uxo do processo em BPEL. Business processes contextualisation via context analysis De La Vara et al. (2010) [5] props uma metodologia para adicionar contextualizao aos modelos de processos de negcio. A proposta obter modelos de processos de negcio que so perceptveis ao contexto. A metodologia descreve vrios passos e inclui anotaes de contexto que baseada na abordagem de [2], que apoia anlise contextual. Os contextos consistem de rvores com facts e statements que so avaliados para identicar quando um contexto est ativo. As informaes contextuais so requeridas para ativar mudanas no uxo dos processos. Com o objetivo de incluir contexto, eles estenderam a notao BPMN para ter contextos embarcados nos uxos de sequncia que ligam as atividades. A descrio da variabilidade adicionada ao modelo de processo, onde o caminho alternativo no uxo do trabalho representa as variantes. Discusso As abordagens de congurao de processos de negcio so complexas e consomem muito esforo e tempo. A abordagem BVCCoN integra metamodelos de anlise realizados durante 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 denir variabilidade de processos. Na BVCCoN, quando o contexto aplicado, os pontos de variao e variantes j esto denidos. Isto reduz a anlise de contexto para apenas contextos relevantes, evitando problemas com a cobertura do modelo de processo e reduzindo a anlise de contexto 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 em BVCCoN, a anlise de requisitos realizada independemente da anlise de variabilidade. Durante a construo do modelo BVCCoN, a anlise de contribuio estabelece ligaes entre 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 con-

44 gurao. Por esta razo, La Rosa foca na reduo da interveno do usurio na realizao da congurao, a abordagem BVCCoN tenta reduzir a necessidade da interao com o usurio durante os passos da congurao. Algumas abordagens apresentaram ferramenta de suporte, porm, os benefcios podem ser limitados devido a abrangncia da ferramenta em relao as etapas das abordagens. A comparao foi baseada na avaliao de documentos, assim, as ferramentas de suporte no foram avaliadas. Mesmo compartilhando algumas caractersticas em comum com as outras abordagens, a BVCCoN mostra mais vantagens que desvantagens quando considerado o cenrio da congurao de processos dinmicos. BVCCoN uma abordagem mais completa, sua ferramenta permite modelar diferentes perspectivas relacionadas aos processos de negcio (requisitos no-funcionais, variabilidade e informaes de contexto), sem a necessidade de estender uma linguagem de modelagem existente ou utilizar uma linguagem apenas por cobrir alguma das perspectivas citadas anteriormente. A Tabela 2.4 mostra um sumrio das abordagens em relao aos critrios discutidos anteriormente.
Tabela 2.4 Sumrio de Critrios
Abordagem La Rosa (2009) Lapouchnian et al. (2007) De La Vara et al. (2010) BVCCoN Variabilidade C-YAWL/YAWL Modelo de Goals/BPEL BPMN estendido BPMN Congurao Seleo de Ns Transformao de modelos Validao de contexto Transformao de modelos Modelo de Processo Questionrio e C-YAWL Modelo de goals Modelo BPMN Modelo BVCCoN Ferramenta Sim Sim No Sim

2.3

Meta-Modelagem

A meta-meta-modelagem responsvel por denir uma linguagem para a especicao de metamodelos. A Object Management Group (OMG) deniu uma linguagem para a especicao de metamodelo denominada Meta Object Facility (MOF) [37]. Esta linguagem oferece um framework para o gerenciamento de metadados e um conjunto de servios de metadados para permitir o desenvolvimento e a interoperabilidade de modelos e sistemas que utilizam metadados. As tecnologias da OMG, incluindo UML (Unied Modeling Language), MOF, XMI1 , dentre outras, usam MOF e tecnologias derivadas de MOF para a troca e manipulao de metadados [37]. A Figura 2.7 apresenta uma infraestrutura em 4 camadas da primeira gerao de tecnologias MDD, ou seja, UML e MOF. Esta infraestrutura apresenta uma hierarquia
um formato de intercmbio amplamente utilizado para o compartilhamento de modelos usando XML [38].
1 XMI

45

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

divida por modelos. Cada modelo (exceto o M3) caracterizado como uma instncia do nvel acima. O nvel mais baixo, M0, responsvel por manipular os dados de usurio. Dados reais em que softwares so projetados para manipular. O nvel M1 representa o prprio modelo, ou seja, designado para manipular um modelo dos dados de usurio M0. O prximo 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 de informaes em M2, e por isso chamado de meta-metamodelo [3]. Neste estudo, proposto o desenvolvimento de um metamodelo (nvel M2) para a ferramenta proposta. Sendo possvel assim, gerar os nveis M1 e M0. O metamodelo a ser desenvolvido, ser construdo utilizando a tecnologia da UML, que revisada na prxima seo.

2.3.1

UML - Unied Modeling Language

A UML uma linguagem de modelagem proposta pela OMG, a qual uma das mais usadas para especicao, construo e documentao de artefatos de software. uma linguagem de modelagem de propsito geral, e pode ser usada para todos os domnios de aplicaes como sade, espao areo e telecomunicaes. Contudo, podem existir situaes em que uma linguagem de um propsito to geral e amplo no seja apropriado para a modelagem de aplicaes de um domnio especco. Isto pode acontecer quando queremos expressar conceitos especcos de um determinado domnio, ou quando

46 queremos restringir ou customizar alguns dos elementos da UML. A OMG discute duas abordagens possveis para denir uma linguagem especca de domnio. A primeira a criao de uma nova linguagem baseada nos mecanismos oferecidos pela prpria OMG para denio de linguagens visuais. Assim, sintaxe e semntica dos elementos da nova linguagem precisam ser denidos de acordo com as caractersticas do domnio [20]. A segunda alternativa se concentra na especializao da UML. Alguns elementos da linguagem so especializados, impondo novas restries sobre eles em relao ao metamodelo UML. A semntica dos elementos UML no alterada (as propriedades de uma classe UML, associaes, atributos, etc, sero os mesmos). Um prole em UML oferece mecanismos de extenses genricos para a customizao de modelos UML para domnios e plataformas particulares. Proles so denidos utilizando stereotypes, tag denitions e constraints [20]. Stereotypes: so denidos por um nome e um conjunto de elementos do metamodelo que so anexados; Constraints: podem estar associadas a esteretipos, impondo restries sobre os elementos do metamodelo correspondente; Tag denitions: um meta-atributo adicional que anexado a uma meta-classe de um metamodelo estendido por um Prole. Para este estudo, foi utilizada a primeira abordagem para o desenvolvimento da ferramenta. Portanto, necessrio construir uma linguagem de modelagem especca de domnio para a abordagem BVCCoN.

2.3.2

DSML - Linguagem para Modelagem Especca de Domnio

Quando tratamos de um domnio especco, as linguagens de modelagem, como por exemplo, UML, BPMN e i*, podem no conter todos os elementos necessrios para realizar a modelagem. Assim, pode ser til a criao de uma linguagem especca de domnio, (do ingls DSL - Domain Specic Language) para descrever com maiores detalhes as caractersticas mais importantes de um domnio especco. Uma DSL uma linguagem que est direcionada em um domnio particular de problema, oferecendo um conjunto restrito de notaes e abstraes apropriadas. Contudo, as DSLs contm uma linguagem de propsito geral (do ingls, GPL - General Purpose

47 Language) incorporada como uma sub-linguagem. Assim, oferecem um poder expressivo especco do domnio em conjunto com o poder de expressividade de uma GPL [51]. Isto acontece quando DSLs so implementadas como linguagens embarcadas. Portanto, quando no desejado criar uma linguagem de programao, melhor herdar toda infraestrutura de alguma outra linguagem, adequando-a em formas especiais para o domnio de interesse. Assim, possvel adquirir uma Linguagem Embarcada Especca de domnio (do ingls, DSEL - Domain Specic Embedded Language) [22]. J uma Linguagem para Modelagem Especca de Domnio (do ingls, DSML Domain Specic Modeling Languages) objetiva elevar o nvel de abstrao, especicando a soluo em uma linguagem que usa diretamente os conceitos e regras de um domnio de problema especco. A ideia modelar produtos de software utilizando DSL e gerar produtos nais em uma linguagem de programao escolhida ou em outras formas, como texto, modelo, cdigo, a partir das especicaes de alto nvel que foram denidas [24]. As DSLs so classicadas como interna, externa e no textuais. Uma DSL interna aquela que usa toda infraestrutura de uma linguagem de programao existente para construir semnticas especca de domnio sobre a mesma. Uma das mais populares DSL interna Rails [44], que implementada em cima da linguagem de programao Ruby [43]. Escrevendo cdigo Rails a mesma coisa que programar em Ruby, s que utilizando a semntica que Rails implementa para o desenvolvimento de aplicaes web [21]. Uma DSL externa aquela que desenvolvida similar implementao de uma nova linguagem de programao, possuindo sua prpria sintaxe e semntica. Uma DSL necessita ser uma representao do domnio, mas isto no implica que sua representao precisa ser apenas textual. DSL no textual aquela que pode modelar o domnio utilizando formas grcas [21]. Nesta dissertao foram utilizados formas grcas para modelar o domnio da congurao de processos de negcio dinmicos. Para denir uma DSL, necessrio desenvolver uma sintaxe concreta e abstrata, seguida de uma semntica projetada para denir o signicado da linguagem. Uma sintaxe abstrata de uma linguagem denida a partir do mtodo de meta-modelagem. Isto simplica o desenvolvimento da linguagem, permitindo aos designers mapear diretamente as classes da anlise de domnio para classes no metamodelo, associaes e herana que so parte da denio da DSL. A sintaxe abstrata descreve os conceitos da linguagem, as relaes entre eles e as regras de estruturao que restringem a combinao de elementos do modelo de acordo com as regras de domnio. A partir do metamodelo, construda a sintaxe

48 concreta. Ela especica como os conceitos de domnio includos no metamodelo so representados, e geralmente denido por um mapeamento entre o metamodelo e uma notao textual ou grca [26]. Durante o desenvolvimento da ferramenta, identicamos incompatibilidade entre sintaxe concreta e abstrata, portanto, realizamos alteraes necessrias para solucionar o problema. Uma vez denido a linguagem especca de domnio, foi necessrio utilizar tecnologias para o desenvolvimento da ferramenta.

2.4

Tecnologias

Esta seo responsvel por apresentar alguns conceitos e tecnologias que foram utilizadas para o desenvolvimento da ferramenta de modelagem proposta neste estudo. Para o desenvolvimento da ferramenta proposta, foi utilizado um conjunto unicado de frameworks de modelagem, ferramentas e implementaes de padres encontrados na comunidade Eclipse [11]. Dentre os frameworks de modelagem, destaca-se o EMF (Eclipse Modeling Framework) [10], que auxilia a especicao de metamodelos e prov funcionalidades para a gerao automtica do cdigo Java respectivo, o GMF (Graphical Modeling Framework) [15], que uma abordagem model-driven para o desenvolvimento de editores grcos baseados no eclipse e o Epsilon [12], [7], que uma famlia de linguagens e ferramentas destinadas 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 de ferramentas baseado em um modelo de dados estruturado (modelo de domnio). A partir de um modelo de domnio especicado em XMI ou em outro formato suportado, o EMF fornece ferramentas e suporte runtime produo de classes Java que implementam esse modelo. Assim como um conjunto de classes adapter que permite a edio e visualizao do modelo atravs de cdigo Java, e um editor bsico. O EMF composto de 3 peas fundamentais. 1) Framework EMF Ecore, que inclui um 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 de editores para modelos EMF, e por ltimo, 3) EMF.Codegen, responsvel por gerar todo cdigo necessrio para construir um editor completo para um modelo EMF [10]. O metamodelo Ecore composto pelos componentes Eclass, utilizado para representar uma metaclasse; EAttribute, para representar um atributo de uma Eclass; EReference,

49 utilizado para descrever associaes entre classes; e EEnum, usado para descrever enumeraes. EMF possui trs nveis de gerao de cdigo: 1) Modelo, oferece interface Java e implementao de classes para todas as classes descritas no metamodelo da ferramenta CASE a ser construda, 2) Adaptadores, capazes de gerar classes de implementao que adaptam as metaclasses do modelo para visualizao e edio, 3) Editor, produz uma estrutura do modelo que poder ser visualizada na fase de criao do editor grco [1].

2.4.2

Graphical Modeling Framework

GMF um framework para a construo de editores grcos a partir de metamodelos baseado em EMF. Para a construo de editores grcos utilizando o GMF, necessrio seguir um processo bem denido. Para facilitar a execuo deste processo, o desenvolvedor pode contar com a ajuda de um painel chamado GMF Dashboard. Este painel serve como um guia durante o desenvolvimento. O GMF Dashboard est ilustrado na Figura 2.8 [15].

Figura 2.8 Dashboard GMF

A gerao de um editor grco GMF consiste na criao e manipulao de alguns arquivos. 1. Domain Model - representa o metamodelo utilizado para criar o editor grco. necessrio importar o metamodelo de domnio denido em Ecore; 2. Domain GenModel - arquivo .genmodel usado para gerar cdigo do domain model; 3. Graphical Def Model - arquivo .gmfgraph responsvel por denir os elementos grcos que representaro cada um dos objetos que foram denidos no arquivo Ecore do Domain Model.

50 4. Tooling Def Model - arquivo com terminao .gmftool utilizado para denir os elementos da paleta de ferramentas. 5. Mapping Model - o arquivo do modelo de mapeamento .gmfmap criado para relacionar os elementos do metamodelo aos elementos do modelo grco e aos elementos do modelo ferramental. 6. Diagram Editor GenModel - o GMF fornece um modelo de gerador para gerar o cdigo executvel do editor grco.

2.4.3

Epsilon

Epsilon uma famlia de linguagens e ferramentas destinadas atividades de gerenciamento de metamodelos. Essas atividades so: gerao de cdigo, transformao modelo para 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 grcos em GMF, diminuindo a complexidade imposta pelo mesmo [13]. EuGENia gera ferramentas grcas a partir de um metamodelo Ecore com anotaes escritas na linguagem Emfatic [16]. Emfatic uma linguagem que foi projetada para representar modelos Ecore EMF de maneira textual simples e compacta, similar linguagem Java. Esta linguagem permite denir metaclasses, atributos de metaclasses, enumeraes, relacionamentos entre metaclasses, dentre outros elementos do modelo EMF Ecore. A partir de um arquivo escrito em Emfatic (arquivo .emf), que representa a sintaxe abstrata da linguagem de modelagem, possvel gerar um modelo Ecore (arquivo .ecore),

51 o inverso tambm possvel. A partir do metamodelo .emf construdo, necessrio enriquec-lo com anotaes em EuGENia, que denir os artefatos concretos a ser representado no editor grco. Assim, possvel denir em Emfatic quais metaclasses so ns ou links, denir a gura (retngulo, elipse) de um n que sero exibidos gracamente, denir a origem (source) e o destino (target) de um link. Tudo o que denido no arquivo Emfatic 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, as anotaes representam o seguinte: Linha 5: o elemento diagram representa o objeto raiz do metamodelo. Apenas uma Eclass no abstrata dever ser anotada como gmf.diagram; Linha 16: cada pasta tem um compartimento onde sub-componentes podem ser alocados; Linha 25: cada Sync representado como um link (associao) entre seus arquivos source e target. A representao grca do link atravs de uma linha pontilhada; Linha 31: cada arquivo representado no diagrama como um retngulo que possui um nome dentro.
Listagem 2.1 Metamodelo escrito em Emfatic
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

@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 " ) @gmf package f i l e s y s t e m ; @gmf . d i a g r a m class Filesystem { val Drive [ * ] d r i v e s ; v a l Sync [ * ] s y n c s ; } c l a s s Drive extends Folder { } c l a s s Folder extends F i l e { @gmf . c o m p a r t m e n t val F i le [*] contents ;

52
18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

} c l a s s Shortcut extends F i l e { @gmf . l i n k ( t a r g e t . d e c o r a t i o n =" a r r o w " , s t y l e =" d a s h " ) ref File t a r g e t ; } @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 i d t h = " 2 " ) c l a s s Sync { ref File source ; ref File t a r g e t ; } @gmf . node ( l a b e l = " name " ) class File { a t t r S t r i n g name ; }

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 para serem inseridas em um modelo que foi criado utilizando a linguagem Emfatic. EOL uma linguagem de programao imperativa para criar, consultar e modicar modelos EMF. Fornece caractersticas imperativas habituais como presena de variveis, comandos sequenciais, estruturas de controle e de desvio condicional, alm de outras caractersticas. Outras linguagens da famlia Epsilon como EVL, podem incorporar pores cdigo EOL em suas estruturas de cdigo [7]. EVL uma linguagem de validao que pode ser utilizada para adicionar validaes e fazer pequenos ajustes no editor grco GMF [18]. As restries em EVL so similares s OCL2 , porm, EVL suporta dependncia entre constraints (se uma constraint A falha, a constraint B no ser avaliada). Mensagens de erro customizadas podem ser exibidas aos usurios e um mecanismo de conserto pode ser ativado pelos usurios para reparar inconsistncias[7]. Em EVL, as especicaes de validao so organizadas em mdulos. A Listagem 2.2 exibe um trecho de cdigo escrito em EVL e os itens abaixo apresentam os mdulos EVL. Em seguida, indicado as linhas da Listagem 2.2 em que determinado mdulo aparece. Context - um contexto especica o tipo de instncia que as invariantes sero
2 OCL

uma linguagem formal utilizada para descrever expresses sobre modelos UML [35]

53 aplicadas (Linhas 1 e 8); Invariant - cada invariante EVL dene um nome e uma vericao (check). Uma invariante tambm pode denir uma mensagem que ser exibida ao usurio caso alguma restrio falhe. Para apoiar o conserto semiautomtico de elementos, uma invariante pode denir um nmero de x (Linhas 4 e 12); Guard - Guards so usados para limitar a aplicabilidade de invariantes. Um guard limita a aplicabilidade de todas as invariantes do contexto, enquanto a nvel de invariant, guard limita a aplicabilidade de uma invariante especca (Linha 10); Fix - Fix determina aes a serem realizadas para corrigir uma inconsistncia. A parte de cdigo "do"encontrada na Listagem 2.2, denida usando a linguagem EOL e responsvel pela correo da funcionalidade; Constraint - Constraints so usadas para capturar erros crticos que invalidam o modelo (Linha 2); Critique - ao contrrio de constraints, critiques so usadas para capturar situaes que no invalidam o modelo, mas que devem ser levadas em considerao pelo usurio para melhorar a qualidade do modelo (Linha 9). Pre and Post - um mdulo EVL pode denir um nmero de blocos chamados pre e post que so escritos em EOL e executados antes ou depois de uma invariante ser avaliada respectivamente.

Listagem 2.2 Exemplo de Cdigo EVL

1 2 3 4 5 6 7 8 9 10 11 12 13

context File { c o n s t r a i n t HasName { check : s e l f . name . i s D e f i n e d ( ) message : Unnamed + s e l f . e C l a s s ( ) . name + n o t a l l o w e d } } context Folder { critique NameStartsWithCapital { guard : s e l f . s a t i s f i e s ( HasName ) 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 . name message : F o l d e r + s e l f . name + s h o u l d s t a r t w i t h an u p p e r c a s e l e t t e r

54
14 15 16 17 18 19 20 21

fix { 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 ( ) do { 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 ( ) ; } } } }

O objetivo da linguagem ETL realizar transformaes de modelos (model-to-model). Mais especicamente, ETL pode ser usado para transformar um nmero arbitrrio de modelos de entrada para um nmero arbitrrio de modelos de sada de diferentes linguagens de modelagem e tecnologias em um alto nvel de abstrao [17]. EGL uma linguagem model-to-text. A partir de um metamodelo construdo em Ecore, pode-se obter cdigo executvel, relatrios HTML, documentao, imagens (usando pontos) e outros artefatos textuais [25] [7]. Transformaes de atualizao so aes que automaticamente cria, atualiza ou deleta elementos do modelo baseado na seleo de elementos existentes no modelo e nas informaes fornecidas pelo usurio (atravs de dados de entrada). EWL a linguagem da 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 de ferramentas de modelagem. Estes estudos utilizaram tecnologias que tambm foram utilizadas nesta dissertao, como o Framework Eclipse em conjunto com os plugins EMG/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 modelagem i*. Um novo metamodelo desenvolvido para a nova verso do i* e um processo de desenvolvimento para obter uma ferramenta grca de modelagem. Para o desenvolvimento da ferramenta, foi adotado o GMF Framework, que permite a modelagem do domnio e a gerao automtica de cdigo para representar os elementos grcos que faro 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 prticas), o autor deniu um conjunto de restries que foram escritas utilizando a linguagem de restrio OCL. Um

55 exemplo de restrio que um elemento no pode se ligar a ele mesmo. Uma segunda restrio 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 exemplicar seu uso e tambm realizar uma vericao para ver se as restries que foram denidas anteriormente estavam sendo executadas corretamente. A concluso obtida foi que a ferramenta se comportou de maneira apropriada. Uma Linguagem Especca do Domnio para uma Abordagem Orientada a Objetivos Baseada em KAOS O estudo apresentado em [6], demonstra um novo metamodelo da linguagem KAOS baseado em um previamente existente. A partir deste metamodelo, uma ferramenta desenvolvida. Para lidar com problemas de escalabilidade, os autores utilizaram o conceito de Compartimento. Para implementar este conceito, o metamodelo foi estendido com caixas (Compartimentos) em que possvel guardar elementos especcos pertencentes aquela caixa. Estas caixas possuem uma caracterstica de colapso, em que a partir de um clique possvel apresentar ou omitir pores do diagrama. A ferramenta apresentada nesta dissertao tambm possui este conceito de compartimento. Assim, possvel esconder ou apresentar pedaos do modelo, obtendo uma melhor escalabilidade e diminuindo a complexidade visual. Visto que a capacidade de colapso facilita a leitura dos modelos. Para projetar o editor grco, os autores utilizaram o Framework Eclipse em conjunto com os plugins EMF/GMF. Estenderam o metamodelo Ecore j existente e deniram no metamodelo o que ir representar os conceitos da linguagem KAOS. Para validar a ferramenta os autores realizaram um estudo de caso e uma avaliao de usabilidade. A avaliao de usabilidade consistiu de um questionamento sobre a sintaxe da linguagem, facilidade de utilizao da ferramenta e nveis de satisfao da ferramenta. Em geral, os utilizadores mostraram grande aceitao da ferramenta. Ficaram satisfeitos e a acharam fcil de utilizar. AGILE: Uma Abordagem para Gerao Automtica de Linguagens i* Em [4], o autor deniu uma abordagem automatizada para a denio estrutural de linguagens baseadas no i* e a gerao automtica de ferramentas CASE de modelagem correspondentes utilizando os conceitos de linhas de produtos de software. As tecnologias utilizadas para desenvolver uma ferramenta que automatize a denio de metamodelos de linguagens i* e a gerao automtica de editores grcos foram o EMF/GMF, baseadas no Eclipse. O autor deniu um metamodelo ncleo (escrito em

56 Ecore) com base nos construtores comuns das linguagens i* com suporte para a insero de variabilidade existente nas diversas linguagens baseadas no i*. A ferramenta proposta auxilia o usurio a projetar a estrutura de uma nova linguagem i* utilizando apenas uma interface grca, reduzindo consideravelmente alteraes manuais e direta em toda estrutura GMF. Com o propsito de testar a ferramenta, o autor realizou um estudo de caso em que foi aplicado a ferramenta AGILE Tool na criao do metamodelo da linguagem i* Aspectual, assim como a gerao de seu editor de modelagem grca. Metamodeling the Enhanced Entity-Relationship Model O 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, os autores desenvolveram uma ferramenta CASE e a testaram com exemplos prticos que cobrem os construtores da linguagem. Para desenvolver a ferramenta, os autores utilizaram tecnologias Eclipse, como o EMF/GMF e o Framework Epsilon e suas linguagens. Essas mesmas tecnologias tambm foram utilizadas para desenvolver a ferramenta proposta nesta dissertao. O metamodelo foi escrito em Ecore, as validaes foram implementadas em EVL e, alm disso, os autores 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 nofuncionais e informaes contextuais em modelos de processos de negcio. Relatamos o processo da abordagem BVCCoN, Elicitar Variabilidade, Descrever Variabilidade, Analisar Contexto, Ligar RNF & Variantes e Realizar Congurao, discutimos trabalhos relacionados, apresentamos conceitos de metamodelagem, UML, DSML e as tecnologias utilizadas para o desenvolvimento da ferramenta proposta e, por m, relatamos alguns trabalhos que desenvolveram ferramentas grcas de modelagem.

3 Linguagem

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

57

3
BVCCoN Tool
Este captulo trata da especicao da ferramenta proposta, incluindo as etapas de desenvolvimento e a criao de um metamodelo para a ferramenta da abordagem BVCCoN. Sero apresentadas as 3 diferentes vises do metamodelo, uma viso referente aos Requisitos No-Funcionais, uma segunda viso relacionada s informaes de contexto e por ltimo, ser apresentada a viso de variabilidade. Estas vises sero exibidas por meio da sintaxe abstrata e concreta da linguagem.

3.1

Modelo e Metamodelo BVCCoN

A abordagem BVCCoN cobre trs perspectivas na congurao de processos de negcio: a descrio da variabilidade, os Requisitos No-Funcionais, e as informaes de contexto. Estas trs perspectivas e seus conceitos so descritos atravs de seus respectivos metamodelos em [48]. Da maneira como foi dividido, torna-se invivel a construo de uma ferramenta de modelagem que suporte estes trs nveis, uma vez que abrange 3 diferentes metamodelos. Isto acontece devido a uma restrio da tecnologia EuGENia utilizada neste estudo, j que a mesma gera ferramentas grcas 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 contm todos 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 alteraes dos metamodelos foram realizadas de maneira independente. Por isso, o foco estava em

58 determinada viso, sem a interferncia das outras duas perspectivas. Quando conclumos as trs vises, realizamos a integrao. Em outras palavras, os trs metamodelos que antes estavam separados, agora fazem parte de apenas um metamodelo, o bvccontool.emf. Dentro do nosso metamodelo, criamos uma classe chamada NFRModel e uma outra chamada ContextModel. A primeira possui todos os elementos relacionados Requisitos No-Funcionais. A segunda possui os elementos de contexto. Assim, deixamos bem separadas as vises de RNF, contexto e variabilidade dentro de um nico metamodelo. Os elementos referentes variabilidade (VariationPoint, Variant, VariantsRelationship e WorkowPattern) esto conectados diretamente com o elemento Model. Variant o elemento principal da modelagem, ele possui ligaes com os elementos NFRSoftgoal, referente aos requisitos no-funcionais e ContextExpression referente s informaes de contexto.

Figura 3.1 Parte do Metamodelo BVCCoN

Durante a modelagem, inconsistncias podem acontecer. Elementos denidos na sintaxe abstrata no sendo representados na sintaxe concreta da linguagem ou elementos denidos na sintaxe concreta no existindo na sintaxe abstrata. O ideal que ocorra um desenvolvimento integrado de ambos artefatos [26]. A Figura 3.2 apresenta um caso em que a sintaxe concreta possui quatro elementos grcos (quadrado, crculo, tringulo e losango), sendo que o losango no est representado no metamodelo. O caso inverso acontece na Figura 3.3, o elemento losango est representado no metamodelo porm sua

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

Figura 3.2 Elementos Grcos x Metamodelo - Exemplo 1

Figura 3.3 Elementos Grcos x Metamodelo - Exemplo 2

Durante o desenvolvimento da ferramenta proposta neste estudo, foi possvel identicar os casos da Figura 3.2 e 3.3. Em seguida, so descritas as trs perspectivas da abordagem BVCCoN e tambm sero expostos os problemas identicados quanto ao mapeamento 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. Estas denies esto agrupadas em quatro partes: modelo de processos de negcio, modelos de requisitos no-funcionais, modelo de descrio de variabilidade e modelo de contexto. Algumas dessas perspectivas j possuem metamodelos denidos na literatura, como BPMN e RNF. Os modelos restantes foram denidos por [48]. Em cada uma dessas perspectivas, primeiro ser apresentado o metamodelo descrito em [48] e, em seguida,

60

Figura 3.4 Elementos Grcos x Metamodelo - Exemplo 3

ser comentado as alteraes realizadas e apresentado o metamodelo nal resultado do presente estudo. Nossa contribuio neste caso, ser a integrao de todos os metamodelos em apenas um, o metamodelo BVCCoN. Realizando os ajustes necessrios para que a integrao seja feita de maneira correta, preservando as caractersticas dos modelos j denidos e sempre buscando um desenvolvimento integrado da sintaxe abstrata com a concreta. Os metamodelos obtidos em [48] esto escritos atravs de uma linguagem de metamodelagem que faz parte do EMF [10], chamada Ecore. O framework Epsilon [12] que utilizamos no desenvolvimento da ferramenta, descreve metamodelos atravs da linguagem Emfatic [16] (ver subseo 2.4.3). O Epsilon possui um mecanismo onde tanto possvel transformar metamodelos Ecore para metamodelos escritos em Emfatic, como o inverso. Portanto, transformamos os metamodelos em Ecore para Emfatic e seguimos com os ajustes necessrios. 3.1.1.1 Modelo BPMN

BPMN (Business Process Modeling and Notation) uma linguagem de modelagem de processos de negcio denida pela OMG [36]. O objetivo do BPMN oferecer uma notao que seja de fcil compreenso por todos os usurios do negcio, dos analistas de negcio que criam os rabiscos iniciais dos processos, at o desenvolvedor tcnico responsvel por implementar a tecnologia que ir executar o processo. Por m, as pessoas do 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 e possui muitas ferramentas de suporte. Possui diferentes tipos de modelos como: modelo

61 de workow, modelos de coreograa, dentre outros. A abordagem utiliza modelos de workow para modelar processos de negcio. Est fora do escopo desta dissertao discutir 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. O primeiro indica qual ponto no modelo de processo de negcio pode mudar, e o segundo so as 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 de negcio (ver Figura 3.5).

Figura 3.5 Perspectiva de Variabilidade [48]

Os links begins e ends acessam o metamodelo do BPMN para um relacionamento com os artefatos FlowElements. As Variants podem ser associadas um ou mais VariationPoints. 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 que dizem como as variantes estaro posicionadas nos modelos de processos de negcio. Os WorkFlowPatterns podem representar, sequncia, paralelismo, comportamento opcional, dentre outros. As Variants so associadas com os VariationPoints por meio de Patterns. As Variants so representadas por pedaos de processos de negcio por meio do BusinessProcessPart.

62 Cada BusinessProcessPart se refere aos FlowElements do metamodelo BPMN e possui os links begins e ends assim como nos VariationPoints. As Variants possuem algumas restries como por exemplo: requires e excludes. A primeira requer a presena de outra variant e a segunda exclui uma variant. Todas essas informaes podem ser vistas na Figura 3.5. At aqui foi descrito o metamodelo da perspectiva de variabilidade da abordagem BVCCoN [48]. Os prximos pargrafos detalha as alteraes que foram realizadas no metamodelo com o intuito de construir uma ferramenta de modelagem grca, sempre buscando o alinhamento entre sintaxe abstrata e concreta. Da maneira como o metamodelo foi construdo, seria necessrio que BusinessProcessPart funcionasse como um n durante a modelagem, o que no estava de acordo com a sintaxe concreta. A sintaxe abstrata possuia o elemento BusinessProcessPart que no era reetido na sintaxe concreta, ou seja, no existia elemento grco que representasse BusinessProcessPart. Portanto, para que a sintaxe abstrata e concreta estivessem de acordo uma com a outra, transferirmos os atributos de BusinessProcessPart e alocamos em Variant. Desta maneira, Variant pode acessar diretamente os FlowElements do metamodelo 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 a sintaxe abstrata e concreta compatvel, ou seja, os elementos grcos da sintaxe concreta esto representados na sintaxe abstrata e o que est sendo representado no metamodelo reetido na sintaxe concreta (ver Figura 3.6). A Listagem 3.1 apresenta o metamodelo de variabilidade escrito na linguagem Emfatic. As anotaes representam o seguinte: Linhas 1 a 5: cada Variante representada como uma Elipse cinza com bordas pretas tracejadas. Possui os atributos name, id e isDefault. Tambm possui um apontamento para um modelo BPMN externo, representado pelas linhas 10, 11 e 12; Linhas 6 e 7: Variant possui um link chamado varPoints que responsvel por ligar uma variante a um ponto de variao. Esse link representado por uma linha preta contnua; Linhas 14 a 18: ContextExpressionLink um link tracejado que possui como source uma variante e como target uma expresso de contexto (ContextExpression); Linhas 19 a 27: cada ponto de variao (varPoints) representado por um retngulo cinza que possui os atributos id, name e operator. O atributo operator uma

63 enumerao que possui as opes AND, OR e XOR. Assim como uma variante, o ponto de variao tambm possui apontamentos para um modelo BPMN externo; Linhas 37 e 38: o link variantSource um link representado por uma seta fechada no elemento target. Responsvel por ligar um WorkowPattern a uma variante; Linhas 53 a 56: cada Requires representado como um link entre duas variantes. A representao grca do link atravs de uma linha contnua com um pequeno quadrado no elemento target; Linhas 57 a 60: cada Excludes representado como um link entre duas variantes. A representao grca do link atravs de uma linha contnua com um pequeno quadrado de cor preta no elemento target;

Figura 3.6 Metamodelo Variability - BVCCoN

Listagem 3.1 Metamodelo Variabilidade escrito em Emfatic

1

2 3

@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 =" d a s h " , 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 " , color ="143 ,148 ,152" , s i z e ="60 ,60") class Variant { a t t r S t r i n g [ 1 ] name ;

64
4 5 6

7 8 9 10 11 12 13 14

id attr String [1] ~id ; attr boolean [1] i s D e f a u l t ; @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") ref VariationPoint [*]# variants varPoints ; ref WorkflowPattern [*]# variantSource p a t t e r n ; / / 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 r e f bpmn2 . F l o w E l e m e n t [ 1 ] b e g i n s ; r e f bpmn2 . F l o w E l e m e n t [ 1 ] e n d s ; r e f bpmn2 . F l o w E l e m e n t [ * ] f l o w E l e m e n t s ; } @gmf . l i n k ( s t y l e =" d a s h " , 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 " , i n c o m i n g =" t r u e " ) class ContextExpressionLink { ref Variant source ; ref ContextExpression t a r g e t ; } @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 " , border . color ="0 ,0 ,0" , color ="143 ,148 ,152") class VariationPoint { id attr String [1] ~id ; a t t r S t r i n g [ 1 ] name ; attr VariationPointOperator [1] operator ; r e f bpmn2 . F l o w E l e m e n t [ 1 ] b e g i n s ; r e f bpmn2 . F l o w E l e m e n t [ 1 ] e n d s ; r e f bpmn2 . F l o w E l e m e n t [ * ] f l o w E l e m e n t s ; } enum V a r i a t i o n P o i n t O p e r a t o r { AND = 0 ; OR = 1 ; XOR = 2 ; } @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 =" d a s h " , 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 " ) c la s s WorkflowPattern { a t t r WorkflowPatternType wfPattern ; id attr String [1] ~id ; @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 " , color ="0 ,0 ,0") ref Variant [1]# pattern variantSource ; } enum W o r k f l o w P a t t e r n T y p e {

15 16 17 18 19

20 21 22 23 24 25 26 27 28 29 30 31 32 33

34 35 36 37

38 39 40

65
41 42 43 44 45 46 47 48 49 50 51 52 53

SEQUENCE = 0 ; PARALLEL_SPLIT = 1 ; SYNCHRONISATION = 2 ; EXCLUSIVE_CHOICE = 3 ; SIMPLE_MERGE = 4 ; MULTIPLE_CHOICE = 5 ; } class VariantsRelationship { ref Variant [1] relationshipSource ; ref Variant [1] relationshipTarget ; id attr String [1] ~id ; } @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 " , i n c o m i n g =" t r u e " ) c l a s s Requires extends V a r i a n t s R e l a t i o n s h i p { a t t r S t r i n g [ 1 ] name =" r e q u i r e s " ; } @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 " , i n c o m i n g =" t r u e " ) c l a s s Excludes extends V a r i a n t s R e l a t i o n s h i p { a t t r S t r i n g [ 1 ] name =" e x c l u d e s " ; }

54 55 56 57

58 59 60

3.1.1.3

Contexto

O metamodelo de contexto denido por [48] foi baseada na avaliao de linguagem para representar contexto proposta por [2]. Ela baseada na decomposio de contexto em uma frmula de facts e statements. Um statement um predicado do mundo que no pode ser vericado por um ator dentro do contexto. Um statement pode ser decomposto em outros statements ou facts. Alm disso, facts podem ser vericados e associados variveis. A Figura 3.7 apresenta a perspectiva de Contexto da abordagem BVCCoN. A classe BVCCoNContext responsvel por representar as informaes contextuais. Um contexto composto por uma ContextExpression que composta por uma frmula de Predicates. Um Predicate pode ser um statement, um fact ou um PredicateDecomposition. Um statement descreve uma expresso que no pode ser validada sozinha. Por isso, apoiado por um outro Predicate. Predicates podem ser decompostos por outros predicates

66

Figura 3.7 Perspectiva Contexto [48]

utilizando os operadores AND, OR e NOT. Facts podem ser avaliados e validados. Esto associados variables, que expressam os valores avaliados pela frmula de predicados. Analisando a perspectiva de Contexto, foi necessrio realizar algumas alteraes para que a sintaxe abstrata e concreta mantenham-se alinhadas. Primeiramente, no metamodelo da Figura 3.7 no existe nenhuma classe para representar os links que iro realizar os relacionamentos entre as classes ns. Por isso, criamos trs classes para representar os links: ContextExpressionLink, PredicateLink e CELink. Estas classes podem ser vistas na Figura 3.8. Na Figura 3.8, Variants precisam de um relacionamento com ContextExpression. A classe ContextExpressionLink responsvel por garantir este relacionamento. O link para relacionamentos entre Predicates o PredicateLink. Por ltimo, CELink realiza apenas ligao entre um Predicate e uma ContextExpression. A nvel de desenvolvimento de ferramenta, mudamos a maneira como a classe BVCCoNContext est inserida no metamodelo. Da forma como est representada, seria necessrio que BVCCoNContext fosse um n para que realmente ela pudesse ser expressa no momento da modelagem. O que, de certa forma, no era compatvel com a sintaxe concreta. Na sintaxe concreta, BVCCoNContext no existe, por isso, resolvemos mant-la no metamodelo da ferramenta apenas como uma classe abstrata a qual ContextExpression herda, no perdendo totalmente a caracterstica do metamodelo anterior. Da maneira como o metamodelo estava desenvolvido, no momento da modelagem para inserir um OrDecomposition, AndDecomposition ou NotDecomposition seria ne-

67 cessrio inserir um n chamado PredicateDecomposition e relacionar com a classe que representa o Or, And ou Not. Porm, PredicateDecomposition uma classe que no representada durante a modelagem. Ento, decidimos excluir a classe chamada DecompositionType, e fazer a herana dos operadores lgicos diretamente com PredicateDecomposition. Desta maneira, conseguimos resolver o problema existente. Como a complexidade do metamodelo de Contexto aumentou, tambm decidimos criar uma classe N e uma Link, com o intuito de deixar bem claro e separado quais as classes "Ns"e quais as classes "Links"dentro do metamodelo. A Figura 3.8 exibe o metamodelo de Contexto da ferramenta proposta nesta dissertao. Todas as alteraes podem ser conferidas e comparadas com o metamodelo da Figura 3.7. A Listagem 3.2 apresenta o metamodelo de Contexto escrito na linguagem Emfatic. Os itens abaixo apresentam as anotaes. Linha 1: ContextModel representado atravs de um retngulo com as bordas arredondadas; Linha 4: um ContextModel um compartimento onde sub-componentes podem ser alocados; Linha 14: cada ContextExpression representado no diagrama como uma Elipse. Possui os atributos id e name; Linha 22: os Statements so representados por um retngulo com uma descrio. Seus atributos so id e a prpria description; Linha 30: cada CELink representado como um link entre um Predicate e uma ContextExpression. A representao grca do link atravs de uma seta fechada; Linha 35: cada PredicateLink representa um link entre os Predicates. A representao grca do link atravs de uma seta fechada com a cor preta; Linha 40: os Facts so representados no diagrama por um retngulo com a borda pontilhada. Os atributos valid, description e name fazem parte deste elemento; Linha 45: os Facts possuem um link chamado de variables que realiza ligaes entre fatos e variveis. A representao grca uma linha pontilhada; Linha 48: uma Variable representado por um retngulo amarelo com bordas arredondadas. Os atributos pertencentes so: name, type e value;

68 Linha 58 e 62: so as decomposies AND e OR de contexto. O smbolo grco um losango com o label AND ou OR; Linha 56: NotDecomposition um link cuja representao grca uma echa fechada com o label NOT.

Figura 3.8 Metamodelo Contexto - BVCCoN-Tool

Listagem 3.2 Metamodelo Contexto escrito em Emfatic

1

2 3 4 5 6 7 8 9 10

@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 =" r o u n d e d " , b o r d e r . c o l o r = " 0 , 0 , 0 " , s i z e = " 5 0 0 , 2 0 0 " ) c l a s s ContextModel { a t t r S t r i n g [ 1 ] name =" C o n t e x t Model " ; @gmf . c o m p a r t m e n t v a l Node [ * ] n o d e s ; val Link [ * ] l i n k s ; } c l a s s Node { }

69
11 12 13 14

a b s t r a c t c l a s s BVCCoNContext { } @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 " , color ="153 ,153 ,153") c l a s s C o n t e x t E x p r e s s i o n e x t e n d s BVCCoNContext , Node { a t t r S t r i n g [ 1 ] name = "C " ; id attr String [1] ~id ; } a b s t r a c t c l a s s P r e d i c a t e e x t e n d s Node { } @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 = " 1 0 0 , 6 0 " , 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 l a s s Statement extends P r e d i c a t e { id attr String [1] ~id ; a t t r S t r i n g [ 1 ] d e s c r i p t i o n = "S : Statement " ; } c l a s s Link { } @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 " ) c l a s s CELink e x t e n d s L i n k { ref Predicate [1] source ; ref ContextExpression [1] t a r g e t ; } @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 " , i n c o m i n g =" t r u e " ) c l a s s P r e d i c a t e L i n k extends Link { ref Predicate [1] source ; ref Predicate [1] t a r g e t ; } @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 = " 1 0 0 , 6 0 " , 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 " ) c l a s s Fact extends P r e d i c a t e { attr boolean [1] valid ; a t t r S t r i n g [ 1 ] d e s c r i p t i o n = "F : Fact " ; i d a t t r S t r i n g [ 1 ] name ;

15 16 17 18 19 20 21 22

23 24 25 26 27 28 29 30

31 32 33 34 35

36 37 38 39 40

41 42 43 44

70
45

46 47 48

@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 " , i n c o m i n g =" t r u e " ) ref Variable [*] variables ; } @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" , border . color ="0 ,0 ,0" , color ="255 ,255 ,102") c l a s s V a r i a b l e e x t e n d s Node { a t t r S t r i n g [ 1 ] name ; attr String [1] type ; attr String [1] value ; } a b s t r a c t c l a s s PredicateDecomposition extends P r e d i c a t e { } @gmf . node ( f i g u r e =" o r g . 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 i a g r a m . f i g u r e s . D i a m o n d F i g u r e " , l a b e l =" name " , s i z e = " 1 0 0 , 6 0 " ) c l a s s OrDecomposition extends PredicateDecomposition { i d a t t r S t r i n g [ 1 ] name = "OR " ; } @gmf . node ( f i g u r e =" o r g . 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 i a g r a m . f i g u r e s . D i a m o n d F i g u r e " , l a b e l =" name " , s i z e = " 1 0 0 , 6 0 " ) c l a s s AndDecomposition extends P r e d i c a t e D e c o m p o s i t i o n { i d a t t r S t r i n g [ 1 ] name = "AND" ; } @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 =" d a s h " , i n c o m i n g =" t r u e " ) c l a s s NotDecomposition extends PredicateDecomposition , P r e d i c a t e L i n k { i d a t t r S t r i n g [ 1 ] name = "NOT " ; }

49 50 51 52 53 54 55 56 57

58 59 60 61

62 63 64 65

66 67 68

3.1.1.4

Requisitos No-Funcionais

O metamodelo adotado por [48] em sua abordagem baseado no NFRFramework [30], porm, com algumas alteraes. O autor adaptou o metamodelo do NFRFramework para que casse de acordo com a abordagem proposta, assim, alguns conceitos foram removidos e outros adaptados. A Figura 3.9 apresenta a perspectiva RNF adaptada. Os principais conceitos so o NFRSoftgoal e o NFRSoftgoalContribution, que so os elementos principais do NFRFramework. So empregados para descrever os catlogos de RNF, as decomposies dos RNF, e para representar as contribuies entre RNF e das Variants para os RNFs. Os relacionamentos de contribuio representados pelo NFRSoft-

71

Figura 3.9 Perspectiva RNF [48].

goalContribution possui vrios sub-tipos como: BreakContribution, HurtContribution, EqualContribution, HelpContribution e MakeContribution, que varia respectivamente do impacto mais negativo ao impacto mais positivo. Contribuies como OrContribution e AndContribution so usadas para decompor os RNFs durante a denio do catlogo de RNFs. Os relacionamentos de contribuio so utilizados para representar preferncias entre as Variants (que um elemento concreto). A classe para representar esse ideia a NFROperationalization. Durante a anlise da perspectiva RNF (ver Figura 3.9), vericamos que todos os links da classe NFRSoftgoalContribution poderiam ser utilizados para realizar ligaes entre RNFs, ligaes de decomposio entre NFRSoftgoal com NFROperationalization e vice-versa, o que de acordo com as especicaes, no permitido. Em [48], o autor utiliza regras OCL para restringir as ligaes entre de contribuio entre NFRSoftgoal como source e Variant como target. Assim como as decomposies OR e AND s podem ser feitas entre NFRSoftgoals. Da maneira como as restries foram utilizadas, no impedir o usurio de realizar relacionamentos incorretos. A ferramenta iria acusar um erro de relacionamento, mas mesmo assim as ligaes ainda seriam permitidas. Para impedir o usurio de cometer erros 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 uma nova classe chamada NFRSoftgoalContributionalOperational, que contm os links de contribuio BreakContribution, HurtContribution, EqualContribution, HelpContribution e MakeContribution. Esses links possuem como source uma Variant (que est representando o NFROperationalization) e como target um NFRSoftgoal. Desta maneira, conseguimos impedir os usurios de realizar ligaes incorretas pelo prprio metamodelo. Assim, regras OCL ou EVL (fornecida pelo framework Epsilon)

72

Figura 3.10 Metamodelo RNF - BVCCoN

no so necessrias. No momento de realizar a modelagem, a ferramenta impedir aes errneas. A Listagem 3.3 apresenta o metamodelo de RNF escrito na linguagem Emfatic. Em particular, as anotaes representam o seguinte: Linha 2: NFRModel representado atravs de um retngulo com as bordas arredondadas; Linha 4: um NFRModel um compartimento onde sub-componentes podem ser alocados; Linhas 15 a 18: cada NFRSoftgoal representado no diagrama como um retngulo com bordas tracejadas que possui os atributos id, name e NFRSoftgoalPriority; Linha 38 e 43: representam os links de contribuio OR e AND entre NFRSoftgoals. Sua representao grca uma linha contnua preta com os labels OR ou AND; Linhas 48, 53, 58, 63 e 68: representam os links de contribuio Break, Make, Equal, Hurt e Help entre variantes e NFRSoftgoals respectivamente. Sua representao grca 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 =" r o u n d e d " , b o r d e r . c o l o r = " 0 , 0 , 0 " , s i z e = " 5 0 0 , 2 0 0 " )

73
2 3 4 5 6 7

8 9 10 11 12 13 14 15

c l a s s NFRModel{ a t t r S t r i n g [ 1 ] name ="NFR Model " ; @gmf . c o m p a r t m e n t v a l NFRElement [ * ] n f r e l e m e n t s ; val NFRSoftgoalContribution [*] c o n t r i b u t i o n s ; val NFRSoftgoalContributionOperational [*] contributionsOperationals ; } c l a s s NFRElement { ! o r d e r e d a t t r S t r i n g [ 1 ] name ; id attr String [1] ~id ; } @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 = " 1 0 0 , 3 0 " , 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 a s h " ) c l a s s N F R S o f t g o a l e x t e n d s NFRElement { ! ordered attr EBigInteger [1] NFRSoftgoalPriority = "0"; } 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 e x t e n d s NFRElement { } c l a s s NFRLink { } 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 e x t e n d s NFRLink { ! o r d e r e d r e f NFRSoftgoal [ 1 ] s o u r c e ; ! o r d e r e d r e f NFRSoftgoal [ 1 ] t a r g e t ; }

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

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 e x t e n d s NFRLink { ! ordered ref Variant [1] source ; ! o r d e r e d r e f NFRSoftgoal [ 1 ] t a r g e t ; } @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 " ) c l a s s OrContribution extends NFRSoftgoalContribution { a t t r S t r i n g name ="OR " ; }

39 40 41

74
42 43

44 45 46 47 48

@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 " ) c l a s s AndContribution extends NFRSoftgoalContribution { a t t r S t r i n g name ="AND" ; } @gmf . l i n k ( t a r g e t . d e c o r a t i o n =" a r r o w " , 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") c l a s s BreakContribution extends NFRSoftgoalContributionOperational { a t t r S t r i n g name=" "; } @gmf . l i n k ( t a r g e t . d e c o r a t i o n =" a r r o w " , 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") c l a s s MakeContribution extends NFRSoftgoalContributionOperational { a t t r S t r i n g name = " + + " ; } @gmf . l i n k ( t a r g e t . d e c o r a t i o n =" a r r o w " , 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") c l a s s EqualContribution extends NFRSoftgoalContributionOperational { a t t r S t r i n g name = " = " ; } @gmf . l i n k ( t a r g e t . d e c o r a t i o n =" a r r o w " , 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") c l a s s HurtContribution extends NFRSoftgoalContributionOperational { a t t r S t r i n g name =" "; } @gmf . l i n k ( t a r g e t . d e c o r a t i o n =" a r r o w " , 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") c l a s s HelpContribution extends NFRSoftgoalContributionOperational { a t t r S t r i n g name = " + " ; }

49 50 51 52 53

54 55 56 57 58

59 60 61 62 63

64 65 66 67 68

69 70 71

75

3.1.2

Sintaxe Concreta

Na seo anterior, ns descrevemos a sintaxe abstrata da linguagem de modelagem. Analisamos as trs vises da abordagem BVCCoN, identicamos alteraes no metamodelo e realizamos essas alteraes. Sempre buscando a coerncia entre a sintaxe abstrata e concreta. Nesta seo, iremos descrever a sintaxe concreta para as vises citadas anteriormente. O modelo de processo de negcio j possui uma sintaxe concreta denida no metamodelo BPMN 2.0, por isso, no ser necessrio descrever a sintaxe concreta do BPMN.

3.1.2.1

Variabilidade

Os principais conceitos relacionados variabilidade, so os VariationPoints e as Variants. Os VariationPoints esto associados aos elementos de uxo do BPMN, indicam onde o ponto de variao comea, onde termina e quais so os elementos pertencentes ao ponto de variao. Estas informaes so armazenas pelos atributos Begins, Ends e FlowElements do ponto de variao. Na sintaxe concreta, denimos que a notao grca de VariationPoint armazenar informaes como Id, Name, os operadores lgicos AND, OR e XOR e as variantes que fazem parte do ponto de variao. O operador lgico de um ponto de variao est relacionado com as variantes, por exemplo, o operador AND indica que todas as variantes daquele ponto de variao podem ser selecionadas. Analisando a Figura 3.11, o ponto de variao VP0 possui o operador AND, portanto, as variantes Realizar Vericao de Segurana e Realizar Vericao Extra de Segurana podem ser selecionadas simultaneamente. Interessante observar que existe um link chamado Requires entre a variante Realizar Vericao Extra de Segurana e a variante Realizar Vericao de Segurana. Isto indica que a presena de Realizar Vericao Extra de Segurana requer obrigatoriamente a presena da variante Realizar Vericao de Segurana. Para identicar os pontos de incio e m de um ponto de variao e os elementos que faro parte do mesmo, necessrio importar um modelo de processo de negcio na ferramenta. Assim, o ponto de variao ter acesso aos elementos de uxo do processo que foi modelado. O processo de referncia importado o da Figura 4.1, que apresenta as atividades para realizar check-in em um aeroporto. A Figura 3.11 tambm apresenta os elementos da sintaxe concreta (a) e abstrata (b). Observe que VariationPoint (1) est conectado aos FlowElements (2) representados pelas tarefas Realizar Vericao de Segurana e Realizar Embarque e est associado

76 com as Variants (3) Realizar Vericao de Segurana e Realizar Vericao Extra de Segurana.

Figura 3.11 Sintaxe concreta do Ponto de Variao.

A associao entre um VariationPoint e uma Variant feito atravs de um link, onde o source a variante e o target o ponto de variao. Similar a um VariationPoint, uma Variant possui elementos de uxo modelados em BPMN. Essa associao ocorre atravs da indicao sobre onde a variante comea, onde termina e quais os elementos de uxo

77 pertencentes quela variante. Assim, importa-se o modelo BPMN e a variante ter total acesso aos elementos que foram modelados. As variantes tambm podem se relacionar entre si. Isto ocorre com os links Requires e Excludes. O primeiro, quando uma variante est presente, requer que a outra tambm esteja. A segunda o inverso, quando determinada variante est presente, a outra excluda. Para informar em como uma Variant ser alocada em um novo processo, necessrio associ-la a um WorkowPattern, que pode ser: Sequence, Parallel, dentre outros. Uma variante tambm est associada a um ou mais contextos. A Figura 3.12 mostra um exemplo utilizando um processo de emergncia quanto a existncia de fogo. Este processo foi descrito na seo 2.2.2 e pode ser encontrado na Figura 2.2. A prxima tarefa do processo aps Vericar Risco e Resgatar qualquer pessoa em perigo Tocar o alarme de Incndio. O ponto de variao da Figura 3.12 est apontando para tarefa Tocar o alarme de Incndio 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 a Variant Tocar Alarme de Fogo Automaticamente (1), est conectada ao VariationPoint VP0 (5) e est associada ao FlowElement (3) Tocar Alarme de Fogo Automaticamente. Tambm est conectada ao WorkowPattern (4) EXCLUSIVE_CHOICE. (2) so as propriedades da variante Tocar Alarme de Fogo Automaticamente. Esta variante est apontando seus atributos Begins e Ends para uma tarefa BPMN tambm chamada Tocar Alarme de Fogo Automaticamente. Como os atributos Begins e Ends apontam para uma nica tarefa, o atributo FlowElements s contm uma tarefa. A Variante Tocar Alarme de Fogo Automaticamente est relacionada com o contexto ServiosDeBackupEstoFuncionando, portanto, esta variante s poder ser selecionada quando este contexto estiver ativo. O atributo IsDefault quer dizer que se no existir outra variante vlida esta ser a escolhida, a ideia deixar sempre um caminho possvel. No caso da variante Tocar Alarme de Fogo Automaticamente, este atributo falso. O tipo de WorkowPattern associado a esta variante o EXCLUSIVE_CHOICE, indicando que os elementos de uxo BPMN da variante sero includos no processo atravs de uma escolha exclusiva. O atributo Var Points indica a qual ponto de variao a variante pertence. O nmero 3 um elemento de uxo BPMN, uma tarefa que faz parte da variante e, por m, nmero 4 o WorkFlowPattern que est associado a variante.

78

Figura 3.12 Sintaxe concreta de uma Variante.

3.1.2.2

Requisitos No-Funcionais

A perspectiva de Requisitos No-Funcionais foi adaptada do NFRFramework [30]. De acordo com este framework, os NFRSoftgoals so ns em formatos de nuvens que so associados por NFRSoftgoalContribution e pelos links NFRSoftgoalCorrelation. Simplicamos a notao visual trocando o smbolo da nuvem por um retngulo com bordas

79 tracejadas e vrtices arredondados, am de que a ferramenta desenhe adequadamente, alm de otimizar o tempo no desenvolvimento da mesma. Quando dois NFRSoftgoals so conectados, so utilizados os links AndContribution e OrContribution. Ambos so representados por um link com um label AND e OR respectivamente. Por outro lado, quando NFRSoftgoals conectam NFROperationalization, as contribuies so MakeContribution, HelpContribution, EqualContribution, HurtContribution e BreakContribution. Representados gracamente por links com os respectivos labels: ++, +, =, - e - -. No NFRFramework, NFROperationalization possui a mesma representao de NFRSoftgoal, uma nuvem, porm, com bordas mais slidas. Em nosso caso, o que ir representar as operacionalizaes so as Variants. A representao grca das variantes podem ser encontradas na seo 3.1.2.1. A Figura 3.13 apresenta um exemplo levando em considerao o processo de check-in em aeroporto (ver Figura 4.1), mais especicamente a tarefa Realizar Vericao de Segurana do processo. O requisito no-funcional que levado em considerao o Segurana, que decomposto em outros RNFs. A variante Realizar Vericao Extra de Segurana e suas ligaes de contribuies com os Softgoals tambm so exibidas. Neste caso, se a variante Realizar Vericao Extra de Segurana for ativada e os elementos de uxo BPMN pertencentes a esta variante forem inclusos no processo principal, ela ir contribuir positivamente para a Condencialidade e Controle de Acesso, gerando Segurana para o processo de negcio. A Figura 3.13 descreve os elementos da sintaxe concreta (a) e a sintaxe abstrata (b). O compartimento NFRModel (1) responsvel por armazenar os NFRSoftgoals, ou seja, a viso de requisitos no-funcionais e suas associaes estaro presentes dentro deste compartimento. O NFRSoftgoal (2) com o label Condencialidade est conectado aos NFRSoftgoals Condencialidade Interna e Condencialidade Externa por meio do link AndContribution (3). O NFRSoftgoal Condencialidade Interna est recebendo um MakeContribution (4) da Variant Realizar Vericao Extra de Segurana. Por ltimo, (5) exibe as propriedades do Softgoal, Id, Name e a prioridade, que devero ser denidas pelo analista. 3.1.2.3 Contexto

Uma expresso de contexto composta por uma frmula de predicados. Os predicados so: Statement, Fact e PredicateDecomposition. A representao grca de um Statement pode ser ligado a uma ContextExpression para indicar que a mesma a raiz da anlise.

80

Figura 3.13 Sintaxe concreta de RNF.

Essa ligao realizada atravs de um link chamado CELink que signica ContextExpressionLink. Os atributos de um Statement so um Id e um texto para descrever o elemento. Um Statement pode receber links de Facts ou de outros PredicateDecomposition. O tipo de link que realiza ligaes entre PredicateDecomposition o PredicateLink. Os Facts esto associados s Variables, que contm informaes que podem ser monitoradas

81 durante a congurao do processo de negcio. Quando necessrio decompor a expresso de contexto, pode-se utilizar os operadores AndDecomposition, OrDecomposition e NotDecomposition. Uma das maneiras de realizar check-in para embarcar em um avio faz-lo online. A Figura 3.14 apresenta informaes de contexto para avaliar se o check-in online est disponvel. O contexto C_0 est implicito pelo Statement S0: check-in online est disponvel. O Statement apoiado por uma decomposio que termina fatos. Os fatos InternetEstOn e Sistema de Checkin Est Funcionando podem ser avaliados como verdadeiro ou falso e o Statement apoiado por estes fatos podem ser validados. A Figura 3.14 descreve o modelo de contexto apresentando a sintaxe grca concreta (a) e a sintaxe abstrata (b). Os nmeros marcados indicam a ContextExpression (1), o Statement (2) representado pela forma S0: check-in online est disponvel, um PredicateDecomposition (3) com o operador AND, os Facts (4) com as descries InternetEstOn e Sistema de check-in est funcionando e por ltimo, as Variables (5) InternetEstOn e Sistema de check-in est funcionando.

3.2

A Ferramenta

Nesta seo apresentamos uma viso geral da ferramenta, visto que os detalhes encontramse disponveis no apndice A. A Figura 3.15 apresenta o editor da ferramenta BVCCoN-Tool. composta por uma rea de trabalho onde sero criados os modelos de requisitos no-funcionais, variabilidade e informao contextual e direita um menu, onde encontram-se os elementos necessrios para a realizao da modelagem: Variability Nodes, Variability Links, Models, ContextNodes, Context Links, NFR Node e NFR Links. A Figura 3.16 exibe o menu de seleo com mais detalhe. Os modelos que sero exibidos em seguida so de exemplos citados anteriormente, portanto, dispensa apresentaes, com exceo do modelo de contexto. A Figura 3.17 exibe um compartimento NFR Model com 5 NFRSoftgoals inseridos. Eles esto relacionados atravs do link de contribuio AndContribution. A Figura 3.18 apresenta o mesmo modelo da Figura 3.17, com a diferena que existe a incluso do modelo de variabilidade. Neste outro modelo, um ponto de variao e duas variantes so inseridas. Os links de contribuio MakeContribution e HelpContribution so utilizados para realizar as ligaes entre Variants e NFRSoftgoal. O padro de WorkowPattern que est associado com as

82

Figura 3.14 Sintaxe concreta de Contexto.

variantes o comportamento SEQUENCE. Por ltimo, as variantes esto associadas com o ponto de variao. O modelo da Figura 3.19 apresenta um exemplo de informao de contexto para avaliar se o alerta de segurana est alto. O Contexto C_0 est implcito pelo Statement

83

Figura 3.15 Editor da Ferramenta BVCCoN-Tool

Figura 3.16 Menu de seleo da ferramenta

S0: Alerta de Segurana Est Alta. Este Statement apoiado pelo fato F0: Alerta de Segurana, que pode ser avaliado como verdadeiro ou falso. Caso esta informao de contexto seja verdadeira, a variante Realizar Vericao Extra de Segurana ativada e

84 os elementos de uxo BPMN pertencentes a esta variante so inseridos no modelo de processo de negcio principal de forma sequencial, j que o WorkowPattern associado o SEQUENCE. Por m, a Figura 3.20 apresenta um modelo BVCCoN com todas as informaes representadas, requisitos no-funcionais, variabilidade e informaes contextuais.

Figura 3.17 Modelo RNF

Figura 3.18 Modelo RNF e Variabilidade

85

Figura 3.19 Modelo de Contexto

Figura 3.20 Modelo BVCCoN

3.3

Restries EVL

Alm das restries impostas pelo metamodelo, tambm criamos algumas restries EVL ao nvel de algumas ligaes entre elementos. A Listagem 3.4 apresenta as restries EVL que foram utilizadas. Linha 2, 10, 17 e 35: essas restries foram utilizadas com o objetivo de evitar ligaes de um elemento (Softgoal, Predicados e Variantes) para ele prprio. Para isto, a expresso EVL if(self.source = self.target) return false; foi utilizada, ou seja,

86 o ponto inicial e o nal de uma ligao no podem ocorrer no mesmo elemento; Linha 26: esta restrio foi realizada com o intuito de evitar que mais de um link saia do elemento PredicateDecomposition, deixando a semntica da linguagem correta. A Expresso EVL foi a seguinte: if(PredicateLink.allInstances()->select(p | p.source = self)->size()>1) return false;. analisado cada instncia do elemento e vericado a quantidade de links que partem dele.
Listagem 3.4 Restries EVL
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

21

22 23 24 25 26 27 28 29

context AndContribution { c o n s t r a i n t notTheSameTargetAndSource { check { i f ( s e l f . source = s e l f . t a r g e t ) return f a l s e ; else return true ; } message : T h i s k i n d o f l i n k i s n o t a l l o w e d . }} context OrContribution { c o n s t r a i n t notTheSameTargetAndSource { check { i f ( s e l f . source = s e l f . t a r g e t ) return f a l s e ; else return true ; } message : T h i s k i n d o f l i n k i s n o t a l l o w e d . }} context PredicateLink { c o n s t r a i n t notTheSameTargetAndSource { check { i f ( s e l f . source . isKindOf ( PredicateDecomposition ) and s e l f . t a r g e t . i s K i n d O f ( PredicateDecomposition ) ) return true ; i f ( s e l f . source . type = s e l f . t a r g e t . type ) return false ; else return true ; } message : T h i s k i n d o f l i n k i s n o t a l l o w e d . }} context PredicateDecomposition { c o n s t r a i n t onlyOneLeavingTheShape { check { 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 ;

87
30 31 32

else return true ; } message : Only one P r e d i c a t e L i n k c a n l e a v e t h i s s h a p e } } context VariantsRelationship { c o n s t r a i n t NotTheSameSourceAndTarget { check { if ( self . relationshipSource = self . relationshipTarget ) return false ; else return true ; } message : T h i s k i n d o f r e l a t i o n s h i p i s n o t a l l o w e d } }

33 34 35 36 37 38

39 40 41 42 43

3.4

Consideraes do Captulo

Nesta seo, foi apresentado o metamodelo da ferramenta BVCCon-Tool, assim como a sintaxe concreta e abstrata da linguagem de modelagem. Apresentamos as vises de requisitos no-funcionais, variabilidae e informao contextual da abordagem BVCCoN atravs de metamodelos UML e tambm na linguagem Emfatic. Por m, apresentamos a ferramenta e algumas restries EVL que foram utilizadas a nvel de ligaes entre elementos.

89

4
Avaliao
Nesta seo, descrevemos o teste de usabilidade que foi realizado com o intuito de avaliar a ferramenta proposta nesta dissertao e tambm um exemplo de uso, com o objetivo de vericar a expressividade da ferramenta, se a sintaxe abstrata denida no metamodelo se mantinha nos modelos criados com a ferramenta.

4.1

Cenrio: Check-In Aeroporto

O cenrio utilizado para realizar o exemplo de uso e a avaliao de usabilidade, foi o processo de Check-In em aeroportos, o mesmo que foi usado em [48] para avaliar a abordagem BVCCoN proposta. Check-In, geralmente o primeiro procedimento que realizado por um passageiro quando ele chega em um aeroporto. As companhias areas requerem que o passageiro realize o check-in um certo tempo antes do horrio do vo, que pode durar entre 30 minutos a 4 horas, dependendo do destino e da companhia area. Muitas atividades relacionadas ao processo de check-in so teis e relevantes para a denio de um modelo de processo de negcio. Por exemplo: polticas de check-in e procedimentos de segurana, movimentao de passageiros e validao da documentao. As opes de check-in e procedimentos podem variar de acordo com a companhia area, algumas possuem certas restries que outras no. Ocasionalmente a mesma companhia em diferentes aeroportos podem ter diferentes procedimentos de check-in. Este tipo de processo realizado em um ambiente altamente dinmico, que pode ser afetado por diversos fatores como a quantidade de passageiros, polticas de segurana, clima, dentre outros. No cenrio descrito acima, poderia ser til congurar o processo de acordo com as mudanas de contexto, levando em considerao as preferncias de qualidade associadas com o processo de check-in.

90

4.2
4.2.1

Exemplo de Uso
Processo de Referncia

A Figura 4.1 apresenta o processo de referncia que servir de apoio para as etapas seguintes. O processo de check-in comea quando um passageiro chega em um aeroporto e dirige-se ao gabinete da companhia. A equipe da companhia area comea identicando o passageiro e o voo. Depois disso, o check-in realizado e um carto de embarque impresso. Se existir bagagem para ser enviada ao compartimento de carga da aeronave, feito o envio nesta etapa. Em seguida, o passageiro pode ir ao posto de segurana, onde a equipe vericar seus dados. Finalmente, o passageiro conduzido para o porto de embarque.

Figura 4.1 Processo de Referncia

Para as prximas sees assumimos que o leitor conhece a abordagem BVCCoN [48] e focaremos apenas nos aspectos de modelagem, que o objetivo deste estudo.

4.2.2

Elicitao da Variabilidade

Esta etapa comea a partir da anlise do processo de referncia, com o objetivo de identicar atravs de uma srie de perguntas as variantes do processo. Logo, possvel encontrar algumas variaes na maneira como o processo executado. A partir dos dados encontrados nesta etapa, eles sero analisados e ento representados como pontos de variaes e variantes.

4.2.3

Descrio da Variabilidade

Um ponto de variao indica em qual parte do processo de negcio as mudanas podem acontecer. Os termos begins e ends so usados para indicar onde o ponto de variao comea e onde termina. A Figura 4.2 mostra a representao grca produzida por nossa ferramenta dos pontos de variaes no processo de referncia. Por exemplo, o ponto de variao VP1 comea na tarefa Vericar Informao de Voo e termina na tarefa Emitir

91 Carto de Embarque, o VP2 comea e termina na tarefa Realizar Embarque e o VP3 comea e termina ta tarefa Realizar Vericao de Segurana. Ento, todos os elementos localizados entre essas tarefas incluindo elas mesmas, podem ser substitudas por variantes. Nossa ferramenta no permite que o processo de negcio representado na Figura 4.2 seja modelado. Ele importado na ferramenta e atravs de um apontamento conseguimos setar os atributos begins e ends. No Apndice A explicado o passo a passo dessa importao e de como acessar as tarefas do modelo BPMN.

92

Figura 4.2 Pontos de Variao no Processo de Referncia

93 Cada ponto de variao possui variantes associadas. O ponto de variao VP1 que corresponde as tarefas de Check-In possui trs variantes, Realizar Check-In, Realizar Check-In Manualmente e Realizar Check-In Online. O ponto de variao VP2 corresponde a tarefa Realizar Embarque e tambm possui trs variantes associadas, Embarcar usando escada, Embarcar usando ponte e Atrasar embarque. Por ltimo, o ponto de variao VP3 que corresponde a tarefa Realizar vericao de segurana possui duas variantes associadas, Executar vericao de segurana e Executar vericao de segurana extra. A Figura 4.3 exibe as associaes entre variantes e os fragmentos de processos de negcio que sero includos no processo principal caso a variante seja ativada. Como pode ser visto, variantes podem apontar para apenas uma tarefa, como em var4, ou para um conjunto de elementos de processos, como em var1. Em alguns casos, uma variante pode requerer ou excluir a presena de outra variante. De acordo com a Figura 4.3 a variante var8 Realizar Vericao de Segurana Extra requer a presena da variante var7 Realizar Vericao de Segurana, pois existe uma ligao entre as duas com o link Requires.

94

Figura 4.3 Pontos de Variao e Variantes com partes de Processos de Negcio

95

4.2.4

Anlise de Contexto

Aps realizar a descrio de variabilidade, a prxima etapa descrever as informaes contextuais e associ-las s variantes do processo. A Figura 4.4 exibe trs rvores de contexto e suas associaes com as variantes. O contexto C0 est ligado com as variantes var1 (Realizar Check-In) e var3 (Realizar Check-In Online), o contexto C1 com a variante var3 e, por ltimo, o contexto C2 com a variante var6 (Embarcar usando ponte). Os seguintes contextos foram mapeados: Check-In Online est Disponvel: Em alguns casos o check-in pode estar indisponvel. A companhia pode optar por fazer o check-in de maneira manual. Mesmo se os servios de internet e os quiosques no estiverem funcionando, o passageiro ainda ser capaz de realizar o check-in no balco da companhia. Para que este contexto seja ativado, necessrio que os fatos InternetEstOn e SistemaDeCheckinFuncionando sejam avaliados como verdadeiros. Internet e Quiosque esto funcionando: Algumas companhias permitem a realizao do check-in atravs da internet ou oferencendo quiosques para os passageiros. Este contexto ativado quando os fatos InternetEstOn e QuiosqueDoAeroportoEstOn forem verdadeiros. Ponte est Disponvel: Alguns aeroportos possuem pontes que permite os passageiros embarquem no porto sem a necessidade de ir diretamente at a aeronave. Essas pontes permitem um embarque mais rpido, porm, no esto disponveis em todos os aeroportos. Este contexto ativado quando o fato PonteEstDisponvel verdadeiro. Quando um contexto verdadeiro, a ou as variantes que esto relacionadas com o contexto so ativadas e os elementos de uxo BPMN pertencentes as variantes podem ser inseridos no processo de negcio principal. A maneira como os elementos so inseridos dependem do padro de Workow que foi determinado anteriormente.

4.2.5

Anlise de Requisitos No-Funcionais

A ltima etapa da fase de modelagem a associao das variantes com os atributos de qualidade. Eles so utilizados para expressar como as variantes podem afetar a congurao do processo. A Figura 4.5 mostra a anlise de contribuio para Performance, Conabilidade e Segurana.

96

Figura 4.4 Anlise de Contexto

O RNF Performance decomposto em outros dois, Espao de Performance e Tempo de Performance, que por sua vez decomposto em mais dois RNFs, Throughput e Tempo de Resposta. Conana o RNF que decomposto em Disponibilidade, Preciso e Tolerncia falhas, por ltimo, o RNF Segurana decomposto em Controle de Acesso e Condencialidade. Este decomposto em Condencialidade Interna e Condencialidade Externa.

Figura 4.5 Requisitos No-Funcionais e Anlise de Contribuio

97

98
Tabela 4.1 Contribuio dos RNFs

NFR Throughput Tempo de Resposta Disponibilidade Preciso Controle de Acesso Condencialidade Interna Condencialidade Externa

var1 + ++ + +

var2 + +

var3 ++ ++ ++ ++

var4 + +

var5 -

var6 ++

var7 -

var8

+ + +

++ ++ ++

A variante Executar vericao de segurana contribui positivamente para Controle de Acesso, reduzindo o acesso de pessoas que no deveriam entrar na rea de embarque. Contudo, esta mesma variante contribui negativamente para Performance, j que reduz a velocidade do processo. A Tabela 4.1 apresenta as contribuies da Figura 4.5, permitindo uma melhor visualizao. Os espaos em branco so compreendidos como EqualContribution (=). Uma possvel melhoria na ferramenta BVCCoN-Tool seria permitir o usurio realizar as ligaes de contribuies diretamente em uma tabela (ver Tabela 4.1), e assim, na medida que as informaes forem inseridas, as ligaes seriam realizadas automaticamente na forma grca (ver Figura 4.5). Desta maneira, a usabilidade da ferramenta seria melhorada, assim como a visualizao das informaes.

4.3
4.3.1

Teste de Usabilidade
The Post-Study System Usability Questionnaire

O estudo proposto por [31] apresenta quatro mtodos para avaliar a usabilidade de sistemas. O mtodo The After-Scenario Questionnaire - (ASQ) baseado em cenrios, ou seja, os usrios devem executar um cenrio e em seguida responder a trs questes, assim por diante, at a quantidade de cenrios acabar. O The Printer-Scenario Questionnaire - (PSQ) uma verso antiga do ASQ. Tambm baseada em cenrios e possui um questionrio com apenas trs questes. O terceiro mtodo o The Computer System Usability Questionnaire - (CSUQ) e indicado para quando o estudo de usabilidade em um ambiente que no seja em laboratrio. O ltimo mtodo o PSSUQ (The Post-Study System Usability Questionnaire). Este mtodo permite calcular quatro diferentes fatores a partir das respostas obtidas do questionrio de avaliao. Os 4 fatores so: satisfao geral, utilidade do sistema, qualidade da

99 informao e qualidade da interface. Optamos escolher este mtodo (Apndice C) por ser o que est de acordo com nosso contexto, ele baseado em um conjunto de tarefas com o usurio respondendo o questionrio aps a execuo de todas as tarefas. indicado para testes de usabilidade em ambientes laboratoriais e possui quatro fatores que podem ser avaliados, permitindo uma avaliao de usabilidade mais ampla. O questionrio do mtodo PSSUQ composto por dezenove ndices, organizada em sete itens de resposta que esto em uma escala grca de 7 pontos, que varia de "Discordo totalmente"com valor 7 e "Concordo totalmente"com valor 1. A partir deste mtodo, adotamos apenas o questionrio, j que permite uma avaliao de usabilidade mais ampla abrangendo quatro diferentes fatores, contudo, zemos uma adaptao em virtude de sabermos que quanto maior a escala, mais difcil dos participantes a interpretarem [50]. Por esta questo e tambm pela quantidade dos participantes na avaliao da usabilidade, optamos reduzir para uma escala Likert de cinco nveis: concordo fortemente, concordo, neutro, discordo e discordo totalmente. Tambm poderamos elaborar nosso prprio questionrio, incluindo nossas prprias perguntas, porm, vrios desaos seriam encontrados, por exemplo: Utilizar linguagem apropriada para a populao; Cada pergunta deve cobrir exatamente um conceito; Evitar respostas vagas e ambguas; Balancear as perguntas positivas e negativas. Alm disso, o questionrio deve ser validado antes de sua utilizao. Segundo [8], o melhor utilizar instrumentos de outras pessoas, visto que j foram validados e, alm disso, torna mais fcil a anlise dos resultados da pesquisa. Por esta razo, decidimos escolher um questionrio que j foi validado e amplamente utilizado.

4.3.2

Usurios

Os usurios que participaram do teste de usabilidade so alunos de ps-graduao em Cincia da Computao da instituio Universidade Federal de Pernambuco. Eles estavam cursando a disciplina de Engenharia de Requisitos e, portanto, possuiam algum contato com ferramentas de modelagem. Ao todo, 15 foram os usurios que participaram do teste.

100

4.3.3

Equipamentos e Ambiente

Os equipamentos utilizados na realizao do teste de usabilidade esto descritos na Tabela 4.3.3.

Tabela 4.2 Equipamentos utilizados para realizao do teste

Equipamento Computador Pessoal Softwares Bsicos

Caractersticas Os componentes de hardware do teste foram computadores pessoais (monitor, gabinete, teclado e mouse). Windows 7, 64 bits, 8GB Ram, Processador AMD Phenom (tm) II X4 B97 3.20 GHz, eclipse Kleper Build id:20130614-0229

Um ambiente real foi utilizado para a realizao do teste: o laboratrio de computadores do Centro de Informtica da Universidade Federal de Pernambuco. Os computadores foram previamente congurados com a verso do eclipse Kepler, a qual foi utilizada para desenvolver a ferramenta. Assim, possveis erros de compatibilidade foram evitados, deixando o usurio focado apenas nas tarefas do teste de usabilidade.

4.3.4

Tarefas

Para esta avaliao, os usurios tiveram que realizar uma sequncia de tarefas cujo objetivo era a construo de parte do cenrio de check-in de um aeroporto, visto que o cenrio completo exige mais tempo para a execuo do teste. Este cenrio foi escolhido visando explorar a utilizao do mximo de recursos que a ferramenta oferece. As tarefas envolvem a modelagem de ponto de variao, variantes, relacionamento entre o ponto de variao e variante, a denio do WorkowPattern, que representa a maneira como as variantes sero alocadas em um novo processo, a importao de modelos BPMN, a modelagem de requisitos no-funcionais e informaes contextuais e os relacionamentos entre os requisitos e informaes de contexto com uma variante. As tarefas de usurio que foram utilizadas para o teste podem ser consultadas no Apndice B.

4.3.5

Processo de Coleta dos Dados

Devido a complexidade da abordagem BVCCoN, no dia 26/11/2013 foi apresentado um seminrio com o objetivo de deixar os usurios cientes do teste. A abordagem foi breve-

101 mente apresentada, assim como uma introduo da ferramenta e suas funcionalidades. A coleta de dados foi realizada no dia 29/11/2013 das 10:00h s 12:00h. Inicialmente, cada usurio foi direcionado para um computador onde o eclipse Kleper j estava aberto e pronto para a inicializao do teste. Tambm foi entregue para cada usurio a lista de tarefas a serem realizadas (Apndice B) e um manual da ferramenta (Apndice A). Em seguida, foram apresentadas aos usurios as seguintes regras para a realizao do teste usabilidade: 1. Seguir a lista de tarefas, executando-as em sequncia; 2. Em caso de dvida na realizao de alguma tarefa, consultar o manual da ferramenta; 3. Se a dvida persistir, tentar executar a tarefa da maneira que achar que est correto; 4. Se a tentativa anterior fracassar, pedir auxlio ao monitor; 5. Aps nalizar o teste, acessar o formulrio online disponvel em: http:goo.glQ5eoB0 e respond-lo de acordo com as tarefas que foram executadas (o formulrio encontra-se no Apndice C); 6. Aps a concluso destas etapas, o teste foi nalizado. O teste iniciado aps o instrutor autorizar a inicializao.

4.3.6

Resultados

Para analisar os dados coletados no questionrio, utilizamos o mtodo proposto por [34]. Visto que nosso objetivo no escolher o melhor mtodo para avaliar os dados coletados, no zemos comparaes entre mtodos. O mtodo descrito em [34] visa analisar resultados obtidos em questionrios na forma de escala de Likert. A Tabela 4.3 apresenta os dados coletados do questionrio. As respostas foram dadas por 15 participantes (A-O) a um questionrio de 19 itens. A parte direita da tabela exibido a soma da quantidade de respostas de cada participante agrupadas pelos pontos da escala Likert [33], ou seja, demonstra quantas vezes cada participante escolheu 5, 4, 3, 2, e 1 como resposta. Para identicar o nmero que corresponder a "sem opinio", calculamos a mdia como se todas as respostas para todos os ndices fossem 3. Ou seja, Media = (19 3)

102 onde 19 o total de itens e 3 o nmero que corresponde a neutro, "sem opinio". Neste caso, o resultado 57. Analisando a Tabela 4.3, o participante K atingiu o total de 58 pontos, muito prximo do nmero 57, que corresponde a "sem opinio". Ainda analisando a Tabela 4.3, identicamos que o participante L no mostrou coerncia em suas respostas, marcando "concordo totalmente"para os 19 itens do questionrio, tornando um vis para a pesquisa. Por isso, ele foi excludo das prximas anlises. O restante dos participantes que responderam o questionrio mostraram coerncia em suas respostas. De acordo com mtodo utilizado para analisar os dados [34], importante observar que a identicao de participantes que no mostram coerncia em suas respostas realizada de forma manual, fazendo comparaes com as respostas de outros participantes. Por isso, pode ocorrer certo vis durante a anlise manual, tornando um ponto negativo do mtodo usado.

A B C D E F G H I J K L M N O

1 5 4 4 4 5 4 4 4 4 5 2 5 4 3 4

2 4 4 3 4 5 4 4 4 4 5 3 5 4 3 4

3 5 5 4 4 5 4 4 4 5 5 4 5 2 4 3

4 4 5 5 3 5 3 4 4 5 4 2 5 4 3 4

5 4 5 5 3 5 4 4 3 3 5 3 5 4 4 3

6 4 4 3 4 4 4 3 4 4 4 1 5 3 3 4

7 5 4 4 4 4 4 4 4 4 4 3 5 3 4 4

8 4 4 3 2 5 2 4 4 4 3 2 5 2 4 4

9 3 3 3 3 5 3 3 3 4 1 3 5 4 2 3

10 3 3 3 3 5 3 3 4 3 2 4 5 4 3 4

11 5 3 5 3 3 4 4 4 3 4 4 5 4 4 4

Tabela 4.3 Respostas dos Participantes 12 13 14 15 16 17 18 19 Total 4 5 5 4 5 5 5 4 83 4 4 4 4 4 5 4 5 78 5 3 5 5 4 3 4 4 75 4 4 4 4 4 2 3 3 65 3 4 4 4 4 4 4 5 83 3 3 3 3 4 4 4 4 67 4 4 4 4 4 4 4 4 73 4 4 3 4 4 4 4 4 73 4 4 4 4 4 4 4 4 75 3 5 4 5 4 4 3 4 74 4 3 3 4 4 3 3 3 58 5 5 5 5 5 5 5 5 95 4 4 4 4 4 3 4 4 69 3 4 4 4 3 3 3 3 64 4 4 3 4 3 4 4 4 71

5 9 5 6 0 9 0 0 0 2 6 0 19 0 0 0

4 8 11 6 10 8 11 16 16 14 8 6 0 14 8 14

3 2 3 7 7 2 7 3 3 3 3 9 0 3 10 5

2 0 0 0 2 0 1 0 0 0 1 3 0 2 1 0

1 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0

103

104 4.3.6.1 Satisfao Geral

A Tabela 4.4 apresenta os dados com o participante L j excludo, assim, podemos continuar com a anlise. Utilizando a Tabela 4.4, calculamos a mdia de todas as respostas obtidas. Somamos os dados da coluna "Total"e dividimos pelo total de participantes. Assim sendo: Media = (1008/14), cujo resultado 72. Portanto, a mdia de todos os participantes superior a mdia 57 ("sem opinio"), implicando que de uma maneira geral nossa ferramenta foi bem aceita pelos participantes. Desta forma, o primeiro fator que queremos calcular (satisfao geral) foi respondido. O prximo passo criar os grupos dos participantes que so "favorveis"e os que so "desfavorveis"ao tema em questo. Para isto, zemos uma comparao da mdia que representa "sem opinio", 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 so "desfavorveis"e aqueles com um total superior a 57 no grupo dos "favorveis". No foi possvel criar os dois grupos, visto que todos os participantes so "favorveis", ou seja, esto no grupo dos que concordam que nossa ferramenta possui uma boa usabilidade. Tambm somamos as respostas das colunas, visando identicar os ndices cujas respostas de uma maneira geral foram positivas, negativas, ou os participantes no possuem opinio sobre a mesma. Para realizar esta tarefa, calculamos a mdia de respostas de cada ndice individualmente e comparamos com a mdia se todas as respostas para um ndice fossem 3 ("sem opinio"). Assim, Media = 3 14 onde 3 o nmero que corresponde a neutro, "sem opinio"e 14 o nmero de participantes. Obtemos como resposta o nmero 42. De acordo com a Tabela 4.4, a mdia de todas os itens foram superiores ao nmero 42. Porm, a mdia do item nmero 9 (mdia 43) se aproxima muito do nmero 42, que corresponde a "sem opinio". Portanto, de uma maneira geral, os participantes no possuem opinio sobre o item The system gave error messages that clearly told me how to x problems..

A B C D E F G H I J K M N O 5 4 3 2 1 Total

1 5 4 4 4 5 4 4 4 4 5 2 4 3 4 3 9 1 1 0 56

2 4 4 3 4 5 4 4 4 4 5 3 4 3 4 2 9 3 0 0 55

3 5 5 4 4 5 4 4 4 5 5 4 2 4 3 5 7 1 1 0 58

4 4 5 5 3 5 3 4 4 5 4 2 4 3 4 4 6 3 1 0 55

5 4 5 5 3 5 4 4 3 3 5 3 4 4 3 4 5 5 0 0 55

6 4 4 3 4 4 4 3 4 4 4 1 3 3 4 0 9 4 0 1 49

7 5 4 4 4 4 4 4 4 4 4 3 3 4 4 1 11 2 0 0 55

8 4 4 3 2 5 2 4 4 4 3 2 2 4 4 1 7 2 4 0 47

9 3 3 3 3 5 3 3 3 4 1 3 4 2 3 1 2 9 1 1 43

Tabela 4.4 Satisfao Geral 10 11 12 13 14 15 16 3 5 4 5 5 4 5 3 3 4 4 4 4 4 3 5 5 3 5 5 4 3 3 4 4 4 4 4 5 3 3 4 4 4 4 3 4 3 3 3 3 4 3 4 4 4 4 4 4 4 4 4 4 3 4 4 3 3 4 4 4 4 4 2 4 3 5 4 5 4 4 4 4 3 3 4 4 4 4 4 4 4 4 4 3 4 3 4 4 4 3 4 4 4 4 3 4 3 1 4 8 1 0 47 2 8 4 0 0 54 1 9 4 0 0 53 2 9 3 0 0 55 2 8 4 0 0 54 2 11 1 0 0 57 1 11 2 0 0 55

17 5 5 3 2 4 4 4 4 4 4 3 3 3 4 2 7 4 1 0 52

18 5 4 4 3 4 4 4 4 4 3 3 4 3 4 1 9 4 0 0 53

19 4 5 4 3 5 4 4 4 4 4 3 4 3 4 2 9 3 0 0 55

Total 83 78 75 65 83 67 73 73 75 74 58 69 64 71

5 9 5 6 0 9 0 0 0 2 6 0 0 0 0

4 8 11 6 10 8 11 16 16 14 8 6 14 8 14

3 2 3 7 7 2 7 3 3 3 3 9 3 10 5

2 0 0 0 2 0 1 0 0 0 1 3 2 1 0

1 0 0 0 0 0 0 0 0 0 1 1 0 0 0

Mdia 72

105

106
Tabela 4.5 4 5 6 4 4 4 5 5 4 5 5 3 3 3 4 5 5 4 3 4 4 4 4 3 4 3 4 5 3 4 4 5 4 2 3 1 4 4 3 3 4 3 4 3 4 Utilidade do Sistema 7 8 Total 5 5 4 35 3 4 4 35 3 4 3 31 2 4 2 28 0 4 5 38 6 4 2 29 0 4 4 31 0 4 4 31 0 4 4 33 2 4 3 35 4 3 2 20 0 3 2 26 0 4 4 28 0 4 4 30 0

A B C D E F G H I J K M N O

1 5 4 4 4 5 4 4 4 4 5 2 4 3 4

2 4 4 3 4 5 4 4 4 4 5 3 4 3 4

3 5 5 4 4 5 4 4 4 5 5 4 2 4 3

4 5 5 3 5 2 6 7 7 5 3 1 4 4 6

3 0 0 3 2 0 1 1 1 1 1 3 2 4 2

2 0 0 0 1 0 1 0 0 0 0 3 2 0 0

1 0 0 0 0 0 0 0 0 0 0 1 0 0 0

4.3.6.2

Utilidade do Sistema

Nesta seo, analisamos os itens que correspondem a utilidade do sistema. Neste caso, os itens so aqueles que esto entre 1 e 8. Realizamos todos os procedimentos que foram descritos na seo 4.3.6.1 e encontramos os resultados obtidos na Tabela 4.5. Mdia para todas as respostas com pontuao 3 ("sem opinio"): 24; Comparando o nmero 30,71 que corresponde a mdia de todos os itens de todos os participantes com o nmero 24 que a mdia se todas as respostas fossem 3 ("sem opinio"), conclumos que nossa ferramenta foi considerada til pelos usurios na realizao das tarefas que a mesma se prope a fazer. Para este caso especco (utilidade do sistema), apenas um participante (o K ) faz parte do grupo dos que so "desfavorveis". Ou seja, sua mdia de respostas foi inferior a mdia "sem opinio". Assim, os 13 participantes restantes fazem parte do grupo dos "favorveis". 4.3.6.3 Qualidade da Informao

Nesta seo, analisamos os itens correspondentes a qualidade da informao fornecida pela ferramenta assim como a documentao. Os itens analisados so aqueles entre 9 e 15. Os procedimentos realizados na seo 4.3.6.1 foram repetidos para este caso e os resultados so encontrados na Tabela 4.6. Mdia para todas as respostas com pontuao 3 ("sem opinio"): 21;

107
9 3 3 3 3 5 3 3 3 4 1 3 4 2 3 10 3 3 3 3 5 3 3 4 3 2 4 4 3 4 Tabela 4.6 Qualidade da Informao 11 12 13 14 15 Total 5 5 4 5 5 4 29 3 3 4 4 4 4 25 0 5 5 3 5 5 29 4 3 4 4 4 4 25 0 3 3 4 4 4 28 2 4 3 3 3 3 22 0 4 4 4 4 4 26 0 4 4 4 3 4 26 0 3 4 4 4 4 26 0 4 3 5 4 5 24 2 4 4 3 3 4 25 0 4 4 4 4 4 28 0 4 3 4 4 4 24 0 4 4 4 3 4 26 0 4 2 4 0 4 3 1 5 5 5 2 4 7 4 5 3 2 3 3 3 2 6 2 2 2 1 3 0 2 2 2 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0

A B C D E F G H I J K M N O

Comparando o nmero 25,93 que corresponde a mdia de todos os itens de todos os participantes com o nmero 21 que a mdia se todas as respostas fossem 3 ("sem opinio"), conclumos que nossa ferramenta foi considerada pelos usurios como ofertante de boa qualidade de informao visual, bem como em documentao na realizao das tarefas. Para este caso especco (qualidade da informao), apenas a mdia do participante F (mdia 22) cou muito prximo da mdia "sem opinio"(mdia 21). Ou seja, apenas uma pessoa no possuiu uma opinio bem denida sobre a qualidade da informao da ferramenta. 4.3.6.4 Qualidade da Interface

Para analisar a qualidade da interface, os itens relacionados so os 16, 17 e 18. Mais uma vez repetimos os procedimentos da seo 4.3.6.1 para encontrarmos os dados relacionados a qualidade da informao. A Tabela 4.7 apresenta os resultados que foram alcanados. Mdia para todas as respostas com pontuao 3 ("sem opinio- linhas): 9; Comparando o nmero 11,43 que corresponde a mdia de todos os itens de todos os participantes com o nmero 9 que a mdia se todas as respostas fossem 3 ("sem opinio"), podemos concluir que nossa ferramenta possui uma boa qualidade da interface e que agradvel sua utilizao. Quando comparamos a mdia individual de cada participante com a mdia "sem opinio", identicamos que os participantes D e N possuem a mesma mdia (mdia 9).

108
Tabela 4.7 Qualidade da Interface 16 17 18 Total 5 4 3 5 5 5 15 3 0 0 4 5 4 13 1 2 0 4 3 4 11 0 2 1 4 2 3 9 0 1 1 4 4 4 12 0 3 0 4 4 4 12 0 3 0 4 4 4 12 0 3 0 4 4 4 12 0 3 0 4 4 4 12 0 3 0 4 4 3 11 0 2 1 4 3 3 10 0 1 2 4 3 4 11 0 2 1 3 3 3 9 0 0 3 3 4 4 11 0 2 1

A B C D E F G H I J K M N O

2 0 0 0 1 0 0 0 0 0 0 0 0 0 0

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Tambm identicamos que a mdia do participante K (mdia 10) se aproxima muito da mdia "sem opinio". A partir destas informaes, podemos concluir que 11 participantes (79%) concordam que a ferramenta possui uma boa qualidade de interface e que 3 participantes (21%) no possuem uma opinio bem denida sobre esta questo.

4.4

Ameaas Validade

Algumas ameaas validade foram identicadas durante a execuo de nossa avaliao. A maioria est relacionada com os seres humanos, como por exemplo: rivalidade, motivao, interao entre os participantes, conhecimento da abordagem BVCCoN, dentre outros. Acreditamos que o ltimo item seja a principal ameaa validade na validao de nossa ferramenta. Os participantes no conheciam a abordagem e um pequeno treinamento de 1 hora foi realizado trs dias antes do teste. Para que os participantes adquirissem certo conhecimento sobre a abordagem, seria necessrio dominar 4 reas do conhecimento. A primeira a de requisitos no-funcionais, mais especicamente o NFRFramework, que envolve a decomposio de Softgoals e as contribuies entre Softgoals. A segunda sobre SPL (Software Product Lines) [41], entender os conceitos de pontos de variao e variantes. A terceira domnio sobre a modelagem de processos de negcio, especialmente a notao BPMN. Por ltimo, seria necessrio entender como construir as rvores de contexto.

109 Por este possvel desconhecimento nestas reas, as tarefas de usurio (Apndice B) foram descritas em um nvel de detalhe muito alto. Desta maneira, os participantes seguiram um tutorial bastante detalhado para atingir o resultado esperado. Assim, possveis falhas podem ter sido evitadas, levando os participantes a executarem corretamente as tarefas de usurio e consequentemente a responder o questionrio (Apndice C) com respostas positivas (Seo 4.3.6).

4.5

Consideraes Finais

A ferramenta BVCCoN-Tool, modelada e descrita no captulo 3 desta dissertao segundo o Framework Epsilon [12] e seu conjunto de linguagens, foi avaliada neste captulo. A ferramenta BVCCoN-Tool tem como objetivo permitir a modelagem das trs vises da abordagem proposta por [48] sobre congurao de processos de negcio dinmicos. Essas vises so a de requisitos no-funcionais, variabilidade e descrio das informaes de contexto. O objetivo foi apresentar a utilizao da ferramenta visando avaliar sua expressividade e tambm realizar um teste de usabilidade com usurios reais. Na aplicao do exemplo de uso e no teste de usabilidade, a ferramenta se comportou de forma apropriada. No exemplo de uso, a ferramenta conseguiu representar as informaes necessrias, enquanto na avaliao de usabilidade, a ferramenta mostrou possuir uma boa usabilidade em todos os aspectos: satisfao geral, utilidade do sistema, qualidade da informao e qualidade da interface.

111

5
Concluses e Trabalhos Futuros
Esta seo apresenta as concluses nais do estudo desta dissertao, resumindo todos os passos realizados para o desenvolvimento da ferramenta. Tambm apresentamos a principais contribuies deste estudo e listamos possveis trabalhos futuros.

5.1

Consideraes Finais

No captulo 1 foi apresentado a justicativa da pesquisa, os objetivos geral e especcos, a relevncia do estudo e a estrutura do trabalho. No captulo 2 foi apresentado brevemente a abordagem de congurao de processos de negcio dinmicos a qual este estudo props e desenvolveu uma ferramenta. Neste captulo, realizamos uma reviso sistemtica da literatura sobre a representao de requisitos no-funcionais e informaes contextuais nos modelos de processos de negcio. Ao nal da anlise, identicamos 13 trabalhos que representam RNF em seus modelos de processos. A abordagem BVCCoN representa RNFs externamente ao modelo de negcio atravs de uma matriz, j que uma soluo escalvel para representar este tipo de informao [48]. Quanto s informaes de contexto, 14 trabalhos foram identicados, portanto, RNF e contexto esto sendo considerados na modelagem dos processos. Ao trmino da anlise, a abordagem BVCCoN foi a nica classicada nos dois itens. Em relao congurao de processos de negcio, La Rosa [28] prope uma abordagem que captura variabilidade de processos, Lapouchnian et al. [29] considera modelo de goals para representar RNF e variabilidade e De La Vara [5] adiciona contextualizao aos modelos de processos de negcio para guiar a variabilidade, portanto, BVCCoN uma abordagem mais completa em relao congurao de processos de negcio dinmicos, visto que considera variabilidade, RNF e contexto. Ainda no captulo 2 foi discutido metamodelagem, DSML (Linguagem para Mode-

112 lagem Especca de Domnio) e sua classicao em interna, externa e no textual e tambm foram inseridas noes de sintaxe concreta e abstrata. Foram apresentados os conceitos 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 tambm o Framework Epsilon, que uma famlia de linguagens e ferramentas destinadas atividades de gerenciamento de metamodelos. Grande parte de suas linguagens foram utilizadas no processo de desenvolvimento da ferramenta. So elas: EuGENia, Emfatic, EOL (Epsilon Object Language) e EVL (Epsilon Validation Language). No captulo 3 foi apresentado o metamodelo da ferramenta desenvolvida neste estudo. Tambm foi discutida a sintaxe concreta e abstrata e ao mesmo tempo exemplos de modelos foram exibidos. Alm disso, uma viso geral da ferramenta foi demonstrada, assim como as restries escritas em EVL. Em seguida, no captulo 4 foi descrito o teste de usabilidade que foi realizado com o intuito de avaliar a ferramenta proposta nesta dissertao e tambm um exemplo de uso, com o objetivo de avaliar a expressividade da ferramenta. Com a BVCCoN-Tool, possvel modelar as trs vises (requisitos no-funcionais, variabilidade e informao contextual) necessrias para a congurao de processos de negcio dinmicos da abordagem encontrada em [48]. O exemplo de uso realizado em um cenrio real, mostra que sua utilizao vivel e prtica para ser utilizada em ambientes reais, como evidenciado pela avaliao de usabilidade. A avaliao de usabilidade mostrou que a ferramenta permitiu a construo das trs vises com sucesso. A anlise dos dados coletados indicam que os quatro fatores (satisfao geral, utilidade do sistema, qualidade da informao e qualidade da interface) fossem alcanados com sucesso, possuindo uma aceitao geral por todos os usurios.

5.2

Contribuies

A pesquisa apresentada nesta dissertao possibilitou as seguintes contribuies: Uma reviso sistemtica da literatura atualizada sobre requisitos no-funcionais e informaes de contexto em modelos de processos de negcio; O desenvolvimento de um metamodelo que integra quatro diferentes perspectivas: modelos de processos de negcio, modelos de requisitos no-funcionais, modelo de descrio de variabilidade e modelo de contexto;

113 Uma ferramenta de modelagem para a congurao de processos de negcio dinmicos; A aplicao de um exemplo de uso visando validar a expressividade da ferramenta; e A denio, planejamento, operao e interpretao de um teste de usabilidade com objetivo de avaliar a usabilidade da ferramenta proposta.

5.3

Trabalhos Futuros

Alguns problemas ainda esto em aberto e outros surgiram a partir dos resultados alcanados. Desta maneira, os seguintes itens devem ser levados em considerao como trabalhos futuros: Realizar outros exemplos de uso com a ferramenta proposta. Para que seja possvel identicar falhas da ferramenta, a apresentao de outros exemplos de uso de fundamental importncia; Realizar outra avaliao de usabilidade. Realizar um treinamento profundo da abordagem BVCCoN [48] com os usurios, permitindo diminuir o nvel de detalhes em que a descrio das tarefas de usurio foram escritas. Desta forma, possveis falhas poderiam ser identicadas; Melhoria contnua da ferramenta. Caso a abordagem BVCCoN evolua, pode ser possvel criar novas formas geomtricas de novos elementos que venham surgir ou excluir elementos que tornem desnecessrios. Tambm possvel adicionar funcionalidades que porventura tornem-se necessrias; Integrao com o editor grco BPMN. A ferramenta proposta nesta dissertao j possui uma integrao com o BPMN2 Modeler [9] (plugin para realizar modelagem BPMN no Eclipse). Porm, ao invs de selecionar os atributos begins e ends atravs de um combobox como demonstrado na Figura A.7, seria interessante ao usurio visualizar o desenho do processo de negcio e selecionar esses atributos atravs de um simples clique em cima do elemento correspondente. Extenso da BVCCoN-Tool. Extender a ferramenta BVCCoN-Tool para que a mesma seja possvel de realizar a congurao de processos de negcio automaticamente.

114 Compilao de modelos. Para continuar o ciclo da abordagem BVCCoN, a prxima etapa realizar uma compilao dos modelos gerados para que possam servir de entrada para alguma plataforma de execuo de processos que venha ser integrada com a abordagem.

Referncias Bibliogrcas
115

[1] EMF: Eclipse Modeling Framework (2nd Edition), volume 1. Addison-Wesley Professional, 2008. [2] Raian Ali, Fabiano Dalpiaz, and Paolo Giorgini. A goal-based framework for contextual requirements modeling and analysis. Requirements Engineering, 15(4):439458, 2010. [3] Colin Atkinson and Thomas Kuhne. Model-driven development: a metamodeling foundation. Software, IEEE, 20(5):3641, 2003. [4] Josias Paes da Silva Junior. Agile: Uma abordagem para gerao automtica de linguagens i*. Masters thesis, Universidade Federal de Pernambuco, Recife, Pernambuco, Brasil, 2011. [5] Jose Luis de la Vara, Raian Ali, Fabiano Dalpiaz, Juan Snchez, and Paolo Giorgini. Business processes contextualisation via context analysis. In Conceptual Modeling ER 2010, pages 471476. Springer, 2010. [6] Ana Cristina de Freitas Dias. Uma linguagem especca do domnio para uma abordagem orientada aos objectivos baseada em kaos. Masters thesis, Universidade Nova de Lisboa, Lisboa, Portugal, 2009. [7] Antonio Garca 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. Selecting empirical methods for software engineering research. In Guide to advanced empirical software engineering, pages 285311. Springer, 2008. [9] Eclipse. BPMN2 Modeler, 2013. http://eclipse.org/bpmn2-modeler/. ltimo acesso em Dezembro/2013. [10] Eclipse. Eclipse Modeling Framework Project (EMF), http://www.eclipse.org/modeling/emf/. ltimo acesso em Outubro/2013. 2013.

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

116 [12] Eclipse. Epsilon, 2013. http://www.eclipse.org/epsilon/. ltimo acesso em Outubro/2013. [13] Eclipse. EuGENia, 2013. http://www.eclipse.org/epsilon/doc/eugenia/. ltimo acesso em Outubro/2013. [14] Eclipse. EuGENia, 2013. http://www.eclipse.org/epsilon/doc/articles/eugenia-gmftutorial/. ltimo acesso em Dezembro/2013. [15] Eclipse. Graphical Modeling Project (GMP), http://www.eclipse.org/modeling/gmp/. ltimo acesso em Outubro/2013. 2013.

[16] Epsilon. Emfatic, 2013. http://www.eclipse.org/epsilon/doc/articles/emfatic/. ltimo acesso em Outubro/2013. [17] Epsilon. Epsilon Transformation Language, http://www.eclipse.org/epsilon/doc/etl/. ltimo acesso em Janeiro/2014. Epsilon Validation Language, [18] Epsilon. http://www.eclipse.org/epsilon/doc/evl/. ltimo acesso em Outubro/2013. 2013.

2013.

[19] Robson N Fidalgo, Edson Alves, Sergio Espaa, Jaelson Castro, and Oscar Pastor. Metamodeling the enhanced entity-relationship model. Journal of Information and Data Management, 4(3):406, 2013. [20] Lidia Fuentes-Fernndez and Antonio Vallecillo-Moreno. An introduction to uml proles. UML and Model Engineering, 2, 2004. [21] Debasish Ghosh. DSLs in action. Manning Publications Co., 2010. [22] Paul Hudak. Building domain-specic embedded languages. ACM Comput. Surv., 28(4es):196, 1996. [23] Zoubida Kedad and Pericles Loucopoulos. Considering quality factors for business processes during requirement engineering. In Research Challenges in Information Science (RCIS), 2011 Fifth International Conference on, pages 19. IEEE, 2011. [24] Steven Kelly and Juha-Pekka Tolvanen. Domain-specic modeling: enabling full code generation. Wiley. com, 2008. [25] Dimitriois Kolovos. An extensible platform for specication of integrated languages for model management. Doutorado, The University of York, 2008.

117 [26] Holger Krahn, Bernhard Rumpe, and Steven Vlkel. Integrated denition of abstract and concrete syntax for textual languages. In Model Driven Engineering Languages and Systems, pages 286300. 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 Hofstede. Questionnaire-based variability modeling for system conguration. Software & Systems Modeling, 8(2):251274, 2009. [29] Alexei Lapouchnian, Yijun Yu, and John Mylopoulos. Requirements-driven design and conguration management of business processes. In Business Process Management, pages 246261. 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: psychometric evaluation and instructions for use. International Journal of Human-Computer Interaction, 7(1):5778, 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 7988. IEEE, 2006. [33] Rensis Likert. A technique for the measurement of attitudes. Archives of psychology, 1932. [34] John A.G. McClelland. Tcnica de questionrio para pesquisa. Revista Brasileira de Fsica, 1(1):93101, 1976. [35] OMG. Omg object constraint language (ocl). Technical report, OMG - Object Management 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 Novembro/2013. [37] OMG. Omg meta object facility (mof) core specication. Technical report, OMG Object Management Group, June 2013.

118 [38] OMG. Omg mof 2 xmi mapping specication. Technical report, OMG - Object Management Group, June 2013. [39] Christopher J Pavlovski and Joe Zou. Non-functional requirements in business process modeling. In Proceedings of the fth Asia-Pacic conference on Conceptual Modelling-Volume 79, pages 103112. Australian Computer Society, Inc., 2008. [40] Tarcisio C Pereira, Fernanda Alencar, Jackson Silva, and Jaelson Castro. Requisitos no-funcionais em modelos de processos de negcio: Uma reviso sistemtica. IX Simpsio Brasileiro de Sistemas de Informao, 1:3748, 2013. [41] Klaus Pohl, Gnter Bckle, 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 business processes. International Journal of Business Process Integration and Management, 3(1):4760, 2008. [43] Ruby. A Programmers Best Friend, 2013. https://www.ruby-lang.org/pt/. ltimo acesso em Outubro/2013. [44] RubyOnRails. Web development that doesnt hurt, 2013. http://rubyonrails.org/. ltimo acesso em Outubro/2013. [45] K. Saeedi, Liping Zhao, and P.R.F. Sampaio. Extending bpmn for supporting customer-facing service quality requirements. In Web Services (ICWS), 2010 IEEE International Conference on, pages 616623, 2010. [46] Brbara Siqueira Santos. Istar tool - uma proposta de ferramenta para modelagem i*. Masters thesis, Universidade Federal de Pernambuco, Recife, Pernambuco, Brasil, 2008. [47] Emanuel Santos, Joo Pimentel, Jaelson Castro, and Anthony Finkelstein. On the dynamic conguration of business process models. In Enterprise, Business-Process and Information Systems Modeling, pages 331346. Springer, 2012. [48] Emanuel Batista Santos. Business Process Conguration with NFRs and ContextAwareness. Doutorado, Universidade Federal de Pernambuco, 2013.

119 [49] Arnd Schnieders and Frank Puhlmann. Variability mechanisms in e-business process families. BIS, 85:583601, 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-specic languages: an annotated bibliography. SIGPLAN Not., 35(6):2636, 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, Queensland University of Technology, 2005. [53] Christian Wolter and Christoph Meinel. An approach to capture authorisation requirements in business processes. Requirements engineering, 15(4):359373, 2010.

121

Apndice

123

A
Manual de Usurio da Ferramenta BVCCoN-Tool
A.1 Criao de Modelos
Nesta seo, apresentamos a forma de utilizao do editor da ferramenta para a criao de modelos. A ferramenta apresenta um espao onde os elementos sero inseridos e do lado direito apresenta um menu de seleo onde so exibidos os elementos necessrios (ns, links e compartments) para construo dos modelos. A Figura A.1 apresenta o espao de modelagem, representado pelo nmero 1 e o menu de seleo pelo nmero 2. O menu de seleo apresenta 7 tipos de elementos: Variability Nodes (onde esto representados os elementos referentes a descrio de variabilidade), Variability Links (representam os diferentes tipos de links que so utilizados para fazer as ligaes dos ns de variabilidade), Models (onde esto representados os compartimentos NFRModel e Context Model, onde so armazenados os elementos de requisitos no-funcionais e contexto respectivamente). Context Nodes (apresenta os elementos referentes a descrio das informaes contextuais), Context Links (exibem os diferentes links utilizados para montar as informaes de contexto), NFRNode (apresenta o elemento que representa um requisito no-funcional) e por ltimo NFRLinks (representa os links de contribuies entre requisitos no-funcionais e tambm entre uma variante e um RNF). Para realizar uma modelagem de um caso, seja ele qual for, necessrio modelar as trs vises que a ferramenta oferece. A de requisitos no-funcionais, variabilidade e informao contextual. Ao longo deste tutorial, ser criado exemplos para ilustrar as etapas necessrias para a construo destas vises.

124

Figura A.1 Editor grco da ferramenta

1. Criar VariationPoint: Para iniciar a modelagem, necessrio incluir algum elemento no diagrama, poderia ser qualquer um, porm, por questes de melhor compreenso e visualizao, optamos por comear inserindo um ponto de variao. Exitem duas maneiras de criao: a primeira ir ao menu de seleo chamado Variability Nodes e escolher o elemento VariationPoint (retngulo vermelho); a segunda maneira na janela de edio, quando aparecem quais os elementos disponveis (retngulo verde), escolher o elemento Variation Point. Aps inserir o ponto de variao, denimos os atributos id, name e operator. O prximo passo carregar um modelo .bpmn e setar no ponto de variao os atributos begins, ends e ow elements. At ento, pode ser conferido a execuo destes passos na Figura A.2. 2. Carregar Modelo BPMN: Para carregar um modelo BPMN, necessrio clicar com o boto direito dentro da rea de modelagem, em seguida clicar em Load Resource. Clicando em Load Resource, ir aparecer uma janela onde necessrio navegar at o caminho em que o arquivo .bpmn est. Pode-ser navager atravs de Browse Workspace, que ir procurar dentro dos projetos do eclipse ou Browse File System, procurando em todas as pastas do computador. Aps encontrar o arquivo BPMN, o selecione e clique em OK e em seguida em OK novamente para nalizar. As Figuras A.3, A.4, A.5 e A.6 apresentam as atividades desta etapa. 3. Associando um VariationPoint ao processo de negcio: Agora que j carregamos

125

Figura A.2 Incluso de um ponto de variao

Figura A.3 Carregando modelo BPMN

126

Figura A.4 Procurando modelo BPMN

o processo de negcio, precisamos setar os atributos restantes do ponto de variao. Ou seja, precisamos denir onde o ponto de variao comea e onde termina no modelo de processo de negcio. Para fazer isso, vamos na aba Properties e clicamos dentro do campo Begins. Ir aparecer um ComboBox com todos os elementos do processo de negcio que foi importado. Neste momento, basta selecionar onde o ponto de variao comea. A mesma coisa deve ser feita para o campo Ends, indicando onde o ponto de variao termina (ver Figura A.7). Em seguida, precisamos adicionar todos os elementos que fazem parte do intervalo do ponto de variao. Portanto, clicamos no campo FlowElements e adicionamos os elementos de uxo pertencentes a determinado ponto de variao (ver Figuras A.8 e A.9). A Figura A.10 apresenta um ponto de variao com os atributos setados. Os elementos de uxo so os elementos BPMN que fazem parte do processo de negcio, incluindo os links. 4. Criar Variant: Exitem duas maneiras de criao: a primeira ir ao menu de seleo chamado Variability Nodes e escolher o elemento Variant; a segunda maneira na janela de edio, quando aparecem quais os elementos disponveis, escolher o elemento Variant. Aps inserir a variante, denimos os atributos id e name. O

127

Figura A.5 Selecionando modelo BPMN

128

Figura A.6 Finalizando o carregamento de um modelo BPMN

129

Figura A.7 Setando os atributos Begins e Ends de um ponto de variao

Figura A.8 Setando os FlowElements de um ponto de variao

130

Figura A.9 Setando os FlowElements de um ponto de variao

131

Figura A.10 Variation Point

132

Figura A.11 WorkowPattern

prximo passo carregar um modelo .bpmn e setar na variante os atributos begins, ends e ow elements. Estes passos so iguais aos descritos no ponto de variao. Uma variante precisa possuir um WorkowPattern, que indicar como os elementos do processo pertencentes a variante iro ser alocadas no processo principal. A prxima etapa indica como fazer isto. 5. Criando um WorkFlowPattern: Exitem duas maneiras de criao: a primeira ir ao menu de seleo chamado Variability Nodes e escolher o elemento WorkowPattern; a segunda maneira na janela de edio, quando aparecem quais os elementos disponveis, escolher o elemento WorkowPattern. Aps inserir o elemento, necessrio denir seu id e o tipo de Pattern. Figura A.11 exibe esta etapa. 6. Ligando WorkowPattern a uma variante: Para realizar este tipo de ligao, necessrio ir at a seo Variability Links, selecionar o link VariantSource e realizar a ligao entre o WorkowPattern e a variante (ver Figura A.12). 7. Ligando uma variante a um ponto de variao: Esta ligaao feita indo na seo Variability Links, selecionando o link VarPoints e realizando a ligao entre a variante e o ponto de variao (ver Figura A.12).

133

Figura A.12 Ligaes

Figura A.13 Links Requires e Excludes

8. Links Requires e Excludes: Uma variante pode requerer ou excluir a presena de outra variante. Os links responsveis por este tipo de ligao so o Requires e Excludes respectivamente. Ambos so encontrados na seo Variability Links. Este tipo de ligao feita selecionando uma variante como source e ligando a uma outra variante que ser o target. A Figura A.13 apresenta estes dois tipos de links. O nmero 1 referente ao link Require e o nmero 2 ao link Excludes. 9. Criar NFRModel e Softgoals: Antes de incluir os Softgoals, necessrio incluir um compartimento chamado NFRModel, encontrado na seo Models. Aps concluir esta etapa, permitido incluir os elementos Softgoals. Para isto, basta ir na seo NFR Node, selecionar o elemento NFRSoftgoal e inclu-lo dentro do

134

Figura A.14 Criando NFRmodel e Softgoals

compartimento que foi criado. Aps incluir o Softgoal, precisamos denir o id, name e o nfr softgoal priority. A Figura A.14 apresenta o NFRModel e dois Softgoals. 10. Ligaes entre Softgoals: So dois, os tipos de ligaes que podem ser feitas de Softgoal para Softgoal. So elas: AndContribution e OrContribution, ambas so encontradas na seo NFRLinks. Para realizar este tipo de ligao basta escolher uma das contribuies, selecionar um Softgoal como source e um outro Softgoal como target (ver Figura A.15). 11. Ligaes entre Variants e Softgoals: Cinco tipos de ligaes so permitidas entre Variants e Softgoals. Exemplo: BreakContribution, MakeContribution, EqualContribution, HurtContribution e HelpContribution. Para realizar estas ligaes de contribuies, basta ir na seo NFRLinks, escolher um tipo de ligao e efetuar a ligaao propriamente dita entre uma Variant desejada e um Softgoal desejado. A

135

Figura A.15 Ligaes entre Softgoals

Figura A.16 ilustra este caso. 12. Criar Context Model e as Informaes de Contexto: Antes de montar as informaes de contexto, necessrio incluir um compartimento chamado Context Model, encontrado na seo Models. Este compartimento onde as informaes de contextos iro ser montadas. Feito isso, permitido incluir todos os elementos da seo Context Nodes e os links da seo Context Links, que so utilizados para montar as informaes contextuais. 13. Inserindo ContextExpression e Statement: Primeiro passo para iniciar a montagem de uma informao contextual incluir um elemento chamado ContextExpression. Aps incluir este elemento, precisamos denir seu id. Em seguida, inserimos um elemento chamado Statement, que uma descrio do contexto. Tambm precisamos denir seu id e uma descrio sobre o que aquela expresso de contexto est representando. O prximo passo realizar uma ligao entre o Statement e o ContextExpression. O link que faz esta ligao o CELink. As etapas at aqui descritas podem ser encontradas na Figura A.17. 14. Decomposio e Fatos: Statement pode ser decomposto em um ou mais fatos. Quando existem mais de um fato, necessrio utilizar os elementos OrDecomposition ou AndDecomposition para realizar a decomposio. No exemplo que estamos utilizando, optamos por usar o AndDecomposition, ento incluimos o elemento que o representa e em seguida adicionamos 2 fatos. Aps adicionar os dois fatos, setamos o nome do fato e uma breve descrio (atributos name e description) (ver

136

Figura A.16 Ligaes entre Variants e Softgoals

Figura A.17 Ligao entre ContextExpression e Statement

137

Figura A.18 AndDecomposition e Fatos

Figura A.18). 15. Ligaes entre fatos, decomposies e statement: Todos estes elementos so conectados atravs do link PredicateLink. Selecionamos o AndDecomposition como source e o Statement como target. Em seguida selecionamos os fatos como source e o AndDecomposition como target (ver Figura A.19). 16. Fatos e Variveis: Todo fato precisa estar conectado com uma varivel. Uma varivel representa os dados que sero monitorados para o ativamento ou no de um

Figura A.19 AndDecomposition e Fatos

138

Figura A.20 Variveis

contexto. Aps incluir as variveis, necessrio inserir seu nome, o tipo de dado que ser monitorado e o valor do dado a ser monitorado. A Figura A.20 apresenta estas informaes. 17. Ligaes entre variveis e fatos: O link responsvel por fazer esta ligao o Variables. Este link possui como source o fato, e como target uma varivel. A Figura A.21 apresenta a informao de contexto montada e pronta para utilizao. A prxima e ltima etapa associar uma variante a uma expresso de contexto. 18. Associar uma variante com uma expresso de contexto: Para realizar esta tarefa, basta selecionar o link Contexts na seo Variability Links, escolher uma Variant como source e uma ContextExpression como target. A Figura A.22 apresenta esta ligao e tambm um pequeno exemplo completo de todas as vises, variabilidade, requisitos no-funcionais e informao contextual.

139

Figura A.21 Expresso de contexto

Figura A.22 Exemplo das trs vises: variabilidade, requisitos no-funcionais e informao contextual

141

B
Avaliao da Usabilidade da Ferramenta BVCCoN-Tool - Tarefa do Usurio
Pesquisa realizada pelo grupo LER (Laboratrio de Engenharia de Requisitos) da Universidade Federeal de Pernambuco, para a elaborao de um relatrio de usabilidade de uma ferramenta de modelagem. Objetivo: Utilizar a ferramenta BVCCoN-Tool para realizar a modelagem de uma parte de um cenrio de Check-In em um aeroporto. Obs: Para validar o modelo, clicar dentro do espao destinado para modelagem, ir ao Menu Edit -> Validate. Passos da tarefa: 1. Criao do Projeto: Para se criar um projeto ir a File -> New -> Project. Na janela que aparece ir a General -> Project. Clicar em Next, escrever o nome do projeto e clicar em Finish. Aps a criao do projeto, deve-se criar o espao de edio dos modelos. 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. No projeto criado anteriormente aparecem dois arquivos, um com extenso .bvccontool e outro com a extenso .bvccontool_diagram. O que vai ser usado na criao de modelos o segundo. 2. Inserindo Modelos BPMN Dentro do Projeto: Acessar o link (http://goo.gl/J2n82r). Se tiver conectado internet, os modelos sero baixados automaticamente em um arquivo .rar. Ir at onde este arquivo .rar foi baixado e

142 extrair em um local de preferncia. Em seguida copiar todos os arquivos .bpmn e colar dentro do projeto que foi criado anteriormente. 3. Criando um Ponto de Variao: Para criar um ponto de variao ir na Paleta de elementos, que ca localizada do lado direito, seo Variability Nodes, seleciona-se o elemento VariationPoint e o insere dentro da rea destinada para modelagem. Ir at a aba Properties e denir seu nome como VP01, seu id como 1 e o operador como OR. Obs: Se a aba Properties no estiver visvel, ir at o menu Window -> ShowView -> Other -> General -> Properties -> OK. 4. Importar Modelo de Referncia: Clicar com o boto direito na rea de modelagem, clicar em Load Resource, em seguida clicar em Browse Workspace, navegar no projeto que foi criado, selecionar o arquivo reference_process.bpmn, clicar em OK e em seguida em OK novamente. 5. Denir Begins, Ends e Flow Elements do Ponto de Variao: Com o ponto de variao selecionado, ir at a aba Properties e denir os atributos begins, ends e ow elements. A Figura B.1 apresenta o processo referncia, a tarefa que representa o atributo Begins (Verify Flight Information), a tarefa que representa o atributo ends (Emit Boarding Pass) e dentro da caixa vermelha os elementos para serem inseridos 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 que ca localizada do lado direito, seo Variability Nodes, seleciona-se o elemento Variant e o insere dentro da rea destinada para modelagem. Ir at a aba Properties e denir seu nome como Perform Online Check-in, seu id como 2. 7. Importando Modelo BPMN Para a Variante: Clicar com o boto direito na rea de 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. Denir Begins, Ends e Flow Elements da Variante: Com a variante selecionada, ir at a aba Properties e denir os atributos begins, ends e ow elements. A Figura B.2 apresenta um pedao de processo que faz parte da variante, incluindo a tarefa que representa o atributo Begins (Verify Flight Information Online), a tarefa que representa o atributo ends (Perform Check-In Online) e dentro da caixa

143

Figura B.1 Processo de Referncia

144

Figura B.2 Pedao 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 WorkowPattern e Conect-lo a Variante: Para criar um WorkowPattern ir na Paleta de elementos que ca localizada do lado direito, seo Variability Nodes, seleciona-se o elemento WorkowPattern e o insere dentro da rea destinada para modelagem. Em seguida, dene o atributo Wt Pattern como SEQUENCE e o id como 3. Para realizar a ligao entre o WorkowPattern e a variante criada anteriormente ir na Paleta de elementos, seo Variability Links e seleciona-se o link VariantSource. Em seguida, efetuar a ligao do WorkowPattern para a variante. 10. Ligar a Variante a um Ponto de Variao: Para realizar a ligao entre a variante e um ponto de variao ir na Paleta de elementos, seo Variability Links e selecionase o link VarPoints. Em seguida, efetuar a ligao da variante para o ponto de variao. 11. Criar NFRModel e Softgoals: Para criar um NFRModel ir na Paleta de elementos que ca localizada do lado direito, seo Models, seleciona-se o elemento NFRModel e o insere dentro da rea destinada para modelagem. Em seguida adiciona-se um Softgoal dentro do NFRModel. Para fazer este passo ir na seo NFR Node, seleciona NFRSoftgoal e o insere dentro do compartimento NFRModel. Em seguida, ir at a aba Properties e denir seu id como 4, nome como Time Performance e seu NFR Softgoal Priority como 0. Inserir outro Softgoal e denir seu id como 5, nome como Throughput e seu NFR Softgoal Priority como 1.

145 Inserir mais um Softgoal e denir seu id como 6, nome como Response Time e seu NFR Softgoal Priority como 2. 12. Ligar Softgoals: Ir at a Paleta de elementos que ca localizada do lado direito, seo NFR Links, selecionar o link AndContribution e realizar uma ligao do Softgoal Time Performance para o Softgoal Throughput. Tambm realizar o mesmo tipo de ligao do Softgoal Time Performance para o Softgoal Response Time. 13. Ligar Variante e Softgoal: Ir at a Paleta de elementos que ca localizada do lado direito, seo NFR Links, selecionar o link MakeContribution e realizar uma ligao da Variante para o Softgoal Throughput. Tambm realizar o mesmo tipo de ligao da Variante para o Softgoal Response Time. 14. Criar ContextModel: Para criar um ContextModel ir na Paleta de elementos que ca localizada do lado direito, seo 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 ContextModel, pode-se comear a montar as expresses de contexto. Ir at a Paleta de elementos que ca localizada do lado direito, seo Context Nodes, selecionar o elemento Context Expression e o inserir dentro do ContextModel. Em seguida, denir seu id como 7. 16. Criar Statement e ligar com a ContextExpression: Para criar um Statement, ir na Paleta de elementos que ca localizada do lado direito, seo ContextNodes, seleciona-se o elemento Statement e o insere dentro da rea destinada para modelagem. Denir seu id como 8 e sua descrio como on-line check-in is available. Para ligar o elemento Statement, ir na Paleta de elementos, seo ContextLinks, selecionar o link CELink e realizar a ligao do Statement que foi criado neste etapa para a ContextExpression que foi criada na etapa anterior. 17. Decompor a Expresso de Contexto: Para decompor a expresso de contexto ir na Paleta de elementos que ca localizada do lado direito, seo ContextNodes, seleciona-se o elemento AndDecomposition e o insere dentro da rea destinada para modelagem. 18. Ligar o AndDecomposition ao Statement: Ir at a Paleta de elementos que ca localizada do lado direito, seo Context Links, selecionar o link PredicateLink e realizar uma ligao do AndDecomposition para o Statement.

146 19. Criar Fatos: Para criar um Fato, ir na Paleta de elementos que ca localizada do lado direito, seo 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, der seu nome como fact1 e sua descrio como InternetIsOn. Para o segundo fato, denir seu nome como fact2 e sua descrio como CheckinSystemIsWorking. 20. Ligar os Fatos ao AndDecomposition: Ir at a Paleta de elementos que ca localizada do lado direito, seo Context Links, selecionar o link PredicateLink e realizar uma ligao do Fato para o AndDecomposition. Realizar este procedimento para os dois fatos que foram inseridos na etapa anterior. 21. Criar Variveis: Para criar uma Varivel, ir na Paleta de elementos que ca localizada do lado direito, seo ContextNodes, seleciona-se o elemento Variable e o insere dentro da rea destinada para modelagem. Repita o procedimento para inserir mais uma varivel, no total 2. Para a primeira varivel, denir seu nome como InternetIsOn, seu tipo como Boolean e seu valor como true. Para a segunda varivel, denir seu nome como CheckinSystemIsWorking, seu tipo como Boolean e seu valor como true. 22. Ligar Variveis aos Fatos: Ir at a Paleta de elementos que ca localizada do lado direito, seo Context Links, selecionar o link Variables e realizar uma ligao do Fato InternetIsOn para a varivel InternetIsOn. Realizar o mesmo procedimento para selecionar o link Variables e realizar uma ligao do Fato CheckinSystemIsWorking para a varivel CheckinSystemIsWorking. 23. Ligar Variante ao ContextExpression: Ir at a Paleta de elementos que ca localizada do lado direito, seo Variability Links, selecionar o link Contexts e realizar uma ligao da Varivel Perform Online Check-in para o ContextExpression C que foi denido no compartimento ContextModel. 24. Preencher Questionrio Online: Acessoar o site http://goo.gl/3wNpKf e preencher o questionrio PSSUQ (The Post-Study System Usability Questionnaire). Ao nal do teste, pretende-se ter construdo o modelo da Figura B.3. Fim do teste! Obrigado pela participao!

Figura B.3 Modelo BVCCoN Completo

149

C
The Post-Study System Usability Questionnaire (PSSUQ)
This questionnaire gives you an opportunity to tell us your reactions to the system you used. Your responses will help us understand what aspects of the system you are particularly 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 the system while you answer these questions. Please read each statement and indicate how strongly you agree or disagree with the statement. Thank you. 1. Overall, I am satised 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 (e) Strongly Disagree

150 3. I could effectively complete the tasks and scenarios using this system. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree 4. I was able to complete the tasks and scenarios quickly using this system. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree 5. I was able to efciently complete the tasks and scenarios using this system. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree 6. I felt comfortable using this system. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree 7. It was easy to learn to use this system. (a) Strongly Agree

151 (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree 8. I believe I could become productive quickly using this system. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree 9. The system gave error messages that clearly told me how to x problems. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly 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 (e) Strongly Disagree 11. The information (such as on-line help, on-screen messages and other documentation) provided with this system was clear. (a) Strongly Agree (b) Agree (c) Neutral

152 (d) Disagree (e) Strongly Disagree 12. It was easy to nd the information I needed. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree 13. The information provided for the system was easy to understand. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree 14. The information was effective in helping me complete the tasks and scenarios. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree 15. The organization of information on the system screens was clear. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree

153 Note: 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 (e) Strongly Disagree 17. I liked using the interface of this system. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree 18. This system has all the functions and capabilities I expect it to have. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree 19. Overall, I am satised with this system. (a) Strongly Agree (b) Agree (c) Neutral (d) Disagree (e) Strongly Disagree