Constraint across three associations

UML related questions and discussions

Moderator: Moderators

Constraint across three associations

Postby m.faughn@prometheuscomputing.com » Mon Aug 21, 2017 1:32 pm

Hello,

How can I create a constraint across three associations? UML provides for this (section 7.6.2 of UML 2.5 standard). How can I do this in MagicDraw?

Thanks,
Michael
m.faughn@prometheuscomputing.com
Forum Newbie
Forum Newbie
 
Posts: 21
Posts Rating:0
Joined: Fri May 30, 2014 9:30 am

Re: Constraint across three associations

Postby donatas.mazeika@nomagic.com » Tue Aug 22, 2017 2:58 am

Hello,

The section 7.6.2 in UML 2.5 specification defines the abstract syntax (meta-model) of Constraint, not its usage. So, this situation cannot be modeled in your model. You could learn more about constraints and how to work with them here: https://docs.nomagic.com/display/MD185/Constraint

If you need more help, just let us know.

Have a nice day,
Donatas Mazeika
donatas.mazeika@nomagic.com
Forum Expert
Forum Expert
 
Posts: 120
Posts Rating:17
Joined: Tue Apr 21, 2015 12:30 am

Re: Constraint across three associations

Postby m.faughn@prometheuscomputing.com » Wed Aug 23, 2017 7:33 am

The abstract syntax does, in fact, inform us on the usage of constraint. My interpretation of the referenced portion of the spec is that a given instance of constraint may constrain zero to infinity elements. Associations are elements. QED I should be able to constrain three associations with one instance of constraint. Furthermore, from section 7.6.4, "For three or more paths of the same kind (such as Generalization paths or Association paths), the constraint string may be attached to a dashed line crossing all of the paths." With MagicDraw I can certainly cross a third association path with a dashed line representing a constraint between two associations but that is not reflected by anything computable that I can see a specification for or access through the API. Anything that is "just a picture" host not, in my opinion, actually been implemented.

Beyond that, it appears to me that MD has implemented Constraint in an...ahem, unconventional way. Here's some Gherkin...
Code: Select all
When I create a constraint between two associations
And then I double click on it.
Then nothing happens.
Then I right click on it to bring up the context menu and I click 'select constraint'
And then I select xor
Then I create a second constraint between two different associations
And then I double click on it.
Then nothing happens.
Then I right click on it to bring up the context menu and I click 'select constraint'
And then I select xor
When I double click on one of the dashed lines in my diagram that represents one of the aforementioned constraint elements
Then I see a modal popup titled 'Specification of Constraint xor [Read Only]'
And I see that the constrained elements list in said specification show all four of the aforementioned associations.
And then I close the popup
When I double click on the dashed line in my diagram that represents the other of the aforementioned constraint elements
Then I see a modal popup titled 'Specification of Constraint xor [Read Only]'
And I see that the constrained elements list in said specification show all four of the same aforementioned associations.


It looks very, very much like there is a conflation between a Constraint element and its associated ValueSpecification element in the UI.

If I then refer to your linked documentation I read that, "The constrained elements are those elements required to evaluate the constraint specification." So, going from the information given by MD, in my above example I would have to evaluate all the constraint in the context of all four of the associations. I think that the intent of the UML spec is that a Constraint indicated by a dashed line between two or more associations need only consider those elements. MagicDraw is, effectively, allowing only one instance of Constraint with ValueSpecification xor. I can't find anything in the OMG spec that supports this implementation. If you can, then please show me where it is. The logical implementation is for completely separate Constraint instances, each with separate instantiations of ValueConstraint (both of which are, coincidentally, {xor}), and independent associations to their respective constrained elements.

Note also that when the context menu on a constraint element says 'specify constraint'. It would be clearer if it did not conflate the constraint element with the constraint elements value specification. What you are doing when you click 'specify constraint' should be to associate a value specification with the constraint instance.

Also, it seems that I can not change the name of a constraint element unless I choose 'Create Constraint' after 'Select Constraint' (which again, is actually the creation of a ValueSpecification and not a Constraint). Otherwise, I am forced by MD to have the name be the same as the name of the value specification. This is not specified by OMG. If I am wrong, please indicate where in the standard this is specified.

I have confirmed that, when accessing UML elements through the API, that all diagram elements representing a constraint with a value specification of {xor} are backed by a single instance of Constraint.

I am fairly convinced that MagicDraw does not implement the OMG standard correctly with respect to Constraint. It appears that the application is, for some unknown reason, limiting the number of OpaqueExpressions with the same value for the body attribute to 1. From there it would follow that you would only have a single instance of Constraint for any unique OpaqueExpression. That would explain the situation. If this is what is happening then I fail to understand the limitation on OpaqueExpression instances with the same value for the body attribute. I'm open to being shown I'm incorrect but you will need to reference the standard and provide a very clear explanation of your interpretation to do so.
m.faughn@prometheuscomputing.com
Forum Newbie
Forum Newbie
 
Posts: 21
Posts Rating:0
Joined: Fri May 30, 2014 9:30 am

Re: Constraint across three associations

Postby donatas.mazeika@nomagic.com » Wed Aug 30, 2017 8:12 am

Hello,

Sorry, for the misunderstanding.
You should not use constraints from "MagicDraw Profile" but define your own constraints. Please see "Constraint across three associations.mdzip" as an example for modeling constraint across multiple elements:
Constraint across three associations.mdzip


Best regards,
Donatas Mazeika
You do not have the required permissions to view the files attached to this post.
donatas.mazeika@nomagic.com
Forum Expert
Forum Expert
 
Posts: 120
Posts Rating:17
Joined: Tue Apr 21, 2015 12:30 am

Re: Constraint across three associations

Postby m.faughn@prometheuscomputing.com » Wed Aug 30, 2017 8:53 am

Thanks for the reply. I eventually did figure out how to do something about like the attached example. I still think that there is clearly a conflation b/w the Constraint element and its associated ValueSpecification. I also think that it would be better if a single diagram element could be used rather than having to use multiples of them.

I also noticed that it is possible to visit all of the constrained elements of a constraint and unapply the constraint but after doing so the diagram element (a dashed line) remains. This seems rather odd.

I am curious as to why the OMG limited the number of Constraints to which a ValueSpecification may be associated to one. Also, why must the Constraint own the ValueSpecification? I'm curious about OMG's rationale for that as well.

FWIW, the example did request several other modules, a profile, and two plugins that I don't have. We only use LTR versions of MD.
m.faughn@prometheuscomputing.com
Forum Newbie
Forum Newbie
 
Posts: 21
Posts Rating:0
Joined: Fri May 30, 2014 9:30 am


Return to Software Modeling (UML)

Who is online

Users browsing this forum: No registered users and 0 guests