Sparx Systems Forum

Discussion => Uml Process => Topic started by: Paolo F Cantoni on September 21, 2005, 01:39:39 pm

Title: Collections, Containers, Composites & Nests
Post by: Paolo F Cantoni 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.
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 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?


Cheers!

Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni 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
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni 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
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 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
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni 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


Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 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?



Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni 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
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 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?...
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni 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
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 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.

(http://clanshaw.dyndns.org/images/breadmeronymy01.png)

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,


Title: Re: Collections, Containers, Composites & Nest
Post by: sargasso 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
Title: Re: Collections, Containers, Composites & Nest
Post by: sargasso 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
Title: Dependency Injection????
Post by: Paolo F Cantoni 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] (http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=UMLPRO;action=display;num=1126412357;start=5#5) 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
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni 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
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on September 27, 2005, 06:36:21 am
Quote
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... ;D)
Quote
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.
Quote
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.  ;D  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 ;D). But also, like you,I've found that you need to eliminate as much fuzziness as you can.
Quote
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.
Quote
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.
Quote
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.
Quote
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.
Quote
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]

Quote
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!
Quote
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.
Quote
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.
Quote
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.
Quote
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).
Quote
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.

Quote
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...  ;D.  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.
Quote
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?  :D

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

I'm looking forward to everyone's comments on this little dissertation  ;D
There were mine...

Paolo

Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 27, 2005, 07:15:31 am
Paolo, you said:
Quote
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:
Quote
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:
Quote
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.

(http://clanshaw.dyndns.org/images/breadmeronymy02.png)
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 27, 2005, 07:24:10 am
Paolo

Quote
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!

Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on September 27, 2005, 04:00:31 pm
Quote
Paolo

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

You asked for it....

(http://sharepoint.knowledgerecovery.com/external/eaug/EA%20Graphics/PaoloFCantoni_Images/Bread.jpg)

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!  ;D)

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.
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on September 28, 2005, 04:48:28 am
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
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 28, 2005, 08:45:26 am
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.  ;D

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

Here is my new offering:  :)
(http://clanshaw.dyndns.org/images/breadmeronymy03.png)
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on September 28, 2005, 06:20:58 pm
Quote
[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.
Quote
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.
Quote
I've added a new <<processOf>> meronymy (sub activity / activity) to the BreadBakingBatch to BreadOven link.
Quote
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.
Quote
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.
Quote
Once we achieve concurrence on this diagram, it will be fun to add the aggregation diamonds.  8)
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
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 28, 2005, 06:48:51 pm
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.


Title: Re: Collections, Containers, Composites & Nest
Post by: KP on September 28, 2005, 07:36:45 pm
Quote
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...  ;)
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 28, 2005, 07:58:52 pm
Quote
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?

Title: Re: Collections, Containers, Composites & Nest
Post by: Simon M on September 28, 2005, 10:13:02 pm
Quote
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
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on September 29, 2005, 05:59:31 am
Quote
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

Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 29, 2005, 07:47:00 am
Quote
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... :-/


Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on September 29, 2005, 12:40:13 pm
Quote
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).
Quote
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
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 29, 2005, 01:54:34 pm
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.


Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 29, 2005, 05:53:03 pm
Paolo;

I'm getting fuzzy again. :(
Quote
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).

