Home » Modeling » UML2 » Implementation of (all) constraints - is it intended?
Implementation of (all) constraints - is it intended? [message #692808] |
Tue, 05 July 2011 09:25 |
Kirsten M. Z. Messages: 132 Registered: July 2010 |
Senior Member |
|
|
Hi @all,
I have a simple question: is there the intention to implement all constraints which can be found in the UML meta model? I saw that most constraints are defined according to the UML 2.x specification. Or rather, there are unimplemented constraints which have a documentation showing the OCL constraint from the UML specification. For example, an initial pseudostate may only have one outgoing transition. So the constraint is defined, documented, but the (generated) code has no implemented validation (Indigo release).
On the other hand, many other constraints are implemented (e.g. no two named elements with the same qualified name).
Therefore, I want to ask if there is a special reason why some constraints are not implemented, e.g. it would break old models which did not care about meticulous constraints, or too many implementations would interfere further development, it would become too slow, etc.
Or as alternative: generating code from the annotated OCL.
Maybe it is implemented already, but I have to use another branch/code generation?
Regards,
Kirsten
|
|
| |
(no subject) [message #693051 is a reply to message #692808] |
Tue, 05 July 2011 16:38 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi Kirsten
The most recent review of the UML Superstructure specification may be
found in http://gres.uoc.edu/OCL2011/pubs/ocl2011_submission_3.pdf which
simplistically concludes that in round numbers, 50% of constraints are
missing, and of those present 50% have errors. These statistics have
changed little between UML 2.0 and 2.4.
The problems are variously due to the lack of good tooling (expect a
major improvement in UML 2.5 which should be fully modelled) and the
lack of man hours (few companies provide significant funding for
specification maintenance, so much of it is voluntary).
Philosophically, no constraint should be unspecified. In practice
perhaps 10 may be unrealistic to specify in OCL. The rest should all
appear one day.
Very similar criticisms could be levelled at the OCL specification. I am
currently modelling this so that OCL 2.4/2.5 might be consistent and
typo-free (http://gres.uoc.edu/OCL2011/pubs/ocl2011_submission_11.pdf).
The specification will be auto-generated from models using Acceleo.
The new Eclipse OCL tooling that can be found as the UML-aligned Pivot
model (http://gres.uoc.edu/OCL2011/pubs/ocl2011_submission_12.pdf) in
the Indigo OCL Examples and Editors uses some OCL from the
specification. A direct OCL to Java code generator is well underway so
that all (debugged) OCL in the OCL specification should form part of the
Eclipse OCL tooling without imposing undue performance penalties. The
same could then be done for UML and QVT.
Regards
Ed Willink
On 05/07/2011 10:25, Kirsten M. Z. wrote:
> Hi @all,
>
> I have a simple question: is there the intention to implement all
> constraints which can be found in the UML meta model? I saw that most
> constraints are defined according to the UML 2.x specification. Or
> rather, there are unimplemented constraints which have a documentation
> showing the OCL constraint from the UML specification. For example, an
> initial pseudostate may only have one outgoing transition. So the
> constraint is defined, documented, but the (generated) code has no
> implemented validation (Indigo release).
>
> On the other hand, many other constraints are implemented (e.g. no two
> named elements with the same qualified name).
>
> Therefore, I want to ask if there is a special reason why some
> constraints are not implemented, e.g. it would break old models which
> did not care about meticulous constraints, or too many implementations
> would interfere further development, it would become too slow, etc.
>
> Or as alternative: generating code from the annotated OCL.
> Maybe it is implemented already, but I have to use another branch/code
> generation?
>
> Regards,
> Kirsten
|
|
|
(no subject) [message #693053 is a reply to message #692808] |
Tue, 05 July 2011 16:38 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi Kirsten
The most recent review of the UML Superstructure specification may be
found in http://gres.uoc.edu/OCL2011/pubs/ocl2011_submission_3.pdf which
simplistically concludes that in round numbers, 50% of constraints are
missing, and of those present 50% have errors. These statistics have
changed little between UML 2.0 and 2.4.
The problems are variously due to the lack of good tooling (expect a
major improvement in UML 2.5 which should be fully modelled) and the
lack of man hours (few companies provide significant funding for
specification maintenance, so much of it is voluntary).
Philosophically, no constraint should be unspecified. In practice
perhaps 10 may be unrealistic to specify in OCL. The rest should all
appear one day.
Very similar criticisms could be levelled at the OCL specification. I am
currently modelling this so that OCL 2.4/2.5 might be consistent and
typo-free (http://gres.uoc.edu/OCL2011/pubs/ocl2011_submission_11.pdf).
The specification will be auto-generated from models using Acceleo.
The new Eclipse OCL tooling that can be found as the UML-aligned Pivot
model (http://gres.uoc.edu/OCL2011/pubs/ocl2011_submission_12.pdf) in
the Indigo OCL Examples and Editors uses some OCL from the
specification. A direct OCL to Java code generator is well underway so
that all (debugged) OCL in the OCL specification should form part of the
Eclipse OCL tooling without imposing undue performance penalties. The
same could then be done for UML and QVT.
Regards
Ed Willink
On 05/07/2011 10:25, Kirsten M. Z. wrote:
> Hi @all,
>
> I have a simple question: is there the intention to implement all
> constraints which can be found in the UML meta model? I saw that most
> constraints are defined according to the UML 2.x specification. Or
> rather, there are unimplemented constraints which have a documentation
> showing the OCL constraint from the UML specification. For example, an
> initial pseudostate may only have one outgoing transition. So the
> constraint is defined, documented, but the (generated) code has no
> implemented validation (Indigo release).
>
> On the other hand, many other constraints are implemented (e.g. no two
> named elements with the same qualified name).
>
> Therefore, I want to ask if there is a special reason why some
> constraints are not implemented, e.g. it would break old models which
> did not care about meticulous constraints, or too many implementations
> would interfere further development, it would become too slow, etc.
>
> Or as alternative: generating code from the annotated OCL.
> Maybe it is implemented already, but I have to use another branch/code
> generation?
>
> Regards,
> Kirsten
|
|
| |
Goto Forum:
Current Time: Wed Sep 25 13:36:08 GMT 2024
Powered by FUDForum. Page generated in 0.04644 seconds
|