This all seems quite complex. I've spent some tmie trying to think this through and this is what I've come up with.
See the diagram in UML1.4.2 spec ( http://www.omg.org/spec/UML/ISO/19501/PDF ) page 339. My design was very much driven from that to where I got in the code at the moment. That diagram shows that a ModelElement has a composite relationship to own many TemplateParameters The TemplateParameter has just 3 related model elements and those are not any specific type of model element like Classifier but can be any ModelElement Those 3 are 1. template ======== The template is just a pointer back to the ModelElement owning the TemplateParameter 2. parameter ========= The parameter association from TemplateParameter to the ModelElement (the middle assoc in the diagram paramterTemplate->parameter) is a composite relationship showing that the parameter ModelElement is contained in the TemplateParameter. That is why I assumed we would create this at the same time as the TemplateParameter is created and the user would have no combo for this to select a different model element. I think you (Alexander) made the same assumption as I think this is originally your code in the UmlFactoryMDRImpl when create a TemlpateParameter <snip> } else if (elementType == this.metaTypes.getTemplateParameter()) { // TODO: the type of the model element used in a type parameter // (ie the formal) needs to match the actual parameter that it // gets replaced with later. This code is going to restrict that // to always being a Parameter which doesn't seem right, but I // don't have time to debug it right now. - tfm - 20090608 Parameter param = getCore().createParameter(); param.setName("T"); // default parameter name element = modelImpl.getCoreFactory().buildTemplateParameter(container, param, null); } else { </snip> The TemplateParameter is created containing a parameter which in the case of the code above is a Parameter I think this is pretty much correct apart from the fact that the model element type of the "parameter" is hard coded to Parameter. See Toms comments in the code and this snippet below from page 69 of the spec. <snip> A template element has the templateParameter association to a list of ModelElements that serve as its parameters. To avoid introducing metamodel (M2) elements in an ordinary (M1) model, the model contains a representative of each parameter element, rather than the type of the parameter element. For example, a frequent kind of parameter is a class. Instead of including the metaclass Class in the (M1) ordinary model, a dummy class must be declared whose name is the name of the parameter. This dummy element is meaningful only within the template (it may not be used within the wider model) and it has no features (such as attributes and operations), because the features are part of an actual element that is supplied when the template is bound. Because a template parameter is only a dummy that lacks internal structure, it may violate well-formedness constraints of elements of its kind; the actual elements supplied during binding must satisfy ordinary well-formedness constraints. </snip> I think the parameter is the "dummy" element being discussed here "This dummy element is meaningful only within the template (it may not be used within the wider model)" - so this should not be a combo to select any other model element from the model. So I think the control I have at the moment is correct but we could do some thing better. As a Java developer the normal type for the parameter I would think would be a classifier as for something like ArrayList<T> The template is the class ArrayList. The parameter is T which we would expect to be either a Class or an Interface. I'm obviously blinkered by my perspective as a java developer though as the spec makes it clear that this can be any model element type. 3. defaultElement ============= This is shown in the spec as being any other model element in the model. Taking the ArrayList<T> example once more we could say that as T is a classifier then defaultElement can be any specific instance of a classifier such as Object. So I think this should be a combo where the type selectable should be the same type as the parameter. In other words if the parameter is a classifier then then defaultElement combo is a list of all classifiers in the model. Short term changes required based on the above =================================== I will change the default type of parameter to be created to a Classifier instead of a Parameter I'll replace the display of the parameter to become more like Alexanders original implementation where it is a text field on the TemplateParameter panel that is actually editing the name of the attached property instance. So the user cannot actually navigate to the parameter from the TemplateParameter. The reason for this is again taken from the spec that I quoted above. I repeat here - "This dummy element is meaningful only within the template", "it has no features (such as attributes and operations)". So the user has no need to see the whole of the classifier, they only need the name. The defaultElement I will make a combo listing only Classifiers in the model. Medium term changes required ======================= A new field on the TemplateParameter panel that show the metatype of the current parameter (initially Classifier). The user can choose any other type. When a type is chosen the parameter is placed with a new dummy element of that type with the name copied from the previous instance. The defaultElement combo will return all model elements of the type chosen. Long term thoughts ============== I'm wondering if we should actually have a panel for TemplateParameter (its not actually a model element). I'm wondering if we can have a specialist control for the template parameter list that uses a JTable for entry. Problems ======= Classifier is abstract in the UML meta model. Is it actually possible to create an instance to become the parameter (dummy element) Bob. 2009/12/12 Alexander Lepekhine <[email protected]>: > Hello, Bob! New panels are wonderful! Here is my point of view to template > parameter: defaultElement should not have drop down list at all. It is an > expression and may be represented as a simple text field. Instead parameter > itself is a classifier. It should have a drop down list with all classifiers > in the model. The most confusing thing in specification is template parameter > name - there is no place in the classifier where we can put it. In java > module I create artificial class for parameter and it's name becomes template > parameter name. Still don't know if it is correct. > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2429947 > > To unsubscribe from this discussion, e-mail: > [[email protected]]. > To be allowed to post to the list contact the mailing list moderator, email: > [[email protected]] > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2430010 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
