Today’s guest article has been written by Carsten Pitz, who shares his insights about the state of Papyrus for modeling, which is likely to be interest to our readers. In particular, as an Eclipse based tool, Papyrus can be integrated with ReqIF Studio.

Nevertheless, Papyrus has the reputation of not being fit for industry, being hard to use and missing important features. However, Carsten’s opinion differs quite a bit. Read on to find out why.

Papyrus – or My View on UML (by Carsten Pitz)

The following article is a very personal view on Papyrus. In order to give it the proper foundation, I need to start with my first contact with UML in 1998. Back then I worked at a large German logistics provider in a group of four architects. Our job was to explore and evaluate innovative technologies. UML was published as an open specification on November 19, 1997, and it was new and innovative that time.

Also, the object oriented methodology (OO) was new at this time. As in Germany the double-zero has a certain meaning, the concept was commonly associated with the toilet – which lead to some amusement with the department secretary…

So we explored the UML 1.1 specification (UML 1.0 was Rational proprietary) and evaluated four UML tools. These tools were: Rational Rose, Together Together/J, Computer Associates Paradigm Plus and Sterling Software COOL:Jex.

Exploring UML 1.1. with Together/J in 1998

Our choice was Together/J. Maybe not the worst choice because Together/J is the only tool of these tools still existing. If Andreas W. is reading this: Hello Andreas, I am aware of the fact Sterling Software COOL:Jex became Telelogic Tau which in turn became IBM Rational Rhapsody. But, the changes to COOL:Jex have been much more disruptive as with Together/J.

Despite the fact, Together/J is the only tool of these tools still existing more or less as it has been 1998 in retro-perspective I have to admit the choice was highly influenced by the developer backgrounds we had in common.

Nevertheless Together/J perfectly fitted our needs back then. The round-trip engineering Together/J featured back in 1998 does not second to any other tool even today.

Focus on Structure

Having strong developer backgrounds, our focus was on structure, more precisely on class diagrams. These simple class diagrams helped us a lot to visualize and discuss ideas (Carsten Pitz)

Simple class diagrams help a lot to visualize and discuss our ideas.

Just one more information on me. The oldest and by far most experienced developer of our team took me aside some morning and told me: “Your designs are somehow weird. Your designs perfectly respect all OO rules I am aware of. But somehow I deny to call your designs object oriented. I thought long on this and got the idea yesterday evening. Your designs are component based.”. After some while I answered: “Yes, my designs are component based. I am an engineer and as an engineer I think in re-usable components communicating via well defined interfaces.”

I analyzed my designs and compared these to the designs of the other architects of our group. I was the only one who used interfaces and packages. I introduced dedicated classes I called interface classes. Today this kind of classes are commonly referred to as facades. These interface classes I gathered in interface class packages. The only public packages of the components.

Focus on Behavior

Later, in 2002 my context changed. I had to discuss implementation options with customers and not only within a team of architects. Even though program code is the most accurate notation to express behavior, most customers with business context are not able to understand program code. As a result describing behavior using UML notation soon extended my modeling portfolio.

State machine diagrams and sequence diagrams can be designed and presented in a way customers understand. This was fine.

Artifact Generation

Being an engineer at heart, it really hurts me to throw away a piece of work. This leads me to artifact generation. My original tooling to achieve that was ArgoUML & AndroMDA. ArgoUML is an UML modeling tool. AndroMDA is a model to text, a M2T converter. But ArgoUML was not migrated to support UML2.

UML2 and the Meta-Object Facility

For me UML2 came perfectly the right time. UML2 provided me with a cleaned up profile mechanism and a cleaned up UML meta-model, the Meta-Object Facility (MOF). The MOF evolved to something really useful to me. But as I mentioned before ArgoUML was not migrated to UML2.

I tried several different tooling setups. Eclipse Topcased fitted my needs best, so I continued with Topcased. Topcased used Acceleo as artifact generator, so I started to use MOFM2T – the OMG’s notation to transform models to text – as transformation language.

Use Cases

As I wrote in a Blog Post at SE-Trends (German), use cases made me view objects as actors, architecture as a choreography of actors. That principle proved to be extremely powerful.

Nevertheless I forgot about use cases, simply because I had no need for them. At that time, no one, even in academia, seemed to use them either.

My interest on use cases came back, when I had to deal with a huge amount of requirements. If I remember correctly, in this project the requirements engineers gathered some 17.000 requirements of questionable quality.

