On Sat, 14 Apr 2012, Piotr Trojanek wrote:

> On Fri, Apr 13, 2012 at 10:43:01AM +0200, Sylvain Joyeux wrote:
>> On 04/12/2012 05:32 PM, Piotr Trojanek wrote:
>>> For the (A) scenario I would prefer to not reinvent the wheel, but
>>> rather make the ROCK's composition meta-model explicit. I have noted the
>>> following check-list of issues, which need to be addressed by the
>>> meta-model: aggregation of components and connections, promotion and
>>> renaming of ports (and operations).
>> There is much more in the Rock model:
>>
>> - component abstractions (a.k.a services)
>> - port mappings from services to concrete components (i.e. cases
>> where services and components have different port names)
>> - Rock does not support promotion of operations, and I currently
>> don't plan to include that. Operations are neither used nor needed
>> at the modelling level so far in our use cases. Note, however, that
>> in the Roby plan model the operations (and their promotions) could
>> be represented easily using events. So, if you do decide to go on
>> with it we could support it easily in Rock.
>> - specializations (ability to "mixin" composition model
>> transformations based on the concrete components selected to
>> instanciate the composition)
>> - refinement of compositions (ability to create composition models
>> that are submodels, or "subclass" of more generic ones)
>
> Indeed, there is a lot! And that's why it is important to formalize it
> explicitly and also provide some fancy tools for all those features :-)
>
> Conceptually all of the above inheritance-related assembly-primitives resembles
> what is already there in object-oriented languages. Thus, there is no really
> much to (re-)invent and it is also easy to find some use-case for all those
> features. Of course, there are some subtle issues (e.g. name clashes), but it
> is just a design decision how to deal with them.

I do not agree that what we need for _component-based_ systems is already
there in _object oriented_ tooling! There is a fundamental difference
between both, with respect to composition: OO relies on the "is-a"
relationship, while CB uses "conforms to" and "is represented by". The
following paper explains this essential difference (which should also be
reflected in the tooling):
<http://atlanmod.emn.fr/www/papers/OnTheUnificationPowerOfModels.pdf>

>> FYI, Rock's underlying data structure is a plan, and therefore also supports
>> sequencing of start / stop -- and in principle much more. Unfortunately, the
>> current model chain is (1) model compositions and (2) transform that model
>> into a plan. In the long run, I want to represent everything inside an
>> (extended) plan model so that one could use every Roby plan primitive to
>> describe compositions, and therefore, in principle, represent sequencing of
>> the updates as well.
>
> I think, that there is something more fundamental with this issue. What
> ROCK/Roby is doing (and what we are talking about in the context of
> "Simulink-like" composition) is to couple the "operational" and "architectural"
> aspects within a single module in order to reuse it.

Such coupling is a very fine feature for efficiency reasons, but it should
not be _hard-coded_ into tools and models.

> Constructing and using of
> such a compounds makes all of this (at least for me) closer and closer to a
> full-featured DSL (at least conceptually).
>

On Sat, Apr 14, 2012 at 03:59:42PM +0200, Herman Bruyninckx wrote:
> >There is much more in the Rock model:
> >
> > - component abstractions (a.k.a services)
>
> I am somewhat puzzled by this terminology, so I would welcome more details :-)
> I guess that the "service" is what the "end users" see, and the "component"
> is what provides the services?

The concept of "service" seems to be already in RTT (it is not ROCK-specific).
However it is not reflected in the meta-model of BRIDE (why?).

--
Piotr Trojanek

