Issue 14930: One association end is derived, another is not (uml2-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: 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 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:05:08 -0500 To: issues@omg.org, uml2-rtf@omg.org From: Juergen Boldt Subject: issue 14930 -- UML2 RTF issue This is issue # 14930 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 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! 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! ted-NM: yes From: "Nerijus Jankevicius" To: "Steve Cook" , Subject: Re: more metamodel issues Date: Thu, 7 Jan 2010 19:01:05 +0200 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-EsetScannerBuild: 6349 Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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! From: Steve Cook To: Nerijus Jankevicius , "uml2-rtf@omg.org" Subject: RE: more metamodel issues Thread-Topic: more metamodel issues Thread-Index: AQHKj60Dpic3tfF8EkODQ0jXRBrDYpGKTmHAgAAIwnyAAAKegA== Date: Thu, 7 Jan 2010 17:18:54 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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! Subject: RE: more metamodel issues Date: Thu, 7 Jan 2010 12:53:13 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: more metamodel issues thread-index: AQHKj60Dpic3tfF8EkODQ0jXRBrDYpGKTmHAgAAIwnyAAAKegIAACY2Q From: "Ed Seidewitz" To: "Steve Cook" , "Nerijus Jankevicius" , Well, no, I don.t think this is fair enough. I don.t think Java implementation issues should drive us to not use what otherwise are valid modeling constructs, especially when there are reasonable work arounds. There is no requirements that that the UML metamodel be implemented internally using Java classes that have any specific mapping from UML classes. For example, the internal representation could be in a generic document-oriented structure with self-describing metadata, rather than instantiated as Java object with metamodel-specific classes. And, even if you want to use specific Java classes, there is no requirement that the fields in those classes have identical multiplicities as in the metamodel. For instance, every Java instance variable could be a collection, and all multiplicities enforced by appropriate programmatic constraints. (After all, unless you use Java arrays, you can.t enforce multiplicities like 1..2 in the collection data structure anyway.) So, I don.t think any of the issues described in Nerijus additional list of issues below are .showstoppers., nor do I think they have XMI impacts. And I think changing them would arguably lead to poorer, not better, modeling constructions (though, I admit, this is arguable either way). So I don.t think these should be addressed by this RTF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 12:19 PM To: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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! DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=hjj1n8iHUQgZKQpVO9Jgb7d3yZbeKCn+yckBq1BAcWY=; b=Bkh/AJhK3ROhxnF/4MESKgLMml27xAEvcdMqf/LG/nIMbd64kUTc4oIMFC2G7wJxbg WeUtamomkOEA7XKKvjPPem1FXiZ6odomnZQB7eo71uXpBLSZ8w+WWAL/9TRXXPB2KhuS PdSi3937mECWCvhEMifrNBco/lKTjfwWZGXrI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=CGgFD13GQYABMmjREpfhiSB2KFPbfw7LSD4vk1JhhAXrRkVpMmdMVdN8dwNp9IRzcK vj+QdePRLwoeg12qhuN7+eNSGSbcZLmWrNPwpIuqf2b6JvfMXQSC+gakGw0watsequqX w+lid6b6EzAlGPBxRAo0o+q76LgQBpLQbZlts= Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 7 Jan 2010 13:01:33 -0500 X-Google-Sender-Auth: d1b73959715a3e28 Subject: Re: more metamodel issues To: Ed Seidewitz Cc: Steve Cook , Nerijus Jankevicius , uml2-rtf@omg.org I fully agree with Ed on this (for a change ). Java or XMI implementation concerns should not force us into contorting the metamodel. Bran On Thu, Jan 7, 2010 at 12:53 PM, Ed Seidewitz wrote: Well, no, I don.t think this is fair enough. I don.t think Java implementation issues should drive us to not use what otherwise are valid modeling constructs, especially when there are reasonable work arounds. There is no requirements that that the UML metamodel be implemented internally using Java classes that have any specific mapping from UML classes. For example, the internal representation could be in a generic document-oriented structure with self-describing metadata, rather than instantiated as Java object with metamodel-specific classes. And, even if you want to use specific Java classes, there is no requirement that the fields in those classes have identical multiplicities as in the metamodel. For instance, every Java instance variable could be a collection, and all multiplicities enforced by appropriate programmatic constraints. (After all, unless you use Java arrays, you can.t enforce multiplicities like 1..2 in the collection data structure anyway.) So, I don.t think any of the issues described in Nerijus additional list of issues below are .showstoppers., nor do I think they have XMI impacts. And I think changing them would arguably lead to poorer, not better, modeling constructions (though, I admit, this is arguable either way). So I don.t think these should be addressed by this RTF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 12:19 PM To: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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! From: Steve Cook To: Bran Selic , Ed Seidewitz CC: Nerijus Jankevicius , "uml2-rtf@omg.org" Subject: RE: more metamodel issues Thread-Topic: more metamodel issues Thread-Index: AQHKj60Dpic3tfF8EkODQ0jXRBrDYpGKTmHAgAAIwnyAAAKegIAACY2QgAAEPICAAAJy8A== Date: Thu, 7 Jan 2010 18:17:48 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: .Contorting the metamodel. is a wild exaggeration in regard to Nerijus.s suggestions. The metamodel is horribly contorted as it is: the current modeling of associations and their ends is a perfect example of it. Making UML simpler to implement cannot be anything but a good thing from an adoption and user perspective. Surely we can at least agree that Nerijus.s category 3 is a bug? From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 07 January 2010 18:02 To: Ed Seidewitz Cc: Steve Cook; Nerijus Jankevicius; uml2-rtf@omg.org Subject: Re: more metamodel issues I fully agree with Ed on this (for a change ). Java or XMI implementation concerns should not force us into contorting the metamodel. Bran On Thu, Jan 7, 2010 at 12:53 PM, Ed Seidewitz wrote: Well, no, I don.t think this is fair enough. I don.t think Java implementation issues should drive us to not use what otherwise are valid modeling constructs, especially when there are reasonable work arounds. There is no requirements that that the UML metamodel be implemented internally using Java classes that have any specific mapping from UML classes. For example, the internal representation could be in a generic document-oriented structure with self-describing metadata, rather than instantiated as Java object with metamodel-specific classes. And, even if you want to use specific Java classes, there is no requirement that the fields in those classes have identical multiplicities as in the metamodel. For instance, every Java instance variable could be a collection, and all multiplicities enforced by appropriate programmatic constraints. (After all, unless you use Java arrays, you can.t enforce multiplicities like 1..2 in the collection data structure anyway.) So, I don.t think any of the issues described in Nerijus additional list of issues below are .showstoppers., nor do I think they have XMI impacts. And I think changing them would arguably lead to poorer, not better, modeling constructions (though, I admit, this is arguable either way). So I don.t think these should be addressed by this RTF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 12:19 PM To: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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! Subject: RE: more metamodel issues Date: Thu, 7 Jan 2010 15:37:21 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: more metamodel issues thread-index: AQHKj60Dpic3tfF8EkODQ0jXRBrDYpGKTmHAgABC9KA= From: "Ed Seidewitz" To: Cc: , Well, perhaps I could be convinced that the third group of Nerijus. .more metamodel issues. represents a real issue. However, I am not sure. It may very well be the case that the derivation of one end of an association depends on the value explicitly set at the other end. I suppose it is worth some discussion though. I definitely don.t think groups 1 and 2 are problems with the metamodel, and the implementation approaches mentioned for them by Nerijus really seem quite straightforward to me. For group 1, the implementation should be managing two collections . subsetting in this case is just a constraint on the two collections. For group 2, the refefinition should be implementated as an additional constraint . in the end, all multiplicities are just constraints anyway. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 11:41 AM To: Nerijus Jankevicius; uml2-rtf@omg.org Cc: issues@omg.org; juergen@omg.org Subject: RE: more metamodel issues 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! From: Salman Qadri To: Steve Cook , Bran Selic , Ed Seidewitz , Nerijus Jankevicius CC: "uml2-rtf@omg.org" Date: Thu, 7 Jan 2010 16:07:08 -0500 Subject: RE: more metamodel issues Thread-Topic: more metamodel issues Thread-Index: AQHKj60Dpic3tfF8EkODQ0jXRBrDYpGKTmHAgAAIwnyAAAKegIAACY2QgAAEPICAAAJy8IAADdbQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US I do not feel category 3 is a bug. It is a valid use-case and if all the subsetted relationships between the ends of the associations are valid, then it should all work out if subsetted and redefined properties is implemented correctly: 1) Package-ownedType subsets Package-packagedElement (non-derived and the slot). So an append operation of a type T to the ownedType role of a Package P would place T in the packagedElement role of P. The opposite of Package-ownedType is Type-package, which is non-derived so the package role on T is set to the P. This was an easy case; now let.s look at a more complicated case. 2) Activity-structuredNode is derived and subsets Activity-node (non-derived), and has the opposite StructuredActivityNode-activity (non-derived) which redefines ActivityNode-activity (non-derived). ActivityNode-activity and Activity-node are opposites of each other. In MOF terms, Activity-node and ActivityNode-activity would be the slots, and so any actions on Activity-structuredNode would affect Activity-node, which should .automatically. update its opposite ActivityNode-activity, which means that StructuredActivityNode-activity should have the correct value since it redefines ActivityNode-activity. If you choose to make StructuredActivityNode-activity the slot as opposed to ActivityNode-activity, it still works out. If you.d like a much more thorough explanation of how all this can work at the MOF Instance Specification level, in terms of Links etc., I can present that as well. So, I don.t think category 3 is a bug. We.ve had discussions about association ends in the past under the topic of subsetting/redefinition implies specialization, and we looked at one possible implementation, which is the Milicev model: On the Semantics of Associations and Association Ends in UML Milicev, D.; Software Engineering, IEEE Transactions on Volume 33, Issue 4, April 2007 Page(s):238 - 251 http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326 Salman From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 1:18 PM To: Bran Selic; Ed Seidewitz Cc: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues .Contorting the metamodel. is a wild exaggeration in regard to Nerijus.s suggestions. The metamodel is horribly contorted as it is: the current modeling of associations and their ends is a perfect example of it. Making UML simpler to implement cannot be anything but a good thing from an adoption and user perspective. Surely we can at least agree that Nerijus.s category 3 is a bug? From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 07 January 2010 18:02 To: Ed Seidewitz Cc: Steve Cook; Nerijus Jankevicius; uml2-rtf@omg.org Subject: Re: more metamodel issues I fully agree with Ed on this (for a change ). Java or XMI implementation concerns should not force us into contorting the metamodel. Bran On Thu, Jan 7, 2010 at 12:53 PM, Ed Seidewitz wrote: Well, no, I don.t think this is fair enough. I don.t think Java implementation issues should drive us to not use what otherwise are valid modeling constructs, especially when there are reasonable work arounds. There is no requirements that that the UML metamodel be implemented internally using Java classes that have any specific mapping from UML classes. For example, the internal representation could be in a generic document-oriented structure with self-describing metadata, rather than instantiated as Java object with metamodel-specific classes. And, even if you want to use specific Java classes, there is no requirement that the fields in those classes have identical multiplicities as in the metamodel. For instance, every Java instance variable could be a collection, and all multiplicities enforced by appropriate programmatic constraints. (After all, unless you use Java arrays, you can.t enforce multiplicities like 1..2 in the collection data structure anyway.) So, I don.t think any of the issues described in Nerijus additional list of issues below are .showstoppers., nor do I think they have XMI impacts. And I think changing them would arguably lead to poorer, not better, modeling constructions (though, I admit, this is arguable either way). So I don.t think these should be addressed by this RTF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 12:19 PM To: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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! Subject: RE: more metamodel issues Date: Thu, 7 Jan 2010 17:26:38 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: more metamodel issues Thread-Index: AQHKj60Dpic3tfF8EkODQ0jXRBrDYpGKTmHAgAAIwnyAAAKegIAACY2QgAAEPICAAAJy8IAADdbQgABDvRA= From: "Pete Rivett" To: "Salman Qadri" , "Steve Cook" , "Bran Selic" , "Ed Seidewitz" , "Nerijus Jankevicius" Cc: The question to me is not whether it can be made to work but whether we need, or even benefit from such complexity: even the .easy case. is pretty non-intuitive and the benefits unclear. IMHO we have far too many different options . through redefinition (with or without renaming), subsetting (with or without unions), unions, readOnly, derivation . all at the Property (as opposed to the Association) level. Not to mention Property ownership (as incorrectly depicted through navigation arrows) which seems to have been based on a superseded MOF .composite closure. rule. And different contributors to the UML metamodel have, in a seemingly random manner (according to their personal understanding, preferences and interests) chosen different combinations for different parts of the metamodel. As a result we cannot readily answer challenges such as from Nerijus as to why something is modeled a certain way, let alone whether it makes sense and whether it can be implemented. If we need an academic paper (as referenced by Salman) to explain the latter then that.s a good indication that we.re in trouble. For example, why do we have Package::/ownedType but not Package::/ownedDependency (or a similar query for other subtypes of PackagedElement)? Another comprehensibility problem we have is the use of one construct . {subsets} for 3 distinct purposes (1) as part of a derived union, 2) to define a .query. such as ownedType and 3) as a genuine constraint): moreover it.s not possible to discern which purpose/semantics without going to a separate diagram (usually) to check whether the property being subsetted is derived/union. We also have other issues, discussed in other threads, such as whether/when it makes sense to have {ordered} on a derived union and to have derived properties updateable. It seems to me there is a small number (2 or 3) of patterns for association generalization that will cover most of our real metamodeling needs. We should document what these are and the criteria for when they should apply . and then apply that logic to the metamodel, while striving for forward compatibility at the XMI level (if necessary by documenting exceptions to the patterns). In fact I think the impact on the XMI will be minimal since most of these properties are not even serialized (e.g. derived properties and .owner. properties). As part of this we should consider including explicit association generalizations in the metamodel diagrams to provide a clearer, higher-level and graphical depiction of what.s happening. Though I accept this could make diagrams a bit more messy in terms of lines so we should test this out on a few. And we should clear up the fudge that has the semantics of association generalization as a semantic variation point (strictly speaking we only need to do this for MOF). For example, off the top of my head, here are some candidate requirements with patterns: note that this is a starter for discussion not fully-thought through a) Provide a generic/more abstract way of accessing relationships (e.g. ownership), or specifying their semantics in one place: use association generalization with an abstract association (and derived unions and subsets at the association end level) which also allows different names to be used for ends b) Apply specific constraints to a relationship: use association generalization with additional OCL on the subsetting association ends. c) Unify multiple inherited owner properties (e.g. as in StructuredActivityNode::activity which has disadvantage of hiding the inherited properties for navigation purposes): use association generalization with XOR (see below) to create what is in effect a .derived intersection.. The following to me are non-requirements for representation using metamodel constructs: · Use of subsetting to constrain 2 non-derived properties · Use of subsetting for type-based .queries. (if really needed a property such as ownedType can be defined as a derived property with an OCL query) · Use of redefinition to change multiplicity (this could be achieved through OCL as per recent discussion on this thread): this includes making a property mandatory or single-valued. · Use of redefinition to change property ordering · Use of redefinition to hide a property inherited from a superclass (this could be achieved by OCL to state the property must be empty) · Use of redefinition to change the default value of a property (I don.t think the metamodel uses this) Note that the use of OCL in the above does not require tools to implement OCL . the OCL is for specification purposes. Tools could implement this using code (which is what Nerijus says is needed anyway). I don.t think it.s justified to expect implementers to support the full combination of the capabilities listed in my first paragraph just for 3 or so uses in the UML metamodel. Note that the above proposal is for use in the UML metamodel itself: these capabilities would still be available to UML modelers in general. And would mean that redefinition is not used at all. One requirement we have no serious means to address (due to underspecification of XOR . and hence presumably its lack of use in the UML metamodel itself) is the one Nerijus raised about restricting a metaclass to have only one composite owner. We should specify XOR and make use of it. We should in the process try to avoid patterns such as in Fig 7.5 where ValueSpecification has separate non-derived properties for owningUpper and owningLower. This is also requirement c) above. It seems to me that this all should be addressed by the Simplification RFP response rather than the current RTF. Pete Regards Pete From: Salman Qadri [mailto:Salman.Qadri@mathworks.com] Sent: 07 January 2010 13:07 To: Steve Cook; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues I do not feel category 3 is a bug. It is a valid use-case and if all the subsetted relationships between the ends of the associations are valid, then it should all work out if subsetted and redefined properties is implemented correctly: 1) Package-ownedType subsets Package-packagedElement (non-derived and the slot). So an append operation of a type T to the ownedType role of a Package P would place T in the packagedElement role of P. The opposite of Package-ownedType is Type-package, which is non-derived so the package role on T is set to the P. This was an easy case; now let.s look at a more complicated case. 2) Activity-structuredNode is derived and subsets Activity-node (non-derived), and has the opposite StructuredActivityNode-activity (non-derived) which redefines ActivityNode-activity (non-derived). ActivityNode-activity and Activity-node are opposites of each other. In MOF terms, Activity-node and ActivityNode-activity would be the slots, and so any actions on Activity-structuredNode would affect Activity-node, which should .automatically. update its opposite ActivityNode-activity, which means that StructuredActivityNode-activity should have the correct value since it redefines ActivityNode-activity. If you choose to make StructuredActivityNode-activity the slot as opposed to ActivityNode-activity, it still works out. If you.d like a much more thorough explanation of how all this can work at the MOF Instance Specification level, in terms of Links etc., I can present that as well. So, I don.t think category 3 is a bug. We.ve had discussions about association ends in the past under the topic of subsetting/redefinition implies specialization, and we looked at one possible implementation, which is the Milicev model: On the Semantics of Associations and Association Ends in UML Milicev, D.; Software Engineering, IEEE Transactions on Volume 33, Issue 4, April 2007 Page(s):238 - 251 http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326 Salman From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 1:18 PM To: Bran Selic; Ed Seidewitz Cc: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues .Contorting the metamodel. is a wild exaggeration in regard to Nerijus.s suggestions. The metamodel is horribly contorted as it is: the current modeling of associations and their ends is a perfect example of it. Making UML simpler to implement cannot be anything but a good thing from an adoption and user perspective. Surely we can at least agree that Nerijus.s category 3 is a bug? From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 07 January 2010 18:02 To: Ed Seidewitz Cc: Steve Cook; Nerijus Jankevicius; uml2-rtf@omg.org Subject: Re: more metamodel issues I fully agree with Ed on this (for a change ). Java or XMI implementation concerns should not force us into contorting the metamodel. Bran On Thu, Jan 7, 2010 at 12:53 PM, Ed Seidewitz wrote: Well, no, I don.t think this is fair enough. I don.t think Java implementation issues should drive us to not use what otherwise are valid modeling constructs, especially when there are reasonable work arounds. There is no requirements that that the UML metamodel be implemented internally using Java classes that have any specific mapping from UML classes. For example, the internal representation could be in a generic document-oriented structure with self-describing metadata, rather than instantiated as Java object with metamodel-specific classes. And, even if you want to use specific Java classes, there is no requirement that the fields in those classes have identical multiplicities as in the metamodel. For instance, every Java instance variable could be a collection, and all multiplicities enforced by appropriate programmatic constraints. (After all, unless you use Java arrays, you can.t enforce multiplicities like 1..2 in the collection data structure anyway.) So, I don.t think any of the issues described in Nerijus additional list of issues below are .showstoppers., nor do I think they have XMI impacts. And I think changing them would arguably lead to poorer, not better, modeling constructions (though, I admit, this is arguable either way). So I don.t think these should be addressed by this RTF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 12:19 PM To: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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! Subject: RE: more metamodel issues Date: Thu, 7 Jan 2010 20:53:24 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: more metamodel issues thread-index: AQHKj60Dpic3tfF8EkODQ0jXRBrDYpGKTmHAgAAIwnyAAAKegIAACY2QgAAEPICAAAJy8IAADdbQgABDvRCAAC2NMA== From: "Ed Seidewitz" To: "Pete Rivett - Adaptive" Cc: Pete . Well, as far as what Nerijus was proposing under .more metamodel issues., he justified it by implementation concerns that I found neither compelling nor warranted. That is not to say there may not be other reasons for what he proposes, along the lines of what you are saying. We certainly all know that the UML metamodel could be done better, just as a matter of modeling style. However, I have to agree with your final comment that this is not something that we can tackle as part of the 2.4 RTF. Besides the inevitable discussions it will generate as to whether this is doable by an RTF at all, it is certainly outside the scope and timebox we are trying to establish for this particular RTF. We could probably spend the whole rest of the planned schedule for this RTF just debating (though probably a very profitable debate!) the best patterns to use, how to use them, etc. I also agree with you that the spec simplification submission would be a good time to handle this sort of thing. Unfortunately, as it turned out, the RFP pretty much precludes doing this: except for a few explicit things, the metamodel resulting from the spec simplification is supposed to be the same as the current merged L3 metamodel . down to all the subsetting, redefinition, etc. The RFP is for spec simplification, not metamodel simplification. This may be less than some of us would like to do, but there are also some good reasons on the other side for not doing more. I think the RFP is a good compromise to at least let us finally get a spec document we can live with for a while! -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, January 07, 2010 8:27 PM To: Salman Qadri; Steve Cook; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues The question to me is not whether it can be made to work but whether we need, or even benefit from such complexity: even the .easy case. is pretty non-intuitive and the benefits unclear. IMHO we have far too many different options . through redefinition (with or without renaming), subsetting (with or without unions), unions, readOnly, derivation . all at the Property (as opposed to the Association) level. Not to mention Property ownership (as incorrectly depicted through navigation arrows) which seems to have been based on a superseded MOF .composite closure. rule. And different contributors to the UML metamodel have, in a seemingly random manner (according to their personal understanding, preferences and interests) chosen different combinations for different parts of the metamodel. As a result we cannot readily answer challenges such as from Nerijus as to why something is modeled a certain way, let alone whether it makes sense and whether it can be implemented. If we need an academic paper (as referenced by Salman) to explain the latter then that.s a good indication that we.re in trouble. For example, why do we have Package::/ownedType but not Package::/ownedDependency (or a similar query for other subtypes of PackagedElement)? Another comprehensibility problem we have is the use of one construct . {subsets} for 3 distinct purposes (1) as part of a derived union, 2) to define a .query. such as ownedType and 3) as a genuine constraint): moreover it.s not possible to discern which purpose/semantics without going to a separate diagram (usually) to check whether the property being subsetted is derived/union. We also have other issues, discussed in other threads, such as whether/when it makes sense to have {ordered} on a derived union and to have derived properties updateable. It seems to me there is a small number (2 or 3) of patterns for association generalization that will cover most of our real metamodeling needs. We should document what these are and the criteria for when they should apply . and then apply that logic to the metamodel, while striving for forward compatibility at the XMI level (if necessary by documenting exceptions to the patterns). In fact I think the impact on the XMI will be minimal since most of these properties are not even serialized (e.g. derived properties and .owner. properties). As part of this we should consider including explicit association generalizations in the metamodel diagrams to provide a clearer, higher-level and graphical depiction of what.s happening. Though I accept this could make diagrams a bit more messy in terms of lines so we should test this out on a few. And we should clear up the fudge that has the semantics of association generalization as a semantic variation point (strictly speaking we only need to do this for MOF). For example, off the top of my head, here are some candidate requirements with patterns: note that this is a starter for discussion not fully-thought through a) Provide a generic/more abstract way of accessing relationships (e.g. ownership), or specifying their semantics in one place: use association generalization with an abstract association (and derived unions and subsets at the association end level) which also allows different names to be used for ends b) Apply specific constraints to a relationship: use association generalization with additional OCL on the subsetting association ends. c) Unify multiple inherited owner properties (e.g. as in StructuredActivityNode::activity which has disadvantage of hiding the inherited properties for navigation purposes): use association generalization with XOR (see below) to create what is in effect a .derived intersection.. The following to me are non-requirements for representation using metamodel constructs: · Use of subsetting to constrain 2 non-derived properties · Use of subsetting for type-based .queries. (if really needed a property such as ownedType can be defined as a derived property with an OCL query) · Use of redefinition to change multiplicity (this could be achieved through OCL as per recent discussion on this thread): this includes making a property mandatory or single-valued. · Use of redefinition to change property ordering · Use of redefinition to hide a property inherited from a superclass (this could be achieved by OCL to state the property must be empty) · Use of redefinition to change the default value of a property (I don.t think the metamodel uses this) Note that the use of OCL in the above does not require tools to implement OCL . the OCL is for specification purposes. Tools could implement this using code (which is what Nerijus says is needed anyway). I don.t think it.s justified to expect implementers to support the full combination of the capabilities listed in my first paragraph just for 3 or so uses in the UML metamodel. Note that the above proposal is for use in the UML metamodel itself: these capabilities would still be available to UML modelers in general. And would mean that redefinition is not used at all. One requirement we have no serious means to address (due to underspecification of XOR . and hence presumably its lack of use in the UML metamodel itself) is the one Nerijus raised about restricting a metaclass to have only one composite owner. We should specify XOR and make use of it. We should in the process try to avoid patterns such as in Fig 7.5 where ValueSpecification has separate non-derived properties for owningUpper and owningLower. This is also requirement c) above. It seems to me that this all should be addressed by the Simplification RFP response rather than the current RTF. Pete Regards Pete From: Salman Qadri [mailto:Salman.Qadri@mathworks.com] Sent: 07 January 2010 13:07 To: Steve Cook; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues I do not feel category 3 is a bug. It is a valid use-case and if all the subsetted relationships between the ends of the associations are valid, then it should all work out if subsetted and redefined properties is implemented correctly: 1) Package-ownedType subsets Package-packagedElement (non-derived and the slot). So an append operation of a type T to the ownedType role of a Package P would place T in the packagedElement role of P. The opposite of Package-ownedType is Type-package, which is non-derived so the package role on T is set to the P. This was an easy case; now let.s look at a more complicated case. 2) Activity-structuredNode is derived and subsets Activity-node (non-derived), and has the opposite StructuredActivityNode-activity (non-derived) which redefines ActivityNode-activity (non-derived). ActivityNode-activity and Activity-node are opposites of each other. In MOF terms, Activity-node and ActivityNode-activity would be the slots, and so any actions on Activity-structuredNode would affect Activity-node, which should .automatically. update its opposite ActivityNode-activity, which means that StructuredActivityNode-activity should have the correct value since it redefines ActivityNode-activity. If you choose to make StructuredActivityNode-activity the slot as opposed to ActivityNode-activity, it still works out. If you.d like a much more thorough explanation of how all this can work at the MOF Instance Specification level, in terms of Links etc., I can present that as well. So, I don.t think category 3 is a bug. We.ve had discussions about association ends in the past under the topic of subsetting/redefinition implies specialization, and we looked at one possible implementation, which is the Milicev model: On the Semantics of Associations and Association Ends in UML Milicev, D.; Software Engineering, IEEE Transactions on Volume 33, Issue 4, April 2007 Page(s):238 - 251 http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326 Salman From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 1:18 PM To: Bran Selic; Ed Seidewitz Cc: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues .Contorting the metamodel. is a wild exaggeration in regard to Nerijus.s suggestions. The metamodel is horribly contorted as it is: the current modeling of associations and their ends is a perfect example of it. Making UML simpler to implement cannot be anything but a good thing from an adoption and user perspective. Surely we can at least agree that Nerijus.s category 3 is a bug? From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 07 January 2010 18:02 To: Ed Seidewitz Cc: Steve Cook; Nerijus Jankevicius; uml2-rtf@omg.org Subject: Re: more metamodel issues I fully agree with Ed on this (for a change ). Java or XMI implementation concerns should not force us into contorting the metamodel. Bran On Thu, Jan 7, 2010 at 12:53 PM, Ed Seidewitz wrote: Well, no, I don.t think this is fair enough. I don.t think Java implementation issues should drive us to not use what otherwise are valid modeling constructs, especially when there are reasonable work arounds. There is no requirements that that the UML metamodel be implemented internally using Java classes that have any specific mapping from UML classes. For example, the internal representation could be in a generic document-oriented structure with self-describing metadata, rather than instantiated as Java object with metamodel-specific classes. And, even if you want to use specific Java classes, there is no requirement that the fields in those classes have identical multiplicities as in the metamodel. For instance, every Java instance variable could be a collection, and all multiplicities enforced by appropriate programmatic constraints. (After all, unless you use Java arrays, you can.t enforce multiplicities like 1..2 in the collection data structure anyway.) So, I don.t think any of the issues described in Nerijus additional list of issues below are .showstoppers., nor do I think they have XMI impacts. And I think changing them would arguably lead to poorer, not better, modeling constructions (though, I admit, this is arguable either way). So I don.t think these should be addressed by this RTF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 12:19 PM To: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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! From: Steve Cook To: Salman Qadri , Bran Selic , "Ed Seidewitz" , Nerijus Jankevicius CC: "uml2-rtf@omg.org" Subject: RE: more metamodel issues Thread-Topic: more metamodel issues Thread-Index: AQHKj60Dpic3tfF8EkODQ0jXRBrDYpGKTmHAgAAIwnyAAAKegIAACY2QgAAEPICAAAJy8IAADdbQgAET9DA= Date: Fri, 8 Jan 2010 11:50:19 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Salman I understand. Nevertheless, if you made Type::package or StructuredActivityNode::activity derived, you would lose nothing from a user.s point of view, and you would make it easier to implement. So I don.t think your argument is compelling. However, there is a case in the spec which I think does justify having one end derived and the other non-derived. It was introduced as the resolution to issue 10536, and is the property ConnectableElement::end. Here, end is marked as derived from its opposite ConnectorEnd::role. The sole purpose of this is to inhibit generation of XMI references for ConnectableElement::end, so as to avoid unwanted dependencies between XMI resources. Although this is exactly the kind of implementation consideration that some people seem to want to avoid putting in the spec, to me this is a compelling argument for allowing this pattern, given the current XMI rules. So I withdraw my .Surely we can at least agree that Nerijus.s category 3 is a bug?. . because I don.t agree. - Steve - PS (to Ed) incidentally my .fair enough. below was a confession of my ignorance about Java 1.5, not my agreement to accept category 2. From: Salman Qadri [mailto:Salman.Qadri@mathworks.com] Sent: 07 January 2010 21:07 To: Steve Cook; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues I do not feel category 3 is a bug. It is a valid use-case and if all the subsetted relationships between the ends of the associations are valid, then it should all work out if subsetted and redefined properties is implemented correctly: 1) Package-ownedType subsets Package-packagedElement (non-derived and the slot). So an append operation of a type T to the ownedType role of a Package P would place T in the packagedElement role of P. The opposite of Package-ownedType is Type-package, which is non-derived so the package role on T is set to the P. This was an easy case; now let.s look at a more complicated case. 2) Activity-structuredNode is derived and subsets Activity-node (non-derived), and has the opposite StructuredActivityNode-activity (non-derived) which redefines ActivityNode-activity (non-derived). ActivityNode-activity and Activity-node are opposites of each other. In MOF terms, Activity-node and ActivityNode-activity would be the slots, and so any actions on Activity-structuredNode would affect Activity-node, which should .automatically. update its opposite ActivityNode-activity, which means that StructuredActivityNode-activity should have the correct value since it redefines ActivityNode-activity. If you choose to make StructuredActivityNode-activity the slot as opposed to ActivityNode-activity, it still works out. If you.d like a much more thorough explanation of how all this can work at the MOF Instance Specification level, in terms of Links etc., I can present that as well. So, I don.t think category 3 is a bug. We.ve had discussions about association ends in the past under the topic of subsetting/redefinition implies specialization, and we looked at one possible implementation, which is the Milicev model: On the Semantics of Associations and Association Ends in UML Milicev, D.; Software Engineering, IEEE Transactions on Volume 33, Issue 4, April 2007 Page(s):238 - 251 http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326 Salman From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 1:18 PM To: Bran Selic; Ed Seidewitz Cc: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues .Contorting the metamodel. is a wild exaggeration in regard to Nerijus.s suggestions. The metamodel is horribly contorted as it is: the current modeling of associations and their ends is a perfect example of it. Making UML simpler to implement cannot be anything but a good thing from an adoption and user perspective. Surely we can at least agree that Nerijus.s category 3 is a bug? From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 07 January 2010 18:02 To: Ed Seidewitz Cc: Steve Cook; Nerijus Jankevicius; uml2-rtf@omg.org Subject: Re: more metamodel issues I fully agree with Ed on this (for a change ). Java or XMI implementation concerns should not force us into contorting the metamodel. Bran On Thu, Jan 7, 2010 at 12:53 PM, Ed Seidewitz wrote: Well, no, I don.t think this is fair enough. I don.t think Java implementation issues should drive us to not use what otherwise are valid modeling constructs, especially when there are reasonable work arounds. There is no requirements that that the UML metamodel be implemented internally using Java classes that have any specific mapping from UML classes. For example, the internal representation could be in a generic document-oriented structure with self-describing metadata, rather than instantiated as Java object with metamodel-specific classes. And, even if you want to use specific Java classes, there is no requirement that the fields in those classes have identical multiplicities as in the metamodel. For instance, every Java instance variable could be a collection, and all multiplicities enforced by appropriate programmatic constraints. (After all, unless you use Java arrays, you can.t enforce multiplicities like 1..2 in the collection data structure anyway.) So, I don.t think any of the issues described in Nerijus additional list of issues below are .showstoppers., nor do I think they have XMI impacts. And I think changing them would arguably lead to poorer, not better, modeling constructions (though, I admit, this is arguable either way). So I don.t think these should be addressed by this RTF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 12:19 PM To: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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! Date: Fri, 08 Jan 2010 12:10:18 +0000 From: Dave Hawkins User-Agent: Thunderbird 2.0.0.6 (X11/20070728) To: Nerijus Jankevicius CC: uml2-rtf@omg.org Subject: Re: more metamodel issues X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0208.4B4720BC.01A8:SCFMA4539814,ss=1,fgs=0 Nerijus Jankevicius wrote: 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 We have no implementation issue with this and I don't think it should be changed. I don't see why it's any different to having a derived union as a superset. 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..*] I think there may be a MOF specification issue here. Section 9.1 contains the following text: get(property: Property) : Object Gets the value of the given property. If the Property has multiplicity upper bound of 1, get() returns Property. If Property has multiplicity upper bound >1, get() returns a ReflectiveSequence containing Property. If there are no values, the ReflectiveSequence returned is empty. ReflectiveSequence is defined Section 10.5, .MOF::Common,. on page 24. Exception: throws IllegalArgumentException if Property is not a member of the Class from class(). As a reflective sequence almost certainly isn't of the same type as the property, I think this could create an invalid model. It needs to be clearer how redefinition works in this case. 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 I don't particularly like these. I think we've tended to assume that the derived end is actually the same as a non-navigable end, although that's not generally true. 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! -- Dave Hawkins | Principal Software Engineer | +44 118 924 0022 Oracle JDeveloper Development Oracle Corporation UK Ltd is a company incorporated in England & Wales. Company Reg. No. 1782505. Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA. To: uml2-rtf@omg.org Subject: RE: more metamodel issues X-KeepSent: 4F6F945F:E77BFAAC-852576A5:0047D4BB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Fri, 8 Jan 2010 06:26:10 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 01/08/2010 06:26:12, Serialize complete at 01/08/2010 06:26:12 We're starting to identify the issues and techniques that we will want to apply to the simplification of UML itself, what we intended to happen after 2.5. 2.4 is intended to address show-stopper issues - issues that prevent the creation of valid UML models, or the proper XMI exchange of those models. 2.5 is intended to cleanup and simplify the specification itself and effectively describe the 2.4 metamodel. Together, these provide a foundation of a usable, implementable, and exchangeable UML. Hopefully this will provide a solid starting point to discuss and implement significant changes to UML in order to improve its value proposition. Simplification of UML itself should start with what we are trying to accomplish with the language. Is it capturing and communicating actionable information about complex systems. Is it model driven development? Is it visual coding and executable models? Then we should look at the notation itself, simplifying the notation to better support the anticipated usage patterns. This should include how the notation elements are assembled into diagrams and views, and how view schemas are defined to support stakeholder viewpoints. All this is focused on an outside-in, or demand-side view of modeling - what we want to provide to the users. Then we can think about the simplest and best approaches to defining the metamodel to support capturing, extending, exchanging and integrating the information needed to support stakeholder concerns. I'm not suggesting we serialize these activities. The AE-SIG should be capturing ideas like those Pete outlines below, and trying them on candidate metamodel content that is existing and well understood. But we shouldn't get too far ahead of ourselves and think that all UML simplification is from the metamodel up. Another thing I think we should consider: are we trying to over-constrain UML? The greatest value from modeling tends to come from the informal models that allow people to effectively understand, communicate, and act on information. By tightening up redefinitions, subsets, derived unions, multiplicities, generalization, OCL constraints, etc., we are making the modeling more formal and constrained - possibly making it harder to use for more informal, collaborative information capture and communication. We're treating UML as more of a formal language targeted at code generation or execution environments. This may be focusing 90% of the effort on 20% of the community requirements, and may actually limit the appeal of modeling for the larger community. Just something to think about... Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Ed Seidewitz" To: "Pete Rivett - Adaptive" Cc: Date: 01/07/2010 09:00 PM Subject: RE: more metamodel issues -------------------------------------------------------------------------------- Pete . Well, as far as what Nerijus was proposing under âmore metamodel issuesâ, he justified it by implementation concerns that I found neither compelling nor warranted. That is not to say there may not be other reasons for what he proposes, along the lines of what you are saying. We certainly all know that the UML metamodel could be done better, just as a matter of modeling style. However, I have to agree with your final comment that this is not something that we can tackle as part of the 2.4 RTF. Besides the inevitable discussions it will generate as to whether this is doable by an RTF at all, it is certainly outside the scope and timebox we are trying to establish for this particular RTF. We could probably spend the whole rest of the planned schedule for this RTF just debating (though probably a very profitable debate!) the best patterns to use, how to use them, etc. I also agree with you that the spec simplification submission would be a good time to handle this sort of thing. Unfortunately, as it turned out, the RFP pretty much precludes doing this: except for a few explicit things, the metamodel resulting from the spec simplification is supposed to be the same as the current merged L3 metamodel . down to all the subsetting, redefinition, etc. The RFP is for spec simplification, not metamodel simplification. This may be less than some of us would like to do, but there are also some good reasons on the other side for not doing more. I think the RFP is a good compromise to at least let us finally get a spec document we can live with for a while! -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, January 07, 2010 8:27 PM To: Salman Qadri; Steve Cook; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues The question to me is not whether it can be made to work but whether we need, or even benefit from such complexity: even the âeasy caseâ is pretty non-intuitive and the benefits unclear. IMHO we have far too many different options . through redefinition (with or without renaming), subbsetting (with or without unions), unions, readOnly, derivation . all at the Property (as opposed to the Associaation) level. Not to mention Property ownership (as incorrectly depicted through navigation arrows) which seems to have been based on a superseded MOF âcomposite closureâ rule. And different contributors to the UML metamodel have, in a seemingly random manner (according to their personal understanding, preferences and interests) chosen different combinations for different parts of the metamodel. As a result we cannot readily answer challenges such as from Nerijus as to why something is modeled a certain way, let alone whether it makes sense and whether it can be implemented. If we need an academic paper (as referenced by Salman) to explain the latter then thatâs a good indication that weâre in trouble. For example, why do we have Package::/ownedType but not Package::/ownedDependency (or a similar query for other subtypes of PackagedElement)? Another comprehensibility problem we have is the use of one construct . {subsets} for 3 distinct purposes (1) as part off a derived union, 2) to define a âqueryâ such as ownedType and 3) as a genuine constraint): moreover itâs not possible to discern which purpose/semantics without going to a separate diagram (usually) to check whether the property being subsetted is derived/union. We also have other issues, discussed in other threads, such as whether/when it makes sense to have {ordered} on a derived union and to have derived properties updateable. It seems to me there is a small number (2 or 3) of patterns for association generalization that will cover most of our real metamodeling needs. We should document what these are and the criteria for when they should apply . and then apply that logic to the metamodel, while striving for forward compatibility at the XMI level (if necessary by documenting exceptions to the patterns). In fact I think the impact on the XMI will be minimal since most of these properties are not even serialized (e.g. derived properties and âownerâ properties). As part of this we should consider including explicit association generalizations in the metamodel diagrams to provide a clearer, higher-level and graphical depiction of whatâs happening. Though I accept this could make diagrams a bit more messy in terms of lines so we should test this out on a few. And we should clear up the fudge that has the semantics of association generalization as a semantic variation point (strictly speaking we only need to do this for MOF). For example, off the top of my head, here are some candidate requirements with patterns: note that this is a starter for discussion not fully-thought through a) Provide a generic/more abstract way of accessing relationships (e.g. ownership), or specifying their semantics in one place: use association generalization with an abstract association (and derived unions and subsets at the association end level) which also allows different names to be used for ends b) Apply specific constraints to a relationship: use association generalization with additional OCL on the subsetting association ends. c) Unify multiple inherited owner properties (e.g. as in StructuredActivityNode::activity which has disadvantage of hiding the inherited properties for navigation purposes): use association generalization with XOR (see below) to create what is in effect a âderived intersectionâ. The following to me are non-requirements for representation using metamodel constructs: · Use of subsetting to constrain 2 non-derived properties · Use of subsetting for type-based âqueriesâ (if really needed a property such as ownedType can be defined as a derived property with an OCL query) · Use of redefinition to change multiplicity (this could be achieved through OCL as per recent discussion on this thread): this includes making a property mandatory or single-valued. · Use of redefinition to change property ordering · Use of redefinition to hide a property inherited from a superclass (this could be achieved by OCL to state the property must be empty) · Use of redefinition to change the default value of a property (I donât think the metamodel uses this) Note that the use of OCL in the above does not require tools to implement OCL . the OCL is for specification ppurposes. Tools could implement this using code (which is what Nerijus says is needed anyway). I donât think itâs justified to expect implementers to support the full combination of the capabilities listed in my first paragraph just for 3 or so uses in the UML metamodel. Note that the above proposal is for use in the UML metamodel itself: these capabilities would still be available to UML modelers in general. And would mean that redefinition is not used at all. One requirement we have no serious means to address (due to underspecification of XOR . and hence presumably its laack of use in the UML metamodel itself) is the one Nerijus raised about restricting a metaclass to have only one composite owner. We should specify XOR and make use of it. We should in the process try to avoid patterns such as in Fig 7.5 where ValueSpecification has separate non-derived properties for owningUpper and owningLower. This is also requirement c) above. It seems to me that this all should be addressed by the Simplification RFP response rather than the current RTF. Pete Regards Pete From: Salman Qadri [mailto:Salman.Qadri@mathworks.com] Sent: 07 January 2010 13:07 To: Steve Cook; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues I do not feel category 3 is a bug. It is a valid use-case and if all the subsetted relationships between the ends of the associations are valid, then it should all work out if subsetted and redefined properties is implemented correctly: 1) Package-ownedType subsets Package-packagedElement (non-derived and the slot). So an append operation of a type T to the ownedType role of a Package P would place T in the packagedElement role of P. The opposite of Package-ownedType is Type-package, which is non-derived so the package role on T is set to the P. This was an easy case; now letâs look at a more complicated case. 2) Activity-structuredNode is derived and subsets Activity-node (non-derived), and has the opposite StructuredActivityNode-activity (non-derived) which redefines ActivityNode-activity (non-derived). ActivityNode-activity and Activity-node are opposites of each other. In MOF terms, Activity-node and ActivityNode-activity would be the slots, and so any actions on Activity-structuredNode would affect Activity-node, which should âautomaticallyâ update its opposite ActivityNode-activity, which means that StructuredActivityNode-activity should have the correct value since it redefines ActivityNode-activity. If you choose to make StructuredActivityNode-activity the slot as opposed to ActivityNode-activity, it still works out. If youâd like a much more thorough explanation of how all this can work at the MOF Instance Specification level, in terms of Links etc., I can present that as well. So, I donât think category 3 is a bug. Weâve had discussions about association ends in the past under the topic of subsetting/redefinition implies specialization, and we looked at one possible implementation, which is the Milicev model: On the Semantics of Associations and Association Ends in UML Milicev, D.; Software Engineering, IEEE Transactions on Volume 33, Issue 4, April 2007 Page(s):238 - 251 http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326 Salman From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 1:18 PM To: Bran Selic; Ed Seidewitz Cc: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues âContorting the metamodelâ is a wild exaggeration in regard to Nerijusâs suggestions. The metamodel is horribly contorted as it is: the current modeling of associations and their ends is a perfect example of it. Making UML simpler to implement cannot be anything but a good thing from an adoption and user perspective. Surely we can at least agree that Nerijusâs category 3 is a bug? From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 07 January 2010 18:02 To: Ed Seidewitz Cc: Steve Cook; Nerijus Jankevicius; uml2-rtf@omg.org Subject: Re: more metamodel issues I fully agree with Ed on this (for a change ). Java or XMI implementation concerns should not force us into contorting the metamodel. Bran On Thu, Jan 7, 2010 at 12:53 PM, Ed Seidewitz wrote: Well, no, I donât think this is fair enough. I donât think Java implementation issues should drive us to not use what otherwise are valid modeling constructs, especially when there are reasonable work arounds. There is no requirements that that the UML metamodel be implemented internally using Java classes that have any specific mapping from UML classes. For example, the internal representation could be in a generic document-oriented structure with self-describing metadata, rather than instantiated as Java object with metamodel-specific classes. And, even if you want to use specific Java classes, there is no requirement that the fields in those classes have identical multiplicities as in the metamodel. For instance, every Java instance variable could be a collection, and all multiplicities enforced by appropriate programmatic constraints. (After all, unless you use Java arrays, you canât enforce multiplicities like 1..2 in the collection data structure anyway.) So, I donât think any of the issues described in Nerijus additional list of issues below are âshowstoppersâ, nor do I think they have XMI impacts. And I think changing them would arguably lead to poorer, not better, modeling constructions (though, I admit, this is arguable either way). So I donât think these should be addressed by this RTF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 12:19 PM To: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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ürgen, 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! Subject: RE: more metamodel issues Date: Fri, 8 Jan 2010 10:17:01 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: more metamodel issues Thread-Index: AcqQZlTQihu9nFunTReqOf5P1X/A2QAJtAfA From: "Pete Rivett" To: "Jim Amsden" , Jim I disagree: I think the changes I outlined are appropriate for the UML 2.5 simplification: they directly support its stated evaluation criterion: Submissions will be evaluated on consumability: completeness, consistency, well formatted, understandable, etc. Submissions should be well understood by the people who participated in developing them or the OMG reviewers, as well as a wide range of consumers of the specification. The recent thread and the resorting to the .Milicev model. paper strongly indicate that some action is needed in this area to meet this criterion . not only for consumability but also consistency and providing a basis for going forward when fixing further issues. And I believe that this can be achieved with little, if any, change to the interchange XMI. Maybe we should .try it out for size. and see what the impact really is . bboth positive and negative. Pete From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: 08 January 2010 05:26 To: uml2-rtf@omg.org Subject: RE: more metamodel issues We're starting to identify the issues and techniques that we will want to apply to the simplification of UML itself, what we intended to happen after 2.5. 2.4 is intended to address show-stopper issues - issues that prevent the creation of valid UML models, or the proper XMI exchange of those models. 2.5 is intended to cleanup and simplify the specification itself and effectively describe the 2.4 metamodel. Together, these provide a foundation of a usable, implementable, and exchangeable UML. Hopefully this will provide a solid starting point to discuss and implement significant changes to UML in order to improve its value proposition. Simplification of UML itself should start with what we are trying to accomplish with the language. Is it capturing and communicating actionable information about complex systems. Is it model driven development? Is it visual coding and executable models? Then we should look at the notation itself, simplifying the notation to better support the anticipated usage patterns. This should include how the notation elements are assembled into diagrams and views, and how view schemas are defined to support stakeholder viewpoints. All this is focused on an outside-in, or demand-side view of modeling - what we want to provide to the users. Then we can think about the simplest and best approaches to defining the metamodel to support capturing, extending, exchanging and integrating the information needed to support stakeholder concerns. I'm not suggesting we serialize these activities. The AE-SIG should be capturing ideas like those Pete outlines below, and trying them on candidate metamodel content that is existing and well understood. But we shouldn't get too far ahead of ourselves and think that all UML simplification is from the metamodel up. Another thing I think we should consider: are we trying to over-constrain UML? The greatest value from modeling tends to come from the informal models that allow people to effectively understand, communicate, and act on information. By tightening up redefinitions, subsets, derived unions, multiplicities, generalization, OCL constraints, etc., we are making the modeling more formal and constrained - possibly making it harder to use for more informal, collaborative information capture and communication. We're treating UML as more of a formal language targeted at code generation or execution environments. This may be focusing 90% of the effort on 20% of the community requirements, and may actually limit the appeal of modeling for the larger community. Just something to think about... Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "Ed Seidewitz" To: "Pete Rivett - Adaptive" Cc: Date: 01/07/2010 09:00 PM Subject: RE: more metamodel issues -------------------------------------------------------------------------------- Pete . Well, as far as what Nerijus was proposing under .more metamodel issues., he justified it by implementation concerns that I found neither compelling nor warranted. That is not to say there may not be other reasons for what he proposes, along the lines of what you are saying. We certainly all know that the UML metamodel could be done better, just as a matter of modeling style. However, I have to agree with your final comment that this is not something that we can tackle as part of the 2.4 RTF. Besides the inevitable discussions it will generate as to whether this is doable by an RTF at all, it is certainly outside the scope and timebox we are trying to establish for this particular RTF. We could probably spend the whole rest of the planned schedule for this RTF just debating (though probably a very profitable debate!) the best patterns to use, how to use them, etc. I also agree with you that the spec simplification submission would be a good time to handle this sort of thing. Unfortunately, as it turned out, the RFP pretty much precludes doing this: except for a few explicit things, the metamodel resulting from the spec simplification is supposed to be the same as the current merged L3 metamodel . down to all the subssetting, redefinition, etc. The RFP is for spec simplification, not metamodel simplification. This may be less than some of us would like to do, but there are also some good reasons on the other side for not doing more. I think the RFP is a good compromise to at least let us finally get a spec document we can live with for a while! -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, January 07, 2010 8:27 PM To: Salman Qadri; Steve Cook; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues The question to me is not whether it can be made to work but whether we need, or even benefit from such complexity: even the .easy case. is pretty non-intuitive and the benefits unclear. IMHO we have far too many different options . through redefinition (with or without renaming), suubsetting (with or without unions), unions, readOnly, derivation . all at the Property (as opposed to the Assocciation) level. Not to mention Property ownership (as incorrectly depicted through navigation arrows) which seems to have been based on a superseded MOF .composite closure. rule. And different contributors to the UML metamodel have, in a seemingly random manner (according to their personal understanding, preferences and interests) chosen different combinations for different parts of the metamodel. As a result we cannot readily answer challenges such as from Nerijus as to why something is modeled a certain way, let alone whether it makes sense and whether it can be implemented. If we need an academic paper (as referenced by Salman) to explain the latter then that.s a good indication that we.re in trouble. For example, why do we have Package::/ownedType but not Package::/ownedDependency (or a similar query for other subtypes of PackagedElement)? Another comprehensibility problem we have is the use of one construct . {subsets} for 3 distinct ppurposes (1) as part of a derived union, 2) to define a .query. such as ownedType and 3) as a genuine constraint): moreover it.s not possible to discern which purpose/semantics without going to a separate diagram (usually) to check whether the property being subsetted is derived/union. We also have other issues, discussed in other threads, such as whether/when it makes sense to have {ordered} on a derived union and to have derived properties updateable. It seems to me there is a small number (2 or 3) of patterns for association generalization that will cover most of our real metamodeling needs. We should document what these are and the criteria for when they should apply . and then apply that logiic to the metamodel, while striving for forward compatibility at the XMI level (if necessary by documenting exceptions to the patterns). In fact I think the impact on the XMI will be minimal since most of these properties are not even serialized (e.g. derived properties and .owner. properties). As part of this we should consider including explicit association generalizations in the metamodel diagrams to provide a clearer, higher-level and graphical depiction of what.s happening. Though I accept this could make diagrams a bit more messy in terms of lines so we should test this out on a few. And we should clear up the fudge that has the semantics of association generalization as a semantic variation point (strictly speaking we only need to do this for MOF). For example, off the top of my head, here are some candidate requirements with patterns: note that this is a starter for discussion not fully-thought through a) Provide a generic/more abstract way of accessing relationships (e.g. ownership), or specifying their semantics in one place: use association generalization with an abstract association (and derived unions and subsets at the association end level) which also allows different names to be used for ends b) Apply specific constraints to a relationship: use association generalization with additional OCL on the subsetting association ends. c) Unify multiple inherited owner properties (e.g. as in StructuredActivityNode::activity which has disadvantage of hiding the inherited properties for navigation purposes): use association generalization with XOR (see below) to create what is in effect a .derived intersection.. The following to me are non-requirements for representation using metamodel constructs: · Use of subsetting to constrain 2 non-derived properties · Use of subsetting for type-based .queries. (if really needed a property such as ownedType can be defined as a derived property with an OCL query) · Use of redefinition to change multiplicity (this could be achieved through OCL as per recent discussion on this thread): this includes making a property mandatory or single-valued. · Use of redefinition to change property ordering · Use of redefinition to hide a property inherited from a superclass (this could be achieved by OCL to state the property must be empty) · Use of redefinition to change the default value of a property (I don.t think the metamodel uses this) Note that the use of OCL in the above does not require tools to implement OCL . the OCL is for specification ppurposes. Tools could implement this using code (which is what Nerijus says is needed anyway). I don.t think it.s justified to expect implementers to support the full combination of the capabilities listed in my first paragraph just for 3 or so uses in the UML metamodel. Note that the above proposal is for use in the UML metamodel itself: these capabilities would still be available to UML modelers in general. And would mean that redefinition is not used at all. One requirement we have no serious means to address (due to underspecification of XOR . and hence presumably its lack of use in thee UML metamodel itself) is the one Nerijus raised about restricting a metaclass to have only one composite owner. We should specify XOR and make use of it. We should in the process try to avoid patterns such as in Fig 7.5 where ValueSpecification has separate non-derived properties for owningUpper and owningLower. This is also requirement c) above. It seems to me that this all should be addressed by the Simplification RFP response rather than the current RTF. Pete Regards Pete From: Salman Qadri [mailto:Salman.Qadri@mathworks.com] Sent: 07 January 2010 13:07 To: Steve Cook; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues I do not feel category 3 is a bug. It is a valid use-case and if all the subsetted relationships between the ends of the associations are valid, then it should all work out if subsetted and redefined properties is implemented correctly: 1) Package-ownedType subsets Package-packagedElement (non-derived and the slot). So an append operation of a type T to the ownedType role of a Package P would place T in the packagedElement role of P. The opposite of Package-ownedType is Type-package, which is non-derived so the package role on T is set to the P. This was an easy case; now let.s look at a more complicated case. 2) Activity-structuredNode is derived and subsets Activity-node (non-derived), and has the opposite StructuredActivityNode-activity (non-derived) which redefines ActivityNode-activity (non-derived). ActivityNode-activity and Activity-node are opposites of each other. In MOF terms, Activity-node and ActivityNode-activity would be the slots, and so any actions on Activity-structuredNode would affect Activity-node, which should .automatically. update its opposite ActivityNode-activity, which means that StructuredActivityNode-activity should have the correct value since it redefines ActivityNode-activity. If you choose to make StructuredActivityNode-activity the slot as opposed to ActivityNode-activity, it still works out. If you.d like a much more thorough explanation of how all this can work at the MOF Instance Specification level, in terms of Links etc., I can present that as well. So, I don.t think category 3 is a bug. We.ve had discussions about association ends in the past under the topic of subsetting/redefinition implies specialization, and we looked at one possible implementation, which is the Milicev model: On the Semantics of Associations and Association Ends in UML Milicev, D.; Software Engineering, IEEE Transactions on Volume 33, Issue 4, April 2007 Page(s):238 - 251 http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326 Salman From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 1:18 PM To: Bran Selic; Ed Seidewitz Cc: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues .Contorting the metamodel. is a wild exaggeration in regard to Nerijus.s suggestions. The metamodel is horribly contorted as it is: the current modeling of associations and their ends is a perfect example of it. Making UML simpler to implement cannot be anything but a good thing from an adoption and user perspective. Surely we can at least agree that Nerijus.s category 3 is a bug? From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 07 January 2010 18:02 To: Ed Seidewitz Cc: Steve Cook; Nerijus Jankevicius; uml2-rtf@omg.org Subject: Re: more metamodel issues I fully agree with Ed on this (for a change ). Java or XMI implementation concerns should not force us into contorting the metamodel. Bran On Thu, Jan 7, 2010 at 12:53 PM, Ed Seidewitz wrote: Well, no, I don.t think this is fair enough. I don.t think Java implementation issues should drive us to not use what otherwise are valid modeling constructs, especially when there are reasonable work arounds. There is no requirements that that the UML metamodel be implemented internally using Java classes that have any specific mapping from UML classes. For example, the internal representation could be in a generic document-oriented structure with self-describing metadata, rather than instantiated as Java object with metamodel-specific classes. And, even if you want to use specific Java classes, there is no requirement that the fields in those classes have identical multiplicities as in the metamodel. For instance, every Java instance variable could be a collection, and all multiplicities enforced by appropriate programmatic constraints. (After all, unless you use Java arrays, you can.t enforce multiplicities like 1..2 in the collection data structure anyway.) So, I don.t think any of the issues described in Nerijus additional list of issues below are .showstoppers., nor do I think they have XMI impacts. And I think changing them would arguably lead to poorer, not better, modeling constructions (though, I admit, this is arguable either way). So I don.t think these should be addressed by this RTF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 12:19 PM To: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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! Subject: RE: more metamodel issues Date: Fri, 8 Jan 2010 10:32:32 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: more metamodel issues Thread-Index: AQHKj60Dpic3tfF8EkODQ0jXRBrDYpGKTmHAgAAIwnyAAAKegIAACY2QgAAEPICAAAJy8IAADdbQgAET9DCAAHPr8A== From: "Pete Rivett" To: "Steve Cook" , "Salman Qadri" , "Bran Selic" , "Ed Seidewitz" , "Nerijus Jankevicius" Cc: I think there is a significant misunderstanding of the .current XMI rules.: a) XMI says nothing whatsoever about resources: the only spec that does is MOF Facility and even there resources (actually called Stores) are still independent of XMI partitioning b) MOF 1.x did indeed have a .Composite Closure Rule. which stated that composite children must be in the same Extent as their composite parent. That rule was dispensed with at MOF 2 (which incidentally removed the tie between Extent and resource . an element can be in multiple Extents for example. Only the Facility spec addresses resources/storage as per a) above). If there are any words in the XMI 2.1 spec that imply otherwise then that is what should be fixed: please supply a quote/reference. Regards Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 January 2010 03:50 To: Salman Qadri; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues Salman I understand. Nevertheless, if you made Type::package or StructuredActivityNode::activity derived, you would lose nothing from a user.s point of view, and you would make it easier to implement. So I don.t think your argument is compelling. However, there is a case in the spec which I think does justify having one end derived and the other non-derived. It was introduced as the resolution to issue 10536, and is the property ConnectableElement::end. Here, end is marked as derived from its opposite ConnectorEnd::role. The sole purpose of this is to inhibit generation of XMI references for ConnectableElement::end, so as to avoid unwanted dependencies between XMI resources. Although this is exactly the kind of implementation consideration that some people seem to want to avoid putting in the spec, to me this is a compelling argument for allowing this pattern, given the current XMI rules. So I withdraw my .Surely we can at least agree that Nerijus.s category 3 is a bug?. . because I don.t agree. - Steve - PS (to Ed) incidentally my .fair enough. below was a confession of my ignorance about Java 1.5, not my agreement to accept category 2. From: Salman Qadri [mailto:Salman.Qadri@mathworks.com] Sent: 07 January 2010 21:07 To: Steve Cook; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues I do not feel category 3 is a bug. It is a valid use-case and if all the subsetted relationships between the ends of the associations are valid, then it should all work out if subsetted and redefined properties is implemented correctly: 1) Package-ownedType subsets Package-packagedElement (non-derived and the slot). So an append operation of a type T to the ownedType role of a Package P would place T in the packagedElement role of P. The opposite of Package-ownedType is Type-package, which is non-derived so the package role on T is set to the P. This was an easy case; now let.s look at a more complicated case. 2) Activity-structuredNode is derived and subsets Activity-node (non-derived), and has the opposite StructuredActivityNode-activity (non-derived) which redefines ActivityNode-activity (non-derived). ActivityNode-activity and Activity-node are opposites of each other. In MOF terms, Activity-node and ActivityNode-activity would be the slots, and so any actions on Activity-structuredNode would affect Activity-node, which should .automatically. update its opposite ActivityNode-activity, which means that StructuredActivityNode-activity should have the correct value since it redefines ActivityNode-activity. If you choose to make StructuredActivityNode-activity the slot as opposed to ActivityNode-activity, it still works out. If you.d like a much more thorough explanation of how all this can work at the MOF Instance Specification level, in terms of Links etc., I can present that as well. So, I don.t think category 3 is a bug. We.ve had discussions about association ends in the past under the topic of subsetting/redefinition implies specialization, and we looked at one possible implementation, which is the Milicev model: On the Semantics of Associations and Association Ends in UML Milicev, D.; Software Engineering, IEEE Transactions on Volume 33, Issue 4, April 2007 Page(s):238 - 251 http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326 Salman From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 1:18 PM To: Bran Selic; Ed Seidewitz Cc: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues .Contorting the metamodel. is a wild exaggeration in regard to Nerijus.s suggestions. The metamodel is horribly contorted as it is: the current modeling of associations and their ends is a perfect example of it. Making UML simpler to implement cannot be anything but a good thing from an adoption and user perspective. Surely we can at least agree that Nerijus.s category 3 is a bug? From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 07 January 2010 18:02 To: Ed Seidewitz Cc: Steve Cook; Nerijus Jankevicius; uml2-rtf@omg.org Subject: Re: more metamodel issues I fully agree with Ed on this (for a change ). Java or XMI implementation concerns should not force us into contorting the metamodel. Bran On Thu, Jan 7, 2010 at 12:53 PM, Ed Seidewitz wrote: Well, no, I don.t think this is fair enough. I don.t think Java implementation issues should drive us to not use what otherwise are valid modeling constructs, especially when there are reasonable work arounds. There is no requirements that that the UML metamodel be implemented internally using Java classes that have any specific mapping from UML classes. For example, the internal representation could be in a generic document-oriented structure with self-describing metadata, rather than instantiated as Java object with metamodel-specific classes. And, even if you want to use specific Java classes, there is no requirement that the fields in those classes have identical multiplicities as in the metamodel. For instance, every Java instance variable could be a collection, and all multiplicities enforced by appropriate programmatic constraints. (After all, unless you use Java arrays, you can.t enforce multiplicities like 1..2 in the collection data structure anyway.) So, I don.t think any of the issues described in Nerijus additional list of issues below are .showstoppers., nor do I think they have XMI impacts. And I think changing them would arguably lead to poorer, not better, modeling constructions (though, I admit, this is arguable either way). So I don.t think these should be addressed by this RTF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 12:19 PM To: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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! From: Steve Cook To: Pete Rivett , Salman Qadri , Bran Selic , Ed Seidewitz , Nerijus Jankevicius CC: "uml2-rtf@omg.org" Subject: RE: more metamodel issues Thread-Topic: more metamodel issues Thread-Index: AQHKj60Dpic3tfF8EkODQ0jXRBrDYpGKTmHAgAAIwnyAAAKegIAACY2QgAAEPICAAAJy8IAADdbQgAET9DCAAHPr8IAAB6BQ Date: Fri, 8 Jan 2010 18:54:57 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Pete I am simply repeating the justification for issue 10536, which was resolved in the way described, and which has the term .resource. in its description. I don.t believe there is a significant misunderstanding. Issue 10536: A_end_role should not be bidirectional (uml2-rtf) Click here for this issue's archive. Source: Embarcadero Technologies (Mr. Kenneth Hussey, kenn.hussey@embarcadero.com) Nature: Uncategorized Issue Severity: Summary: The A_end_role association between ConnectableElement and ConnectorEnd should not be bidirectional - it's unreasonable to expect that a connectable element be changed in order to connect it to another connectable element, considering that the connectable element(s) could be in a different model from the connector. There should perhaps be a separate, derived ConnectableElement::end property instead Resolution: Revised Text: Superstructure (formal/2007-11-02) Page 163: Figure 9.3 - Connectors, the .end. association end should have ./. in front to indicate derived. Page 174: Replace: end: ConnectorEnd Denotes a connector that attaches to this connectable element. With: /end: ConnectorEnd Denotes a connector that attaches to this connectable element. Derived in the following way: context ConnectableElement::end derive : ConnectorEnd.allInstances()-> select(e | e.role=self) Actions taken: December 21, 2006: received issue Discussion: ConnectableElement and ConnectorEnd are related via a bi-directional association: (ConnectableElement::end . ConnectorEnd::role). The ends of the association are concrete (non-derived). This means setting one end of such association also sets the opposite end. This poses no problem if both ends of the association are co-located in the same resource. However, in the context of structure inheritance, more specifically when the structure of a classifier is inherited by a specializing classifier, it can happen that a new connector is added to the specialized classifier, whose one or both connector ends point to roles from the general classifier. Furthermore, if the specialization occurs in resource B that is different (common case) than resource A with the general classifier, this can lead to resource A changing unnecessarily due to adding the connector. Two possible solutions to this problem: 1) redefine the roles of the general classifier that are connected to/from by a connector in the specialized classifier 2) make the ConnectableElement:end collection derived (and non-ordered). Solution 1 has efficiency implications (memory cost of the redefinition). As such, solution 2 seems like a more favorable alternative and the derivation can easily be specified in OCL. From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: 08 January 2010 18:33 To: Steve Cook; Salman Qadri; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues I think there is a significant misunderstanding of the .current XMI rules.: a) XMI says nothing whatsoever about resources: the only spec that does is MOF Facility and even there resources (actually called Stores) are still independent of XMI partitioning b) MOF 1.x did indeed have a .Composite Closure Rule. which stated that composite children must be in the same Extent as their composite parent. That rule was dispensed with at MOF 2 (which incidentally removed the tie between Extent and resource . an element can be in multiple Extents for example. Only the Facility spec addresses resources/storage as per a) above). If there are any words in the XMI 2.1 spec that imply otherwise then that is what should be fixed: please supply a quote/reference. Regards Pete From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 08 January 2010 03:50 To: Salman Qadri; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues Salman I understand. Nevertheless, if you made Type::package or StructuredActivityNode::activity derived, you would lose nothing from a user.s point of view, and you would make it easier to implement. So I don.t think your argument is compelling. However, there is a case in the spec which I think does justify having one end derived and the other non-derived. It was introduced as the resolution to issue 10536, and is the property ConnectableElement::end. Here, end is marked as derived from its opposite ConnectorEnd::role. The sole purpose of this is to inhibit generation of XMI references for ConnectableElement::end, so as to avoid unwanted dependencies between XMI resources. Although this is exactly the kind of implementation consideration that some people seem to want to avoid putting in the spec, to me this is a compelling argument for allowing this pattern, given the current XMI rules. So I withdraw my .Surely we can at least agree that Nerijus.s category 3 is a bug?. . because I don.t agree. - Steve - PS (to Ed) incidentally my .fair enough. below was a confession of my ignorance about Java 1.5, not my agreement to accept category 2. From: Salman Qadri [mailto:Salman.Qadri@mathworks.com] Sent: 07 January 2010 21:07 To: Steve Cook; Bran Selic; Ed Seidewitz; Nerijus Jankevicius Cc: uml2-rtf@omg.org Subject: RE: more metamodel issues I do not feel category 3 is a bug. It is a valid use-case and if all the subsetted relationships between the ends of the associations are valid, then it should all work out if subsetted and redefined properties is implemented correctly: 1) Package-ownedType subsets Package-packagedElement (non-derived and the slot). So an append operation of a type T to the ownedType role of a Package P would place T in the packagedElement role of P. The opposite of Package-ownedType is Type-package, which is non-derived so the package role on T is set to the P. This was an easy case; now let.s look at a more complicated case. 2) Activity-structuredNode is derived and subsets Activity-node (non-derived), and has the opposite StructuredActivityNode-activity (non-derived) which redefines ActivityNode-activity (non-derived). ActivityNode-activity and Activity-node are opposites of each other. In MOF terms, Activity-node and ActivityNode-activity would be the slots, and so any actions on Activity-structuredNode would affect Activity-node, which should .automatically. update its opposite ActivityNode-activity, which means that StructuredActivityNode-activity should have the correct value since it redefines ActivityNode-activity. If you choose to make StructuredActivityNode-activity the slot as opposed to ActivityNode-activity, it still works out. If you.d like a much more thorough explanation of how all this can work at the MOF Instance Specification level, in terms of Links etc., I can present that as well. So, I don.t think category 3 is a bug. We.ve had discussions about association ends in the past under the topic of subsetting/redefinition implies specialization, and we looked at one possible implementation, which is the Milicev model: On the Semantics of Associations and Association Ends in UML Milicev, D.; Software Engineering, IEEE Transactions on Volume 33, Issue 4, April 2007 Page(s):238 - 251 http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4123326 Salman From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 1:18 PM To: Bran Selic; Ed Seidewitz Cc: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues .Contorting the metamodel. is a wild exaggeration in regard to Nerijus.s suggestions. The metamodel is horribly contorted as it is: the current modeling of associations and their ends is a perfect example of it. Making UML simpler to implement cannot be anything but a good thing from an adoption and user perspective. Surely we can at least agree that Nerijus.s category 3 is a bug? From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: 07 January 2010 18:02 To: Ed Seidewitz Cc: Steve Cook; Nerijus Jankevicius; uml2-rtf@omg.org Subject: Re: more metamodel issues I fully agree with Ed on this (for a change ). Java or XMI implementation concerns should not force us into contorting the metamodel. Bran On Thu, Jan 7, 2010 at 12:53 PM, Ed Seidewitz wrote: Well, no, I don.t think this is fair enough. I don.t think Java implementation issues should drive us to not use what otherwise are valid modeling constructs, especially when there are reasonable work arounds. There is no requirements that that the UML metamodel be implemented internally using Java classes that have any specific mapping from UML classes. For example, the internal representation could be in a generic document-oriented structure with self-describing metadata, rather than instantiated as Java object with metamodel-specific classes. And, even if you want to use specific Java classes, there is no requirement that the fields in those classes have identical multiplicities as in the metamodel. For instance, every Java instance variable could be a collection, and all multiplicities enforced by appropriate programmatic constraints. (After all, unless you use Java arrays, you can.t enforce multiplicities like 1..2 in the collection data structure anyway.) So, I don.t think any of the issues described in Nerijus additional list of issues below are .showstoppers., nor do I think they have XMI impacts. And I think changing them would arguably lead to poorer, not better, modeling constructions (though, I admit, this is arguable either way). So I don.t think these should be addressed by this RTF. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, January 07, 2010 12:19 PM To: Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: more metamodel issues Fair enough. What solution do you propose for (2)? Deleting the association and adding a constraint that the collection size <= 1? Also > What is your proposed metamodel modification for (say) Association::memberEnd? From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: 07 January 2010 17:01 To: Steve Cook; uml2-rtf@omg.org Subject: Re: more metamodel issues Java 1.5 allows type narrowing (overrided operation return type) and we have no problems with that, but can't solve multiplicity narrowing. >>(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. ----- Original Message ----- From: Steve Cook To: Nerijus Jankevicius ; uml2-rtf@omg.org Cc: issues@omg.org ; juergen@omg.org Sent: Thursday, January 07, 2010 6:41 PM Subject: RE: more metamodel issues 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!