Archives for posts with tag: interpreter

Atom3logo

AToM3 is a language workbench developed at the Modelling, Simulation and Design Lab (MSDL) in the School of Computer Science of McGill University. Please note that the reviewed version is not the latest (0.3).

The focus of the review is the language workbench capabilities, that is everything related to specification of modeling languages and automated processing of models.

Freeform Multilingual Modeling

In AToM3, models (and metamodels) are visually described as graphs. There is no support for spatial relationships, such as containment or touch. While position of modeling elements may seem to imply spatial relationships among them (e.g. among a software component and a port), AToM3 does not recognize, maintain or process such relationships.

Modeling is performed by means of a visual editor: one selects a modeling concept from one of possibly multiple language toolbars (to the left of the canvas) and places (instantiates) it on the canvas. Any language toolbar can be easily removed or added by closing or opening its language-specification file. Furthermore, the toolbar itself is defined by a model in a so-called “Buttons” DSL (see Figure 1). At any time, the modeler is free to edit this model to e.g. arrange buttons in one or multiple rows, remove language concepts or specify additional buttons to launch transformations frequently used with the given language. Both language specification and toolbar files are generated by AToM3 from the language model (aka metamodel). Language independent tools like Edit, Connect, Delete form the general modeling toolbar (above the canvas).

Figure_1

Figure 1: A “Buttons” model for a DSL

A special feature of AToM3 is a freeform multi-language canvas. AToM3 breaks with the tradition of “strongly typed” diagrams that prevent intermixing modeling elements if not explicitly allowed by the diagram’s metamodel type. AToM3 canvas can be considered a diagram that allows any modeling elements. However, elements can only be connected if their metamodel allows this. Such canvas provides users with a high degree of modeling freedom. (As illustration of this freedom, AToM3 logo itself is a freeform model done using 5-6 DSLs). Furthermore, because models are not fragmented among islands of diagrams, information access is optimal. Another benefit is less effort on the metadeveloper’s part because a freeform model can be handled by a transformation without the prior need of metamodel integration.

Unfortunately as models grow in size and number, the single canvas does not scale well, nor does AToM3 provide the user with means to manage them.

AToM3 uses this editor and the freeform canvas in a few different contexts. The primary role is a modeling editor, however the same editor is used for metamodeling and specifying transformation definitions. Such reuse reduces the learning curve and more importantly, brings the benefits of a domain specific modeling environment and the freeform canvas to metadevelopers as well.

Language Specification

AToM3’s metalanguage is based on the Entity Relationship (ER) formalism. In order to provide complete metamodeling capabilities, concepts Entity and Relationship are extended with constraints and appearance properties (see Figure 2). Property constraints is used to define static semantics. Appearance defines visual presentation or concrete syntax of a language concept.

Figure_2Figure_3

Figure 2: Features of Entity or Relationship. Appearance editor

AToM3 provides overall excellent metamodeling capabilities that enable metadevelopers produce level 5 quality metamodels. The following details these capabilities.

Abstract Syntax

For this task metadevelopers are equipped with the ER-based metalanguage, which is very close to conceptual modeling techniques, such as ORM. This means that there is a minimum gap between conceptual, business world-oriented models and AToM3 metamodels. In fact, AToM3 abstract syntax models are surprisingly simple and void of technical details typical for metamodels, which makes the models very readable by subject experts. Figures 2 and 4 of the Curriculum Content Sequencing (CCS) demo illustrate this point.

Concrete Syntax

A simple but sufficient editor allows to define a vector presentation for a language concept. Figure 2 shows all that the editor has to offer.

Static Semantics

The constraints property contains rules that control how a modeling element can be connected to another element to form a meaningful composition. Such rules can be defined per language concept or a model and triggered by editor events (e.g. edit, save, transformation start) or on demand by user, thus covering all imaginable ways to invoke model checking.

AToM3 constraint language is Python, which is an unusual choice. Indeed, Python is not a constraint language, not formal (in the model-driven sense), and has side effects (AToM3 is written in Python too). However, my experience with AToM3 showed that none of those are real disadvantages in practice: Python is known for a concise and easy to read syntax and as constraint language, is intended for metadevelopers (who know how to deal with side-effects). In this role, Python proved to be powerful, flexible and efficient.

Dynamic Semantics

AToM3 uses a common approach to define DSL semantics by translating language concepts to concepts in another target domain with predefined dynamic semantics (e.g, C++, Java). This approach is known as translational.