I thought on it and after a while I – more by instinct as by ratio – started to define use cases and to assign requirements to the defined use cases. That approach proved to work. So I instructed the other architects to help me doing this. It worked. We quite fast developed an understanding of what was to do.

On tools and their limitations

As you might already noticed, my tool history was diverse and quite disruptive. With my strong developer focus I started with Together/J, because of its unsurpassed round-trip engineering features. My need for artifact generation lead me to the combination of ArgoUML and AndroMDA. And to participate with the advantages of UML2 over UML1, I migrated to Topcased.

In addition to these, I tried many so called “UML” tools. All these other tools I felt as jails, to be more precise as collections of limitations. These limitations express themselves as limitations in expression power, model size, and the ability to adapt and extend the tools to me needs.

Expression power – UML out of the box provides me with a rather limited expression power, but its profile mechanism enables me to extend the expression power to fit my needs. Utilizing the profile mechanism UML provides me with a virtually unlimited expression power. That is why I often translate the “U” in “UML” as “universal”. For me, a tool must not limit the profile mechanism of UML.

I prefer to translate the “U” in UML as “universal”, not “unified” (Carsten Pitz)

Model size – Modeling in the depth of detail needed to perform artifact generation results in rather big models. Many tools I tried failed to support models of the sizes required for that job.

Adaptation and extension – So far I had no need to seriously adapt or extend an UML tool. While this makes it hard for me to commend on this subject, I prefer to have the ability to do so.

Papyrus: A Modeling Framework for UML and SysML

Topcased has been discontinued, and after several incarnations (OPEES, Polarsys), Papyrus seems to be where all the action is. I first tried Papyrus when its version was 0.8 and the evaluation of the pre-1.0 looked promising. In many ways, Papyrus followed highly controversial design decisions, that had already been discussed in the days of Topcased. Even more than Topcased, Papyrus was a set of tools, a framework to be assembled and configured by the customer. But having a developer background I was used to assemble and configure modules.

Even more than Topcased, Papyrus is a set of tools, a framework to be assembled and configured (Carsten Pitz)

Strictly speaking, Papyrus is only the UML/SysML editor. What I am referring to here as “Papyrus” is actually a customized and extended Eclipse, with the Papyrus Plug-In at its core.

Papyrus features the most accurate UML 2.5 implementation of any UML tool I used so far. In some way it seems to me Papyrus wants to be more holy than the pope. But I can not just life fine with that, I really appreciate this attitude, because Papyrus is intended to model safety critical systems. While working with Papyrus is hard, ig gives me the confidence that I did my job right.

Papyrus is the most faithful UML 2.5 implementation to date (Carsten Pitz)

I use the full set of diagrams UML provides, including timing diagrams. Papyrus is the only UML tool I am aware of which respects the first sentence of chapter 9.6 “Operations” of the UML 2.5 specification: “An Operation is a BehavioralFeature that may be owned by an Interface, DataType or Class.”. This very sentence is absolutely vital to me. It enables me to specify a behavior as an operation.

SysML 1.4

Papyrus 2.x supports SysML 1.4 and optionally SysML 1.1 (SysML 1.1 support has to be installed separately). Working hard to be more holy than the pope also seems to be the agenda of the SysML team. But as mentioned before, I really appreciate this attitude.

From the SysML offerings I actually only use block definition diagrams, internal block diagrams and and sometimes requirements.

Strictly implementing the SysML specifications, connectors are only allowed to connect parts of a block. Consequently connectors are only available in internal block diagrams. Once I learned to respect this, I feel about it as a guide, not as a limitation.

SysML Connectors are only allowed to connect parts of a block. This acts as a guide, not a limitation. (Carsten Pitz)

What else? BPMN, Profiles, OCL

BPMN – Even though support for the Business Process Modeling Notation (BPMN) is very preliminary, I currently evaluate it. So far I do not use it productive. Somehow I miss swim lanes and would like to assign UML actors to BPMN swim lanes. But at least the second aspect is a BPMN specification issue and not an implementation issue.

UML Profiles – As mentioned before the UML profile mechanism is absolutely vital for me. Papyrus provides me with an in no way crippled, mature implementation of the UML profile mechanism. The support includes beside a complete implementation of the UML specification a very comprehensive profile versioning mechanism.

OCL – The object constraint language of UML(OCL) is an IMHO important part of the UML world. OCL allows you to define constraints. The following diagram represents a simple example:

