Author Topic: Collections, Containers, Composites & Nests  (Read 7096 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5848
  • Karma: +71/-75
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Collections, Containers, Composites & Nests
« on: September 21, 2005, 01:39:39 pm »
Jim Shaw has asked me to document some thoughts on these topics.  Here they are...

They are a work in progress and feedback most welcome. 8)

------------------------------------------------------------------------
[size=16]Meronymy[/size]
Meronymy (n): the semantic relation that holds between a part and the whole [synonym: part to whole relation].  In UML terms, this is related to the notion of aggregation.
The AggregationKind adornment
We are familiar with the UML AggregationKind enumeration type and its corresponding diamond shaped adornment.  Since there are only two effective AggregationKind literals (shared and composite), and we are about to define four types of meronymy, we won’t use the terms shared and composite aggregation, but will use the diamond adornment – either filled or open as required.
Policies
Some aspects of the following attributes and behaviours may be controlled by the adoption of various policy directions and their accompanying policy variant implementation.  For example, it can be a policy decision as to whether an item may self-remove from a collection or grouping.  The policy would be entitled: Item self-removal.  The two implementations would be: Item can self-remove and the other Item cannot self-remove.  As each instance of the whole is created, the appropriate policy implementations are applied and the behaviour adjusted accordingly.
Where a behaviour may be policy controlled the denotation [Policy] is added.

[size=16]Containers / Collections / Compositions / Nests[/size]

Nest
Nests hold items structurally (similar to composites).  They have to be able to hold the kinds of items you need to put in them.  [Policy]
Nested items are either all classifiers or all instances (not a mixture).
Nested items cannot be references.
There can be only one item of a given name in a nest.
The types of items held in nests are usually (but certainly not exclusively) not of the same metatype as the container.  [Policy]  Where the same metatype may be nested, then we have the possibility of recursion.
The types of the nested items do not define the nest.
Each classifier item can be in more than one nest at a time.  But a specific instance item is always only in one nesting instance. 1
The item needs to know which nest it's in.
The nest may restrict access to (some or all) the items.  [Policy]
Destroying the nest necessarily destroys the nested items.2
Destroying the nested items never destroys the nest.
Nesting without Stereotype.  (But see footnote 1)

Container
Containers contain items (physically but not structurally).  They have to be able to contain the kinds of items you need to put in them.  [Policy]
The types of items held in containers are usually (but certainly not exclusively) not of the same type as the container.  [Policy]
Contained items may be references.
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 its innermost container)
The item needs to know which container it's in.
The container may restrict access to (some or all) the items.  [Policy]
Destroying the container doesn't necessarily destroy the contained items (but often may).  [Policy]
Destroying the contained items never destroys the container.
If the container can destroy the items: Filled diamond Association with Stereotype: «contain».
If the container cannot destroy the items: Open diamond Association with Stereotype: «contain».

Collection
All containers define collections (even if only implicitly - the objects contained)
Not all collections are containers.  [Policy]
Collections collect (group) things.  They have to be able to collect the kinds of items you need to add to them.  [Policy]
The types of items held in collections are usually (but certainly not exclusively) not of the same type as the collection.
Collected items may be references.
The types of the collected items do not define the collection.
An item can be in more than one collection at the same time.  [Policy]
Often the item knows which collections it's in, but sometimes it doesn't.  [Policy]
The collection may never restrict access to the items.
Destroying the collection never destroys the items.
Destroying the items doesn't necessarily destroy the collection, but may do.
Open diamond Association with Stereotype: «include».

Composite
Composite objects define the types of the composing items.  The items are functionally and/or structurally related to the composite.  [Policy]
The types of the items define the composite (but some types are there for adornment and are not intrinsically part of the composite).  [Policy]
An item instance can only be in one composition at a time.
The composite may restrict access to (some or all) the items.  [Policy]
Composing items cannot be references.
Destroying the composite always destroys the item.
Destroying the items destroys the composite.
Filled diamond Association with Stereotype «comprise».

NOTE: in all cases, the items can be removed from the container / collection / composite / nest.  It may be a policy to allow an item to self-remove.