Another less common approach supported by AToM3, is by modeling the operational behavior of language concepts [1]. The operational semantics approach specifies how models can be directly executed, typically by an interpreter. Such specifications are expressed in terms of operations on the language itself, which is in contrast to translating the language into another form. The advantage is that operational semantics are easier to understand and write. The disadvantage is that interpreters are normally not available for DSLs due to the very specific nature of the latter. (For an AToM3 illustration of how to build a custom interpreter in a model-driven way, please refer to this article.)

In AToM3 translational and operational approaches are implemented as transformations.

Transformation

AToM3 employes the graph rewriting approach to transform models. Transformations themselves are declaratively expressed as graph-grammar models. My experience with transformation models written in imperative languages (e.g. QVT Operational, MERL) is that more time is spent figuring out how to navigate host model structure to access right information than actually specifying what to do with this information. Declarative approach like that of AToM3, frees the metadeveloper from having to specify navigation, thus drastically reducing complexity of transformation modeling.

Figure_4_1Figure_4_2Figure_4_3Figure_4_4

Figure 3: A GG transformation model, a rule, an LHS and an element’s properties

To define a transformation in AToM3, one needs to create a graph grammar and specify one of more GG rules. Figure 3 shows a GG model for the export transformation in the CCS demo. Each rule specifies how a (sub)graph of a so-called host graph can be replaced by another (sub)graph. These (sub)graphs are respectively called the left-hand side (LHS) and the right-hand side (RHS). A rule is assigned an order (priority), a condition and an action. In AToM3, conditions and actions are programmed in Python. As in the case with the constraint language, Python performs very well in these roles too.

A special feature of AToM3 is that both LHS and RHS can be modeled with the DSL(s) of the host graph. In fact, the (sub)graph editor is based on the above mentioned model editor, and provides the metadeveloper with the freeform multilingual canvas, customizable language toolbars and transformations. The consequence is that it is very easy to construct sub-graphs and verify them with subject experts.

Figure_5

Figure 4: A host model together with a “parameter” model

An interesting feature of AToM3 transformation system is that it does not feature transformation parameters. This may seem limiting, however an equally effective alternative is to store “parameter” information in a model. The AToM3 canvas makes it extremely easy to mix such “parameter” model(s) with a host model and pass them to a transformation. Figure 4 shows a sequencing model from the CCS demo together with a repository model (top left corner of the canvas). Given both, an export transformation can access the remote model repository, pass authentication, and store the sequencing model at the repository.

Another interesting feature is that transformation input can be also an element selected by users (unfortunately multiple selection does not work in this version). A promising application thereof is user-defined in-place transformations that automate frequent and routine modeling operations. For example, decomposing a group element into constituent objects (and vice-versa) with a click of a button. Industrial users that often work with large models would really appreciate the resulting reduction of repetitive strain.

Finally, AToM3 supports nearly all transformation kinds known to the author [2, 3]. It is easier to list what is unsupported: text-to-model and text-to-text (which is a consequence of the graphical nature of the language workbench), and the more exotic synchronization and bidirectional kinds. Due to its graph rewriting system, AToM3 is very strong in model-to-model (M2M) and model-to-text (M2T) transformations. A GG-based support for the latter, very popular category, is not obvious and therefore warrants an extra explanation.

M2T Transformation

In AToM3 M2T means producing textual structures from graph structures. One way of doing this is via a transformation where the source and the target models are the same. Rules of such transformation do not perform any important rewriting, but use the graphical nature of the source language to traverse and annotate the source model with temporary information that is needed for text generation. Text itself is generated by side-effects encoded in actions of rules, which can access the annotations.

A typical M2T application is code generation. An example of a non trivial code generation made with AToM3 is ZCase, a software factory for Zope. In the CCS demo, ZCase is a part of the ERZope transformation chain.

Conclusion

The is no escaping the fact that AToM3 is a research tool and is not suitable for demanding industrial use. The workbench does not scale well for large models (both in terms of performance and user controls) and its tools are basic. There is no reliable support, no up-to-date exhaustive documentation, no collaborative development, no integration with version control and requirement management systems, and naturally plenty of bugs and annoyances. In short, the tool is far from being mature and ready for industrial users.

