Depois de introduzida a linguagem sob um ponto de vista geral, neste capítulo enume- ram-se as construções que a linguagem permite. Nos apêndices A.1 e A.2 encontra- se, respectivamente, o metamodelo correspondente à gramática do SATEL e a sintaxe concreta escolhida para os trabalhos desta dissertação e que tem por base a gramática proposta originalmente. Nos apêndices, tanto o metamodelo como a gramática apre- sentados foram desenvolvidos na plataforma de modelação do Eclipse2, e contêm as
3. TRABALHO RELACIONADO 3.2. SATEL
construções adicionais (eg. ADT, APN), que serão discutidas nos próximos capítulos. Aqui apresenta-se apenas as que a SATEL suporta.
Assim sendo, a linguagem por defeito, como ❈♦♥❞✐t✐♦♥❆t♦♠, aceita as seguintes construções:
ConditionAtom Descrição
AlgEquality Igualdade entre dois termos algébricos SyncEquality Igualdade entre dois termos de sincronização
HMLEquality Igualdade entre dois termos HML(padrões de execução) BooleanEquality Igualdade entre dois termos Booleanos
ArithmeticEquality Igualdade entre dois termos aritméticos Not Negação de um termo booleano Positive Padrão de execução positivo Sequence Padrão de execução é uma Sequencia Trace Padrão de execução é um traço BooleanVariable Variável booleana
BooleanValue Valor booleano
BooleanAnd Conjunção de dois termos booleanos BooleanOr Disjunção inclusiva de dois termos booleanos BooleanEquals Igualdade entre dois termos aritméticos BooleanNotEquals Desigualdade entre dois termos aritméticos BooleanGT Desigualdade "Maior"entre dois termos aritméticos BooleanLT Desigualdade "Menor"entre dois termos aritméticos BooleanGTE Desigualdade "Maior ou Igual"entre dois termos aritméticos BooleanLTE Desigualdade "Menor ou Igual"entre dois termos aritméticos
Tabela 3.1: ConditionAtom’s aceites pela linguagem SATEL
Desta tabela (3.1) há alguns ❈♦♥❞✐t✐♦♥❆t♦♠ que necessitam de explanação adicio- nal, nomeadamente Positive, Trace, e Sequence que têm como argumento, um HMLTerm. Um HMLTerm é padrão de execução constituído por uma lista de fórmulas e/ou variá- veis ordenadas que veremos na tabela 3.3. Em rigor já vimos pelo menos duas: uma explícita HMLTop e outra implícita pelo operador de concatenção de caminhos (ponto); trata-se da fórmula HMLNext. E existem ainda duas outras fórmulas: HMLNot e HM- LAnd.
Informalmente, um HMLNext é um construtor de caminho que possui dois argu- mentos. Um evento e uma fórmula seguinte. É portanto um operador que permite sequenciar caminho. Por seu turno, um HMLNot é um construtor de caminho pela ne- gativa que tem um HMLTerm como argumento, i.e., quando aparece um HMLNot no padrão de execução significa que se pretendem todos os caminhos que não contêm o argumento desse HMLNot a partir do ponto em que este aparece. A figura 3.4 retrata essa situação.
Em relação ao construtor HMLAnd, este, por seu turno, permite construir caminhos que possuem ramos de execução diferentes. Num caminho que possua um HMLAnd, o traço de execução nesse ponto é decidido não deterministicamente por um dos ramos do HMLAnd.
Posto isto, pode-se já entender o que são os ConditionAtom atrás referidos: Positive, 40
3. TRABALHO RELACIONADO 3.2. SATEL
HMLNext HMLNext
HMLNext HMLNot
HMLNext HMLNext
HMLNext
Figura 3.4: Visualização de um HMLTerm contendo fórmulas HMLNot
Trace, e Sequence. Positive tem valor de verdade quando o seu argumento não possui fórmulas negativas HMLNot. Sequence tem valor de verdade quando o seu argumento não possui HMLAnd. E por fim, Trace tem valor de verdade quando para o seu argu- mento, os ConditionAtom, Positive e Sequence têm também valor de verdade. De modo mais informal, um caminho é um traço de execução se não contém negações e bifur- cações. Mais se acrescenta que para esta dissertação o interesse recai sobre caminhos que sejam traços, sendo que os que não são, estão direccionados para trabalho futuro, a partir desta tese.
Em relação aos ArithmeticTerm, que são argumentos de alguns ConditionAtom da tabela 3.1, a linguagem SATEL define os seguintes presentes na tabela 3.2.
ArithmeticTerm Descrição
IntegerVariable Variável Número Inteiro IntegerValue Valor Inteiro
BOPPlus Soma de dois Inteiros BOPMinus Subtracção de dois Inteiros BOPTimes Multiplicação de dois Inteiros BOPDiv Divisão Inteira de dois Inteiros
NBEvents Medida de dimensão de caminho: Número de eventos. Depth Medida de dimensão de caminho: Profundidade. UOPMinus Negação unária sobre inteiros
Tabela 3.2: ArithmeticTerm’s aceites pela linguagem SATEL
Pensa-se que os ArithmeticTerm aceites pela linguagem sejam auto-explanatórios, uma vez que a maioria são operações básicas sobre inteiros. Destinguem-se de entre todos o NBEvents e o Depth. Semanticamente, o NBEvents deve retornar o número de eventos de um padrão de execução segundo as seguintes regras informais:
Percorrendo um caminho de execução, se se encontrar uma fórmula: HMLTop: não é contabilizado nenhum evento.
HMLNext(Event(Synchronization(Input,Output)), h:HMLFormula): é contabilizado um evento por cada sincronização de in- put e somam-se ainda os eventos de h
HMLNot: são contabilizados os eventos do seu argumento
3. TRABALHO RELACIONADO 3.2. SATEL
Por outro lado o Depth, semanticamente, deve retornar a profundidade de um pa- drão de execução, i.e, o comprimento do maior ramo do padrão de execução. Deve ser calculado segundo as seguintes regras informais:
Ao se percorrer um caminho de execução, se se encontrar uma fórmula: HMLTop: nada é contabilizado.
HMLNext(Event), h:HMLFormula): o Depth é incrementado de uma unidade e soma-se ainda o Depth de h
HMLNot: é contabilizada a profundidade do seu argumento
HMLAnd: é contabilizado o máximo entre os Depth de cada argumento
Por fim a tabela 3.3 mostra as construções que permitem definir um padrão de execução.
HMLTerm ou relacionado Descrição
HMLTerm Padrão de execução
HMLNext Fórmula de padrão de execução que permite definir um evento e uma fórmula seguinte HMLTop Fórmula de padrão de execução equivalente a vazio
HMLNot Fórmula de negação de padrão de execução
SynchronizationInputTerm Referente a um método de input e respectivos parâmetros algébricos SynchronizationOutputTerm Referente a uma gate de output e respectivos variáveis algébricas de output.
HMLEvent Um evento constituído por um SynchronizationInputTerm e opcionalmente Synchroni- zationOutputTerm
Tabela 3.3: ArithmeticTerm’s aceites pela linguagem SATEL
Com a linguagem SATEL pode-se, como se viu, definir variáveis do tipo Inteiro (Pr✐♠✐t✐✈❡■♥t❡❣❡r e ❇♦♦❧❡❛♥) e de caminho de execução (Pr✐♠✐t✐✈❡❍▼▲). Adicionalmente podem ainda ser definidas variáveis de estímulo -Pr✐♠✐t✐✈❡❙t✐♠✉❧❛t✐♦♥ - e de observa- ção (Pr✐♠✐t✐✈❡❖❜s❡r✈❛t✐♦♥), utilizáveis nos padrões ❁✐♥♣✉t ✇✐t❤ ♦✉t♣✉t❃ e, por fim, variáveis algébricas de um determinado sort.
Aquando da resolução das variáveis, a linguagem ainda oferece duas construções unárias interessantes: hipótese de uniformidade e hipótese de subuniformidade so- bre qualquer variável. Quando aplicado um predicado de uniformidade sobre uma variável deve ser devolvido um valor aleatório disponível para essa variável, dadas as restrições sobre ela incidentes. Por outro lado, quando aplicada a hipótese de su- buniformidade deve ser escolhido um valor por cada comportamento despoletável pelo método de input envolvido na intenção de teste, dado o valor dessa variável. A título exemplificativo, se hipoteticamente a variável counter estivesse explicitamente implicada no segundo axioma do exemplo, que se tem vindo a explorar, tal como está implicada no terceiro axioma, aplicar uma hipótese de subuniformidade sobre essa va- riável resultaria na escolha de apenas dois valores para a instanciar: o valor suc10(zero)
3. TRABALHO RELACIONADO 3.3. DSLTrans - Transformação de modelos
e qualquer outro valor diferente que respeitasse a restrição lt(counter, suc10(zero)) =
true.
Apenas seriam seleccionados estes dois valores, pois são os suficientes para cobrir os dois possíveis comportamentos da APN; ou transita para o place✜♥✐s❤❡❞ ou incre- menta o valor de counter no place✐♥❝r❡♠❡♥t.
3.3
DSLTrans - Transformação de modelos
Embora não constitua um foco desta dissertação, a transformação de modelos acabou, após diferentes tentativas de implementação a explicitar nos próximos capítulos, por se revelar uma técnica útil e fundamental para a solução proposta. Existem diversas ferramentas que utilizam diferentes técnicas para transformar modelos conformantes com determinado metamodelo A em modelos conformantes com determinado meta- modelo B. Metamodelos estes que podem ser o mesmo (no caso das transformações endógenas) ou diferentes (transformações exógenas).
São exemplos do enorme grupo de ferramentas, o ATOM33, o ATL4(da plataforma
Eclipse), FUJABA 5e o DSLTrans6que é a principal ferramenta adoptada no desenvol-
vimento da presente dissertação.
A ferramenta DSLTrans7 [4] [18] é uma ferramenta de transformação de modelos
desenvolvida pelo grupo de investigação onde se insere esta dissertação. A ferramenta permite fazer transformações sendo apenas necessário indicar com regras qual o pa- drão que se pretende encontrar no modelo e qual o padrão que se pretende construir a partir desse. As regras estão organizadas em diferentes layers o que, semanticamente, impõe que regras de layers sequenciais sejam aplicadas pela ordem em que aparecem as respectivas layers.
A técnica usada permite que apenas se especifiquem as regras necessárias para re- conhecer os padrões que nos interessam, ao contrário do que acontece por exemplo com o ATL, cujas regras, são processadas de forma indutiva, sendo nesse caso neces- sário descrever regras para cada uma das classes que sejam containers directos ou in- directos das classes que nos interessam para os padrões. No ATL, o único caso em que não é necessário processar toda a sub-árvore até ao nó do padrão que interessa é nas transformações endógenas em modo de refinamento, que serve essencialmente para fazer manipulações no próprio modelo de entrada. Para uma visão mais detalhada
3http://atom3.cs.mcgill.ca 4http://eclipse.org/atl 5http://www.fujaba.de
6http://pessoa.fct.unl.pt/rlf18343/dsltrans_manual.pdf
3. TRABALHO RELACIONADO 3.3. DSLTrans - Transformação de modelos
atentemos no metamodelo da figura 3.5.
Universidade name : EString Faculdade name : EString Departamento name : EString Area name : EString faculdades 0..* departamentos 0..* areas 0..*
Figura 3.5: Metamodelo Universidades
Numa transformação em que apenas se quer encontrar todos os departamentos de um modelo, se esta for implementada no ATL é necessário definir regras para que se mapeem os objectos Universidade e Faculdade em entidades do metamodelo destino, por outro lado no DSLTrans apenas definimos uma regra cuja execução fará a identi- ficação/matching de todos os departamentos e que o mapeará em alguma entidade no metamodelo de destino.
Relativamente às regras do DSLTrans, e reforçando a bibliografia do DSLTrans ante- riormente apresentada, veja-se a figura 3.6 e considere-se a existência de um metamo- delo destino minimalista que apenas contém uma classe ’Unidade’ contida por algum objecto e que apenas tem ‘name’ como atributo.
3. TRABALHO RELACIONADO 3.3. DSLTrans - Transformação de modelos inputmodel.xmi universidades.Universidades Layer unidades.Unidades Rule Depart2Unidade MatchModel Departamento name ApplyModel Unidade name FilePort Layer previousSource MetaModelIdentifier Rule MatchModel AnyMatchClass ApplyClass ApplyAttribute MatchAttribute AttributeRef AttributeRef Connection
Figura 3.6: Regra de transformação em DSLTrans
Através da figura notemos que é necessário indicar o modelo e metamodelo de entrada em❋✐❧❡P♦rt, e que a ele está ligada a primeira layer(a azul) pela relação ♣r❡✈✐✲ ♦✉s❙♦✉r❝❡. Em cada layer é também necessário indicar o metamodelo da instância que resultará da transformação. Isto é feito através de elementos▼❡t❛▼♦❞❡❧■❞❡♥t✐✜❡r.
Em cada layer podemos ter várias regras e cada regra contém duas secções: uma de match (▼❛t❝❤▼♦❞❡❧) e uma de apply (❆♣♣❧②▼♦❞❡❧).
Na secção de match colocam-se as classes dos objectos que queremos transformar bem como seus atributos e relações. Na secção de apply podemos fazer exactamente o mesmo através dos objectos adequados à secção ❆♣♣❧②▼♦❞❡❧ tais como ❆♣♣❧②❈❧❛ss e❆♣♣❧②❆ttr✐❜✉t❡. Adicionalmente podemos reutilizar valores que foram identificados na parte de match para construir objectos na parte de apply.
Podemos ainda referenciar objectos já criados em alguma regra de layers anteriores desde que devidamente identificados com um ❆♣♣❧②❆ttr✐❜✉t❡, que deve obrigatori- amente designar-se por ’ApplyAttribute’ ou simplesmente não ter designação. Este tipo de objecto deve ter uma restrição (❇❛❝❦✇❛r❞❘❡str✐❝t✐♦♥) para a classe que o possa
3. TRABALHO RELACIONADO 3.3. DSLTrans - Transformação de modelos
ter gerado. Por exemplo, relativamente à figura, o objecto Unidade que estamos a criar poderia hipoteticamente ter sido criado numa layer anterior a partir de um ob- jecto Departamento e, nesse caso, poderíamos indicar que queríamos usar o mesmo objecto desde que ambos, nas duas regras, tivessem um❆♣♣❧②❆ttr✐❜✉t❡ com o ❆t♦♠ contendo um identificador com o mesmo valor em ambas. Adicionalmente pôr-se-ia um❇❛❝❦✇❛r❞❘❡str✐❝t✐♦♥ da Unidade para o objecto Universidade.
É ainda possível no DSLTrans identificar padrões de associação entre classes que se relacionam tanto directamente como indirectamente.
Para finalizar consegue-se através do DSLTrans especificar padrões pela negativa e existenciais, isto é, temos objectos(❆♥②▼❛t❝❤❈❧❛ss, ❊①✐sts▼❛t❝❤❈❧❛ss e ◆❡❣❛t✐✈❡▼❛t✲ ❝❤❈❧❛ss) e relações (◆❡❣❛t✐✈❡▼❛t❝❤❆ss♦❝✐❛t✐♦♥ e ❆♣❧②❆ss♦❝✐❛t✐♦♥) que, conjuntamente, permitem expressar padrões como “Todos os departamentos sem faculdades”, ou “Todos os departamentos que contenham pelo menos uma faculdade”.
Para mais informação sobre o DSLTrans deve-se consultar a referência. Não obs- tante, no contexto da descrição da solução proposta conseguir-se-á explicitar de melhor forma o desenvolvimento de modelos de transformação via DSLTrans.