Architecture
The Simulator Core Model represents the main component, where most of code is generated and modeled behavior is integrated. It provides an API for clients to create games, build stages or interact with actors by their commands and queries. For internal access, the core model provides several roles which represent dedicated interfaces for use-cases like reading information, processing game commands or building a stage. Further, state information can be observed by the observer pattern.
The UI Logic and View Model represent another combined component, which depends on the core model. By using a view-model, relevant information which is rendered on screen is defined as an in-memory representation. It acts as a simple, observable data-structure which can be observed by code based on a concrete UI framework. A presenter class represents the implementation of the UI logic and is responsible to fill or update the view-model. For the UI component, only data structures and class stubs are generated. The UI logic itself has to be implemented manually, since generating this code is out of scope of this project.
On the left side the UI Framework component is depicted, which is handled as an infrastructural detail of the architecture and therefore placed on an ''outside'' layer (see Uncle Bob's Clean Architecture). It is responsible to render the view-model on the screen and obtain user input events to trigger the UI logic. In case of Java, the framework JavaFX is used. For the C++ variant, the SDL is used as an application framework. Alternatively, this component can be replaced by a test runner, which can interact with the whole UI logic for automated testing.
Last, the Client Code is shown below the core model. It represents code which is implemented via an IDE of choice, like Eclipse or IntelliJ IDEA. Through a delay mechanism, called commands on the core are processed with a delay to be able to follow changes on the rendered view.
The modules are implemented in Eclipse using the emf framework and are structured to be deployed as an OSGi component. The structure is oriented on the best-practice layout for publishing with Tycho by using sub-folders named bundles, features and releng. The figure shows a package diagram representing the relevant modules of the mpw framework. While the related Eclipse module names have the prefix "de.unistuttgart.iste.sqa.mpw", for readability this is omitted in the figure.
The modules placed under bundles are Eclipse plugin projects which represent the essence of the mpw modeling framework.
These plugins are classified as modeling or generator modules, while the former contain entity models, transformations and workflow scripts.
First, the module mpw contains meta-models used to describe MPWs and contains the MiniProgrammingWorld package, Command package and ViewModel package.
Transformation logic is placed in the transformation module, which includes QVT-O transformations and further intermediate meta-models.
It imports mpw, since some entity types are transformed for the simulator, e.g. by adding roles to concrete Actor or Stage classes.
Next, the workflow module provides the basic infrastructure to execute the transformation workflow based on the MWE2.
It defines several classes to load different input models on the file-system, integrates the QVT-O Java API to execute transformation rules and calls the generator components.
Since the workflow module is not intended to be executed directly, a separate framework module is defined, which contains a concrete MWE2 workflow to generate mpw simulator framework classes.
For generation, primarily the two modules generator.cpp and generator.java are used.
They contain Xpand and Xtend code to generate the intermediate models after executing transformation rules into concrete code.
To share common generation logic, a further module generator.utils is defined, which is omitted in the figure for simplicity.
Another relevant component is represented by the querydsl module (https://github.com/SQAHamster/mpw-modeling-querydsl), which defines the concrete and abstract syntax of the Query-DSL, which is used to model queries and constraints.
It is deployed as a separate OSGi bundle with its own modularization structure.
The transformation module imports querydsl to operate on these input models.
The next modules are mainly used for deployment of the plugins projects.
While the feature module represents an OSGi feature including the modeling and generator plugin projects, the updatesite defines a repository consisting of this feature.
Last, the targetplatform module defines several update sites, which provide all required OSGi dependencies used in the mpw modeling framework.