I built this model:
(http://clanshaw.dyndns.org/images/Association02.png)

Generating the code I got:
Code: [Select]

public class BreadProduct {


public BreadDough MadeFrom;

public BreadProduct(){

}


public void finalize() throws Throwable {

}

}
public class BreadDough {


public BreadProduct MadeInTo;

public BreadDough(){

}


public void finalize() throws Throwable {

}
}

public class DoughFormulation {


private int BreadType;

private int Yeald;


public DoughFormulation(){

}


public void finalize() throws Throwable {

}
}


I didn't think I should take you literally and I didn't know what to expect from EA's code generator, but I was hoping for more in the generated code to tie DoughFormulation in a bit more tightly to the other classes.

As you can see, what I got was standard association attributes references in BreadDough and BreadProduct and a DoughFormulation class dangling out in space by itself.  Visibility of DoughFormulation does not seem be an issue is link navigatability.  So are you suggesting that I must add in the missing code to set up the logic in your statement?  ???

Note that I took the link name from our earlier diagrams and decomposed them into role names.  This helped to generate more meaningfull attribute names for the association ends.  Do you have any problems with this notation style instead of using the roles in the link name?
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on September 30, 2005, 05:49:20 am
Quote
Paolo;
I'm getting fuzzy again. :(
[size=13][SNIP][/size]
I didn't think I should take you literally and I didn't know what to expect from EA's code generator, but I was hoping for more in the generated code to tie DoughFormulation in a bit more tightly to the other classes.
Yes, you should have taken me literally (I'm a very literal person... ;D.)  And yes, you should have expected more from the code generator.  However, to give Sparx their due, they appear to be like most OO programmers - they wouldn't know what to do with an AssociationClass if it bit them in the proverbial.

In trying to formulate an answer for you, I tried a few PITS tests today (Programmer-In-The-Street :))  Universally, they either had 1) never seen an AssociationClass or 2) Didn't know what it meant (exactly) and 3) had never created or used one...
Quote
As you can see, what I got was standard association attributes references in BreadDough and BreadProduct and a DoughFormulation class dangling out in space by itself.  Visibility of DoughFormulation does not seem be an issue is link navigability.  So are you suggesting that I must add in the missing code to set up the logic in your statement?  ???
For the present, Yes...

Quote
Note that I took the link name from our earlier diagrams and decomposed them into role names.  This helped to generate more meaningful attribute names for the association ends.  Do you have any problems with this notation style instead of using the roles in the link name?
The names are not correct as they aren't actually role names.  (Actually, the whole model is suspect from a domain point of view, but that isn't the point here...)

Below is the required code for C# to create and manage this relationship.

First the Class definitions...   [Note for simplicity's sake, I've made all the attributes public.]

public class BreadProduct
{
   public ArrayList _DoughFormulations = new ArrayList();    //because the Association is optional manifold                        
   public int Value;    //Just to show we got here...
   public BreadProduct()
   {
   }        

   public void AddDoughFormulation(DoughFormulation associatedDoughFormulation)
   {
       _DoughFormulations.Add(associatedDoughFormulation);
   }
}

public class BreadDough
{
   public ArrayList _DoughFormulations = new ArrayList();    //because the Association is optional manifold                
   public int Value;    //Just to show we got here...

   public BreadDough()
   {
   }        

   public void AddDoughFormulation(DoughFormulation associatedDoughFormulation)
   {
       _DoughFormulations.Add(associatedDoughFormulation);
   }
}

public class DoughFormulation
{
   public BreadDough _BreadDough;
   public BreadProduct _BreadProduct;

   private DoughFormulation()
   {
   }    

   public DoughFormulation(BreadProduct BreadProduct, BreadDough BreadDough, int BreadType, int Yield)
   {
       _BreadProduct = BreadProduct;    //set reference to AssociationEnd
       _BreadDough = BreadDough;    //set reference to AssociationEnd

       _BreadType = BreadType;        //set AssociationClass Attribute    
       _Yield = Yield;        //set AssociationClass Attribute
       
       _BreadProduct.AddDoughFormulation(this);    //Inject reference to AssociationClass
       _BreadDough.AddDoughFormulation(this);    //Inject reference to AssociationClass    
   }
   public int _BreadType;    
   public int _Yield;
}


It should gladden your heart to see some Slot Injections in the AssociationClass constructor...  8)

