4 When Such Things Happen He Must Grit His Teeth
4.2 Script for Situation Six: Violence and the Segregation of Words
No caso de gerência de variabilidades em arquivos XMI, as seções anteriores ilustram que o uso de comentários/anotações sobre tais arquivos foram suficientes para permitir a criação automática dos modelos de derivação, assim garantindo que elementos de pro- cesso, tais como, atividades e tarefas pudessem ser tratados como variabilidades da linha de processo. Entretanto, alguns elementos de processo, assim como relacionamentos ex- istentes entre tais elementos e que também podem representar variabilidades, não são representados usando arquivos XMI individuais. Por exemplo, os passos definidos para
Figura 3.10: Modelo de configuração gerado pelo GenArch
uma tarefa são especificados dentro do próprio arquivo XMI que descreve a tarefa. Ou- tros exemplos de elementos de processo que não são definidos dentro de arquivos XMI exclusivos para isso foram: artefatos de entrada e saída, papéis participantes, conceitos relacionados e guias. Analisando a arquitetura e os arquivos gerados pelo EPF Composer, observamos que vários arquivos eram gerados em conjuntos com os arquivos relacionados diretamento aos artefatos de processo.
A Figura 3.12 mostra uma visualização do processo gerado pela ferramenta EPF. Podemos observar na figura que temos arquivos com os nomes a mesma nomenclatura atribuída às tarefas, por exemplo, Criar os Casos de Teste.xmi, Detalhar os Requisitos.xmi e Encontrar e Descrever os Requisitos.xmi. Esses arquivos gerados pela ferramenta re- cebem o nome de method content element, que possui o conteúdo do elemento de pro- cesso, e na sua criação pela ferramenta é nomeado da seguinte maneira: <method content element>.xmi, recebendo o mesmo nome que é dado ao elemento de processo. Observa- mos também que são criados arquivos que auxiliam na montagem do processo pela fer- ramenta agregando os elementos de processo, por exemplo temos os arquivos model.xmi dentro de uma camada superior chamada de delivery process, que por sua vez representa um modelo de processo completo e integrado para a realização de um tipo específico de projeto. Esse arquivo contém a referências para os descritores (tarefa, papel e produ- tos de trabalho), ou seja quando estamos definindo a variabilidade da linha de processo temos que levar em consideração que existe a necessidade de gerênciar variabilidades em pequenas granularidades. Por exemplo, se preferimos que a tarefa Criar os Casos de Testenão esteja presente em um processo derivado da linha de processo precisamos, além de retirar o elemento do processo Criar os Casos de Teste.xmi, retirar também a sua referência dentro do arquivo model.xmi. Da mesma forma deve ocorrer dentro do ar-
Figura 3.11: Arquivo xmi representando elemento do processo com multipla anotações de variabilidade
quivo plugin.xmi, este arquivo contém a referência para todos os elementos presentes no processo bem como os nomes de apresentação, uma breve descrição, e as relações para cada elemento, tais como orientação, entradas ou saídas (tarefas), a atribuição de papeis (tarefas), responsabilidade pelos produtos de trabalho (papel), etc
Para garantir a gerência de variabilidade de tais trechos de menor granularidade den- tro de arquivos XMI, foi utilizada outro recurso da ferramenta GenArch, denominado fragmentos. Um fragmento é caracterizado como um trecho de texto de qualquer tipo de artefato (código, arquivo de configuração, texto, etc) que pode ser inserido (ou não) dependendo da escolha de uma dada variabilidade, durante o processo de derivação na engenharia de aplicação. Ferramentas como pure::varians7 e Gears8 também oferecem
mecanismos parecidos com um propósito similar.
As Figuras 3.13 e 3.14 também ilustram as definições de fragmentos dentro dos mod- elos de arquitetura e configuração da linha de processo. Tais fragmentos representam trechos com tags XML que representam variabilidades a serem inseridas dentro dos ar- quivos que representam os elementos de processo. Usando a ferramenta GenArch, é possível selecionar um trecho de um arquivo específico e extrair tal trecho automatica- mente para um fragmento, realizando assim uma refatoração nos artefatos da LPS para expor tal variação. Tal refatoração transforma o arquivo cujo fragmento foi extraído em um template na linguagem XPand [EFFTINGE S.; KADURA, 2006], além de criar as
7Disponível em: http://www.pure-systems.com Acesso em: 3 Nov. 2009
8GEARS. Software Product Lines - Pragmatic Innovation from BigLever Software. 2009. Disponível
Figura 3.12: Visualização dos arquivos gerados pela ferramenta EPF na geração do Pro- cesso
respectivas entradas no modelo de arquitetura do processo e no modelo de configuração para representar o fragmento.
A Figura 3.15 ilustra como fica parte de um arquivo XMI após a extração de alguns trechos e associação destes à fragmentos específicos. O trecho de arquivo ilustrado rep- resenta a junção das tarefas relacionadas ao nosso processo. Das três tarefas associadas ao processo, uma foi identificada como opcional, conforme nossa análise do projeto para identificação de similaridades e variabilidades. A Figura 3.16 apresenta a extração de parte do código XMI do arquivo plugin.xmi e sua associação a um fragmento gerenciado pela ferramenta GenArch. No template temos que o trecho referente a tarefa Criar os Ca- sos de Testefoi extraído para um fragmento denominado Criar_os_Casos_de_Teste que foi associado posteriormente a uma feature de mesmo nome no modelo de configuração. Esta associação possibilita que cada um desses fragmentos seja inserido no arquivo da especificação final do processo derivado apenas se as features a eles relacionadas forem selecionadas.
A seção seguinte utiliza os resultados obtidos neste estudo de modelagem de vari- abilidades em diferentes granularidades para permitir que a derivação e customização dos
Figura 3.13: Modelo de Arquitetura do Processo gerado pelo GenArch com a adição de Fragmentos
processos ocorram de forma a manter a integridade das referências entre os elementos presentes na linha de processo.
3.4
Derivação e Customização Automática de Processos
A etapa apresentada nesta seção consiste na derivação e customização de um pro- cesso, a partir dos modelos de derivação e artefatos que representam a implementação da linha de processo. Assim, após a realização de todas as atividades anteriores, resta ao engenheiro de processo selecionar, usando a ferramenta GenArch, o conjunto de car- acterísticas variáveis (variabilidades) que ele deseja para o seu processo, e também uti- lizando esta ferramenta podemos executar a derivação da linha em um novo processo de software A atividade de customização do processo consiste basicamente na seleção ex- plícita de quais características opcionais e alternativas se deseja ter no processo que será derivado da linha de processo. A seleção de features é baseada nas características de um projeto específico, bem como na experiência dos engenheiros de processo, responsáveis pela customização do processo que será usado em tal projeto, uma vez que toda a base de
Figura 3.14: Modelo de Configuração gerado pelo GenArch com a adição de Fragmentos conhecimento do que seria disponibilizado como característica opcional ou alternativa foi baseado no conhecimento de processos aplicados em diversos projetos desenvolvidos por uma empresa, chamados de processos legados, ou por empresa especializada em prestar consultoria para definir, implantar ou implementar melhorias em processos de software [BARRETO et al., 2010].
A Figura 5.6 ilustra o processo de seleção de variabilidades no modelo de caracterís- tica que é realizado dentro da ferramenta GenArch, para a seleção das variabilidades no modelo de característica é preciso criar um configuration of feature, como pode ser visual- izado nesta figura. Importante lembrar que no modelo de configuração estão definidos os mapeamento das features para os elementos do processo, sejam eles arquivos individuais ou trechos (fragmentos) de arquivos específicos. São esses mapeamentos que são proces- sados pela ferramenta de derivação para decidir quais arquivos e fragmentos devem entrar na especificação de processo sendo gerada. Como exemplo de derivação de um novo pro- cesso partindo na nossa linha de processo de software, partiremos do princípio que para o desenvolvimento de um projeto específico não será necessário a realização da tarefa Criar os Casos de Teste , que está caracterizada como opcional na linha de processo, porém será necessário ter a presença de um Testador para a realização a realização da tarefa de Detalhar os Requisitos que tem o Testador como papel opcional. Obedecendo esta customização temos o configuration of feature selecionado como demonstrado na Figura 5.6. Após a operação de derivação teremos um processo baseado na linha que não contém a tarefa de Criar os Casos de Teste , que será utilizado para apoiar o desenvolvi- mento de um projeto em específico. A Figura 3.18 demostra o resultado da derivação do
Figura 3.15: Arquivo XMI após ser transformado em um template segundo a linguagem XPand
processo.
Como resultado dessa geração automática, é criada uma estrutura de diretórios semel- hante a definida para a linha de processo, mas com as devidas adaptações realizadas levando em consideração as features selecionadas. Tal seleção implica na inclusão ou não de determinados arquivos ou trechos de arquivos (fragmentos) na especificação EPF que representa o processo desejado. Após a derivação, a estrutura de diretórios gerada, por ser a mesma estrutura da linha de processo, pode ser importada pelo EPF Composer e um site correspondente a esse processo customizado pode ser finalmente gerado, além de proporcionar toda manipulação de informação oferecida pelo EPF Composer.
3.5
Transformação de Modelo de Processo para Modelo
de Workflow
Tendo derivado o processo de software, temos agora um processo específico e mode- lado para um dado projeto. De acordo com as diretrizes da abordagem proposta neste tra- balho precisamos realizar uma transformação do modelo de processo de software em um modelo de workflow, sendo este uma especificação de um metamodelo JPDL. A Figura 3.19 ilustra a estrutura do nosso processo, agora uma derivação da nossa linha de pro- cesso, na forma de um WBS (Work Breakdown Structure) através do Eclipse Process Framework (EPF).
Figura 3.16: Extração de código para fragmento
Para permitir a implantação e execução da especificação do processo EPF em um mo- tor de workflow, precisamos transformar tal especificação que segue o metamodelo UMA, em um modelo de workflow, que segue a especificação do metamodelo JPDL de forma a permitir sua execução no motor de execução de workflow jBPM. O conjunto de ele- mentos do processo definidos no EPF é atualmente disponibilizada na forma de um mod- elo do Eclipse Modeling Framework (EMF), composta por uma série de arquivos XMLs com extensão .XMI, que na verdade são instâncias do metamodelo UMA. O metamod- elo UMA define uma terminologia e esquema para representar elementos do processo. Cada processo UMA especificado e modularizado no EPF, usando pequenas unidades, são denominadas conteúdo de método (method content)9.
A transformação de modelo para modelo - especificação de processo UMA para a especificação de workflow jPDL - é implementada na nossa abordagem utilizando o QVT Operational, que é uma linguagem que segue a especificação QVT (Query / Views / Trans-
9Eclipse Process Framework (EPF) Composer 1.0 Architecture Overview. 2010. Disponível em:
Figura 3.17: Processo de seleção de variabilidades no modelo de característica dentro da ferramenta GenArch
formations)[LAARMAN, 2009]. O QVT é uma linguagem padrão da OMG para expres- sar consultas, exibições e transformações em modelos MOF (Meta-Object Facility). Para a implementação das funções de transformação em QVTO, foram mapeados os diferentes tipos de elementos existentes na especificação de processo para um equivalente na especi- ficação do workflow. A Figura 3.20 apresenta uma tabela que ilustra o mapeamento entre tais elementos.
A Figura 3.21 apresenta uma visão parcial da implementação QVTO para a trans- formação dos modelos de processo. A criação das regras de transformação envolveu a solução de alguns problemas relacionados ao mapeamento entre as abstrações dos dife- rentes metamodelos. Um destes problemas foi a forma de encadeamento das atividades (activities)no UMA que é diferente da forma de encadeamento de tarefas no jPDL. No metamodelo UMA temos cada atividade apontando seu predecessor, já na linguagem jPDL cada task-node (elemento que representa a atividade de UMA, ver Figura 3.21) aponta para suas sucessoras. Este problema também dificultou a criação dos nós join e fork, pois não existe tais informações nos elementos UMA.
No código apresentado na Figura 3.21, as duas linhas de códigos iniciais servem para instanciar os metamodelos envolvidos na transformação. As demais linhas de código são funções de mapeamentos entre os elementos dos metamodelos. No mapeamento, denom-
Figura 3.18: Processo derivado sem a presença da tarefa Criar os Casos de Teste inado Activity2TaskNode, podemos verificar, por exemplo, que a criação de um nó join no jPDL se dá através de um mapeamento direto de UMA para JPDL, pois tal elemento não está presente no modelo UMA de forma explícita. Sendo assim, tal transformação é feita através da verificação, em cada elemento Activity, para saber se a mesma possui mais de um predecessor, o que indica a existência de um nó join antes de tal atividade, caso seja verdade, é criado o nó join e uma transição entre ele e a atividade atual (como pode ser observado no rótulo 1 da Figura 3.21).
A Figura 3.22 ilustra um resultado da transformação de modelo-para-modelo do ma- peamento do processo modelado no estudo de caso. Podemos perceber que cada uma de suas tarefas (exemplos: Encontrar e Descrever os Requisitos, Detalhar os Requisitos) foram transformadas em elementos jPDL do tipo task-node. Finalmente, os passos de cada tarefa, foram mapeados em task . Como resultado da nossa transformação obtemos
Figura 3.19: Imagem com Work breakdown structure do processo derivado
uma instância do metamodelo jPDL que passa por mais uma transformação, desta vez uma transformação de modelo para texto, conforme descrito na próxima seção, para que daí então possa ser implantado no motor de workflow.
3.6
Transformação de Modelo de Workflow para Projeto
de Workflow
A transformação de modelo para texto da nossa abordagem utiliza como entrada o modelo jPDL, resultante da transformação de modelo para modelo, descrito na seção an- terior. A transformação de modelo para texto nos proporciona como resultado os arquivos necessários para a implantação do workflow de processo, que será implantado e executado no motor de execução de workflow jBPM.
A Figura 3.24 apresenta os arquivos resultantes da transformação Modelo para texto (M2T). Para a exibição de forma gráfica este plugin necessita de basicamente dois ar- quivos, um desses arquivos é gerado como resultado da transformação M2T, são os ar- quivos: (i) o arquivo XML com o conteúdo do nosso fluxo de trabalho, chamado de processdefinition.xml, este arquivo é gerado como resultado da transformação modelo- para-texto e (ii) outro arquivo XML chamado de gpd.xml que permite a visualização do processo de forma gráfica. Este último contém os nós e as posições de cada nó que representam os elementos presentes no workflow de maneira que sejá possível a sua vi-
Figura 3.20: Mapeamento elementos UMA e JPDL
sualização. A Figura 3.23 ilustra a notação gráfica para o workflow, sendo visualizado através do plugin editor de workflow do Eclipse Designer (GPD). Este arquivo também será interpretado pelo motor jBPM para a visualização gráfica do fluxo de atividades do processo no jBPM-console usando um browser.
Para a transformação de modelo para texto utilizamos o Acceleo, que é uma lin- guagem de geração de texto padrão da OMG, baseada em uma abordagem DDM. Ela permite a geração automática de código a partir de um metamodelo que esteja de acordo com o EMF. Essa transformação se dá a partir da construção de templates do Acceleo. Dessa maneira analisando os arquivos de configuração do jBPM que são necessários para a implantação e execução do workflow de processo, fomos capazes de construir templates Acceleo e a partir desses templates recuperar informações do modelo JPDL para que fosse possível a geração dos arquivos necessários a implantação, execução e gerencia- mento do workflow no engine jBPM.
O jBPM permite a criação de formulários web implementados no framework Java Server Faces (JSF), a partir de uma definição de um modelo de workflow jPDL. Tais formulários podem ser usados para acompanhar o fluxo de execução do processo. Esta funcionalidade de acompanhamento é responsável por armazenar informações sobre as tarefas e/ou decisões tomadas durante sua execução. Os formulários JSF gerados são customizados usando uma conjunto de tags específicas do jBPM o que habilita a sua implantação e reconhecimento automático por parte do seu motor de execução. Para enriquecer a geração de tais formulários, os templates que os representam na tecnolo- gia Accelleo, foram modificados para incluir um conjunto de componentes gráficos que
Figura 3.21: Fragmento de Código da transformação em QVTO
oferecem diversas informações de interesse que são coletadas do processo. Exemplos de componentes gerados para cada formulário são: (i) botões de upload para tarefas/passos associados a produção de artefatos; (ii) campos de data para indicar o período de real- ização da tarefa/passo; (iii) campos extras de texto para descrição e comentários extras da tarefa/passo; e (iv) caixas de seleção indicando o status (não iniciado, em andamento, finalizado, etc) das tarefas/passos do processo. A Figura 3.26 apresenta um template do Acceleo para a composição das páginas JSF que irão complementar com informações a execução das tarefas do nosso workflow. Utilizamos taglibs próprias do jBPM para que o motor possa executar o formulário e associá-lo ao processo. Vale observar a configuração no template de informações relativas as tarefas (tasks) e transições (transitions) entre as mesmas. Estes trechos de código são automaticamente gerados a partir do processamento do modelo de workflow. As transformações modelo-para-texto Acceleo são também re- sponsáveis pela geração de um arquivo de configuração (forms.xml) que relaciona cada tarefa do nosso fluxo a um formulário JSF. A Figura 3.25 apresenta o conteúdo deste ar- quivo. A seção seguinte apresenta o processo de implantação e execução do workflow, utilizando os artefatos gerados a partir da transformação modelo-para-texto.
Figura 3.22: Modelo JPDL, resultado da transformação modelo-para-modelo
Figura 3.23: Visualização do workflow através do Plug In GPD no eclipse