Composite vs Component

[jeshaw2]

Paolo;

Each item can be on only one container at a time. (The item can only be inside the innermost container)

Should this read:

The item can only be inside its innermost container

?

Surely an item can be a sibling of another item which happens to be a logically nested container...

[Paolo F Cantoni]

Paolo;

Should this read...

Surely an item can be a sibling of another item which happens to be a logically nested container...

Yes, it should read

The item can only be inside its innermost container

A slip of the mind

Paolo

[jeshaw2]

Good!

If we are in agreement on your use of the term 'Policy' Ref: reply 14 above:

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?

then your comments combined with the UML Superstructure sections referenced by Thomas have been most helpful.

I note that in EA, the Component element is only available in the Component and Deployment tool boxes.  This reenforces my assertion that, for the time being, Components are primarily relevent in the context of packaging and deployment.  The concept of Components has more to do with packaging architecture than with pure object design

I'm a happy camper now.

[Paolo F Cantoni]

[

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?

Yes and No..  I'm saying that the Container will accept as items only those Objects that provide the item Interface it requires.

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...

See above...

This interests me...it gets at a thought-seed I've been nurturing in my head.  At the Java level, implementation 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.

This is where Design by Contract comes in...  If your implementation of the Interface violates one of the conditions of the contract - then it's not much good and the requrier of the interface has every right to Exception at that point.  This is the essence of Eiffel's power.  Both sides specify their expectations of the contract and the Interface will Exception when the contract is violated!

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?

Effectively yes..

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, navigable associations 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 compliance 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 modellers, this concept is rarely expressed to students; and they just don't get it for a long time.

I believe my use of Policies and the use of Design By Contract conditions makes these things explicit.  In my experience there's no such thing as the "bleeding obvious".  Everything should be explicit!
For example, You can only apply Collection specific policies to a Collection.  A Collection requires a shared aggregation and so on... You can define these kinds of rules and validate the model against them.

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.

As an Architect who actually codes I can attest to the dichotomy - but I resolve it by saying that, in principle, one can get from a CIM (Computationally Independent Model - that should be business (and environment - world) focused) to a PSM (Platform Specific Model - that is focused on a particular deployment model) ONLY by a defined series of transformations.

HTH,
Paolo

[jeshaw2]

Well said!

Bravo!