CONFIGURAÇÃO DO AMBIENTE - AUTOMAÇÃO DAS TRANSFORMAÇÕES

3. AUTOMAÇÃO DAS TRANSFORMAÇÕES

3.1. CONFIGURAÇÃO DO AMBIENTE

As atividades “Refatorar Modelos de Requisitos” e “Derivar Soluções Arquiteturais” do processo STREAM apresentam algumas regras de transformação. Estas regras de transformação podem ser definidas precisamente usando a linguagem de transformação QVTO (Query/View /Transformation Operational) (OMG, 2011), em conjunção com OCL (Object Constraint Language) (OMG, 2001)para representar as restrições.

O processo de transformação requer a definição das regras de transformação e metamodelos para as linguagens fonte e alvo. A atividade 1) apresenta as regras de transformação horizontais, as HTRs, que objetivam melhorar a modularidade dos modelos i* e têm a linguagem i* como linguagem fonte e alvo. A atividade 2) apresenta as regras de transformação verticais, que aqui apresentamos como VTRs, e que objetivam transformar modelos i* modularizados em modelo arquitetural inicial em Acme.

As regras foram definidas em QVTO e executadas através do plugin para a plataforma Eclipse. As transformações são especificadas com base em metamodelos. Nas regras de transformação horizontais as linguagens fonte (do artefato modelo i* junto com as escolhas do engenheiro) e alvo (modelo i* modularizado) são a mesma, i*. O metamodelo desta linguagem utilizado neste trabalho é o que está presente na ferramenta iStarTool.

Foi utilizada iStarTool, uma ferramenta que permite a modelagem em i*. Ela foi desenvolvida pelo grupo onde esta dissertação foi desenvolvida. E foi utilizada aqui para facilitar a construção do artefato de entrada para aplicação das regras de transformação horizontais.

Em QVTO, é desta forma que fazemos referência ao metamodelo da linguagem i*, presente na iStarTool:

Nas regras de transformação verticais as linguagens fonte e alvo são diferentes, visto que o modelo de entrada é um modelo de requisitos e o modelo de saída é um modelo arquitetural, portanto as linguagens fonte e alvo são i* e Acme, respectivamente. O metamodelo de Acme utilizado neste trabalho é o apresentado na seção 2 do capítulo 2 desta dissertação. Fazemos referência a este metamodelo desta forma:

modeltype ISTAR uses istar ("http://www.cin.ufpe.br/istar");

Na configuração de QVT (QVT Settings) do projeto, é necessário referenciar todos os metamodelos a serem utilizados no projeto. Na Figura 14 é possível visualizar o metamodelo da linguagem i* presente na iStarTool. Ele está em formato Ecore, referenciado pela descrição da pasta onde se encontra no projeto em questão e pela URL especificada no próprio metamodelo Ecore.

Figura 18. QVT Settings

As regras de transformação horizontais precisam ser definidas utilizando um único arquivo de entrada e saída. Esse arquivo receberá as modificações em seu próprio corpo e será também o arquivo de saída.

As regras de transformação verticais são definidas utilizando um arquivo de entrada e um de saída. O arquivo de entrada será utilizado como referência para fazer as modificações (do tipo ISTAR), porém outro arquivo será gerado com as modificações (do tipo ACME).

Após especificar a quantidade e o tipo dos arquivos de entrada e saída, a configuração para execução da transformação habilita os campos para entrada dos arquivos. O arquivo de entrada deve ser apontado. Se o arquivo de saída for apontado, transformation Htr2Htr3Htr4(inout oriModel : ISTAR);

ele será sobrescrito, caso não seja apontado, será gerado. Na Figura 19 podemos visualizar a configuração da transformação horizontal. Contornado de azul podemos visualizar o arquivo fonte das transformações, em QVTO, em verde visualizamos o arquivo XMI para entrada nas transformações.

Figura 19. Configuração de Execução da Transformação Horizontal

O QVTO processa arquivos XMI. Para que o plugin do QVTO para o Eclipse leia o arquivo XMI, é necessário que esse arquivo possua na sua tag principal, ou seja, na tag onde tem o elemento da classe que representa o “palco” 1 (no metamodelo da linguagem i* é a classe Model), o atributo xsi:schemaLocation, que referencia a URL cadastrada no metamodelo em formato Ecore, seguido do nome do metamodelo.

Para ter o atributo xsi:schemaLocation é necessário ter o atributo xmlns:xsi, que informa que o documento deve ser validado contra um esquema, além das tags

xmi:version, xmlns:xmi e xmlns:istar (ou xmlns:Acme), que especificam,

respectivamente, a versão do XMI utilizada, a URL onde está presente o XMI e a URL cadastrada no metamodelo Ecore.

No Quadro 2 há um exemplo de um arquivo XMI produzido pela iStarTool, um detalhe do sistema BTW visualizado em modo texto. O detalhe representa um modelo i* em XMI baseado no metamodelo referenciado no atributo xsi:schemaLocation. A

1_{“palco” da modelagem é a tela de modelagem da ferramenta onde é permitido criar os}

linha 1 apresenta a tag principal de um arquivo XML. As linhas de 2 a 6 apresenta a tag principal de um arquivo produzido na iStarTool, é a tag da classe Model com todos os atributos. As linhas de 7 a 15 apresentam tags de elementos com seus nomes e tipos e a linha 16 apresenta uma tag de ator sem fronteira. A linha 17 é o fechamento da tag referente à classe Model.

O modelo apresenta nove elementos, três tarefas (Use Maps Service, Furnish Feedback e Trace Route), três softgoals (Relevant Advices, Precise information e Usuability), dois goals (Advice be Received e Advice be Published) e um recurso (Profile Information), e um ator sem fronteira de nome actor.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <?xml version="1.0" encoding="UTF-8"?>

<istar:Model xmi:version="2.0" xmlns:xmi=http://www.omg.org/XMI xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xmlns:istar="http://www.cin.ufpe.br/istar"

xsi:schemaLocation="http://www.cin.ufpe.br/istar istar.ecore" title="titulo">

</istar:Model>

Quadro 2. Detalhe do arquivo XMI do BTW

A Figura 20 mostra o mesmo modelo i* presente no Quadro 2, visualizado no Editor XMI no Eclipse e acrescido de quatro atores (Internet Provider, Advice Receiver, Advice Giver e Travelers) e duas ligações de dependência.

A seguir, descrevemos as duas primeiras atividades do processo STREAM e explicamos como foi desenvolvida a automatização das regras propostas por elas.

No documento Automatização das Regras de Transformação do Processo STREAM (páginas 57-61)