Skip to main content
Jump to: navigation, search

Difference between revisions of "Papyrus/Discussion"

(Possible Solutions: filled)
(Replaced content with "to be deleted")
 
Line 1: Line 1:
 
+
to be deleted
This page is dedicated to gather discussions on potential evolution of Papyrus.
+
 
+
= Architecture refactoring =
+
 
+
* [[Papyrus/Photon Work Description/Architecture refactoring/Papyrus SDK|Papyrus SDK]]
+
 
+
= 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.
+
 
+
[[File:NewChildPopup UseCase.png|800px]]
+
 
+
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 ====
+
 
+
[[File:CombinedFragment_GuardIcon.png|500px]]
+
 
+
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:
+
 
+
[[File:DetachedReflectiveMessage_init.png|500px]]
+
 
+
Lifeline2 has a reflective message13 residing on the execution bar.
+
 
+
Step1:
+
 
+
[[File:DetachedReflectiveMessage_Step1.png|500px]]
+
 
+
Message13 goes down together, everything's Ok.
+
 
+
Step2:
+
 
+
[[File:DetachedReflectiveMessage_Step2.png|500px]]
+
 
+
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:
+
 
+
[[File:FalseContainer_init.png|500px]]
+
 
+
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:
+
 
+
[[File:FalseContainer_Step_a.png|500px]]
+
 
+
When moving the fragment down, its inner content does not go along with it.
+
 
+
Step b:
+
 
+
[[File:FalseContainer_Step_b.png|500px]]
+
 
+
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 ==
+
 
+
...
+

Latest revision as of 11:18, 19 November 2020

to be deleted

Back to the top