İsmail Ferid’e Göre İnsanlara Peygamber Gönderilişi ve Mucize

Esta subseção apresenta a construção de um metamodelo para uma linguagem de modelagem executável de Redes de Petri. O padrão de projeto apresentado na subseção 5.2.1, embora tenha sido criado com base no MOF, é aqui aplicado com o SBMM.

Redes de Petri se referem a uma linguagem de modelagem executável que, entre outras aplicações, podem descrever sistemas distribuídos discretos. Uma rede de Petri consiste em posições, transições e arcos direcionados. Arcos partem de uma posição para uma transição ou vice-versa, não ligam posições a posições ou transições a transições (BRETON; BÉZIVIN, 2001). As posições das quais algum arco parte para uma transição são denominadas posições de entrada da transição,

146 enquanto as posições para as quais arcos chegam de uma transição são chamadas de posições de saída da transição.

A semântica de execução de uma rede de Petri é descrita a seguir. Graficamente, posições em uma rede de Petri podem conter um número discreto de marcações denominadas tokens. Uma dada distribuição de tokens pelas posições da rede representa uma configuração. Uma transição de uma rede de Petri pode ser disparada se estiver habilitada, ou seja, se existirem tokens suficientes em todas as suas posições de entrada. Quando a transição é disparada, ou executada, ela consome os tokens requeridos de suas posições de entrada, e produz tokens nas posições de saída. Um disparo é uma operação atômica, isto é, um único passo que não pode ser interrompido.

O número requerido de tokens em cada posição de entrada é dado pelo peso do arco que parte para a transição. O número de tokens a serem produzidos em cada posição de saída é dado pelo peso do arco que parte da transição para a posição. A Figura 17 (a) apresenta um exemplo de rede de Petri utilizando sua notação gráfica usual (ou seja, sua sintaxe concreta). Posições são representadas por círculos, transições são representadas por retângulos preenchidos e setas representam arcos, que são rotulados por seus pesos. Tokens são representados por pontos dentro das posições. A mesma rede após o disparo da única transição está representada na Figura 17 (b).

Figura 17 – (a) Rede de Petri com uma transição habilitada; (b) A mesma rede após o disparo.

(a) (b)

147 Ao menos que uma política de execução seja definida, a execução das redes de Petri é não determinística: quando múltiplas transições estão habilitadas ao mesmo tempo, qualquer uma delas pode ser disparada.

Considerando os conceitos aqui apresentados, a Figura 18 apresenta um metamodelo para redes de Petri.

Figura 18 – Metamodelo para Redes de Petri (DDMM)

Fonte: autor

A restrição de que um arco não pode ligar duas posições ou duas transições, juntamente com outras, estão representadas mais adiante através de expressões em lógica de primeira ordem.

Deve-se observar que um modelo conforme a esse metamodelo, isto é, uma instância de rede de Petri, não é autocontido porque não carrega informações que descrevem seu estado de execução. O metamodelo apresentado na Figura 18 é a parte DDMM do metamodelo executável de acordo com o padrão descrito por Combemale, Crégut e Pantel (2012) e apresentado na subseção 5.2.1. O mesmo metamodelo é representado em SBMM pela sétupla mostrada em (69).

PetriDDMM= (“PetriDDMM”, CDDMM, DDMM, EDDMM, RDDMM,

descriptorc_DDMM, descriptore_DDMM)

(69)

Em que:

148 o c1 =c_DDMM(“Arc”, P1)  P1 = {p11, p12, p13}  p11= (“weight”, e1, 1..1)  p12= (“source”, c2, 1..1)  p13= (“destination”, c2, 1..1) o c2 =c_DDMM(“PetriNode”, ) o c3 =c_DDMM(“Place”, ) o c4 =c_DDMM(“Transition”, )  DDMM = { (c3,c2), (c4,c2) }  EDDMM = {e1} o e1 =e_DDMM(“Integer”, ℤ)  RDDMM = {r1, r2, r3, r4}

o r1: a Arc(a)  (Transition(Arc.source(a))  Place(Arc.destination(a)))

o r2: a Arc(a)  (Place(Arc.source(a))  Transition(Arc.destination(a)))

o r3: x PetriNode*(x)

o r4: a Arc(a)  Arc.weight(a) > 0

A restrição r1 estabelece que, para todos os elementos de modelo que forem

instâncias de Arc, se source for uma transição então destination deve ser uma posição. A restrição r2 estabelece a mesma regra para a situação oposta. O fato de

PetriNode ser uma metaclasse abstrata é representado por r3. Isso significa que uma

instância direta de PetriNode não pode existir em um modelo conforme ao metamodelo. A restrição r4 garante que os pesos dos arcos são números positivos.

Para adicionar informação relacionada a estado de execução nesse metamodelo, pode-se incluir a propriedade numberOfTokens na metaclasse Place, como mostrado na Figura 19, que corresponde à parte SDMM.

