Pós-Graduação em Ciência da Computação
BVCCoN-Tool – Uma Ferramenta para Apoiar uma Abordagem de Configuração de Processos de Negócio
Dinâmicos Por
Tarcísio Couto Pereira
Dissertação de Mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
Tarcísio Couto Pereira
“BVCCoN-Tool - Uma Ferramenta para Apoiar uma
Abordagem de Configuração de Processos de Negócio
Dinâmicos”
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Jaelson Freire Brelaz de Castro Co-Orientador: Fernanda Maria Ribeiro de Alencar
Catalogação na fonte
Bibliotecário Jefferson Luiz Alves Nazareno, CRB 4-1758
Pereira, Tarcísio Couto.
BVCCoN-Tool: uma ferramenta para apoiar uma abordagem de configuração de processos de negócio dinâmicos./ Tarcísio Couto Pereira. – Recife: O Autor, 2014.
xxv, 125f. : fig.
Orientador: Jaelson Freire Brelaz de Castro. Dissertação (Mestrado) - Universidade Federal de Pernambuco. Cin. Ciência da computação , 2014.
Inclui referências e apêndice.
1. Ciência da computação . 2. Engenharia de software. 3. Processos de negócio I. Castro, Jaelson Freire Brelaz.. (orientador). II. Título.
Dissertação de Mestrado apresentada por Tarcísio Couto Pereira à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título “BVCCoN-Tool - Uma Ferramenta para Apoiar uma Abordagem de Configuração de Processos de Negócio Dinâmicos” orientada pelo Prof. Jaelson Freire Brelaz de Castro e aprovada pela Banca Examinadora formada pelos professores:
______________________________________________ Prof. Robson do Nascimento Fidalgo
Centro de Informática / UFPE
______________________________________________ Prof. Gilberto Amado de Azevedo Cysneiros Filho Departamento de Estatística e Informática / UFRPE
_______________________________________________ Profa. Jaelson Freire Brelaz de Castro
Centro de Informática / UFPE
Visto e permitida a impressão. Recife, 24 de fevereiro de 2014.
___________________________________________________ Profa. Edna Natividade da Silva Barros
Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.
Pereira Silva e Ana Maria Couto de Lucena Pereira, sem vocês nada disso seria possível.
Agradecimentos
Primeiramente agradeço a Deus por todas as bençãos, amor, proteção e por todas 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 vocês me porporcionaram. Obrigado por sempre me ajudar a encontrar o caminho correto a seguir e por confiar em todas as decisões que tomei. Amo vocês.
A minha noiva Luma Hannah, por todo o amor, companheirismo e dedicação durante esses 4 anos que estamos juntos. Te agradeço por todo o apoio durante os últimos 2 anos e pela compreensão e paciência nos momentos difíceis que passei. Eu te amo! A minha amada família por me proporcionar momentos de união e felicidades. Apesar de muitas vezes longe um do outro, o amor e apoio sempre foi o mesmo.
Também agradeço aos meus amigos Jackson Raniel e Thiago Mendes pelas ideias compartilhadas. Ao meu professor orientador Jaelson Castro, por me aceitar orientar e por toda contribuição e ensinamentos que resultaram neste trabalho. A todos meus amigos do grupo LER (Laboratório de Engenharia de Requisitos), em especial a Emanuel Santos, Paulo de Lima, Jéssyka Flavyanne e Monique Soares por todo apoio. Aos professores Fernanda Alencar, Robson Fidalgo e ao meu amigo Edson Alves por toda ajuda durante o desenvolvimento deste trabalho. . . .
Some were born to sing the blues Oh, the movie never ends It goes on and on and on and on
Strangers waiting Up and down the boulevard Their shadows searching in the night Streetlights, people Living just to find emotion Hiding somewhere in the night
Don’t stop believin’ Hold on to the feelin’ Streetlights, people...
Resumo
Os processos estão se tornando cada vez mais complexos e heterogêneos, inseridos em ambientes onde as mudanças são constantes, sendo influenciados por fatores geográficos, climáticos, dentre outros. As empresas precisam manter seus processos atualizados e funcionando adequadamente, sem desprezar os requisitos de qualidade. Baseado neste cenário, foi proposto na literatura uma abordagem de configuração de processos chamada BVCCoN.
Esta abordagem possui como objetivo oferecer suporte a configuração de processos baseada em NFRs e informações contextuais. A abordagem possui três perspectivas na configuração de processo de negócio: a descrição de variabilidade, os requisitos não-funcionais e o contexto. Durante as etapas desta abordagem, é necessário realizar a modelagem destas três perspectivas. Contudo, modelar as três perspectivas é uma atividade que requer tempo e que está propensa a erros.
Assim, esta dissertação propõe o desenvolvimento de uma ferramenta que apoia a modelagem dos requisitos não-funcionais, da variabilidade e das regras de contexto. Para construir a ferramenta, foi realizada a integração de três metamodelos, com algumas alterações, sendo cada um referente a uma perspectiva da abordagem BVCCoN. Além disso, foi utilizado o framework Epsilon e seu conjunto de linguagens integrado no ambiente Eclipse para o desenvolvimento da ferramenta. Para ilustrar a utilização da ferramenta, foi realizado um estudo de caso em um cenário de check-in em aeroporto, bem como uma avaliação de usabilidade com potenciais usuários, visando avaliar os seguintes fatores: satisfação geral, utilidade do sistema, qualidade da informação e qualidade da interface.
Palavras-chave: bvccon. processos de negócio. requisitos não-funcionais. variabilidade. contexto. ferramenta. eclipse. epsilon. eugenia.
Abstract
Processes are becoming increasingly complex and heterogeneous, embedded in an envi-ronment where changes are constant, being influenced by geographic, climatic factors, among others. Companies need to keep the processes updated and working properly, without neglecting the quality requirements. Based on this scenario, it was proposed in the literature a process configuration approach called BVCCoN.
The goal of this approach is to offer support for processes configuration based on NFRs and contextual information. The approach has three perspectives on business process configuration: 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 Processo da abordagem BVCCoN. Adaptado de [47]. . . 34
2.2 Exemplo de modelo referência com pontos de variação. Adaptado de [48]. 36 2.3 Exemplo de variantes e pontos de variação. Adaptado de [48]. . . 38
2.4 Exemplo de decomposição de contexto. Adaptado de [48]. . . 40
2.5 RNFs e Variantes. Adaptado de [48]. . . 42
2.6 Exemplo de uma instância de processo. Adaptado de [48]. . . 44
2.7 Infraestrutura Tradicional MDD. Adaptado de [3]. . . 47
2.8 Dashboard GMF. . . 51
3.1 Parte do Metamodelo BVCCoN . . . 60
3.2 Elementos Gráficos x Metamodelo - Exemplo 1 . . . 61
3.3 Elementos Gráficos x Metamodelo - Exemplo 2 . . . 61
3.4 Elementos Gráficos x Metamodelo - Exemplo 3 . . . 62
3.5 Perspectiva de Variabilidade [48] . . . 63
3.6 Metamodelo Variability - BVCCoN . . . 65
3.7 Perspectiva Contexto [48] . . . 68
3.8 Metamodelo Contexto - BVCCoN-Tool . . . 70
3.9 Perspectiva RNF [48]. . . 73
3.10 Metamodelo RNF - BVCCoN. . . 74
3.11 Sintaxe concreta do Ponto de Variação. . . 78
3.12 Sintaxe concreta de uma Variante. . . 80
3.13 Sintaxe concreta de RNF. . . 82
3.14 Sintaxe concreta de Contexto. . . 84
3.15 Editor da Ferramenta BVCCoN-Tool . . . 85
3.16 Menu de seleção da ferramenta . . . 85
3.17 Modelo RNF . . . 86
3.18 Modelo RNF e Variabilidade . . . 86
3.19 Modelo de Contexto . . . 87
3.20 Modelo BVCCoN . . . 87
4.1 Processo de Referência . . . 92
4.2 Pontos de Variação no Processo de Referência . . . 94
4.3 Pontos de Variação e Variantes com partes de Processos de Negócio . . 96
xvi
4.5 Requisitos Não-Funcionais e Análise de Contribuição . . . 99
A.1 Editor gráfico da ferramenta . . . 126
A.2 Inclusão de um ponto de variação . . . 127
A.3 Carregando modelo BPMN . . . 127
A.4 Procurando modelo BPMN . . . 128
A.5 Selecionando modelo BPMN . . . 129
A.6 Finalizando o carregamento de um modelo BPMN . . . 130
A.7 Setando os atributos Begins e Ends de um ponto de variação. . . 131
A.8 Setando os FlowElements de um ponto de variação . . . 131
A.9 Setando os FlowElements de um ponto de variação . . . 132
A.10 Variation Point . . . 133
A.11 WorkflowPattern . . . 134
A.12 Ligações . . . 135
A.13 Links Requires e Excludes . . . 135
A.14 Criando NFRmodel e Softgoals . . . 136
A.15 Ligações entre Softgoals . . . 137
A.16 Ligações entre Variants e Softgoals . . . 138
A.17 Ligação entre ContextExpression e Statement . . . 138
A.18 AndDecomposition e Fatos . . . 139
A.19 AndDecomposition e Fatos . . . 139
A.20 Variáveis . . . 140
A.21 Expressão de contexto . . . 141
A.22 Exemplo das três visões: variabilidade, requisitos não-funcionais e infor-mação contextual . . . 141
B.1 Processo de Referência . . . 145
B.2 Pedaço de um Processo de uma Variante . . . 146
Lista de Tabelas
2.1 Relação entre o tipo de representação de RNF e trabalhos selecionados [40]. 32
2.2 Sumarização dos Resultados . . . 32
2.3 Contribuição para os RNFs Confiança e Performance . . . 43
2.4 Sumário de Critérios . . . 46
4.1 Contribuição dos RNFs . . . 100
4.2 Equipamentos utilizados para realização do teste. . . 102
4.3 Respostas dos Participantes . . . 105
4.4 Satisfação Geral . . . 107
4.5 Utilidade do Sistema . . . 108
4.6 Qualidade da Informação . . . 109
Lista de Acrônimos
BPMN Business Process Management and Notation
BVCCoN Business Process Configuration with NFR and Context-Awareness
DSEL Domain Specific Embedded Language
DSL Domain Specific Language
DSML Domain Specific Modeling Language
EMF Eclipse Modeling Framework
EOL Epsilon Object Language
GMF Graphical Modeling Framework
GPL General Purpose Language
MOF Meta Object Facility
NFR Non-Functional Requirements
OMG Object Management Group
PSSUQ The Post-Study System Usability Questionnaire
Lista de Listagem
2.1 Metamodelo escrito em Emfatic . . . 53
2.2 Exemplo de Código EVL . . . 55
3.1 Metamodelo Variabilidade escrito em Emfatic . . . 65
3.2 Metamodelo Contexto escrito em Emfatic . . . 70
3.3 Metamodelo RNF escrito em Emfatic . . . 74
Sumário
1 Introdução 27 1.1 Motivação e Justificativa . . . 27 1.2 Objetivos da Investigação . . . 28 1.2.1 Objetivo Geral . . . 28 1.2.2 Objetivos Específicos . . . 29 1.3 Estrutura da Dissertação. . . 292 Fundamentação Teórica e Trabalhos Relacionados 31
2.1 Revisão Sistemática da Literatura . . . 31
2.2 BVCCoN - Business Process Configuration with NFRs and Context-Awareness . . . 33
2.2.1 Elicitação da Variabilidade . . . 34
2.2.2 Descrição da Variabilidade . . . 34
2.2.3 Análise de Contexto . . . 39
2.2.4 Ligar Variantes & RNF . . . 40
2.2.5 Realizar a Configuração . . . 43
2.2.6 Trabalhos Relacionados. . . 43
2.3 Meta-Modelagem . . . 46
2.3.1 UML - Unified Modeling Language . . . 47
2.3.2 DSML - Linguagem para Modelagem Específica de Domínio . . 48
2.4 Tecnologias . . . 50
2.4.1 Eclipse Modeling Framework . . . 50
2.4.2 Graphical Modeling Framework . . . 51
2.4.3 Epsilon . . . 52
2.4.4 Estudos que Desenvolveram Ferramentas de Modelagem . . . . 56
2.5 Considerações do Capítulo . . . 58
3 BVCCoN Tool 59
3.1 Modelo e Metamodelo BVCCoN . . . 59
3.1.1 Sintaxe Abstrata. . . 61
3.1.1.1 Modelo BPMN . . . 62
3.1.1.2 Variabilidade . . . 63
3.1.1.3 Contexto . . . 67
xxiv 3.1.2 Sintaxe Concreta . . . 77 3.1.2.1 Variabilidade . . . 77 3.1.2.2 Requisitos Não-Funcionais. . . 80 3.1.2.3 Contexto . . . 81 3.2 A Ferramenta . . . 83 3.3 Restrições EVL . . . 87 3.4 Considerações do Capítulo . . . 89 4 Avaliação 91
4.1 Cenário: Check-In Aeroporto . . . 91
4.2 Exemplo de Uso . . . 92
4.2.1 Processo de Referência . . . 92
4.2.2 Elicitação da Variabilidade . . . 92
4.2.3 Descrição da Variabilidade . . . 92
4.2.4 Análise de Contexto . . . 97
4.2.5 Análise de Requisitos Não-Funcionais . . . 97
4.3 Teste de Usabilidade . . . 100
4.3.1 The Post-Study System Usability Questionnaire . . . 100
4.3.2 Usuários . . . 101
4.3.3 Equipamentos e Ambiente . . . 102
4.3.4 Tarefas . . . 102
4.3.5 Processo de Coleta dos Dados . . . 102
4.3.6 Resultados. . . 103 4.3.6.1 Satisfação Geral . . . 106 4.3.6.2 Utilidade do Sistema . . . 108 4.3.6.3 Qualidade da Informação . . . 108 4.3.6.4 Qualidade da Interface . . . 109 4.4 Ameaças à Validade . . . 110 4.5 Considerações Finais . . . 111
5 Conclusões e Trabalhos Futuros 113
5.1 Considerações Finais . . . 113
5.2 Contribuições . . . 114
5.3 Trabalhos Futuros . . . 115
A Manual de Usuário da Ferramenta BVCCoN-Tool 125
A.1 Criação de Modelos . . . 125
B Avaliação da Usabilidade da Ferramenta BVCCoN-Tool - Tarefa do Usuário143
1
Introdução
Este capítulo apresenta a motivação e os objetivos para a realização deste estudo, além de apresentar a estrutra da dissertação.
1.1
Motivação e Justificativa
Os processos estão se tornando cada vez mais complexos e heterogêneos, inseridos em ambientes onde as mudanças são constantes, sendo influenciados por fatores geográficos, climáticos, 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 através da capacidade de percepção contínua do ambiente do processo e decisões baseadas no controle do processo [47].
Processos de negócio dinâmicos são aqueles capazes de se adaptar a novas situações. Essas novas situações são impostas pelo ambiente em que o processo está inserido, afetando a maneira como os processos são realizados [42]. Para que os processos de negócios sejam flexíveis às mudanças no ambiente organizacional, é necessário 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. Também pode incluir informações como: os recursos necessários e o responsável pela execução da atividade [27].
Considerar a qualidade de processos é essencial em futuros sistemas de software [23]. As modelagens atuais de processos de negócio capturam atividades que representam aspectos funcionais de um sistema de informação. Enquanto os requisitos ditos de qualidade, restrições ou softgoals, os chamados Requisitos Não-Funcionais (RNFs), não são capturados, pois o foco, na modelagem de processos de negócio tem sido no
28
comportamento funcional [53] [39]. Os RNFs são importantes para as organizações, uma vez que estão relacionados a aspectos de restrição e qualidade, tais como tempo de execução, segurança, usabilidade, manutenabilidade e confiabilidade.
Baseado na grande importância de RNFs e contexto em modelos de processos de negócio, Santos [47] propõe uma abordagem de configuração de processos que tem como objetivo oferecer suporte à sua configuração baseada em RNFs e informações contextuais. A abordagem possui três perspectivas na configuração de processo de negócio: a descrição de variabilidade, os Requisitos Não-Funcionais e o contexto [47].
A primeira perspectiva tem como foco a descrição da variabilidade de modelos de processos de negócio e os mecanismos necessários para lidar com isto. Na segunda perspectiva, é utilizado RNFs para representar qualidades dos modelos de processos de negócio. Esta perspectiva aborda as preferências e interferências de atributos de qualidade nos modelos de processos. A perspectiva de contexto incorpora as influências do ambiente no modelo de processo. Através da associação de informações monitoráveis aos modelos de processos, é possível oferecer capacidade de adaptação aos mesmos para possíveis mudanças de ambiente.
Contudo, a abordagem de Santos [47] é complexa, envolvendo modelos de processos de negócio, de requisitos não-funcionais e de informações contextuais que estão inter-ligados, ou seja, existe uma dependência entre esses modelos. O usuário necessita ter como produto destas fases, modelos que os represente. A falta de uma ferramenta, que auxilie o usuário a realizar as etapas de modelagem, torna o processo mais lento, difícil de entender e mais propenso a erros.
Com o propósito de solucionar estes problemas, o presente trabalho propõe a es-pecificação e o desenvolvimento de uma ferramenta que integre os diferentes modelos. Assim, deseja-se obter como produto final, uma ferramenta de modelagem que ofereça mais velocidade na execução do processo de modelagem, que facilite a compreensão dos modelos e que evite erros.
1.2
Objetivos da Investigação
1.2.1
Objetivo Geral
O principal objetivo deste estudo é o desenvolvimento de uma ferramenta para apoiar o processo de modelagem da abordagem BVCCoN apresentada em [48].
1.2.2
Objetivos Específicos
Para alcançar o objetivo geral deste estudo, os seguintes objetivos específicos foram definidos:
• Planejar e executar uma revisão sistemática da literatura sobre requisitos não-funcionais, informações contextuais e modelos de processos de negócio;
• Desenvolver o metamodelo para a BVCCoN-Tool;
• Implementar a ferramenta de modelagem para a configuração de processos de negócio dinâmicos;
• Aplicar um exemplo de uso com o objetivo de avaliar a expressividade da ferra-menta;
• Definir, planejar, executar e interpretar uma avaliação de usabilidade com usuários reais.
1.3
Estrutura da Dissertação
O restante desta dissertação está organizada da seguinte maneira: Capítulo2apresenta o background necessário para a compreensão deste trabalho. Neste capítulo, são descri-tas as etapas da abordagem BVCCoN, trabalhos relacionados, também são discutidos metamodelagem e apresentadas as tecnologias utilizadas para o desenvolvimento da ferramenta; Capítulo 3 descreve a ferramenta proposta, incluindo o metamodelo e as etapas de desenvolvimento; Capítulo 4 apresenta um exemplo de uso e também uma avaliação de usabilidade da ferramenta proposta; Por fim, capítulo5oferece um conjunto de conclusões discutindo nossas contribuições e diretrizes para trabalhos futuros.
2
Fundamentação Teórica e Trabalhos
Relacionados
Neste capítulo, apresentamos o background necessário para a compreensão do trabalho proposto. É importante ressaltar que não é o objetivo desta seção descrever todas as informações necessárias para a execução da abordagem BVCCoN, mas sim, apresentar de forma sucinta as etapas da abordagem. Para conhecimento de todo o processo e forma de execução da BVCCoN, consultar [48]. Também discutimos meta-modelagem e o frameworkEpsilon [12], que foi utilizado no desenvolvimento deste trabalho.
2.1
Revisão Sistemática da Literatura
Em [40], realizamos uma revisão sistemática da literatura com o intuito de identificar como os requisitos não-funcionais e as informações contextuais são representados nos modelos de processos de negócios. Utilizando-se da busca às principais bases de dados, identificamos 1883 trabalhos, dentre os quais foram classificados e analisados 13 trabalhos que levam em conta RNFs na modelagem de processos e 14 que consideram contexto em BPM.
Realizamos uma leitura cuidadosa dos trabalhos e identificamos as linguagens de modelagens de processos que foram utilizadas para representar os RNFs e também realizamos um mapeamento entre os tipos de representação de RNF e seus determinados autores. Ao final desta primeira análise 8 trabalhos utilizaram a notação BPMN, 2 usaram digrama de atividades, 2 fizeram uso da modelagem de processos de negócio orientada a objetivos e apenas 1 trabalho usou a notação Stock and Flow Diagrams. A Tabela
2.1exibe o mapeamento entre os tipos de representação de RNFs e seus determinados autores.
32
Tabela 2.1 Relação entre o tipo de representação de RNF e trabalhos selecionados [40].
Tipo de Representação | Trabalhos Selecionados [Bartonili,2012] [Bocciarelli,2011] [Pavlo
vski,2008]
[Saeedi,2010] [Santos,2012] [Serrano,2009] [W
olter ,2010] [Xa vier ,200] [Ab urub,2007] [Khaluf,2011] [K edad,2011] [Cardoso,2009] [Lapouchnian,2007]
RNF anotado textualmente nos elementos do modelo • • • •
Associação textual entre RNF e elementos do modelo • •
Extensão da notação BPMN com criação de artefatos •
Representação externa do RNF ao modelo de negócio •
Criação de símbolos para representar os RNFs • • •
NFR Frameworkou derivados • •
Analisando a Tabela 2.1percebe-se que o maior tipo de representação de RNF se dá anotando elementos de um modelo com o nome do RNF, 4 dos 13 trabalhos adotam este tipo de representação. Em seguida, 3 trabalhos representam os RNFs através da criação de símbolos para representá-los. Um empate ocorre entre aqueles que fazem associação textual entre RNF e elementos do modelo e os que utilizam o NFRFramework para representar RNF, cada um com 2 trabalhos. Por fim, encontra-se 1 trabalho que propõe a criação de novos artefatos e um outro que representa os RNFs externamente ao modelo de negócio.
Analisando os trabalhos referentes às informações de contexto identificamos itens como, por exemplo, se o trabalho é classificado 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 estratégias de adaptação de processos de negócio. A Tabela2.2apresenta a sumarização desses itens.
Tabela 2.2 Sumarização dos Resultados
[Santos,2012] [Xia,2008] [Balabk
o,2003] [Born,2009] [Bucchiarone,2012] [V ara,2010] [Hallerback,2008] [Mejia, 2010] [Ploesser ,2009]
[Rosemann,2008] [Saidani,2009] [Zacarias,2005] [Zerari,2011] [Boukadi,2009] Itens
Tipo de Contribuição - Abordagem • • • • • • •
Tipo de Contribuição - Framework • • • • • • •
Ferramentas de Suporte • •
Testes da Abordagem/Framework • • • • • • • • • •
Discute Estratégias de Adaptação • • •
Para fins de contagem, consideramos apenas os itens "Ferramenta de Suporte", "Testes da Abordagem/Framework"e "Discute Estratégias de Adaptação". Portanto, analisando a Tabela2.2, identificamos que 1 trabalho cobre os 3 itens citados anteriormente, 1 trabalho
discute ferramenta de suporte e estratégias de adaptação, 1 trabalho trata de estratégias de adaptação e 9 trabalhos realizam testes da abordagem/framework.
Durante o processo de extração dos dados e análise dos resultados, encontramos a abordagem BVCCoN. Esta foi a única abordagem que foi classificada tanto na análise dos requisitos não-funcionais quanto na de informação contextual. Portanto, BVCCoN é uma abordagem de configuração de processos de negócios que leva em consideração RNFs e contexto no momento de realizar configurações. Informações de contexto são importantes para obter flexibilidade e requisitos de qualidade segundo Saeedi [45], são o caminho para alcançar performance e satisfação dos clientes.
Esta abordagem representa os RNF externamente ao modelo de negócio através do NFRFramework. Uma vez definido os RNFs, os mesmos são ligados às variantes do processo. Quanto às informações de contexto, a abordagem utiliza um conjunto de regras para montar as informações contextuais e não possui uma ferramenta que apoie estas construções, assim como, também não possui uma ferramenta que realize a representação dos RNFs. Estas informações obtidas da revisão sistemática fortalece a inexistência de uma ferramenta que apoie as fases de modelagem da abordagem, tornando o processo mais lento, difícil de entender e mais propenso a erros. A seção seguinte descreve as etapas da abordagem.
2.2
BVCCoN - Business Process Configuration with NFRs
and Context-Awareness
A BVCCoN [48] é uma abordagem que visa a configuração de processos de negócio utilizando requisitos não-funcionais e informações contextuais. A abordagem é composta de cinco atividades: Elicitar Variabilidade, Descrever Variabilidade, Analisar Contexto, Ligar RNFs & Variantese Realizar Configuração. As primeiras quatro etapas são realiza-das em design time (ver Figura2.1). Enquanto a última etapa, Realizar Configuração é realizada em runtime. Nossa ferramenta de modelagem cobre as atividades Descrever Variabilidade, Analisar Contexto e Ligar RNF & Variantes da abordagem. Para executar a atividade Elicitar Variabilidade, não é necessário a utilização de uma ferramenta de modelagem, mas sim uma análise em cima dos elementos do modelo de negócio em BPMN. Nas próximas subseções são detalhadas as etapas do processo da abordagem BVCCoN apresentado na Figura2.1.
34
Figura 2.1 Processo da abordagem BVCCoN. Adaptado de [47].
2.2.1
Elicitação da Variabilidade
Esta primeira etapa é responsável por identificar e descobrir possíveis variações em um modelo de processo de negócio. O objetivo é descobrir diferentes maneiras de executar um processo, bem como os efeitos da inclusão, mudança ou exclusão de elementos do modelo. Possui como entrada um processo de negócio inicial e como saída toda informação sobre variabilidade elicitada.
Para realizar esta atividade, é utilizado o information analysis framework [32] que explora diferentes características da informação e obtém novos dados sobre as informa-ções. No contexto de modelos BPMN, este framework é utilizado para analisar tarefas, atividades e outros elementos do modelo para identificar novas informações sobre eles. Este framework é baseado em um conjunto de perguntas como:
• Agente (Quem irá executar a tarefa?) • Dativo (Quem será afetado pela tarefa?)
• Objetivo (Quais são os objetos consumidos ou produzidos pela tarefa?) • Extensão (Até que ponto a tarefa será executada?)
2.2.2
Descrição da Variabilidade
Por meio da elicitação de variabilidade, é possível analisá-la com o intuito de identificar o que pode ser modelado como pontos de variações e variantes. A partir desta seção, o modelo BVCCoN começa a ser construído incrementalmente por meio das próximas seções. Para ilustrar um exemplo, estamos utilizando um processo de emergência quanto
a existência de fogo. Este processo é um caso clássico de um sistema sócio-técnico onde software e humanos devem executar com segurança (ver Figura2.2).
O processo é iniciado com a procura por fumaça ou fogo, caso identificado uma dessas situações, é verificado o risco. Caso o risco não seja real, o processo é finalizado, porém, se o perigo for real, inicia-se a tarefa de resgatar as pessoas em perigo, seguida por tocar alarme de incêndio, ligar para os serviços de segurança pública, abrir saídas de emergênciae Evacuar o prédio imediatamente.
Pontos de variações são pontos de mudanças definidos no modelo de processo de negócio que podem representar caminhos alternativos ou variáveis de realizar atividades no processo. Para definir os pontos de variação, é necessário receber como entrada o modelo referência de processo de negócio e a informação elicitada. Baseado nesta entrada, o analista define o que será marcado como ponto de variação e quais tarefas farão parte do ponto de variação. O analista também deve definir onde o ponto de variação começa (begins) e termina (ends). A saída destas atividades é o modelo referência de processo marcado com os pontos de variações. Esta saída faz parte do processo de descrição de variabilidade.
A Figura 2.2exibe um possível modelo de referência com os pontos de variações. Quatro pontos de variações foram identificados: PV1 associado a tarefa Procurar por fumaça ou fogo, PV2 relacionado a tarefa Tocar alarme de incêndio, PV3 corresponde a tarefa Ligar para os serviços de segurança pública e PV4 está ligado a tarefa Abrir saídas de emergência. Após definir os pontos de variações e selecionar onde eles começam e terminam, a próximo passo é definir os elementos que serão parte das variantes.
As informações adquiridas durante a elicitação e os pontos de variação definidos ante-riormente são entradas para a definição de variantes. Variantes são objetos de mudanças, representando caminhos alternativos ou variáveis, ou seja, como as atividades do processo podem ser realizadas. Desta maneira, as variantes estão associadas a fragmentos de processos BPMN que irão expressar a maneira como um processo pode ser alterado para se adaptar a uma nova configuração de ambiente. Assim como os pontos de variações, as variantes também são identificadas por um analista.
No exemplo de emergência de fogo, foram identificadas variantes que estão associadas ao tipo de agente que executará algumas tarefas. Na tarefa Procurar por fogo e fumaça, é possível visualizar este caso, no qual a tarefa pode ser executada por uma pessoa ou um sensor. A descrição de variabilidade também pode afetar o comportamento das tarefas. Os padrões de work-flow descrevem comportamentos de atividades quando associadas a um ponto de variação. No modelo BVCCoN, a utilização de padrões work-flow ajuda
36
Figura 2.2 Exemplo de modelo referência com pontos de variação. Adaptado de [48].
a descrever como combinar as variantes e os pontos de variações, ou seja, os padrões descrevem como os elementos (neste caso BPMN) serão agrupados [52].
Os padrões básicos são sequence, parallel split, synchronization, exclusive choice e simple merge. O padrão sequence é aquele em que as tarefas são executas em sequencia, o parallel splitas tarefas são executas em paralelo, o padrão synchronization precisa existir uma sincronia entre as tarefas do BPMN, ou seja, um conjunto de tarefas precisam ser executadas para que o fluxo do processo BPMN continue. No padrão Exclusive Choice é dado um conjunto de tarefas, mas apenas uma é executada, por fim, no padrão Merge é dado um conjunto de tarefas em que apenas uma precisa ser executada para que o fluxo do processo seja continuado.
O próximo passo é associar os pontos de variações às variantes. Nesta etapa, é necessário definir algum operador lógico no ponto de variação para indicar como as variantes estarão associadas. Na abordagem BVCCoN, é utilizado os termos AND, OR e XOR. Estes operadores podem influenciar os padrões de work-flow que estão associados às variantes. Por exemplo, um operador AND permite incluir como solução os padrões
sequencee parallel split/synchronization.
A Figura2.3exibe as variantes associadas com seus respectivos pontos de variações. O ponto de variação VP1 possui duas variantes, var1 e var2, que são Procurar por fogo ou fumaça automaticamentee Procurar por fogo ou fumaça pessoalmente respectivamente. Cada variante está associada a uma tarefa BPMN, var1 está associada com a tarefa Procurar por fogo ou fumaça automaticamentee var2 com a tarefa Procurar por fogo ou fumaça. Os pontos de variações VP2, VP3 e VP4 também estão associados com suas respectivas variantes e as variantes com as tarefas BPMN. Após concluir esta etapa, o próximo passo é executar a análise de contexto.
38
2.2.3
Análise de Contexto
Segundo Ali [2], contexto pode ser definido como um estado do mundo que é relevante para um objetivo de um ator. Nesta etapa, o modelo de processos de negócio é analisado para identificar os contextos que podem afetar o modelo. Analisando o domínio, os contextos podem ser identificados. Estados de sistemas e também usuários podem ser descritos como contexto. O contexto pode descrever:
• O que está acontecendo? • Onde eles estão localizados?
• Quais são os recursos disponíveis para uso?
O contexto pode ser analisado através de um conjunto de fatos e statements que estão conectados [2]. Fatos podem ser avaliados, já os statements não. Para que um statement assuma um valor verdadeiro, deve existir um conjunto suficiente de evidências que realize a comprovação. Essas evidências são encontradas por meio das avaliações dos fatos [5]. A decomposição termina quando é possível descrever todas as variáveis que permitem verificar se o contexto foi ativado. O objetivo é obter uma fórmula de fatos apoiados por variáveis monitoráveis. Os seis passos abaixo são utilizados para obter o conjunto de contextos associados às variantes.
1. Selecionar uma variante do modelo de variabilidade a ser avaliado;
2. Identificar fatores que afetam a execução do fragmento de processo de negócio de uma variante;
3. Decompor os fatos e statements que apoiam o contexto; 4. Associar as variáveis monitoráveis aos fatos;
5. Validar a interferência com outros contextos; 6. Repetir os passos para outras variantes.
A Figura 2.4 exibe um exemplo de decomposição de contexto. Por exemplo, o contexto Bombeiros serem chamados automaticamente é apoiado por três fatos: Alarme de fogo está ativo, Fogo foi confirmado, e Serviços de rede está funcionando. Quando as variáveis que estão associadas a este contexto atingem o valor especificado, o contexto é ativado e a variante que está associada a este contexto pode fazer parte do processo.
40
Figura 2.4 Exemplo de decomposição de contexto. Adaptado de [48].
2.2.4
Ligar Variantes & RNF
Na abordagem BVCCoN, os requisitos não-funcionais são utilizados para representar as preferências dos stakeholders. Nesta etapa, os RNFs que são importantes para o processo são identificados e também é definido o impacto de cada variante sobre os RNFs. Assim, os RNFs são ligados às variantes do processo de negócio que foram levantadas nos passos anteriores da abordagem.
Os RNFs que serão levados em consideração são identificados e então é feito uma descrição dos RNFs e variantes. Essa elicitação pode ser realizada entrevistando pessoas que estão envolvidas no processo de negócio. Em seguida, pode-se associar os RNFs com as variantes para representar as preferências dos stakeholders sobre a seleção de possíveis variantes. RNFs representarão atributos de qualidade que os stakeholders esperam do sistema.
Uma vez identificados os RNFs, é permitido realizar as ligações entre estes e as variantes do processo. A abordagem BVCCoN utiliza a escala qualitativa proposta pelo NFRFramework [30] para realizar essas ligações. O impacto mais positivo sobre um requisito não-funcional é chamado Make, um impacto parcialmente positivo Help, um impacto parcialmente negativo é chamado de Hurt e um impacto mais negativo Break. Esses valores são mapeados respectivamente para, ++,+,-,– na escala da abordagem BVCCoN.
A Figura2.5mostra uma versão simplificada de um modelo BVCCoN. As variantes Tocar alarme de fogo manualmentee Tocar alarme de fogo automaticamente fazem parte do ponto de variação VP2, que possui o operador lógico XOR. Este operador lógico indica que apenas uma das variantes pode ser selecionada. A variante Tocar alarme de fogo automaticamenteestá relacionada com o contexto Serviços de backup estão funcionando, assim, esta variante só poderá ser selecionada se o contexto for verdadeiro. A Tabela
2.3apresenta as contribuições da Figura2.5, permitindo uma melhor visualização. Os espaços em branco são compreendidos como EqualContribution (=).
42
Tabela 2.3 Contribuição para os RNFs Confiança e Performance
Variante/RNF Confiança Performance
Procurar por fogo ou fumaça automaticamente ++ Procurar por fogo ou fumaça pessoalmente ++
-Tocar alarme de fogo manualmente +
-Tocar alarme de fogo automaticamente ++
Chamar os serviços de segurança pública automaticamente – ++ Chamar os serviços de segurança pública por linha telefônica
-Chamar os serviços de segurança pública por telefone móvel + + Abrir saídas de emergência manualmente ++
Abrir saídas de emergência automaticamente ++
2.2.5
Realizar a Configuração
Existem duas maneiras de executar a configuração de um processo de negócio: a primeira é selecionando as variantes e a segunda é priorizando algum requisito não-funcional. Existem diversas maneiras de analisar o impacto de cada configuração sobre os RNFs, por exemplo: análise top-down e bottom-up.
A top-down é feita selecionando um RNF que terá maior prioridade, e em seguida, derivado uma configuração de processo que maximiza o RNF selecionado. Ou seja, cada ponto de variação é avaliado para identificar a variante que melhor se ajusta ao requisito não-funcional selecionado.
Na análise bottom-up, uma configuração de processo é definida selecionando um sub-conjunto de variantes e então, uma matriz de ligação é utilizada para calcular o impacto da configuração sobre o requisito não-funcional. A Figura2.6apresenta uma solução de um processo priorizando o RNF Performance.
Para descrever os conceitos de ponto de variação, variantes, requisitos não-funcionais e informações contextuais, é utilizado um mecanismo chamado de metamodelagem. Assim, através de um metamodelo, é possível definir os elementos de modelagem e seus respectivos relacionamentos [4].
2.2.6
Trabalhos Relacionados
A seguir, apresentamos uma comparação entre estudos que descrevem abordagens de configuração de modelos de processos de negócio em ambientes dinâmicos descritos na literatura.
Trabalhos Identificados
44
Figura 2.6 Exemplo de uma instância de processo. Adaptado de [48].
La Rosa [28] propôs uma abordagem para capturar variabilidade de sistemas baseada em modelos de questionário. Ela apoia a configuração com um processo e um modelo de questionário. O modelo de questionário consiste de um gráfico que define as questões a serem respondidas. Questões são respondidas em sequencia, lidando para a identificação de ações que são realizadas pela configuração.
Os modelos de processos são representados por modelos de processos configuráveis escritos em Configurable Yet Another Workflow Language (C-YAWL). Esta linguagem é uma extensão que possui a característica de descrever os pontos de variação do processo dentro do modelo de processo. O modelo de processo com a informação de variabilidade está alinhado com o modelo de questionário. A configuração do processo é realizada pelo usuário respondendo questões que levam a um novo modelo de processo.
Requirements-driven design and configuration management of business processes Lapouchnian et al. (2007) [29] apresenta uma abordagem que alinha processos de negócio com modelos de Goal. Modelos de Goal são usados para descrever os objetivos do negócio e as preferências dos usuários. Através da decomposição dos modelos, é possível obter uma estrutura de goals [objetivos] do processo de negócio. O modelo de goalssegue uma estrutura em formato de árvore na qual os goals são decompostos em subgoals.
A descrição da informação de variabilidade é adicionada a estrutura do modelo de goals. Por isso, as informações do processo está misturado com anotações. As anotações que descrevem variabilidade são baseadas em IF-THEN-ELSE, regras assim como os operadores lógicos (AND, OR). Os requisitos não-funcionais são descritos como Softgoalse as contribuições para Softgoals representam as preferências dos usuários sobre
possíveis escolhas. Os pontos de variação são os lugares onde existe uma decomposição OR. Com o objetivo de obter um modelo de fluxo de processo, eles descrevem os passos do começo da configuração com uma análise de Softgoal e seleção de variantes. Após a seleção, uma transformação gera o modelo de fluxo do processo em BPEL.
Business processes contextualisation via context analysis
De La Vara et al. (2010) [5] propôs uma metodologia para adicionar contextualização aos modelos de processos de negócio. A proposta é obter modelos de processos de negócio que são perceptíveis ao contexto. A metodologia descreve vários passos e inclui anotações de contexto que é baseada na abordagem de [2], que apoia análise contextual. Os contextos consistem de árvores com facts e statements que são avaliados para identificar quando um contexto está ativo.
As informações contextuais são requeridas para ativar mudanças no fluxo dos pro-cessos. Com o objetivo de incluir contexto, eles estenderam a notação BPMN para ter contextos embarcados nos fluxos de sequência que ligam as atividades. A descrição da variabilidade é adicionada ao modelo de processo, onde o caminho alternativo no fluxo do trabalho representa as variantes.
Discussão
As abordagens de configuração de processos de negócio são complexas e consomem muito esforço e tempo. A abordagem BVCCoN integra metamodelos de análise realizados durante os passos do processo BVCCoN, que foca em uma clara separação de interesses. De La Vara et al. (2010) [5] usa variabilidade de contexto para definir variabilidade de processos. Na BVCCoN, quando o contexto é aplicado, os pontos de variação e variantes já estão definidos. Isto reduz a análise de contexto para apenas contextos relevantes, evitando problemas com a cobertura do modelo de processo e reduzindo a análise de contexto que não será utilizada.
Quando comparado com a abordagem proposta por Lapouchnian et al. (2007) [29], podemos ver que a integração de metamodelos também é uma vantagem. Observe que em BVCCoN, a análise de requisitos é realizada independemente da análise de variabilidade. Durante a construção do modelo BVCCoN, a análise de contribuição estabelece ligações entre variantes e RNFs. Por isso, a análise de preferências pode ser refeita se uma variante é adicionada ou removida. Ao contrário, a abordagem proposta por Lapouchnian et al. (2007) mistura as informações de processo com a descrição de variabilidade e softgoals. Quando uma variante é adicionada ou removida, todo o modelo deve ser revisado.
Diferente das outras duas abordagens, La Rosa [28] propôs compartilhar menos, similar a BVCCoN. É utilizado diferentes estratégias para lidar com variabilidade e
confi-46
guração. Por esta razão, La Rosa foca na redução da intervenção do usuário na realização da configuração, a abordagem BVCCoN tenta reduzir a necessidade da interação com o usuário durante os passos da configuração.
Algumas abordagens apresentaram ferramenta de suporte, porém, os benefícios podem ser limitados devido a abrangência da ferramenta em relação as etapas das abor-dagens. A comparação foi baseada na avaliação de documentos, assim, as ferramentas de suporte não foram avaliadas. Mesmo compartilhando algumas características em comum com as outras abordagens, a BVCCoN mostra mais vantagens que desvantagens quando considerado o cenário da configuração de processos dinâmicos. BVCCoN é uma abordagem mais completa, sua ferramenta permite modelar diferentes perspectivas relaci-onadas aos processos de negócio (requisitos não-funcionais, variabilidade e informações 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 sumário das abordagens em relação aos critérios discutidos anteriormente.
Tabela 2.4 Sumário de Critérios
Abordagem Variabilidade Configuração Modelo de Processo Ferramenta
La Rosa (2009) C-YAWL/YAWL Seleção de Nós Questionário e C-YAWL Sim
Lapouchnian et al. (2007) Modelo de Goals/BPEL Transformação de modelos Modelo de goals Sim
De La Vara et al. (2010) BPMN estendido Validação de contexto Modelo BPMN Não
BVCCoN BPMN Transformação de modelos Modelo BVCCoN Sim
2.3
Meta-Modelagem
A meta-meta-modelagem é responsável por definir uma linguagem para a especificação de metamodelos. A Object Management Group (OMG) definiu uma linguagem para a especificação de metamodelo denominada Meta Object Facility (MOF) [37]. Esta linguagem oferece um framework para o gerenciamento de metadados e um conjunto de serviços de metadados para permitir o desenvolvimento e a interoperabilidade de modelos e sistemas que utilizam metadados.
As tecnologias da OMG, incluindo UML (Unified Modeling Language), MOF, XMI1, dentre outras, usam MOF e tecnologias derivadas de MOF para a troca e manipulação de metadados [37].
A Figura 2.7 apresenta uma infraestrutura em 4 camadas da primeira geração de tecnologias MDD, ou seja, UML e MOF. Esta infraestrutura apresenta uma hierarquia
1XMI é um formato de intercâmbio amplamente utilizado para o compartilhamento de modelos usando XML [38].
Figura 2.7 Infraestrutura Tradicional MDD. Adaptado de [3].
divida por modelos. Cada modelo (exceto o M3) é caracterizado como uma instância do nível acima.
O nível mais baixo, M0, é responsável por manipular os dados de usuário. Dados reais em que softwares são projetados para manipular. O nível M1 representa o próprio modelo, ou seja, é designado para manipular um modelo dos dados de usuário M0. O próximo nível, M2, é conhecido como metamodelo por ser um modelo de modelo. M2 é um modelo que mantém informações do modelo M1. Por último, M3 é um modelo de informações em M2, e por isso é chamado de meta-metamodelo [3].
Neste estudo, é proposto o desenvolvimento de um metamodelo (nível M2) para a ferramenta proposta. Sendo possível assim, gerar os níveis M1 e M0. O metamodelo a ser desenvolvido, será construído utilizando a tecnologia da UML, que é revisada na próxima seção.
2.3.1
UML - Unified Modeling Language
A UML é uma linguagem de modelagem proposta pela OMG, a qual é uma das mais usadas para especificação, construção e documentação de artefatos de software. É uma linguagem de modelagem de propósito geral, e pode ser usada para todos os domínios de aplicações como saúde, espaço aéreo e telecomunicações. Contudo, podem existir situações em que uma linguagem de um propósito tão geral e amplo não seja apropri-ado para a modelagem de aplicações de um domínio específico. Isto pode acontecer quando queremos expressar conceitos específicos de um determinado domínio, ou quando
48
queremos restringir ou customizar alguns dos elementos da UML.
A OMG discute duas abordagens possíveis para definir uma linguagem específica de domínio. A primeira é a criação de uma nova linguagem baseada nos mecanismos oferecidos pela própria OMG para definição de linguagens visuais. Assim, sintaxe e semântica dos elementos da nova linguagem precisam ser definidos de acordo com as características do domínio [20].
A segunda alternativa se concentra na especialização da UML. Alguns elementos da linguagem são especializados, impondo novas restrições sobre eles em relação ao metamodelo UML. A semântica dos elementos UML não é alterada (as propriedades de uma classe UML, associações, atributos, etc, serão os mesmos). Um profile em UML oferece mecanismos de extensões genéricos para a customização de modelos UML para domínios e plataformas particulares. Profiles são definidos utilizando stereotypes, tag definitionse constraints [20].
• Stereotypes: são definidos por um nome e um conjunto de elementos do metamo-delo que são anexados;
• Constraints: podem estar associadas a estereótipos, impondo restrições sobre os elementos do metamodelo correspondente;
• Tag definitions: é um meta-atributo adicional que é anexado a uma meta-classe de um metamodelo estendido por um Profile.
Para este estudo, foi utilizada a primeira abordagem para o desenvolvimento da ferramenta. Portanto, é necessário construir uma linguagem de modelagem específica de domínio para a abordagem BVCCoN.
2.3.2
DSML - Linguagem para Modelagem Específica de Domínio
Quando tratamos de um domínio específico, as linguagens de modelagem, como por exemplo, UML, BPMN e i*, podem não conter todos os elementos necessários para realizar a modelagem. Assim, pode ser útil a criação de uma linguagem específica de domínio, (do inglês DSL - Domain Specific Language) para descrever com maiores detalhes as características mais importantes de um domínio específico.
Uma DSL é uma linguagem que está direcionada em um domínio particular de problema, oferecendo um conjunto restrito de notações e abstrações apropriadas. Contudo, as DSLs contém uma linguagem de propósito geral (do inglês, GPL - General Purpose
Language) incorporada como uma sub-linguagem. Assim, oferecem um poder expressivo específico do domínio em conjunto com o poder de expressividade de uma GPL [51].
Isto acontece quando DSLs são implementadas como linguagens embarcadas. Por-tanto, quando não é desejado criar uma linguagem de programação, é melhor herdar toda infraestrutura de alguma outra linguagem, adequando-a em formas especiais para o domínio de interesse. Assim, é possível adquirir uma Linguagem Embarcada Específica de domínio (do inglês, DSEL - Domain Specific Embedded Language) [22].
Já uma Linguagem para Modelagem Específica de Domínio (do inglês, DSML -Domain Specific Modeling Languages) objetiva elevar o nível de abstração, especificando a solução em uma linguagem que usa diretamente os conceitos e regras de um domínio de problema específico. A ideia é modelar produtos de software utilizando DSL e gerar produtos finais em uma linguagem de programação escolhida ou em outras formas, como texto, modelo, código, a partir das especificações de alto nível que foram definidas [24]. As DSLs são classificadas como interna, externa e não textuais. Uma DSL interna é aquela que usa toda infraestrutura de uma linguagem de programação existente para construir semânticas específica de domínio sobre a mesma. Uma das mais populares DSL interna é Rails [44], que é implementada em cima da linguagem de programação Ruby[43]. Escrevendo código Rails é a mesma coisa que programar em Ruby, só que utilizando a semântica que Rails implementa para o desenvolvimento de aplicações web [21].
Uma DSL externa é aquela que é desenvolvida similar à implementação de uma nova linguagem de programação, possuindo sua própria sintaxe e semântica. Uma DSL necessita ser uma representação do domínio, mas isto não implica que sua representação precisa ser apenas textual. DSL não textual é aquela que pode modelar o domínio utilizando formas gráficas [21]. Nesta dissertação foram utilizados formas gráficas para modelar o domínio da configuração de processos de negócio dinâmicos.
Para definir uma DSL, é necessário desenvolver uma sintaxe concreta e abstrata, seguida de uma semântica projetada para definir o significado da linguagem. Uma sintaxe abstrata de uma linguagem é definida a partir do método de meta-modelagem. Isto simplifica o desenvolvimento da linguagem, permitindo aos designers mapear diretamente as classes da análise de domínio para classes no metamodelo, associações e herança que são parte da definição da DSL.
A sintaxe abstrata descreve os conceitos da linguagem, as relações entre eles e as regras de estruturação que restringem a combinação de elementos do modelo de acordo com as regras de domínio. A partir do metamodelo, é construída a sintaxe
50
concreta. Ela especifica como os conceitos de domínio incluídos no metamodelo são representados, e é geralmente definido por um mapeamento entre o metamodelo e uma notação textual ou gráfica [26]. Durante o desenvolvimento da ferramenta, identificamos incompatibilidade entre sintaxe concreta e abstrata, portanto, realizamos alterações necessárias para solucionar o problema. Uma vez definido a linguagem específica de domínio, foi necessário utilizar tecnologias para o desenvolvimento da ferramenta.
2.4
Tecnologias
Esta seção é responsável por apresentar alguns conceitos e tecnologias que foram uti-lizadas para o desenvolvimento da ferramenta de modelagem proposta neste estudo. Para o desenvolvimento da ferramenta proposta, foi utilizado um conjunto unificado de frameworksde modelagem, ferramentas e implementações de padrões encontrados na comunidade Eclipse [11].
Dentre os frameworks de modelagem, destaca-se o EMF (Eclipse Modeling Fra-mework) [10], que auxilia a especificação de metamodelos e provê funcionalidades para a geração automática do código Java respectivo, o GMF (Graphical Modeling Framework) [15], que é uma abordagem model-driven para o desenvolvimento de editores gráficos baseados no eclipse e o Epsilon [12], [7], que é uma família de linguagens e ferramentas destinadas à atividades de gerenciamento de metamodelos.
2.4.1
Eclipse Modeling Framework
O projeto EMF é um framework de modelagem e geração de código para a construção de ferramentas baseado em um modelo de dados estruturado (modelo de domínio). A partir de um modelo de domínio especificado em XMI ou em outro formato suportado, o EMF fornece ferramentas e suporte runtime à produção de classes Java que implementam esse modelo. Assim como um conjunto de classes adapter que permite a edição e visualização do modelo através de código Java, e um editor básico.
O EMF é composto de 3 peças fundamentais. 1) Framework EMF Ecore, que inclui um metamodelo Ecore para os modelos descritos e suporte runtime para os modelos, 2) EMF.Edit, que fornece um conjunto de classes genéricas reusáveis para a construção de editores para modelos EMF, e por último, 3) EMF.Codegen, responsável por gerar todo código necessário para construir um editor completo para um modelo EMF [10].
O metamodelo Ecore é composto pelos componentes Eclass, utilizado para represen-tar uma metaclasse; EAttribute, para represenrepresen-tar um atributo de uma Eclass; EReference,
utilizado para descrever associações entre classes; e EEnum, usado para descrever enume-rações. EMF possui três níveis de geração de código: 1) Modelo, oferece interface Java e implementação de classes para todas as classes descritas no metamodelo da ferramenta CASE a ser construída, 2) Adaptadores, capazes de gerar classes de implementação que adaptam as metaclasses do modelo para visualização e edição, 3) Editor, produz uma estrutura do modelo que poderá ser visualizada na fase de criação do editor gráfico [1].
2.4.2
Graphical Modeling Framework
GMF é um framework para a construção de editores gráficos a partir de metamodelos baseado em EMF. Para a construção de editores gráficos utilizando o GMF, é necessário seguir um processo bem definido. Para facilitar a execução deste processo, o desenvolve-dor pode contar com a ajuda de um painel chamado GMF Dashboard. Este painel serve como um guia durante o desenvolvimento. O GMF Dashboard está ilustrado na Figura
2.8[15].
Figura 2.8 Dashboard GMF
A geração de um editor gráfico GMF consiste na criação e manipulação de alguns arquivos.
1. Domain Model - representa o metamodelo utilizado para criar o editor gráfico. É necessário importar o metamodelo de domínio definido em Ecore;
2. Domain GenModel - arquivo .genmodel usado para gerar código do domain model; 3. Graphical Def Model - arquivo .gmfgraph responsável por definir os elementos gráficos que representarão cada um dos objetos que foram definidos no arquivo Ecore do Domain Model.
52
4. Tooling Def Model - arquivo com terminação .gmftool utilizado para definir 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 gráfico e aos elementos do modelo ferramental.
6. Diagram Editor GenModel - o GMF fornece um modelo de gerador para gerar o código executável do editor gráfico.
2.4.3
Epsilon
Epsilon é uma família de linguagens e ferramentas destinadas à atividades de gerencia-mento de metamodelos. Essas atividades são: geração de código, transformação modelo para modelo, validação de modelo, comparação, migração e refactoring de modelos [12]. Dentre as linguagens e ferramentas da família Epsilon, as seguintes se destacam:
• EuGENia • Emfatic
• EOL (Epsilon Object Language) • EVL (Epsilon Validation Language) • ETL (Epsilon Transformation Language) • EGL (Epsilon Generation Language) • EWL (Epsilon Wizard Language)
EuGENia é uma ferramenta que facilita a geração de editores gráficos em GMF, diminuindo a complexidade imposta pelo mesmo [13]. EuGENia gera ferramentas gráficas a partir de um metamodelo Ecore com anotações escritas na linguagem Emfatic [16]. Emfatic é uma linguagem que foi projetada para representar modelos Ecore EMF de maneira textual simples e compacta, similar à linguagem Java. Esta linguagem permite definir metaclasses, atributos de metaclasses, enumerações, 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, é possível gerar um modelo Ecore (arquivo .ecore),
o inverso também é possível. A partir do metamodelo .emf construído, é necessário enriquecê-lo com anotações em EuGENia, que definirá os artefatos concretos a ser representado no editor gráfico. Assim, é possível definir em Emfatic quais metaclasses são nós ou links, definir a figura (retângulo, elipse) de um nó que serão exibidos graficamente, definir a origem (source) e o destino (target) de um link. Tudo o que é definido no arquivo Emfatic é gerado um metamodelo Ecore de EMF. A partir do arquivo Ecore gerado, EuGENia gera os modelos EMF e GMF.
A Listagem 2.1demonstra uma versão anotada do metamodelo. Em particular, as anotações representam o seguinte:
• Linha 5: o elemento diagram representa o objeto raiz do metamodelo. Apenas uma Eclassnão 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 (associação) entre seus arquivos sourcee target. A representação gráfica do link é através de uma linha pontilhada; • Linha 31: cada arquivo é representado no diagrama como um retângulo que possui
um nome dentro.
Listagem 2.1 Metamodelo escrito em Emfatic
1 @namespace ( u r i =" f i l e s y s t e m " , p r e f i x =" f i l e s y s t e m " ) 2 @gmf 3 package f i l e s y s t e m ; 4 5 @gmf . d i a g r a m 6 c l a s s F i l e s y s t e m { 7 v a l D r i v e [ * ] d r i v e s ; 8 v a l Sync [ * ] s y n c s ; 9 } 10 11 c l a s s D r i v e e x t e n d s F o l d e r { 12 13 } 14 15 c l a s s F o l d e r e x t e n d s F i l e { 16 @gmf . c o m p a r t m e n t 17 v a l F i l e [ * ] c o n t e n t s ;
54 18 } 19 20 c l a s s S h o r t c u t e x t e n d s F i l e { 21 @gmf . l i n k ( t a r g e t . d e c o r a t i o n =" a r r o w " , s t y l e =" d a s h " ) 22 r e f F i l e t a r g e t ; 23 } 24 25 @gmf . l i n k ( s o u r c e =" s o u r c e " , t a r g e t =" t a r g e t " , s t y l e =" d o t " , w i d t h = " 2 " ) 26 c l a s s Sync { 27 r e f F i l e s o u r c e ; 28 r e f F i l e t a r g e t ; 29 } 30 31 @gmf . n o d e ( l a b e l = " name " ) 32 c l a s s F i l e { 33 a t t r S t r i n g name ; 34 }
Existem inúmeras anotações além das que foram exibidas na Listagem2.1. Em [14], é apresentado a listagem completa de todas as anotações que o Eugenia oferece para serem inseridas em um modelo que foi criado utilizando a linguagem Emfatic.
EOL é uma linguagem de programação imperativa para criar, consultar e modificar modelos EMF. Fornece características imperativas habituais como presença de variáveis, comandos sequenciais, estruturas de controle e de desvio condicional, além de outras características. Outras linguagens da família Epsilon como EVL, podem incorporar porções código EOL em suas estruturas de código [7].
EVL é uma linguagem de validação que pode ser utilizada para adicionar validações e fazer pequenos ajustes no editor gráfico GMF [18]. As restrições em EVL são similares às OCL2, porém, EVL suporta dependência entre constraints (se uma constraint A falha, a constraint B não será avaliada). Mensagens de erro customizadas podem ser exibidas aos usuários e um mecanismo de conserto pode ser ativado pelos usuários para reparar inconsistências[7].
Em EVL, as especificações de validação são organizadas em módulos. A Listagem
2.2exibe um trecho de código escrito em EVL e os itens abaixo apresentam os módulos EVL. Em seguida, é indicado as linhas da Listagem2.2 em que determinado módulo aparece.
• Context - um contexto especifica o tipo de instância que as invariantes serão
aplicadas (Linhas 1 e 8);
• Invariant - cada invariante EVL define um nome e uma verificação (check). Uma invariante também pode definir uma mensagem que será exibida ao usuário caso alguma restrição falhe. Para apoiar o conserto semiautomático de elementos, uma invariante pode definir um número de fix (Linhas 4 e 12);
• Guard - Guards são usados para limitar a aplicabilidade de invariantes. Um guard limita a aplicabilidade de todas as invariantes do contexto, enquanto a nível de invariant, guard limita a aplicabilidade de uma invariante específica (Linha 10); • Fix - Fix determina ações a serem realizadas para corrigir uma inconsistência. A
parte de código "do"encontrada na Listagem2.2, é definida usando a linguagem EOL e é responsável pela correção da funcionalidade;
• Constraint - Constraints são usadas para capturar erros críticos que invalidam o modelo (Linha 2);
• Critique - ao contrário de constraints, critiques são usadas para capturar situações que não invalidam o modelo, mas que devem ser levadas em consideração pelo usuário para melhorar a qualidade do modelo (Linha 9).
• Pre and Post - um módulo EVL pode definir um número de blocos chamados pre e post que são escritos em EOL e executados antes ou depois de uma invariante ser avaliada respectivamente.
Listagem 2.2 Exemplo de Código EVL
1 c o n t e x t F i l e {
2 c o n s t r a i n t HasName {
3 c h e c k : s e l f . name . i s D e f i n e d ( )
4 message : ’ Unnamed ’ + s e l f . e C l a s s ( ) . name + ’ n o t a l l o w e d ’
5 } 6 } 7 8 c o n t e x t F o l d e r { 9 c r i t i q u e N a m e S t a r t s W i t h C a p i t a l { 10 guard : s e l f . s a t i s f i e s ( ’ HasName ’ ) 11 c h e c k : 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 12 message : ’ F o l d e r ’ + s e l f . name + 13 ’ s h o u l d s t a r t w i t h an u p p e r −c a s e l e t t e r ’
56 14 f i x { 15 t i t l e : ’ Rename t o ’ + s e l f . name . f i r s t T o U p p e r C a s e ( ) 16 do { 17 s e l f . name : = s e l f . name . f i r s t T o U p p e r C a s e ( ) ; 18 } 19 } 20 } 21 }
O objetivo da linguagem ETL é realizar transformações de modelos (model-to-model). Mais especificamente, ETL pode ser usado para transformar um número arbitrário de mo-delos de entrada para um número arbitrário de momo-delos de saída de diferentes linguagens de modelagem e tecnologias em um alto nível de abstração [17]. EGL é uma linguagem model-to-text. A partir de um metamodelo construído em Ecore, pode-se obter código executável, relatórios HTML, documentação, imagens (usando pontos) e outros artefatos textuais [25] [7].
Transformações de atualização são ações que automaticamente cria, atualiza ou deleta elementos do modelo baseado na seleção de elementos existentes no modelo e nas informações fornecidas pelo usuário (através de dados de entrada). EWL é a linguagem da família Epsilon que oferece esse suporte [7].
2.4.4
Estudos que Desenvolveram Ferramentas de Modelagem
A seguir, apresentamos estudos que realizaram pesquisa na área de desenvolvimento de ferramentas de modelagem. Estes estudos utilizaram tecnologias que também foram utilizadas nesta dissertação, como o Framework Eclipse em conjunto com os plugins EMG/GMF e também o Framework Epsilon.
IStar Tool - Uma Proposta de Ferramenta para Modelagem i*
O estudo descrito em [46] propõe o desenvolvimento de uma ferramenta de modela-gem i*. Um novo metamodelo é desenvolvido para a nova versão do i* e um processo de desenvolvimento para obter uma ferramenta gráfica de modelagem.
Para o desenvolvimento da ferramenta, foi adotado o GMF Framework, que permite a modelagem do domínio e a geração automática de código para representar os elementos gráficos que farão parte do modelo. O metamodelo foi criado a partir do Framework EMF e escrito em Ecore.
A partir de um guia i* (contendo guidelines e boas práticas), o autor definiu um conjunto de restrições que foram escritas utilizando a linguagem de restrição OCL. Um
exemplo de restrição é que um elemento não pode se ligar a ele mesmo. Uma segunda restrição é que a utilização do link de associação só é permitida para nós do tipo ator.
Após o desenvolvimento da ferramenta, a mesma foi aplicada em diferentes cenários, visando exemplificar seu uso e também realizar uma verificação para ver se as restrições que foram definidas anteriormente estavam sendo executadas corretamente. A conclusão obtida foi que a ferramenta se comportou de maneira apropriada.
Uma Linguagem Específica do Domínio para uma Abordagem Orientada a Ob-jetivos Baseada em KAOS
O estudo apresentado em [6], demonstra um novo metamodelo da linguagem 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 (Comparti-mentos) em que é possível guardar elementos específicos pertencentes aquela caixa. Estas caixas possuem uma característica de colapso, em que a partir de um clique é possível apresentar ou omitir porções do diagrama.
A ferramenta apresentada nesta dissertação também possui este conceito de compar-timento. Assim, é possível esconder ou apresentar pedaços do modelo, obtendo uma melhor escalabilidade e diminuindo a complexidade visual. Visto que a capacidade de colapso facilita a leitura dos modelos.
Para projetar o editor gráfico, os autores utilizaram o Framework Eclipse em conjunto com os plugins EMF/GMF. Estenderam o metamodelo Ecore já existente e definiram no metamodelo o que irá representar os conceitos da linguagem KAOS. Para validar a ferramenta os autores realizaram um estudo de caso e uma avaliação de usabilidade.
A avaliação de usabilidade consistiu de um questionamento sobre a sintaxe da lin-guagem, facilidade de utilização da ferramenta e níveis de satisfação da ferramenta. Em geral, os utilizadores mostraram grande aceitação da ferramenta. Ficaram satisfeitos e a acharam fácil de utilizar.
AGILE: Uma Abordagem para Geração Automática de Linguagens i*
Em [4], o autor definiu uma abordagem automatizada para a definição estrutural de linguagens baseadas no i* e a geração automática de ferramentas CASE de modelagem correspondentes utilizando os conceitos de linhas de produtos de software.
As tecnologias utilizadas para desenvolver uma ferramenta que automatize a definição de metamodelos de linguagens i* e a geração automática de editores gráficos foram o EMF/GMF, baseadas no Eclipse. O autor definiu um metamodelo núcleo (escrito em
