Eclipse Community Forums: UML2 » Derived Properties Constraints

Help

Home

Home » Modeling » UML2 » Derived Properties Constraints

Show: Today's Messages :: Show Polls :: Message Navigator

Derived Properties Constraints [message #478338]

Mon, 27 April 2009 13:11

Marco Mosconi

Messages: 63
Registered: July 2009

Member

Hi all,

I'm wondering why the UML metamodel doesn't define an attribute on
uml::Property to hold a specification for its derived value. For
Operations similar attributes are defined for body, precondition and
postcondition.
With such an attribute it would be possible to formally specify
derviation constraints directly in the metamodel instead of using the
common workaround to introduce additional operations (which IMHO is
really bad).

Any insights/opinions? (Should I raise an issue at OMG for this?)

Cheers,
Marco

Report message to a moderator

Re: Derived Properties Constraints [message #478339 is a reply to message #478338]

Mon, 27 April 2009 13:30

Christian Damus

Messages: 1270
Registered: July 2009
Location: Canada

Senior Member

--=-BHtAwcd1TjncuVfLX8ZZ
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Marco,

Just add your attribute constraint to the Classifier that defines the
attribute and reference the attribute as one of its constrained
elements. If you like, you can stereotype the constraint as <<derive>>.
You don't need any additional operations for this.

The operation constraints are special because operations are namespaces
that define names for parameters, which their constraints need to be
able to access. Properties aren't namespaces, so they don't need to be
able to own constraints.

HTH,

Christian

On Mon, 2009-04-27 at 15:11 +0200, Marco Mosconi wrote:

> Hi all,
>
> I'm wondering why the UML metamodel doesn't define an attribute on
> uml::Property to hold a specification for its derived value. For
> Operations similar attributes are defined for body, precondition and
> postcondition.
> With such an attribute it would be possible to formally specify
> derviation constraints directly in the metamodel instead of using the
> common workaround to introduce additional operations (which IMHO is
> really bad).
>
> Any insights/opinions? (Should I raise an issue at OMG for this?)
>
> Cheers,
> Marco

--=-BHtAwcd1TjncuVfLX8ZZ
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Marco, 
 
Just add your attribute constraint to the Classifier that defines the attribute and reference the attribute as one of its constrained elements.  If you like, you can stereotype the constraint as <<derive>>.  You don't need any additional operations for this. 
 
The operation constraints are special because operations are namespaces that define names for parameters, which their constraints need to be able to access.  Properties aren't namespaces, so they don't need to be able to own constraints. 
 
HTH, 
 
Christian 
 
 
On Mon, 2009-04-27 at 15:11 +0200, Marco Mosconi wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi all,

I'm wondering why the UML metamodel doesn't define an attribute on
uml::Property to hold a specification for its derived value. For
Operations similar attributes are defined for body, precondition and
postcondition.
With such an attribute it would be possible to formally specify
derviation constraints directly in the metamodel instead of using the
common workaround to introduce additional operations (which IMHO is
really bad).

Any insights/opinions? (Should I raise an issue at OMG for this?)

Cheers,
Marco
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-BHtAwcd1TjncuVfLX8ZZ--

Report message to a moderator

Re: Derived Properties Constraints [message #478340 is a reply to message #478339]

Mon, 27 April 2009 14:10

Marco Mosconi

Messages: 63
Registered: July 2009

Member

Christian,

thanks for the fast reply.
I still think it would be more intuitive and in-line with other features
like inital values, operation bodies etc. to define a derivation
constraint directly on the Property (that corresponds to the 'derive: '
declaration in OCL). Or any other standardized way to specify that this
is a derivation and not an invariant or something else. I believe that
'derive: ...' syntax from OCL is not usable in UML2-Constraints, am I right?
Actually, I want to get code generated from these constraints (and avoid
the mentioned operation workaround used in UML2 codegen). Do you know of
a way to achieve this already? Any chance that the OCLSettingDelegate
thing will be included in Galileo?

Best regards,
Marco

Christian W. Damus schrieb:
> Hi, Marco,
>
> Just add your attribute constraint to the Classifier that defines the
> attribute and reference the attribute as one of its constrained
> elements. If you like, you can stereotype the constraint as <<derive>>.
> You don't need any additional operations for this.
>
> The operation constraints are special because operations are namespaces
> that define names for parameters, which their constraints need to be
> able to access. Properties aren't namespaces, so they don't need to be
> able to own constraints.
>
> HTH,
>
> Christian
>
>
> On Mon, 2009-04-27 at 15:11 +0200, Marco Mosconi wrote:
>
>> Hi all,
>>
>> I'm wondering why the UML metamodel doesn't define an attribute on
>> uml::Property to hold a specification for its derived value. For
>> Operations similar attributes are defined for body, precondition and
>> postcondition.
>> With such an attribute it would be possible to formally specify
>> derviation constraints directly in the metamodel instead of using the
>> common workaround to introduce additional operations (which IMHO is
>> really bad).
>>
>> Any insights/opinions? (Should I raise an issue at OMG for this?)
>>
>> Cheers,
>> Marco
>

Report message to a moderator

Re: Derived Properties Constraints [message #478341 is a reply to message #478340]

Tue, 28 April 2009 12:03

Christian Damus

Messages: 1270
Registered: July 2009
Location: Canada

Senior Member

--=-E+sr6FTYuuWxNVDSgRBq
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Marco,

Initial-value constraints are structurally similar to derivation
constraints. Or, do you mean Property::defaultValue? That's something
different, because it is redefinable (in UML, Constraints are not
redefinable elements).

In the UML model, a constraint is only an invariant if it constrains a
Classifier. If the constraint constrains a Property, then it is an
attribute constraint (initial or derive). Have a look at the semantics
of the Constraint::constrainedElement attribute.

To specify a derive: constraint with OCL in the UML model, you don't
need the concrete syntax of context declarations because the context is
provided by the Constraint element. All you need is the OCL expression.
So, just create a Constraint in the classifier that owns your attribute
and set that attribute as the constraint's constrained element.
Stereotype the constraint as <<derive>> so you know it's not an
initial-value constraint, and create an OpaqueExpression for its
specification with OCL language and your derivation expression in the
body.

Others in this newsgroup can be more helpful for the customization of
the UML2 code generation templates. Ask on the EMF newsgroup about the
status of the OCLSettingDelegate, but I doubt you'll see it in Galileo
given that M7 is imminent.

HTH,

Christian

On Mon, 2009-04-27 at 16:10 +0200, Marco Mosconi wrote:

> Christian,
>
> thanks for the fast reply.
> I still think it would be more intuitive and in-line with other features
> like inital values, operation bodies etc. to define a derivation
> constraint directly on the Property (that corresponds to the 'derive: '
> declaration in OCL). Or any other standardized way to specify that this
> is a derivation and not an invariant or something else. I believe that
> 'derive: ...' syntax from OCL is not usable in UML2-Constraints, am I right?
> Actually, I want to get code generated from these constraints (and avoid
> the mentioned operation workaround used in UML2 codegen). Do you know of
> a way to achieve this already? Any chance that the OCLSettingDelegate
> thing will be included in Galileo?
>
> Best regards,
> Marco
>
> Christian W. Damus schrieb:
> > Hi, Marco,
> >
> > Just add your attribute constraint to the Classifier that defines the
> > attribute and reference the attribute as one of its constrained
> > elements. If you like, you can stereotype the constraint as <<derive>>.
> > You don't need any additional operations for this.
> >
> > The operation constraints are special because operations are namespaces
> > that define names for parameters, which their constraints need to be
> > able to access. Properties aren't namespaces, so they don't need to be
> > able to own constraints.
> >
> > HTH,
> >
> > Christian
> >
> >
> > On Mon, 2009-04-27 at 15:11 +0200, Marco Mosconi wrote:
> >
> >> Hi all,
> >>
> >> I'm wondering why the UML metamodel doesn't define an attribute on
> >> uml::Property to hold a specification for its derived value. For
> >> Operations similar attributes are defined for body, precondition and
> >> postcondition.
> >> With such an attribute it would be possible to formally specify
> >> derviation constraints directly in the metamodel instead of using the
> >> common workaround to introduce additional operations (which IMHO is
> >> really bad).
> >>
> >> Any insights/opinions? (Should I raise an issue at OMG for this?)
> >>
> >> Cheers,
> >> Marco
> >

--=-E+sr6FTYuuWxNVDSgRBq
Content-Type: text/html; charset="utf-8"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Marco, 
 
Initial-value constraints are structurally similar to derivation constraints.  Or, do you mean Property::defaultValue?  That's something different, because it is redefinable (in UML, Constraints are not redefinable elements). 
 
In the UML model, a constraint is only an invariant if it constrains a Classifier.  If the constraint constrains a Property, then it is an attribute constraint (initial or derive).  Have a look at the semantics of the Constraint::constrainedElement attribute. 
 
To specify a derive: constraint with OCL in the UML model, you don't need the concrete syntax of context declarations because the context is provided by the Constraint element.  All you need is the OCL expression.  So, just create a Constraint in the classifier that owns your attribute and set that attribute as the constraint's constrained element.  Stereotype the constraint as <<derive>> so you know it's not an initial-value constraint, and create an OpaqueExpression for its specification with OCL language and your derivation expression in the body. 
 
Others in this newsgroup can be more helpful for the customization of the UML2 code generation templates.  Ask on the EMF newsgroup about the status of the OCLSettingDelegate, but I doubt you'll see it in Galileo given that M7 is imminent. 
 
HTH, 
 
Christian 
 
On Mon, 2009-04-27 at 16:10 +0200, Marco Mosconi wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Christian,

thanks for the fast reply.
I still think it would be more intuitive and in-line with other features
like inital values, operation bodies etc. to define a derivation
constraint directly on the Property (that corresponds to the 'derive: '
declaration in OCL). Or any other standardized way to specify that this
is a derivation and not an invariant or something else. I believe that
'derive: ...' syntax from OCL is not usable in UML2-Constraints, am I right?
Actually, I want to get code generated from these constraints (and avoid
the mentioned operation workaround used in UML2 codegen). Do you know of
a way to achieve this already? Any chance that the OCLSettingDelegate
thing will be included in Galileo?

Best regards,
Marco

Christian W. Damus schrieb:
> Hi, Marco,
>
> Just add your attribute constraint to the Classifier that defines the
> attribute and reference the attribute as one of its constrained
> elements. If you like, you can stereotype the constraint as <<derive>>.
> You don't need any additional operations for this.
>
> The operation constraints are special because operations are namespaces
> that define names for parameters, which their constraints need to be
> able to access. Properties aren't namespaces, so they don't need to be
> able to own constraints.
>
> HTH,
>
> Christian
>
>
> On Mon, 2009-04-27 at 15:11 +0200, Marco Mosconi wrote:
>
>> Hi all,
>>
>> I'm wondering why the UML metamodel doesn't define an attribute on
>> uml::Property to hold a specification for its derived value. For
>> Operations similar attributes are defined for body, precondition and
>> postcondition.
>> With such an attribute it would be possible to formally specify
>> derviation constraints directly in the metamodel instead of using the
>> common workaround to introduce additional operations (which IMHO is
>> really bad).
>>
>> Any insights/opinions? (Should I raise an issue at OMG for this?)
>>
>> Cheers,
>> Marco
>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-E+sr6FTYuuWxNVDSgRBq--

Report message to a moderator