Composite vs Component

[jeshaw2]

What are the essential or vital differences between a Composite and a Component?  Except fir scale and packaging, they look the same to me.

[thomaskilian]

Refer to chapters 8 and 9 of Superstructures (just look at the contents/sub-chapters). I'd say that Components are related to things which at last execute something (containing classes) while Composites are more generally looked at as any contstruction of UML Elements.

[jeshaw2]

Thomas;
I read the two chapters but didn't come to the same conclusion.  However, I was squinting my eyes as I read past the examples and allusions that related to the context of their usage, to get a feeling for the underlying semantics.  Then, again, I may not have made my question clear.  I'm comparing Components to Classes having a composite structure.

Both Components and Composite Classes may have public interfaces, exhibit behavior, are assembled from other classes playing specific roles, if designed well can be substituted with others of the same type, are reusable, may be provided by third parties, can be 'wired' in at execution time, etc.   I just don't see a difference other than the notations used to diagram them and the context in which they are defined.

It seems that the major differentating features relate to their implementation & usage rather than their structure.  When I start to design an application, I should not have to be concerned whether I'm desiging a component structure or a composite structure.  IMO, that type of thinking should be deferred to development time.

I postulate that the subject two concepts had their genisis in two different areas of applied computer science and are now, perhaps, merging.

