Is Eclipse Papyrus Ready for Industry?

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:

A Simple OCL ExampleMOFM2T – 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 within Timing Diagrams

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

One Pingback/Trackback

  • Pingback: Wie ausgereift ist Papyrus für UML wirklich? - Systems Engineering Trends()

  • Charles Rivet

    Thanks Carsten!

    I really enjoyed this article. This was a well-thought and thorough view of the current state of Papyrus. However and in your opinion, reusing the title of your article: Is Eclipse Papyrus Ready for Industry?

    A few comments about the history:
    Rational Rose became IBM Rational Rose, which became (for a _very_ short period of time) Rational XDE, which then became IBM Rational Software Architect, which still exists.
    Note that Telelogic Tau and I-logix Rhapsody were not the same tool and were developed independently by two different companies. Although they were touted as complementary when Telelogic acquired I-Logix, they were never truly merged. Just to provide some background on me: I started using Rational Rose with v2.7, have been involved with Rational XDE as both a developer and product manager, and with IBM Rational System architect and IBM Telelogic Tau as a product manager.
    Did you know that Papyrus and Topcased were merged with the Eclipse Helios release? At that point, the UML modeler part of Topcased was Papyrus (there is more to Topcased than just UML modeling)! The two were then forked again with the Eclipse Indigo release.

    Some notes about the issues you noted:
    Lollipop notation: Agreed. This has also been a problem for me recently with one particular contract, but it is not something I use in my day-to-day work with Papyrus for Real Time as it is not part of the UML-RT definition.
    Timing diagrams: these often do not get too much love, but they are also rather low on the list of diagram usage…so they are rarely a priority.
    Nested ports: I ran into that at the end of last year and figured out how to do it – and no, it is not intuitive. I’ll dig through my mail to find the process I followed and let you know. I’m pretty sure I created a bug for that…
    GenDoc: That tool has made great advances over the last year or so! However, they are a small team…
    As with anything, if you (or any of your readers) find a bug, please report it! The development team can not fix things of which they are not aware!

    Sinde this article is related to the use of Papyrus in industry, I would also like to mention that Papyrus is end-user-driven through the Eclipse Papyrus Industry Consortium (“PIC”,, under the Eclipse PolarSys working group. As part of its mandate, the Papyrus IC is developing a Papyrus product line ( For industries who are interested in Papyrus, this is a good way of influencing its future!
    Also note that there is at least one commercial support offering available for Papyrus , which is an important consideration for industrial use.

    • pica

      Hi Charles,

      many thanks for the roses.

      I was always better in math than in history 😉

      on nested ports:

      A nested port is simply a port, which has a block with ports as type. This has a really nice implication. The definition of a nested port is recursive.

      Consequently the IMHO intuitive way to model a nested port would be to assign a port a block with ports as type. This would result in visualizing the port with its nested ports as default. But sometimes a port with nested ports shall be presented as “simple” port. And at this point things get complicated. The recursive nature of nested ports makes it even worse.

      on GenDoc:

      I know it is a small team, but nevertheless they do an excellent job. Printed documentation manually signed (to make it a contract is) often a must. Consequently I view GenDoc is a crucial part.

      • Charles: Regarding GenDoc, I absolutely agree with Carsten, for yet another reason: Im my experience, there are 20% creators of models and 80% consumers. The consumers rarely look at the model in a tool, but on paper. Also, document generation is often the first line of contact with modeling for the non-enthusiasts (i.e. those who need to be convinced). Document generation is crucial on order to gain momentum.

        • Charles Rivet

          I agree with both of you on this topic. In addition, there are industries that still have requirements for printed document as the “truth” (e.g, medical equipment). We just can’t get away from paper…

        • Antonio Campesino

          I am one of the Gendoc committers and it will be very interesting for us to know what and how do you guys use Gendoc today. As Carsten says we are a small team and today mainly progress in the project by the things we need for our daily work.
          I recently contribute to support xlsx formats, so with the latest and greatest it is possible to create excel files. Next in the pipe is to be able to create slide presentations (pptx).
          So please, if you have some interesting idea or use case for Gendoc, please contact us and let see what we can do.

  • Axel Scheithauer

    Thank you for this interesting post.
    One thing I don’t understand. Are there really tools that don’t allow to specify operations for classes, interfaces and data types? All tools I know can do this. Probably you are referring to something else, but I don’t know what.
    There is a small error in your OCL-example: The multiplicities must be 0..1, since OCL cannot override this constraint.
    You are perfectly right, tools should stick strictly to the specification. I just had to tell a customer that they have to redo most of their modeling, since all connectors were connecting the wrong elements (I won’t mention the tool here).
    One diagram I badly miss in Papyrus is the Interaction Overview Diagram. Rebranding an Activity Diagram is not doing the trick. I know, not many people are using it and in UML 2.5 it almost was thrown out. Nevertheless it is a very valuable Diagram that should be used more often, in particular to describe use cases.
    I really like your chainsaw metapher: UML – the chainsaw of modeling languages, better get your “Kettensägenschein” first.

    • pica

      Hi Axel,
      what do you refer with: “Are there really tools that don’t allow to specify operations for classes, interfaces and data types?”.
      If it is the first sentence of the chapter of “Operations”, it simply is, Papyrus is the only tool, which enables me to assign an operation of a class or interface to a behavior. One example are state diagrams. UML 2.5 defines behaviors to be executed when a state is entered or left. With Papyrus I can assign these behaviors to operations.
      Best regards,

      • Axel Scheithauer

        Hi Carsten,

        yes, that is the sentence I was referring to. But I still don’t understand. I can define an entry-Behavior for a State in a Statemachine. Papyrus offers me Activity, FunctionBehavior, Interaction, OpaqueBehavior, ProtocolStatemachine and Statemachine. This is the complete list of Behaviors defined in UML. Of course one of these Behaviors could internally call the operation, but I cannot directly assign it. Not in Papyrus and not in other UML-compliant tools. Or do you want to reuse the the entry-Behavior as method of an operation? While this is possible I fail to see why this would be useful.



        • pica

          With Papyrus you can directly assign an operation as specification of a behavior.

          Please refer to chapter “Association Ends” of the UML 2.5 specification for the definition of the association end “specification”.

          The association end “specification” is typed as “BehavioralFeature”. And an “Operation” is a specialization of the “BehavioralFeature” type.


          • Axel Scheithauer

            Yes, that is correct. The other end of this Association is “method”. So the Behavior is the method of the Operation and the Operation is the specification of the Behavior. The same Behavior could be used as entry-Behavior of a state. That would allow to specify that the Behavior can get invoked indirectly by entering the state and directly by calling the Operation. This might be useful in special cases, but I’m surprised that you deem it so important?

            Nevertheless I agree: A tool that does not allow to do this, should not be called a UML-Tool.


          • pica

            What is your way to connect state machines with class models?

          • Axel Scheithauer

            A Statemachine could specify the Behavior of the Class. In this case Transitions in this Statemachine could be triggered by the call of an Operation of the Class or the Reception of a Signal sent to the Class. And the effect of a Transition could be a Behavior that internally calls an Operation of the Class.
            Finally a Statemachine could also be the method of an Operation.
            These are all the possibilities I can think of.

          • pica

            “A Statemachine could specify the Behavior of the Class.”

            I am not aware of an association end of the class class that associates a class with a state machine. So how would you specify that association?

            “a Statemachine could also be the method of an Operation”

            same here.

            But nevertheless thanks for giving me insight. I now think I understand your way using UML better. Please correct me if I am wrong. Your approach is using UML diagrams to visualize and use free text to describe the context.

            I also used that approach up to 2002. Then I though on, if I already implemented a state machine using UML, why should I re-implement it using C, C++ or Java?

            That was my start of using the generative approach. I generate the C, C++ or Java implementation of a state machine out of the UML implementation.

            Being able to directly assign an operation as specification of a behavior allows me to connect the custom code with the generated code. The custom code implements the custom behavior to be performed on entry or exit of a state. The generated code implements the state machine itself.

            That is why this very point is really important for me.


          • Axel Scheithauer

            Everything I mentioned are formal UML-Associations. So this is not free text, but a structured model from which I could generate code. I agree that it doesn’t make sense to implement a statemachine manually, that has already been defined with UML.
            A BehavioredClassifier can have a classifierBehavior. A Class is a BehavioredClassifier and a Statemachine is a Behavior.
            A Behavior can be the method of an Operation. This Operation is then the specification of the Behavior. This allows to connect an Operation (specifies only the parameters) with a Behavior (specifies what happens).

            If I understand you right, you want to generate the Statemachine. At the same time you are generating a Class and implement the operations manually. Now you want to specify that one of the operations is called on entering a state.

            This is how I would do it: Create an OpaqueBehavior that contains C++ code that calls the Operation. Assign this as the entry-Behavior. If I can generate code from Activity Diagrams, I could alternatively use an Activity with a CallOperationAction.

            I still don’t get how you achieve this. As far as I can see it is not possible in Papyrus to assign an Operation as entry-Behavior (and should not be). The only way I can think of, is to create an empty Dummy-Behavior, assign it to the entry-Behavior and at the same time as method of an operation (making it its specification). However that would not mean, that this operation is called on entering the state. Of course you could write a generator that interprets it this way. A better way would then be to define a Stereotype for OpaqueBehavior that allows to specify an Operation.

            — Axel