MOFM2T – The transformation technology for MOF-Models (Model Object Facility) was already mentioned earlier. I use MOFM2T directly via Acceleo to generate artifacts and indirectly via GenDoc to generate documentation. Despite the fact the version number of GenDoc is v0.60 and still has minor issues I start to use it in a productive environment.

Acceleo from Obeo is a code generator, which is is a very mature tool that I completely rely on.

ReqCycle is a requirements tracing extension to Papyrus. ReqCycle is highly configurable and does not limit you assigning requirements to elements in any way.So far, I really appreciate ReqCycle. But I am missing some crucial features. For instance, how do I get the number of fulfilled, open or obsolete requirements?

My Issues with Papyrus

At this point it should be obvious that I am not only a fan of Papyrus, but I consider it production-ready. Having said that, there is room for improvement. Here is the list of grapes that I have with the tool:

Lollipop notation – The lollipop notation for interfaces has some issues. This very issue has been recorded nine times in the bug tracker, and so far has still not been resolved.

Messages within Timing Diagrams – I so far did not figured out how to do this with Papyrus 2 or 3. I retested it with the versions 2.0.2 and 3.0 M4 without success. It perfectly worked with Papyrus 1. But with Papyrus 2 and also 3 a message between events seems to only accept its start point, but not its end point.

The following diagram demonstrates this with a fictive, simple timing diagram done with Papyrus version 1.1.4, showing messages between events highlighted with red color:

Messages between lifelines are shown in figure 17.30 “Timing Diagram with more than one Lifeline and with Messages” of the UML 2.5 specification. I filed an issue for this. It is not a show stopper at all for me, but still an issue.

Nested ports – So far I was unable to model nested ports. But as I understood, this feature is work in progress. I really value nested ports when it for example comes to transform a set of BDDs and IDBs representing some hardware into an input file of a PCB layout system.

GenDoc is used for document generation. When text is generated from an owned comment containing dynamic references to elements the link is not resolved.

What About the Critics?

There has been some criticism about Papyrus, some of it justified, some due to miscommunication. I’ll comment to some of the more prevalent issues.

Framework vs. off the shelf product – I mentioned that point before. But, as far as I understood Papyrus is intended to fit needs far above the scope of other so called high end UML/SysML modeling tools. This requires Papyrus to be adaptable and to be extensible. These two requirements IMHO simply cannot be met by a monolithic design. Feel free to teach me better.

Easy of use – Papyrus is not just what I refer to as “a so called “UML” tool”, Papyrus is a real UML tool. And Papyrus is a tool and by no way a toy.  My wife bought a chain saws recently. Even such a simple tool like a chain saw requires users to know how to use it. But unlike an UML modeling tool, a chain saw is a merciless tool. If you do not know how to use it, you most likely literally will loose a leg or an arm. Consequently, the pain induced by this notion is sufficient to make most users to study the basics before using their chain saws. The same applies to a modeling tool: the user shall be familiar with the modeling notation and with modeling.

An architect familiar with the UML notation will face no major issues in mastering Papyrus. But being familiar with the UML notation requires one to read and understand the UML specification, which is not trivial. According to my perception, at most one out of a hundred people who claim familiarity with UML even know a specification exists. Without judgment, this simply is too disappointing to me.

In my perception, only one of a hundred UML users knows that there is a UML specification.

Many “UML” users consider UML to be what I refer to as “drawings”. Even worse, “drawings” are often demanded. Sorry, in my very own view an UML model is not colorful, not sexy in any way. An UML model is a rather abstract, (semi-)formal description of a plan, nothing else. Only very few customers today are willing to accept this. Compare this to the early 2000s, where customers were much more willing to accept this. I consider this to be a social problem.

Papyrus Evolves

Papyrus evolves fast. The current version is 2.0.2 (as of December 7, 2016). Milestone 4 of version 3 has been published December 14, 2016 and the final of version 3 is planned to be published Juli 3, 2017 along with Eclipse Oxygen. Version 1 was intended to make it work, version 2 to improve the GUI, and version 3 for full support of model to model transformations (M2M). So far I only used model to text transformations. M2M will open a new world to me.

The Papyrus team is also responsive, as shown by the links to entries in the Papyrus bug tracker in this article. The developers respond to these, communication is in no way a monologue, it is a dialog.

I Learned to Say: “Thanks”

We Germans are known to complain. In that way, I am German. We Germans are also known to not say: “Thanks”. But I am practicing, and will work hard to improve my skills that way. Promised. Thanks.

Photo: Michael Baird / Unsplash