Basically, the developement rules are the same than for Papyrus.
The recommendation are almost the same than for Papyrus. We reuse its Code Style configurations for Clean Up and Formatter. Concerning the Code Templates, we did these changes:
These 3 templates files are stored into the git org.eclipse.papyrus-sirius, into the folder releng-sirius/templates.
We provide pre-configured preferences files to copy in the .settings folder (it is a hidden folder by default) in each new plugin. There are 6 files to copy:
These preferences files can be copied from releng-sirius/preferences into the .setting folder of your new plugin.
Add your user name as vmargs argument like that in order to get a nice file header for the new creted file:
-vmargs
-Duser.name=John Doe (Company) <john.doe@company.com>
Rules:
This framework has been developed to be used only when a sirius diagram is opened.
The Papyrus user is used to non-synchronized diagrams. Hence, while developing the Sirius Diagram, we must consider them as not synchronized by default. We advise you to set the Sirius synchronization preferences to false and to show the synchronization marker to always display the status (synchronized/unsynchronized) of the diagram.
To ease development and review, we decided to follow conception rules for odesign file:
Developing the class diagram it appeared that it is often easier to call a java service instead of writing aql rules. As we created the same methods for each semantic element, we follow a common pattern for the naming of these methods. Each method must be prefixed by the managed metaclass (see org.eclipse.papyrus.sirius.uml.diagram.clazz.services.ClassDiagramServices). For the UML::Abstraction we have these methods:
NB: Currently these methods, for each UML Element, are in the ClassDiagramServices. In the future, we will probably create a java class for each semantic element, and the ClassDiagramServices will delegate to these classes. This point is still open for a discussion, because we are also thinking about a connection to the Papyrus Edition Service and it could be redundant.
To be able to represent UML Elements located outside of the diagram context, we created specific mappings. These mappings are defined as Not Synchronized in order to avoid to reveal all outside elements on the diagram when the user uses a Synchronized diagram. To get the expected result, we created:
In addition, we propose a specific appearance to these elements:
We also configure these new mappings in order to use the DirectEdit:
Each new diagram contribution is added in a new plugin, which contains the description of the mapping, the filters and the tools available for this diagram.
For more information about viewpoint description, you can have a look at the sirius documentation available here: https://www.eclipse.org/sirius/doc/specifier/general/Specifying_Viewpoints.html
The editor provided to edit the DocumentStructureTemplate metamodel is not exactly the version generated by EMF. We customized it in order to use a TransactionalEditingDomain (to ease the Papyrus integration).
When we add a new Sirius diagram, we shall create a new Sirius diagram prototype:
Once the Sirius Diagram Prototype has been created, it shall be defined as in the following picture:
To be able to reference the corresponding Diagram Description, it shall first be loaded in order to reference it. This can be done as in the following image:
And select the corresponding *.odesign file using the Browse Workspace:
Once the Sirius Diagram Prototype has been created. We shall select on which viewpoint this representation shall be allowed. To do this, select the viewpoint and add a Representation Kinds:
And simply select the diagram prototype that was created on the previous step.
This shall be done for both Analysis and Design viewpoint.
In the org.eclipse.papyrus.sirius.editor.representation.architecture plugin, a new class extending the AbstractCreateSiriusDiagramEditorCommand shall be created. This class will manage the condition of the creation of the diagram and the action to execute before creating it depending on the context.
We created the Papyrus service org.eclipse.papyrus.sirius.editor.internal.sessions.SessionService initialized during Papyrus' launch. This service is in charge creating the Sirius Session and attaching it to the edited semantic resource (uml file). This way a Sirius Session will always be accesible even if the user didn't yet created a Sirius diagram.
To use the same transactional editing domain as other Papyrus services, we had to override the default Sirius Session and its creation process. This is done by the PapyrusSessionFactory which creates the PapyrusSession (which is just a Sirius session with the Papyrus TransactionalEditingDomain).
For new services using session, it is recommanded to use the SessionService provided in the org.eclipse.papyrus.sirius.editor plugin.
From a selected EObject, we want to find all SiriusDiagramViewPrototype and store them into a list:
List<ViewPrototype> data = new ArrayList<>();
for (final ViewPrototype proto : PolicyChecker.getFor(selection).getPrototypesFor(selection)) {
if (proto instanceof SiriusDiagramViewPrototype && proto.getRepresentationKind() instanceof SiriusDiagramPrototype) {
final SiriusDiagramViewPrototype siriusPrototype = (SiriusDiagramViewPrototype) proto;
//additional check not yet done by the PolicyChecker
if (siriusPrototype.canInstantianteOn(selection)) {
data.add(proto);
}
}
}
Initially, for an Editpart selected in a Sirius Diagram, the method org.eclipse.papyrus.infra.emf.utils.EMFHelper.getEObject(Object) returns as EObject the Sirius diagram element representation (from the Sirius DDiagram metamodel) instead of the semantic EObject. We get this problem, because Sirius uses an intermediate metamodel (DDiagram) between the semantic element and the GMF metamodel. Consequently, the selection in the ModelExplorer and the displayed property view were never synchronized with a Sirius Diagram.
To solve this problem, our class org.eclipse.papyrus.sirius.editor.Activator contributes to the OSGi Service EObjectResolverService defined by the Papyrus plugin org.eclipse.papyrus.infra.emf. Our resolver is the class org.eclipse.papyrus.sirius.editor.internal.emf.SiriusEditPartEObjectResolver.
The selection of the ModelExplorer is propagated to the Papyrus Sirius Diagram editor (class org.eclipse.papyrus.sirius.editor.internal.editor.NestedSiriusDiagramViewEditor) using the interface org.eclipse.papyrus.infra.widgets.util.IRevealSemanticElement.
Some services class have been implemented for VSM use in AQL configuration field :
An EditPart and Figure have been created to allow using a Custom Style with Bordered Nodes in the VSM (*.odesign file) in order to rotate the associated image according to the position of the Bordered Node regarding its parent. To use it, a Custom Style must be used and the id filled with the prefix "rotative:", then the page of the image. Note that only non-SVG images can be used. For instance, PNG, GIF and JPEG formats are accepted. Here is an example with the InputPin Bordered Node, by using the id "rotative:/org.eclipse.papyrus.sirius.uml.diagram.activity/icons/InputPin.png":
The CommonDiagramServices class contains the isTypeOf(Element, String) method that checks if the provided element is an instance of the provided type. This method is similar to AQL's oclIsTypeOf service, but it also ensures that the EPackage containing the provided element's type is the UML package. This additional check prevents clashes between classes that have the same name and are defined in package with the same name. For example, it is used to check instances of PrimitiveType, which is defined in both the standard UML package and the UML package from OCL (also named uml).
This service is not necessary to specify Domain Class in the VSM. Domain classes are only checked against the EPackages specified in the Metamodels section of the representation.
The Activity diagram code is located in the
org.eclipse.papyrus.sirius.uml.diagram.activity plugin. Services and diagram tools are tested in the org.eclipse.papyrus.sirius.uml.diagram.activity.tests plugin.
ActivityDiagramServices class handles services used by tools of the Activity diagram for the creation of some specific element.
The creation is mainly handled by the UML-Service API. Sometimes, we needed to implement some logic in that class to determine the proper containing feature according the the selected parent element.
Note that the service ActivityDiagramServices.createExpansionNode implements a part of the business logic that cannot be fully handled in UML-Service.
Indeed, the ExpansionNode is referenced as input or output according to the executed tool (create InputExpansionNode or OutputExpansionNode). That reference cannot be determined in UML-Service: the UML-Service API does not allow to provide the tool being executed.
This class also provides services to retrieve semantic candidates and compute some preconditions expressions.
This service is a specific implementation of org.eclipse.papyrus.sirius.uml.diagram.common.services.DomainBasedEdgeServices to make possible the creation of InputPin and OutputPin nodes when selecting an
OpaqueAction as source or target of the ObjectFlow.
ActivityDropBehaviorProvider class handles services used by drag and drop tools (semantic or graphical). It will check drag and drop authorization and it will execute drag and drop action.
This class provides an implementation of UMLSwitch to retrieve the feature to use according to the semantic context and the type of the element to create.
This provider is mainly used to get the Pin feature to use according to the parent and the type of the Pin to create (input/output).
The diagram description (VSM) is located in the papyrus_activity.odesign and contains 3 layers :
The "Activity" layer defines all the mapping and tools specific to the Activity diagram:
As done in Composite Structure Diagram for instance, to allow creation and reconnection of Edge on compartment of container, these compartments of container should be added in Source mapping and/or Target mapping of the Edge configuration (see Composite Structure section for more details).
The "Display Qualified Name" layer allows displaying qualified labels on Nodes or Edges.
The "Display Applied Stereotypes" layer allows to display the label with Stereotype on Nodes or Edges.
All Pins border nodes mappings are synchronized. That allows to make them visible automatically since some of them are created at the same time as the parent action.
A specific mapping
AD_DecisionNodeComment has been defined to display a note attached to the DecisionNode if the feature DecisionNode#decisionInput is set.
This mapping is always synchronized. To prevent displaying the note when the DecisionNode is not visible, a precondition checks the visibility of this one.
Limitation: When performing a "Delete from diagram" on a DecisionNode with a note attached to him, the AD_DecisionNodeComment precondition is not evaluated since Sirius does not trigger a refresh. That means the Note will still be visible and need to be removed from the diagram manually with the "Delete from diagram" action.
Since Sirius cannot represent node mappings with rounded corners, we have represented most of the Action UML types (often represented with rounded corners) by containers without internal compartments. The container mapping allows defining styles with rounded corners.
The ActivityEdge (ControlFlow and ObjectFlow) label displays the name, guard and weight of the ActivityEdge but the direct edit allows the name editing only.
The class diagram code is located in the org.eclipse.papyrus.sirius.uml.diagram.clazz plugin.
The diagram description is located in the papyrus_class.odesign:
The Class layer defines all the mapping and tools specific to the class diagram:
The Communication diagram code is located in the
org.eclipse.papyrus.sirius.uml.diagram.communication plugin. Services and diagram tools are tested in the org.eclipse.papyrus.sirius.uml.diagram.communication.tests plugin.
CommunicationDiagramServices class handles services used by tools of the Communication diagram for the creation of some specific element. It also provides services to retrieve semantic candidates and compute some preconditions expressions.
CommunicationDropBehaviorProvider class handles services used by drag and drop tools (semantic or graphical). It will check drag and drop authorization and it will execute drag and drop action.
The diagram description (VSM) is located in the papyrus_communication.odesign and contains 3 layers :
The "Communication" layer defines all the mapping and tools specific to the Communication diagram:
As done in Composite Structure diagram, to allow creation and reconnection of Edge on compartment of container, these compartments of container should be added in Source mapping and/or Target mapping of the Edge configuration (see Composite Structure section for more details).
The "Display Qualified Name" layer allows displaying qualified labels on Nodes or Edges.
The "Display Applied Stereotypes" layer allows to display the label with Stereotype on Nodes or Edges.
The Component diagram code is located in the
org.eclipse.papyrus.sirius.uml.diagram.component plugin. Services and diagram tools are tested in the org.eclipse.papyrus.sirius.uml.diagram.component.tests plugin.
ComponentDiagramServices class handles services used by tools of the Component diagram for the creation of some specific element. It also provides services to retrieve semantic candidates and compute some preconditions expressions.
ComponentDiagramDropBehaviorProvider class handles services used by drag and drop tools (semantic or graphical). It will check drag and drop authorization and it will execute drag and drop action.
The diagram description (VSM) is located in the papyrus_component.odesign and contains 3 layers :
The "Component" layer defines all the mapping and tools specific to the Component diagram:
As done in Composite Structure diagram, to allow creation and reconnection of Edge on compartment of container, these compartments of container should be added in Source mapping and/or Target mapping of the Edge configuration (see Composite Structure section for more details).
The "Display Qualified Name" layer allows displaying qualified labels on Nodes or Edges.
The "Display Applied Stereotypes" layer allows to display the label with Stereotype on Nodes or Edges.
The Composite Structure diagram code is located in the
org.eclipse.papyrus.sirius.uml.diagram.compositestructure plugin. Services and diagram tools are tested in the org.eclipse.papyrus.sirius.uml.diagram.compositestructure.tests plugin.
CompositeStructureDiagramServices class handles services used by tools of the Composite Structure diagram for :
Service to detect Port loop will check that no infinity loop exists starting from the current port. A loop exists if the current port is reachable from its type, by navigation through its ports hierarchy.For instance Port 1 is owned by Class1 and it is typed by Class2 that owns a port typed by Class1.
Service to detect Port loop will also display error message in error log to prevent user of the infinity loop.
CompositeStructureDropBehaviorProvider class handles services used by Drag and drop tools (semantic or graphical). It will check drag and drop authorization and it will execute drag and drop action.
The diagram description (VSM) is located in the papyrus_compositestructure.odesign and contains 3 layers :
The "Composite structure" layer defines all the mapping and tools specific to the CompositeStructure diagram:
To allow creation and reconnection of Edge on compartment of container, these compartment of container should be added in Source mapping and/or Target mapping of the Edge configuration. This mechanism will display two edges on diagram :
To avoid this double representation, Precondition expression in advanced tab of the edge configuration should be completer with the following AQL expression : aql:not(sourceView.isCompartmentView()) and not(targetView.isCompartmentView()).
The "Display Qualified Name" layer allows displaying qualified labels on Nodes or Edges.
The "Display Applied Stereotypes" layer allows to display label with Stereotype on Nodes or Edges.
The Deployment diagram code is located in the
org.eclipse.papyrus.sirius.uml.diagram.deployment plugin. Services and diagram tools are tested in the org.eclipse.papyrus.sirius.uml.diagram.deployment.tests plugin.
To represent ExecutionEnvironment, Device and Node as a 3D box, we provided a specific draw2D figure: CuboidSiriusDefaultSizeNodeFigure. This figure overrides the SiriusDefaultSizeNodeFigure.
To achieve that, two Sirius EditPart are overriden:
CuboidDNodeContainerEditPartCuboidDNodeContainerInContainerEditPartIndeed, because of some specific behaviors following if the container is represented on the diagram or within another container, two specific EditParts implementations are defined in Sirius.
These EditParts are provided by the DeploymentDiagramContainerEditPartProvider through the org.eclipse.gmf.runtime.diagram.ui.editpartProviders extension point.
The DeploymentDiagramContainerEditPartProvider provides these EditPart only if the represented element type is ExecutionEnvironment, Device or a Node.
DeploymentDiagramServices class handles services used by tools of the Deployment diagram for the creation of some specific element. It also provides services to retrieve semantic candidates and compute some preconditions expressions.
DeploymentDropBehaviorProvider class handles services used by drag and drop tools (semantic or graphical). It will check drag and drop authorization and it will execute drag and drop action.
The diagram description (VSM) is located in the papyrus_deployment.odesign and contains 3 layers :
The "Deployment" layer defines all the mapping and tools specific to the Deployment diagram:
As done in Composite Structure diagram, to allow creation and reconnection of Edge on compartment of container, these compartments of container should be added in Source mapping and/or Target mapping of the Edge configuration (see Composite Structure section for more details).
The "Display Qualified Name" layer allows displaying qualified labels on Nodes or Edges.
The "Display Applied Stereotypes" layer allows to display the label with Stereotype on Nodes or Edges.
The Package diagram code is located in the
org.eclipse.papyrus.sirius.uml.diagram.pkg plugin. Services and diagram tools are tested in the org.eclipse.papyrus.sirius.uml.diagram.pkg.tests plugin.
PackageDiagramDropBehaviorProvider class handles services used by drag and drop tools (semantic or graphical). It will check drag and drop authorization and it will execute drag and drop action.
The diagram description (VSM) is located in the papyrus_package.odesign and contains 3 layers :
The "Package" layer defines all the mapping and tools specific to the Package diagram:
As done in Composite Structure diagram, to allow creation and reconnection of Edge on compartment of container, these compartments of container should be added in Source mapping and/or Target mapping of the Edge configuration (see Composite Structure section for more details).
The "Display Qualified Name" layer allows displaying qualified labels on Nodes or Edges.
The "Display Applied Stereotypes" layer allows to display the label with Stereotype on Nodes or Edges.
The Profile diagram code is located in the
org.eclipse.papyrus.sirius.uml.diagram.profile plugin. Services and diagram tools are tested in the org.eclipse.papyrus.sirius.uml.diagram.profile.tests plugin.
ProfileDiagramServices class handles services used by tools of the Profile diagram for the creation of specific nodes as the Metaclass for instance.
ProfileDropBehaviorProvider class handles services used by Drag and drop tools (semantic or graphical). It will check drag and drop authorization and it will execute drag and drop action.
The diagram description (VSM) is located in the papyrus_profile.odesign and contains 3 layers :
The "Profile" layer defines all the mapping and tools specific to the Profile diagram:
As done in Composite Structure diagram or UseCase Diagram, to allow creation and reconnection of Edge on compartment of container, these compartments of container should be added in Source mapping and/or Target mapping of the Edge configuration (see Composite Structure section for more details).
The Import Metaclass tool delegates to a service to open the MetaClass selection dialog. (see ProfileDiagramServices)
The PRD_PrimitiveType mapping uses the isTypeOf service in its precondition to check that the element is an instance of PrimitiveType and that its metaclass is defined in the UML package. This prevents clashes with the UML package defined in the OCL metamodel, which has the same name as the standard UML package (name is uml), and also defines a PrimitiveType metaclass.
The "Display Qualified Name" layer allows displaying qualified labels on Nodes or Edges.
The "Display Applied Stereotypes" layer allows to display label with Stereotype on Nodes or Edges.
The Sequence diagram code is located in the
org.eclipse.papyrus.sirius.uml.diagram.sequence plugin. Services and diagram tools are tested in the org.eclipse.papyrus.sirius.uml.diagram.sequence.tests plugin.
Sirius-based Sequence diagram relies on an ordered list of event-based elements to keep the graphical ordering consistent:
This list is provided by the Ends Ordering expression of the
SequenceDiagram Description in the odesign file (papyrus_sequence.odesign).
We call these elements "
ends". They have to be an
EObject.
For each sequenced element (ExecutionSpecification, StateInvariant, Message, ...),
start and
finish ends must be defined. They are identified by the Starting End Finder Expression and Finishing End Finder Expression fields in the odesign.
The ordering of the previous screenshot is the following (displayed by using the Papyrus Sequence Debug View):
The first element represents the start of the ExecutionSpecification, is followed by the send and receive ends of the message and then by the finish of the ExecutionSpecification.
Key points:
Ends Ordering expression defined on the SequenceDiagram in the odesign.org.eclipse.papyrus.sirius.uml.diagram.sequence.services.SequenceDiagramOrderServices#getEndsOrdering(Interaction, List<EObject>) Synchronized messages are represented as follow:
In UML model, receive event of a synchronized message is the same as the start event of an execution. The send event of return message is the same as the finish event of execution. To do so, the execution references events of related messages:
Odesign expressions must provide the same EAnnotation instance for Messages and related Execution ends.
Ideally, ordering elements should be part of the meta-model but UML meta-model lacks information Sirius descriptions need. Some implemented UML elements lack finishing indication : Combined Fragment and State Invariant..
In the example above, the Sequence diagram needs to know if the execution start or finish is before, within or after the combined fragment range:
To do so, the ordering elements are represented and persisted by using EMF EAnnotations in the Interaction root element.
All EAnnotations are stored in a parent EAnnotation attached to the root
Interaction. The source of this annotation is org.eclipse.papyrus.sirius.uml.diagram.sequence.end.
The constant is defined in org.eclipse.papyrus.sirius.uml.diagram.sequence.services.SequenceDiagramOrderServices.ORDERING_ANNOTATION_SOURCE
At runtime, the list of EAnnotation instances can be retrieved using the Papyrus Sequence Debug View.
This specific Debug view is provided by the org.eclipse.papyrus.sirius.uml.diagram.sequence.debug plugin in the
Toolsmith directory.
It allows developers to visualize the graphical elements ordering (with their Y coordinates).
As mentioned above, it also allows developers to inspect the content of the interaction EAnnotations. These annotations stands for the events used in ordering sequence. (see the first Ordering Principles section above).
Java services specific to Sequence diagram are provided by org.eclipse.papyrus.sirius.uml.diagram.sequence.services and org.eclipse.papyrus.sirius.uml.diagram.sequence.services.reorder packages.
Main entry point service for the following operations:
Handle Property and Class element dropping on the Sequence diagram (to create a new Lifeline or to set the
represents property on an existing LifeLine).
All services related to the global end ordering of the Sequence diagram.
All services to compute the semantic candidates of the Sequence diagram.
All services to display and edit Observation related elements for Sequence diagrams to be used by the VSM.
Provides Sequence diagram-specific labels for semantic elements.
SequenceDiagramReorderElementSwitch: Performs the reordering operations for the Sequence diagram according element type. it combines Semantic Elements ordering and Representation Ends ordering.SequenceDiagramEndReorderHelper: Performs reordering of event-based ends (EAnnotation) in Sequence diagram elements.SequenceDiagramSemanticReorderHelper: Performs reordering of UML elements in their UML container. UML does not fully the semantic order of fragments but CEA requires to keep the same order for diagram display, fragment containment and Lifeline covering list.The Sequence diagram description is defined in /description/papyrus_sequence.odesign.
The main layer
Sequence contains the mappings representing the visual elements.
Creation tools are dispatched as usual into 2 tool sections: Node and Edge.
There are some specific points to mention. They are described in the subsections below.
Each time an element is moved on the diagram, the reorder tool is called.
These tools invokes reorder functions provided by the SequenceDiagramOrderServices.
In the Sequence diagram, a specific mapping allows to define visual elements attached at the start or end of elements.
Two Observation Point Mapping are defined in the Papyrus Sequence diagram:
They make possible to identify and restrict the area where Time Element tools (TimeObservation and TimeConstraint) or Synchronized message tool can be applied.
The Sirius Sequence diagram engine needs to know which semantic element has been created to locate it properly where the user performs the action. For instance, when using an Execution creation tool, the user expects to see the new execution at the location where he clicked. To do so, we have to create the instance by using the Sirius Instance Creation operation. Unlike other diagrams of Paryrus, it is not possible to delegate the creation of main semantic element to a Java service (the one targeted by the mapping).
Several elements (ExecutionSpecifications, Messages, DurationConstraints, ...) references companion-elements without including them (OccurrenceSpecification, Interval, ...). Such companion-elements must be removed when the main elements is removed unless referenced by another elements.
This implies that, in Papyrus Services, following classes must be updated accordingly:
org.eclipse.papyrus.uml.domain.services.create.ElementConfigurer$ElementInitializerImplorg.eclipse.papyrus.uml.domain.services.destroy.ElementDependencyCollector$DestroyDependencyCollectorSwitchTo prevent moving an Execution with messages related to it, we provide a custom EditPolicy. The code is provided by org.eclipse.papyrus.sirius.uml.diagram.sequence.edit.parts package.
PapyrusSequenceDiagramEditPartProvider: the contribution to the org.eclipse.gmf.runtime.diagram.ui.editpartProviders extension point. It overrides the Sirius ExecutionEditPart to replace it by the PapyrusExecutionEditPart.PapyrusExecutionEditPart: specialization of Sirius ExecutionEditPart to provide specific Selection Edit Policy.PapyrusExecutionSelectionEditPolicy: the specific GMF EditPolicy to prevent Execution with connected messages to be moved.The State Machine diagram code is located in the org.eclipse.papyrus.sirius.uml.diagram.statemachine plugin.
To handle the specific behavior of Region, since both VerticalStack or HorizontalStack children presentations could not handle the mixed behavior of region (sometimes vertical and sometimes horizontal). Hence, the Freeform children presentation is used combined to a manageRegionPresentation and setChildRepresentation method that allows to chose between either horizontal and vertical.
The diagram description is located in the papyrus_statemachine.odesign:
The State Machine layer defines all the mapping and tools specific to the state machine diagram:
The Use Case diagram code is located in the
org.eclipse.papyrus.sirius.uml.diagram.usecase plugin. Services and diagram tools are tested in the org.eclipse.papyrus.sirius.uml.diagram.usecase.tests plugin.
UseCaseDiagramServices class handles services used by tools of the UseCase diagram for :
UseCaseDropBehaviorProvider class handles services used by Drag and drop tools (semantic or graphical). It will check drag and drop authorization and it will execute drag and drop action.
The diagram description (VSM) is located in the papyrus_usecase.odesign and contains 3 layers :
The "Use Case" layer defines all the mapping and tools specific to the UseCase diagram:
As done in Composite Structure diagram, to allow creation and reconnection of Edge on compartment of container, these compartments of container should be added in Source mapping and/or Target mapping of the Edge configuration (see Composite Structure section for more details).
Unlike most representations in this diagram, Actor and UseCase are represented with SVG image.
To represent all different "Subject" to create in the palette node, a Group has been used in the VSM and each Subject is represented by a container tool inside the Group.
The "Display Qualified Name" layer allows displaying qualified labels on Nodes or Edges.
The "Display Applied Stereotypes" layer allows to display label with Stereotype on Nodes or Edges.
Code in org.eclipse.papyrus.sirius.uml.diagram.textedit override classic editpart to add an xtext parser on each label edition.
Each new feature must be added as extra requirements in the pom.xml of the plugin org.eclipse.papyrus.sirius.bundles.tests to ensure that all plugins provided by the new feature is well configured (about.xml, min/max for dependencies ...)
The common method to create new tests for sirius diagram is located in org.eclipse.papyrus.sirius.junit.utils. In this plugin, the SiriusDiagramEditorFixture provide all the method to load model, ope session, tests tools that will be used in the several test case.
Each specific diagram is tested in a specific plugin. Those tests include:
Each test should check the state of the tested diagram (synchronized/unsynchronized), to ensure that the test is executed on the expected diagram configuration.
This element is quite difficult to represent. Its representation is composed with two edges and one node:
The AssociationClass is owned by the nearest Package of the source. The AssociationClass owns 2 Property referenced by the feature memberEnds.