Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Paolo F Cantoni

Pages: 1 ... 353 354 [355] 356 357 ... 403
5311
Uml Process / Re: Abstraction of the Member_of Meronymy
« on: October 06, 2005, 03:53:51 pm »
Jim,

Again, just a quick note.

Yes, I was only using Collection as a synonym, but I agree that a Collection is very specialised (weak) form of Container.

Previously we've basically said:
Every Container has an implicit Collection (those items in it).  Only some Collections exhibit Container Characteristics.

As to my example,  I was focusing on the fact that at work we need to move a specific item between the "collections".

As far as I can tell I'm not using metonymy...

Paolo

5312
Uml Process / Re: Abstraction of the Member_of Meronymy
« on: October 06, 2005, 05:43:07 am »
Quote
[size=13][SNIP][/size]
• Members implement a common interface.
The common interface may be only that related to the membership.  That is to say, If the items are arbitrarily placed in the group, then they may not have much in common.
Quote
• The group (as a lexical collective) is a concept different and apart from the crop's hosting context.  For example:  there is a difference between an elevator and those_who_are_on_the_elevator.  We may speak of the elevator_people as either being on the elevator or awaiting_arrival of the elevator at their floor.
[size=13][SNIP][/size]
Jim,
This one I'm not so sure about...
At work, we deal with groups of people, and have a number of groups:  People_waiting_at_Stop_for_Bus, Passengers_boarding_Bus, Passengers_on_Bus, Passengers_alighting_Bus, People_at_Stop_having_alighted_from_Bus, People_away_from_Stop
We need to exercise our systems but simulating People moving between these groups (collections).  The people do different things depending on which collection they are in.  For example, a Passenger_boarding_Bus will Tag-On (with their smart-card ticket) through an entry door.  Similarly, Passenger_alighting_Bus will Tag-Off through an exit door.
I'm not sure the concept you proposed works this way...
Can you comment on whether you mean the same as me or something different?

Member_Of is a Collection is it not?

Paolo

5313
Uml Process / Re: Collections, Containers, Composites & Nest
« 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

5314
Uml Process / Re: Collections, Containers, Composites & Nest
« 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

5315
Uml Process / Re: Collections, Containers, Composites & Nest
« 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



5316
Uml Process / Re: Collections, Containers, Composites & Nest
« 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

5317
Uml Process / Re: Collections, Containers, Composites & Nest
« 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.

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

5318
Uml Process / Re: Collections, Containers, Composites & Nest
« 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

5319
Uml Process / Re: Collections, Containers, Composites & Nest
« 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?

5320
Uml Process / Re: Collections, Containers, Composites & Nest
« 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...

5321
Uml Process / Re: Collections, Containers, Composites & Nest
« 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...

5322
Uml Process / Re: Collections, Containers, Composites & Nest
« 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...

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

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

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




5323
Uml Process / Re: Collections, Containers, Composites & Nest
« 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

5324
Uml Process / Re: Collections, Containers, Composites & Nest
« 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

5325
Uml Process / Re: Collections, Containers, Composites & Nest
« 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


Pages: 1 ... 353 354 [355] 356 357 ... 403