Listagem 4.1: Metamodelo SATEL - Classe APN
✶ c l a s s APN extends environmentmm : : Environment ✷ {
✸ p r o p e r t y ownedPlaces : Place [ + ] { composes } ;
✹ p r o p e r t y ownedArcs : Arc [ ∗ ] { composes } ;
✺ p r o p e r t y ownedVariables : adtmm : : V a r i a b l e [ ∗ ] { composes } ; ✻ a t t r i b u t e name : S t r i n g [ 1 ] ;
✼ p r o p e r t y methods : Method [ ∗ ] { composes } ;
✽ p r o p e r t y gates : Gate [ ∗ ] { composes } ; ✾ p r o p e r t y ownedTransitions : T r a n s i t i o n
[ + ] { composes } ; ✶✵ }
Listagem 4.2: Metamodelo SATEL - Classe Transition
✶ c l a s s T r a n s i t i o n extends Node ✷ {
✸ p r o p e r t y ownedGuard : guardmm : : Guard [ ? ] { composes } ; ✹ p r o p e r t y g a t e C a l l s : GateCall [ ∗ ] { composes } ; ✺ p r o p e r t y methodCall : MethodCall [ ? ] { composes } ; ✻ }
4.2.1
Composição das EAPN com a SATEL
Na secção anterior viu-se como foram estendidas as APN e localizámos no metamo- delo SATEL essa mesma extensão. Implicitamente acabou-se por ver também como foi feita a composição da SATEL com as EAPN. Na verdade se atentarmos ao metamodelo do SATEL, na linha 1 da listagem 4.3 vemos que um❍▼▲◆❡①t é composto por um ❍▼✲ ▲❊✈❡♥t, e que esse ❍▼▲❊✈❡♥t possui um ✐♥♣✉t❚❡r♠✿SynchronizationInputTerm e um ✐♥♣✉t❚❡r♠✿SynchronizationOutputTerm, que por sua vez podem ser ❙②♥❝❤r♦♥✐③❛t✐♦✲ ♥❊✈❡♥t■♥♣✉t❚❡r♠ (resp. ❙②♥❝❤r♦♥✐③❛t✐♦♥❊✈❡♥t❖✉t♣✉t❚❡r♠) ou uma variável ❲Pr✐♠✐t✐✲ ✈❡❙t✐♠✉❧❛t✐♦♥❱❛r❉❡❝ (resp. ❲Pr✐♠✐t✐✈❡❖❜s❡r✈❛t✐♦♥❱❛r❉❡❝) instanciável com qualquer ▼❡t❤♦❞❈❛❧❧ ou ●❛t❡❈❛❧❧.
A composição da SATEL com EAPN foi feita exactamente neste ponto. Tanto❙②♥❝❤✲ r♦♥✐③❛t✐♦♥❊✈❡♥t■♥♣✉t❚❡r♠ como ❙②♥❝❤r♦♥✐③❛t✐♦♥❊✈❡♥t❖✉t♣✉t❚❡r♠ têm uma referência event que pode ser respectivamente um■♥♣✉t❊✈❡♥t ou um ❖✉t♣✉t❊✈❡♥t. Assim, com o fim de compor ambas as linguagens tem-se que:
• um■♥♣✉t❊✈❡♥t da SATEL é um ▼❡t❤♦❞ das EAPN • um❖✉t♣✉t❊✈❡♥t da SATEL é uma ●❛t❡ das EAPN Mais ainda, formalmente tem-se que:
• (∀GG∈ P(SAT EL.AP N.Gate) ⇒ G specializes SAT EL.HM LF ormula.InputEvent) • (∀M M∈ P(SAT EL.AP N.M ethod) ⇒ M specializes SAT EL.HM LF ormula.OutputEvent)
4.3
Preliminares da solução
Uma descrição geral da solução foi apresentada no capítulo 1, onde a figura 4.1 foi exposta e uma pequena descrição de cada uma das etapas que dela constam foi apre-
4. ABORDAGEM PROPOSTA/SOLUÇÃO 4.3. Preliminares da solução
Listagem 4.3: Excerto do Metamodelo SATEL
✶ c l a s s HMLNext extends HMLFormulaContent ✷ { ✸ p r o p e r t y hmlFormulaContent : HMLFormulaContent [ 1 ] { !ordered, composes } ; ✹ p r o p e r t y hmlEvent : HMLEvent [ 1 ] { ! ordered,composes } ; ✺ } ✻ c l a s s HMLEvent ✼ { ✽ p r o p e r t y inputTerm : SynchronizationInputTerm [ 1 ] { ! ordered,composes } ; ✾ p r o p e r t y outputTerm : SynchronizationOutputTerm [ ? ] { ! ordered,composes } ; ✶✵ } ✶✶ c l a s s SynchronizationTerm { a b s t r a c t } ; ✶✷ c l a s s SynchronizationInputTerm extends SynchronizationTerm { a b s t r a c t } ; ✶✸ c l a s s SynchronizationEventInputTerm extends SynchronizationInputTerm ✶✹ { ✶✺ p r o p e r t y event : InputEvent [ 1 ] ; ✶✻ p r o p e r t y parameters : Parameter [ ? ] { composes } ; ✶✼ } ✶✽ c l a s s SynchronizationOutputTerm extends SynchronizationTerm { a b s t r a c t } ;
Listagem 4.4: Excerto do Metamodelo do SATEL ✶ c l a s s SynchronizationEventOutputTerm extends SynchronizationOutputTerm ✷ { ✸ p r o p e r t y event : OutputEvent [ 1 ] ; ✹ p r o p e r t y parameters : Parameter [ ? ] { composes } ; ✺ } ✻ c l a s s WPrimitiveObservationVarDec extends SynchronizationOutputTerm ✼ { ✽ p r o p e r t y p r i m i t i v e O b s e r v a t i o n : V a r i a b l e D e c l a r a t i o n s : : PrimitiveObservationVarDec [ 1 ] ; ✾ } ✶✵ c l a s s WPrimitiveStimulationVarDec extends SynchronizationInputTerm ✶✶ { ✶✷ p r o p e r t y p r i m i t i v e S t i m u l a t i o n : V a r i a b l e D e c l a r a t i o n s : : P r i m i t i v e S t i m u l a t i o n V a r D e c [ 1 ] ; ✶✸ }
sentada. Para uma melhor compreensão de cada uma delas é necessário conhecer o metamodelo que se encontra no apêndice A.1.
Como primeira etapa temos o pré-processamento dos modelos SATEL⊕EAPN que nos remete para o tratamento de variáveis e estruturas que necessitam de unfolding. Ao nível das variáveis é feita a alteração do nome da cada variável presente nos modelo SATEL⊕EAPN. Como necessitamos que os nomes das variáveis sejam maiúsculas (re- quisito do Prolog), visitamos todas as variáveis incrementando um índice inicializado a zero no início do processamento. O nome de cada variável será uma letra maiúscula concatenada com esse índice. As entidades que representam variáveis que são alte- radas são os ❱❛r✐❛❜❧❡❉❡❝, que são as variáveis do SATEL, e os ❱❛r✐❛❜❧❡ referentes às variáveis das APN e, mais particularmente, aos ADT que lhe estão associados).
Nesta fase preliminar é feito também o unfolding dos termos algébricos complexos para que a transformação na ferramenta DSLTrans se torne possível. Esta alteração na realidade não altera o significado do modelo de entrada.
Recordemos a notação suc10(zero)que significa aplicação sucessiva (dez vezes) da
operação suc. Em termos de sintaxe concreta do editor implementado, a notação é idêntica, e em termos de metamodelo a representação é, também, similar (listagens 4.6 e 4.5 correspondentes aos elementos❈♦♠♣♦s✐t❡❚❡r♠ das ❆❧❣❡❜r❛✐❝❊①♣r❡ss✐♦♥s e ❈❚❡r♠
4. ABORDAGEM PROPOSTA/SOLUÇÃO 4.3. Preliminares da solução
Modelos SATELEAPN
Testes abstractos com oráculos
Pré-processamento de modelos SATELEAPN
1
Refinamento de modelos SATELEAPN
2
Pós-processamento dos modelos MPrologTR
4
Transformação de MprologTR para MProlog
5
Transformação de Mprolog para Text
6
Transformação de Text para Prolog Texto
7
Geração de testes abstractos
8
Anotação dos testes com os oráculos
9
Transformação de SATELEAPN para MPrologTR
3
Trabalho previamente realizado pelo grupo Trabalho realizado no âmbito da tese Legenda:
Figura 4.1: Visão geral da solução proposta
4. ABORDAGEM PROPOSTA/SOLUÇÃO 4.3. Preliminares da solução
dos ADT das APN, respectivamente). Listagem 4.5: Metamodelo SATEL - CTerm
✶ c l a s s CTerm extends Term
✷ { ✸ a t t r i b u t e i t e r : ecore_0 : : E I n t [ ? ] ; ✹ p r o p e r t y ownedTerms : Term [ ∗ ] { composes } ; ✺ p r o p e r t y op : Operation [ 1 ] ; ✻ }
Listagem 4.6: Metamodelo SATEL - CompositeTerm ✶ c l a s s AbstractCompositeTerm extends AlgebraicTerm { a b s t r a c t } ✷ { ✸ p r o p e r t y terms : AlgebraicTerm [ ∗ ] { ! ordered,composes } ; ✹ p r o p e r t y op : adtmm : : Operation [ 1 ] { ! ordered, !unique } ; ✺ a t t r i b u t e i t e r : ecore_0 : : E I n t [ ? ] = ’ 0 ’ ; ✻ } ✼ c l a s s CompositeTerm extends AbstractCompositeTerm ; ✽ }
Se se reparar, ambos têm um atributo ✐t❡r e é sobre esse atributo que vamos fazer unfolding. Assim, como exemplo, teremos:
suc3(zero) = CT erm(op, 3, [zero]) = CT erm(op, 1, CT erm(op, 1, CT erm(op, 1, [zero])
Após ter sido feito o pré-processamento, é feito o refinamento do modelo. Este refi- namento encontra-se no apêndice A.4, e serve para facilitar a transformação principal com a ferramenta DSLtrans. Com efeito a Eclipse Modeling Framework representa lis- tas em formato XML (XMI), mas a partir da ferramenta DSLTrans não é possível obter iterativamente cada um dos elementos de uma lista pela ordem que estão colocados, deste modo é necessário carregar o modelo com alguma redundância colocando em cada objecto de uma lista, um apontador para o seguinte nessa lista.
Por esse motivo foi adicionado um apontador♥❡①t na declaração do tipo dos objec- tos pertencentes a listas, que necessitem ser processadas como lista e não como conjun- tos, estendendo o metamodelo SATEL⊕EAPN. Desta forma, manteve-se a compatibi- lidade com o AlPiNa. Este refinamento foi implementado através de ATL em refining mode, linguagem de transformação baseada em modelos apresentada em trabalho re- lacionado, que se recorre de OCL estendido e que permite construções iterativas.
A listagem 4.7 contempla um excerto da transformação referida. Como se pode ob- servar na linha 14 temos uma das várias regras presentes na transformação. Neste caso temos a regra para objectos❈♦♥❞✐t✐♦♥❇♦❞② que pode conter diversos ❈♦♥❞✐t✐♦♥❆t♦♠. Para cada um desses❈♦♥❞✐t✐♦♥❆t♦♠ é invocado um helper que devolve o elemento se- guinte na lista de❈♦♥❞✐t✐♦♥❆t♦♠ e cujo valor é afectado na propriedade ♥❡①t. Note-se ainda que a transformação é endógena e executada em modo de refinamento (ver linha 2 - ’refining’).