However, metadevelopers may find the above drawbacks quite tolerable, because they are better prepared to deal with technical issues and metamodels typically do not stress the tool’s scalability. On the positive side, AToM3 provides simple but optimal tools and set of features that work together to create one of the most robust and powerful language workbenches I know. Thereby AToM3 is extremely suitable for agile, responsive and timely development. Due to the maturity level of the workbench, its application is best limited to proofs of concept. To date, AToM3 is the language workbench of my choice for quick prototyping.

AToM3 is recommended to MDE students, analysts in need of quick prototyping and tool vendors seeking to improve their language workbenches. In my opinion, AToM3’s metamodeling and transformation technology is nearly optimal, and is still ahead of the larger and more inert commercial workbenches. While its problems are numerous, they are run-of-the-mill and knowledge and technologies to address them are commonly available. If these problems could have been removed, then AToM3 would have been the tool I could have easily recommended to industrial customers too.

References

[1] Tony Clark, Andy Evans, Paul Sammut, and James Willans. Applied Metamodelling: A foundation for Language Driven Development. Version 0.1. Xactium Ltd., 2004.

[2] Krzysztof Czarnecki and Simon Helsen. Classification of model transformation ap- proaches. In Jorn Bettin, Ghica van Emde Boas, Aditya Agrawal, Ed Willink, and Jean Bezivin, editors, 2nd OOPSLA Workshop on Generative Techniques in the Context of Model-Driven Architecture, Anaheim, CA, October 2003. ACM Press.

[3] Tom Mens, Krzysztof Czarnecki, and Pieter Van Gorp. Discussion – a taxonomy of model transformations. In Jean Bezivin and Reiko Heckel, editors, Language Engineering for Model-Driven Software Development, volume 04101 of Dagstuhl Seminar Proceedings, Dagstuhl, Germany, 2005. Internationales Begegnungs- und Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl, Germany.

Blogs by Johan den Haan, Stefano Butti and Jordi Cabot raised interesting discussions about code generation (CG) and model interpretation (MI). One observation I took from these discussions is that MI is still little known. Previously I demonstrated operation of a custom-made model interpreter for a so-called weighbridge domain. Today I would like to share my experience of building this interpreter in a model-driven way.

MDE Approach

Two main choices underpin the process and technology used to develop the interpreter:

  1. Execution semantics of the interpreter is defined within the problem domain itself (weighbridge in this case), without translating it to another domain (e.g. .Net or Java) as it is the case with CG. Such definition of semantics is also known as operational semantics. The advantage is reduction of development complexity: out of at least 2 domains needed for CG, only one and the more abstract domain is sufficient.
  2. Operational semantics is defined within an MDE framework. This enables customization of modeling language for problem domains besides that of the weighbridge example. Moreover, transformation capabilities are used to define operational semantics. 

Domain-specific_nested_interpretation_mde_framework

Figure 1: Domain-specific, nested interpretation (DSNI) MDE framework

Figure 1 shows the MDA framework [1] after it has been adapted to reflect the above mentioned choices. (If you are confused between MDA and MDE, you might find this article useful.) In contrast to MDA, there is no PIM or PSM model, but single computational independent model (CIM) written in DSL. CIM is both source and target of Transformation Tool. Transformation Tool carries out transformation classified as same language, same model. Transformation Definition defines operational semantics. It is not important if Transformation Definition Language (TDL), extends the Metalanguage as in MDA or is customizable by means of meta-specification. Therefore TDL is omitted from the framework and TDL selection criteria are defined instead (see below). Finally, new concept System Context is connected to Transformation Tool. This is due to the fact that interpretation as system exhibits external behavior through communication with other systems.

This approach can be described as nested interpretation, where a domain-specific interpreter is executed (nested) by a generic interpreter. From this perspective, Transformation Tool assumes the role of a generic interpreter and execution of Transformation Definition fills in the role of the domain-specific interpreter.

TDL Selection Criteria

Selection criteria for transformation definition language are:

  • declarative modeling 
  • support for domain-specific notation

These criteria help to reduce development complexity and improve communication with problem domain experts.

Selected MD Technology

AToM3 is a free language workbench written in Python and under development at the Modelling, Simulation and Design Lab (MSDL) in the School of Computer Science of McGill University. The workbench closely matches the DSNI framework and meets the TDL selection criteria. 

