Modelling with Papyrus: Domain-Specific Modelling Languages

Transcription

Modelling with Papyrus: Domain-Specific Modelling Languages
Modelling with Papyrus: Domain-Specific Modelling
Languages using UML Profiles
Kristof De Middelaer
University of Antwerp
kristof.de.middelaer@gmail.com
Abstract
Domain specific modelling languages (DSML) are often built from scratch. An
alternative way of doing this is by taking the Unified Modelling Language (UML)
and tailoring it to the needs of the domain. This can be done by using UML’s
profiling system. We take a look at how we can use Papyrus (an Eclipse based
UML2 modelling tool) to accomplish this goal using a Railway DSML as example.
Keywords: UML2, UML Profile, DSML, Papyrus, Modelling, Eclipse
1. Introduction
There are numerous reasons why one would want a (domain specific) modelling language. One of the reasons being that it adds another layer of abstraction so that domain experts can more easily build and argue about models
without having to learn how to code. For a long time modelling languages
weren’t standardized. Numerous modelling languages existed that were used
for the same purpose.
The Object Management Group (OMG) unified some of these modelling
languages and created UML: the Unified Modelling Language. UML made it
possible to describe systems in such a way so that everyone who understood
UML could understand the model.
Nowadays, a lot of UML tools exist. However, a lot of them are proprietary.
This makes the users of these tools dependent on the vendor providing the tools
which is always a risk: imagine the vendor dropping support or decides to stop
developing the tool. For this reason, open source tools are often preferred by
the industry and academia.
The Eclipse project provides an open source tool for graphical modelling of
UML2 models: Papyrus. It implements 100% of the OMG UML specification
and has become the de facto standard implementation of the UML2 meta-model.
Papyrus also supports the use of UML profiles which makes it suitable to create
domain specific languages.
The following sections talk about UML, Papyrus and how they can be used
to create domain specific languages. Section 2 talks about UML in general and
UML profiles. Section 3 gives information about what relevant functionality
Papyrus has to offer. Sections 4 and 5 talk about how a DSML can be built by
creating a Papyrus plugin and section 6 talks about further possibilities such
as model execution. Section 7 concludes and gives a short review of Papyrus in
terms of DSML modelling.
2. UML
The Unified Modelling Language (UML) is the successor to the wave of
object-oriented analysed and design methods that appeared in the late ’80s and
early ’90s. [1] Instead of everyone using their own language, a standardized
modelling language makes it easier to communicate about models. Models also
allow us to work at a higher level of abstraction. A model may do this by hiding
or masking details, bringing out the big picture, or by focusing on different
aspects of the prototype.
UML is a general-purpose modelling language. It helps you specify, visualize
and document models of (software) systems. Using a UML-based tool (such as
Papyrus) you can analyze the requirements and design a solution that meets
them. This solution can then be represented using UML’s diagram types.
2.1. UML diagram types
UML defines thirteen types of diagrams which are divided into three categories.
2.1.1. Structure Diagrams
These diagrams represent static application structure.
• Class Diagram
• Object Diagram
• Component Diagram
• Composite Structure Diagram
• Package Diagram
• Deployment Diagram
2.1.2. Behavior Diagrams
These diagrams represent general types of behavior.
• Use Case Diagram
• Activity Diagram
• State Machine Diagram
2
2.1.3. Interaction Diagrams
These diagrams represent different aspects of interactions.
• Sequence Diagram
• Communication Diagram
• Timing Diagram
• Interaction Overview Diagram
2.2. DSML using UML
Often times a single modelling language will not be enough to cover all
the various concerns involved in a specific area. A domain specific modelling
language (DSML) is needed. Instead of building these DSMLs from scratch,
UML could be adopted and tailored to the needs of the domain.
A custom language (that is not based on UML) has the advantage that it can
be defined in a way that is optimally suited to the domain. However, imagine
each individual subdomain of a complex system using a different modelling
language. Getting these submodels into a consistent, integrated whole that
can be verified, tested or simply unambiguously understood poses quite the
challenge.
If all of system’s submodels are based on UML, existing UML tools and
widely available UML expertise can be reused. Note that this does not completely solve the integration issues but mitigate these because of the common
UML semantics and syntax.
But how do we create a DSML using UML? This is where UML profiles
come into play.
2.2.1. UML profiles
In UML profiles all domain specific concepts are derived as extensions or
refinements of existing UML concepts (which are the UML metaclasses). These
extensions are called stereotypes. They are profile classes that extend UML
metaclasses.
Figure 1: Train is a stereotype that extends the Metaclass Class
3
These stereotypes can also include tagged values. Since UML 2.0 a tagged
value is represented as an attribute defined on a stereotype. Stereotypes can
also be used to change the graphical appearance of the extended model element
by attaching icons.
Figure 2: A custom icon that is given given to the stereotype.[7]
Constraints (such as OCL constraints) can also be defined. These apply
to stereotypes defined in the profile. Using these constraints we can further
constrain elements of the UML metamodel. For example, we could define an
OCL constraint that says that all instances of Class need to have at least one
operation. Constraints that can’t be expressed in OCL have to be denoted in
natural language which can then be rewritten in some language the used UML
tool will understand.
3. Papyrus
3.1. About
Papyrus is an Eclipse-based tool that uses the Eclipse Graphical Modelling
Framework (GMF). It aims at providing an integrated and userconsumable environment for editing any kind of Eclipse Modelling Framework (EMF) model
(in particular UML and related modelling languages such as SysML1 ). Papyrus
offers this integrated and userconsumable environment by providing diagram
editors for these models.
3.2. Functionality
3.2.1. UML modelling
Papyrus allows users to build UML2 models that strictly conform to the
OMG’s UML specification. If something cannot be represented in Papyrus, it
generally means that it is not allowed by the specification.[8] These models can
be created and edited using the graphical editor.
1A
dialect of UML for systems engineering applications: http://sysml.org/
4
As mentioned before, there are a lot of functions in support of UML2 modelling. To name a few: a tools palette which allows the creation of UML elements
in the diagram, a properties window that allows you to edit UML elements and
OCL constraints can be specified for each UML element which can then be
checked.
Figure 3: UML diagram in Papyrus
3.2.2. DSML
Papyrus provides extensive support for UML profiles. This allows the user
to create profiles for their domain which serves as the domain specific modelling
language.
The UML profile can change the concrete syntax: instead of the standard
UML graphics, custom icons can either be added to these or completely replace
them. Papyrus also provides powerful tool customization capabilities. This way
the tools can be customized to better fit the domain.
In other words: when a profile is applied, the tool may adapt its visual
rendering and GUI to fit the specific domain supported by that profile.
5
Figure 4: Customized tool and icons.
Eclipse provides the Papyrus User Guide Series. It is a series of documents
dedicated to assist the usage of Papyrus. There is a volume focused on using
UML profiles within Papyrus: from design and definition to application and
usage.[5] This 30 pages long document explains how to define and apply a very
basic UML profile.
3.3. Papyrus plug-ins
As Papyrus is based on Eclipse, it supports the use of plug-ins. What we
want to do is create a new Papyrus plug-in for our DSML. This way distribution
is easy by either copying the plug-in files into the correct directory or by using an
update site. As the following section will contain some Eclipse plug-in references,
we’ll first take a look at how Eclipse plug-ins work.
When people hear Eclipse they usually think about the Eclipse IDE. However, the Eclipse IDE is based on the Eclipse Rich Client Platform (Eclipse RCP)
which can be used as a basis to create other sorts of feature-rich stand-alone
applications.
The Eclipse RCP provides the existing user interface and the internal framework which can be extended using plug-ins. The Eclipse IDE for example
extends the Eclipse RCP with Java development or C development tools as
plug-ins.
Papyrus works the same way: it is also based on the Eclipse RPC and
provides plugins for UML modelling and all its capabilities.
Apart from building an extension for the Eclipse RPC it is also possible to
write extensions for Papyrus. This is done by creating a plug-in that uses the
concept of extensions and extension points. Papyrus offers a set of extension
points in which we can ’plug in’ our extensions. Concretely: Papyrus offers
6
extension points such as org.eclipse.papyrus.uml.extensionpoints.UMLProfile at
which we can register a certain profile which then becomes part of our extended
Papyrus program.
Eclipse provides a plug-in development environment which can be used to
more easily create plugins instead of creating these with raw files.
Figure 5: Creating an Eclipse plugin
7
4. DSML modelling in Papyrus
In order to create a DSML in Papyrus the following steps need to be followed.
First, a general step that is inherent to creating a DSML: identifying domain
concepts and relations. In this report the railway domain has been chosen as
an example.
Then we need to create a UML Profile that reflects our DSML. We create
stereotypes, a concrete syntax etc.
After this we add constraints in order to be able to validate models created
by the user.
Of course, the user needs to be able to create the models so we need a new
type of diagram. In our railway example this will be the Railway Diagram.
Figure 6: Creating a DSML
4.1. Identifying domain concepts and relations
A first, general step in creating a DSML is identifying domain concepts and
relations. This step is not explained here as it is not what this report is about.
For the example in this report the railway domain has been chosen. Note
that this is more of a toy example to show the DSML functionality of Papyrus
instead of a fully correct railway DSML.
8
4.2. Creating the UML profile
Creating the UML profile is quite a straightforward process.
You first start by creating a new Papyrus Project (or diagram) where you’ll
create the profile (file >new >Papyrus Project). This will open up the new
Papyrus Project wizard. Most steps are straightforward: when asked to select
a diagram language choose profile.
Figure 7: Select the Profile diagram language
Complete the wizard and when asked, select the Profile Diagram kind. Now
we need to create our stereotypes, give them tagged values and add images to
these.
Our stereotypes are extended from metaclasses. A metaclass can be added
by selecting import metaclass from the palette, clicking in the diagram and then
selecting the desired metaclass.
9
Figure 8: Import metaclass from the palette
Once this metaclass has been added we can start creating stereotypes that
extend these.
Figure 9: Metaclass extension
We can add tagged values to our stereotypes by selecting property from the
palette to our stereotype and clicking in the diagram. In the properties of this
tagged value we can choose the type, the initial value and other things.
10
Figure 10: Editing a tagged value
Once we have our stereotypes we can add images to these. In the properties of the stereotype under the UML tab we can add an icon. There seem
to be numerous ways of adding icons to the stereotypes but the only way I
found to be working was by adding the location of an svg file to the stereotype and then creating a CSS file that makes the images visible and hide the
usual UML boxes when creating an element. This CSS file can be found at
resources/Railway/custom.css.
A user can manually apply UML profiles. In a true DSML environment it is
preferable to hide as much of UML as possible. Automatic application of a UML
profile is possible but there is no very user-friendly way of doing this. This is
done programmatically by overriding the initializeModel method in a class that
extends from ModelCreationCommandBase and adding some code here. This
can be found in src/railway/CreateRailwayModelCommand.java.
4.3. Adding constraints
Model validation is an important aspect of using a DSML. Papyrus provides
support for constraints in the form of OCL or Java. I found no real documentation about the Java constraints and chose to write OCL constraints as there
was more documentation for this and as I tried to stay away from writing Java
code as much as possible.
Adding a constraint to a UML profile can be done by selecting constraint
from the palette and then clicking in the diagram. In this element the constraint
can be written by choosing the constraint’s context and adding a specification
in the UML tab in the constraint block’s properties.
11
Figure 11: Adding a constraint
An issue I encountered was when trying to create a constraint using Train.allInstances().
The returning set was always of size 0 and I had no clue why. I asked on the
Papyrus forums and turns out that it was a bug. A bug report was filed and it
has been supposedly been fixed.
When creating a model in the DSML, the constraints can be checked by
right clicking on the diagram and letting it verify the model. Manually doing
this is not ideal. It would be nice to alert the user and prohibiting a certain
action at the time the user is doing it. I found no functionality for doing this
in the standard Papyrus install. However, I found a validation plug-in that is
supposed to support the live evaluation of constraints and some more handy
features.
The validation plug-in contains a UML profile that can be applied to the
UML profile being created. It contains a stereotype for constraints which provides these advanced features. After creating the constraints, you would generate a validation plug-in that takes care of the constraints.
Unfortunately, the plug-in doesn’t really work as it is supposed to for OCL.
It should work with Java constraints but that would be too impractical. The
problem is that the OCL constraints are defined and validated in different OCL
environments (LPG vs. Pivot) which renders these unusable.
4.4. Creating a custom diagram
When a DSML user creates a model they’d need to create a new diagram
and add elements in that diagram. It’s important that this diagram is of a new
type as modelling the domain specific language in a UML diagram is not very
desirable. Creating an environment that facilitates the use of the DSML and
hides all UML would be nice.
12
Unfortunately, the online Papyrus documentation concerning this is very
limited and does not really specify how this can be done. Papyrus comes bundled
with SysML support which accomplishes this. So in theory I just had to open
the SysML plug-ins and see how this had been done.
There were numerous SysML plugins which did a lot of things. I had found
what extension points I needed to use in order to add a new diagram category
and diagram. After some searching I found the org.eclipse.papyrus.infra.core.papyrusDiagram
extension point which could be used for this. There was little documentation
on doing this in the help section. The things I achieved using this approach was
quite limited as it was quite complex, impractical and involved a lot of Java
coding. I turned to the Papyrus forums for some help and Camille Letavernier
(a Papyrus developer) told me that that was the old way of doing things. There
is a new way of doing this which is being used in the new SysML version called
viewpoints.
After installing and inspecting the SysML1.4 plug-ins together with the documentation (Help >Help Contents >Papyrus Guide >User Guide >Viewpoints
in Papyrus) I found out how viewpoints were created.
4.4.1. Viewpoints
The Papyrus documentation describes viewpoints as follows: ”Viewpoints
in Papyrus enable the specialization and customization of the user experience
by constraining what can be seen and interacted with in Papyrus diagrams and
tables.”
Figure 12: A viewpoint file
For our Railway example I created a Railway viewpoint which creates the
Railway diagram that is under the Railway category, adds the custom palette
and the custom CSS file that enables the stereotypes to show. Normally, creating
13
the Railway category could just be done in the viewpoint.configuration file but
that didn’t work. Creating the diagram category using the old org.eclipse.papyrus.infra.core.papyrusDiagram
did work.
Besides the earlier mentioned custom CSS file (that takes care of the concrete
syntax) the palette is a very important part of modelling in Papyrus. Elements
are added to the diagram by selecting them from the palette and clicking in the
diagram. A custom palette can manually be made which generates an XML file
in your workspace folder at .metadata/.plugins/org.eclipse.papyrus.diagram.common.
This XML file can then be included in the plug-in and used in the viewpoint so
that it automatically gets loaded.
Figure 13: Creating a custom palette
After defining the viewpoint, it can be added to the Railway plug-in through
the org.eclipse.papyrus.infra.viewpoints.policy.custom extension point. You can
either choose your viewpoint to be a contribution or a configuration. The contribution choice will add your new viewpoint to the already existing UML/SysML
viewpoints. If the configuration element is chosen your new viewpoint will be
the only one used. For our example the user should only be able to build models
in our DSML. Hiding the other options will make for a cleaner, less complicated
environment.
14
4.4.2. Property views
In Papyrus, every element in a diagram has a properties view. In this properties view one can edit the element’s information. In a DSML context it makes
sense to show the tagged values and make them editable. In order to get this
functionality in the properties tab we have to create a new properties context
file. Papyrus provides a wizard to generate such a properties context file from
a UML Profile (File >New >Other >Papyrus/Property view configuration).
This properties context can be hot deployed as well as be included in the DSML
plug-in directly through the org.eclipse.papyrus.views.properties.context extension point.
As we’re creating a UML profile, numerous tabs in the properties windows
in our stereotypes contain UML information. We generally want to hide this
information from the user. This can be done by deselecting the contexts we
want to hide in the workspace preferences (Window >Preferences >Papyrus
>Property views).
Figure 14: Selecting the desired contexts
15
4.4.3. Diagram assistants
Papyrus UML diagrams provide a feature called diagram assistants that
offer context-sensitive tools directly in the diagram. These assist the user in
two ways: there are pop-up bars that contain a variety of tools for the creation
of new model elements. The other way the assistants help is by providing
connection handles which can be used to easily create new connections to other
elements in the diagram.
The capabilities of these diagram assistants can be extended in order to
provide assistence for our profile-based DSL.
Unfortunately, it seems to be that there is no way to hide the existing UML
assistance which makes these assistants rather unuseful.
5. The complete DSML plug-in
5.1. Exporting and installing the plug-in
Once the development of the plug-in is finished, it can be exported. When
opening the plugin.xml file, there is an export wizard that helps you do this.
In order to use this plug-in you can copy the generated .jar file to the plug-ins
folder of your Papyrus installation and restart Papyrus. Another way of doing
this is by creating an update site for your plug-in. If you want to do this, I
suggest taking a look at the Eclipse documentation on this.
5.2. Using the plug-in
After starting Papyrus with our plug-in installed we need to make some one
time adjustments in order to be able to fully use the plug-in.
Open Window >Preferences >Papyrus
• In the Viewpoints Configuration section: choose Deployed through the extension point as configuration selection.
• In the Property Views section: deselect the contexts we want to hide as
described in section 4.4.3.
Now you should be able to create a new Papyrus Railway project, create a
Railway diagram and create a model using the palette and property view.
6. Further possibilities
As Papyrus is Eclipse-based it is based on technology which works with other
tools such as code generators, model checkers and transformation engines.
16
6.1. Operational semantics
For adding operational semantics there is a tool called MOKA[10] which is
used for model execution and is recommended in the Papyrus user guide. MOKA
is a Papyrus module for the execution of UML models, it is quite extendable
in order to support alternative execution semantics as you would want to have
with DSMLs.
Models can interactively be executed and CSS can be used to visualize the
execution.
6.2. Translational semantics
For translational semantics one can use a transformation language such as
QVT[11].
7. Conclusion
Development of domain specific modelling languages ogether with a DSML
environment should be easy and well documented.
Papyrus has great potential but at the moment of writing this report it has
some issues. It isn’t very user friendly to build a DSML environment: I encountered numerous bugs (most of them reported but not fixed), documentation
was lacking and sometimes outdated. If the process of creating the modelling
environment could be streamlined and well documented I’m sure Papyrus could
gain a bigger userbase.
One of the big strengths of Papyrus is that you can reuse Papyrus as a DSML
environment. In order to do so, one has to write a Papyrus plug-in.
All of this combined means that using Papyrus for domain specific modelling
has quite a steep learning curve. Once these issues have been resolved and there
is proper documentation Papyrus could be a great way of creating DSMLs.
17
References
[1] M. Fowler, UML Distilled, 2nd edition, Addison-Wesley, 1999.
[2] I. Object Management Group, What is uml?, http://www.omg.org/
gettingstarted/what_is_uml.htm (2015).
[3] I. Object Management Group, Uml website, http://www.uml.org/ (2015).
[4] T. E. Foundation, Papyrus website, https://eclipse.org/papyrus/
(2015).
[5] T. E. Foundation, Papyrus user guide:
About uml profiling,
https://eclipse.org/papyrus/usersTutorials/resources/
PapyrusUserGuideSeries_AboutUMLProfile_v1.0.0_d20120606.pdf
(2011).
[6] Softeam, The uml profile technology, https://eclipse.org/gmt/
omcw/resources/chapter04/downloads/TheUMLProfileTechnology.
SOFTEAM.ppt.
[7] uml diagrams, Uml profile diagrams, http://www.uml-diagrams.org/
profile-diagrams.html.
[8] T. E. Foundation, Eclipse newsletter april 2014, http://www.eclipse.
org/community/eclipse_newsletter/2014/april/article2.php
(2014).
[9] TechnologyUK, Uml profile diagrams, http://www.technologyuk.net/
computing/uml/profile_diagrams.shtml.
[10] B. M. Arnaud Cuccuru, J. Tatibouet, Moka model execution, https://
wiki.eclipse.org/Papyrus/UserGuide/ModelExecution.
[11] I. Object Management Group, Qvt, http://www.omg.org/spec/QVT/.
[12] G. P. Paul Roubekas, N. FAUVERGUE, others., Papyrus user guide,
https://wiki.eclipse.org/Papyrus_User_Guide.
[13] P. Eclipse, Papyrus youtube channel,
channel/UCxyPoBlZc_rKLS7_K2dtwYA.
https://www.youtube.com/
[14] C. Damus, Christian damus youtube channel, https://www.youtube.com/
channel/UCDYrc4lezoXkituy7B8xPNA.
18