[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[stp-dev] SCA model: the "implementation", "component" and "componentType" elements...
|
Hi,
In order to get a better
understanding of the SCA model, I have spent the past few days looking at the 0.9 SCA specs
from the IBM web site as well as the ecore model and the unit tests available in
the STP CVS.
At this stage, I have some
trouble understanding the relationship between the "implementation", "component"
and "componentType" elements of the actual SCA model and was hoping for some
assistance from those familiar with the code.
According to my understanding of the
written specs:
- a "componentType" is basically the public interface
layer of an "Implementation" with which it has a one to one relationship.
- a "component" is a configured instance of an
"implementation" for which it provides the necessary values for the relevant
config points of its "componentType" layer.
My problem is that I do not see this
reflected by the schema snippets provided with the specs document or the ecore
model in CVS:
- Neither the
"implementation", nor the "componentType" elements reference the other in any
way. In fact the only point of interaction I found is with the element
"AbstractImplementation" which extends "implementation" and contains a
"componentType". (Other extensions of "implementation" don not even care about
"componentType" at all)
- In the same fashion, the model doesn't
establish any direct relationship between "component" and either
"componentType” or "implementation" elements. Again the only point of
interaction I found is an extension of "component" called
"ImplementationComponent" which is meant to contain an "Implementation"
element.
It almost looks like the concepts
and relationships established by the written specs aren't implemented by the
model artefacts the specs said
it should but by children of those artefacts. Is there something I missed? Is it
intended? If it is, why?
Looking at the code in CVS and
the "ComponentTests" class in particular, I got even more
confused:
- Line 74: an Instance of a
class named "component" is produce from a factory but unlike the "component"
element of the ecore model this class
contains an "Implementation" attribute like the "ImplementationComponent" of the ecore model. So:
1- was the "Component" class generated off the "ImplementationComponent" or "Component" element of the ecore
model?
2- why the confusing naming?
- Line 103: the Component
instance has a method named "setAbstractImplementation" which accept a "ComponentType" object as parameter. Again:
1- this
establish a relationship between the "component" and the "componentType" as I
understood it in the written specs but that I didn't see reflected in the model.
2- the naming of the method also seems to establish a 1 to 1
relationship between the concepts of
"ComponentType" and "implementation" (or at least an extension of it)
which again reflect my understanding of the written specs but which I didn't see
in the model (both the schema snippets provided with the specs and the ecore
model in CVS).
It almost looks like the stp.core APIs are more in synch with the written
specs but still with some of the naming convention used by the model. I have
seen the mention of the added abstraction
in the STP online docs but this section of the models isn't mentioned.
The bottom line is that there seems
to be some syncing issues between the written specs, the ecore model and
the code in stp.core.
If it's the case, is there any
plan to bring all of them in
sync? Until that happens, what should I relate to? The code
only?
If it's not the case, and that's
very possible since both SCA and EMF are 2 very new things for me, what do I
miss?
Thanks for the
help.
D.