Sunday, September 25, 2016

Implementation of Piping and Instrumentation Diagrams for Enterprise Architect

Piping and Instrumentation Diagrams (P&IDs) are a common way to model systems in process engineering. However, currently very few modeling tools support this kind of diagrams.

The complexity of modern process plants is steadily increasing. To overcome this potential source of error it is obvious that a abstract way to model such systems is needed. Piping and Instrumentation Diagrams or P&IDs are used in various areas to model these complex plants. To evolve the usage of P&IDs in the industry, significant support of modeling tools is needed. Our research showed that currently few tools allow modeling of such diagrams.

P&ID

The Piping and Instrumentation Diagram (P&ID), is primarily derived from the Process Flow Diagram (PFD). P&ID is used to support or guide the design and construction of process plants. P&ID helps to communicate between designers, constructors, operators and owners of the plant by providing a schematic representation. The schematic representation elaborates important details of piping and instrumentation and should tie together the system description, system flow, electric control schematic and the control logic. The semantic of the diagram should help to demonstrate the physical sequence and connectivity of equipment in a system. Another important concept is the isometric drawing scheme or the orthographic physical layout. In other words the  placement of elements in the diagram should practically represent the physical placement of components in a plant.


UML Extension Techniques

Although UML offers a broad range of diagrams to model systems there will always be a need to model domain specific characteristics. Another fact is that it will always need time to take care of new technologies in the UML standard.
Two overcome these drawbacks UML allows to adapt the standard. 
Basically there are two different approaches: lightweight extensions through profiles and heavyweight extensions through meta-model modifications. Enterprise Architect mainly features extension through UML Profiles, this is why we chose this approach.

Implementation of P&ID Profiles in Enterprise Architect

Enterprise Architect offers a powerful extension mechanism based on the standardized UML Profile principles. Enterprise Architect lets you access this functionality via the Model Driven Generation Technologies SDK. Enterprise Architect has a built in MDG Technology Creation Wizard which eases initial contact with the overwhelming size of the tool.

Visualizing P&ID elements with Shape Script

Elements and connectors which were extended via UML stereotyping conform to the standard UML notation in terms of shape, color and labeling. Enterprise Architect offers the possibility to define the appearance of extended elements and connectors using their proprietary Shape Scripts language. Shape Script allows the developer to define size, shape, orientation and color of custom elements. Furthermore Shape Script provides some methods for reflection, with which the graphical representation can react to the properties of the given instance of the element. Shape Script uses a C-like syntax.

Comparison of the Eclipse Modeling Framework (EMF) with the Meta Programming System (MPS)

By Romana Jakob, Julian Lehner, Alexander Schörghuber

Introduction


In the last decade a dramatic growth of software intricacy and different methodologies and techniques have been proposed to support the development of complex systems. Model Driven Engineering lays the focus more on modelling than on coding and lets software architects harness the opportunity of dealing with higher-level abstractions.

Basically said, programming is completely based on abstraction, which increases the need for models in order to get a better understanding of the whole problem. Nowadays, there is a huge amount of diverse tools to create languages. Therefore, the need for objective empirical tool comparison increases.

Models can only develop their full potential if they can be manipulated by means of automated transformation to obtain different kinds of artifacts. These artifacts may range from other models to documentation or even implemented code. At this point it is vital, that the designers and developers are able to comprehend the overall possibilities of the framework used for development. It is left to say, that each system focuses on different outcomes and therefore it is important to know the differences and the advantages and drawbacks of the used system within the applied field.

Thus, when it comes to evolving a system it is crucial to obtain an accurate picture of the quality requirements of the system. In this work, the focus especially lies on frameworks for the realization of a model-driven approach to language development. The concrete tools used in this comparison are the Eclipse Modeling Framework (EMF) which is used for the definition of a metamodel together
with Xtext which is used for defining a textual notation and JetBrain's Meta programming system (MPS).

The core topic of the project is the comparison of these tools. EMF may be more established as it enjoys a longer market presence but MPS has definitely made up its delay. The paper tries to develop neutral criteria to compare modeling frameworks and apply them on EMF and MPS based on an example implementation of IML (Intermediate Modeling Layer).

Evaluation


By implementing a pre-defined language named IML in these two meta modeling systems, the knowledge was gained to accomplish the evaluation. In each of these two implementations, the focus was held on using system specific elements and do not focus on details and syntactic sugar.

