Define shown features in property views

[planger]

We require input on which features are to be shown in the properties views and whether we need to simplify those in some aspects for some concepts.

UML Use Case

• [ ] Package
• [ ] Subject
• [ ] Actor
• [ ] Use Case
• [ ] Comment
• [ ] Association
• [ ] Generalization
• [ ] Include
• [ ] Extend
• [ ] Comment link

  Activity Diagram

• [ ] Activity
• [ ] Initial Node
• [ ] Final Node
• [ ] Activity final
• [ ] Decision node
• [ ] Merge node
• [ ] Join node
• [ ] Fork node
• [ ] Opaque Action
• [ ] Comment
• [ ] Control Flow
• [ ] Link
• [ ] Action
• [ ] Call BehaviorAction
• [ ] CallOperation Action
• [ ] AcceptEventAction
• [ ] Pin
• [ ] InputPin
• [ ] OutputPin

  Class Diagram

• [x] Class
• [x] Comment
• [x] DataType
• [x] Enumeration
• [x] Enumeration Literal
• [x] Interface
• [x] Interface Realization
• [x] Primitive Type
• [x] Operation
• [x] Package
• [x] Property
• [x] Operation
• [x] Parameter
• [x] Aggregation (composition, aggregation)
• [x] Association
• [x] Association Class
• [x] Generalization
• [x] Link
• [x] Realization
• [x] Visibility (public, private, protected)
• [x] Dependency
• [x] Multiplicity

  State Machine

• [x] State
• [x] Initial
• [x] FinalState
• [x] Choice
• [x] Junction
• [x] Comment
• [x] Transition
• [x] Link

  Package Diagram

• [x] Comment
• [x] Model
• [x] Package
• [x] Containment Link
• [x] Dependency
• [x] Link
• [x] PackageImport

  Sequence Diagram

• [ ] OccurrenceSpecification
• [ ] Executation Specification
• [ ] Interaction
• [ ] Action Execution Specification
• [ ] Comment
• [ ] Interaction Use
• [ ] Lifeline
• [ ] Message Async
• [ ] Message Sync
• [ ] Message Occurence Specification
• [ ] MessageSort
• [ ] MessageEnd
• [ ] CallEvent
• [ ] SignalEvent
• [ ] OpaqueBehavior
• [ ] Link

[cdamus]

A proposal for properties of Package Diagram, Class Diagram, Use Case Diagram, and Sequence Diagram concepts:

Properties View.pdf

[planger]

Nice proposal, thanks @cdamus!

[cdamus]

And a proposal for the other two diagram types, the State Machine Diagram and the Activity Diagram:

Properties View II.pdf

[tortmayr]

@cdamus Very nice proposal I'm wondering though if we really need the localized Label property in the context of UML Light.

[cdamus]

The Label is an extra-UMLism provided by Papyrus that I imagine is particularly interesting for presenting diagrams in multiple languages in the context of system documentation, and I imagine documentation being a prime use case for UML Light. So, it seems harmless but it does imply the management of additional properties resources that complicate a user's life. And it's non-standard. So I would support suppressing it, but perhaps our stakeholders should weigh in on the question as it could be valuable for that documentation use case.

[cdamus]

One aspect of this that we will have to address is the problem of what to do about the default UML property views provided by Papyrus UML. As we develop our custom properties views, we will be testing them by disabling the UML Metamodel (plugin) context in the preferences because otherwise we won't see any effective change.

So, our work won't help users unless that context is disabled, but disabling it also affects non-light UML models. Unfortunately, Papyrus has neglected (so far) to tie properties contexts to the architecture model. So, we could (once we have finished the coverage of properties for all of the diagrams) implement an Equinox XSLT transform that sets the default enablement of Papyrus's UML properties context to false on the understanding that users may have to explicitly enable it for themselves if they need also to use full UML.

Comments, @planger and @tortmayr?

[planger]

Right, in Papyrus-IM we added an activator that hides them at runtime via a ContextConfigurator. I think we can do the same but put it in an own plug-in, so that we can easily build with and without this activator. Similar as we did with all the simplification mechanisms that are rather intrusive.

What do you think?

[cdamus]

Another aspect that I've noticed in testing is that the green ➕ buttons in the Properties view that create new elements suggest metaclasses that are not included in the UML Light subset. We need to filter those out. I'm not sure whether it is sufficient to contribute edit-helper advice that disables creation of these elements as we do for trimming the New Child menu. In any case, it should be investigated because this is a leak of concepts that we don't want the user to face.

[CharlesAtZelig]

This is a good list of simplifications. I would prefer to keep "isQuery" for operations, simply because I have used it fairly often during early modeling for a projrct, especially of datastores, to provide a hint to the user. But I am not dogmatic about it. I would also like to mention that, during the first "election" of capabilities for Papyrus UML Light, mutiplicity and subject were explicitly out.

[planger]

I would also like to mention that, during the first "election" of capabilities for Papyrus UML Light, mutiplicity and subject were explicitly out.

In the final election those were in again. I'm not against removing them, but for now I'd like to stick to the final list, until there is a common agreement to change it.

[CharlesAtZelig]

OK. agreed. I was not even aware that there had been more elections. And where could I find the results of the latest so I can stop bother people about this?

And what are your thoughts qbout my comment on the "isQuery?

[planger]

