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