THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
A component can refer to three disctinct concepts :
- a ComponentType that is a type (described in a java annoted file, a .componentType file or a .composite file)
- a Component that describes an instance of ComponentType (described by the content of a <component> tag in a .composite file)
- a ComponentInstance that is a runtime instance.
For example, if you take the following components and instanciate CompositeB:
- CompositeA
- Component1 - implementation.java -> MyClass - scope = COMPOSITE
- Component2 - implementation.java -> MyClass - scope = COMPOSITE
- CompositeB
- Component3 - implementation.composite -> Composite A
- Component4 - implementation.composite -> Composite A
There are 3 ComponentType : CompositeA, CompositeB and MyClass.
There are 4 Component : Component1, Component2, Component3 and Component4.
There are 7 ComponentInstance : The enclosing CompositeB instance (let's call it /), /Component3, /Component4, /Component3/Component1, /Component3/Component2, /Component4/Component1, /Component4/Component2.
In the actual implementation, there is not a class associated for each concept, this leads to some problems especially in the handling of the "scope" of components.
The ComponentType class is inherited by Composite and CPPImplementation, but where Composite actually is the reifiction of a ComponentType, CPPImplementation is the reification of a Component.
There is no reification for ComponentInstance except for the opaque user-provided implementation of the component.
A short-term solution would be to clone the Composite class each time a Component of this type is instanciated.
This way, these instances of Composite and CPPImplementation would both be the reification of a ComponentInstance.
The cloned Composite instance would be the reification of the ComponentType.
A longer term solution would be to clean the model and associate a class to each concept. A firt attempt in this direction is presented in the following UML diagram :
