Skip to main content
Jump to: navigation, search

Getting Started with Papyrus UMLLight

Revision as of 11:04, 15 May 2019 by (Talk | contribs) (Papyrus UMLLight personae.)


Getting Started with Papyrus UMLLight


As part of this tutorial, the trainee will:

  • Learn how to download and install Papyrus UMLLight.
  • Become familiar with the various aspects of the modeling environment such as workspaces, menus, views, perspectives and palettes.
  • Become familiar with the elements that make up the“Papyrus UMLLight” UML subset.
  • Through the implementation of a sample modeling project, become familiar with a simple model development approach that will enable you to use the elements that are part of the Papyrus UMLLight subset.

At the end of the training, the trainee will be able to apply their acquired knowledge in real project.

What this tutorial is and is not

what this tutorial IS What this tutorial Is NOT
An overview of the Papyrus UMLLightuser interface A UML specification tutorial (but we do talk about the UML elements we use)
An overview of the UML diagrams and elements available in Papyrus UMLLight An exhaustive tutorial on all UML diagrams, entities, and semantics
An hands-on experience developing a UML model with Papyrus UMLLight A tutorial advocating a specific method for modeling software,

Papyrus UMLLight and Papyrus

What is Papyrus

* A complete open Source model editor that Conform to UML, SysML, and other Object Management Group (OMG) standards
* [An Eclipse Project [1] where this project resides.
* A family of modeling tools:
* Papyrus itself (both tool and platform) ("Papyrus")
* Papyrus for information modeling ("Papyrus-IM")
* Papyrus for Real-time ("Papyrus-RT")
* and now Papyrus UMLLight
* [Supported by the Papyrus Industry Consortium, a community of developers, committers and contributors from many organizations and involved in different application domains.

What is Papyrus UMLLight

A specialized variant of Papyrus that provides:

* a streamlined user interface for creating, viewing, and editing models using:
* an optimized “Foundation level” subset of UML;

Comparing Papyrus and Papyrus UMLLight

Papyrus vs Papyrus UMLLight.png

Papyrus UMLLight personae.

Discussions with early stakeholders enabled the Papyrus UMLLight team to define the following three user personae, describing the users targeted by this product.

Papyrus UMLLight User personae.
Name Short Description Detailed description
Nicole a Papyrus novice, is knowledgeable in UML but not familiar with Papyrus or Papyrus UMLLight Nicole is already knowledgeable in UML at or above the OCUP2 Foundation or intermediate level contents.
As the project on which ze worked was completed, ze is being moved to a new team that uses Papyrus, a tool with which ze is not familiar.

Nicole's goal in using Papyrus UML Light is to quickly get familiar with Papyrus UML Light and how it supports UML-based modeling. Ze appreciates and benefits from Papyrus UML Light's streamlined editor with the most common concepts of UML, so that ze can focus on getting to know the Papyrus UML Light user interface and way of working without being exposed to the full spectrum of UML model elements.

Steve a student and novice in UML, Papyrus, and Papyrus UMLLight Steve is new to the modeling world and has no or very limited familiarity with the UML. Steve is starting to learn about UML and faces the dual tasks of learning to use UML at the same time as learning to use a UML modeling tool.

Using Papyrus UML Light, Steve will be exposed to fewer language and tool concepts at a time, which results in a lowering of the learning curve.,In addition, the alignment of Papyrus UML Light to OCUP2 (Foundational) is beneficial, as it ensures that ze first deals with the most most important concepts of UML before tackling the more complex aspects.

Brisha a basic UML User Brisha only uses UML from time to time and then only for basic purposes such as documentation or, presentations, discussions, etc. Ze is not interested in a full model-based engineering tool or method and rather uses it to "sketch" using UML to ensure common understanding of the graphics. As such, ze only needs the basic concepts of UML. In this context, an easy to use UML modeling tool such as Papyrus UML Light, which provides a reduced, targeted user interface and ease of use is easiest to adopt.

This product is for you! If you recognize yourself in these personae!

Installing Papyrus UMLLight

To install Papyrus UMLLight, follow these steps:

1. Ensure that you have Java 8 (or later) installed and configured for your operating system.

2. Go to:

3. The list of downloads for different operating environments will be displayed:

* Papyrus UML Light 0.0.1 RC2* for Windows 64bit
* Papyrus UML Light 0.0.1 RC2* for Linux 64bit
* Papyrus UML Light 0.0.1 RC2* for MacOS X 64bit
the version displayed on the download site may be different from the one listed above - For best results, use the most recent

4. Click on the link for your development environment to download the archive

5. Extract the executable from the downloaded archive into the proper location for your operating system.

Tip: On MacOS and some Linux, you may need to use “gunzip” followed by “tar xvf” to successfully extract the archive.

6. You are now ready to start using Papyrus UML Light!

Running Papyrus UMLLight

1. Double-click on the Papyrus UMLLight application you installed in the previous step.

2. A dialog is shown asking you to select a workspace.


About Workspaces

Workspaces are folders on your computer where your models and associated files are stored.
You can have multiple workspaces defined, but only one can be used at a time. For example, you would use different workspaces for different projects. A list of recently used Workspaces can be accessed from the above dialog by clicking on "Recent Workspaces"

1. Click on browse to select a folder that will hold your work.

2. Click “Launch” to start Papyrus UMLLight

3. The Papyrus UMLLight modeling environment's workspace is shown.



Palettes are the toolboxes of the Papyrus UMLLight modeling environment.

Palette Structure

Palette Structure.png CommonTools.png

Customized Palettes

In addition to the common tools, every Papyrus UMLLight diagram has a customized palette” containing the model elements that can be used with that diagram. You can think of it as your modeling “toolbox”. Each Papyrus UMLLight diagram’s palette is customized to meet the simplification goals of Papyrus UMLLight.

Diagram Palettes

Views of all the Papyrus UMLLight Palettes (in alphabetical order)



The "comment node" and the "comment link" are available in all palettes. This make sense as they can be used to annotate any element

Before we go any further, let's have a look at the tutorial project so we can start implementing it!

Online Shopping System (OSS) Project Overview

OSS Project goal
The goal of this tutorial is to familiarize the user with Papyrus UMLLight capabilities and the exercises are designed to meet this goal. As such, the system will not be implemented in its entirety as part of the tutorial. The skills you gain as you progress through the tutorial will enable you to complete the exercises on your own.

The Online Shopping System (OSS) is a web-based system that allows customers to

  • browse and search for products available in the catalogue and view their information;
  • Add/remove products to/from a virtual shopping cart;
  • View the content of the chopping cart;
  • Purchase shopping cart products using a Credit or an online payment service (e.g., PayPal)
  • Have the purchased items delivered.

Actors and use cases

Given these descriptions, we can deduce the following preliminary list of actors and use cases:

Actors Customer Product Manager Payment Service Product Database
Use Cases Login Add product Accept Payment Request Store product information
Find products Remove product Return payment status Store shopping carts
Add product to cart Update product
View Cart List existing products

We will further elaborate on this as we go through the creation of a model that will describes the OSS system.

Use Case Modeling

Use case modeling is about visualizing the environment and requirements of the system being built.

Therefore it is about about users, their needs, and how they interact with the system being built, as well as how the OSS system interacts with other systems.

Before We start, let's understand the main concepts of use case modeling.

Basic Use Case Diagram Concepts



The subject represents the system under consideration ("OSS" in our case) to which a set of use cases applies. As such, it also represents the boundary between our system and it's interactions with the "outside world." What is inside the subject constitutes the functionality of the system and what lies outside represent elements that interact with OSS, by providing input or services.


An Actor models a role played by an entity that interacts with the subject (e.g., by exchanging signals and data) but which is external to the subject, e.g., users accessing OSS or providing a service, e.g., an bank's payment service). As you can see, both people and external systems actors can be actors.

Use Case

A use case is the specification of a set of actions performed by the system, which yields observable results of value to one or more actors or other stakeholders of the system. { Adapted from UML Superstructure Specification, v2.4.1}.

Use cases are typically described as a sequence of steps. This sequence can be illustrated by using a sequence diagram to model the sequence of steps and can also be expressed textually (an example is provided a the end of this tutorial for those interested).


The relationships that are available to you in Papyrus UMLLight can be found in the "Links" section of the use case diagram palette and consist of:

  • Association
* The association relationship is used to link actors to the use cases affected by them.
* The association relationship, being bidirectional, does not indicate directionality and can therefore be draw in either direction.
  • Generalization
* The “Generalization” relationship is used to specify inheritance/generalization relationships between use cases or actors.
* The relationship is drawn from the specialized entity to the general entity.
  • Include: enable composition of use cases
The include relationship is used to:
* Simplify a use case by decomposing it into smaller use cases with the goal of increasing modularity and reusability.
* The include relationship is drawn from the including element to the included element.
* A use case "A" included in use case"B indicates that "B" requires "A" to accomplish its goals.
  • Extend is used to specify an optional part of a use case
* The extend relationship is drawn from the extender element to the extended element.
* a use case "C" Extends use case "D" indicates that use case "C" is an optional part of use case D.
  • Comment Link
* The comment link is used to connect a comment to the element to which the comment applies.

Modeling the OSS Use Case

The time has come to get you modeling!

Papyrus UMLLight is not running?!?
If you closed Papyrus UMLLight after looking at its workspace content earlier in the tutorial, please reopen it now!

Create and initialize the OSS Project


First, you need to create a project For your OSS model:

. From the Papyrus UMLLight main menu, select “File >New UML Light Project” to create the OSS project.

2. In the New UML Light Model Project" resulting dialog, set the project name to "OSS" 3. Note that the model name is given the same name as the project.

4. Leave the location as is (default).

New UMLLightModelProjectDialog.png

5. Click on [Next] to display the initialization dialog

6. check the box left of the "Light Use Case Diagram.

This will create an empty case diagram as part of the project creation.

New InitializeOSSwUCD.png

7, Click on "Finish"

Your project has been created and its Initialization information dialog is displayed.

New OSSProjectCreated.png

Tip: Diagram names
As you can have many diagrams based on each diagram type, it is a good idea, to rename each diagram to something more distinctive.

What was created

Before we move on, let's look at what was created...

The project Explorer

In the project explorer, There is now an entry titled "OSS" That is the project you just created as stored on disk. If you expand it, it will look like this:

Model in Project Explorer.png

The are two things you need to know about the "di", "notation", ad "uml files:

1. They contain a machine-readable serialization of your model and its notation (diagrams).

2. You must NEVER edit them directly! ... That's why Papyrus and its variants were built!

Never manually edit the project explorer files (di, notation, and model)
The only safe way to edit the model is by using Papyrus UMLLight. Trying to edit those files manually is likely to result in loss of your model!

The Model Explorer

Start by expanding the OSS Model element in the project explorer OSSModelExplorer.png by clicking on the arrow to the left of the model elements to see the content of the model.

The model elements under OSS have been created as part of the initial model creation.You can see that a "Light Use Case Diagram has been created as expected. In addition, Papyrus UMLLight also automatically includes a library of UML primitives that define data types. Those will be useful later in the tutorial.

View Synchronization
It is often useful to be able to view the same element in multiple views (e.g.the diagram, model Explorer, and Properties) to take advantage of their respective editing capabilities. The diagram and properties views are already automatically synchronized. You can do the same for the Model Explorer by using the the link to editor, double-arrow button LinkToEditor.png in its tool bar!

The workspace is now ready for the creation of the use case model


Populate the OSS Use Case Diagram

Adding the Subject

  1. In the palette, click on the Subject PUL-Subject.png and then click in the middle of the diagram to create the subject.
  2. Note that the subject object is also visible in both the model explorer and in the Properties view. Each of these views (diagram, model explorer, and property) provide a representation of the same, single model element in each of these particular contexts. Each “view” provides a set of information about that model element.
  3. Rename the subject to "OSS" by clicking on the Subject to display its properties view and, from the the properties view, change the value of the name property to "OSS". You will notice that the name also changes in the diagram and Model Explorer.
Tip: Actor locations on diagram
Actors that primarily start a use case are typically on the left of the Subject while Actors that primarily react to a use case are typically on its right (at least in "left-to-right" languages).

  1. Now Click and drag an actor from the palette to a location at the left of the subject. Drag and drop is another way to place elements on a diagram.
  2. Rename the actor to “Customer” to match the list of actors in the system.
  3. To complete this diagram, add a use case named “sign-in” to the subject and then add an association from the Customer to the use case, indicating that the customer starts the sign-in use case.
                                         The diagram should now look like this: PUL-OSSSUCDStart.png

Complete the use case diagram

Now that you know how to add use case diagram elements, Use the information from the Actors and Use Cases table to complete the use case diagram.

When done, Your use case diagram should be similar to: PUL-OSSSUCDComplete.png


Tip: Use case diagram organization
When dealing with large systems, it is a good idea to create multiple focused and easy to read use case diagrams. For example, creating a diagram for each actor helps ensure that their behaviours clear are well understood.

Documentation View

The documentation view provides a mechanism to add documentation to a model element. Although this is useful in many areas of modeling, it is very helpful when doing use case analysis at the beginning of the project where you can use this capability to add textual information to better textually describe the actors and to provide a textual description of the use cases. To show the documentation view and edit its content, right-click on a model element on a diagram and select “Show Documentation view” and the Properties view will display the documentation view.

Adding documentation to a use case

  1. Right-click on the "FindProducts" use case and select "Show Documentation View" command
  2. In the "Find Products" input, add your documentation for that use case.

Example of the documentation view.

This is an example of a use case's requirements documented with using user stories. PUL-DocumentationViewSample.png

Pervasive Documentation
Papyrus UMLLight’s documentation capability is not limited to the use case diagram! It can be used with all model elements!

Adding Structure to models

Using packages to add structure and layers to a model
  • The purpose of packages is to contain other NamedElements in order to organize a

model, typically to manage groups of similar or related model elements.

  • Examples of package usage:
* Separating common elements into logical groups
* Separating parts of the model using packages also enables reams to work in parallel on different packages (although this is out of the scope of this tutorial).
 :: An example of the use of packages can be seen in the implementation of a layered model architectures (e.g., with presentation, business, persistence layers).
* The use of packages also facilitate the visualization of a coarse level of traceability across the development lifecycle.

Package Diagram

Build a simple package diagram for a layered model development approach

Creating the package diagram

  1. Click on the model in the model explorer.
  2. From the main toolbar, Select Papyrus > “New Diagram > Light Package Diagram.
  3. Name the diagram “Packaging exercise” and click “OK”
  4. The use case diagram has been replaced by the new diagram Package in the model editor, but is still available as a tab if you need to get back to it. As you create new diagrams, they will be listed there until you close them.
  5. As well, the palette has changed to display the tools for package diagrams.
  6. Using the palette, add a package at the top left of the diagram and name it “Use Case Model
  7. Add another package below and slightly to the right of the Use Case Model package and name it “Design Model”.
  8. Draw a dependency from the left side of the Design Model package to the bottom of the Use Case Model
  9. To make the dependency look better, click in the middle of the dependency and drag left and down to make a nice elbow connector.
This dependency indicates that the “Design Model” is dependent on one or more element found in the “Use Case Model” package.
  1. In the Model Explorer, you can now the use case model elements into their UseCase model package and do the same for the design models elements into the Design package.
  2. . Your diagram and model should look similar to:

Use Case Analysis

Moving from use cases to design



Which diagrams to create?!
There are no rule that you have to create all four diagram listed above, or as to the number or kind of diagram you need to create! You do need to do enough to enable your team has a good idea of the structure and behaviour required to satisfy your your system's users

Activity and Sequence Diagrams

  • At the use case analysis level, Activity and Sequence diagrams are used to provide the bridge between the use case and the system design models.
  • Sequence diagrams and activity diagrams provide two complementary graphical views of use cases
* Activity diagrams focus on the description of the use cases as a workflow or process
* Sequence diagrams focus on the order of the message with regards to time.


Activity Diagrams

Role of Activity diagrams

At the use case level, the role of activity diagrams is to describe the use cases as a sequence of 'actions' performed by the system and the different actors

Basic Activity Diagram Concepts

Refer to the activity diagram palette for the icons associated with the following model elements.

Basic Activity Diagram Concepts
Name Description
Initial Node Acts as a starting point for executing an Activity
Input Pin Holds input values to be consumed by an Action
Output pin Holds output values produced by an Action
Value Pin Provides a value by evaluating a ValueSpecification
Opaque Action Action not specified within UML, e.g., using normal language.
Call Behavior Action Directly invokes a Behavior
Name Description
Control Flow Used to control the execution of ExecutableNodes
ObjectFlow ActivityEdge that can carry,object,tokens that may hold values

Creating an activity diagram for a customer purchase

In this exercise, you will create an activity diagram for a customer purchase.

Sequence Diagrams

This happens then that happens: Creating a sequence diagram for the Login use case

Role of sequence diagrams

  • At the use case analysis level, the role of sequence diagrams is to describe the use cases as a sequence of interactions between the system and the different actors
* Sequence diagrams also include the specification of the main internal actions executed by the system in the execution of the use cases.
  • While UML provides a rich set of concepts/notations for sequence diagrams the subset provided by Papyrus UMLLight is more than adequate for our purpose.

Basic Sequence Diagram Concepts

Refer to the sequence diagram palette for the icons associated with the following model elements.

Basic Sequence Diagram Concepts
Name Description
LifeLine A Lifeline represents a single individual participant (e.g., instance of an actor) in the sequence diagram.
Action Execution Specification The specification of a single executable unit of functionality.
Behavior Execution Specification Whereas the Action was a single unit of functionality, behaviour is a specification of events that may occur dynamically over time (e.g., an ordered set of actions.
Interaction Use Allows the reuse of an interaction from within another one. Tip: Often seen as an "include" relationship in the use case diagram.
Name Description
Sync Call Message A message generated by a synchronous call to an operation - a reply is automatically provided
Async Call Message A message generated by an asynchronous call to an operation. A reply message is not provide but is expected.
Reply message Used to reply to an Async Call Message
Create message Create a new lifeline
Delete message Delete (end) a an existing lifeline

Creating a sequence diagram for a TBD

Back to the top