Showing the classifier in a part's name

[jeshaw2]

Under Help "Properties (EA User Manual)", in the example Component Structure diagram, the name of a Part's classifier appears after the Part's name, delimited by a colon.  Eg.;  libBooks:Books.  It goes on to say:

After dragging parts from the toolbox out to the workspace, right-click on a part and select Set Classifier Instance to link to a classifier.

When I right-click on the part, "Set Classifier Instance" does not appear as an option.  
Under "Advanced settings" I do get a 'Set Property Type' option which in turn provides a list-box where I can find the parent class for the type, but selecting that classifier does not result in its appearance in the diagram.

I'm afraid that if I type the classifier's name in the part's name field, it will have an undesirable effect on the generated Java code.

What is the best way to get the classifier name on the diagram in EA?

Thanks
Jim

[thomaskilian]

You have to create an object. Either transform the class to an object or drag a new one onto the diagram. The option will then show up.

[jeshaw2]

Well, that worked, but now I've lost the ability to set the 'Custom Properties' isReference to 'true' so that I get a dashed outline signifying that the object is not 'owned' by the containing object...

What am I missing here?

Cheers
Jim

[Maarten]

You can use classes. Drag them on the diagram - create them as part - right click - features - feature visibility - check the "Show element type (Port and Part only") checkbox"

If I understood your question well this should do what you want

[jeshaw2]

Thanks, but I don't think you understand.  I recommend you review figure 114 in Section 9 of the OMG UML spec.  Using a class|part gives me 1/3 of my modeling needs, using an object provides another 1/3.  Some UML 2.0 features still seem to be missing, or, at least I can't find them.  All of these features should be available in a single part element.  For example, I should be able to specify a part's properties and have them appear in the (class structure?) diagram.

Parts in a class context on a Composit Structure diagram are actually Properties of a role that an underlying class instance plays in realizing the composite object's behavior (I think I said this correctly).  They do not represent a class. Nor do they represent an instance;  that prevent models implementing the principle of Inversion of Control or specifying an interface as the part's classifier.

I'm not convinced that EA currently models this part of UML 2.0 fully; but I'm still open for enlightenment.

This issue is turning out to be more interesting than I thought.  For now, I'm studying Section 9 of the OMG UML Architecture Specification.  Hopefully that will provide proper enlightenment.  If not, perhaps I can come back in another thread with a more complete and supported statememnt of my problem.  At present, my questions on this topic are spread across this and several other forum threads and i need to gather everything into a single context.

Thanks
Jim

[thomaskilian]

Quite interesting indeed. Also you should note that there are two (redundant) representations in that picture. Maybe you choose (i)?

[jeshaw2]

Hummm...not completely redundant I think.  The OMG UML spec just above the figure states:

Figure 114 shows two possible views of the Car class. In subfigure (i), Car is shown as having a composition associations with role name rear to a class Wheel and an association with role name e to a class Engine. In subfigure (ii), the same is specified. However, in addition, in subfigure (ii) it is specified that rear and e belong to the internal structure of the class Car. This allows specification of detail that holds only for instances of the Wheel and Engine classes within the context of the class Car, but which will not hold for wheels and engines in general. For example, subfigure (i) specifies that any instance of class Engine can be linked to an arbitrary number of instances of class Wheel. Subfigure (ii), however, specifies that within the context of class Car, the instance playing the role of e may only be connected to two instances playing the role of rear. In addition, the instances playing the e and rear roles may only be linked if they are roles of the same instance of class Car.
In other words, subfigure (ii) asserts additional constraints on the instances of the classes Wheel and  Engine, when they are playing the respective roles within an instance of class Car. These constraints are not true for instances of Wheel and Engine in general. Other wheels and engines may be arbitrarily linked as specified in subfigure (i).

I think that sub-fugure (i) would allow the engine in myCar to be attached to the wheels in yourCar?  That would help keep yourFuelCost attribute low, but myFuelCost value would not make me happy.  

By the way, I figured out my issue with getting property attrubutes on the diagram..I need to use the Tagged Values feature! I'm beginning to figure out how to use them.  I was looking for (but didn't know what to call them) the subset, redefines, union, etc. tags.

Now if I can get the Part element working for me I'm home free.  In the part element (not in a substituted class, interface, or object element) I need to show the part's classifier and ownership status via the isReference flag. We should not confuse an object with the part it plays in a composition.  i.e.; Tom Jones (the actor-object) is not Hamlet (the part) in Shakespear's play (the composition).  Tom delivers the behaviors specified by the Hamlet interface; as well as can other Shakespearean actors.  When the play is presented (at execution time) last minute changes to the actors often occurs, so hard coding objects creates unwanted dependencies.

So, how can I use the Part element and specify its classifier and ownership status?

[jeshaw2]

Maarten!
My appologies.  You did understand and your solution works.  I just didn't understand your procedure, but when I worked it out I got just what I needed.
Thanks you,
Jim