1  NOTE: For browser purposes, where a single nesting is defined, the nestling shall be physically placed (nested) under the nest.  Where more than one nesting is defined, one will be designated the «physical» nesting and the nestling placed under that nest.  The other nesting(s) will be designated «symbolic».
2  If an item is nested in more than one nest, then only that nestling is destroyed.  If that nestling is the «physical» nesting, then the «physical» nesting is transferred to one of the remaining nestings.
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #1 on: September 22, 2005, 11:48:28 pm »
Thanks for starting this thread Paolo.  It is interesting to see the development of these ideas across the other threads of discussion, yet have them pulled together like this.

My thoughts...

My cognitative level is at a lower level of abstraction than yours.  That presents a refreshing challange for me. :)

Your notational methods seem good to me.  I'll be adopting them.

With respect to Nests:
Nests are related to the Part_of Meronymy.

Quote
Each classifier item can be in more than one nest at a time.
I'm still not sure I understand this statement.  I can't decide if it important or trivial...I think that this may relate more to non-Java like languages...perhaps browsers?

With respect to Collections:  
Collections are related to the Member_of [Group] Meronymy.

Quote
Collections collect (group) things.  
How about "Collections group things based on a subset of their attributes"?

Also: "parts do not necessarily have a structural or functional relation with respect to the whole, parts are distinct from each other".

With respect to Containers:
With respect to Containers:
Containers are related to the Member_of [Set] Meronymy.

Also: "parts do not necessarily have a structural or functional relation with respect to the whole, parts are distinct from each other".

With respect to Composite:
Composites are related to the Part_of Meronymy.

I would suggest reserving the <<comprise>> Stereotype for items that are intrinsically part of the composite.

With respect to Meronymy types:
Are you planning any thoughts on these additional forms?
  • portion / mass : (Portion_of) There is a complete similarity between the parts and between parts and the whole. Limits between parts are arbitrary and parts do not have any specific function a priori with respect to the whole. We have in this class for example: slice/bread, centimeter/meter. This sub relation is often called a mereology.
  • object / material : (Substance_of)This type of relation describes the materials from which an object is constructed or created, or the constitutive elements of an object, e.g. alcohol/wine, steel/car. Generally, the parts loose their identity once they enter the composition.
  • precise place / area : (Location_of) parts do not really contribute to the whole in a functional way. This sub relation expresses spatiality, as in : oasis/desert, Alps/Europe.


Cheers!

« Last Edit: September 22, 2005, 11:53:28 pm by jeshaw2 »
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5848
  • Karma: +71/-75
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #2 on: September 23, 2005, 01:01:15 am »
Jim,

just an initial quick response...  ("up to my neck in muck and bullets")

Looks good!  I'll provisionally accept all your recommendations.

Why don't you have a go at the other types?

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5848
  • Karma: +71/-75
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #3 on: September 23, 2005, 05:04:19 am »
Quote
Thanks for starting this thread Paolo.  It is interesting to see the development of these ideas across the other threads of discussion, yet have them pulled together like this.
No problem! I find it useful when ideas have stabilised, to create a Monograph on the topic.  I'm just sharing it...

Now, for a more detailed response...
Quote
My thoughts...

My cognitive level is at a lower level of abstraction than yours.  That presents a refreshing challenge for me. :)
Be warned! Once you embark on this abstraction lark, you get hooked!  The amount of leverage you can achieve is often phenomenal! 8) 8)

Don't forget the guy with his head in the clouds can see everything... ;D

Quote
Your notational methods seem good to me.  I'll be adopting them.
But wait!  There's more! ;)
Quote
With respect to Nests:
Nests are related to the Part_of Meronymy.

Each classifier item can be in more than one nest at a time.
I'm still not sure I understand this statement.  I can't decide if it important or trivial...I think that this may relate more to non-Java like languages...perhaps browsers?
You don't need to worry about it... It's just that the same Class could be nested in more than one Class, but the Object instantiated is ALWAYS only in the instantiated nest.  Also, I forgot to indicate that this is covered by [Policy] - for example, a Package can't be in more than one nest, and a Class is unlikely to be nested in more than one Package etc...
Quote
[size=13][SNIP][/size]

I would suggest reserving the <<comprise>> Stereotype for items that are intrinsically part of the composite.
I agree.  This would require a separate Association for the other items.  Can you suggest a Stereotype name for that one?

Quote
[size=13][SNIP][/size]

Cheerz,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #4 on: September 23, 2005, 07:31:13 am »
Quote
Why don't you have a go at the other types?
Sounds like fun!  I accept the challange.  

