İsmail Ferid’e Göre Âlemin Varoluşu ve Tanrı

Um modelo executável é um tipo de modelo que pode ser executado. Algumas DSMLs permitem a criação de modelos executáveis e, por isso, são conhecidas como Executable DSMLs (x-DSML). A execução de modelos pode ser alcançada não apenas por transformações modelo-para-código, mas também por interpretação direta de modelos. Modelos escritos em uma Interpreted DSML (i-DSML) podem ser interpretados de acordo com uma semântica por um motor de execução (CARIOU et al., 2013). Com essa abordagem, nenhuma transformação precisa ocorrer e o modelo é diretamente executado. A executabilidade de modelos se tornou um tópico chave de pesquisa na MDE (COMBEMALE; CRÉGUT; PANTEL, 2012).

Esta seção apresenta uma caracterização precisa de modelos executáveis, e também de semânticas de execução, utilizando o SBMM como formalismo subjacente.

O termo “metamodelo executável” é apenas um atalho para expressar que modelos conformes a ele são executáveis (CARIOU et al., 2011). O metamodelo em si não é um artefato executável.

Modelos executáveis são discutidos em vários trabalhos, sendo que o seguinte consenso é identificado por Cariou et al. (2013):

142  Alguns tipos de modelo são executáveis, outros não;

 Um motor (engine) é responsável por executar o modelo;

 Se o modelo apresenta em si todas as informações necessárias para sua execução por um motor, então é dito ser autocontido.

Um modelo autocontido apresenta slots de propriedades que explicitamente definem o estado de execução do modelo (p. ex., o estado de uma máquina de estados pode ter uma propriedade Booleana isCurrent para determinar qual é o estado corrente em um dado passo de execução).

Assim como observado para o termo “metamodelo executável”, o termo “metamodelo autocontido” também é um atalho para expressar que, na verdade, os modelos conformes ao metamodelo são autocontidos.

Existe uma classificação geral que pode ajudar a identificar modelos executáveis: a classificação produto ou processo. Segundo ela, modelos podem expressar produtos ou processos, independentemente do tipo de sistema sob consideração. A ideia central é que modelos de processo possibilitam a executabilidade de seu conteúdo porque contêm conceitos diretamente relacionados à execução: ponto de início, ponto de término, passo de evolução, etc. (CARIOU et al., 2013). Por outro lado, modelos de produto são mais estruturais, tais como diagramas de classes UML, e esses não expressam diretamente aspectos de comportamento e interação.

Essa classificação pode não ser muito precisa para determinar modelos executáveis. Observa-se um exemplo de modelo que descreve uma interface de usuário do tipo Create/Retrieve/Update/Delete (CRUD) para objetos persistentes em aplicativos de negócio (CANOVAS; CUGNASCA, 2015b). O metamodelo correspondente define uma DSML que prevê apenas elementos estruturais da interface de usuário, podendo seus modelos ser classificados como modelos de produto. Entretanto, não se pode afirmar que esses modelos não são executáveis. Um motor, que implementa a semântica de execução, pode ser capaz de renderizar a interface e processar todas as interações com o usuário, tais como o clique em um botão para criar um objeto. Em todo o caso, essa classificação ainda provê alguma evidência sobre a executabilidade de um dado tipo de modelo.

143 Para dar continuidade à conceituação de modelos executáveis utilizando o SBMM como formalismo subjacente, consideram-se apenas os modelos executáveis de processo. Sendo assim, deve-se pressupor que um modelo de produto executável pode ser mapeado em um modelo de processo equivalente. Sempre pode ser criado um modelo de processo de mais baixo nível de abstração (em outra linguagem de modelagem) que incorpore explicitamente conceitos implícitos no modelo de mais alto nível. Mesmo que esse mapeamento não seja necessariamente de interesse da MDE, pois essa abordagem clama pelo aumento do nível de abstração, é de interesse para a conceituação proposta nesta seção. Esse princípio pode ser argumentado pela analogia com programas de computador: um programa escrito em alguma linguagem de alto nível, que torna implícitos detalhes computacionais de execução, sempre pode ser reescrito ou compilado em um código equivalente em uma linguagem de mais baixo nível, no qual detalhes computacionais de execução são mais evidentes (CANOVAS; CUGNASCA, 2016).

Cariou et al. (2011) apresentam uma visão de execução de modelos como transformações de modelos. É assumido que os modelos executáveis sob consideração são autocontidos. Um passo de execução é descrito como uma evolução de um modelo de origem (o modelo em seu estado de origem) para um modelo alvo (o modelo em seu próximo estado de execução). Tanto o modelo de origem como o modelo alvo são do mesmo tipo. O trabalho usa OCL para descrever a semântica de execução de máquinas de estado UML. Markovic e Baar (2008) usam QVT para expressar regras de reescrita que gradualmente computam os valores de expressões OCL.

