Deliverables

Home
Plan
Publications
Deliverables
Wish List
Canada
Links

Edit

Simplified Class Diagrams

This is a custom UML Class Diagrams-like formalism designed with AToM³. The following UML constructs are supported:

Class
Object
AssociationClass
Generalization

Note that SCD is fewer and simpler in features then UML Class Diagrams. However, it features a number of automated transformations (see below).

Graph Grammar transformations for the SCD formalism

DEVS2DEVS_GG: transforms a DEVS metamodel into another equivalent DEVS metamodel in the same formalism. The goal is to expose some implicit features as explicit attributes and methods, with some optimizations. This transformation is meaningful only in the context of E. Posse 's DEVS metamodel. It was created to formaly specify (manual) changes that were necessary to convert the original metamodel into a form suitable to contain abstract specifications of DEVS components (models).
SCD2ZSCD_GG: transforms any model in the SCD formalism into equivalent SCD model and optimises the model for consiquent generation of ZProduct code (see below). For instance, it removes quasy features like roles and substitutes them with new methods on proper classes; in addition, it also implements those methods using Zope API.
ZSCD2ZProduct_GG: given any model in the SCD formalism, generates corresponding ZProduct implementation (in Python). The result can be placed in the Product directory of Zope. It is recommended that the source model be optimised with SCD2ZSCD_GG transformation before a code generation takes place.

Creating DEVS Components with the Meta-Modelling Tool AToM³

In close cooperation with the MSDL lab, a dedicated DEVS modelling and simulation environment was implemented by means of metamodels and graph transformations. This work is described in a conference paper (see section Publications ). The following is an abstract of the paper:

"DEVS is a well-known formalism that provides a rigorous basis for discrete event modelling and simulation. In this paper we present two possible DEVS metamodels that are used to automatically generate 1) a tool that allows the graphical definition of DEVS models and 2) Zope products that allow storing DEVS models in a model library under the Web Application Server Zope. The tool is capable of generating a representation suitable for simulation by an external DEVS solver. The generation of executable model representations and Zope products is realized by graph transformation. The tool, the simulator and the model library form a dedicated DEVS modelling and simulation environment. The paper demonstrates how dedicated, domain/problem-specific modelling and simulation environments can be easily generated from metamodels using graph transformation."

Process Interaction formalism

A Process Interaction metamodel (PI_ER) is used in the Graph Grammar model of piDemos' Operational Semantics (see below). Originally, the metamodel was developed by Juan de Lara. For the new application, PI_ER was extended to a) explicitly represent mapping and sequence data structures and b) include additional constructs (PieceClass, PieceDeclarations, etc.) and some new attributes as in piDemos system.

Modelling piDemos' Operational Semantics in the Graph Grammar formalism

This work was done in order to have an abstact specification of operational semantics for a custom Process Oriented Kernel (POKer), and consequently be able to automatically generate the solver in one of the programming languages (see below). Another advantage of a Graph Grammar model is that it is executable model, therefore effects of operational semantics of the modelled kernel can be studied visually.

POKer is based on a piDemos by G. Birtwistle and C. Tofts, a demo Process Interaction (PI) programming language featuring formal specifications of operational semantics of its commands. The authors prooved some interesting properties of piDemos, such as livestock and deadlock, which makes it a good starting point for developing custom PI kernels.

Generating Efficient Solvers from Operational Semantics specified with the Graph Grammar

This work considers a model transformation itself as a subject model (let us name it GG1) in the Graph Grammar formalism and applies a Graph Grammar transformation (GG2) to GG1 (we assume that it specifies operational semantics). Given that enough information is available in model GG1, the output of such a transformation can be executable code in a programming language implementing the operational semantics of the solver.

We tackle this task with help of two transformations:

GG2SCD_GG: transforms any Graph Grammar model into an equivalent model in the SCD formalism. Obviously, the result is meaningful, if the GG model describes operational semantics. In addition few more conditions apply.
SCD2Python_GG: given any model in the SCD formalism, generates corresponding Python implementation.

This is a work in progress.

Other

ER2SCD_GG: a rather straightforward transformation that, given a model in the ER formalism, creates an equivalent model in the SCD formalism.
ZProject: an attempt to make the original MSDL web pages more generic and dynamic by using the acquision mechanism of Zope. The project included a) factoring out common code from the previous page templates/scripts, and b) parametrizing new zope objects. More details can be found here.