Quote
I would suggest reserving the <<comprise>> Stereotype for items that are intrinsically part of the composite.
 
I agree.  This would require a separate Association for the other items.  Can you suggest a Stereotype name for that one?
I've been thinking about this.  In this thread, you've selected verbs for your Stereotype names.  I'm wondering if adjectives would serve us better?  I'll come back with some ideas on this too.

Muck can be very fertile.  While you're there, plant some seeds.  :D
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5848
  • Karma: +71/-75
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #5 on: September 23, 2005, 05:26:23 pm »
Quote
I've been thinking about this.  In this thread, you've selected verbs for your Stereotype names.  I'm wondering if adjectives would serve us better?  I'll come back with some ideas on this too.
Yes Jim, you're probably right. I just took the verb from the Association naming and sort of took my cue from «manifest» - but, of course, "manifest" is a verb and an adjective and a noun!

Keep dem cards an' Letters rollin' in Folks!

Paolo


« Last Edit: September 23, 2005, 05:26:48 pm by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #6 on: September 24, 2005, 10:28:39 pm »
I'm doing my "homework" Paolo... ;)

I'm looking at the meronymy forms for which I'm developing notational recomendations, and how they may be similar or different from the forms that you've described.  This has led me to do the same analysis within your set of meronymy forms also.

Quote
Collection
All containers define collections (even if only implicitly - the objects contained)
Not all collections are containers. [Policy]

I'm looking for examples of collections that are not containers.  In this context, do you consider Arrays, Vectors, linked (or otherwise structured) lists (such as those commonly found in C++, Java, etc.) to be containers?  I think not.  To me a Container is an object that demonstrates some form of problem domain behavior (i.e.; beyond that of sequencing, iterating, etc.), whereas these data types are more passive structures.

I'm wondering about a need to refactor the differentiting  points on Container and Collection.  Their key differentations seem to have more to do with ownership and access rights than they do with pure meronymy.  I don't think being contained or not contained is a meronymy issue. To me, container differentation could be on how their behavior participates in the enforcement of ownership and access policy.  But alas!...The diamond is on the association and not on the container... :'(

I'm also looking 'slanty-eyed' at Nest.  Might this also be a Container in disguise...?

Thoughts?



Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5848
  • Karma: +71/-75
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #7 on: September 25, 2005, 05:36:04 am »
Quote
I'm doing my "homework" Paolo... ;)
That's good to see! :)
Remember to use First principles.  They are a a powerful technique.
Quote
I'm looking at the meronymy forms for which I'm developing notational recommendation, and how they may be similar or different from the forms that you've described.  This has led me to do the same analysis within your set of meronymy forms also.
AS I said, they are a work in progress...
Quote
I'm looking for examples of collections that are not containers.  In this context, do you consider Arrays, Vectors, linked (or otherwise structured) lists (such as those commonly found in C++, Java, etc.) to be containers?  I think not.  To me a Container is an object that demonstrates some form of problem domain behavior (i.e.; beyond that of sequencing, iterating, etc.), whereas these data types are more passive structures.
Now you're talking!  It was precisely this problem that got me started on this meronymy lark!  

I think we need to agree on what we are dealing with here in this monograph.  I've already indicated that one of the problems (perhaps the fundamental) problem with Round-Trip-Code-Engineering is that there are more syntaxes available in the model than in the programming languages.  Thus although we can go from model semantics to the equivalent code semantics, we can't necessarily go in the reverse direction.

What I'm trying to achieve in this monograph is to determine what features are required to differentiate the various concepts in the Computationally Independent (or Conceptual) Model to accurately determine what structural and behavioural elements are necessary to manipulate them in the Platform Independent and Platform Specific Models.

So, like you, I don't think these structured are containers, but they may be used to represent them.
Quote
I'm wondering about a need to refactor the differentiating  points on Container and Collection.  Their key differentiations seem to have more to do with ownership and access rights than they do with pure meronymy.  I don't think being contained or not contained is a meronymy issue. To me, container differentiation could be on how their behavior participates in the enforcement of ownership and access policy.  But alas!...The diamond is on the association and not on the container... :'(
Assuming you agree that we're dealing with the CIM level, then you're probably right.  It may well be that the associated Collections represent the Container's meronymy aspects.  It may well be that some Collections with certain policies in effect are Containers.  Perhaps if you look at it that way it may become clearer...
Quote
I'm also looking 'slanty-eyed' at Nest.  Might this also be a Container in disguise...?
That also occurred to me.  It seems to me to be a very special container and (vide UML) worthy of it's own distinction.