Next, the code to test and verify the structures...

   BreadProduct oBreadProduct = new BreadProduct();
   oBreadProduct.Value = 23;
   BreadDough oBreadDough = new BreadDough();
   oBreadDough.Value = 77;

   DoughFormulation oDoughFormulation = new DoughFormulation(oBreadProduct, oBreadDough, 1, 5);
   oDoughFormulation = new DoughFormulation(oBreadProduct, oBreadDough, 2, 7);

   System.Collections.IEnumerator oIterator = oBreadProduct._DoughFormulations.GetEnumerator();
   while ( oIterator.MoveNext() )
   {
       DoughFormulation oIteratedDoughFormulation = (DoughFormulation)oIterator.Current;
       Trace.WriteLine(oIteratedDoughFormulation._BreadType + "->" +  oIteratedDoughFormulation._BreadDough.Value);
   }

   oIterator = oBreadDough._DoughFormulations.GetEnumerator();
   while ( oIterator.MoveNext() )
   {
       DoughFormulation oIteratedDoughFormulation = (DoughFormulation)oIterator.Current;
       Trace.WriteLine(oIteratedDoughFormulation._BreadType + "->" +  oIteratedDoughFormulation._BreadProduct.Value);
   }


See how we use the DoughFormulation to traverse to the BreadDough (from the BreadProduct) - and vice versa!

Lastly, the output...

1->77
2->77
1->23
2->23

So it did work!

In C++, the Classes would look like...
Code: [Select]
[size=13]
class DoughFormulation;

class BreadProduct
{
public:
       std::vector<DoughFormulation*> _doughFormulations;
       int Value;
};

class BreadDough
{
public:
       std::vector<DoughFormulation*> _doughFormulations;
       int Value;
};

class DoughFormulation
{
public:
       BreadProduct& _BreadProduct;
       BreadDough& _BreadDough;
       int _BreadType;
       int _Yield;
};
[/size]


Does that help remove the fuzziness?

You should now be able to generate the Java equivalent...

(Now you know why I'm going to emit the code not EA... ;D)

Paolo
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on September 30, 2005, 06:54:24 am
Jim,

here is the next iteration of the model.

It's in three diagrams - 'Cos it gets complicated...
(http://sharepoint.knowledgerecovery.com/external/eaug/EA%20Graphics/PaoloFCantoni_Images/BreadStructure.jpg)
BreadProducts can be in a number of forms - here we show two Loaf and Roll.  The {(Form)} is my notation for a GeneralizationSet (until EA supports them properly!).
A BreadProduct can be portioned in a number of ways.  The whole form, cut into slices or broken into pieces.  {(Portioning)}
The slices and pieces are thus «portionOf» meronymies.
An arbitrary set of slices can be reassembled into a cut form (similarly with a set of pieces).
(http://sharepoint.knowledgerecovery.com/external/eaug/EA%20Graphics/PaoloFCantoni_Images/BreadMaking.jpg)
A BreadProduct is made by a process called BreadMaking that is specified by a recipe.  The recipe includes details of making the dough, proving it, and then baking it.  Only whole products can be proved and baked.
Each part of the BreadMaking is a «processOf» meronymy.
Each whole BreadProduct is a «memberOf» the collection of forms on the tray while proving and baking.
Each BreadBakingTray is a «memberOf» the collection of Trays in the batch while baking.
The Oven is comprised of two types of parts the Doors and HeatSources - they're in the «partOf» meronymy.
The Bakery consists of an ingredient StorageRoom, 3 MixingRooms, 2 BakingRooms and a Shop.
The rooms are thus in the «locationOf» meronymy.
Mixing and Proving take place in the MixingRoom, Baking in the BakingRoom, presumably when they've cooled, the BreadProducts end up in the Shop...
(http://sharepoint.knowledgerecovery.com/external/eaug/EA%20Graphics/PaoloFCantoni_Images/BreadIngredients.jpg)
BreadDough is made to a recipe which depends on the BreadType.  The BreadType determines the ratio of ingredients.
BreadDouchFormulation determine how much of the ingredients are required to make up a specific mass of dough.
The actual BreadDough reflects the actual amounts of the ingredients used and the actual mass prepared.
In all these cases the relationships to the Ingredient types are «substanceOf» meronymies.

That's ALL the six meronymies!  What a neat example!

Comments?

Paolo



Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 30, 2005, 10:09:32 am
Paolo;

Quote
here is the next iteration of the model.
I think it should be the last iteration.  ;D It is a master piece (given that it is a study of the 6 meronyms and not of the bread domain issues).  It stands alone as a complete model.  This, along with the previous iterations, combine to form a wonderful learning experience in the development of a model diagram too!

My Congratulations!  Well done!



How did you get that N-ary icon into the upper right corner of the associationclass elements?



Now that we have arrived at this point, was all of this meronymy 'stuff' just an academic side-track or can we do something with it?   Personally, I think there is much we can do with this.  I would suggest the following areas for further investigation.

I think we have a good forking opportunity here for some of these topics.  :D  I'd suggest individual threads for the lesser known meronymys <<locationOf>>, <<portionOf>>, <<activity of>>, and another for "Ownership defined"...

Thoughts anyone?

Cheers

Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on September 30, 2005, 04:19:07 pm
Quote
[size=13][SNIP][/size]

How did you get that N-ary icon into the upper right corner of the AssociationClass elements?

I always visually differentiate AssociationClasses from others.  So I set up a UML stereotype colouring for «association»

The icon cam along for free!

Just part of EA's UI (Unique Interface).  
However, a long time back I did postulate that EA should provide the ability to add one (or preferably a number of) icon(s) for a stereotype.   Maybe this is part of the support.

Paolo

BTW, we still need to as the AggregationKind diamonds...
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 30, 2005, 04:33:04 pm
Quote
BTW, we still need to as the AggregationKind diamonds...

Yes, but I now refer to them as Ownership Diamonds.  ;D  I figure on dealing with them in a thread on Ownership (assuming we agree to fork)  ;)  It would be interesting to put them on this last diagram.  8)
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on September 30, 2005, 04:41:41 pm
Quote
Yes, but I now refer to them as Ownership Diamonds.  ;D  I figure on dealing with them in a thread on Ownership (assuming we agree to fork)  ;)  It would be interesting to put them on this last diagram.  8)
OK..