Essas abordagens permitem uma definição mais precisa de modelos executáveis e mostram como um modelo gradualmente evolui durante sua execução. Entretanto, elas são baseadas em linguagens ou implementações computacionais, e seus fundamentos subjacentes não são tão explorados.

Combemale et al. (2012) propõem a modelagem do domínio semântico de uma x- DSML em duas partes: ações específicas de domínio e modelo de computação, ou Model of Computation (MoC). A primeira se refere a conceitos de execução específicos do domínio da DSML e suas semânticas, enquanto a segunda é responsável por agendar e orquestrar as ações em um modelo executável. O artigo apresenta experimentações desta proposta utilizando o Kermeta Workbench

144 (MULLER; FLEUREY; JÉZÉQUEL, 2005), ferramenta especializada em metamodelagem, e o ambiente ModHel’X (BOULANGER; HARDEBOLLE, 2008), que suporta a definição de MoCs. O artigo apresenta uma proposta sobre como combinar artefatos produzidos por essas duas ferramentas para obter a definição do domínio semântico de uma x-DSML. Dois benefícios dessa abordagem são a possibilidade de reusar o mesmo MoC com diferentes x-DSMLs e reusar ações específicas de domínio com diferentes MoCs para implementar pontos de variação semânticos na x-DSML. Embora traga contribuições, o trabalho foca em aspectos práticos e nem tanto em aspectos teóricos de modelos executáveis.

A semântica de execução de uma x-DSML usualmente está embutida de forma hard coded nas funções de execução ou de mapeamento presentes nas ferramentas de desenvolvimento de sistemas baseadas em modelos. Para tornar esta definição explícita, Combemale, Crégut e Pantel (2012) propõem um padrão de projeto para x- DSMLs. De acordo com esse padrão, metaelementos estruturais são separados de metaelementos de estados e eventos em diferentes pacotes (packages) MOF. Por ser um padrão relacionado à metamodelagem, também é conhecido como padrão de metamodelagem.

Metaelementos estruturais estão relacionados aos conceitos chave da linguagem e seus relacionamentos. O padrão estabelece que eles devem ser parte de um pacote denominado Domain Definition MetaModel (DDMM). Já a definição da informação que deve ser gerenciada em tempo de execução, isto é, aquela que torna o modelo autocontido (tal como a noção de estado corrente em uma máquina de estados), compõe o pacote State Definition MetaModel (SDMM). Tais dados são explicitamente definidos no metamodelo e devem ser manipulados e registrados no modelo na forma de instâncias de metaclasses e valores de propriedades em slots, ao invés de ficarem ocultos e implícitos na ferramenta de execução de modelos. O pacote Event Definition MetaModel (EDMM), por sua vez, especifica eventos concretos que direcionam a execução dos modelos conformes ao metamodelo da x- DSML. Ainda de acordo com o padrão, o MoC deve ser especificado no pacote Trace Management MetaModel (TM3), sendo que este é reusado por todas as x- DSMLs baseadas no mesmo MoC. Por fim, tanto o mapeamento semântico quanto as interações com o ambiente são abstraídos pelo pacote Semantics. Ele descreve como o modelo em execução (cujo estado de execução é especificado pelo SDMM)

145 evolui de acordo com os estímulos especificados pelo EDMM através de eventos. O pacote Semantics pode ser especificado por uma função de transição através de uma linguagem de ação (semântica operacional) ou implicitamente definido pelo mapeamento em outra linguagem (semântica translacional).

Sendo assim, de acordo com esse padrão, um metamodelo que define uma x-DSML é composto por cinco pacotes: DDMM, SDMM, EDMM, TM3 e Semantics. Este artigo provê alguns insights para formalmente descrever modelos executáveis, apesar de não o fazer por não ser seu foco.

Considerando i-DSMLs, o foco deve ser colocado sobre a semântica operacional, pois uma semântica translacional requer a tradução para outra linguagem, por definição, e neste caso o modelo não é diretamente interpretado.

As próximas subseções apresentam um exemplo de metamodelo que define uma x- DSML para redes de Petri, e também o exemplo de um modelo específico que é instância desse metamodelo. Em seguida, propõe-se uma caracterização formal para semânticas de execução utilizando o SBMM como formalismo subjacente. Motores de execução também são caracterizados. Por fim, são apresentadas quinze definições sobre metamodelos e modelos executáveis, incluindo o conceito de modelos executáveis adaptativos, ainda utilizando o SBMM como base.