Paolo
« Last Edit: September 26, 2005, 02:53:45 am by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #8 on: September 25, 2005, 11:40:55 pm »
Paolo;
This too is a work in progress, but I thought I'd share some of my thoughts and conclusions so far.  This may curl the toe nails of the UML work-to-rule advocates, but I take the position that UML syntax and grammar rules are advisory.  ;)  These assertions will bias my refactoring of what has gone on before in this thread.

My Assertions:
The concepts of Containment, Composition, Aggregation and Ownership are  independent and stand apart from each other.

Containers
• Containers provide a context for the contained elements.  Containers are a system that hosts objects and provides a set of services that allow those objects to be accessed and/or manipulated by objects external to the container.
• A container contains other objects in such a way the objects can be stored or removed at run time.  This is different from being created or destroyed.
• A contained element may be a reference.
• Some features of Aspect Oriented Programming (AOP) are implemented, perhaps logically, by the services of a container.
• There are may types of containers.  Composites, Containers, Components, Nests, Arrays, Vectors, etc. are all examples of containers. They differ in the technology of their realization, the context they present, the policies they enforce, their scalability, and the services they provide.
• A container’s features are described in the container’s class specifications of attributes, constraints, and methods.  Permutations of these features may be abstracted into container Stereotypes.

Composites
• Contrary to current thinking in UML 2, it is a mistake to say that “composition is a form of aggregation”.
• Composition forms a new type, an aggregation does not.
• Dependencies within a composite may be a reference.
• Dependencies between composites and their constituent parts should be  Stereotyped by the meronymy form.
Composition Kind, not Aggregation Kind, specify the form of meronymy.
• It is a mistake to Stereotype a composite with the meronymy form.
• Within a composite set of dependencies, each dependency may take on a different form of meronymy.  Thus, the composite takes on varying roles of the whole element in a whole/part meronymy.
Notation:  The nature of the whole becomes the role name on the dependency line.  The nature of the part becomes the role name at the other end of the dependency line.

Aggregation
• It is incorrect to assert that “aggregation is a form of composition”.
• Aggregations do not represent forms of meronymy.
• Aggregations simply recognize the coexistence of elements which may, or may not be associated with each other within a given context.

Ownership
• Ownership responsibilities relate to element stewardship including, but not limited to, an element’s creation, accessibility, and ultimate destruction.
• Contrary to current thinking in UML 2, Composition does not imply ownership.  Implementations of Inversion Of Control (IoC) (a.k.a., Dependency Injection (DI))  demonstrate that Ownership of objects my be held apart from the composition in which they participate.
• Containership does not imply ownership nor does it exclude it.
• The Aggregation Diamond on association lines within a UML diagram is misnamed.  It is better named the Ownership Diamond.  Ownership is specified if the diamond is filled, there is no ownership if the diamond is empty.

Any thoughts on this?...
« Last Edit: September 25, 2005, 11:46:18 pm by jeshaw2 »
Verbal Use Cases aren't worth the paper they are written upon.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5848
  • Karma: +71/-75
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #9 on: September 26, 2005, 04:16:23 am »
Quote
Paolo;
This too is a work in progress, but I thought I'd share some of my thoughts and conclusions so far.  This may curl the toe nails of the UML work-to-rule advocates, but I take the position that UML syntax and grammar rules are advisory.  ;)  These assertions will bias my refactoring of what has gone on before in this thread.
I agree we shouldn't be bound by strict UML conformity.  However, we should only veer away there from under carefully specified circumstances.
Quote
My Assertions:
The concepts of Containment, Composition, Aggregation and Ownership are  independent and stand apart from each other.
I think based on our discussions and thoughts, I'd agree with this statement.  It would be good if some of the other "heavies" would throw their thoughts into the arena.  I've had some off-line feedback that some are enjoying the discussion, but as to whether they find it useful...

Also, I'd like to re-iterate one point.  In your discussion below, you are more closer to the implementation point of view than I.  This is, in part, due to your current needs and viewpoint.  What I think we should be able to come up with is a description and definition of a set of terms that apply equally well to a .Net structure and a real world element (such as a bus with passengers).  As a colleague at work said of an earlier version of the monograph, "I've never seen a formal definition of a container".