To summarize the outcome of the evaluation it is important to say that each of the considered systems has its own advantages and disadvantages regarding the used evaluation criteria. To pick out some of the features there are for example those that are really good in both systems, like Feature coverage, Functionality or Scalability. Then, there are criteria that are very different in both systems like Lines of code (or better the textual overhead) because of the spread files approach of MPS. A little bit surprising is that, there is no criteria that has got a bad grade in both systems. This as much more shows that the existence of both meta modelling systems is legitimate.

Outlook


The work gives only a small overview about some parts of those very powerful meta modeling tools. The focus was on analyzing an existing language in EMF and implementing this language completely from scratch in MPS by focusing on the Meta-Modeling and defining and implementing of the abstract syntax.

And then to analyze the different approaches and make a comparison of those two systems. Because MPS is not so well known and more new than EMF, it was also a bigger part of the project to describe some basics of MPS. The task for the future would be to work out more examples about the additional features of MPS and to compare them with the existing implementations of EMF.

EMF is a very powerful and wide meta modeling system with a big community and because of using eclipse also continously enhanced, for example in the area of creating View Models and using renderer based on the Ecore Domain Model to achieve user interfaces. A study would be interesting on how these approaches could be realized in MPS. Maybe this is more work to do to fit it into a single project, but some fundamental research would be fine.

For more information on the project, we kindly refer to the full report and the source code of the implementation.


Realizing a DSL in MPS

By Alexander Eigner and Paramvir Parhar

Introduction
The aim of this project was to get first hands-on-experience in the Meta Programming System by implementing an own domain specific language in MPS. This DSL should be based on some main ideas from the fields of systems engineering and executable UML. By taking the structuring aspect of systems engineering into account this DSL should allow the user to model a system that is composed out of interlinked components. Following some ideas of executable UML this DSL should also allow the user to model behavioral aspects of a system and to execute (e.g. simulate) this system already during the design phase by means of code generation.

The Meta Programming System
For implementing our DSL we used a relatively new language workbench, namely Meta Programming System developed by JetBreains. JetBrains MPS is an open-source language workbench for language engineering. MPS itself is implemented in Java. It runs on the JVM and allows defining general-purpose as well as domain-specific languages. Unlike other implementa- tions MPS does not use a parser or grammer at all, but it uses structural editors, in which the textual syntax represents a projection of the abstract syntax tree (AST), hence the user edits directly on the abstract syntax tree. Therefore, MPS supports mixed notations like textual, symbolic, or graphical. The fact that MPS does not use a parser allows users to enable language modularization and com- position more easily. The projection of the AST guides the user through the development as it knows what is allowed and what not. MPS supports combining and extending different languages. In order to trans- late the DSL code into another language like Java it is necessary to do a model transformation.

Implemented DSL: ComponentStateCharts (CSC)
The name of the implemented domain specific language origins from two well known modeling diagram-types, the component diagram and the statechart diagram. CSC offers the possibility to model the structure of a system by allowing the user to define components and connect them with eachother via ports, which shows the similarity of our DSL to component diagrams. CSC also allows the user to define the behavior of a system by letting the user define a state machine for each component. Therefore the domain of CSC extends to the modeling of structured systems that consist out of interlinked components with specific behavioral features. CSC moreover allows the user to define a simple execution sequence, which is a sequence of function-calls of the components, in order to simulate a sequence of events on these components. In addition to that a CSC-to-Java generator was implemented that can generate a Java class for each component as well as a simulation class to simulate a concrete behavior of the components according to the defined execution sequence.

Evaluation
The main part of the evaluation was conducted by counting the number of code-lines that were needed to model a sample systen in CSC against the number of Java code-lines that were generated via the CSC-to-Java generator. This evaluation showed, that there was a huge saving in code-lines in CSC due to its laconic and error-tolerant syntax. Besides the saving of code-lines CSC also has some shortcomings. Due to the lack of time of this project it was not possible to implement a sophisticated concept for component-functions that e.g. could allow the user to define return types. This fact can lead the user to tedious coding-bypasses if he or she wishes to overcome that lack of return types.

Future work
There are several upgrade possibilities for CSC. Component-functions could for example have return types. The transitions of a component's statechart diagram could have guard conditions. Components could interact with eachother sophisticatedly via data streams. The use of Realtime UML could allow a wider range of analysis during the execution of a CSC model.