Collections, Containers, Composites & Nests

[Paolo F Cantoni]

I wish this forum had a way to save drafts of replies.  I just spent an hour on this and lost it all!  

Been there, done that (see other post... )

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.

I liked the chapter and the explanations.  But I still hold that dependency is still not the right term, at least not a UML Dependency.

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 fuzziness 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 coming and my confidence is building; and I find that to be very useful.    Hopefully, I'll be able to pass this on to my students.

Yes, I've found this true also.  I'm starting to find I'm thinking in UML (at least my variant ). But also, like you,I've found that you need to eliminate as much fuzziness as you can.

UML 2 Superstructure does provide a (formal ?) definition of Container.
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.

A tautological definition is NOT a definition.

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.

OK.  I'll leave it for now.

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.

I'm not sure that's a good idea.

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

OK about further discussions.  I DO agree that Composites define a new type and Aggregations do not (although they may involve a new type).  However, I don't see why that disqualifies an Aggregation from being Member_of.

member / set or group: parts do not necessarily have a structural or functional relation with respect to the whole, parts are distinct from each other. In this kind fall for example tree/forest, student/class.  [Member_of]

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 legitimacy of the type thus asserted.  For me, this cleans up a lot of fuzziness!

You raise an interesting point here.I think it would be safe to say that we both agree that the "Collection" PeopleInElevator (differences in language across the ponds?) is a Class and that there exists a «memberOf» relationship between the Class and its items (Person).  In another post, I mentioned that one of the important differences between Composites [Part_of] and Non-Composites (such as Containers and Collections) is that there is a minimum number/type of parts which are required to make up the composite, otherwise we don't have a composite.  You agreed with this when you said I should only use the «comprise» stereotype for those essential/intrinsic parts.  This isn't the case here.  I can keep taking people away from the Collection until it's empty and I still have a valid Collection (albeit an empty one)!  That's why PeopleInElevator isn't a Composite!

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

Yes.

You mentioned that Dependencies don't have roles.  If that is true in UML, then EA is inconsistent 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 flour substance genus" link.

Be careful about using the natural language term dependency and thinking it directly maps to a UML Dependency.  It often does, but not always.

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 fuzziness here!

You can use an ordinary Association and use the Role Aggregation to determine whether the diamond should be present.

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

In my view, Associations (with appropriate meronymic stereotypes and the diamond).

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 differing 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?

I don't think it's as simple as that.  In my diagram there's a lot more stuff.  The type (and quantity) of flour used affects the type and flavour of the bread.

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?

My diagram should reveal all...  .  I've extended the scope slightly, but I managed to create examples of five of the six kinds of meronymy.  I hope it will be found to be useful.

When the flour is incorporated 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?  

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

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

There were mine...

Paolo

[jeshaw2]

Paolo, you said:

In Modelling Dependency Injection 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.  

I have no problem using Attribute Injection.  Guess I got too close to Implementation speak again.    In Java, the typing of the attribute, when it is declared in code, sets it up to be a reference and generally that reference represents a dependency.  That would be my only defence if I chose to use it.  But I see your point.

sargasso, you said:

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

Sounds good!  I can, I think, use an Association Class to conatin this information.  

I noticed that an association Class can be stereotyped <<injected>> or <<subscribe>>.  What is that all about?  Does it relate to Association Injection or the Publish/subscribe pattern?  The UML Structure spec. does not discuss this.

Paolo, you said:

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.

I have no problem revising the diagram, here it is.  But I would be interested in seeing a version that uses an N-ary association.    If it is not too much trouble...? It is not necesary if you are referring back to your assertion that the lozenge is the Association Class and you and sargasso are of like mind.

[jeshaw2]

Paolo

My diagram should reveal all...  .  I've extended the scope slightly, but I managed to create examples of five of the six kinds of meronymy.  I hope it will be found to be useful.

I've changed my mind!  I would be excited and happy to see your diagram.  Please show it!

[Paolo F Cantoni]

Paolo

I've changed my mind!  I would be excited and happy to see your diagram.  Please show it!