I didn't see Collections on the list...  I guess for me, a Collection is (essentially) an Aggregation.
Quote
Containers
• Containers provide a context for the contained elements.  Containers are a system that hosts objects and provides a set of services that allow those objects to be accessed and/or manipulated by objects external to the container.
• A container contains other objects in such a way the objects can be stored or removed at run time.  This is different from being created or destroyed.
I like this!  I'd just remove the reference to run time.
Quote
• A contained element may be a reference.
• Some features of Aspect Oriented Programming (AOP) are implemented, perhaps logically, by the services of a container.
Since I know zero about AOP, I'll take your word for it... :)  However, from the quick peek at the site, it looks very interesting!
Quote
• There are may types of containers.  Composites, Containers, Components, Nests, Arrays, Vectors, etc. are all examples of containers. They differ in the technology of their realization, the context they present, the policies they enforce, their scalability, and the services they provide.
I'm not sure I agree with the list at this stage.  For example, you include Composites under Containers, yet you state Containment and Composition are independent.  Also, you can't really say Containers are Containers... ;D
Quote
• A container's features are described in the container's class specifications of attributes, constraints, and methods.  Permutations of these features may be abstracted into container Stereotypes.
In principle I agree with this statement.  However, I found that what's happened in my models is that the topics we're discussing here end up being Templates or Patterns or Parameterized Classes that I realize or bind to create the actual class.  I've evolved a technique where the features can be gathered into Policies (based on Interfaces) and Policy Implementations (based on Classes that implement the Interfaces).  I then use a kludge where I use the EA Generalization technology to simulate Realization and apply the selected Policies and their Implementations as appropriate to the instantiated class.  Thus the collection of "passengers on a bus" has certain properties based upon the the policies and implementations applied.  Because these policies are additive and transitive, it becomes difficult to accumulate them into Stereotypes.  I've found this policy idea to be very useful.
Quote
Composites
• Contrary to current thinking in UML 2, it is a mistake to say that “composition is a form of aggregation”.
• Composition forms a new type, an aggregation does not.
I like this very much!
Quote
• Dependencies within a composite may be a reference.
I don't understand this.  Are you trying to say you may compose By Reference?  If so, then I don't think this is a good way to say it.
Quote
• Dependencies between composites and their constituent parts should be  Stereotyped by the meronymy form.
Did you mean Associations?  We have to be really clear here.
Quote
Composition Kind, not Aggregation Kind, specify the form of meronymy.
• It is a mistake to Stereotype a composite with the meronymy form.
• Within a composite set of dependencies, each dependency may take on a different form of meronymy.  Thus, the composite takes on varying roles of the whole element in a whole/part meronymy.
I think I follow here.
Quote
Notation:  The nature of the whole becomes the role name on the dependency line.  The nature of the part becomes the role name at the other end of the dependency line.
This is a bit more tricky.  Assuming you mean Associations and not Dependencies (since under UML, Dependencies DON'T have roles), the roles at the end of the Associations preform the same roles as Attribute names.  I'm sympathetic to your ideas here, but I'm not sure how to implement them.  Perhaps if you provided a picture or two...
Quote
Aggregation
• It is incorrect to assert that “aggregation is a form of composition”.
Yes
Quote
• Aggregations do not represent forms of meronymy.
NO!  I disagree here.  I thought Aggregations could properly be described as implementing the Member_of meronymy.  There must be a reason for the membership (even if somewhat arbitrary - thus modifying your next point), but once established, an item can be accepted or rejected for membership based on the the criteria.
Quote
• Aggregations simply recognize the coexistence of elements which may, or may not be associated with each other within a given context.
See above.
Quote
Ownership
• Ownership responsibilities relate to element stewardship including, but not limited to, an element's creation, accessibility, and ultimate destruction.
• Contrary to current thinking in UML 2, Composition does not imply ownership.  Implementations of Inversion Of Control (IoC) (a.k.a., Dependency Injection (DI))  demonstrate that Ownership of objects my be held apart from the composition in which they participate.
• Containership does not imply ownership nor does it exclude it.
• The Aggregation Diamond on association lines within a UML diagram is misnamed.  It is better named the Ownership Diamond.  Ownership is specified if the diamond is filled, there is no ownership if the diamond is empty.
I think I can agree with all the above here...

There's something to be getting on with!

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #10 on: September 26, 2005, 10:13:00 pm »
I wish this forum had a way to save drafts of replys.  I just spent an hour on this and lost it all!  :'(

If you are not familiar with IoC and AOP, I highly recommend reading sections 1.4.2 IoC in Action and 1.5.2 AOP in Action in this book.  Cut and paste and reassemble  this URL into your browser:  http://www.manning-source.com/books/walls2/walls2_chp1.pdf

It is an easy and fun read.  It is also helps to explain what I mean by the term "Dependencies can be a reference",  for the dependency is injected into the composite.

You mention that some enjoy this discussion, but may not find it useful...  I use UML & EA for two reasons:  First, As a communication vehicle, but more importantly, as a tool that aids my thinking during an OOD process.  The utility of UML & EA as a thinking aid is directly related to the accuracy and clarity I'm able to achieve when modeling real-world concepts.  I used to believe that strict conformance to UML rules and diagramming in EA would keep my thinking valid and clear.  However, I discovered areas of fuzzyness in the UML and EA which have lead to fuzzy thinking about my models.  Participation in these discussions have convinced me that my thinking was more fuzzy than I thought.  But clarity is comming and my confidence is building; and I find that to be very useful.  ;D  Hopefully, I'll be able to pass this on to my students.

UML 2 Superstructure does provide a (formal ?) definition of Container.  
Quote
An instance that exists to contain other instances, and that provides operations to access or iterate over its contents
I don't think it to be a very good definition; it is too loose and trivial for my liking.  I accept your recommendation to remove the reference to run time.  It was just a last minute thought as I typed the definition.

Quote
I didn't see Collections on the list... I guess for me, a Collecion is (essentially) an Aggregation.
 I'm still thinking about the nature of Collections, but I didn't include it in my list because I believe concept of Collections to be at a higher level of abstraction and I wanted avoid multiple abstraction levels in my list.

My current thinking is that both Aggregations and Composites can represent collection;  Composites as a collection of parts and aggregates as a collection of things.

We need further discussion about Aggregations.  If you will grant me that Composites define a type and aggregations do not, then to be internally consistant I must reject the assertion that aggregations implement the Member_of meronymy.  

Consider an elevator filled with people... Yes, I will stipulate that the people are members of an arbitrary  group whose shared attribute is their current location of being on the elevator.  I would go on to say that this would define a type: PeopleOnElevator whose members are people.  However, I suggest that the PeopleOnElevator type is somewhat trivial in most modeling situations.  If they are non-trivial, as they might be in the modeling of an elevator queue, they should be promoted to Composites; otherwise, I would not recognize the legitimaticy of the type thus asserted.  For me, this cleans up a lot of fuzzyness! :)