On 04/14/2012 03:59 PM, Herman Bruyninckx wrote:
> On Fri, 13 Apr 2012, Sylvain Joyeux wrote:
>
>> On 04/12/2012 05:32 PM, Piotr Trojanek wrote:
>>> For the (A) scenario I would prefer to not reinvent the wheel, but
>>> rather make the ROCK's composition meta-model explicit. I have noted the
>>> following check-list of issues, which need to be addressed by the
>>> meta-model: aggregation of components and connections, promotion and
>>> renaming of ports (and operations).
>> There is much more in the Rock model:
>>
>> - component abstractions (a.k.a services)
>
> I am somewhat puzzled by this terminology, so I would welcome more
> details :-)
> I guess that the "service" is what the "end users" see, and the "component"
> is what provides the services?
The "data services" are abstract component models, i.e. an
ImageProvider, or a DenseImageProvider. I don't know what you mean by
"end users", though, as the end users of these modelling tools usually
understands the actual components better than these abstractions.

>> - port mappings from services to concrete components (i.e. cases
>> where services and components have different port names)
>
> This is (a necessary) part of the "port promotion" semantics, in my view on
> things.
I am, for my side, puzzled by the "Port promotion" terminology. It was
used, so far, in the context of creating ports on compositions by
"exporting" ports (that's the Rock terminology) from components from
within that composition. What I was talking about here does not fit this
definition.

>> I don't know how far you want to go with your model, though.
>>> Next step is to derive at least
>>> 2 tools from the meta-model: textual (preferable with ROCK-compatible
>>> syntax) and graphical (with the notation aligned with conventions of
>>> diagrams in the RTT manuals). The goal is to reuse/refine what's already
>>> in ROCK and extend its capabilities with graphical tooling.
>> I'm obviously all for it ;-)
>>
>> FYI, Rock's underlying data structure is a plan, and therefore also
>> supports sequencing of start / stop -- and in principle much more.
>> Unfortunately, the current model chain is (1) model compositions and (2)
>> transform that model into a plan. In the long run, I want to represent
>> everything inside an (extended) plan model so that one could use every
>> Roby plan primitive to describe compositions, and therefore, in
>> principle, represent sequencing of the updates as well.
>
> You lost me a bit here... But since you are talking about "the long run",
> that is probably not a problem :-)
Well. The underlying plan structure includes synchronization primitives
that are built around event systems, such as: temporal constraints,
event generalization, rendez vous and so on. The current issue *at the
implementation level* is that there is (1) a composition model that is
in step (2) translated into the plan model. Which makes these
synchronization primitives unavailable when modelling the compositions.

In the long run, I plan to directly express the composition model as an
extension of the plan model, allowing to mix both freely. It is actually
a pretty straightforward extension of the current system.

On Sat, 14 Apr 2012, Piotr Trojanek wrote:

> On Thu, Apr 12, 2012 at 08:44:27PM +0200, Herman Bruyninckx wrote:
>>> [...]
>>> To some extent Sylvian is right - a lot of what we need may be already
>>> there (in ROCK). But to stress the point: we want the models to be
>>> *explicit* and tools, which are derived from these models.
>>
>> "derived from" is not the most correct expression, I think. The tools must
>> support the operations (transformations, aggregations,...) that are
>> defined formally on the model level.
>
> When saying "derived from" I am thinking mostly about model editors. I agree,
> that this term is not really fortunate for all the rest. I just wanted
> to avoid "model-driven", which is already over-used :-)
>
>>> At this moment, there are at least two already identified scenarios: (A)
>>> "ROCK-like" composition (i.e. as supported by the implicit ROCK
>>> meta-model and Ruby-based tools) and (B) "Simulink-like" composition
>>> (i.e. as discussed few days ago and partially implemented in FBSched).
>>> These are by no means exhaustive, but they seem to cover a fairly large
>>> number of use-cases and that's why they deserve some special attention.
>>
>> Maybe a good start is to try to make both of them formally explicit?
>
> I was also thinking about this. This is not so difficult for (A) and
> after getting some grips with Ruby I am already able to dig most of them
> out from the ROCK. With (B) there are at least 3 options identified
> (with references included in my previous email), so the only question is
> "which one to choose?" (see below).
>
>>> I can also think about (C) "plan-like" scenario, with the focus on the
>>> control-flow instead of data-flow composition like in (B). However, this
>>> is even more difficult and I guess, that for any non-trivial use-case it
>>> requires manual coding/scripting (so let's skip it at this moment).
>>
>> Wait, not so fast: I am interested in getting to know one or more use cases
>> for which "class C" is the best solution.
>
> With (C) I was thinking of composition like in languages, which traditionally
> belong to the sequencer/executive layer (e.g. TDL, PLEXIL). I am not even
> really sure how do they fit into component-based design...

that's also my intuition for now. That does not mean that these aspects
need not be modelled, but not inside of a "Component Model".

> However, my
> intuition tells me, that there are use-cases where it makes sense to "compose"
> (or maybe "coordinate"?) operations of two components into a single piece.

Sure.

> Doing it with the general purpose programming language (e.g. C++ or Lua) is
> extremely error-prone. This is why I think, that DSMLs can be useful here.
>
> What Sylvian said is that "Rock's underlying data structure is a plan".
> I guess, that we may be talking about similar kind of composition (?).
>
>>> I would like to propose/discuss the following road-map.
>>>
>>> For the (A) scenario I would prefer to not reinvent the wheel, but
>>> rather make the ROCK's composition meta-model explicit.
>>
>> You have my support for this suggestion. I expect that we will all learn
>> from this effort, in the worst case.
>>
>>> I have noted the
>>> following check-list of issues, which need to be addressed by the
>>> meta-model: aggregation of components and connections, promotion and
>>> renaming of ports (and operations).
>>
>> While being active on this job anyway, it would also be useful to make an
>> "ontology" of terminology: "what term means what in which context?".
>> For example: do we make a distinction between "composition" and
>> "aggregation"? (I do not, and prefer composition, because of the shared
>> semantic origin with "component". Hence, my preference for the terms
>> "composability" and "compositionality".)
>
> Definitely all those names should be clarified, but what I prefer is to
> look for already established "ontology" instead of defining a new one.
>
> I was trying to locate some "reference" terms for what we are speaking
> about. What Szyperski and OMG use is the 'component assembly' and
> 'composite components'. To be more specific [1]:
>
> ``Component instances may be composed together to form new component
> types; these latter are called <<composite component types>> or
> sometimes <<component assemblies>>. The component instances that
> comprise the internal structure of a composite component are referred to
> as its <<parts>>. Those parts are connected to one another and to their
> containing composite component via <<connectors>> between their
> respective ports.''
>
> I did not found any references to "aggregation", so please excuse me and
> let's forget about this term :-)

One should not forget about it, but say explicitly that it is a 100%
synonym for composition (in our model context). Unless someone finds a
reason to make a semantic differentiation between both.
The one that is used in OO, if I am not mistaken is the following:
aggregation takes parts together and makes them available as one new part,
but the parts themselves do not depend on each other, or rather, they can
exist by themselves; in composition, that is not the case: the parts loose
their "life" as soon as the composite is removed.

>> I consider 'port renaming' as one of the concepts that belong to the
>> semantics of "composition", as one particular example of the
>> "namespace scoping" that a composite provides. And this, in turn, is
>> one part of the "closure" concept that belongs naturally at the
>> composition level; that is, the scope until which more internal
>> components can 'export' names as 'global' to their own scope.
>
> Regarding the "promotion" both Szyperski and OMG use 'delegation' for
> the incoming requests/data. OMG use also 'propagation' for the outgoing
> data [2]. I have not found any reference to "renaming" and I think, that
> this term is not really necessary in the presence of the former two.
>
>> There are more semantic primitives that naturally belong to the
>> composition context; but what is the minimum?
>
> I like this question but I am not ready to answer it (yet!) :(

This discussion is a common effort to try to get that far :-)

>>> Next step is to derive at least
>>> 2 tools from the meta-model: textual (preferable with ROCK-compatible
>>> syntax)
>>
>> A metametamodel of the semantic meaning of that syntax will allow
>> model-to-model transformations to other "DSLs".
>
> I am not sure if I understand what is the "metametamodel of the semantic
> meaning". Do you mean "a semantic domain" for the component/composition
> meta-model?

>
>>> and graphical (with the notation aligned with conventions of
>>> diagrams in the RTT manuals). The goal is to reuse/refine what's already
>>> in ROCK and extend its capabilities with graphical tooling.
>>
>>> For the (B) scenario the main problem I see is not in the composition
>>> primitives (i.e. data-flow connections of ports with the DAG/Polytree
>>> restrictions applied),
>>
>> I see no reasons to limit the _topology_ of the composition to DAGs or
>> Polytrees; the 'serialization' can be done on graphs, via (possibly multiple
>> alternative) scheduling data structures at the composite level. Each of
>> these _will_ superimpose a DAG/Polytree on top of the graph topology.
>
> Yes, but for DAG/Polytree is it clear how to 'serialize' just from their
> topology.
>
>>> but in specification of the order of
>>> activation/evaluation (the data-flow computation model is not precise
>>> enough here).
>>
>> I think you implicitly refer to the _topological_ part of the "data flow
>> computation model"; I indeed see the "schedulers" as a minimum extra part
>> of that model. (Other extras are: data 'forgetting' policies, execution
>> triggering, ...)
>
> Yes, I refer only to topological part of the data flow. In case of
> graphs one needs some 'hint' primitives or heuristics to
> choose/calculate one of the many possible alternatives.
>
>>> Identified "best practices" include: "hidden"
>>> semantics/heuristics of Simulink [1], similar solution by Scicos [2] and
>>> guard expressions of Erlang [3]. For me it is still not clear how these
>>> approaches can be glued with the existing 'connection policy' mechanism
>>> and which of them is "the way to go". One idea is not to stick with just
>>> one of them, but to introduce an abstract 'activation policy'
>>> concept/enumeration into meta-model (but I would still really want to
>>> find "the way to go"!).
>>
>> I am not completely sure I understand the last sentences above...
>
> Sorry, I was not clear here... What I meant was to include more than one
> alternative set of primitives for the "Simulink-like" composition.
>
>>> As soon, as we formalize some composition/activation primitives for (B),
>>> we should evaluate them with some of the "reference use-cases" (and we
>>> need to find them anyway!).
>>
>> Absolutely. I would even suggest to start with categorizing them: control
>> diagrams, Bayesian networks, FSMs, kin&dyn solvers,...
>>
>>> Yes, evaluate, because the question is not what information to get from
>>> the designer, but how he/she wants to express it.
>>>
>>> Ideally, I would like to integrate both (A) and (B) scenarios into a
>>> common formal model. However, I do not think that it is possible with
>>> the current state of research/development.
>>
>> Why not...? I see not a single fundamental showstopper.
>
> Sorry once again... I was thinking about finding a common semantical domain for
> assigning the meaning to all the "composition primitives", e.g. 'port
> promotion' and 'guard expression'. In fact, the meanings will be defined by the
> model-to-code transformations into the RTT/C++ domain.
>
>>> Regarding the technology: my idea is to use XText for textual and GMF
>>> for graphical notations respectively. EMFText, was the second candidate
>>> after XText. However, it imposes some limitations on syntax related to
>>> unordered grouping of attributes. Motivation for GMF is that all the
>>> other "easy to use" frameworks make customization of the graphical
>>> notation much more difficult. Besides, GMF is already used in BRIDE,
>>> which makes the integration somehow easier.
>>
>> The big lack in all these examples is a (set of) formal constraint
>> languages...
>
> Indeed, but I had some intentions for that. I already had some "clash" about
> constraint languages on this mailing list (at the time of the alpha-release of
> BRIDE). Now I decided to not mention about them just to avoid disturbance of
> the essential part of the discussion (sorry, I should be more explicit about
> this).
>
> Constraints are complementary to the meta-models and when I say "meta-model",
> then what I really mean is "Ecore+constraint annotations".

Oops, that is a too high lock-in as far as I am concerned.

> AFAIK the only
> constraint language capable of annotating the meta-model itself is the OCL.
> However, there are other languages, which are better/easier to integrate with
> the textual/graphical editors (e.g. EVL, which is already used in BRIDE)...

I think we will need lots of constraint languages, sooner or later.

> I am afraid, that it is not possible to stick with a single constraint language
> for the whole toolchain at this moment. This is not good, as some helper
> functions can/should be reused within different contexts (e.g. in graphical and
> textual editors, code generators, ...). This means a violation of the 'Don't
> Repeat Yourself' rule, but I see no way to avoid this.
>
> In short, I prefer to use OCL where it is possible. If something can not be
> done with OCL, then I prefer to use some other language than not applying
> constraint at all or hacking with Java.
>
> [1] OMG, "Robotic Technology Component Specification", Version 1.0,
> April 2008.
>
> [2] OMG, "Deployment and Configuration of Component-based Distributed
> Applications Specification", Version 4.0, April 2006.
>
> --
> Piotr Trojanek

Thanks for keeping this discussion alive! I hope you (or someone else) will
be able to make a useful summary out of it, that can be consolidated in a
tool roadmap and an "ontology" :-)