But we're agreed, after we've fleshed out the rest of the stuff, we'll come back and finalise the model.

Paolo

BTW: I noticed you've now called the stereotype «activityOf» in stead of «processOf»
could we make it «subactivityOf»?  That way ALL the meronymic stereotypes take the part's view...
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 30, 2005, 04:55:57 pm
Quote
But we're agreed, after we've fleshed out the rest of the stuff, we'll come back and finalise the model.
Agreed.  In fact we can begin that now if you like.

Quote
BTW: I noticed you've now called the stereotype «activityOf» in stead of «processOf»
could we make it «subactivityOf»?  That way ALL the meronymic stereotypes take the part's view...
Good idea, I agree.
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on September 30, 2005, 05:56:12 pm
Quote
Agreed.  In fact we can begin that now if you like.
Go for it...

As you said a few posts back, the stereotypes should give the programmer some indication of the necessary procedural processing involved.

I'm interested from the point of being able to write code from the highest level of abstraction I can get away with.  So, the sooner I can create some patterns for this stuff, the better.

I'll let you kick off the threads...

Paolo

BTW The AssociationClass stuff might warrant a thread of it's own...  Did you follow that?
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on September 30, 2005, 06:38:25 pm
Quote
BTW The AssociationClass stuff might warrant a thread of it's own...  Did you follow that?
If you are referring to my recient concerns about it, yes I follow.  Good Idea.

OK, I'll set up the threads.  I'll need a day or two as I'm working this weekend and I need some time to get things organized.  I also got my teaching assignment for the Spring semester so there is a need to organize my lectures notes too.

I'll be back!

Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on October 01, 2005, 01:23:39 pm
Paolo
In the BreadBaking Diagram, on BreadRecipe, how did you get {Specification} to appear?
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on October 01, 2005, 03:58:48 pm
Quote
Paolo
In the BreadBaking Diagram, on BreadRecipe, how did you get {Specification} to appear?
Advanced button of the General Tab... :)

Paolo
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on October 01, 2005, 08:36:20 pm
Paolo;

Two questions and a thought:

1) Have you looked at the Java code EA generates for the BreadRecipe class?  When I did, BreadRecipe.java contains two definitions for the class; one with the nested classes and a second empty class stub.  ??? Whyizzat?