In AToM3, DSLs and models are described as graphs. From a language specification written in the metalanguage (ER formalism), AToM3 generates a tool to visually manipulate (create and edit) models written in the specified DSL. Model transformations are performed by graph rewriting. The transformations themselves can thus be declaratively expressed as graph-grammar models. However, AToM3 provides no communication infrastructure as needed by the framework.

Proof of Concept

As demonstration, a language specification for the weighbridge domain was defined (see sections domain and weighbridge DSL here) and graph rewriting was used to model operational semantics (see below). Source code of AToM3 itself, being written in Python, was extended to support web services for the communication purpose.

Operational Semantics

As blueprint for operational semantics of the interpreter, we took πDemos [2], a small process-oriented discrete event simulation language. There is a number of πDemos events that change state of a weighbridge system. For each such event, [2] defined the transitions induced on system state. While the original used functional programming language, this work uses graph rewriting and a graph grammar (GG) rule is defined per event.

Priority GG Rule Description
50 importProcess Adds an external vehicle to EL
25 removeProcess Deletes a vehicle that has completed its todos (events)
40 newR Creates a new weighbridge
40 decP Creates a new vehicle class
40 newP Creates a vehicle from a vehicle class
40 getR Acquires a non-busy weighbridge
40 blockProcess Blocks a vehicle acquiring a busy weighbridge
40 promoteProcess Unblocks a delayed vehicle
40 useR Moves a vehicle on a weighbridge until service is complete
30 releaseResource Moves a served vehicle from a weighbridge to EL
41 putR Releases an occupied weighbridge

Table 1: Graph grammar rules of weighbridge events

Table 1 lists the minimum set of required events and their corresponding GG rules. Execution of such rules needs to be globally orchestrated through proper sequencing. The rules, together with execution sequencing, form an operational semantics model of the interpreter. 

For complete description of the model, please refer to [3]. In the following, we present a detailed description of an example rule, followed by the execution sequencing model.

Example GG Rule

LhsRhs

Figure 2: Subgraphs of the promoteProcess rule

Rule promoteProcess releases a busy weighbridge (bluish box in Figure 2.1) that delays at least one vehicle (yellow box labelled 5). In the new state, the weighbridge remains busy and the blocked vehicle (5) is removed from the head of queue Delay and inserted in waiting queue EL.

The rule is executed if:

  1. The left-hand side (LHS) shown in Figure 2.1 is matched in the host graph (the CIM model).
  2. Associated condition is true: the weighbridge in LHS is the one referred to in the imminent event putR (a todo) in the body (a todo list) of the first vehicle (label 21) in queue EL.

If the above holds, the matched part of the CIM model is substituted with the right-hand side (RHS) shown in Figure 2.2. Note new objects are labelled 10, 11, 13. The entities and relationships in RHS are initialized as follows:

  1. Objects copied from LHS keep all their properties. 
  2. Imminent event putR (a todo)  of the current vehicle (21) is completed. 
  3. All properties of blocked vehicle (5) are copied to vehicle (10).

Execution Sequencing

The execution sequencing is based on the next-event approach: Next event to execute is always the imminent event in the body of the current vehicle. Informally, the operational semantics of execution sequencing is as follows: if EL is empty, interpreter idles until at least one vehicle is inserted in EL. Such vehicle becomes current. If the body of the current vehicle is empty then it is removed from EL and EL is examined again. Otherwise, interpreter  executes a GG rule corresponding to the imminent event of the current and EL is examined again. Note that whenever interpreter is idle, EL is being updated with new vehicles that meanwhile might have arrived from system context.

The execution sequencing is implemented by organizing GG rules into groups, each group having its own base priority. These groups, in the descending order of priority are: vehicle removal, weighing activities and vehicle arrival. Within a group, each rule is assigned a relative priority. If pattern matching of two and more rules within a group is deterministic on the basis of LHSs and conditions, then these rules can share the same priority level. Example rule priorities are given in Table 1.

Conclusion

The demonstrated development approach is characterized by a very high level of abstraction, direct involvement of problem domain experts and absence of software development. All these factors contribute to fast development times: The lead time of this one man project including research and development was 3 weeks. Admittedly, tests of the produced model interpreter showed noticeable performance penalty due to 1) repurposing of MD technology that was not designed for use as interpreter and 2) the overhead introduced by nested interpretation. In my opinion there is much room for performance improvement and I am wondering if MDE can prove useful again. An important message from this experience is that model interpretation does not have to be prerogative of big commercial tools and can get closer to code generation in terms of accessibility.

