Issue 14928: Property subsets other regular property, non-derived union (uml2-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: Property subsets other regular property, non-derived union. I would like to get rid of that as it causes implementation overhead costs, we must manage and synchronize two collections. Association::memberEnd is not union but is subsetted Class::ownedAttribute is not union but is subsetted TemplateSignature::parameter is not union but is subsetted Resolution: Revised Text: Actions taken: January 8, 2010: received issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 08 Jan 2010 14:01:52 -0500 To: issues@omg.org, uml2-rtf@omg.org From: Juergen Boldt Subject: issue 14928 -- UML 2 RTF issue This is issue # 14928 Property subsets other regular property, non-derived union Property subsets other regular property, non-derived union. I would like to get rid of that as it causes implementation overhead costs, we must manage and synchronize two collections. Association::memberEnd is not union but is subsetted Class::ownedAttribute is not union but is subsetted TemplateSignature::parameter is not union but is subsetted Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: Steve Cook To: Nerijus Jankevicius , "uml2-rtf@omg.org" CC: "issues@omg.org" , "juergen@omg.org" Subject: RE: more metamodel issues Thread-Topic: more metamodel issues Thread-Index: AQHKj60Dpic3tfF8EkODQ0jXRBrDYpGKTmHA Date: Thu, 7 Jan 2010 16:41:17 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Nerijus, again an excellent list. My view is that (3) is definitely a bug (and is related to issue 9999: .Assocation::isDerived should be derived. and 12357: .CMOF file for UML2 does not have derived Associations marked as such.). (2) makes things tricky to implement but can be worked around. Another thing that Java cannot do is covariant type narrowing on redefinition, and we don.t rule that out. I can live with (2), personally. (1) is likely to be contentious because it affects very commonly used things. What is your proposed metamodel modification for (say) Association::memberEnd? Jü can we create 3 issues from these lists please? - Steve From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 15:19 To: uml2-rtf@omg.org Subject: more metamodel issues There are more issues kinds that cause huge implementation problems, so we must do metamodel modifications: (All these categories must be discussed, as I'm not sure they are really "bugs", but they cause implementation problems for sure.) 1) Property subsets other regular property, non-derived union. I would like to get rid of that as it causes implementation overhead costs, we must manage and synchronize two collections. Association::memberEnd is not union but is subsetted Class::ownedAttribute is not union but is subsetted TemplateSignature::parameter is not union but is subsetted 2) Redefined with lowered multiplicity. It is not possible to have correct Java implementation of that, as inherited class must have getter with same name which return type is not collection, but single element. We (and Eclipse) simply ignoring these redefinitions or adding constraint which checks value number in collection. OccurrenceSpecification::covered [1] redefines InteractionFragment::covered [0..*] Transition::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*] State::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*] StateInvariant::covered [1] redefines InteractionFragment::covered [0..*] Extension::ownedEnd [1] redefines Association::ownedEnd [0..*] Region::redefinitionContext [1] redefines RedefinableElement::redefinitionContext [0..*] 3) One association end is derived, another is not. It causes implementation issues, as when we set one end, opposite should be automatically set also. Vertex::outgoing [0..*] is derived, opposite Transition::source [1] is not Activity::structuredNode [0..*] is derived, opposite StructuredActivityNode::activity [0.. ConnectableElement::end [0..*] is derived, opposite ConnectorEnd::role [1] is not Package::ownedType [0..*] is derived, opposite Type::package [0..] is not Package::nestedPackage [0..*] is derived, opposite Package::nestingPackage [0..] is not Vertex::incoming [0..*] is derived, opposite Transition::target [1] is not Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple!