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