References

[1] Anneke G. Kleppe, Jos Warmer and Wim Bast. “MDA Explained: The Model Driven Architecture: Practice and Promise”. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, April 2003.

[2] Graham Birtwistle and Chris Tofts. “An operational semantics of process-oriented simulation languages: Part 1 πDemos”. ACM Transactions on Modeling and Com- puter Simulation, 10(4):299–333, December 1994.

[3] Andriy Levytskyy. “Model Driven Construction and Customization of Modeling & Simulation Web Applications”. PhD thesis, Delft University of Technology, Delft, The Netherlands, January 2009.

Model interpretation approach is grasping attention of the model driven community. Industrial experiences of company Mendix has shown some very promising results. A recent post at a popular “model-minded” blog triggered a discussion about code generation versus model interpretation. Model interpretation in itself is not a new concept and there exist well known interpreters for generic and mainstream domains (e.g., Ptolemy and Simulink). The novelty in model interpretation today is that model driven methods provide efficiency and flexibility, which enable application of this concept to arbitrary problem domains. In a series of blogs we will illustrate this novel aspect and provide an example of model interpretation. Specifically this article will illustrate 1) how a custom modeling language (DSL) is developed for an arbitrary problem domain and 2) how a system behavior can be specified with the DSL and directly interpreted without any intermediate transformation steps. In a followup article we will show how a custom model interpreter can be efficiently built using a model driven method.

Model Interpretation As System

Traditional generative approaches like Model Driven Architecture (MDA) prescribe an (automated) code generation process that takes a system model as input and eventually produces code that implements the specified system. The system comes to existence when the code is executed. Alternatively, the code generation process can be skipped and a system model be executed directly.  Model Interpretation achieves such direct execution by means of a model interpreter. In this case the system comes to existence when the model is being interpreted. Thereby system behavior is completely defined by the model being interpreted. Fig. 1 illustrates a possible approach to model interpretation of event-driven systems.  An event-driven system exhibits behavior by generating (external) events in reaction to incoming external events. Therefore, the interpreter should support two-way event communication with the context. An example of an incoming external event is arrival of a positive signal from a motion sensor for an automated door. An outgoing external event could be a command to an actuator to open the door.

Media_httplsdluminisn_fhrvg

Figure 1: An approach to system as model interpretation In the figure, entities are shown as boxes and their roles w.r.t.  each other are shown in italic. Given that a domain-specific language (DSL) and an interpreter already exist, a domain expert uses the DSL to specify a system and its events at development time. Moving to the run-time, the same model (system configuration) represents the system and its events. During model execution, the interpreter reads system state from the model and interprets system events according to the semantics of the events. Interpretation may change the state of the system by changing the system configuration at run time, and communicate external events to the system’s context. Typically a sequence of external events is provided by the context of the system. Alternatively, these events can be specified in the system model and consequently generated by the interpreter itself (in this case, system behavior is simulated).

Domain

Today model interpretation can be applied to an arbitrary problem domain. To reflect this freedom, we chose a minor and uncommon weighbridge domain, whose purpose is to measure weight of vehicles. The following is a typical weighbridge scenario: One or more delivery vans arriving (at a factory) must pass over a weighbridge on entry. A weighbridge accepts one van at a time and each weighing operation takes a certain amount of time. If the weighbridge is busy, arriving vans join the waiting queue to the bridge. When the weighbridge becomes available again, the first van in the waiting queue drives over the bridge. This domain is characterized by a number of inherent variations, such as number of weighbridges, weighbridge capacity, weighing operation duration, number of arriving vans, arrival times of vans, etc.. The result is that a multitude of weighbridge system configurations are possible and per configuration a multitude of dynamic van arrival and weighing scenarios can play out.

Media_httplsdluminisn_foxbw

Figure 2: A weighbridge system modeled in a DSL Figure 2 shows a simplified weighbridge system configuration, originally described by Birtwistle and Tofts [1]. Yellow boxes are vans. The large blue box is a weighbridge and green entities are a van arrival queue (EL) at the factory and a van waiting queue (Delay) at a weighbridge. As you can see the factory’s configuration has a single weighbridge W, which is free at this time. Finally, three delivery vans V1, V2 and Main have arrived (external events). An execution of this model is illustrated further in the article. An AToM3 implementation of a DSL for the domain is briefly described next.

