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/Discussion"

(Problem Description: conclusion)
(Possible Solutions: filled)
Line 110: Line 110:
 
==== Possible Solutions ====
 
==== Possible Solutions ====
  
...
+
Improve the algo.
  
 
== Class Diagram ==
 
== Class Diagram ==

Revision as of 05:23, 19 January 2019

This page is dedicated to gather discussions on potential evolution of Papyrus.

Architecture refactoring

Usability related issues

This part presents and discusses some noticeable usability related issues or defects of the current releases.

Papyrus version: 4.2 Model type: UML

General

...

Model Explorer

The Lengthy Menu of New Child (right-clicked)

Problem Description

The menu list of New Child is too long to browse through.

For example, every time you want to create a new use case (unfortunately it's at the bottom of the menu) directly in the model explorer (not from in a use case diagram), you have to browse and scroll down the lengthy, complex list by pressing the downward arrow repeatedly, tedious operation.

NewChildPopup UseCase.png

The same situation happens when creating a new package. You have to scroll down by pressing the arrow many times when the menuitem Package does not appear on the first screen.

Possible Solutions

  • Provide a new quick access (shortcuts) panel at the top in the 'New Child' menu for most frequently-created (or primary) items, e.g. Actor, Class, Model, Package and Use Case, etc.
  • An alternative way is providing a History panel in the menu to record items most recently created by the user, hence enabling quick access to them by just one click without scrolling.
  • Besides the lengthy alphabetical listing, group items into semantical categories to greatly shorten the list, and move those less-created (or secondary) ones into lower-level submenus.

Sequence Diagram

Failed to hide/remove unnecessary guard icons in combined fragments

Problem Description

CombinedFragment GuardIcon.png

No any apparent way can be found to hide or remove the guard icons (as shown above, red circled) in combined fragments. Seemingly superfluous, they are not normative, and inconsistent with plain-style drawings (merely simple forms in black and white without any colors or unnecessary decorations).

Possible Solutions

  • Could there be a handy project, model and/or diagram level mechanism (by configuration and/or switching) to turn on/off guard icons in all combined fragments in any relevant diagram?

Detached reflective message from its own execution bar

Problem Description

Start from here:

DetachedReflectiveMessage init.png

Lifeline2 has a reflective message13 residing on the execution bar.

Step1:

DetachedReflectiveMessage Step1.png

Message13 goes down together, everything's Ok.

Step2:

DetachedReflectiveMessage Step2.png

Error!

This proves that the reflective message13 has not been attached all the time to its own execution bar. But it behaved correctly in Step1 when moving down, strange.

It seems a bug somewhere in the code or algo.

Possible Solutions

...

Combined Fragments are not real containers but plain frames

Problem Description

Start from here:

FalseContainer init.png

When you draw several inner messages in the seq fragment, the messages are supposed to be contained by and belong to the fragment. It looks like the above, but only superficially.

Step a:

FalseContainer Step a.png

When moving the fragment down, its inner content does not go along with it.

Step b:

FalseContainer Step b.png

When you move down something up outside (Msg3), surprisingly, the fragment even keeps static, while its supposed inner content is moving out!


The demo proves that the combined fragments are not real object containers but plain graphical frames, and their positions cannot be automatically re-adjusted as those capable messages in response to outside changes.

The current approach merely works and the diagrams still look okay, however, much extra time (minutes) are spent in rearranging the affected fragments and their inner content to get it right, since moving elements (messages, fragments, etc.) up and down alongside lifelines is quite common when daily drawing somewhat complex sequence diagrams.

Possible Solutions

Improve the algo.

Class Diagram

...

Use Case Diagram

...

Activity Diagram

...

Package Diagram

...

Copyright © Eclipse Foundation, Inc. All Rights Reserved.