Home » Modeling » MDT (Model Development Tools) » UML2 constraints -- problem with spec, repository model required
| UML2 constraints -- problem with spec, repository model required [message #376823] |
Mon, 06 November 2006 13:03  |
 Michael Golubev
Messages: 383
Registered: July 2009 |
Senior Member |
|
|
Hi,
(crossposted to eclipse.modeling.mdt, eclipse.tools.uml2)
I am trying to implement constraints support for the MDT Class diagram, and
I have some troubles.
Any help is highly appreciated, especially from experts from MDT OCL
sub-component.
To understand the issue please take a look at the OMG UML2 specification
06-04-02, Figure 7.7 "Constraints diagram of the Kernel package". Note 2
associations +context/+ownedRule (with composite aggregation at the
"context" end) and +constrainedElement navigable from constraint to element.
Note that NONE of them IS DERIVED.
Also please take a look at the "Semantics" part of the paragraph 7.3.10 that
explicitly states:
"For example, in OCL 'self' is used to refer to the __context__ element".
The problem is that given any repository model, we can change 3 different
things: context/owned rule containment, value specification's "body" and
"constarintedElement" association.
It looks like only 2 of these 3 things may be changed independently --
either (context + body) that effectively makes "constrainedElement" to be
derived. Or (context + constrainedElement) that derives "body", or finally
(body + constrainedElement) that derives context.
To have an example, consider very simple UML model instance that contains
class Person with integer attribute age. We want to constraint age to be
positive ("AIP" -- stands for "age is positive").
There are a lot of possible repository models for this case.
E.g, we can arrange it as follows:
1. Model instance owns the Class "Person". Class owns Property "age".
Property owns Constraint "AIP", Constraint in turn owns ValueSpecification
like "self > 0". Note that once we set containment context to be a property,
we HAVE TO use "self" to denote the context element (property), so we can
not write AIP body as, say "self.age > 0". Note that once we set context and
body, we can not say that constrainedElement is some independent "Actor" --
the pair of context/body effectively derives the contextElement.
We had a chance to arrange model using other way:
2. Model owns the Class "Person". Class owns the Property age. The same
class (in contrast to the Property in the first arrangement) owns Constraint
"AIP". Assume that at first we set the constrainedElement association to
reference the property and now we are wondering what may be the constraint
body. Given the prerequisite that "self" ultimately has to express the class
(due to "Semantics" part of the 7.3.10 spec), we have no chances to define
body other than "self.age > 0" -- any other left part of the body will not
give us the correct preset value for constrainedElement.
It is not the "theoretical" question.
The graphical representation of the repository model should be:
- the Constraint rectangle,
- Class rectangle
- Property label
- and some link between Constraint rectangle and _something_.
When looking for this "_something_", we can rely either on the
context/ownedRule association or on the constrainedElement association. I am
rising this issue mainly to choose one of them to visualize.
Regards,
Michael
|
|
|
| Re: UML2 constraints -- problem with spec, repository model required [message #376826 is a reply to message #376823] |
Thu, 09 November 2006 18:48  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hello, Michael,
Please find some responses in-line, below.
HTH,
Christian
Michael Golubev wrote:
> Hi,
>
> (crossposted to eclipse.modeling.mdt, eclipse.tools.uml2)
>
> I am trying to implement constraints support for the MDT Class diagram,
> and I have some troubles.
> Any help is highly appreciated, especially from experts from MDT OCL
> sub-component.
>
> To understand the issue please take a look at the OMG UML2 specification
> 06-04-02, Figure 7.7 "Constraints diagram of the Kernel package". Note 2
> associations +context/+ownedRule (with composite aggregation at the
> "context" end) and +constrainedElement navigable from constraint to
> element. Note that NONE of them IS DERIVED.
Interestingly, Section 7.3.10 indicates that "context" is derived, but that
must be a mistake. The Rose model (from which the diagrams are generated)
is definitive.
> Also please take a look at the "Semantics" part of the paragraph 7.3.10
> that explicitly states:
> "For example, in OCL 'self' is used to refer to the __context__ element".
>
> The problem is that given any repository model, we can change 3 different
> things: context/owned rule containment, value specification's "body" and
> "constarintedElement" association.
>
> It looks like only 2 of these 3 things may be changed independently --
> either (context + body) that effectively makes "constrainedElement" to be
> derived. Or (context + constrainedElement) that derives "body", or finally
> (body + constrainedElement) that derives context.
I don't see that there is any relationship between context and
constrainedElement. The discussion is pretty clear that the context
element is the namespace that owns the constraint. In the case of OCL, one
can argue that the constraintElement association can be derived from the
features and metaclasses that the expression accesses, but I think its main
purpose is for connecting pre-defined constraints such as "xor" to elements
(as well as natural-language constraints).
> To have an example, consider very simple UML model instance that contains
> class Person with integer attribute age. We want to constraint age to be
> positive ("AIP" -- stands for "age is positive").
>
> There are a lot of possible repository models for this case.
> E.g, we can arrange it as follows:
>
> 1. Model instance owns the Class "Person". Class owns Property "age".
> Property owns Constraint "AIP", Constraint in turn owns ValueSpecification
> like "self > 0". Note that once we set containment context to be a
> property, we HAVE TO use "self" to denote the context element (property),
> so we can not write AIP body as, say "self.age > 0". Note that once we set
> context and body, we can not say that constrainedElement is some
> independent "Actor" -- the pair of context/body effectively derives the
> contextElement.
The "age" property cannot own the constraint, because it is not a namespace.
Moreover, in the case of OCL, 'self' always refers to the _classifier_
context of a constraint. In OCL, a constraint defined in the 'context'
(using the term generically) constrains the property but has the property's
owner as its context classifier.
> We had a chance to arrange model using other way:
> 2. Model owns the Class "Person". Class owns the Property age. The same
> class (in contrast to the Property in the first arrangement) owns
> Constraint "AIP". Assume that at first we set the constrainedElement
> association to reference the property and now we are wondering what may be
> the constraint body. Given the prerequisite that "self" ultimately has to
> express the class (due to "Semantics" part of the 7.3.10 spec), we have no
> chances to define body other than "self.age > 0" -- any other left part of
> the body will not give us the correct preset value for constrainedElement.
This is the most natural approach (at least for me), and is consistent with
the OCL specification.
> It is not the "theoretical" question.
>
> The graphical representation of the repository model should be:
> - the Constraint rectangle,
> - Class rectangle
> - Property label
> - and some link between Constraint rectangle and _something_.
>
> When looking for this "_something_", we can rely either on the
> context/ownedRule association or on the constrainedElement association. I
> am rising this issue mainly to choose one of them to visualize.
I think, perhaps, that the visual links should be of two discernible kinds:
one link for the "context" reference (max. 1 instance) and a different link
for the "constrainedElement" references (unbounded instances). The
semantics of context are special, including that the context determines
when a constraint is evaluated by the system. The "constrainedElement"
seems to me completely unrelated to context.
So, in your AIP example, I think you might have one link (perhaps visually
heavier) between the Constraint rect and the Class rect, and another
(perhaps visually lighter) between the Constraint rect and the Property
label.
>
> Regards,
> Michael
|
|
|
| Re: UML2 constraints -- problem with spec, repository model required [message #568722 is a reply to message #376823] |
Thu, 09 November 2006 18:48 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hello, Michael,
Please find some responses in-line, below.
HTH,
Christian
Michael Golubev wrote:
> Hi,
>
> (crossposted to eclipse.modeling.mdt, eclipse.tools.uml2)
>
> I am trying to implement constraints support for the MDT Class diagram,
> and I have some troubles.
> Any help is highly appreciated, especially from experts from MDT OCL
> sub-component.
>
> To understand the issue please take a look at the OMG UML2 specification
> 06-04-02, Figure 7.7 "Constraints diagram of the Kernel package". Note 2
> associations +context/+ownedRule (with composite aggregation at the
> "context" end) and +constrainedElement navigable from constraint to
> element. Note that NONE of them IS DERIVED.
Interestingly, Section 7.3.10 indicates that "context" is derived, but that
must be a mistake. The Rose model (from which the diagrams are generated)
is definitive.
> Also please take a look at the "Semantics" part of the paragraph 7.3.10
> that explicitly states:
> "For example, in OCL 'self' is used to refer to the __context__ element".
>
> The problem is that given any repository model, we can change 3 different
> things: context/owned rule containment, value specification's "body" and
> "constarintedElement" association.
>
> It looks like only 2 of these 3 things may be changed independently --
> either (context + body) that effectively makes "constrainedElement" to be
> derived. Or (context + constrainedElement) that derives "body", or finally
> (body + constrainedElement) that derives context.
I don't see that there is any relationship between context and
constrainedElement. The discussion is pretty clear that the context
element is the namespace that owns the constraint. In the case of OCL, one
can argue that the constraintElement association can be derived from the
features and metaclasses that the expression accesses, but I think its main
purpose is for connecting pre-defined constraints such as "xor" to elements
(as well as natural-language constraints).
> To have an example, consider very simple UML model instance that contains
> class Person with integer attribute age. We want to constraint age to be
> positive ("AIP" -- stands for "age is positive").
>
> There are a lot of possible repository models for this case.
> E.g, we can arrange it as follows:
>
> 1. Model instance owns the Class "Person". Class owns Property "age".
> Property owns Constraint "AIP", Constraint in turn owns ValueSpecification
> like "self > 0". Note that once we set containment context to be a
> property, we HAVE TO use "self" to denote the context element (property),
> so we can not write AIP body as, say "self.age > 0". Note that once we set
> context and body, we can not say that constrainedElement is some
> independent "Actor" -- the pair of context/body effectively derives the
> contextElement.
The "age" property cannot own the constraint, because it is not a namespace.
Moreover, in the case of OCL, 'self' always refers to the _classifier_
context of a constraint. In OCL, a constraint defined in the 'context'
(using the term generically) constrains the property but has the property's
owner as its context classifier.
> We had a chance to arrange model using other way:
> 2. Model owns the Class "Person". Class owns the Property age. The same
> class (in contrast to the Property in the first arrangement) owns
> Constraint "AIP". Assume that at first we set the constrainedElement
> association to reference the property and now we are wondering what may be
> the constraint body. Given the prerequisite that "self" ultimately has to
> express the class (due to "Semantics" part of the 7.3.10 spec), we have no
> chances to define body other than "self.age > 0" -- any other left part of
> the body will not give us the correct preset value for constrainedElement.
This is the most natural approach (at least for me), and is consistent with
the OCL specification.
> It is not the "theoretical" question.
>
> The graphical representation of the repository model should be:
> - the Constraint rectangle,
> - Class rectangle
> - Property label
> - and some link between Constraint rectangle and _something_.
>
> When looking for this "_something_", we can rely either on the
> context/ownedRule association or on the constrainedElement association. I
> am rising this issue mainly to choose one of them to visualize.
I think, perhaps, that the visual links should be of two discernible kinds:
one link for the "context" reference (max. 1 instance) and a different link
for the "constrainedElement" references (unbounded instances). The
semantics of context are special, including that the context determines
when a constraint is evaluated by the system. The "constrainedElement"
seems to me completely unrelated to context.
So, in your AIP example, I think you might have one link (perhaps visually
heavier) between the Constraint rect and the Class rect, and another
(perhaps visually lighter) between the Constraint rect and the Property
label.
>
> Regards,
> Michael
|
|
|
Goto Forum:
Current Time: Fri Apr 19 23:26:14 GMT 2024
Powered by FUDForum. Page generated in 0.02953 seconds |
] 
Search
Help
Register
Login
Home