Ok, it is "Show-n-tell" time.  Please! The following diagram is a kluge.  But it will serve as an anchor for further discussion.



You mentioned that Dependencies don't have roles.  If that is true in UML, then EA is inconsistant with that and I'm feeling fuzzy again.  :(  I used role naming functionality present in the dependency properties window to produce the "Bread flavor is dependent on the flower substance  genus" link.

I used the Composite tool to draw the other links (being forced to do so to get a association with an "Ownership Diamond"  ;)  So more fuzzyness here!

I don't know which is correct for connecting parts with their wholes:  associations or dependencies.  

If a component whole is not dependent upon its parts, then I suggest that the parts are not intrinsically part of the component.  Clearly, the flavor of the bread is dependent upon the type of flour used.  Under IoC, the flavor may be dynamically changed by substituting differeing flours.  (Wondering how to diagram that!)

Clearly, does not the bread own its substance part (the flour) and isn't that flour destroyed when the bread is destroyed?

But then again, a BreadSlice is a portion of the bread loaf.  Does consumption of a BreadSlice cause destruction of the loaf?  If maybe, then how many slices must be consumed before the loaf becomes a simple collection of slices?  And by inference, what does this say about the destruction of the flour?

When the flour is incorportated into the bread dough it looses its distinction.  Is this a form of destruction?  If yes, and if the flour is an intrinsic part of the bread, is the bread destroyed by the act of its creation?  If no, how is an indistinct part destroyed?  :D

And finally, can it be said that the loaf ownes its slices?  Surely the loaf may be destroyed, but in my bread box, some slices linger on... ;D

I'm looking forward to everyone's comments on this little dissertation  ;D

Cheerz,


« Last Edit: September 26, 2005, 11:15:40 pm by jeshaw2 »
Verbal Use Cases aren't worth the paper they are written upon.

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #11 on: September 26, 2005, 11:36:07 pm »
Quote
I wish this forum had a way to save drafts of replys.  I just spent an hour on this and lost it all!



Ah the joys of the internut.

Compose your post using your favourite text editor and paste it in.   ;)

