Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Papyrus/Papyrus User Guide"

(Constraints in Papyrus)
(Textual Editor For Named Element)
(40 intermediate revisions by 8 users not shown)
Line 4: Line 4:
 
-->  
 
-->  
  
= Using UML modeling editors  =
+
= Using modeling editors  =
  
 
== UML modeling  ==
 
== UML modeling  ==
Line 130: Line 130:
 
==== Create and edit constraints ====
 
==== Create and edit constraints ====
  
===== Define a constraint and its context =====
+
[[Papyrus/UserGuide/Papyrus Constraints|Create and edit constraints]]
 
+
Papyrus supports the creation of UML constraints. To create a constraint, and associated context, do one of the following:
+
 
+
* Within any Papyrus diagram select the constraint tool from the palette and then press the mouse button at the position where you want to create the constraint on the diagram canvas. The constraint should then be connected to another element on the diagram, via a ContextLink relationship, by clicking on the target element in the diagram (in two-click mode). If you are in one-click-mode (connection tool preference), press the mouse button on the constraint and keep it pressed until the context object is selected. This ContextLink relationship defines the context for which the constraint will be evaluated.
+
 
+
<center>
+
[[Image:Constraint_CreateViaDiagram.png]]&nbsp;&nbsp;&nbsp;[[Image:Constraint_ContextViaDiagram.png]]<br>
+
The constraint and context-link tools in the palette
+
</center>
+
 
+
* Within the Model Explorer via right clicking a model element and then selecting New Child -> Create a new Constraint. The context is automatically set to the parent of the constraint. The context can be changed via the Properties View if required.<br>
+
 
+
<center>
+
[[Image:Constraint_CreateViaME.png]]<br>
+
Create a constraint via the model explorer
+
</center>
+
 
+
<center>
+
[[Image:Constraint_ContextViaPropertyView.png]]<br>
+
Set the context via the property view
+
</center>
+
 
+
===== Define constraint specification =====
+
 
+
Each constraint has a specification containing a condition. Whereas it may be an arbitrary value specification, such as a StringExpression or LiteralInteger, it is in most cases useful to define an opaque expression consisting of a pair of language and body (a list of these pairs). The constraint body may be written in at least OCL, JAVA, or natural language. In order to make constraints evaluable by Papyrus the constraint must be written in either OCL or JAVA. To define a constraint's specification, first select a constraint on either a diagram or in the Model Explorer, then do the following:
+
 
+
* On the diagram open the default editor for constraints using the keyboard shortcut F2 or with a second click on an already selected constraint. The editor assume the language is OCL but this can be changed later via the Properties View. The constraint text is defined directly in the editor. The default editor can be controlled via the preferences.
+
 
+
* On the diagram select a specific editor via the context menu, as shown in the following screenshot.
+
 
+
<center>
+
[[Image:Constraint_ChooseEditor.png]]<br>
+
Explicitly choose the editor for the constraint
+
</center>
+
 
+
Use the property view to create a new or open an existing specification, as shown in the following figure.
+
In the sequel, we assume that the specification is an opaque expression.
+
 
+
<center>
+
[[Image:Constraint_SpecViaPropertyView.png]]<br>
+
Open the specification via the property view
+
</center>
+
 
+
You can add the language, as in the following figure:<br>
+
 
+
<center>
+
[[Image:Constraint_OpaqueExpressionAddLang.png]]<br>
+
Specify a language.
+
</center>
+
 
+
<center>
+
[[Image:Constraint_OpaqueExpressionEdit.png]]<br>
+
Write the body of the opaque expression
+
</center>
+
 
+
This method is a bit more complicated, but gives the user full control over the opaque specification. In particular,
+
it is possible to enter more than one language, body pair (even if this is rarely needed).
+
  
 
==== Validate OCL Constraints of a Profile ====
 
==== Validate OCL Constraints of a Profile ====
  
Papyrus supports an additional profile for defining Domain Specific Modeling Languages (DSML) that refines how constraints are validated.
+
[[Papyrus/UserGuide/Profile Constraints|Define Profile Constraints]]
The additional profile enables a more precise specification of validation properties, for example:
+
•Mode: Defines if the validation of the constraint is done in “batch” or “live” mode
+
•Severity: Defines the severity of the constraint violation. It can be one of INFORMATION, WARNING or ERROR. The latter is the default severity (if none is specified). The CANCEL severity should be used with caution, as it causes the validation operation to be interrupted, possibly resulting in the loss of valuable diagnostic information from other constraints.
+
•Message: Defines the message that will be displayed if the constraint is violated
+
•Description: Provides a description of the constraint •Enabled by default: Defined if this constraint should be enabled by default or not
+
 