Could it be that UML maintains the distinction between the two to serve the commercial marketing interests of the corporations seated on the UML committee?  (I mean this in a kind and positive way guys  After all, business is business, and I'm well aware, having 30 yrs in corporate software development, of the realities of that environment.)  Or, perhaps, with all the issues the UML committee has on its plate, they just haven't gotten to this issue yet...

[Paolo F Cantoni]

Well,

FWIW, I'm emitting a Component as a Container with Interfaces.  That is, its primary Inheritance is as a Container (such as Model (EA Repository), Subject (EA Project), Package etc.  It (unlike the others) also has one or more Interfaces.  

From my quick overview of the two chapters, it seems to me that Components are a subset of Structured Classes (that is, of Composite Structures).

So, in that sense, I'm agreeing with both Jim:

I postulate that the subject two concepts had their genesis in two different areas of applied computer science and are now, perhaps, merging.

and Thomas:

I'd say that Components are related to things which at last execute something (containing classes) while Composites are more generally looked at as any construction of UML Elements.

 

Paolo

BTW: the emitted Component is also a Namespace.

[jeshaw2]

Paolo;

It (unlike the others) also has one or more Interfaces.

Can you elaborate on this?  What do you mean by "others"?  Structured Classes can, at least in Java, implement multiple interfaces too.

[Paolo F Cantoni]

Paolo;
 Can you elaborate on this?  What do you mean by "others"?  Structured Classes can, at least in Java, implement multiple interfaces too.

I just mean the other container types I'd listed...  Not a general comment.

Should have been more precise...  

Paolo

[jeshaw2]

So, Component Is-A Container.  This would be a significant differentiation feature...

Container objects are designed to hold other objects, including other containers, without concern for the types of objects being contained.  Other objects may access the contained objects freely.  Contained objects are not hidden.

A composite is composed of other objects, but the typing of those objects is restricted specific types and outside objects normally do not have access to them.  Component objects are normally private.

Containers (ergo, components) hold collections, composites own their parts.  

Am I getting closer?

[Paolo F Cantoni]

So, Component Is-A Container.  This would be a significant differentiation feature...

Yes Jim, I think we need to find "differentiation features" between the different constructs to enable us to create better models.  I don't have the attributed quote with me at present, but it goes along the lines of: "All models are wrong, but some are useful..."  We should therefore strive to produce more useful models.

Container objects are designed to hold other objects, including other containers, without concern for the types of objects being contained.

Just so... In general at least, but there are some conditions, from time to time... A colander isn't much use for holding liquids.  Sometimes the nature of what you wish to hold imposes constraints on the container.  For example, a Source (logical) Component doesn't hold binaries.  I have found a way to handle these constraints between the container and contained by means of Policies and Policy Implementations that act as "enforcers" of stereotypical behaviour.

Other objects may access the contained objects freely.  Contained objects are not hidden.

Here, my view is that both these behavioural aspects are managed by the types of policies that may be applied to the container and contained.  One could certainly argue that (by default) contained objects are public, but I don't think there is a requirement of it to be so.

A composite is composed of other objects, but the typing of those objects is restricted specific types and outside objects normally do not have access to them.  Component objects are normally private.

Now this is where things get interesting, in my view.  From meronymy we learn that the "composition" works both ways... The set of types of the composition is governed by the composed object (parent).  But also the type of the composed object is determined by the types of the composing objects.  In my recent musing on this subject, when we look at a composed objects, we need to distinguish between those components that are essential to the composition and those that are just optional adornments.  Over twenty years ago I created the problem of the yellow Rolls Royce:  "I have before me a red Mini, I change one panel/part.  Do I still have a Mini?  I keep changing panels/parts until I have before me what looks like a yellow Rolls Royce.  At what point did I stop being a Mini and become a Roller?"  Answering that question often provides an insight into what is actually going on.
In other words, look at what is essential and what is adornment, for determining the composition.

Containers (ergo, components) hold collections, composites own their parts.

Am I getting closer?

Since you seem to like my shorthand, here's some ideas:

Containers hold things.  They have to be able to hold the kinds of items you need to put in them.
The types of things held in containers are usually (but certainly not exclusively) not of the same type as the container.
The types of the contained items do not define the container.
Each item can be on only one container at a time. (The item can only be inside the innermost container)
The item needs to know which container it's in.
The container may hide (some or all) the items.
Destroying the container doesn't necessarily destroy the contained items (but often may).
Destroying the contained items never destroys the container.

All containers define collections (even if only implicitly  - the objects contained)
Not all collections are containers.
Collections collect(group) things.  They have to be able to collect the kinds of items you need to add to them.
The types of things held in collections are not of the same type as the collection.
The types of the collected items do not define the collection.
An item can be in more than one collection at the same time.
Often the item knows which collections it's in, but sometimes it doesn't.
The collection can never hide the item.
Destroying the collection never destroys the items.
Destroying the items doesn't necessarily destroy the collection, but may.

Composite objects define the types of the components.
The types of the components define the composite (some types are there for adornment and are not intrinsically part of the composite).
A component can only be in one composition at a time.
The composite may hide (some or all) the components.
Destroying the composite always destroys the components.
Destroying the components destroys the composite.
NOTE: in all cases, the items can be removed from the container/collection/composite.  It may be a policy to allow an item to self-remove.

Does that help things?  You should find a clear set of differentiators to allow you to work out which kind of thing you are dealing with.

NOTE; this is still a work-in-progress.  Feedback most welcome - especially where mistakes have been made.  I'm just as eager to get this right as the next...

Cheerz,
Paolo

[size=0]©2005 Paolo Cantoni, -Semantica-[/size]

[jeshaw2]

Paolo;
You have provided much food for thought; it will take a few days to digest and possibly several "reply"s to properly respond.

There is a parallel to your "Yellow Rolls Royce" problem.  It was set forth back in the early 1960s by John Cambell, editor of Analog Magazine. Consider a man with a prosthetic arm who is repairing the engine of his car.  Is the arm part of the human struggling with his environment, or, is the arm part of the environment with which the human is struggeling?  My addition to this is "as we replace various body parts and organs with mechanical devices, at what point does the entity cease to be human?"  "As my body parts are replaced with organic parts donated by others, at what point to I cease to be 'Jim' and I become someone else?"  Even more confusing: "Does the car also define the man (or at least the man's Ego component) such that the struggle is internal and also definitive of the man?"

Principle of Compositionality is the heading under which these issues are discussed.  Do the parts involved in a composition define the whole, enable it to exist and function or simply adorn it.  While all three of these should be shown on a Class Structure diagram, I think only those parts that define the whole should be shown on a Composite Structure diagram  I'm undecided about showing the enabeling parts on a Composite Structure diagram; I think it depends on the essence of the abstraction that is being modeled

More in a little bit, cheers...

[jeshaw2]

In other words, look at what is essential and what is adornment, for determining the composition.

 I think it important to understand just what one is building with a composite structure.  For example:
If I'm building a car, which is basically a device for transporting people from one place to another, then the engine is essential and participates in the composition; the sterio radio is adornment and does not participate.

However, if I'm building a luxury car, which, in addition to transporting people, must do so while coddling the passengers in the lap of luxury, then both the engine and the sterio radio are essential and participate in the composition.

I think we are in agreement thus far...  What may be interesting is:  As Vehicle is specalized into Car and Car is specalized into LuxuryCar, the composition structure changes.  What was adornment becomes a necessary part of the composition, etc.

[jeshaw2]

The types of things held in containers are usually (but certainly not exclusively) not of the same type as the container.
The types of the contained items do not define the container.

Agreed, but for clarification I would also add that: "Containers may hold either a homogeneous or a heterogeneous set of object types."  Should I also add the constraint:  "as long as they all implement a common Interface type?"

[Paolo F Cantoni]

Agreed, but for clarification I would also add that: "Containers may hold either a homogeneous or a heterogeneous set of object types."  Should I also add the constraint:  "as long as they all implement a common Interface type?"

Yes, Agreed!

I'd forgotten that - I think I have policies that govern the homogeneity of contents.

Also, the Interface type is only for containment purposes.  That is, they exhibit the Item Interface with the required policy implementations to implement the policies attached to this particular Container...  (Hopefully that makes sense?)

Cheerz,
Paolo

[sargasso]

Does this mean I cant put loose screws in the fruit bowl, or use my toolbox to hold my lunch?  And what about those things my son puts in his posckets?

Methinks even interface homogeneity may impose unwarranted restriction.

JM2CW

bruce

[Paolo F Cantoni]

Does this mean I cant put loose screws in the fruit bowl, or use my toolbox to hold my lunch?  And what about those things my son puts in his posckets?

Methinks even interface homogeneity may impose unwarranted restriction.

JM2CW

bruce

Not if de guys wid de violin cases say youse can't...  

Besides, I specified very carefully, the ONLY interface they need to be consistent on is the Item (in container) Interface...

Cheerz,
Paolo

[jeshaw2]

Also, the Interface type is only for containment purposes.  That is, they exhibit the Item Interface with the required policy implementations to implement the policies attached to this particular Container...  (Hopefully that makes sense?)

I think I understand. But surely, you don't mean that the item interface is exclusive to a particular Container?

Besides, I specified very carefully, the ONLY interface they need to be consistent on is the Item (in container) Interface...

But then again, perhaps you do mean that...

with the required policy implementations

This interests me...it gets at a thought-seed I've been nurturing in my head.  At the Java level, implmentation of an Interface only requires a class to provide methods (and perhaps attributes) that have names identical to those in the interface declaration.  There are no restrictions on the behavior exhibited by those methods.

Does your use of the term "policy" imply that there may be Container specific behavior specifications that must also be realized in the Java code?

My thought-seed is that a model in UML goes beyond what is to be coded in a language to how it is to be coded to achieve a complete realization.  Many students don't understand this! And that lack of understanding leads to their confusion on drawing and reading UML diagrams.  For example;  At the Java level, navigatable asssociations are implemented in code with an attribute containing a reference to the associated class.  However, the nature of the UML association (aggregate, composition, dependency, etc.) places restrictions on how the programmer may use that reference.  Those restrictions (policies?) are not enforced by the Java translator, but by the  quality control team reviewing the code for complyance with the specifications expressed in the UML model.  My postulate is that I may extend this concept to a more general abstraction that covers a global relationship between UML models and their realization in code.  Since this is obvious to experienced UML modelers, this concept is rarely expressed to students; and they just don't get it for a long time.

My observation is that UML diagrams prepared by programmers are more code centric and those prepared by Architects are more business centric.  This is the fundamental problem of "round-trip" code generation that will take better minds than I to resolve.