You asked for it....



I'm off to work so here's a quick summary...  Also, as noted on the diagram, I've deliberately left off the AggregationKind diamonds.

Bread can come in a number of forms (loaf, roll etc).
BreadForms are made up according to a recipe.
Bread is made up of Flour (and meal) and possibly Rising Agents.  The AssociationClasses detail the formulations.
BreadLoaves  (and for that matter Rolls) can be whole, cut or broken.   See!  In verbalising the diagram I've found an error!  I won't fix it now 1) No Time 2)It's useful to see the effect of the verbalisation!   The three subtypes relating to previous processes should be Specialized off BreadForm.  Note this is a different GeneralizationSet to the existing Subtypes (BreadLoad and BreadRoll)

You can cut a hole loaf into slices or you can break a whole loaf into pieces.  
You can reassemble an arbitrary set of slices into a CutLoaf
A slice could be part of CutLoaf or be on its own.
A BreadForm may be on a Baking Tray (during baking).
A BakingTray may be part of a batch being baked.
Batches are baked in Bread Oven which must have at least one door and a Heat source.

Did you see all those Business Rules in the diagram?
Note especially the multiplicity from Whole Load to Slices and Pieces: 0,2..*  - this means a WholeLoaf need not be cut, but if it is, it must be cut into at least two slices.

Jim, can you let me know if I've got the meronymic sterotypes right for each particular situation?  (Spot the deliberate mistake!  )

HTH,
Paolo

BTW: (Like I did) try verbalising - speaking the business ruels as you traverse the model.  It really works!

Oh, I forgpt... Association names of the form: forward [size=13]\[/size] inverse, name both directions of the Association (which is a binary Relation).  Thus:
Each WholeLoaf may have been cut into at least 2 BreadSlices.  Each BreadSlice must have been cut from only one WholeLoaf.
My RationalRose verbalizer does this automatically from the diagram.  I haven't converted it to EA yet.

[Paolo F Cantoni]

There are a number of things wrong with the model...  
But I don't want to change it yet...

Like Jim, I want to foster some discussion and learn something.

I'd appreciate some feedback on what's wrong, in people's view.

Paolo

[jeshaw2]

I too would like others to join the fun.  This thread is turning into a nice case study on how diagrams are developed in addition to the modeling issues under study.  

Paolo;
Your diagram is very thought provoking and I like the potential it has for summarizing/diagramming our discussions.  

I've redrawn the diagram to include the restructuring of the generalization sets and I've changed and added some meronymys.

Apparently, EA still does not support multiple generation sets on a class.  Has anyone figured out a way to emulate multiple sets?  I could use that in the case of the BreadForm class.

I've added a new <<processOf>> meronymy (sub activity / activity) to the BreadBakingBatch to BreadOven link.

I was uncomfortable with the BreadRecipe association because a recipe has two major sections; so I redesigned that.  To me, a recipe an artifact with internal structure; gave me a chance to show nesting.

Once we achieve concurrance on this diagram, it will be fun to add the aggregation diamonds.  

Here is my new offering:  

[Paolo F Cantoni]

[size=13][SNIP][/size]
I've redrawn the diagram to include the restructuring of the generalization sets and I've changed and added some meronyms.

Yes, I like some of the changes you've made and some I think are not correct... More below.

Apparently, EA still does not support multiple generation sets on a class.  Has anyone figured out a way to emulate multiple sets?  I could use that in the case of the BreadForm class.

Yes, you're right here.  In my own modelling, I use them a lot.  For the present I've used the Constraints tab to create a new type of constraint Gen.Set (for Generalization Set - too long for field!].  I will include them on the next iteration of my diagram.

I've added a new <<processOf>> meronymy (sub activity / activity) to the BreadBakingBatch to BreadOven link.