+
CAVEAT: The information added via the profile using the DSML profile is not currently taken into account during OCL validation. The support will be added soon.
+
 
+
Advanced users can also define:
+
• Id: The constraint id
+
• Status code: The plug-in unique status code, useful for logging.
+
•The target of validation, the element to be validated
+
 
+
How to apply the DSML validation profile:
+
1.Select the profile root and apply the profile
+
 
+
2.Select the profile tab in the property view
+
  
3.Click on the registered profile button
+
=== Working with Profiles ===
  
4.Select the "DSML Validation" profile
+
==== Externalized Profile Applications ====
  
<center>
+
[[Papyrus/UserGuide/Externalized Profile Applications|Managing profile applications separately from the applying models]]
[[Image:DSML-profileApplication.png]]<br>
+
Open the specification via the property view
+
</center>
+
 
+
5.Select the constraint
+
 
+
6.Select the profile tab of the property view
+
7.Click on the apply profile button
+
8.Select the ValidationRule stereotype
+
 
+
<center>
+
[[Image:DSML-stereotypeApplication.png]]<br>
+
Open the specification via the property view
+
</center>
+
 
+
You can then edit the stereotype attribute to define information about the behavior of the validation.
+
 
+
===== Generation from Constraints =====
+
 
+
Constraints expressed in OCL can be validated directly in the tool. This is not the case for Java constraints which must be placed in a suitable plugin. However, Papyrus supports the generation of this plugin.
+
 
+
Generate constraints directly into the definition
+
 
+
Constraints written in OCL within the profile can be generated into the definition of the profile and read during the validation of the model.
+
 
+
How to
+
 
+
When you save the profile, Papyrus asks to you if want to define the profile.
+
Click on yes and then assure that the "Save OCL constraint into the definition" button is active (which is the case by default)
+
  
 
== SysML Modeling  ==
 
== SysML Modeling  ==
Line 294: Line 191:
 
== Layer Support  ==
 
== Layer Support  ==
 
See [[Papyrus/UserGuide/Layers|Layers Guide]]
 
See [[Papyrus/UserGuide/Layers|Layers Guide]]
 +
 +
== Model Execution ==
 +
[[Papyrus/UserGuide/ModelExecution|Execute your fUML models with MOKA]]
  
 
== Automatic Layout Support  ==
 
== Automatic Layout Support  ==
Line 299: Line 199:
 
== Code Generation Support  ==
 
== Code Generation Support  ==
  
=== JAVA Code Generation  ===
+
=== Existing Code Generation Facilities ===
 +
Currently, Papyrus supports code generation for the following programming languages:
 +