OK. agreed. I was not even aware that there had been more elections. And where could I find the results of the latest so I can stop bother people about this?

I forwarded you the mail to the steering committee about the decision. It (hopefully) should correspond to the list we have in the descriptions of the respective github issues, such as this one.

And what are your thoughts qbout my comment on the "isQuery?

I'm fine with keeping it. I think the semantics is simple enough to keep it anyway.

[cdamus]

The problem I have with isQuery is that it asserts that an operation is free of side-effects, which is interesting mostly for active classes (which we don't have in UML Light) and other concurrency concerns that we don't support. Plus access from OCL (which I don't know what its relationship to UML Light is supposed to be), inasmuch as OCL expressions may only call query operations.

Note that not including a property in the UML tab doesn't make it unavailable. It's still presented in the Advanced tab. To me, this property feels sufficiently "advanced".

[cdamus]

Another aspect that I've noticed in testing is that the green ➕ buttons in the Properties view that create new elements suggest metaclasses that are not included in the UML Light subset.

For the sequence diagram properties view (#62), I'm working on a custom ModelElement implementing the filtering of creatable types and other concerns. This apply generically to all of the diagrams via the Properties View Context Model that we already have in place.

[CharlesAtZelig]

Please see my comments, inline below.

Regards / cordialement,

Charles Rivet Senior Product Manager / directeur principal de produits charles@zeligsoft.com mailto:charles@zeligsoft.com

On 2018Dec 17,, at 14:08, Christian W. Damus <notifications@github.com mailto:notifications@github.com> wrote:

The problem I have with isQuery is that it asserts that an operation is free of side-effects, which is interesting mostly for active classes (which we don't have in UML Light) and other concurrency concerns that we don't support. Plus access from OCL (which I don't know what its relationship to UML Light is supposed to be), inasmuch as OCL expressions may only call query operations.

I cannot comment on the use of isQuery in OCL. However, I respectfully disagree with it being only interesting for active classes, as per my example of hints for datastore, especially when used as a hint in the early modeling lifecycle. I also contend that not every model, depending on the typeof approach or where they are in their lifecycle, needs the formality of using OCL

From the spec (2.5.1), which I am sure you already know (and most likely better than I do ;-): 9.6.3. : “1f the isQuery property is true, an invocation of the Operation shall not modify the state of the instance or any other element in the model”.

99.11.4 : “Specifies whether an execution of the BehavioralFeature leaves the state of the system unchanged (isQuery=true) or whether side effects may occur (isQuery=false)”.

This is exactly what I would expect in cases where, in early modeling stages, one would want to identify (hint at) a read-only operation access on a data store.

Granted, this is a single example, but it is a good illustration of its potential use.

Note that not including a property in the UML tab doesn't make it unavailable. It's still presented in the Advanced tab. To me, this property feels sufficiently "advanced".

All in all, The advanced tab could be sufficient, it this tool were not targeting the following personas (do you have access to their description?): Papyrus Novice UML Novice or Student Basic UML User Some of the users might be less inclined to go look at "Advanced tab (although many will likely do so…)

In the grand scheme of this effort, I do not think it is worth arguing further and I will defer to Philip, as project lead for the development, to make the best decision for the tool.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/eclipsesource/papyrus-umllight/issues/18#issuecomment-447961893, or mute the thread https://github.com/notifications/unsubscribe-auth/AHqD7QBknrbRxFG0QZaLUqYZL3Yr7B1Pks5u5-udgaJpZM4Xtiq0.

[planger]

@CharlesAtZelig @cdamus Thanks for the discussion! These are all valid points, but I agree that given the scope of this project, it is not worth discussing this further. I think for the main goals of UMLLight, simplicity should have higher priority than including certain additional aspects; especially if those aspects can still be specified in the not-so-convenient but available advanced property tab. Thus, for the sake of keeping it as simple as possible, I'd remove isQuery then.

[cdamus]

Per discussion in #10, we need to add ObjectFlow to the Acitivty Diagram. For that, I would suggest a similar treatment as for ControlFlow, plus suppression of the multicast-related properties:

[cdamus]

For Parameter, the proposal indicates that we should have edit advice to set the effect in accordance with a plausible default for the direction. However, looking at this again, I see that UML metamodel has the effect as optional ([0..1] multiplicity) which in the EMF-based implementation is an "unsettable" feature. Because EMF requires the effect to have a value in the Java implementation (it has an enumeration type), it looks like it's set even when it isn't. And by default, it isn't set, so I think we do not need the proposed advice.

[tortmayr]

@planger @cdamus Are there any pending questions left in this issue ore can we close it?

[planger]

I think we can close this, however I'm not sure about comment https://github.com/eclipsesource/papyrus-umllight/issues/18#issuecomment-449129509 above. @cdamus what do you think?

[cdamus]

I agree to close. My comment about the parameter effect property is my reasoning for just leaving it off the UML tab (which it now is) and doing nothing further, so as far as I'm concerned, the class diagram properties implementation is complete.

(Perhaps my earlier comment wasn't quite complete. I should mention that the consequence of not presenting effect in the properties view is that it will always be unset, so any EMF-savvy application that gets a model produced by the UML Light tooling should see that it is "unset" and so consider it as not having a value, which is the best default for the "light" modeling IMHO).

[planger]

:+1: Great thanks for clarifying.