|UML profile with OCL constraints on stereotypes [message #661357]
||Thu, 24 March 2011 06:59
Originally posted by: ss.thinkersfoot.net|
Some background on my story can be found in a posting to the OCL newsgroup:
My task: In Helios (3.6.2 M20110210-1200), to have a UML profile
equipped with OCL constraints and have models applying the profile being
validated against the profile's constraints (OCL constraints written in
the context of the stereotypes).
By now, I am aware that there /might/ different approaches to this
problem (leaving aside the plans for Indigo), I took a step back and
tried the most obvious one to me; attaching constraints + opaque
behaviour (OCL + body) to the profile's stereotypes:
What I got: a UML profile, wrapped up with an EPackage stereotype
(explicitly set NS Uri!). from there, I saw two alternative paths to
take: 1) "dynamic" constraint evaluation or 2) "static" constraint
ad 1): By "defining" the Profile (UML Editor > Profile > Define) and
processing the "body invariants", I get an embedded ecore model of my
profile, with constraint-implementing operations (named after the
However, as can be learnt from
https://bugs.eclipse.org/bugs/show_bug.cgi?id=105199 (last posting):
> Support for dynamically evaluating stereotype (or other) constraints will not
> be provided (at least not in UML2) since this would introduce a circular build
> dependency on MDT OCL. Besides, this a tool-level capability that would be more
> appropriately provided by the UML2 Tools component of MDT (seeing as it already
> depends on both UML2 and OCL).
So, even though, the constraints are reflected in the ecore model, they
are not put to any use. Farewell ...
ad 2) Left with static evaluation, I did the following: turned my
*.profile.uml into a *.genmodel and generated the model code. I verified
that there is not only a standalone ecore model now (with
constraint-implementing operations), but also that the
stereotype-representing Java classes have constraint-checking methods
(and dependencies on OCL packages etc.)
I then built the model code, fired up a Eclipse application, create a
UML model, apply the profile to the model (causing the EPackage and its
class set to be initialised/loaded based on the NSUri lookup), setting
the stereotype to the permissive model element. However, applying the
stereotype fails, with the base_XXX attribute not being set (in the XMI
perspective), the stereotype not showing up in the UML editor view as
"<<...>>" tag to the extended element but as dangling, alien element.
When using approach 1), applying the stereotype works. However, using
1), I don't get constraint evaluation!
So I feel trapped now ... can anybody help me out here?!
|Re: UML profile with OCL constraints on stereotypes [message #662063 is a reply to message #662051]
||Tue, 29 March 2011 03:03
| Ed Willink
Registered: July 2009
Today, probably it doesn't work.
After Indigo, I hope it will, but you'll only need EMF + UML + OCL; no
need for the EMF Validation framework.
On 29/03/2011 07:33, Timothy Marc wrote:
> Hi all,
> did I get it right? It is not possible to add constraints to a profile
> definition and to validate the UML model after applying the
> constrainted profile with the EMF Validation Framework?
> I never tried it, but I thought this would not be a problem? Actually,
> I planned to use OCL exactly this way in a future project.
> Thanks a lot for any remark.
> "Vlad Varnica" schrieb im Newsbeitrag
> Profile is complex but trying to add constraints on existing profile
> is very very hard job. :roll:
> What some of Omondo EclipseUML users do is to add a stereotype on an
> model element and then add a constraints on the same element. It
> means that in the xmi you get stereotype and constraints information
> live synchronized with the diagram.
> They parse the xmi at every 30 seconds and depending on conditions
> execute a predefined task if they parser find the stereotype +
> It works well and really easy to put in place but I am not sure it
> could help you because we add the constraints and stereotype directly
> and manually in the metamodel without any transformation therefore you
> can not add transformation rules because you have no transformation.
> Hope this is understandable :blush:
Powered by FUDForum
. Page generated in 0.02529 seconds