Herman

Zitat von Piotr Trojanek <piotr [dot] trojanek [..] ...>:

> On Thu, Apr 12, 2012 at 08:44:27PM +0200, Herman Bruyninckx wrote:
>> > [...]
>> >To some extent Sylvian is right - a lot of what we need may be already
>> >there (in ROCK). But to stress the point: we want the models to be
>> >*explicit* and tools, which are derived from these models.
>>
>> "derived from" is not the most correct expression, I think. The tools must
>> support the operations (transformations, aggregations,...) that are
>> defined formally on the model level.
>
> When saying "derived from" I am thinking mostly about model editors.
> I agree,
> that this term is not really fortunate for all the rest. I just wanted
> to avoid "model-driven", which is already over-used :-)
>
>> >At this moment, there are at least two already identified scenarios: (A)
>> >"ROCK-like" composition (i.e. as supported by the implicit ROCK
>> >meta-model and Ruby-based tools) and (B) "Simulink-like" composition
>> >(i.e. as discussed few days ago and partially implemented in FBSched).
>> >These are by no means exhaustive, but they seem to cover a fairly large
>> >number of use-cases and that's why they deserve some special attention.
>>
>> Maybe a good start is to try to make both of them formally explicit?
>
> I was also thinking about this. This is not so difficult for (A) and
> after getting some grips with Ruby I am already able to dig most of them
> out from the ROCK. With (B) there are at least 3 options identified
> (with references included in my previous email), so the only question is
> "which one to choose?" (see below).
>
>> >I can also think about (C) "plan-like" scenario, with the focus on the
>> >control-flow instead of data-flow composition like in (B). However, this
>> >is even more difficult and I guess, that for any non-trivial use-case it
>> >requires manual coding/scripting (so let's skip it at this moment).
>>
>> Wait, not so fast: I am interested in getting to know one or more use cases
>> for which "class C" is the best solution.
>
> With (C) I was thinking of composition like in languages, which traditionally
> belong to the sequencer/executive layer (e.g. TDL, PLEXIL). I am not even
> really sure how do they fit into component-based design... However, my
> intuition tells me, that there are use-cases where it makes sense to
> "compose"
> (or maybe "coordinate"?) operations of two components into a single piece.
> Doing it with the general purpose programming language (e.g. C++ or Lua) is
> extremely error-prone. This is why I think, that DSMLs can be useful here.
>
> What Sylvian said is that "Rock's underlying data structure is a plan".
> I guess, that we may be talking about similar kind of composition (?).
>
>> >I would like to propose/discuss the following road-map.
>> >
>> >For the (A) scenario I would prefer to not reinvent the wheel, but
>> >rather make the ROCK's composition meta-model explicit.
>>
>> You have my support for this suggestion. I expect that we will all learn
>> from this effort, in the worst case.
>>
>> >I have noted the
>> >following check-list of issues, which need to be addressed by the
>> >meta-model: aggregation of components and connections, promotion and
>> >renaming of ports (and operations).
>>
>> While being active on this job anyway, it would also be useful to make an
>> "ontology" of terminology: "what term means what in which context?".
>> For example: do we make a distinction between "composition" and
>> "aggregation"? (I do not, and prefer composition, because of the shared
>> semantic origin with "component". Hence, my preference for the terms
>> "composability" and "compositionality".)
>
> Definitely all those names should be clarified, but what I prefer is to
> look for already established "ontology" instead of defining a new one.
>
> I was trying to locate some "reference" terms for what we are speaking
> about. What Szyperski and OMG use is the 'component assembly' and
> 'composite components'. To be more specific [1]:
>
> ``Component instances may be composed together to form new component
> types; these latter are called <<composite component types>> or
> sometimes <<component assemblies>>. The component instances that
> comprise the internal structure of a composite component are referred to
> as its <<parts>>. Those parts are connected to one another and to their
> containing composite component via <<connectors>> between their
> respective ports.''
>
> I did not found any references to "aggregation", so please excuse me and
> let's forget about this term :-)
>
>> I consider 'port renaming' as one of the concepts that belong to the
>> semantics of "composition", as one particular example of the
>> "namespace scoping" that a composite provides. And this, in turn, is
>> one part of the "closure" concept that belongs naturally at the
>> composition level; that is, the scope until which more internal
>> components can 'export' names as 'global' to their own scope.
>
> Regarding the "promotion" both Szyperski and OMG use 'delegation' for
> the incoming requests/data. OMG use also 'propagation' for the outgoing
> data [2]. I have not found any reference to "renaming" and I think, that
> this term is not really necessary in the presence of the former two.
>
>> There are more semantic primitives that naturally belong to the
>> composition context; but what is the minimum?
>
> I like this question but I am not ready to answer it (yet!) :(
>
>> >Next step is to derive at least
>> >2 tools from the meta-model: textual (preferable with ROCK-compatible
>> >syntax)
>>
>> A metametamodel of the semantic meaning of that syntax will allow
>> model-to-model transformations to other "DSLs".
>
> I am not sure if I understand what is the "metametamodel of the semantic
> meaning". Do you mean "a semantic domain" for the component/composition
> meta-model?
>
>> >and graphical (with the notation aligned with conventions of
>> >diagrams in the RTT manuals). The goal is to reuse/refine what's already
>> >in ROCK and extend its capabilities with graphical tooling.
>>
>> >For the (B) scenario the main problem I see is not in the composition
>> >primitives (i.e. data-flow connections of ports with the DAG/Polytree
>> >restrictions applied),
>>
>> I see no reasons to limit the _topology_ of the composition to DAGs or
>> Polytrees; the 'serialization' can be done on graphs, via (possibly multiple
>> alternative) scheduling data structures at the composite level. Each of
>> these _will_ superimpose a DAG/Polytree on top of the graph topology.
>
> Yes, but for DAG/Polytree is it clear how to 'serialize' just from their
> topology.
>
>> >but in specification of the order of
>> >activation/evaluation (the data-flow computation model is not precise
>> >enough here).
>>
>> I think you implicitly refer to the _topological_ part of the "data flow
>> computation model"; I indeed see the "schedulers" as a minimum extra part
>> of that model. (Other extras are: data 'forgetting' policies, execution
>> triggering, ...)
>
> Yes, I refer only to topological part of the data flow. In case of
> graphs one needs some 'hint' primitives or heuristics to
> choose/calculate one of the many possible alternatives.
>
>> >Identified "best practices" include: "hidden"
>> >semantics/heuristics of Simulink [1], similar solution by Scicos [2] and
>> >guard expressions of Erlang [3]. For me it is still not clear how these
>> >approaches can be glued with the existing 'connection policy' mechanism
>> >and which of them is "the way to go". One idea is not to stick with just
>> >one of them, but to introduce an abstract 'activation policy'
>> >concept/enumeration into meta-model (but I would still really want to
>> >find "the way to go"!).
>>
>> I am not completely sure I understand the last sentences above...
>
> Sorry, I was not clear here... What I meant was to include more than one
> alternative set of primitives for the "Simulink-like" composition.
>
>> >As soon, as we formalize some composition/activation primitives for (B),
>> >we should evaluate them with some of the "reference use-cases" (and we
>> >need to find them anyway!).
>>
>> Absolutely. I would even suggest to start with categorizing them: control
>> diagrams, Bayesian networks, FSMs, kin&dyn solvers,...
>>
>> >Yes, evaluate, because the question is not what information to get from
>> >the designer, but how he/she wants to express it.
>> >
>> >Ideally, I would like to integrate both (A) and (B) scenarios into a
>> >common formal model. However, I do not think that it is possible with
>> >the current state of research/development.
>>
>> Why not...? I see not a single fundamental showstopper.
>
> Sorry once again... I was thinking about finding a common semantical
> domain for
> assigning the meaning to all the "composition primitives", e.g. 'port
> promotion' and 'guard expression'. In fact, the meanings will be
> defined by the
> model-to-code transformations into the RTT/C++ domain.
>
>> >Regarding the technology: my idea is to use XText for textual and GMF
>> >for graphical notations respectively. EMFText, was the second candidate
>> >after XText. However, it imposes some limitations on syntax related to
>> >unordered grouping of attributes. Motivation for GMF is that all the
>> >other "easy to use" frameworks make customization of the graphical
>> >notation much more difficult. Besides, GMF is already used in BRIDE,
>> >which makes the integration somehow easier.
>>
>> The big lack in all these examples is a (set of) formal constraint
>> languages...
>
> Indeed, but I had some intentions for that. I already had some "clash" about
> constraint languages on this mailing list (at the time of the
> alpha-release of
> BRIDE). Now I decided to not mention about them just to avoid disturbance of
> the essential part of the discussion (sorry, I should be more explicit about
> this).
>
> Constraints are complementary to the meta-models and when I say "meta-model",
> then what I really mean is "Ecore+constraint annotations". AFAIK the only
> constraint language capable of annotating the meta-model itself is the OCL.
> However, there are other languages, which are better/easier to integrate with
> the textual/graphical editors (e.g. EVL, which is already used in BRIDE)...
> I am afraid, that it is not possible to stick with a single
> constraint language
> for the whole toolchain at this moment. This is not good, as some helper
> functions can/should be reused within different contexts (e.g. in
> graphical and
> textual editors, code generators, ...). This means a violation of the 'Don't
> Repeat Yourself' rule, but I see no way to avoid this.

IMO it's not bad to have not *one* constraint language. It depends
what we want to do with the constraints. In case of tooling: OCL is
good enough, because there is great support in the Ecore and Eclipse
eco-system.

Nico

>
> In short, I prefer to use OCL where it is possible. If something can not be
> done with OCL, then I prefer to use some other language than not applying
> constraint at all or hacking with Java.
>
> [1] OMG, "Robotic Technology Component Specification", Version 1.0,
> April 2008.
>
> [2] OMG, "Deployment and Configuration of Component-based Distributed
> Applications Specification", Version 4.0, April 2006.
>
> --
> Piotr Trojanek
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>