Weighbridge DSL

The earlier mentioned freedom of application depends on flexibility and efficient adaptation of model interpreters to new domains. Model driven methods achieve this flexibility through metamodeling. If you are not familiar with metamodeling, you can skip this section as it is not required for understanding the demo. A DSL is defined with abstract syntax, concrete syntax, static semantics and dynamic semantics. (Such a definition is known as metamodel.) Behind every DSL is a modeling paradigm that gives fundamental guidelines for metamodeling. In case of the weighbridge domain, a proper modeling paradigm is Process Interaction [2].

Media_httplsdluminisn_harrk

Figure 3: PI Metamodel For the purposes of this demo, a PI modeling language will suffice  and we will reuse and extend a PI metamodel developed by Juan de Lara [3]. We just have to keep in mind that Process and Resource in Juan’s metamodel correspond to van and weighbridge concepts in the demo domain. The abstract syntax of the PI DSL is illustrated in Figure 3. The concrete syntax of this DSL is illustrated in Figure 2. We skip static semantics (in other words, business rules) as the focus of the domain is interpretation, not domain modeling. The following is a brief description of the key PI concepts: Resource is a synonym for the Weighbridge concept. A weighbridge has the following attributes: Name is a unique identifier of Weighbridge: String State denotes availability of Weighbridge: Enum{idle, busy} Tproc is typical duration of weighing service: Time (used in simulated execution) Capacity denotes capability to weigh multiple vans at the same time: [1..N] Load denotes weighbridge’s capacity occupied with served vans: [0..Capacity] Process is a synonym of the Van concept. A van has the following attributes: Name is a unique identifier of Van: String Tcreation is time-stamp of Van’s arrival event: Time Tinitproc is the start time of weighing operation: Time Tendproc is the end time of weighing operation: Time Body is a sequence of tasks: sequence{task} (tasks examples are bridge access, van weighing, bridge exit, etc.) EVnext is the iterator for tasks in body: [0..N] For simulation purposes, additional concepts are defined: Time is a clock for simulated time. ProcIntGenerator specifies time intervals between van arrivals. Finally, to assist visualization of system state, the original metamodel was extended with additional relationship: manageElement specifies an operation (append, insert or remove) on an element (target end of this relationship) of a sequence (source end of this relationship). The final touch of DSL definition is dynamic semantics (meaning of DSL concepts). In the model interpretation approach, such semantics is defined in an interpreter. In case of a DSL and a pure interpretive approach there is a good chance that an interpreter exactly matching the DSL will need to be developed. More so if the interpreter has to meet additional specific requirements. In our case, such requirements were run-time visualization of system behavior and interpreter integration with the factory context (not covered in this article). In a followup article we will show how a custom model interpreter can be developed. Incidentally our development approach is also based on model interpretation.

Run Time Example

A picture is worth a thousand words. With that in mind an illustration of model interpretation is best done with a video. The following screencast shows execution of the weighbridge system configuration introduced earlier (see Figure 2). For the sake of visualization, execution is carried out in the step-by-step mode and displays how the state of the weighbridge configuration changes in response to events.

Conclusions

In our experience model interpretation is characterized by very fast development times. In fact it did not even feel like development at all as domain experts are completely shielded from all incidental technical details.  I believe that Birtwistle and Tofts, the scientists that coined the weighbridge benchmark, would feel at home with the demonstrated DSL and the interpreter in no time. With incidental complexity out of the equation and direct involvement of domain experts, I think we’ve come very close to the essential complexity of the domain and development times cannot be drastically improved any more. That said, I feel that those interested in this approach should be aware of run-time performance penalty due to interpreter indirection. Whether this will pose a problem, depends on the application domain. What are your experiences with model interpretation? What is your domain?

References

[1] Graham Birtwistle and Chris Tofts. An operational semantics of process-oriented simulation languages: Part 1 πDemos. ACM Transactions on Modeling and Computer Simulation, 10(4):299–333, December 1994. [2] Jerry Banks, editor. Handbook Of Simulation. Principles, Methodology, Advances, Applications, and Practice, pages 813 – 833. Wiley-Interscience Publication, New York, September 1998. [3] Juan de Lara. Simulacio ́n educativa mediante meta-modelado y grama ́ticas de grafos. Revista de Ensen ̃anza y Tecnolog ́ıa, 23, Mayo-Agosto 2002.