149

Figura 19 – Metaclasse Place com a propriedade de estado numberOfTokens (SDMM)

Fonte: autor

O metamodelo da Figura 19 é composto por uma única metaclasse e, em SBMM, é denotada por (70).

PetriSDMM= (“PetriSDMM”, CSDMM, SDMM, ESDMM, RSDMM,

descriptorc_SDMM, descriptore_SDMM)

(70) Em que:  CSDMM = {c5} o c5 =c_SDMM(“Place”, P5)  P5 = {p51}  p51= (“numberOfTokens”, e2, 1..1)  SDMM =   ESDMM = {e2} o e2 =e_SDMM(“Integer”, ℤ)  RSDMM = {r5} o r5: p Place(p)  Place.numberOfTokens(p) ≥ 0

Para adicionar informações de evento, ou seja, a parte EDMM, cria-se a metaclasse Firing, que representa um evento de disparo. Ela é associada a uma transição e contém um carimbo de tempo (timestamp), modelado aqui como um número inteiro

150 representando o instante em que o evento ocorreu. Na verdade, Combemale, Crégut e Pantel (2012) propõem que uma metaclasse de evento deve ser filha de uma metaclasse mais geral chamada RuntimeEvent do pacote TM3. Entretanto, para os nossos propósitos aqui, apenas criar a metaclasse Firing sem herança já é suficiente. A Figura 20 mostra o conteúdo da parte EDMM.

Figura 20 – Metaclasse Firing (EDMM)

Fonte: autor

O metamodelo da Figura 27 é denotado em SBMM por (71).

PetriEDMM= (“PetriEDMM”, CEDMM, EDMM, EEDMM, REDMM,

descriptorc_EDMM, descriptore_EDMM)

(71) Em que:  CEDMM = {c6, c7} o c6 =c_EDMM(“Firing”, P6)  P6 = {p61, p62}  p61= (“timeStamp”, e3, 1..1)  p62= (“transition”, c7, 1..1) o c7 =c_EDMM(“Transition”, )  EDMM =   EEDMM = {e3} o e3 =e_EDMM(“Integer”, ℤ)

151  REDMM = 

O metamodelo executável autocontido é então construído pela mesclagem de DDMM com SDMM e EDMM, operação representada pela Figura 21 em notação MOF.

Figura 21 – Construção do metamodelo executável autocontido

Fonte: Combemale, Crégut e Pantel (2012) (adaptado)

Como visto na subseção 4.10.2, o SBMM provê a função de mesclagem de metamodelos @MM. Sendo assim, o metamodelo executável autocontido é expresso

em SBMM por (72).

PetriMM = @MM(“PetriMM”,@MM(“TempPetriMM”,PetriDDMM,PetriSDMM),PetriEDMM) (72)

Essa operação resulta no metamodelo autocontido final apresentado na Figura 22 (notação gráfica) e na eq. (73) (notação de conjuntos). Observe que as metaclasses e enumerações com o mesmo nome não são duplicadas no metamodelo resultante. Elas são mescladas conforme definido pela função @MM.

152

Figura 22 – Metamodelo autocontido para uma x-DSML de Redes de Petri

Fonte: autor

PetriMM= (“PetriMetamodel”, CMM, MM, EMM, RMM,

descriptorc_MM, descriptore_MM)

(73) Em que:  CMM = {c1, c2, c3, c4, c6} o c1 =c_MM(“Arc”, P1)  P1 = {p11, p12, p13}  p11= (“weight”, e1, 1..1)  p12= (“source”, c2, 1..1)  p13= (“destination”, c2, 1..1) o c2 =c_MM(“PetriNode”, ) o c3 =c_MM(“Place”, P3)  P3 = {p31}  p31= (“numberOfTokens”, e1, 1..1) o c4 =c_MM(“Transition”, ) o c6 =c_MM(“Firing”, P6)  P6 = {p61, p62}  p61= (“timeStamp”, e1, 1..1)

153  p62= (“transition”, c4, 1..1)  MM = { (c3,c2), (c4,c2) }  EMM = {e1} o e1 =e_MM(“Integer”, ℤ)  RMM = {r1, r2, r3, r4, r5}

o r1: a Arc(a)  (Transition(Arc.source(a))  Place(Arc.destination(a)))

o r2: a Arc(a)  (Place(Arc.source(a))  Transition(Arc.destination(a)))

o r3: x PetriNode*(x)

o r4: a Arc(a)  Arc.weight(a) > 0

o r5: p Place(p)  Place.numberOfTokens(p) ≥ 0

O objeto p31 era originalmente p51. Uma vez que as metaclasses c3 e c5 foram

mescladas, c3 ficou no metamodelo resultante e incorporou esta propriedade de c5

(conforme definições da função @MM). Sendo assim, as referências P5 e p51 foram

renomeadas para P3 e p31, respectivamente, para manter a convenção de

indexação.