* [http://wiki.eclipse.org/Java_Code_Generation Java code generation]
 +
* [http://wiki.eclipse.org/Papyrus/Codegen/Cpp_description C++ code generation]
  
=== C/C++ Code Generation  ===
+
=== Upcoming Code Generation Facilities ===
 +
Papyrus is going to support code generation for the following programming languages, which are in the experimental phase now, soon:
 +
* ADA code generation
 +
* C code generation
  
see [http://wiki.eclipse.org/Codegen_description Papyrus C++ code generation]
+
=== Adding a New Code Generator ===
 +
Apart from the aforementioned programming language, it is also possible to develop and integrate other code generators to Papyrus.
 +
To learn about how to add a new code generator to Papyrus, refer to the following [http://wiki.eclipse.org/Papyrus/Codegen/Adding_a_New_Code_Generator wikipage].
  
=== ADA Code Generation  ===
+
== Reverse Engineering ==
 +
 
 +
=== Java Reverse Engineering ===
 +
 
 +
see [http://wiki.eclipse.org/Java_reverse_engineering Java reverse engineering]
  
 
== Documentation Support  ==
 
== Documentation Support  ==
Line 312: Line 224:
  
 
=== Documentation Generation ===
 
=== Documentation Generation ===
 +
 +
== Deploy your applications ==
 +
 +
see [http://wiki.eclipse.org/Papyrus_Qompass Qompass for Papyrus]
  
 
[[Category:Papyrus]]
 
[[Category:Papyrus]]
 +
 +
= General Feature =
 +
 +
== Editors ==
 +
=== Palette ===
 +
The palette is available with any diagrams. But its content depends on the diagrams type.
 +
The standard palette ( the top container of the palette in red in the here-after capture) contents a standard selection tool (the white arrow), a zoom in and zoom out tool, and marquee selection tools.<br/>
 +
[[File:Palette1.JPG]] <br/>
 +
The standard palette is available for every diagram.
 +
==== Properties ====
 +
 +
See [http://wiki.eclipse.org/Papyrus_User_Guide/Palette/Properties Properties]
 +
 +
==== Standard Selection tool ====
 +
 +
See [http://wiki.eclipse.org/Papyrus_User_Guide/Palette/Standard_Selection_Tool Standard selection Tool]
 +
 +
==== Zoom Tools ====
 +
See [http://wiki.eclipse.org/Papyrus_User_Guide/Palette/Zoom_Tools Zoom Tools]
 +
 +
==== Marquee Selection Tools====
 +
See [http://wiki.eclipse.org/Papyrus_User_Guide/Palette/Marquee_Selection_Documentation Marquee Selection Tool]
 +
 +
=== Toolbars ===
 +
Papyrus has its own set of Toolbars. A Toolbar regroups a set of tools belonging to the same kind of activity.
 +
The different Toolbars can be shown or hide depending on the perspectives. <br/>
 +
The toolbars visibility can be customized from the menu Windows/Customize Perspectives. <br/>
 +
[[File:Customize_Perspective.JPG|frame|center|Alignment Perpective]]
 +
 +
==== Alignment ====
 +
See [http://wiki.eclipse.org/Papyrus_User_Guide/Toolbars/Alignment Alignment]
 +
 +
====Text alignment ====
 +
See [http://wiki.eclipse.org/Papyrus_User_Guide/Toolbars/TextAlignment Text alignment]
 +
 +
--[[User:Celine.Janssens.all4tec.net|Céline Janssens &#91;ALL4TEC&#93;]] ([[User talk:Celine.Janssens.all4tec.net|talk]]) 12:06, 28 August 2014 (EDT)
 +
[[Category:Papyrus]]
 +
 +
=Embedded Editors=
 +
Papyrus provides embedded editors to edit UML Elements. Of course these editors allows to edit the name of the elements, but they allow to edit much more than this.
 +
 +
==UML ValueSpecification editor==
 +
This editor allows to edit UMLValueSpecification. ValueSpecifications are used to define the default value of a Property or to define the multiplicity of a MultiplicityElement (lower and upper values).
 +
Papyrus provides an Xtext Editor for UML ValueSpecification. This editor provides completion (CTRL+SPACE) to help the user to define the value to set crossing easily the model.
 +
 +
You can use this editors in Papyrus table or in papyrus Property View for example.
 +
 +
The developer documentation for this editors is available [[Papyrus_Developer_Guide/Papyrus_Embedded_Editors_Documentation/Value_Specification_Xtext_editor#Parser_definition|here]].
 +
===Usage===
 +
The default grammar of the XText parser for the Value Specification is the following:
 +
 +
<code><nowiki>(visibility)? (name'=')? value</nowiki></code>
 +
 +
The values accepted for the differents attributes are the following:
 +
{| class="wikitable"
 +
! style="width:20%" | Attribute
 +
! style="width:10%" | Required
 +
! style="width:60%" | Values accepted
 +
|-
 +
| '''visibility'''
 +
| align="center" | No
 +
|
 +
* <code>+</code> (public)
 +
* <code>#</code> (protected)
 +
* <code>~</code> (package)
 +
* <code>-</code> (private)
 +
|-
 +
| '''name'''
 +
| align="center" | No
 +
| String representing an ID (i.e. XText grammar: <code>'^'?('a'..'z'&#124;'A'..'Z'&#124;'_') ('a'..'z'&#124;'A'..'Z'&#124;'_'&#124;'0'..'9')*</code>)
 +
|-
 +
| '''value'''
 +
| align="center" | Yes
 +
|
 +
* <code>true</code> or <code>false</code> (<code>LiteralBoolean</code>)
 +
* positive integer (<code>LiteralUnlimitedNatural</code>)
 +
* negative integer (<code>LiteralInteger</code>)
 +
* double (<code>LiteralReal</code>)
 +
* <code>null</code> (<code>LiteralNull</code>)
 +
* String with quote (<code>LiteralSting</code>). The quote (') is essential for 2 reasons:
 +
** The XText parser cannot define the difference between the name representing an <code>InstanceSpecification</code> and a simple string value
 +
** A Non-valid value won't be defined as an <code>OpaqueExpression</code> without quote but always as a <code>LiteralString</code> value
 +
* Instance Specification name (<code>InstanceValue</code>)
 +
* <code><Undefined></code> or empty (<code>null</code>)
 +
|}
 +
 +
If the text filled is not compatible with the grammar of XText parser, an <code>OpaqueExpression</code> will be created.
 +
 +
 +
The XText parser for Value Specification is not restrictive with the text filled, i.e. the different features setted on an existing Value Specification will be kept if possible.
 +
 +
For example: If an existing Value Specification is a <code>LiteralBoolean</code> named 'testBoolean' with the visibility 'public' and the value setted to <code>true</code>, the text <code>+testBoolean=false</code> and <code>false</code> have the same result: the value of <code>LiteralBoolean</code> existing will pass to <code>false</code> (the name and the visilibity don't change).
 +
 +
 +
The XText parser reacts differently instead of the type of the Value Specification's container:
 +
 +
====Example: Without defined type on Value Specification's container====
 +
 +
If the type of Value Specification's container is not defined, the default behaviour will be applied.
 +
 +
Here, some examples:
 +
{| class="wikitable"
 +
! style="width:15%" rowspan="2" | Text filled
 +
! style="width:20%" rowspan="2" | Namely
 +
! style="width:65%" rowspan="1" colspan="4" | Created ValueSpecification
 +
|-
 +
! style="width:15%" rowspan="1" colspan="1" | Type
 +
! style="width:8%" rowspan="1" colspan="1" | Visibility
 +
! style="width:15%" rowspan="1" colspan="1" | Name
 +
! style="width:27%" rowspan="1" colspan="1" | Value
 +
|-
 +
| rowspan="2" | +testInstanceValue=InstanceSpec1
 +
| 'InstanceSpec1' is an <code>InstanceSpecification</code> existing in the model
 +
| <code>InstanceValue</code>
 +
| public
 +
| testInstanceValue
 +
| 'instance' attribute of <code>InstanceValue</code> is a reference to the existing <code>InstanceSpecification</code> named 'InstanceSpec1'
 +
|-
 +
| No <code>InstanceSpecification</code> exist in the model
 +
| <code>OpaqueExpression</code>
 +
| public
 +
| +testInstanceValue=InstanceSpec1
 +
|
 +
|-
 +
| +testBoolean=true
 +
|
 +
| <code>LiteralBoolean</code>
 +
| public
 +
| testBoolean
 +
| <code>true</code>
 +
|-
 +
| #testUnlimitedNatural=5
 +
|
 +
| <code>LiteralUnlimitedNatural</code>
 +
| protected
 +
| testUnlimitedNatural
 +
| 5
 +
|-
 +
| ~testInteger=-8
 +
|
 +
| <code>LiteralInteger</code>
 +
| package
 +
| testInteger
 +
| -8
 +
|-
 +
| -testReal=12.34
 +
|
 +
| <code>LiteralReal</code>
 +
| private
 +
| testReal
 +
| 12.34
 +
|-
 +
| ~testNull=null
 +
|
 +
| <code>LiteralNull</code>
 +
| package
 +
| testNull
 +
| <code>null</code>
 +
|-
 +
| -testString="foo"
 +
|
 +
| <code>LiteralString</code>
 +
| private
 +
| testString
 +
| foo
 +
|-
 +
| ##testString="foo"
 +
|
 +
| <code>OpaqueExpression</code>
 +
| public
 +
| ##testString="foo"
 +
|
 +
|}
 +
 +
====Example: With defined type on Value Specification's container====
 +
 +
If the type of Value Specification's container is setted, the same text filled will be have different behaviour depending to the type. In fact, the value filled must be consistent to the type, otherwise an <code>OpaqueExpression</code> will be created.
 +
 +
The different types corresponding to <code>LiteralSpecification</code> are the following:
 +
{| class="wikitable"
 +
! style="width:50%" | LiteralSpecification
 +
! style="width:50%" | Types corresponding
 +
|-
 +
| <code>LiteralBoolean</code>
 +
|
 +
* JavaPrimitiveTypes::boolean
 +
* EcorePrimitiveTypes::EBoolean
 +
* EcorePrimitiveTypes::EBooleanObject
 +
* PrimitiveTypes::Boolean
 +
* XMLPrimitiveTypes::Boolean
 +
* XMLPrimitiveTypes::BooleanObject
 +
|-
 +
| <code>LiteralUnlimitedNatural</code>
 +
|
 +
* PrimitiveTypes::UnlimitedNatural
 +
|-
 +
| <code>LiteralInteger</code>
 +
|
 +
* JavaPrimitiveTypes::int
 +
* EcorePrimitiveTypes::EInt
 +
* EcorePrimitiveTypes::EIntegerObject
 +
* PrimitiveTypes::Integer
 +
* XMLPrimitiveTypes::Int
 +
* XMLPrimitiveTypes::Integer
 +
* XMLPrimitiveTypes::IntObject
 +
|-
 +
| <code>LiteralReal</code>
 +
|
 +
* JavaPrimitiveTypes::double
 +
* EcorePrimitiveTypes::EDouble
 +
* EcorePrimitiveTypes::EDoubleObject
 +
* PrimitiveTypes::Real
 +
* XMLPrimitiveTypes::Double
 +
* XMLPrimitiveTypes::DoubleObject
 +
|-
 +
| <code>LiteralString</code>
 +
|
 +
* EcorePrimitiveTypes::EString
 +
* PrimitiveTypes::String
 +
* XMLPrimitiveTypes::String
 +
|}
 +
 +
Here, some examples:
 +
{| class="wikitable"
 +
! style="width:15%" rowspan="2" | Text filled
 +
! style="width:20%" rowspan="2" | Value Specification's container type
 +
! style="width:65%" rowspan="1" colspan="4" | Created ValueSpecification
 +
|-
 +
! style="width:15%" rowspan="1" colspan="1" | Type
 +
! style="width:8%" rowspan="1" colspan="1" | Visibility
 +
! style="width:15%" rowspan="1" colspan="1" | Name
 +
! style="width:27%" rowspan="1" colspan="1" | Value
 +
|-
 +
| rowspan="2" | +testBoolean=true
 +
| PrimitiveTypes::Boolean
 +
| <code>LiteralBoolean</code>
 +
| public
 +
| testBoolean
 +
| <code>true</code>
 +
|-
 +
| PrimitiveTypes::Integer
 +
| <code>OpaqueExpression</code>
 +
| public
 +
| +testBoolean=true
 +
|
 +
|-
 +
| rowspan="4" | -testUnlimitedNatural=8
 +
| PrimitiveTypes::UnlimitedNatural
 +
| <code>LiteralUnlimitedNatural</code>
 +
| private
 +
| testUnlimitedNatural
 +
| 8
 +
|-
 +
| PrimitiveTypes::Integer
 +
| <code>LiteralInteger</code>
 +
| private
 +
| testUnlimitedNatural
 +
| 8
 +
|-
 +
| PrimitiveTypes::Real
 +
| <code>LiteralReal</code>
 +
| private
 +
| testUnlimitedNatural
 +
| 8.0
 +
|-
 +
| PrimitiveTypes::Boolean
 +
| <code>OpaqueExpression</code>
 +
| public
 +
| -testUnlimitedNatural=8
 +
|
 +
|-
 +
| rowspan="4" | #testInteger=-6
 +
| PrimitiveTypes::UnlimitedNatural
 +
| <code>OpaqueExpression</code>
 +
| public
 +
| #testInteger=6
 +
|
 +
|-
 +
| PrimitiveTypes::Integer
 +
| <code>LiteralInteger</code>
 +
| protected
 +
| testInteger
 +
| 6
 +
|-
 +
| PrimitiveTypes::Real
 +
| <code>LiteralReal</code>
 +
| protected
 +
| testInteger
 +
| 6.0
 +
|-
 +
| PrimitiveTypes::Boolean
 +
| <code>OpaqueExpression</code>
 +
| public
 +
| #testInteger=6
 +
|
 +
|-
 +
| rowspan="3" | -testReal=4.5
 +
| PrimitiveTypes::Integer
 +
| <code>OpaqueExpression</code>
 +
| public
 +
| -testReal=4.5
 +
|
 +
|-
 +
| PrimitiveTypes::Real
 +
| <code>LiteralReal</code>
 +
| private
 +
| testReal
 +
| 4.5
 +
|}
 +
 +
==Textual Editor For Named Element==
 +
Since Papyrus 1.1.0 (Eclipse Mars), Papyrus provides a new texutal editor to edit references to UML NamedElement. This editor works only for references which are not in containment. This editor has not been developed using XText. It use a custom string parser and provide a completion (CTRL+SPACE) to help the user to find the named elements to reference in the model.
 +
 +
You can use this editor in Property View or in Papyrus table for example.
 +
Developer documentation is available [[Papyrus_Developer_Guide/Papyrus_Embedded_Editors_Documentation/Textual_Editor_For_NamedElement|here]].
 +
 +
===Usage===
 +
* This editors allows to find named element typing its name.
 +
* In case of several elements to found, the separator to use is the comma </code>'</code>
 +
* If the name of the element contains a comma, you should prefix and suffix its name by a quote <code>'</code>.
 +
* The value will not be set if the element can't be found is the model
 +
 +
===Example===
 +
If you have 3 Classes in your model, named <code>Class1</code>, <code>Class2</code> and <code>Clas,s3</code>.
 +
{| class="wikitable"
 +
! style="font-weight: bold;" | typed text
 +
! style="font-weight: bold;" | completion proposal
 +
! style="font-weight: bold;" | explanation
 +
|-
 +
| empty string
 +
| <Undefined>, ...
 +
| we look for nothing, so we provide the <code><Undefined></code> value and <code>...</code> to ask to the user to write more text
 +
|-
 +
| Clas
 +
| <Undefined>,Class1,Class2,Clas,s3
 +
| 3 classes matches the string, <code><Undefined></code> is always proposed
 +
|-
 +
| Class
 +
| <Undefined>,Class1,Class2
 +
| 3 classes matches the string, <Undefined>is always proposed
 +
|-
 +
| 'Clas
 +
| <Undefined>, Clas,s3
 +
| the string starts with a quote and Clas,s3 contains a comma, so we propose <code>Clas,s3</code>; <code><Undefined></code> is always proposed
 +
|-
 +
| Clas,
 +
| <Undefined>,...
 +
| interpreted as a list of value, the first value is </code>Clas</code>, and we have no information for the second one, for the completion it is an empty string
 +
|}

Revision as of 10:45, 25 March 2015


Contents

Using modeling editors

UML modeling

Getting Started

Papyrus Perspective

The Papyrus perspective contains :

  • Model Explorer view
  • Outline view
  • Multi diagram editor view
  • Properties view
  • Toolbar

Papyrus Perspective.png

Model Explorer View

The model explorer is used to navigate to the all model's elements and the diagrams.

Papyrus ModelExplorer.png

This action link the model explorer with the active diagram selection. This action works bidirectionally.

Papyrus ME Sync.png

This action allow to add new semantic element.

Papyrus ME NewChild.png

This action allow to add new diagram in current selection.

Papyrus ME NewDiagram.png

All actions are available on diagram item.

Papyrus ME DiagramMenu.png

The model explorer used Common Navigator Framework and provide facilities to customize view.

Papyrus ME CustomizeView.png

To customize the content of treeViewer:

Papyrus ME CustomizeView Content.png

To filter the content of treeViewer:

Papyrus ME CustomizeView Filters.png

Outline View

The Outline offers a thumbnail of the graphical representation and the list of semantic elements used in current diagram.

Papyrus OutLine.pngPapyrus OutLine All.pngPapyrus OutLine Tree.png

Tutorials on UML modeling with Papyrus

Model/Diagram creation wizard

Create a new Model.

Papyrus CreateNewModel.png


Choose the model file name and the first diagram to create.

Papyrus CreateNewModel-2.png Papyrus CreateNewModel-3.png

Create a diagram from an existing uml file

From your uml file, select the "Initialize Papyrus diagram" to access the creation wizard of Papyrus. Your Papyrus diagram will be linked with your existing model.

CreateDiagramFromModel.PNG


Apply a static profile
  • 1 - Select a package element (ie a Model or a Package).
  • 2 - Select the tab "Profile" on the "Properties" view
  • 3 - Click on the plug-in icon
  • 4 - Select your static profile
  • 5 - Choose profiles to apply

PapyrusApplyStaticProfil.PNG

Load an additionnal resource
Show additional resources in your model explorer view

Ensure that the filter for the additional resources is not checked on your model explorer view : PapyrusFilterAdditionalResources.PNG

Add an additional resource

Right click on an element of your model and select the menu "Load resource..."

PapyrusLoadResources.PNG


Table Documentation

See http://wiki.eclipse.org/Papyrus_User_Guide/Table_Documentation

Papyrus Zoo of UML Models

Composite Structure Diagram

CompositeSupport.PNG

The project is available here [1]

Constraints in Papyrus

Create and edit constraints

Create and edit constraints

Validate OCL Constraints of a Profile

Define Profile Constraints

Working with Profiles

Externalized Profile Applications

Managing profile applications separately from the applying models

SysML Modeling

Tutorials on SysML modeling with Papyrus

Papyrus Zoo of SysML Models

MARTE Modeling

Tutorials on MARTE modeling with Papyrus

Papyrus Zoo of MARTE Models

fUML and Alf Modeling

Using fUML and Alf to produce executable models

Developing custom DSL based editor with Papyrus

UML Profile Modeling

Define Profile Constraints

MetaModel Modeling

Additional Editor Integration (this section is for the Backone)

Diagram Editors Customizations

Specific Diagram Editors Creation

Diagram Editor Palette Customization

Here you can find the documentation describing palette customization: Doc

This document can also be found in Papyrus help section => User Guide => Palette customization

Property Editor Customization

Model Explorer Customization

Diagram Appearance Customization with CSS Stylesheets

CSS Stylesheets in Papyrus

Additional Utilities of Papyrus

Collaborative Work Support

Layer Support

See Layers Guide

Model Execution

Execute your fUML models with MOKA

Automatic Layout Support

Code Generation Support

Existing Code Generation Facilities

Currently, Papyrus supports code generation for the following programming languages:

Upcoming Code Generation Facilities

Papyrus is going to support code generation for the following programming languages, which are in the experimental phase now, soon:

  • ADA code generation
  • C code generation

Adding a New Code Generator

Apart from the aforementioned programming language, it is also possible to develop and integrate other code generators to Papyrus. To learn about how to add a new code generator to Papyrus, refer to the following wikipage.

Reverse Engineering

Java Reverse Engineering

see Java reverse engineering

Documentation Support

Documentation Modelling

Documentation Generation

Deploy your applications

see Qompass for Papyrus

General Feature

Editors

Palette

The palette is available with any diagrams. But its content depends on the diagrams type. The standard palette ( the top container of the palette in red in the here-after capture) contents a standard selection tool (the white arrow), a zoom in and zoom out tool, and marquee selection tools.
Palette1.JPG
The standard palette is available for every diagram.

Properties

See Properties

Standard Selection tool

See Standard selection Tool

Zoom Tools

See Zoom Tools

Marquee Selection Tools

See Marquee Selection Tool

Toolbars

Papyrus has its own set of Toolbars. A Toolbar regroups a set of tools belonging to the same kind of activity. The different Toolbars can be shown or hide depending on the perspectives.
The toolbars visibility can be customized from the menu Windows/Customize Perspectives.

Alignment Perpective

Alignment

See Alignment

Text alignment

See Text alignment

--Céline Janssens [ALL4TEC] (talk) 12:06, 28 August 2014 (EDT)

Embedded Editors

Papyrus provides embedded editors to edit UML Elements. Of course these editors allows to edit the name of the elements, but they allow to edit much more than this.

UML ValueSpecification editor

This editor allows to edit UMLValueSpecification. ValueSpecifications are used to define the default value of a Property or to define the multiplicity of a MultiplicityElement (lower and upper values). Papyrus provides an Xtext Editor for UML ValueSpecification. This editor provides completion (CTRL+SPACE) to help the user to define the value to set crossing easily the model.

You can use this editors in Papyrus table or in papyrus Property View for example.

The developer documentation for this editors is available here.

Usage

The default grammar of the XText parser for the Value Specification is the following:

(visibility)? (name'=')? value

The values accepted for the differents attributes are the following:

Attribute Required Values accepted
visibility No
  • + (public)
  • # (protected)
  • ~ (package)
  • - (private)
name No String representing an ID (i.e. XText grammar: '^'?('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'_'|'0'..'9')*)
value Yes
  • true or false (LiteralBoolean)
  • positive integer (LiteralUnlimitedNatural)
  • negative integer (LiteralInteger)
  • double (LiteralReal)
  • null (LiteralNull)
  • String with quote (LiteralSting). The quote (') is essential for 2 reasons:
    • The XText parser cannot define the difference between the name representing an InstanceSpecification and a simple string value
    • A Non-valid value won't be defined as an OpaqueExpression without quote but always as a LiteralString value
  • Instance Specification name (InstanceValue)
  • <Undefined> or empty (null)

If the text filled is not compatible with the grammar of XText parser, an OpaqueExpression will be created.


The XText parser for Value Specification is not restrictive with the text filled, i.e. the different features setted on an existing Value Specification will be kept if possible.

For example: If an existing Value Specification is a LiteralBoolean named 'testBoolean' with the visibility 'public' and the value setted to true, the text +testBoolean=false and false have the same result: the value of LiteralBoolean existing will pass to false (the name and the visilibity don't change).


The XText parser reacts differently instead of the type of the Value Specification's container:

Example: Without defined type on Value Specification's container

If the type of Value Specification's container is not defined, the default behaviour will be applied.

Here, some examples:

Text filled Namely Created ValueSpecification
Type Visibility Name Value
+testInstanceValue=InstanceSpec1 'InstanceSpec1' is an InstanceSpecification existing in the model InstanceValue public testInstanceValue 'instance' attribute of InstanceValue is a reference to the existing InstanceSpecification named 'InstanceSpec1'
No InstanceSpecification exist in the model OpaqueExpression public +testInstanceValue=InstanceSpec1
+testBoolean=true LiteralBoolean public testBoolean true
#testUnlimitedNatural=5 LiteralUnlimitedNatural protected testUnlimitedNatural 5
~testInteger=-8 LiteralInteger package testInteger -8
-testReal=12.34 LiteralReal private testReal 12.34
~testNull=null LiteralNull package testNull null
-testString="foo" LiteralString private testString foo
##testString="foo" OpaqueExpression public ##testString="foo"

Example: With defined type on Value Specification's container

If the type of Value Specification's container is setted, the same text filled will be have different behaviour depending to the type. In fact, the value filled must be consistent to the type, otherwise an OpaqueExpression will be created.

The different types corresponding to LiteralSpecification are the following:

LiteralSpecification Types corresponding
LiteralBoolean
  • JavaPrimitiveTypes::boolean
  • EcorePrimitiveTypes::EBoolean
  • EcorePrimitiveTypes::EBooleanObject
  • PrimitiveTypes::Boolean
  • XMLPrimitiveTypes::Boolean
  • XMLPrimitiveTypes::BooleanObject
LiteralUnlimitedNatural
  • PrimitiveTypes::UnlimitedNatural
LiteralInteger
  • JavaPrimitiveTypes::int
  • EcorePrimitiveTypes::EInt
  • EcorePrimitiveTypes::EIntegerObject
  • PrimitiveTypes::Integer
  • XMLPrimitiveTypes::Int
  • XMLPrimitiveTypes::Integer
  • XMLPrimitiveTypes::IntObject
LiteralReal
  • JavaPrimitiveTypes::double
  • EcorePrimitiveTypes::EDouble
  • EcorePrimitiveTypes::EDoubleObject
  • PrimitiveTypes::Real
  • XMLPrimitiveTypes::Double
  • XMLPrimitiveTypes::DoubleObject
LiteralString
  • EcorePrimitiveTypes::EString
  • PrimitiveTypes::String
  • XMLPrimitiveTypes::String

Here, some examples:

Text filled Value Specification's container type Created ValueSpecification
Type Visibility Name Value
+testBoolean=true PrimitiveTypes::Boolean LiteralBoolean public testBoolean true
PrimitiveTypes::Integer OpaqueExpression public +testBoolean=true
-testUnlimitedNatural=8 PrimitiveTypes::UnlimitedNatural LiteralUnlimitedNatural private testUnlimitedNatural 8
PrimitiveTypes::Integer LiteralInteger private testUnlimitedNatural 8
PrimitiveTypes::Real LiteralReal private testUnlimitedNatural 8.0
PrimitiveTypes::Boolean OpaqueExpression public -testUnlimitedNatural=8
#testInteger=-6 PrimitiveTypes::UnlimitedNatural OpaqueExpression public #testInteger=6
PrimitiveTypes::Integer LiteralInteger protected testInteger 6
PrimitiveTypes::Real LiteralReal protected testInteger 6.0
PrimitiveTypes::Boolean OpaqueExpression public #testInteger=6
-testReal=4.5 PrimitiveTypes::Integer OpaqueExpression public -testReal=4.5
PrimitiveTypes::Real LiteralReal private testReal 4.5

Textual Editor For Named Element

Since Papyrus 1.1.0 (Eclipse Mars), Papyrus provides a new texutal editor to edit references to UML NamedElement. This editor works only for references which are not in containment. This editor has not been developed using XText. It use a custom string parser and provide a completion (CTRL+SPACE) to help the user to find the named elements to reference in the model.

You can use this editor in Property View or in Papyrus table for example. Developer documentation is available here.

Usage

  • This editors allows to find named element typing its name.
  • In case of several elements to found, the separator to use is the comma </code>'</code>
  • If the name of the element contains a comma, you should prefix and suffix its name by a quote '.
  • The value will not be set if the element can't be found is the model

Example

If you have 3 Classes in your model, named Class1, Class2 and Clas,s3.

typed text completion proposal explanation
empty string <Undefined>, ... we look for nothing, so we provide the <Undefined> value and ... to ask to the user to write more text
Clas <Undefined>,Class1,Class2,Clas,s3 3 classes matches the string, <Undefined> is always proposed
Class <Undefined>,Class1,Class2 3 classes matches the string, <Undefined>is always proposed
'Clas <Undefined>, Clas,s3 the string starts with a quote and Clas,s3 contains a comma, so we propose Clas,s3; <Undefined> is always proposed
Clas, <Undefined>,... interpreted as a list of value, the first value is </code>Clas</code>, and we have no information for the second one, for the completion it is an empty string

Back to the top