The deliberate mistake I alluded to on my previous diagram was the use of locationOf.  You can't use the meronymic Stereotype unless both ends are Locations!  Similarly, you can't use processOf (is that the "standard form?"  I would prefer subprocessOf (since the meronymic stereotypes appear to take the member name) unless both ends are processes!  However, you've given me an idea and I've added some processOf links in my diagram.

I was uncomfortable with the BreadRecipe association because a recipe has two major sections; so I redesigned that.  To me, a recipe an artifact with internal structure; gave me a chance to show nesting.

I agree with recipe, I'm not so sure about nesting, but I can't come up with any reason why it should be... so I've gone along.  Also, in my diagram I've catered for the notion of recipe (specification) versus tracking actual ingredients.

Once we achieve concurrence on this diagram, it will be fun to add the aggregation diamonds.  

I'm still brushing up my diagram (actually two - one for bread structure and one for bread making)  I'll post it when I've done a bit more work.  But we can discuss the issues above regarding meronymic stereotype without the diagram.

Paolo

[jeshaw2]

If it helps, I don't have a strong case for nesting within the recipe either.  In fact, in my thinking, I'm drifting away from it.

However, wishing to use this model as a teaching aid, I'd like to demonstrate nesting somewhere.  Perhaps we can find a more appropriate place for it?

What I did find interesting was the ability to show association classes as a component of another class.

[KP]

If it helps, I don't have a strong case for nesting within the recipe either.  In fact, in my thinking, I'm drifting away from it.

However, wishing to use this model as a teaching aid, I'd like to demonstrate nesting somewhere.  Perhaps we can find a more appropriate place for it?

I think a little care is necessary when using the nesting connector because it isn't actually a UML 2.0 class, just an alternative notation. So, in strict UML terms, there isn't actually a relationship element between Recipe and DoughFormulation; the notation just says that "DoughFormulation is nested beneath Recipe in the Project Browser over on the right-hand side of my screen, but you can't see that in the diagram", which I very much doubt is the case.

And not being a UML element, you shouldn't give nesting connectors names or stereotypes or multiplicities.

And strictly speaking, the target of the nesting connector should be a Package.

Of course nobody will shoot you if you don't use strict UML; it's just that this discussion is in the "UML Process" forum...  

[jeshaw2]

And strictly speaking, the target of the nesting connector should be a Package.

Interesting.  That explains why I didn't get much when I searched for it in the UML Superstructure.

I first became aware of the notation when EA reverse engineered a Java class that had an inner class.  I was curious about how to model that configuration.  EA diagramed two classes that were related using the nesting notation.

How is the nesting connector related to your concept of a nest mentioned in the subject of this thread?

[Eve]

I first became aware of the notation when EA reverse engineered a Java class that had an inner class.  I was curious about how to model that configuration.  EA diagramed two classes that were related using the nesting notation.

EA stopped reverse engineering inner classes in that way when UML 2.0 support was introduced in version 4.0.

Simon

[Paolo F Cantoni]

I think a little care is necessary when using the nesting connector because it isn't actually a UML 2.0 class, just an alternative notation. So, in strict UML terms, there isn't actually a relationship element between Recipe and DoughFormulation; the notation just says that "DoughFormulation is nested beneath Recipe in the Project Browser over on the right-hand side of my screen, but you can't see that in the diagram", which I very much doubt is the case.

And not being a UML element, you shouldn't give nesting connectors names or stereotypes or multiplicities.

And strictly speaking, the target of the nesting connector should be a Package.

Of course nobody will shoot you if you don't use strict UML; it's just that this discussion is in the "UML Process" forum...  

KP is right in saying that UML shows the "nesting" link as an alternative notation (see 7.3.37 - Figure 61).  But unfortunately EA DIDN"T implement it that way!  (Thomas' "error by design?")  It's implemented as a real connector - just like any other.  That's why it doesn't automatically appear when you have the nesting Classifier and the nested Classifier on the same diagram, with the nested Classifier outside the nest (as in the Lithuanian tool).

So, we can use it how we will...

Also, I don't believe it is limited to packages.  Again, being merely a notational form, it can be more than reasonably said to apply to any nesting situation.

Other products (particularly the Lithuanian tool) allow this.

However,that having been said, KP's point about taking care in it's use is correct.  Unfortunately one place where you can't use nesting is when attempting to nest an Association Class.  (See!  I told you I had disquiet about the use of nesting, but couldn't put my finger on it... )