2) I've not used the {specification} check box before nor can I find any documentation on it.  Nor do I understand the Multiplicity value.  Can you explain what they represent and what impact they might have on code generation?

Thought:  Would you consider using the Stereotype of <<intrinsicPartOf>> on the BreadProduct/BreadDough association line to identify the meronymy type?  I'd stereotype the line, not the DoughMixing class.
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on October 02, 2005, 02:28:43 am
Quote
Paolo;

Two questions and a thought:

1) Have you looked at the Java code EA generates for the BreadRecipe class?  When I did, BreadRecipe.java contains two definitions for the class; one with the nested classes and a second empty class stub.  ??? Whyizzat?

2) I've not used the {specification} check box before nor can I find any documentation on it.  Nor do I understand the Multiplicity value.  Can you explain what they represent and what impact they might have on code generation?

Thought:  Would you consider using the Stereotype of <<intrinsicPartOf>> on the BreadProduct/BreadDough association line to identify the meronymy type?  I'd stereotype the line, not the DoughMixing class.
Jim,

The "Stub" is the constructor.  This constructor is often (in my view mis-)named the default constructor.

In my view, it should be called the constructor with no parameters.  In the DoughFormulation Class, I make it private to ensure it isn't accidentally invoked.

public class DoughFormulation
{
...
   private DoughFormulation()
   {
   }

   public DoughFormulation(BreadProduct BreadProduct, BreadDough BreadDough, int BreadType, int Yield)
   {
...
   }
...
}

The specification checkbox is documented (tautologically) in the EA help file.  As to what it means to define a Classifier as a Specification...  In the past I've used a stereotype for this purpose, but in EA I'm given a property.  BTW: The EA Help file implies a connector can also be a specification, but there doesn't seem to be any way to set it...

There are two related concepts, Cardinality and Multiplicity.  (I've described Multiplicity as a Cardinality that can be zero... - since, in my view, Cardinality can't be zero).  Anyway, EA has both on its UI (Unique Interface), however, but ONLY emits Multiplicity.

Multiplicity defines how many instances of a Class you expect in your environment.  Thus, if a Class is supposed to be a Singleton, this value should be set to 1.

