Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Michael Golubev is currently offline Michael GolubevFriend
Messages: 373
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 Go to previous message
Eclipse UserFriend
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 Go to previous message
Eclipse UserFriend
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
Previous Topic:MDT Project Provisioned
Next Topic:Interest in MDT
Goto Forum:
  


Current Time: Fri Nov 21 16:51:06 GMT 2014

Powered by FUDForum. Page generated in 0.03580 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software