Of its nature, an Association Class instance has to be reachable by both the end Classes.  This is NOT possible if it's nested - remember the Class can be nested in more than one nest, but the Instance can't.

The next iteration of my diagram addresses this.

HTH,
Paolo

[jeshaw2]

Of its nature, an Association Class instance has to be reachable by both the end Classes. This is NOT possible if it's nested - remember the Class can be nested in more than one nest, but the Instance can't.

Precisely the concern that triggered my retreat from nesting.  However...

I need to study the implementation of an AssociationClass more.  Is it a fact that if the AssociationClass is unreachable the link it describes is also unreachable?   :-/

Even though the DoughFormulation is a component of an <<artifact>>?  (I'm wondering what the implementation of a class stereotyped as an artifact looks like...)  

Perhaps, in this case, Recipe should not be modeled as a Stereotype... :-/

[Paolo F Cantoni]

Precisely the concern that triggered my retreat from nesting.  However...

I need to study the implementation of an AssociationClass more.  Is it a fact that if the AssociationClass is unreachable the link it describes is also unreachable?   :-/

The Association Class embodies the link...  Think of the Class as having (at least) two Attributes which correspond to the ends and reference the end Classes.  Each end Class has a collection to reference the set of AssociationClasses that point back to it (and on to the other end).  This is because the if the AssociationClass contains real attributes (whose values correspond to the values appropriate to the link instance in question) they have to go in one place, not in both classes.  So... If the AssociationClass object is nested in one superior, it isn't in the other (and what's more can't be reached by the other).  Finally, if it is nested, then it can't be manifold (that is, have a multiplicity > 1).

Even though the DoughFormulation is a component of an <<artifact>>?  (I'm wondering what the implementation of a class stereotyped as an artifact looks like...)  

Perhaps, in this case, Recipe should not be modelled as a Stereotype... :-/

An Artifact is a Classifier, but it's not a Class...
The recipe is NOT an Artifact.  It is a specification (modelled as a normal Class).  The Artifact is an embodiment or manifestation of the recipe on some medium (such as a piece of paper) in some layout.

Consequently, if you need to have a Class to hold the Artifact and (I'd suggest) another to hold the ArtifactInstance.  The Artifact Class would hold the metadata to render the recipe in some form (and format) and the ArtifactInstance Class would hold the metadata to place it somewhere (and perhaps re-reference it).  The ArtifactInstance would have a reference back to the particular Artifact Class that was used to render it.

In the long gestating next iteration of th emodel, I've NOT used Artifacts.

Making sense?

HTH,
Paolo

[jeshaw2]

Yes, I understand. Thank you.

Now I think I have three problems with Recipe in my diagram:  

First, it should not be Stereotyped as an artifact for it needs to articulate recipes as needed.

Second, The Baking and Dough Formulations should not be nested within it for external access is needed.

And Finally,  the rectangle is correct, but the name is wrong.  It needs to have the term Formulation in its name (as in BreadFormulation) to move it to the same level of abstraction as the Baking and Dough Formulations.  From my experience in the kitchen, Recipes are not very abstract.

I think DoughFormulation is an n-ary association.  I just had a piece of raisin wheat bread with white icing on it.  I imagine that the DoughFormulation would associate BreadProduct with BreadDough and BreadIcing, while the Raisins would be a FlavoringIngredient of BreadDough (either intrinsic or extrinsic depending on the view). Intrinsic if making raisin bread, extrinsic if making wheat bread.

I'm suggesting that the lowest level abstraction (wet concrete?) ingredient list resides in BreadDough as (FlouringIngredient, RaisingAgent) and those might be finally resolved through IoC which might wire in Summer Wheat and Yeast. :-/

Paolo, I'm not sure I have DoughFormulation figured out correctly; especially in how it relates to, or is contrasted with, BreadDough.  Can you expand on that a bit with perhaps a real world example?  I may be confusing bill-o-material levels with abstraction levels here.