As to your thought...  Firstly, I think (as we've previously discussed) «partOf» actually requires we consider what parts are intrinsically part of the whole and which aren't. If something is intrinsically part of the whole, then it's multiplicity can't have a lower bound of zero.  Looking at the oven; you can't have an oven without a heat source.  But it could be argued that an oven doesn't need door(s).  If so, then we can set the multiplicity of the association to 0..* instead of 1..*.  For my model, I'm asserting that a bread making oven DOES need a door...

Secondly, given my view that the AssociationClass and the Association are effectively one and the same, applying the stereotype to the Association also conceptually applies it to the AssociationClass and vice versa.

Now, as to your specific question... I don't agree that the link you mention should have that stereotype; however, that's because I now think the model is wrong in this area!

You'll see that in the current model, there is a 1:0..* relationship between the BreadDough and the BreadProduct.  The BreadDough, however, is supposed to to be the entire mass for the batch, not just the Dough for a particular product.  What's missing is shown in the diagram below.
(http://sharepoint.knowledgerecovery.com/external/eaug/EA%20Graphics/PaoloFCantoni_Images/BreadAndDough.jpg)
The large mass of dough is portioned to make individual products.
I've altered the relationship to allow more then one batch of dough to be used in the creation of the dough for one product (arguable - or at least determined by the rules of the bakery).
As a consequence, I've moved the proving relationships to the BreadProductDough rather than BreadProduct.  Thus the BreadProductDough represents the bread before baking and the BreadProduct after baking...

HTH,
Paolo
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on October 02, 2005, 05:43:42 am
Paolo;

I'm used to seeing constructor methods inside of the class they instantiate, not outside of it.  It looks like they are generating two constructors.  What I'm getting is two classes in the same source file (a no no where I come from because of the problems that creates, but allowed by Java) and both classes have the same name!!  I think c++ allows this type of class specification resumption, but I'm not aware that Java does.
Code: [Select]
package Bread;

public class BreadRecipe {

public class BreadDoughFormulation {

private int wholeBreadMass;
private int kneedingDuration;

public BreadDoughFormulation(){}

public void finalize() throws Throwable {}

}


public class ProvingAndBakingFormulation {

private int bakingTime;
private int provingDuration;
private int ovenTemperature;

public ProvingAndBakingFormulation(){}

public void finalize() throws Throwable {}

}


public BreadRecipe(){}  // The constructor !!


public void finalize() throws Throwable {}

}   // End of BreadRecipe class

/**                                 What is this??!!
* @author Jim Shaw
* @version 1.0
* @created 01-Oct-2005 11:09:05 PM
*/
public class BreadRecipe {   // If this is a constructor it should be in the class above??


public BreadRecipe(){

}

public void finalize() throws Throwable {}

}


Quote
In my view, it should be called the constructor with no parameters.
I agree. Most texts are too patronizing about the instantiation process, especally about what goes on behind the scenes.  However, in your code you have placed the constructor inside of the class, which is where I expect to find it.

Quote
Secondly, given my view that the AssociationClass and the Association are effectively one and the same, applying the stereotype to the Association also conceptually applies it to the AssociationClass and vice versa.

 Another unique EA interface then as EA allows them both to be independently Stereotyped.  These extentions to UML might be nice, but they are really confusing if Sparks does not document them as such.  ::)

Quote
If something is intrinsically part of the whole, then it's multiplicity can't have a lower bound of zero.
 A subulty I missed, this is good.

Quote
The large mass of dough is portioned to make individual products.
I've altered the relationship to allow more then one batch of dough to be used in the creation of the dough for one product (arguable - or at least determined by the rules of the bakery).
As a consequence, I've moved the proving relationships to the BreadProductDough rather than BreadProduct.  Thus the BreadProductDough represents the bread before baking and the BreadProduct after baking...
For the sake of consistancy in our goal to demonstrate the six meronymys, can we put one on this association too?
Can you republish the origiional diagram (used in the reply #32 of this thread) so that that reply will always contain the current version?  It would be nice to keep the current drawing published in one place for reference from the other threads forked from here.



Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on October 02, 2005, 06:24:27 am
Quote
Swans, Tigers - its all Good!  ;D ;D ;D
Why pick this thread?
Or did you know I used to drive past the Balmain Club a lot when I lived in Sydney?

Paolo
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on October 02, 2005, 06:51:38 am
Quote
Paolo;

I'm used to seeing constructor methods inside of the class they instantiate, not outside of it.  It looks like they are generating two constructors.  What I'm getting is two classes in the same source file (a no no where I come from because of the problems that creates, but allowed by Java) and both classes have the same name!!  I think c++ allows this type of class specification resumption, but I'm not aware that Java does.
[size=13][SNIP][/size]
Jim,
I think you have fallen foul of EA's UI (Unique Interface).  My version only has the one constructor, inside the class.  You may have got a left over from a previous emission.  When I was doing my preliminary testing of EA code emission, I couldn't get it to reliably locate and update the right stuff in various files, especially if I tried round-tripping.  If you delete the file and recreate, you should find all is fine.

My testing was another reason I decided to go the route of decoupling code generation from model management.  Again, I don't think EA is worse than any other tool, I just think round tripping to pure code is fatally flawed.
Quote
I agree. Most texts are too patronizing about the instantiation process, especially about what goes on behind the scenes.  However, in your code you have placed the constructor inside of the class, which is where I expect to find it.
As I said, try it again and it should be in yours also.
Quote
Another unique EA interface then as EA allows them both to be independently Stereotyped.  These extensions to UML might be nice, but they are really confusing if Sparx does not document them as such.  ::)
Here, It's not EA's fault.  This is my private view (that they are one and the same) - I've explained the reasons in other posts.  Given the current state of the UML 2 specification, EA is quite within its rights to see them as separate elements.  Again, EA isn't alone in this.
Quote
For the sake of consistency in our goal to demonstrate the six meronymies, can we put one on this association too?
Do you mean the new 1:0..1 be made from \ be made into?  I put the «portionOf» stereotype on the other one.  The reason I didn't put one on the Association I just mentioned is that I don't think it's a meronymy.  In my view the relationship between the BreadProductDough and the BreadProduct is between two wholes and therefore not a meronymy.
Quote
Can you republish the original diagram (used in the reply #32 of this thread) so that that reply will always contain the current version?  It would be nice to keep the current drawing published in one place for reference from the other threads forked from here.
I'm happy to publish the current diagram in one place, but #32 shouldn't be it (In my view).  I think it's good to show the evolution.  Also, the diagram and discussion wouldn't make sense if it wasn't static.

Paolo


Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on October 02, 2005, 05:00:12 pm
Paolo;
Quote
I think you have fallen foul of EA's UI (Unique Interface).  My version only has the one constructor, inside the class.  You may have got a left over from a previous emission
Nope!  I deleted all the source files and the directory they were in and reran the generation.  I got the exact same result that I posted above.  :'(  I think EA has an an enhancement opportlunity here.

Quote
In my view the relationship between the BreadProductDough and the BreadProduct is between two wholes and therefore not a meronymy.

OK, upon further reflection I see that you are correct.  I agree.

Quote
I'm happy to publish the current diagram in one place, but #32 shouldn't be it (In my view).  I think it's good to show the evolution.  Also, the diagram and discussion wouldn't make sense if it wasn't static.
I had the same thoughts, but didn't know you were willing to provide a home for a current version.  When you set that up, give me the URL so I can use it for refererence in the new threads.

Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on October 02, 2005, 06:41:56 pm
Quote
Paolo;
Nope!  I deleted all the source files and the directory they were in and reran the generation.  I got the exact same result that I posted above.  :'(  I think EA has an an enhancement opportunity here.
[size=13][SNIP][/size]
Check your database, you may have a second object with that name... That's what I meant about the UI.  If you change a Class to an Association Lozenge, it is no longer visible in the Browser...  But it's still there!

Paolo
Title: Re: Collections, Containers, Composites & Nest
Post by: jeshaw2 on October 02, 2005, 09:36:34 pm
I've looked in gthe project browser and only found one BreadRecipe class.

I opened the database in Access and looked at t_object but didn't find anything but packages.  When I expanded the Bread Package, I didn't see anything recognizable.  :'(
Title: Re: Collections, Containers, Composites & Nest
Post by: SF_lt on October 10, 2005, 06:59:22 am

Paolo, what tools do you use to get code?
EA for design, then emit XMI to Rose?
Title: Re: Collections, Containers, Composites & Nest
Post by: Paolo F Cantoni on October 10, 2005, 03:32:42 pm
Quote
Paolo, what tools do you use to get code?
EA for design, then emit XMI to Rose?
sf,

My references to Rose are historical.  Initially I had my own Conceptual Modelling Tool based on ER style diagrams (with OO overtones).   I built a lot of model checking algorithms and a verbaliser (it describes the model in narrative).  When I joined my current employers, I changed to Rose (as it was their modelling tool) and I wanted to get experience in UML.  I built the verbaliser in Rose.   I haven't yet moved it to EA - only through lack of resources.

The only code I've emitted is using EA, but apart from some early tests I've emitted model metadata through my own XML structure and used another tool CodeSmith/CodeDOM to create the code.

Unfortunately, for the present I've been diverted onto other tasks so the code generator is on-hold.

Nevertheless, I believe that the stuff Jim and I are talking about will allow me to adorn the model with sufficient metadata to aid in the generation process.  I stress that it is early days yet, but so far, each piece of the vision has been implemented without undue problems.  Thus I'm quite hopeful.

Also, in line with my approach to system building, I canvas as much as possible in the CIM domain.  One I have a CIM model that makes sense, I start implementing.  I try to resist implementation until the CIM makes sense in the area I'm trying to implement.

Paolo