bruce
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #12 on: September 27, 2005, 12:14:29 am »
Quote
When the flour is incorportated into the bread dough it looses its distinction.  Is this a form of destruction?  If yes, and if the flour is an intrinsic part of the bread, is the bread destroyed by the act of its creation?  If no, how is an indistinct part destroyed?


Interesting!

If one imagines that class Bread posesses a Kontainer attribute (just to separate this from the above discussions) of name "Ingredients", then while the portions of flour, water, yeast, etc  lie uncombined then the distinction remains.  Now if the goal of the Bread class is to manage supply of raw materials and the combining thereof (IOW class Bread is a specialisation of Recipe) then the retention of the distinction appears to be required. However, if the goal of the Bread class is management of the weekly trip to the General Store then why should we care at all about your <substance of> relationship - unless we are gluten intolerant and therefore have to mind our ingredients.  In the latter case, even though Flour may have lost its "natural  intuitive integrity" the fact that it once was an ingredient of the Bread is important (say, if the role of the (yet another) Bread class is the printing of correctly labelled foodstuffs.......


What I'm inadequately trying to point out is that (sometimes) the nature of the relationships under the microscope in this thread are often modified by context beyond the current focus.  I appreciate that you-all are trying, through the abstraction process, to come up with a model that is beyond these context nuances.  Good oh!  Keep it up.

Now the bad news..... I also believe that there are many instances of merrynomicromancy (whatever  ;D )  that are not only context bound but are also temporally bound - Kollection "Aquaintances" instances "girlfriend", "wife", "ex' leap to mind.

good luck!


bruce
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5848
  • Karma: +71/-75
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Dependency Injection????
« Reply #13 on: September 27, 2005, 01:25:19 am »
Quote
Jim,

This is just a short observation on what you've just said.  Before I reply to the substance of what you said I think there's a big problem looming up...

In [size=13]Modelling Dependency Injection[/size] I observed that I didn't think that Dependency Injection was a good name from what was going on...

I re-iterate this!  ALL references to instances of a Class or to the Operations of a Class have to be made through Attributes.  That's why I said I thought Attribute Injection was a better term.  

Notwithstanding that Martin is a nice guy (he and I exchanged some pleasantries and ideas some years back), if we're prepared to chuck UML2 where it's fuzzy, we should be prepared to chuck Martin when he's fuzzy.

I'm comfortable with the term Inversion of Control and I'm comfortable with the notion of Injection.  But I again submit that what is injected is a Attribute value.  In particular, if you go back to your topic on Modelling Dependency Injection, you'll see we never used (UML) Dependencies at all!  We only used Associations (Attributes).

What has this to do with your problem at hand?

You've used UML Dependencies in your diagram.  I don't believe they're appropriate.  I don't believe Dependency is associated with Meronymy.  As I said in my previous post, we have to be deadly accurate here otherwise we'll all get lost.

The reason Associations have Roles is that the Role name corresponds to the Attribute name and (effectively) have the same semantics.  Notwithstanding that EA allows you to put Roles on Associations, that's just structure re-use.  There may be some use for Roles on Dependencies, but it's NOT that of Attribute.

Can I ask you to have another look at your diagram and see if you can replace the Dependency with one (or more Associations - including possibly an N-Ary Association).  If you don't want to or would like me to put up my version, just let me know.

Also, can you say whether or not you're happy (for the present) to go along with Attribute Injection rather than Dependency Injection.  If not, can you present a justification for why we should use Dependency Injection.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5848
  • Karma: +71/-75
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Collections, Containers, Composites & Nest
« Reply #14 on: September 27, 2005, 03:43:21 am »
Quote
Ah the joys of the internut.

Compose your post using your favourite text editor and paste it in.   ;)

bruce
But first turn on autosave.  Fenestrae decided to reboot me without warning, and I lost half-an-hour's work in my favourite editor... :(

Paolo

Yes, Yes, I know Linux felix...  :P
« Last Edit: September 27, 2005, 03:44:09 am by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!