Bugzilla – Full Text Bug Listing
| Summary: | UML2 Implementation Bug - Redefinable Template Signature does not conform to OMG Spec | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] MDT.UML2 | Reporter: | Aitor <aitor.aldazabal> | ||||
| Component: | Core | Assignee: | James Bruck <bruck.james> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | minor | ||||||
| Priority: | P3 | CC: | aitor.aldazabal, aldazabal.a, bruck.james, Kenn.Hussey | ||||
| Version: | 3.0.0 | Keywords: | plan | ||||
| Target Milestone: | M6 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | Compliance | ||||||
| Attachments: |
|
||||||
If I'm not mistaken, what you are proposing would mean that there would be no difference between inheritedParameter (which is derived) and parameter list. It strikes me as being a little different from other areas in the spec. Hello James, The collections would indeed be different. inheritedParameters would contain a subset of the parameter list. This is, those parameters which are inherited but not owned. The parameter list should contain all, both inherited and owned parameters. This is to allow proper multi-level inheritance between templates. I think I have seen something similar to this in other areas of the spec, having a collection with only the inherited ones and having another collection containing all the elements. Something like this could be the memberEnds and ownedEnds in associations. What do you think? An analogy would be If we compare to Classifier for example, the getMembers() does return inherited members aswell. Classifier has getMembers(), getOwnedMembers() and getInheritedMembers(). In our case we have.. 1. TemplateSignature::parameter 2. TemplateSignature::ownedParameter 3. RedefinableTemplateSignature::inheritedParameter The parameter collection returns all the owned and non-owned TemplateParameter (but not the inherited ones). The ownedParameter collection contains only the owned TemplateParameters. Currently, the inheritedParameter collection looks at the extended Signatures and collects all the parameters (all owned and non-owned parameters) that are strictly inherited. So you are correct that inheritedParameter and parameter would differ in your proposed implementation. The memberEnds and ownedEnds in Association is a bit different because memberEnds does not return inherited ends. I think a better analogy would be Association member and ownedMember, where member returns inherited members aswell. Originally I was looking at the attribute and ownedAttribute collections on Class. The attribute collection does not consider inherited attributes. Kenn correctly points out that parameters is not shown as being derived which it would have to be if it included inherited parameters. So there is an inconsistency in the spec. If we follow the existing pattern for the API's we would add a allParameters() function which will return parameters with inherited parameters. This is the same pattern on Classifier such as attributes, allAttributes, ownedAttributes etc. What I could do is add an allParameters() and raise an issue with OMG. Unfortunately I don't think this will help you in the near term. Thank you all for your input. I agree that the example with the classifier that James proposed explains the analogy much better. I also agree that there is an inconsistency in the spec, however I am inclined to think that the solution would be to show the members attribute as derived. The allParameters() would be helpful as long as it returns all the operations of the signature and all the parameters of the signatures it "specializes" or extends from in a recursive fashion. The major problem I guess relies on the spec, with states that inherited parameters of a Template which extends another are calculated from the parameter List. This list does not take into account previously inherited parameters. This issue makes it "impossible" to create a proper template inheritance structure. Only the parameters of the nearest level are inherited, the rest are lost. For the moment I have solved this issue by creating an utility M2M transformations which manually searches for the entire extension tree and calculates the proper Set of attributes. So for the near term I'm already "satisfied" ;-) I would appreciate if you could raise this issue, I do not know the procedure too well myself but if there is anything I can do to help please let me know (I'll ask around and inform myself anyway). As for the allParameters operation, if it were to work as I have tried to specify I think it would be most helpful. I think I can provide you with the Java code I used to implement the transformation, in order to make sure that we are both in the same page. Again, thanks a lot for your time. Created attachment 107705 [details]
Java Example Code for the getAllParameters operation
RTF issue 12580 has been raised at the OMG to address the inconsistency in the spec. Closing this defect since it depends on http://www.omg.org/issues/uml2-rtf.html#Issue12580 and will be fixed when the spec gets updated. . |
Build ID: 200706251652 Steps To Reproduce: 1. Create a new UML model with the tree editor 2. Create Class A 3. Create a Redefinable Template Signature inside Class A 4. Add a template parameter to the signature (I used the Classifier Template parameter) 5. Create Class B 6. Create a Redefinable Template Signature inside Class B 7. Add the Template Signature from Class A to the extendedSignature reference of the signature in Class B. 8. The extended template's parameters appear correctly in the inherited parameter section but they don't appear in the parameter section. This seems to be non compliant with the standard. See more information below. More information: "/ inheritedParameter : TemplateParameter[*] The formal template parameters of the extendedSignature." This works OK! "[1] The inherited parameters are the parameters of the extended template signature. inheritedParameter = if extendedSignature->isEmpty() then Set{} else extendedSignature.parameter endif" This works OK too! "All the formal template parameters of the extended signatures are included as formal template parameters of the extending signature, along with any parameters locally specified for the extending signature." DOESN'T WORK! Following this specification and going back to the TemplateSignatureSpec parameter : TemplateParameter[1..*] The ordered set of all formal template parameters for this template signature. Thus this set (parameter) should be updated with the inheritedParameters and it is not. This really becomes an issue when trying to create a third Class C and create a RedifinableTemplateSignature for this class. If we want this template signature to extend the one from class B it will inherit 0 parameters, since the inheritanmce only looks at the parameter referece (which by the way is OK by the standard).