Issue 15449: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations (uml2-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association. Two group of proposed changes were removed from 14977. The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274 Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf The second group involves associations that are under-specified in the sense that each association: - does not own any end (i.e., both ends are navigable according to 7.3.45) - none of the ends subset/redefine ends of another association that has semantic directionality The criteria for an association to have semantic directionality is: a) one end is navigable; the other isn't b) one end is composite; the other isn't c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0) e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0) Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any. In UML2.4, there are 9 associations that fail all of (a) through (e): [qvto:transformation] A_containedEdge_inGroup [qvto:transformation] A_containedNode_inGroup [qvto:transformation] A_covered_coveredBy [qvto:transformation] A_edge_inPartition [qvto:transformation] A_generalizationSet_generalization [qvto:transformation] A_inInterruptibleRegion_node [qvto:transformation] A_inPartition_node [qvto:transformation] A_predecessorClause_successorClause [qvto:transformation] A_subject_useCase 19 associations satisfy (a), (b), (c) but fail either (d) and (e): [qvto:transformation] A_before_toAfter [qvto:transformation] A_classifier_templateParameter_parameteredElement [qvto:transformation] A_connectableElement_templateParameter_parameteredElement [qvto:transformation] A_end_role [qvto:transformation] A_extension_metaclass [qvto:transformation] A_incoming_target_node [qvto:transformation] A_incoming_target_vertex [qvto:transformation] A_inputElement_regionAsInput [qvto:transformation] A_interruptingEdge_interrupts [qvto:transformation] A_method_specification [qvto:transformation] A_operation_templateParameter_parameteredElement [qvto:transformation] A_outgoing_source_node [qvto:transformation] A_outgoing_source_vertex [qvto:transformation] A_outputElement_regionAsOutput [qvto:transformation] A_parameterSet_parameter [qvto:transformation] A_parameteredElement_templateParameter [qvto:transformation] A_powertypeExtent_powertype [qvto:transformation] A_submachineState_submachine [qvto:transformation] A_toBefore_after All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association). The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end -- i.e., the association is semantically directed in that one end can be logically derived from the other end. Resolution: Revised Text: Actions taken: September 8, 2010: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (316A)" To: "issues@omg.org" CC: "uml2-rtf@omg.org" Date: Wed, 8 Sep 2010 12:54:00 -0700 Subject: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Topic: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Index: ActPj5VITzBJbewdRMaa3nDRm6JegQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association. Two group of proposed changes were removed from 14977. The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274 Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf The second group involves associations that are under-specified in the sense that each association: - does not own any end (i.e., both ends are navigable according to 7.3.45) - none of the ends subset/redefine ends of another association that has semantic directionality The criteria for an association to have semantic directionality is: a) one end is navigable; the other isn't b) one end is composite; the other isn't c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0) e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0) Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any. In UML2.4, there are 9 associations that fail all of (a) through (e): [qvto:transformation] A_containedEdge_inGroup [qvto:transformation] A_containedNode_inGroup [qvto:transformation] A_covered_coveredBy [qvto:transformation] A_edge_inPartition [qvto:transformation] A_generalizationSet_generalization [qvto:transformation] A_inInterruptibleRegion_node [qvto:transformation] A_inPartition_node [qvto:transformation] A_predecessorClause_successorClause [qvto:transformation] A_subject_useCase 19 associations satisfy (a), (b), (c) but fail either (d) and (e): [qvto:transformation] A_before_toAfter [qvto:transformation] A_classifier_templateParameter_parameteredElement [qvto:transformation] A_connectableElement_templateParameter_parameteredElement [qvto:transformation] A_end_role [qvto:transformation] A_extension_metaclass [qvto:transformation] A_incoming_target_node [qvto:transformation] A_incoming_target_vertex [qvto:transformation] A_inputElement_regionAsInput [qvto:transformation] A_interruptingEdge_interrupts [qvto:transformation] A_method_specification [qvto:transformation] A_operation_templateParameter_parameteredElement [qvto:transformation] A_outgoing_source_node [qvto:transformation] A_outgoing_source_vertex [qvto:transformation] A_outputElement_regionAsOutput [qvto:transformation] A_parameterSet_parameter [qvto:transformation] A_parameteredElement_templateParameter [qvto:transformation] A_powertypeExtent_powertype [qvto:transformation] A_submachineState_submachine [qvto:transformation] A_toBefore_after All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association). The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end -- i.e., the association is semantically directed in that one end can be logically derived from the other end. Subject: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Date: Wed, 8 Sep 2010 15:10:41 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Thread-Index: ActPoqpMoJ62YPqRThy1foozG3MXTg== From: "Pete Rivett" To: I don.t see why lack of .semantic directionality. ( a new concept) has any bearing at all on the effect of changing one end. Or even what semantics are apparently present which does make use of such directionality . AFAIK it is not specified in UML or MOF. All the Association semantics (in UML and MOF) are based on Links. Independent of any notion of direction. To take one example, A_subject_useCase, if we have Usecase U1 linked to Class C1 as the subject, then: a) Unsetting U1:subject, or removing C1 from the collection, will delete the link and so C1:useCase becomes unset. And vice versa if C1:useCase is unset b) Adding U2 to C1:useCase will retain the original Link and create an additional link between U2 and C1. So C1:useCase = U1, U2; U1.subject=C1, U2.subject=C1. Similarly if C2 is added to U1:subject c) Setting C1:useCase to U2, U3 will remove any existing links from C1 . in this case the link between C1 and U1 There.s an extra complexity if either of the ends is single-valued. If UseCase::subject were [0..1] then in case b) if U2.subject=C2 then that link would be removed Pete From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, September 08, 2010 1:13 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 15449 -- UML 2 RTF issue From: "Rouquette, Nicolas F (316A)" To: "issues@omg.org" CC: "uml2-rtf@omg.org" Date: Wed, 8 Sep 2010 12:54:00 -0700 Subject: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Topic: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Index: ActPj5VITzBJbewdRMaa3nDRm6JegQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association. Two group of proposed changes were removed from 14977. The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274 Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf The second group involves associations that are under-specified in the sense that each association: - does not own any end (i.e., both ends are navigable according to 7.3.45) - none of the ends subset/redefine ends of another association that has semantic directionality The criteria for an association to have semantic directionality is: a) one end is navigable; the other isn't b) one end is composite; the other isn't c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0) e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0) Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any. In UML2.4, there are 9 associations that fail all of (a) through (e): [qvto:transformation] A_containedEdge_inGroup [qvto:transformation] A_containedNode_inGroup [qvto:transformation] A_covered_coveredBy [qvto:transformation] A_edge_inPartition [qvto:transformation] A_generalizationSet_generalization [qvto:transformation] A_inInterruptibleRegion_node [qvto:transformation] A_inPartition_node [qvto:transformation] A_predecessorClause_successorClause [qvto:transformation] A_subject_useCase 19 associations satisfy (a), (b), (c) but fail either (d) and (e): [qvto:transformation] A_before_toAfter [qvto:transformation] A_classifier_templateParameter_parameteredElement [qvto:transformation] A_connectableElement_templateParameter_parameteredElement [qvto:transformation] A_end_role [qvto:transformation] A_extension_metaclass [qvto:transformation] A_incoming_target_node [qvto:transformation] A_incoming_target_vertex [qvto:transformation] A_inputElement_regionAsInput [qvto:transformation] A_interruptingEdge_interrupts [qvto:transformation] A_method_specification [qvto:transformation] A_operation_templateParameter_parameteredElement [qvto:transformation] A_outgoing_source_node [qvto:transformation] A_outgoing_source_vertex [qvto:transformation] A_outputElement_regionAsOutput [qvto:transformation] A_parameterSet_parameter [qvto:transformation] A_parameteredElement_templateParameter [qvto:transformation] A_powertypeExtent_powertype [qvto:transformation] A_submachineState_submachine [qvto:transformation] A_toBefore_after All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association). The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end -- i.e., the association is semantically directed in that one end can be logically derived from the other end. - Nicolas. 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: "Rouquette, Nicolas F (316A)" To: Pete Rivett CC: "uml2-rtf@omg.org" Date: Thu, 9 Sep 2010 13:47:06 -0700 Subject: Re: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Thread-Topic: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Thread-Index: ActQYCp730EtRZMZSeqtSCC5GhDsdg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized You picked the only example of all 9 associations where one can make a reasonable case that the association is truly binary. For the remaining 8 of 9 cases, there is a reasonable way to suggest that there is in fact an intended directionality. For the remaining 409 out of 418 in UML 2.4, the criteria (a) - (e) suffices to give to each association an interpretation as a semantically directed association. For a binary association: u:U -- v:V if v satisfies any of (a)-(e) and u satisfies none of (a)-(e), then the above association is semantically directed: /u:U -> v:V with the derivation for /V:u : U[*] being simply: context V::u : U derive: U.allInstances()->select(u|u.v = self) When the association is truly binary, no such optimization is possible. From a usability point of view, semantically directed associations are easier for users to use because one can explain that we start from the class that owns or is next to the derived end (e.g.,U in the example) and choose value(s) for the end that carries information (e.g., U::v) with the understanding the values of the other end (i.e., /V::u) simply reflect the choices we've made about setting the ends that carry information. From the point of view of integrating models with OWL2 ontologies, semantically directed associations correspond 1-1 to OWL2's OWLObjectProperty where the derived end corresponds to the inverse of the end that carries information. The implication of this criteria is that, except possibly for A_subject_useCase, we can specify the semantics for all or all but one of the 418 associations in UML2.4 with just EMOF without even needing CMOF. That's a simplification in my book! - Nicolas. On Sep 8, 2010, at 3:10 PM, Pete Rivett wrote: I don.t see why lack of .semantic directionality. ( a new concept) has any bearing at all on the effect of changing one end. Or even what semantics are apparently present which does make use of such directionality . AFAIK it is not specified in UML or MOF. All the Association semantics (in UML and MOF) are based on Links. Independent of any notion of direction. To take one example, A_subject_useCase, if we have Usecase U1 linked to Class C1 as the subject, then: a) Unsetting U1:subject, or removing C1 from the collection, will delete the link and so C1:useCase becomes unset. And vice versa if C1:useCase is unset b) Adding U2 to C1:useCase will retain the original Link and create an additional link between U2 and C1. So C1:useCase = U1, U2; U1.subject=C1, U2.subject=C1. Similarly if C2 is added to U1:subject c) Setting C1:useCase to U2, U3 will remove any existing links from C1 . in this case the link between C1 and U1 There.s an extra complexity if either of the ends is single-valued. If UseCase::subject were [0..1] then in case b) if U2.subject=C2 then that link would be removed Pete From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, September 08, 2010 1:13 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 15449 -- UML 2 RTF issue From: "Rouquette, Nicolas F (316A)" To: "issues@omg.org" CC: "uml2-rtf@omg.org" Date: Wed, 8 Sep 2010 12:54:00 -0700 Subject: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Topic: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Index: ActPj5VITzBJbewdRMaa3nDRm6JegQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association. Two group of proposed changes were removed from 14977. The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274 Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf The second group involves associations that are under-specified in the sense that each association: - does not own any end (i.e., both ends are navigable according to 7.3.45) - none of the ends subset/redefine ends of another association that has semantic directionality The criteria for an association to have semantic directionality is: a) one end is navigable; the other isn't b) one end is composite; the other isn't c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0) e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0) Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any. In UML2.4, there are 9 associations that fail all of (a) through (e): [qvto:transformation] A_containedEdge_inGroup [qvto:transformation] A_containedNode_inGroup [qvto:transformation] A_covered_coveredBy [qvto:transformation] A_edge_inPartition [qvto:transformation] A_generalizationSet_generalization [qvto:transformation] A_inInterruptibleRegion_node [qvto:transformation] A_inPartition_node [qvto:transformation] A_predecessorClause_successorClause [qvto:transformation] A_subject_useCase 19 associations satisfy (a), (b), (c) but fail either (d) and (e): [qvto:transformation] A_before_toAfter [qvto:transformation] A_classifier_templateParameter_parameteredElement [qvto:transformation] A_connectableElement_templateParameter_parameteredElement [qvto:transformation] A_end_role [qvto:transformation] A_extension_metaclass [qvto:transformation] A_incoming_target_node [qvto:transformation] A_incoming_target_vertex [qvto:transformation] A_inputElement_regionAsInput [qvto:transformation] A_interruptingEdge_interrupts [qvto:transformation] A_method_specification [qvto:transformation] A_operation_templateParameter_parameteredElement [qvto:transformation] A_outgoing_source_node [qvto:transformation] A_outgoing_source_vertex [qvto:transformation] A_outputElement_regionAsOutput [qvto:transformation] A_parameterSet_parameter [qvto:transformation] A_parameteredElement_templateParameter [qvto:transformation] A_powertypeExtent_powertype [qvto:transformation] A_submachineState_submachine [qvto:transformation] A_toBefore_after All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association). The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end -- i.e., the association is semantically directed in that one end can be logically derived from the other end. - Nicolas. 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 Subject: RE: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Date: Thu, 9 Sep 2010 14:25:08 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Thread-Index: ActQYCp730EtRZMZSeqtSCC5GhDsdgAAlzww From: "Pete Rivett" To: "Rouquette, Nicolas F (316A)" Cc: I don.t see what.s so special about A_subject_useCase. For example why is A_predecessorClause_successorClause particularly directed? And what is the implication of saying only one end .carries information.: would you make the other .derived. properties (such as V:u in your example) read only? That would IMHO be a huge loss of capability. As I said in my last email,, all UML and MOF semantics are in terms of Links which seem simple and powerful and fundamental (corresponding to tuples or relations in logic). And a lot more open and extensible. I don.t see what.s motivating this: if your aim is simplification it seems more appropriate for the UML 2.5 submission team mailing list. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, September 09, 2010 1:47 PM To: Pete Rivett Cc: uml2-rtf@omg.org Subject: Re: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) You picked the only example of all 9 associations where one can make a reasonable case that the association is truly binary. For the remaining 8 of 9 cases, there is a reasonable way to suggest that there is in fact an intended directionality. For the remaining 409 out of 418 in UML 2.4, the criteria (a) - (e) suffices to give to each association an interpretation as a semantically directed association. For a binary association: u:U -- v:V if v satisfies any of (a)-(e) and u satisfies none of (a)-(e), then the above association is semantically directed: /u:U -> v:V with the derivation for /V:u : U[*] being simply: context V::u : U derive: U.allInstances()->select(u|u.v = self) When the association is truly binary, no such optimization is possible. From a usability point of view, semantically directed associations are easier for users to use because one can explain that we start from the class that owns or is next to the derived end (e.g.,U in the example) and choose value(s) for the end that carries information (e.g., U::v) with the understanding the values of the other end (i.e., /V::u) simply reflect the choices we've made about setting the ends that carry information. From the point of view of integrating models with OWL2 ontologies, semantically directed associations correspond 1-1 to OWL2's OWLObjectProperty where the derived end corresponds to the inverse of the end that carries information. The implication of this criteria is that, except possibly for A_subject_useCase, we can specify the semantics for all or all but one of the 418 associations in UML2.4 with just EMOF without even needing CMOF. That's a simplification in my book! - Nicolas. On Sep 8, 2010, at 3:10 PM, Pete Rivett wrote: I don.t see why lack of .semantic directionality. ( a new concept) has any bearing at all on the effect of changing one end. Or even what semantics are apparently present which does make use of such directionality . AFAIK it is not specified in UML or MOF. All the Association semantics (in UML and MOF) are based on Links. Independent of any notion of direction. To take one example, A_subject_useCase, if we have Usecase U1 linked to Class C1 as the subject, then: a) Unsetting U1:subject, or removing C1 from the collection, will delete the link and so C1:useCase becomes unset. And vice versa if C1:useCase is unset b) Adding U2 to C1:useCase will retain the original Link and create an additional link between U2 and C1. So C1:useCase = U1, U2; U1.subject=C1, U2.subject=C1. Similarly if C2 is added to U1:subject c) Setting C1:useCase to U2, U3 will remove any existing links from C1 . in this case the link between C1 and U1 There.s an extra complexity if either of the ends is single-valued. If UseCase::subject were [0..1] then in case b) if U2.subject=C2 then that link would be removed Pete From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, September 08, 2010 1:13 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 15449 -- UML 2 RTF issue From: "Rouquette, Nicolas F (316A)" To: "issues@omg.org" CC: "uml2-rtf@omg.org" Date: Wed, 8 Sep 2010 12:54:00 -0700 Subject: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Topic: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Index: ActPj5VITzBJbewdRMaa3nDRm6JegQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association. Two group of proposed changes were removed from 14977. The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274 Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf The second group involves associations that are under-specified in the sense that each association: - does not own any end (i.e., both ends are navigable according to 7.3.45) - none of the ends subset/redefine ends of another association that has semantic directionality The criteria for an association to have semantic directionality is: a) one end is navigable; the other isn't b) one end is composite; the other isn't c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0) e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0) Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any. In UML2.4, there are 9 associations that fail all of (a) through (e): [qvto:transformation] A_containedEdge_inGroup [qvto:transformation] A_containedNode_inGroup [qvto:transformation] A_covered_coveredBy [qvto:transformation] A_edge_inPartition [qvto:transformation] A_generalizationSet_generalization [qvto:transformation] A_inInterruptibleRegion_node [qvto:transformation] A_inPartition_node [qvto:transformation] A_predecessorClause_successorClause [qvto:transformation] A_subject_useCase 19 associations satisfy (a), (b), (c) but fail either (d) and (e): [qvto:transformation] A_before_toAfter [qvto:transformation] A_classifier_templateParameter_parameteredElement [qvto:transformation] A_connectableElement_templateParameter_parameteredElement [qvto:transformation] A_end_role [qvto:transformation] A_extension_metaclass [qvto:transformation] A_incoming_target_node [qvto:transformation] A_incoming_target_vertex [qvto:transformation] A_inputElement_regionAsInput [qvto:transformation] A_interruptingEdge_interrupts [qvto:transformation] A_method_specification [qvto:transformation] A_operation_templateParameter_parameteredElement [qvto:transformation] A_outgoing_source_node [qvto:transformation] A_outgoing_source_vertex [qvto:transformation] A_outputElement_regionAsOutput [qvto:transformation] A_parameterSet_parameter [qvto:transformation] A_parameteredElement_templateParameter [qvto:transformation] A_powertypeExtent_powertype [qvto:transformation] A_submachineState_submachine [qvto:transformation] A_toBefore_after All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association). The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end -- i.e., the association is semantically directed in that one end can be logically derived from the other end. - Nicolas. 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 Subject: RE: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Date: Thu, 9 Sep 2010 17:40:49 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) thread-index: ActQYCp730EtRZMZSeqtSCC5GhDsdgAAlzwwAAE9pWA= From: "Ed Seidewitz" To: "Pete Rivett - Adaptive" , "Rouquette, Nicolas F (316A)" Cc: Well, since I think what Nicolas is suggesting would require a metamodel change, it would actually be out of scope for the UML 2.5 spec simplification. -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, September 09, 2010 5:25 PM To: Rouquette, Nicolas F (316A) Cc: uml2-rtf@omg.org Subject: RE: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) I don.t see what.s so special about A_subject_useCase. For example why is A_predecessorClause_successorClause particularly directed? And what is the implication of saying only one end .carries information.: would you make the other .derived. properties (such as V:u in your example) read only? That would IMHO be a huge loss of capability. As I said in my last email,, all UML and MOF semantics are in terms of Links which seem simple and powerful and fundamental (corresponding to tuples or relations in logic). And a lot more open and extensible. I don.t see what.s motivating this: if your aim is simplification it seems more appropriate for the UML 2.5 submission team mailing list. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, September 09, 2010 1:47 PM To: Pete Rivett Cc: uml2-rtf@omg.org Subject: Re: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) You picked the only example of all 9 associations where one can make a reasonable case that the association is truly binary. For the remaining 8 of 9 cases, there is a reasonable way to suggest that there is in fact an intended directionality. For the remaining 409 out of 418 in UML 2.4, the criteria (a) - (e) suffices to give to each association an interpretation as a semantically directed association. For a binary association: u:U -- v:V if v satisfies any of (a)-(e) and u satisfies none of (a)-(e), then the above association is semantically directed: /u:U -> v:V with the derivation for /V:u : U[*] being simply: context V::u : U derive: U.allInstances()->select(u|u.v = self) When the association is truly binary, no such optimization is possible. From a usability point of view, semantically directed associations are easier for users to use because one can explain that we start from the class that owns or is next to the derived end (e.g.,U in the example) and choose value(s) for the end that carries information (e.g., U::v) with the understanding the values of the other end (i.e., /V::u) simply reflect the choices we've made about setting the ends that carry information. From the point of view of integrating models with OWL2 ontologies, semantically directed associations correspond 1-1 to OWL2's OWLObjectProperty where the derived end corresponds to the inverse of the end that carries information. The implication of this criteria is that, except possibly for A_subject_useCase, we can specify the semantics for all or all but one of the 418 associations in UML2.4 with just EMOF without even needing CMOF. That's a simplification in my book! - Nicolas. On Sep 8, 2010, at 3:10 PM, Pete Rivett wrote: I don.t see why lack of .semantic directionality. ( a new concept) has any bearing at all on the effect of changing one end. Or even what semantics are apparently present which does make use of such directionality . AFAIK it is not specified in UML or MOF. All the Association semantics (in UML and MOF) are based on Links. Independent of any notion of direction. To take one example, A_subject_useCase, if we have Usecase U1 linked to Class C1 as the subject, then: a) Unsetting U1:subject, or removing C1 from the collection, will delete the link and so C1:useCase becomes unset. And vice versa if C1:useCase is unset b) Adding U2 to C1:useCase will retain the original Link and create an additional link between U2 and C1. So C1:useCase = U1, U2; U1.subject=C1, U2.subject=C1. Similarly if C2 is added to U1:subject c) Setting C1:useCase to U2, U3 will remove any existing links from C1 . in this case the link between C1 and U1 There.s an extra complexity if either of the ends is single-valued. If UseCase::subject were [0..1] then in case b) if U2.subject=C2 then that link would be removed Pete From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, September 08, 2010 1:13 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 15449 -- UML 2 RTF issue From: "Rouquette, Nicolas F (316A)" To: "issues@omg.org" CC: "uml2-rtf@omg.org" Date: Wed, 8 Sep 2010 12:54:00 -0700 Subject: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Topic: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Index: ActPj5VITzBJbewdRMaa3nDRm6JegQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association. Two group of proposed changes were removed from 14977. The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274 Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf The second group involves associations that are under-specified in the sense that each association: - does not own any end (i.e., both ends are navigable according to 7.3.45) - none of the ends subset/redefine ends of another association that has semantic directionality The criteria for an association to have semantic directionality is: a) one end is navigable; the other isn't b) one end is composite; the other isn't c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0) e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0) Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any. In UML2.4, there are 9 associations that fail all of (a) through (e): [qvto:transformation] A_containedEdge_inGroup [qvto:transformation] A_containedNode_inGroup [qvto:transformation] A_covered_coveredBy [qvto:transformation] A_edge_inPartition [qvto:transformation] A_generalizationSet_generalization [qvto:transformation] A_inInterruptibleRegion_node [qvto:transformation] A_inPartition_node [qvto:transformation] A_predecessorClause_successorClause [qvto:transformation] A_subject_useCase 19 associations satisfy (a), (b), (c) but fail either (d) and (e): [qvto:transformation] A_before_toAfter [qvto:transformation] A_classifier_templateParameter_parameteredElement [qvto:transformation] A_connectableElement_templateParameter_parameteredElement [qvto:transformation] A_end_role [qvto:transformation] A_extension_metaclass [qvto:transformation] A_incoming_target_node [qvto:transformation] A_incoming_target_vertex [qvto:transformation] A_inputElement_regionAsInput [qvto:transformation] A_interruptingEdge_interrupts [qvto:transformation] A_method_specification [qvto:transformation] A_operation_templateParameter_parameteredElement [qvto:transformation] A_outgoing_source_node [qvto:transformation] A_outgoing_source_vertex [qvto:transformation] A_outputElement_regionAsOutput [qvto:transformation] A_parameterSet_parameter [qvto:transformation] A_parameteredElement_templateParameter [qvto:transformation] A_powertypeExtent_powertype [qvto:transformation] A_submachineState_submachine [qvto:transformation] A_toBefore_after All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association). The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end -- i.e., the association is semantically directed in that one end can be logically derived from the other end. - Nicolas. 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=m4s1hwUYqgZGztY27i51V2evK3TkNZYBvD70vJcJJRM=; b=ghhUhyadcgVcEcFdxBdTZlgfi2+aPcb2+LQVlrANU6pZCEa3KH/ju2la029bP0022w DIHzsV5Y3eMSkveTExqrLuMyZJ292nAPlIicjOzPlsYdqCYl/6W0nKVuAOFenT5Do40z 2fAIrMPfyyUsIzXiOzBQDWuQBCo6363zjGFFk= 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=rsqqMuX6vBppV4NX/e6BzqxRoWfI/0qJvbvVLx0d6PCWH4DhA7/iCMHXX1MSJCGhEY rkwbHqMeGUIL+MhxPUBRalyx4TZTepswggQtlwrVwHNvNso+BvR+Vk7qdnRNysJHton2 ajoWScZavputJjknbf8b11P/S9wqC2eQ7mLjY= Sender: bran.selic@gmail.com From: Bran Selic Date: Thu, 9 Sep 2010 18:09:33 -0400 X-Google-Sender-Auth: Fr5TY7JE9ajPv6YUby5MpW35mQA Subject: Re: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) To: Ed Seidewitz Cc: Pete Rivett - Adaptive , "Rouquette, Nicolas F (316A)" , uml2-rtf@omg.org I think that Ed is right: this may require a metamodel change and may be out of scope for 2.5. However, if I understood Nicolas' intent properly, I fully agree with him that there are many cases where there is an intended directionality to links. This, BTW, is what I called the "Milicev interpretation" of associations, which I see as perfectly valid. It occurs in cases where the association can be viewed as a mapping from a source set (classifier) to a target set (classifier). Such mappings need not always be symmetric. For example, one association end of a binary association may be unique but not its opposite (see issue 6464). You may decide to exclude this interpretation of associations -- although I think that would reduce the expressive power of UML (which I think is Nicolas' point). Whatever the decision, this point should be clarified. Cheers...Bran On Thu, Sep 9, 2010 at 5:40 PM, Ed Seidewitz wrote: Well, since I think what Nicolas is suggesting would require a metamodel change, it would actually be out of scope for the UML 2.5 spec simplification. -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, September 09, 2010 5:25 PM To: Rouquette, Nicolas F (316A) Cc: uml2-rtf@omg.org Subject: RE: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) I don.t see what.s so special about A_subject_useCase. For example why is A_predecessorClause_successorClause particularly directed? And what is the implication of saying only one end .carries information.: would you make the other .derived. properties (such as V:u in your example) read only? That would IMHO be a huge loss of capability. As I said in my last email,, all UML and MOF semantics are in terms of Links which seem simple and powerful and fundamental (corresponding to tuples or relations in logic). And a lot more open and extensible. I don.t see what.s motivating this: if your aim is simplification it seems more appropriate for the UML 2.5 submission team mailing list. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, September 09, 2010 1:47 PM To: Pete Rivett Cc: uml2-rtf@omg.org Subject: Re: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) You picked the only example of all 9 associations where one can make a reasonable case that the association is truly binary. For the remaining 8 of 9 cases, there is a reasonable way to suggest that there is in fact an intended directionality. For the remaining 409 out of 418 in UML 2.4, the criteria (a) - (e) suffices to give to each association an interpretation as a semantically directed association. For a binary association: u:U -- v:V if v satisfies any of (a)-(e) and u satisfies none of (a)-(e), then the above association is semantically directed: /u:U -> v:V with the derivation for /V:u : U[*] being simply: context V::u : U derive: U.allInstances()->select(u|u.v = self) When the association is truly binary, no such optimization is possible. From a usability point of view, semantically directed associations are easier for users to use because one can explain that we start from the class that owns or is next to the derived end (e.g.,U in the example) and choose value(s) for the end that carries information (e.g., U::v) with the understanding the values of the other end (i.e., /V::u) simply reflect the choices we've made about setting the ends that carry information. From the point of view of integrating models with OWL2 ontologies, semantically directed associations correspond 1-1 to OWL2's OWLObjectProperty where the derived end corresponds to the inverse of the end that carries information. The implication of this criteria is that, except possibly for A_subject_useCase, we can specify the semantics for all or all but one of the 418 associations in UML2.4 with just EMOF without even needing CMOF. That's a simplification in my book! - Nicolas. On Sep 8, 2010, at 3:10 PM, Pete Rivett wrote: I don.t see why lack of .semantic directionality. ( a new concept) has any bearing at all on the effect of changing one end. Or even what semantics are apparently present which does make use of such directionality . AFAIK it is not specified in UML or MOF. All the Association semantics (in UML and MOF) are based on Links. Independent of any notion of direction. To take one example, A_subject_useCase, if we have Usecase U1 linked to Class C1 as the subject, then: a) Unsetting U1:subject, or removing C1 from the collection, will delete the link and so C1:useCase becomes unset. And vice versa if C1:useCase is unset b) Adding U2 to C1:useCase will retain the original Link and create an additional link between U2 and C1. So C1:useCase = U1, U2; U1.subject=C1, U2.subject=C1. Similarly if C2 is added to U1:subject c) Setting C1:useCase to U2, U3 will remove any existing links from C1 . in this case the link between C1 and U1 There.s an extra complexity if either of the ends is single-valued. If UseCase::subject were [0..1] then in case b) if U2.subject=C2 then that link would be removed Pete From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, September 08, 2010 1:13 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 15449 -- UML 2 RTF issue From: "Rouquette, Nicolas F (316A)" To: "issues@omg.org" CC: "uml2-rtf@omg.org" Date: Wed, 8 Sep 2010 12:54:00 -0700 Subject: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Topic: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Index: ActPj5VITzBJbewdRMaa3nDRm6JegQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association. Two group of proposed changes were removed from 14977. The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274 Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf The second group involves associations that are under-specified in the sense that each association: - does not own any end (i.e., both ends are navigable according to 7.3.45) - none of the ends subset/redefine ends of another association that has semantic directionality The criteria for an association to have semantic directionality is: a) one end is navigable; the other isn't b) one end is composite; the other isn't c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0) e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0) Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any. In UML2.4, there are 9 associations that fail all of (a) through (e): [qvto:transformation] A_containedEdge_inGroup [qvto:transformation] A_containedNode_inGroup [qvto:transformation] A_covered_coveredBy [qvto:transformation] A_edge_inPartition [qvto:transformation] A_generalizationSet_generalization [qvto:transformation] A_inInterruptibleRegion_node [qvto:transformation] A_inPartition_node [qvto:transformation] A_predecessorClause_successorClause [qvto:transformation] A_subject_useCase 19 associations satisfy (a), (b), (c) but fail either (d) and (e): [qvto:transformation] A_before_toAfter [qvto:transformation] A_classifier_templateParameter_parameteredElement [qvto:transformation] A_connectableElement_templateParameter_parameteredElement [qvto:transformation] A_end_role [qvto:transformation] A_extension_metaclass [qvto:transformation] A_incoming_target_node [qvto:transformation] A_incoming_target_vertex [qvto:transformation] A_inputElement_regionAsInput [qvto:transformation] A_interruptingEdge_interrupts [qvto:transformation] A_method_specification [qvto:transformation] A_operation_templateParameter_parameteredElement [qvto:transformation] A_outgoing_source_node [qvto:transformation] A_outgoing_source_vertex [qvto:transformation] A_outputElement_regionAsOutput [qvto:transformation] A_parameterSet_parameter [qvto:transformation] A_parameteredElement_templateParameter [qvto:transformation] A_powertypeExtent_powertype [qvto:transformation] A_submachineState_submachine [qvto:transformation] A_toBefore_after All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association). The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end -- i.e., the association is semantically directed in that one end can be logically derived from the other end. - Nicolas. 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: "Rouquette, Nicolas F (316A)" To: Bran Selic CC: Ed Seidewitz , Pete Rivett - Adaptive , "uml2-rtf@omg.org" Date: Thu, 9 Sep 2010 20:09:22 -0700 Subject: Re: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Thread-Topic: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Thread-Index: ActQlZISvlVJdiM6RX6+FGJAa5v+Bg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Bran, Indeed, this issue came about from having to clarify how much information each binary association really carries. 1) are both association ends necessary? 2) can we pick any association end arbitrarily and fully derive the other association end from it? 3) are the options limited to only one association end with which one can then fully derive the other association end from it but not the other way around? Metamodel implementations compensate with the help of code generators for (1) vs. (2) or (3); however, code generators operate outside the scope of the specification so we still need to clarify what really determines the collection of links in the association. For end user models, there is a significant difference between (1) vs. (2) or (3). With (1), if the modeling tool doesn't have support for association links in user models (e.g., Eclipse EMF/UML), then this kind of association spells all kinds of troubles, particularly if instances are involved. End user models that have associations with non-unique association ends are particularly troublesome as explained in Dragan;s book. - Nicolas. On Sep 9, 2010, at 3:09 PM, Bran Selic wrote: I think that Ed is right: this may require a metamodel change and may be out of scope for 2.5. However, if I understood Nicolas' intent properly, I fully agree with him that there are many cases where there is an intended directionality to links. This, BTW, is what I called the "Milicev interpretation" of associations, which I see as perfectly valid. It occurs in cases where the association can be viewed as a mapping from a source set (classifier) to a target set (classifier). Such mappings need not always be symmetric. For example, one association end of a binary association may be unique but not its opposite (see issue 6464). You may decide to exclude this interpretation of associations -- although I think that would reduce the expressive power of UML (which I think is Nicolas' point). Whatever the decision, this point should be clarified. Cheers...Bran On Thu, Sep 9, 2010 at 5:40 PM, Ed Seidewitz wrote: Well, since I think what Nicolas is suggesting would require a metamodel change, it would actually be out of scope for the UML 2.5 spec simplification. -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, September 09, 2010 5:25 PM To: Rouquette, Nicolas F (316A) Cc: uml2-rtf@omg.org Subject: RE: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) I don.t see what.s so special about A_subject_useCase. For example why is A_predecessorClause_successorClause particularly directed? And what is the implication of saying only one end .carries information.: would you make the other .derived. properties (such as V:u in your example) read only? That would IMHO be a huge loss of capability. As I said in my last email,, all UML and MOF semantics are in terms of Links which seem simple and powerful and fundamental (corresponding to tuples or relations in logic). And a lot more open and extensible. I don.t see what.s motivating this: if your aim is simplification it seems more appropriate for the UML 2.5 submission team mailing list. Pete From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, September 09, 2010 1:47 PM To: Pete Rivett Cc: uml2-rtf@omg.org Subject: Re: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) You picked the only example of all 9 associations where one can make a reasonable case that the association is truly binary. For the remaining 8 of 9 cases, there is a reasonable way to suggest that there is in fact an intended directionality. For the remaining 409 out of 418 in UML 2.4, the criteria (a) - (e) suffices to give to each association an interpretation as a semantically directed association. For a binary association: u:U -- v:V if v satisfies any of (a)-(e) and u satisfies none of (a)-(e), then the above association is semantically directed: /u:U -> v:V with the derivation for /V:u : U[*] being simply: context V::u : U derive: U.allInstances()->select(u|u.v = self) When the association is truly binary, no such optimization is possible. From a usability point of view, semantically directed associations are easier for users to use because one can explain that we start from the class that owns or is next to the derived end (e.g.,U in the example) and choose value(s) for the end that carries information (e.g., U::v) with the understanding the values of the other end (i.e., /V::u) simply reflect the choices we've made about setting the ends that carry information. From the point of view of integrating models with OWL2 ontologies, semantically directed associations correspond 1-1 to OWL2's OWLObjectProperty where the derived end corresponds to the inverse of the end that carries information. The implication of this criteria is that, except possibly for A_subject_useCase, we can specify the semantics for all or all but one of the 418 associations in UML2.4 with just EMOF without even needing CMOF. That's a simplification in my book! - Nicolas. On Sep 8, 2010, at 3:10 PM, Pete Rivett wrote: I don.t see why lack of .semantic directionality. ( a new concept) has any bearing at all on the effect of changing one end. Or even what semantics are apparently present which does make use of such directionality . AFAIK it is not specified in UML or MOF. All the Association semantics (in UML and MOF) are based on Links. Independent of any notion of direction. To take one example, A_subject_useCase, if we have Usecase U1 linked to Class C1 as the subject, then: a) Unsetting U1:subject, or removing C1 from the collection, will delete the link and so C1:useCase becomes unset. And vice versa if C1:useCase is unset b) Adding U2 to C1:useCase will retain the original Link and create an additional link between U2 and C1. So C1:useCase = U1, U2; U1.subject=C1, U2.subject=C1. Similarly if C2 is added to U1:subject c) Setting C1:useCase to U2, U3 will remove any existing links from C1 . in this case the link between C1 and U1 There.s an extra complexity if either of the ends is single-valued. If UseCase::subject were [0..1] then in case b) if U2.subject=C2 then that link would be removed Pete From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, September 08, 2010 1:13 PM To: issues@omg.org; uml2-rtf@omg.org Subject: issue 15449 -- UML 2 RTF issue From: "Rouquette, Nicolas F (316A)" To: "issues@omg.org" CC: "uml2-rtf@omg.org" Date: Wed, 8 Sep 2010 12:54:00 -0700 Subject: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Topic: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Index: ActPj5VITzBJbewdRMaa3nDRm6JegQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association. Two group of proposed changes were removed from 14977. The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274 Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf The second group involves associations that are under-specified in the sense that each association: - does not own any end (i.e., both ends are navigable according to 7.3.45) - none of the ends subset/redefine ends of another association that has semantic directionality The criteria for an association to have semantic directionality is: a) one end is navigable; the other isn't b) one end is composite; the other isn't c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0) e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0) Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any. In UML2.4, there are 9 associations that fail all of (a) through (e): [qvto:transformation] A_containedEdge_inGroup [qvto:transformation] A_containedNode_inGroup [qvto:transformation] A_covered_coveredBy [qvto:transformation] A_edge_inPartition [qvto:transformation] A_generalizationSet_generalization [qvto:transformation] A_inInterruptibleRegion_node [qvto:transformation] A_inPartition_node [qvto:transformation] A_predecessorClause_successorClause [qvto:transformation] A_subject_useCase 19 associations satisfy (a), (b), (c) but fail either (d) and (e): [qvto:transformation] A_before_toAfter [qvto:transformation] A_classifier_templateParameter_parameteredElement [qvto:transformation] A_connectableElement_templateParameter_parameteredElement [qvto:transformation] A_end_role [qvto:transformation] A_extension_metaclass [qvto:transformation] A_incoming_target_node [qvto:transformation] A_incoming_target_vertex [qvto:transformation] A_inputElement_regionAsInput [qvto:transformation] A_interruptingEdge_interrupts [qvto:transformation] A_method_specification [qvto:transformation] A_operation_templateParameter_parameteredElement [qvto:transformation] A_outgoing_source_node [qvto:transformation] A_outgoing_source_vertex [qvto:transformation] A_outputElement_regionAsOutput [qvto:transformation] A_parameterSet_parameter [qvto:transformation] A_parameteredElement_templateParameter [qvto:transformation] A_powertypeExtent_powertype [qvto:transformation] A_submachineState_submachine [qvto:transformation] A_toBefore_after All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association). The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end -- i.e., the association is semantically directed in that one end can be logically derived from the other end. - Nicolas. 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 Date: Fri, 10 Sep 2010 18:38:00 +0100 From: Dave Hawkins User-Agent: Thunderbird 2.0.0.21 (X11/20090302) To: "Rouquette, Nicolas F (316A)" CC: Bran Selic , Ed Seidewitz , Pete Rivett - Adaptive , "uml2-rtf@omg.org" Subject: Re: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Like Pete, I'm a little perplexed by this issue. Your most recent mail suggests that the source of the problem is that EMF/UML doesn't handle opposite properties properly. That would seem to be a tooling issue for EMF rather than an issue with UML. Oracle's MOF implementation effectively acts as Pete describes, although we don't have direct representation of links; we just keep the ends updated appropriately. (This does mean we don't support non-unique ends, which I was under the impression weren't allowed in MOF, but I believe changed in a recent resolution. I don't really see any value in having non-unique ends in MOF.) Now I can understand if your concern is more about the storage of data. For example, if you serialise a model into XMI such that linked objects are stored in separate files with their ends. With both ends storing semantic data there's a possibility that the files may become out of sync. This is particularly problematic in a versioned environment. Only storing one end mitigates that a little as it reduces link validation. It also means that fewer files will be dirtied as a result of updating a single link. Is this effectively what you are trying to achieve? Cheers, Dave Rouquette, Nicolas F (316A) wrote: Bran, Indeed, this issue came about from having to clarify how much information each binary association really carries. 1) are both association ends necessary? 2) can we pick any association end arbitrarily and fully derive the other association end from it? 3) are the options limited to only one association end with which one can then fully derive the other association end from it but not the other way around? Metamodel implementations compensate with the help of code generators for (1) vs. (2) or (3); however, code generators operate outside the scope of the specification so we still need to clarify what really determines the collection of links in the association. For end user models, there is a significant difference between (1) vs. (2) or (3). With (1), if the modeling tool doesn't have support for association links in user models (e.g., Eclipse EMF/UML), then this kind of association spells all kinds of troubles, particularly if instances are involved. End user models that have associations with non-unique association ends are particularly troublesome as explained in Dragan;s book. - Nicolas. On Sep 9, 2010, at 3:09 PM, Bran Selic wrote: I think that Ed is right: this may require a metamodel change and may be out of scope for 2.5. However, if I understood Nicolas' intent properly, I fully agree with him that there are many cases where there is an intended directionality to links. This, BTW, is what I called the "Milicev interpretation" of associations, which I see as perfectly valid. It occurs in cases where the association can be viewed as a mapping from a source set (classifier) to a target set (classifier). Such mappings need not always be symmetric. For example, one association end of a binary association may be unique but not its opposite (see issue 6464). You may decide to exclude this interpretation of associations -- although I think that would reduce the expressive power of UML (which I think is Nicolas' point). Whatever the decision, this point should be clarified. Cheers...Bran On Thu, Sep 9, 2010 at 5:40 PM, Ed Seidewitz > wrote: Well, since I think what Nicolas is suggesting would require a metamodel change, it would actually be out of scope for the UML 2.5 /spec/ simplification. ------------------------------------------------------------------------ *From:* Pete Rivett [mailto:pete.rivett@adaptive.com ] *Sent:* Thursday, September 09, 2010 5:25 PM *To:* Rouquette, Nicolas F (316A) *Cc:* uml2-rtf@omg.org *Subject:* RE: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) I don.t see what.s so special about A_subject_useCase. For example why is A_predecessorClause_successorClause particularly directed? And what is the implication of saying only one end .carries information.: would you make the other .derived. properties (such as V:u in your example) read only? That would IMHO be a huge loss of capability. As I said in my last email,, all UML and MOF semantics are in terms of Links which seem simple and powerful and fundamental (corresponding to tuples or relations in logic). And a lot more open and extensible. I don.t see what.s motivating this: if your aim is simplification it seems more appropriate for the UML 2.5 submission team mailing list. Pete *From:* Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov ] *Sent:* Thursday, September 09, 2010 1:47 PM *To:* Pete Rivett *Cc:* uml2-rtf@omg.org *Subject:* Re: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) You picked the only example of all 9 associations where one can make a reasonable case that the association is truly binary. For the remaining 8 of 9 cases, there is a reasonable way to suggest that there is in fact an intended directionality. For the remaining 409 out of 418 in UML 2.4, the criteria (a) - (e) suffices to give to each association an interpretation as a semantically directed association. For a binary association: u:U -- v:V if v satisfies any of (a)-(e) and u satisfies none of (a)-(e), then the above association is semantically directed: /u:U -> v:V with the derivation for /V:u : U[*] being simply: context V::u : U derive: U.allInstances()->select(u|u.v = self) When the association is truly binary, no such optimization is possible. From a usability point of view, semantically directed associations are easier for users to use because one can explain that we start from the class that owns or is next to the derived end (e.g.,U in the example) and choose value(s) for the end that carries information (e.g., U::v) with the understanding the values of the other end (i.e., /V::u) simply reflect the choices we've made about setting the ends that carry information. From the point of view of integrating models with OWL2 ontologies, semantically directed associations correspond 1-1 to OWL2's OWLObjectProperty where the derived end corresponds to the inverse of the end that carries information. The implication of this criteria is that, except possibly for A_subject_useCase, we can specify the semantics for all or all but one of the 418 associations in UML2.4 with just EMOF without even needing CMOF. That's a simplification in my book! - Nicolas. On Sep 8, 2010, at 3:10 PM, Pete Rivett wrote: I don.t see why lack of .semantic directionality. ( a new concept) has any bearing at all on the effect of changing one end. Or even what semantics are apparently present which does make use of such directionality ­ AFAIK it is not specified in UML or MOF. All the Association semantics (in UML and MOF) are based on Links. Independent of any notion of direction. To take one example, A_subject_useCase, if we have Usecase U1 linked to Class C1 as the subject, then: a) Unsetting U1:subject, or removing C1 from the collection, will delete the link and so C1:useCase becomes unset. And vice versa if C1:useCase is unset b) Adding U2 to C1:useCase will retain the original Link and create an additional link between U2 and C1. So C1:useCase = U1, U2; U1.subject=C1, U2.subject=C1. Similarly if C2 is added to U1:subject c) Setting C1:useCase to U2, U3 will remove any existing links from C1 ­ in this case the link between C1 and U1 There.s an extra complexity if either of the ends is single-valued. If UseCase::subject were [0..1] then in case b) if U2.subject=C2 then that link would be removed Pete *From:* Juergen Boldt [mailto:juergen@omg.org ] *Sent:* Wednesday, September 08, 2010 1:13 PM *To:* issues@omg.org ; uml2-rtf@omg.org *Subject:* issue 15449 -- UML 2 RTF issue From: "Rouquette, Nicolas F (316A)" > To: "issues@omg.org " > CC: "uml2-rtf@omg.org " > Date: Wed, 8 Sep 2010 12:54:00 -0700 Subject: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Topic: Under-specified associations in UML2.4 & the need for clarifying the semantic directionality for all UML associations. Thread-Index: ActPj5VITzBJbewdRMaa3nDRm6JegQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Resolution 14977 cleaned up many association end subsets/redefinitions; in particular, this resolution ensures that if an association end subsets/redefines another, then there is a symmetric subsetting/redefinition of the other end and that the subsetted/redefined ends belong to the same association. Two group of proposed changes were removed from 14977. The first group involves generalization relationships among associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274 Generalization relationships are needed when the semantics of an association whose ends subset/redefine the ends of another association is that the set of links of the former association are necessarily a subset of the links of the latter. Since this isn't necessarily the case, it implies that generalization relationships are needed to clarify this semantic intent as shown in slide 31 of the following UML2.0 presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf The second group involves associations that are under-specified in the sense that each association: - does not own any end (i.e., both ends are navigable according to 7.3.45) - none of the ends subset/redefine ends of another association that has semantic directionality The criteria for an association to have semantic directionality is: a) one end is navigable; the other isn't b) one end is composite; the other isn't c) one end subsets/redefines another end of an association that is semantically directed; the other doesn't d) one end has required multiplicity (i.e., lower>0); the other is optional (i.e., lower=0) e) one end has bounded multiplicity (i.e., upper>0); the other has unbounded multiplicity (i.e., upper<0) Without semantic directionality, an association owns neither of its member ends and there is no objective criteria to determine what effect changing one association end can/should/may have on changes to the other end, if any. In UML2.4, there are 9 associations that fail all of (a) through (e): [qvto:transformation] A_containedEdge_inGroup [qvto:transformation] A_containedNode_inGroup [qvto:transformation] A_covered_coveredBy [qvto:transformation] A_edge_inPartition [qvto:transformation] A_generalizationSet_generalization [qvto:transformation] A_inInterruptibleRegion_node [qvto:transformation] A_inPartition_node [qvto:transformation] A_predecessorClause_successorClause [qvto:transformation] A_subject_useCase 19 associations satisfy (a), (b), (c) but fail either (d) and (e): [qvto:transformation] A_before_toAfter [qvto:transformation] A_classifier_templateParameter_parameteredElement [qvto:transformation] A_connectableElement_templateParameter_parameteredElement [qvto:transformation] A_end_role [qvto:transformation] A_extension_metaclass [qvto:transformation] A_incoming_target_node [qvto:transformation] A_incoming_target_vertex [qvto:transformation] A_inputElement_regionAsInput [qvto:transformation] A_interruptingEdge_interrupts [qvto:transformation] A_method_specification [qvto:transformation] A_operation_templateParameter_parameteredElement [qvto:transformation] A_outgoing_source_node [qvto:transformation] A_outgoing_source_vertex [qvto:transformation] A_outputElement_regionAsOutput [qvto:transformation] A_parameterSet_parameter [qvto:transformation] A_parameteredElement_templateParameter [qvto:transformation] A_powertypeExtent_powertype [qvto:transformation] A_submachineState_submachine [qvto:transformation] A_toBefore_after All 28 cases above correspond to associations that, while well-formed in the metamodel according to 14977 & other applicable resolutions, are under-specified in the specification in the sense that there is a reasonable interpretation where each association has a natural direction, either because of cardinality restrictions (i.e., (d) or (e) would suffice to give direction to the 19 associations above) or because there is insufficient application of the architecture principles for OMG metamodels (e.g., incomplete modeling of ownership in most of the cases for the first group of 9 association). The consequence for end users is that each of the 28 associations represents a source of modeling errors unless tool implementations choose to implement these associations in a non-standard way, e.g., by ascribing a sensible semantics to these associations that removes the ambiguity about which end can be changed independently of the other end -- i.e., the association is semantically directed in that one end can be logically derived from the other end. - Nicolas. * 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 *[] -- 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. From: "Rouquette, Nicolas F (316A)" To: Dave Hawkins CC: Bran Selic , Ed Seidewitz , Pete Rivett - Adaptive , "uml2-rtf@omg.org" Date: Fri, 10 Sep 2010 18:38:32 -0700 Subject: Re: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Thread-Topic: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Thread-Index: ActRUgskvaDw7pOjTqy/o2fQoq3RbA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o8B1M9jn004384 Dave, I'll only focus on the issue as reported. The underlying problem has a relation to storage, e.g., XMI, where the XMI serialization rules apply similar criteria to decide whether an association end carries essential information that must be serialized or not. Example of an association that is already semantically directed in the metamodel: A_redefinedProperty_property (fig 7.12) -- according to (a) it is directed. Indeed, we only store the Property::redefinedProperty end in XMI. Example of one of the 19 association that is currently not semantically directed but could be: A_outgoing_source_node (fig 12.5) --according to (d), it is directed; it would be sufficient to store just the information in ActivityEdge::source and we could derive the information in ActivityNode::outgoing from all edges in the activity. In fact, there is very little difference between this association and the one below where, thanks to one end being derived, the directionality is reflected in the XMI serialization. A_outgoing_source_vertex (fig. 15.2) -- according to (d) and (a), it is directed; indeed, XMI doesn't even store derived properties; we only store Transition::source. The point of this issue is that the modeling of associations is done sub-optimally w.r.t. what the associations really mean. If we examined each of the 19 associations, it is easy to conclude that the association is semantically directed in the sense that only one of the association ends matters for serialization and for model construction. The other end is important but it can be derived from the first. The first group of 9 associations is different in that there is no obvious criteria with which one can choose a particular direction. However, for each of these 9 associations, one can propose a reasonable argument to prefer one association end over the other, which would effectively become derived. A_containedEdge_inGroup (fig 12.10) A_containedNode_inGroup (fig 12.10) All ends are derived unions; none are stored in XMI. A_edge_inPartition (fig 12.10) -- this is clearly a specialization of A_containedEdge_inGroup A_inPartition_node (fig 12.10) -- this is clearly a specialization of A_containedNode_inGroup A_inInterruptibleRegion_node (fig 12.20) -- ditto XMI stores both ends of each association; however, this is clearly redundant. It would suffice, e.g., to store only one end and derive the other end from it; e.g.: ActivityPartition::node => ActivityNode::/inPartition ActivityPartition::edge => ActivityEdge::/inPartition InterruptibleRegion::node => ActivityNode::/inInterruptibleRegion A_generalizationSet_generalization (fig 7.18) Clearly, it makes sense to prefer storing GeneralizationSet::generalization and derive from it Generalization::/generalizationSet A_predecessorClause_successorClause Given the semantics of Clause & ConditionalNode in 12.3.17 & 12.3.18, it is clear that there is a natural direction from a clause to its successor (in the sense of execution) and make the predecessor information derived, i.e.: Clause::successorClause => Clause::/predecessorClause A_subject_useCase Again, following the description of UseCase::subject, it is clear that there is a natural direction from UseCase to Classifier, i.e.: UseCase::subject => Classifier::/useCase Since this particular association seems to be of interest to several people, let me include the description of the association ends. 16.3.2 -- Classifier::useCase [*] The set of use cases for which this Classifier is the subject. 16.3.6 -- UseCase::subject: Classifier[*] References the subjects to which this use case applies. The current association definition gives us two different ways to elaborate a use case model: 1) starting from a Classifier, change the Classifier::useCase property to add/remove use cases. 2) starting from a UseCase, change the UseCase::subject property to add/remove subjects. I can certainly relate to (2) but (1) strikes me as particularly awkward and ill-advised. By making Classifier::/useCase derived, the metamodel would be biased for (2). Tools can certainly implement support for (1) but the metamodel benefits from reduced coupling between Classifier & UseCase and XMI serializations benefit from not having to serialize Classifier::/useCase at all. >From a collaboration point of view, the current state of affairs makes it more difficult for multiple users to collaborate on use case modeling because of the potential conflicts for updating the Classifier::useCase property. - Nicolas. On Sep 10, 2010, at 10:38 AM, Dave Hawkins wrote: > Like Pete, I'm a little perplexed by this issue. Your most recent mail > suggests that the source of the problem is that EMF/UML doesn't handle > opposite properties properly. That would seem to be a tooling issue for > EMF rather than an issue with UML. > > Oracle's MOF implementation effectively acts as Pete describes, although > we don't have direct representation of links; we just keep the ends > updated appropriately. (This does mean we don't support non-unique ends, > which I was under the impression weren't allowed in MOF, but I believe > changed in a recent resolution. I don't really see any value in having > non-unique ends in MOF.) > > Now I can understand if your concern is more about the storage of data. > For example, if you serialise a model into XMI such that linked objects > are stored in separate files with their ends. With both ends storing > semantic data there's a possibility that the files may become out of > sync. This is particularly problematic in a versioned environment. Only > storing one end mitigates that a little as it reduces link validation. > It also means that fewer files will be dirtied as a result of updating > a single link. Is this effectively what you are trying to achieve? > > Cheers, > > Dave > > Rouquette, Nicolas F (316A) wrote: >> Bran, >> >> Indeed, this issue came about from having to clarify how much >> information each binary association really carries. >> 1) are both association ends necessary? >> 2) can we pick any association end arbitrarily and fully derive the >> other association end from it? >> 3) are the options limited to only one association end with which one >> can then fully derive the other association end from it but not the >> other way around? >> >> Metamodel implementations compensate with the help of code generators >> for (1) vs. (2) or (3); however, code generators operate outside the >> scope of the specification so we still need to clarify what really >> determines the collection of links in the association. >> >> For end user models, there is a significant difference between (1) vs. >> (2) or (3). >> >> With (1), if the modeling tool doesn't have support for association >> links in user models (e.g., Eclipse EMF/UML), then this kind of >> association spells all kinds of troubles, particularly if instances are >> involved. >> End user models that have associations with non-unique association ends >> are particularly troublesome as explained in Dragan;s book. >> >> - Nicolas. >> >> On Sep 9, 2010, at 3:09 PM, Bran Selic wrote: >> >>> I think that Ed is right: this may require a metamodel change and may >>> be out of scope for 2.5. >>> >>> However, if I understood Nicolas' intent properly, I fully agree with >>> him that there are many cases where there is an intended >>> directionality to links. This, BTW, is what I called the "Milicev >>> interpretation" of associations, which I see as perfectly valid. It >>> occurs in cases where the association can be viewed as a mapping from >>> a source set (classifier) to a target set (classifier). Such mappings >>> need not always be symmetric. For example, one association end of a >>> binary association may be unique but not its opposite (see issue 6464). >>> >>> You may decide to exclude this interpretation of associations -- >>> although I think that would reduce the expressive power of UML (which >>> I think is Nicolas' point). Whatever the decision, this point should >>> be clarified. >>> >>> Cheers...Bran >>> >>> On Thu, Sep 9, 2010 at 5:40 PM, Ed Seidewitz >> > wrote: >>> >>> Well, since I think what Nicolas is suggesting would require a >>> metamodel change, it would actually be out of scope for the UML >>> 2.5 /spec/ simplification. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> *From:* Pete Rivett [mailto:pete.rivett@adaptive.com >>> ] >>> *Sent:* Thursday, September 09, 2010 5:25 PM >>> *To:* Rouquette, Nicolas F (316A) >>> >>> >>> *Cc:* uml2-rtf@omg.org >>> *Subject:* RE: Semantic directionality (was RE: issue 15449 -- UML >>> 2 RTF issue) >>> >>> >>> >>> I don.t see what.s so special about A_subject_useCase. For example >>> why is A_predecessorClause_successorClause particularly directed? >>> >>> >>> >>> And what is the implication of saying only one end .carries >>> information.: would you make the other .derived. properties (such >>> as V:u in your example) read only? >>> >>> That would IMHO be a huge loss of capability. >>> >>> As I said in my last email,, all UML and MOF semantics are in >>> terms of Links which seem simple and powerful and fundamental >>> (corresponding to tuples or relations in logic). And a lot more >>> open and extensible. >>> >>> >>> >>> I don.t see what.s motivating this: if your aim is simplification >>> it seems more appropriate for the UML 2.5 submission team mailing >>> list. >>> >>> >>> >>> Pete >>> >>> >>> >>> *From:* Rouquette, Nicolas F (316A) >>> [mailto:nicolas.f.rouquette@jpl.nasa.gov >>> ] >>> *Sent:* Thursday, September 09, 2010 1:47 PM >>> *To:* Pete Rivett >>> *Cc:* uml2-rtf@omg.org >>> *Subject:* Re: Semantic directionality (was RE: issue 15449 -- UML >>> 2 RTF issue) >>> >>> >>> >>> You picked the only example of all 9 associations where one can >>> make a reasonable case that the association is truly binary. >>> >>> For the remaining 8 of 9 cases, there is a reasonable way to >>> suggest that there is in fact an intended directionality. >>> >>> For the remaining 409 out of 418 in UML 2.4, the criteria (a) - >>> (e) suffices to give to each association an interpretation as a >>> semantically directed association. >>> >>> >>> >>> For a binary association: u:U -- v:V >>> >>> >>> >>> if v satisfies any of (a)-(e) and u satisfies none of (a)-(e), >>> then the above association is semantically directed: >>> >>> /u:U -> v:V >>> >>> >>> >>> with the derivation for /V:u : U[*] being simply: >>> >>> >>> >>> context V::u : U >>> >>> derive: U.allInstances()->select(u|u.v = self) >>> >>> >>> >>> When the association is truly binary, no such optimization is >>> possible. >>> >>> >>> >>> From a usability point of view, semantically directed associations >>> are easier for users to use because one can explain that we start >>> from the class that owns or is next to the derived end (e.g.,U in >>> the example) and choose value(s) for the end that carries >>> information (e.g., U::v) with the understanding the values of the >>> other end (i.e., /V::u) simply reflect the choices we've made >>> about setting the ends that carry information. >>> >>> >>> >>> From the point of view of integrating models with OWL2 ontologies, >>> semantically directed associations correspond 1-1 to OWL2's >>> OWLObjectProperty where the derived end corresponds to the inverse >>> of the end that carries information. >>> >>> >>> >>> The implication of this criteria is that, except possibly for >>> A_subject_useCase, we can specify the semantics for all or all but >>> one of the 418 associations in UML2.4 with just EMOF without even >>> needing CMOF. That's a simplification in my book! >>> >>> >>> >>> - Nicolas. >>> >>> >>> >>> >>> On Sep 8, 2010, at 3:10 PM, Pete Rivett wrote: >>> >>> >>> >>> I don.t see why lack of .semantic directionality. ( a new concept) >>> has any bearing at all on the effect of changing one end. >>> >>> Or even what semantics are apparently present which does make use >>> of such directionality ­ AFAIK it is not specified in UML or MOF. >>> >>> >>> >>> All the Association semantics (in UML and MOF) are based on Links. >>> Independent of any notion of direction. >>> >>> To take one example, A_subject_useCase, if we have Usecase U1 >>> linked to Class C1 as the subject, then: >>> >>> a) Unsetting U1:subject, or removing C1 from the collection, >>> will delete the link and so C1:useCase becomes unset. And vice >>> versa if C1:useCase is unset >>> >>> b) Adding U2 to C1:useCase will retain the original Link and >>> create an additional link between U2 and C1. >>> So C1:useCase = U1, U2; U1.subject=C1, U2.subject=C1. >>> Similarly if C2 is added to U1:subject >>> >>> c) Setting C1:useCase to U2, U3 will remove any existing >>> links from C1 ­ in this case the link between C1 and U1 >>> >>> >>> >>> There.s an extra complexity if either of the ends is >>> single-valued. If UseCase::subject were [0..1] then in case b) if >>> U2.subject=C2 then that link would be removed >>> >>> >>> >>> >>> Pete >>> >>> >>> >>> *From:* Juergen Boldt [mailto:juergen@omg.org >>> ] >>> *Sent:* Wednesday, September 08, 2010 1:13 PM >>> *To:* issues@omg.org ; uml2-rtf@omg.org >>> >>> *Subject:* issue 15449 -- UML 2 RTF issue >>> >>> >>> >>> >>> >>> From: "Rouquette, Nicolas F (316A)" >>> >> > >>> To: "issues@omg.org " >> > >>> CC: "uml2-rtf@omg.org " >> > >>> Date: Wed, 8 Sep 2010 12:54:00 -0700 >>> Subject: Under-specified associations in UML2.4 & the need for >>> clarifying >>> the semantic directionality for all UML associations. >>> Thread-Topic: Under-specified associations in UML2.4 & the need for >>> clarifying the semantic directionality for all UML associations. >>> Thread-Index: ActPj5VITzBJbewdRMaa3nDRm6JegQ== >>> Accept-Language: en-US >>> X-MS-Has-Attach: >>> X-MS-TNEF-Correlator: >>> acceptlanguage: en-US >>> X-Source-IP: altvirehtstap01.jpl.nasa.gov >>> [128.149.137.72] >>> X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov >>> >>> X-AUTH: Authorized >>> >>> Resolution 14977 cleaned up many association end >>> subsets/redefinitions; in particular, this resolution ensures that >>> if an association end subsets/redefines another, then there is a >>> symmetric subsetting/redefinition of the other end and that the >>> subsetted/redefined ends belong to the same association. >>> >>> Two group of proposed changes were removed from 14977. >>> >>> The first group involves generalization relationships among >>> associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274 >>> Generalization relationships are needed when the semantics of an >>> association whose ends subset/redefine the ends of another >>> association is that the set of links of the former association are >>> necessarily a subset of the links of the latter. Since this isn't >>> necessarily the case, it implies that generalization relationships >>> are needed to clarify this semantic intent as shown in slide 31 of >>> the following UML2.0 >>> presentation: http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf >>> >>> The second group involves associations that are under-specified in >>> the sense that each association: >>> - does not own any end (i.e., both ends are navigable according to >>> 7.3.45) >>> - none of the ends subset/redefine ends of another association >>> that has semantic directionality >>> >>> The criteria for an association to have semantic directionality is: >>> a) one end is navigable; the other isn't >>> b) one end is composite; the other isn't >>> c) one end subsets/redefines another end of an association that is >>> semantically directed; the other doesn't >>> d) one end has required multiplicity (i.e., lower>0); the other is >>> optional (i.e., lower=0) >>> e) one end has bounded multiplicity (i.e., upper>0); the other has >>> unbounded multiplicity (i.e., upper<0) >>> >>> Without semantic directionality, an association owns neither of >>> its member ends and there is no objective criteria to determine >>> what effect changing one association end can/should/may have on >>> changes to the other end, if any. >>> >>> In UML2.4, there are 9 associations that fail all of (a) through (e): >>> [qvto:transformation] A_containedEdge_inGroup >>> [qvto:transformation] A_containedNode_inGroup >>> [qvto:transformation] A_covered_coveredBy >>> [qvto:transformation] A_edge_inPartition >>> [qvto:transformation] A_generalizationSet_generalization >>> [qvto:transformation] A_inInterruptibleRegion_node >>> [qvto:transformation] A_inPartition_node >>> [qvto:transformation] A_predecessorClause_successorClause >>> [qvto:transformation] A_subject_useCase >>> >>> 19 associations satisfy (a), (b), (c) but fail either (d) and (e): >>> >>> [qvto:transformation] A_before_toAfter >>> [qvto:transformation] >>> A_classifier_templateParameter_parameteredElement >>> [qvto:transformation] >>> A_connectableElement_templateParameter_parameteredElement >>> [qvto:transformation] A_end_role >>> [qvto:transformation] A_extension_metaclass >>> [qvto:transformation] A_incoming_target_node >>> [qvto:transformation] A_incoming_target_vertex >>> [qvto:transformation] A_inputElement_regionAsInput >>> [qvto:transformation] A_interruptingEdge_interrupts >>> [qvto:transformation] A_method_specification >>> [qvto:transformation] >>> A_operation_templateParameter_parameteredElement >>> [qvto:transformation] A_outgoing_source_node >>> [qvto:transformation] A_outgoing_source_vertex >>> [qvto:transformation] A_outputElement_regionAsOutput >>> [qvto:transformation] A_parameterSet_parameter >>> [qvto:transformation] A_parameteredElement_templateParameter >>> [qvto:transformation] A_powertypeExtent_powertype >>> [qvto:transformation] A_submachineState_submachine >>> [qvto:transformation] A_toBefore_after >>> >>> All 28 cases above correspond to associations that, while >>> well-formed in the metamodel according to 14977 & other applicable >>> resolutions, are under-specified in the specification in the sense >>> that there is a reasonable interpretation where each association >>> has a natural direction, either because of cardinality >>> restrictions (i.e., (d) or (e) would suffice to give direction to >>> the 19 associations above) or because there is insufficient >>> application of the architecture principles for OMG metamodels >>> (e.g., incomplete modeling of ownership in most of the cases for >>> the first group of 9 association). >>> >>> The consequence for end users is that each of the 28 associations >>> represents a source of modeling errors unless tool implementations >>> choose to implement these associations in a non-standard way, >>> e.g., by ascribing a sensible semantics to these associations that >>> removes the ambiguity about which end can be changed independently >>> of the other end -- i.e., the association is semantically directed >>> in that one end can be logically derived from the other end. >>> >>> - Nicolas. >>> >>> >>> >>> * >>> >>> 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 >>> >>> *[] >>> >>> >>> >>> >>> >>> >> > > -- > 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. Subject: RE: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Date: Sat, 11 Sep 2010 08:36:35 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Thread-Index: ActRUgskvaDw7pOjTqy/o2fQoq3RbAAcWCuA From: "Pete Rivett" To: "Rouquette, Nicolas F (316A)" , "Dave Hawkins" Cc: "Bran Selic" , "Ed Seidewitz" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o8BFIEiP017989 Don't forget that the I in XMI is for Interchange - do not confuse XMI with a storage or repository mechanism. Moreover one cannot presume how a model might be partitioned for storage, management, ownership or versioning purposes. Pete -----Original Message----- From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, September 10, 2010 6:39 PM To: Dave Hawkins Cc: Bran Selic; Ed Seidewitz; Pete Rivett; uml2-rtf@omg.org Subject: Re: Semantic directionality (was RE: issue 15449 -- UML 2 RTF issue) Dave, I'll only focus on the issue as reported. The underlying problem has a relation to storage, e.g., XMI, where the XMI serialization rules apply similar criteria to decide whether an association end carries essential information that must be serialized or not. Example of an association that is already semantically directed in the metamodel: A_redefinedProperty_property (fig 7.12) -- according to (a) it is directed. Indeed, we only store the Property::redefinedProperty end in XMI. Example of one of the 19 association that is currently not semantically directed but could be: A_outgoing_source_node (fig 12.5) --according to (d), it is directed; it would be sufficient to store just the information in ActivityEdge::source and we could derive the information in ActivityNode::outgoing from all edges in the activity. In fact, there is very little difference between this association and the one below where, thanks to one end being derived, the directionality is reflected in the XMI serialization. A_outgoing_source_vertex (fig. 15.2) -- according to (d) and (a), it is directed; indeed, XMI doesn't even store derived properties; we only store Transition::source. The point of this issue is that the modeling of associations is done sub-optimally w.r.t. what the associations really mean. If we examined each of the 19 associations, it is easy to conclude that the association is semantically directed in the sense that only one of the association ends matters for serialization and for model construction. The other end is important but it can be derived from the first. The first group of 9 associations is different in that there is no obvious criteria with which one can choose a particular direction. However, for each of these 9 associations, one can propose a reasonable argument to prefer one association end over the other, which would effectively become derived. A_containedEdge_inGroup (fig 12.10) A_containedNode_inGroup (fig 12.10) All ends are derived unions; none are stored in XMI. A_edge_inPartition (fig 12.10) -- this is clearly a specialization of A_containedEdge_inGroup A_inPartition_node (fig 12.10) -- this is clearly a specialization of A_containedNode_inGroup A_inInterruptibleRegion_node (fig 12.20) -- ditto XMI stores both ends of each association; however, this is clearly redundant. It would suffice, e.g., to store only one end and derive the other end from it; e.g.: ActivityPartition::node => ActivityNode::/inPartition ActivityPartition::edge => ActivityEdge::/inPartition InterruptibleRegion::node => ActivityNode::/inInterruptibleRegion A_generalizationSet_generalization (fig 7.18) Clearly, it makes sense to prefer storing GeneralizationSet::generalization and derive from it Generalization::/generalizationSet A_predecessorClause_successorClause Given the semantics of Clause & ConditionalNode in 12.3.17 & 12.3.18, it is clear that there is a natural direction from a clause to its successor (in the sense of execution) and make the predecessor information derived, i.e.: Clause::successorClause => Clause::/predecessorClause A_subject_useCase Again, following the description of UseCase::subject, it is clear that there is a natural direction from UseCase to Classifier, i.e.: UseCase::subject => Classifier::/useCase Since this particular association seems to be of interest to several people, let me include the description of the association ends. 16.3.2 -- Classifier::useCase [*] The set of use cases for which this Classifier is the subject. 16.3.6 -- UseCase::subject: Classifier[*] References the subjects to which this use case applies. The current association definition gives us two different ways to elaborate a use case model: 1) starting from a Classifier, change the Classifier::useCase property to add/remove use cases. 2) starting from a UseCase, change the UseCase::subject property to add/remove subjects. I can certainly relate to (2) but (1) strikes me as particularly awkward and ill-advised. By making Classifier::/useCase derived, the metamodel would be biased for (2). Tools can certainly implement support for (1) but the metamodel benefits from reduced coupling between Classifier & UseCase and XMI serializations benefit from not having to serialize Classifier::/useCase at all. >From a collaboration point of view, the current state of affairs makes it more difficult for multiple users to collaborate on use case modeling because of the potential conflicts for updating the Classifier::useCase property. - Nicolas. On Sep 10, 2010, at 10:38 AM, Dave Hawkins wrote: > Like Pete, I'm a little perplexed by this issue. Your most recent mail > suggests that the source of the problem is that EMF/UML doesn't handle > opposite properties properly. That would seem to be a tooling issue > for EMF rather than an issue with UML. > > Oracle's MOF implementation effectively acts as Pete describes, > although we don't have direct representation of links; we just keep > the ends updated appropriately. (This does mean we don't support > non-unique ends, which I was under the impression weren't allowed in > MOF, but I believe changed in a recent resolution. I don't really see > any value in having non-unique ends in MOF.) > > Now I can understand if your concern is more about the storage of data. > For example, if you serialise a model into XMI such that linked > objects are stored in separate files with their ends. With both ends > storing semantic data there's a possibility that the files may become > out of sync. This is particularly problematic in a versioned > environment. Only storing one end mitigates that a little as it reduces link validation. > It also means that fewer files will be dirtied as a result of updating > a single link. Is this effectively what you are trying to achieve? > > Cheers, > > Dave > > Rouquette, Nicolas F (316A) wrote: >> Bran, >> >> Indeed, this issue came about from having to clarify how much >> information each binary association really carries. >> 1) are both association ends necessary? >> 2) can we pick any association end arbitrarily and fully derive the >> other association end from it? >> 3) are the options limited to only one association end with which one >> can then fully derive the other association end from it but not the >> other way around? >> >> Metamodel implementations compensate with the help of code generators >> for (1) vs. (2) or (3); however, code generators operate outside the >> scope of the specification so we still need to clarify what really >> determines the collection of links in the association. >> >> For end user models, there is a significant difference between (1) vs. >> (2) or (3). >> >> With (1), if the modeling tool doesn't have support for association >> links in user models (e.g., Eclipse EMF/UML), then this kind of >> association spells all kinds of troubles, particularly if instances >> are involved. >> End user models that have associations with non-unique association >> ends are particularly troublesome as explained in Dragan;s book. >> >> - Nicolas. >> >> On Sep 9, 2010, at 3:09 PM, Bran Selic wrote: >> >>> I think that Ed is right: this may require a metamodel change and >>> may be out of scope for 2.5. >>> >>> However, if I understood Nicolas' intent properly, I fully agree >>> with him that there are many cases where there is an intended >>> directionality to links. This, BTW, is what I called the "Milicev >>> interpretation" of associations, which I see as perfectly valid. It >>> occurs in cases where the association can be viewed as a mapping >>> from a source set (classifier) to a target set (classifier). Such >>> mappings need not always be symmetric. For example, one association >>> end of a binary association may be unique but not its opposite (see issue 6464). >>> >>> You may decide to exclude this interpretation of associations -- >>> although I think that would reduce the expressive power of UML >>> (which I think is Nicolas' point). Whatever the decision, this point >>> should be clarified. >>> >>> Cheers...Bran >>> >>> On Thu, Sep 9, 2010 at 5:40 PM, Ed Seidewitz >> > wrote: >>> >>> Well, since I think what Nicolas is suggesting would require a >>> metamodel change, it would actually be out of scope for the UML >>> 2.5 /spec/ simplification... >>> >>> >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> *From:* Pete Rivett [mailto:pete.rivett@adaptive.com >>> ] >>> *Sent:* Thursday, September 09, 2010 5:25 PM >>> *To:* Rouquette, Nicolas F (316A) >>> >>> >>> *Cc:* uml2-rtf@omg.org >>> *Subject:* RE: Semantic directionality (was RE: issue 15449 -- UML >>> 2 RTF issue) >>> >>> >>> >>> I don't see what's so special about A_subject_useCase. For example >>> why is A_predecessorClause_successorClause particularly directed? >>> >>> >>> >>> And what is the implication of saying only one end 'carries >>> information': would you make the other 'derived' properties (such >>> as V:u in your example) read only? >>> >>> That would IMHO be a huge loss of capability. >>> >>> As I said in my last email,, all UML and MOF semantics are in >>> terms of Links which seem simple and powerful and fundamental >>> (corresponding to tuples or relations in logic). And a lot more >>> open and extensible. >>> >>> >>> >>> I don't see what's motivating this: if your aim is simplification >>> it seems more appropriate for the UML 2.5 submission team mailing >>> list. >>> >>> >>> >>> Pete >>> >>> >>> >>> *From:* Rouquette, Nicolas F (316A) >>> [mailto:nicolas.f.rouquette@jpl.nasa.gov >>> ] >>> *Sent:* Thursday, September 09, 2010 1:47 PM >>> *To:* Pete Rivett >>> *Cc:* uml2-rtf@omg.org >>> *Subject:* Re: Semantic directionality (was RE: issue 15449 -- UML >>> 2 RTF issue) >>> >>> >>> >>> You picked the only example of all 9 associations where one can >>> make a reasonable case that the association is truly binary. >>> >>> For the remaining 8 of 9 cases, there is a reasonable way to >>> suggest that there is in fact an intended directionality. >>> >>> For the remaining 409 out of 418 in UML 2.4, the criteria (a) - >>> (e) suffices to give to each association an interpretation as a >>> semantically directed association. >>> >>> >>> >>> For a binary association: u:U -- v:V >>> >>> >>> >>> if v satisfies any of (a)-(e) and u satisfies none of (a)-(e), >>> then the above association is semantically directed: >>> >>> /u:U -> v:V >>> >>> >>> >>> with the derivation for /V:u : U[*] being simply: >>> >>> >>> >>> context V::u : U >>> >>> derive: U.allInstances()->select(u|u.v = self) >>> >>> >>> >>> When the association is truly binary, no such optimization is >>> possible. >>> >>> >>> >>> From a usability point of view, semantically directed associations >>> are easier for users to use because one can explain that we start >>> from the class that owns or is next to the derived end (e.g.,U in >>> the example) and choose value(s) for the end that carries >>> information (e.g., U::v) with the understanding the values of the >>> other end (i.e., /V::u) simply reflect the choices we've made >>> about setting the ends that carry information. >>> >>> >>> >>> From the point of view of integrating models with OWL2 ontologies, >>> semantically directed associations correspond 1-1 to OWL2's >>> OWLObjectProperty where the derived end corresponds to the inverse >>> of the end that carries information. >>> >>> >>> >>> The implication of this criteria is that, except possibly for >>> A_subject_useCase, we can specify the semantics for all or all but >>> one of the 418 associations in UML2.4 with just EMOF without even >>> needing CMOF. That's a simplification in my book! >>> >>> >>> >>> - Nicolas. >>> >>> >>> >>> >>> On Sep 8, 2010, at 3:10 PM, Pete Rivett wrote: >>> >>> >>> >>> I don't see why lack of 'semantic directionality' ( a new concept) >>> has any bearing at all on the effect of changing one end. >>> >>> Or even what semantics are apparently present which does make use >>> of such directionality - AFAIK it is not specified in UML or MOF. >>> >>> >>> >>> All the Association semantics (in UML and MOF) are based on Links. >>> Independent of any notion of direction. >>> >>> To take one example, A_subject_useCase, if we have Usecase U1 >>> linked to Class C1 as the subject, then: >>> >>> a) Unsetting U1:subject, or removing C1 from the collection, >>> will delete the link and so C1:useCase becomes unset. And vice >>> versa if C1:useCase is unset >>> >>> b) Adding U2 to C1:useCase will retain the original Link and >>> create an additional link between U2 and C1. >>> So C1:useCase = U1, U2; U1.subject=C1, U2.subject=C1. >>> Similarly if C2 is added to U1:subject >>> >>> c) Setting C1:useCase to U2, U3 will remove any existing >>> links from C1 - in this case the link between C1 and U1 >>> >>> >>> >>> There's an extra complexity if either of the ends is >>> single-valued. If UseCase::subject were [0..1] then in case b) if >>> U2.subject=C2 then that link would be removed >>> >>> >>> >>> >>> Pete >>> >>> >>> >>> *From:* Juergen Boldt [mailto:juergen@omg.org >>> ] >>> *Sent:* Wednesday, September 08, 2010 1:13 PM >>> *To:* issues@omg.org ; uml2-rtf@omg.org >>> >>> *Subject:* issue 15449 -- UML 2 RTF issue >>> >>> >>> >>> >>> >>> From: "Rouquette, Nicolas F (316A)" >>> >> > >>> To: "issues@omg.org " >> > >>> CC: "uml2-rtf@omg.org " >> > >>> Date: Wed, 8 Sep 2010 12:54:00 -0700 >>> Subject: Under-specified associations in UML2.4 & the need for >>> clarifying >>> the semantic directionality for all UML associations. >>> Thread-Topic: Under-specified associations in UML2.4 & the need for >>> clarifying the semantic directionality for all UML associations. >>> Thread-Index: ActPj5VITzBJbewdRMaa3nDRm6JegQ== >>> Accept-Language: en-US >>> X-MS-Has-Attach: >>> X-MS-TNEF-Correlator: >>> acceptlanguage: en-US >>> X-Source-IP: altvirehtstap01.jpl.nasa.gov >>> [128.149.137.72] >>> X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov >>> >>> X-AUTH: Authorized >>> >>> Resolution 14977 cleaned up many association end >>> subsets/redefinitions; in particular, this resolution ensures that >>> if an association end subsets/redefines another, then there is a >>> symmetric subsetting/redefinition of the other end and that the >>> subsetted/redefined ends belong to the same association. >>> >>> Two group of proposed changes were removed from 14977. >>> >>> The first group involves generalization relationships among >>> associations: http://www.omg.org/issues/uml2-rtf.open.html#Issue15274 >>> Generalization relationships are needed when the semantics of an >>> association whose ends subset/redefine the ends of another >>> association is that the set of links of the former association are >>> necessarily a subset of the links of the latter. Since this isn't >>> necessarily the case, it implies that generalization relationships >>> are needed to clarify this semantic intent as shown in slide 31 of >>> the following UML2.0 >>> presentation: >>> http://www.omg.org/members/cgi-bin/doc?omg/04-05-01.pdf >>> >>> The second group involves associations that are under-specified in >>> the sense that each association: >>> - does not own any end (i.e., both ends are navigable according to >>> 7.3.45) >>> - none of the ends subset/redefine ends of another association >>> that has semantic directionality >>> >>> The criteria for an association to have semantic directionality is: >>> a) one end is navigable; the other isn't >>> b) one end is composite; the other isn't >>> c) one end subsets/redefines another end of an association that is >>> semantically directed; the other doesn't >>> d) one end has required multiplicity (i.e., lower>0); the other is >>> optional (i.e., lower=0) >>> e) one end has bounded multiplicity (i.e., upper>0); the other has >>> unbounded multiplicity (i.e., upper<0) >>> >>> Without semantic directionality, an association owns neither of >>> its member ends and there is no objective criteria to determine >>> what effect changing one association end can/should/may have on >>> changes to the other end, if any. >>> >>> In UML2.4, there are 9 associations that fail all of (a) through (e): >>> [qvto:transformation] A_containedEdge_inGroup >>> [qvto:transformation] A_containedNode_inGroup >>> [qvto:transformation] A_covered_coveredBy >>> [qvto:transformation] A_edge_inPartition >>> [qvto:transformation] A_generalizationSet_generalization >>> [qvto:transformation] A_inInterruptibleRegion_node >>> [qvto:transformation] A_inPartition_node >>> [qvto:transformation] A_predecessorClause_successorClause >>> [qvto:transformation] A_subject_useCase >>> >>> 19 associations satisfy (a), (b), (c) but fail either (d) and (e): >>> >>> [qvto:transformation] A_before_toAfter >>> [qvto:transformation] >>> A_classifier_templateParameter_parameteredElement >>> [qvto:transformation] >>> A_connectableElement_templateParameter_parameteredElement >>> [qvto:transformation] A_end_role >>> [qvto:transformation] A_extension_metaclass >>> [qvto:transformation] A_incoming_target_node >>> [qvto:transformation] A_incoming_target_vertex >>> [qvto:transformation] A_inputElement_regionAsInput >>> [qvto:transformation] A_interruptingEdge_interrupts >>> [qvto:transformation] A_method_specification >>> [qvto:transformation] >>> A_operation_templateParameter_parameteredElement >>> [qvto:transformation] A_outgoing_source_node >>> [qvto:transformation] A_outgoing_source_vertex >>> [qvto:transformation] A_outputElement_regionAsOutput >>> [qvto:transformation] A_parameterSet_parameter >>> [qvto:transformation] A_parameteredElement_templateParameter >>> [qvto:transformation] A_powertypeExtent_powertype >>> [qvto:transformation] A_submachineState_submachine >>> [qvto:transformation] A_toBefore_after >>> >>> All 28 cases above correspond to associations that, while >>> well-formed in the metamodel according to 14977 & other applicable >>> resolutions, are under-specified in the specification in the sense >>> that there is a reasonable interpretation where each association >>> has a natural direction, either because of cardinality >>> restrictions (i.e., (d) or (e) would suffice to give direction to >>> the 19 associations above) or because there is insufficient >>> application of the architecture principles for OMG metamodels >>> (e.g., incomplete modeling of ownership in most of the cases for >>> the first group of 9 association). >>> >>> The consequence for end users is that each of the 28 associations >>> represents a source of modeling errors unless tool implementations >>> choose to implement these associations in a non-standard way, >>> e.g., by ascribing a sensible semantics to these associations that >>> removes the ambiguity about which end can be changed independently >>> of the other end -- i.e., the association is semantically directed >>> in that one end can be logically derived from the other end. >>> >>> - Nicolas. >>> >>> >>> >>> * >>> >>> 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 >>> >>> *[] >>> >>> >>> >>> >>> >>> >> > > -- > 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. - Nicolas.