Issue 5802: 2.5.2.15 Dependency (uml2-superstructure-ftf) Source: (Mr. Jeffrey Barnes, jbarnesweb(at)yahoo.com) Nature: Clarification Severity: Minor Summary: The text "client The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements." disagrees with the 1..* cardinality on the client association end of the association between Dependency and ModelElement (Figure 2-7 on page 2-15). The same issue applies to the supplier association end and its documentation. Resolution: see above and below - resolved Revised Text: Associations • client: NamedElement [1..*] The element(s) dependent on the supplier element(s). In some cases (such as a Trace Abstraction) the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler, and is a stipulation. • supplier: NamedElement [1..*] The element(s) independent of the client element(s), in the same respect and in the same dependency relationship. In some directed dependency relationships (such as Refinement Abstractions), a common convention in the domain of class-based OO software is to put the more abstract element in this role. Despite this convention, users of UML 2 may stipulate a sense of dependency suitable for their domain, which makes a more abstract element dependent on that which is more specific. Actions taken: December 19, 2002: received issue March 8, 2005: closed issue Discussion: In the FAS, the relevant figure was renumbered as 51, and the section from which the quoted text comes is 7.14.3, page 108 as printed, 122 in pdf electronic form . The full text in context from page 108(122) is: Associations • client: NamedElement [1..*] The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements. • supplier: NamedElement [1..*] Designates the element that is unaffected by a change. In a twoway relationship (such as some Refinement Abstractions) this would be the more general element. In an undirected situation, such as a Trace Abstraction, the choice of client and supplier is not relevant. There is indeed a disagreement between the text and the multiplicity. The text for both client and supplier must be in the plural, since the same dependency may have many clients and/or many suppliers. An alternative solution would be to decide that the multiplicity in the diagram is at fault, and that every Dependency Relationship is binary, with exactly one client and exactly one supplier, but this does not seem to be the intent of the metamodel, so we propose changing the nouns to allow a plural form. This one change is sufficient to address the issue, but examination of the text quoted above reveals other significant defects. Another defect in the text is the unexplained switch in terminology between the texts defining client and the text defining supplier. In one case, the other element is what does or does not affect, and in the other case it is a “change”, with no indication of what the change is. Since there is no “change” identified in the context, this second definition is the defective one. A third defect is the affront to logic involved in three asseritions that contradict the premise that directed dependency relationships are being defined. These confused and inconsistent assertions are: 1) that “… undirected situations” can arise in a directed dependency relationship, and 2) that “… the choice of client does not matter” in a relationship In which the client is the role of the element(s) that are affected by the other, and the supplier(s) are the element(s) that are not affected. There is also confusion of the text in its 3) assertion that directed dependency relationships include “two-way” relationships. Assertions such as these, if allowed to stand, may bring the specification into disrepute. It has been many centuries since the logic of relations differentiated symmetric relationships. No Directed Dependency is symmetric, and all are transitive, which the assertion that some are “two-way” appears to contradict. Two way relationships are symmetric, and directed dependency is most certainly not symmetric. Two one-way relationships do not automatically make one two-way. Obviously, a client who is dependent on a supplier in one respect, may also be a supplier with respect to that other in some other respect, but this does not make a directed dependency relationship symmetric. In such cases there are two dependency relationships, based on different semantic criteria, not one “two-way” symmetric dependency. The resolution is to rewrite the quoted text (see above, from page 108/122) as shown below End of Annotations:===== From: webmaster@omg.org Date: 19 Dec 2002 12:02:14 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Jeff Barnes Company: ManaSoft mailFrom: jeff.barnes@mnsft.com Notification: Yes Specification: Unified Modeling Language (UMLDependency FormalNumber: formal/2001-09-67 Version: 1.4 RevisionDate: September 2001 Page: 2-34 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; YComp 5.0.0.0; .NET CLR 1.0.3705) Description The text "client The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements." disagrees with the 1..* cardinality on the client association end of the association between Dependency and ModelElement (Figure 2-7 on page 2-15). The same issue applies to the supplier association end and its OMG Issue No: 5802 Title: 2.5.2.15 Dependency Source: ManaSoft (Mr. Jeff Barnes, jeff.barnes@mnsft.com) Summary: The text "client The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements." disagrees with the 1..* cardinality on the client association end of the association between Dependency and ModelElement (Figure 2-7 on page 2-15). The same issue applies to the supplier association end and its documentation. Discussion: Proposed Resolution: In section 7.14.3 Dependency of the final adopted spec under "Associations" heading, 1. Change the cited text for client by replacing the word "unimportant" with the words "at the discretion of the modeler". 2. Change the text for supplier:NamedElement [1..*], by replacing the concluding sentence "In an undirected situation, such as a Trace Abstraction, the choice of client and supplier is not relevant." with the sentence, "The choice of client and supplier ends in Dependency relationships may sometimes be at the discretion of the modeler, but consistency with the generalization DirectedRelationship requires that client and supplier ends always be distinguished." Discussion: The assertion that a subtype of DirectedRelationship is an undirected situation is inconsistent with the meaning of subtyping, and is easily corrected with a local change in wording. Even our standard arrow notation for Dependency makes the statements that direction is "not relevant" and "unimportant" undesirable. Disposition: Unresolved OMG Issue No: 5802 Title: 2.5.2.15 Dependency Source: ManaSoft (Mr. Jeff Barnes, jeff.barnes@mnsft.com) Summary: The text "client The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements." disagrees with the 1..* cardinality on the client association end of the association between Dependency and ModelElement (Figure 2-7 on page 2-15). The same issue applies to the supplier association end and its documentation. Discussion: Proposed Resolution: In section 7.14.3 Dependency of the final adopted spec under "Associations" heading, 1. Change the cited text for client by replacing the word "unimportant" with the words "at the discretion of the modeler". 2. Change the text for supplier:NamedElement [1..*], by replacing the concluding sentence "In an undirected situation, such as a Trace Abstraction, the choice of client and supplier is not relevant." with the sentence, "The choice of client and supplier ends in Dependency relationships may sometimes be at the discretion of the modeler, but consistency with the generalization DirectedRelationship requires that client and supplier ends always be distinguished." Discussion: The assertion that a subtype of DirectedRelationship is an undirected situation is inconsistent with the meaning of subtyping, and is easily corrected with a local change in wording. Even our standard arrow notation for Dependency makes the statements that direction is "not relevant" and "unimportant" undesirable. BRAN: First of all, the issue description is incorrect. There is no disagreement with the cardinality because the lower bound of 1 for both multiplicities is simply saying that all dependencies must have at least one source element and one client element. A dependency that does not have anything attached to one or the other end is not meaningful. Second, I agree that some further clarification is required here. I don.t think that there is ever a case where the direction does not matter (i.e., is irrelevant), but that there may be cases where the dependency is bi-directional (not at all the same as undirected . as we found out with navigability). I think that this clarification belongs in the Semantics section of Dependency rather than in the descriptions of the .client. and .supplier. roles because it is an overarching discussion that applies to both items. In fact, it probably would have been better to call the roles .origin. and .end., which are merely geometric designations, and are less likely to be misinterpreted semantically. (I have seen several specializations of Dependency where the terms .client. and .supplier. are actually the inverse of what the semantics of the dependency would suggest.) I would like to keep this one open until we get more discussion on it. Disposition: Unresolved Subject: RE: ,cb cs,One Proposed resolution for 15 Date: Sun, 23 May 2004 21:40:10 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ,cb cs,One Proposed resolution for 15 Thread-Index: AcRBLYHWfAS8xv8UTO2S248kdv2d/AAADJPA From: "Karl Frank" To: "Branislav Selic" Cc: X-OriginalArrivalTime: 24 May 2004 01:40:11.0820 (UTC) FILETIME=[0DC0EEC0:01C44130] The attached is just one issue, but it may be problematic, as it proposes to go beyond the particular issue and fix other defects in the same text that the issue was raised against. - Karl Frank (in Pacific time zone for this week) BallotClasses5802.doc OMG Issue No: 5802 Title: 2.5.2.15 Dependency Source: ManaSoft (Mr. Jeff Barnes, jeff.barnes@mnsft.com) Summary: The text "client The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements." disagrees with the 1..* cardinality on the client association end of the association between Dependency and ModelElement (Figure 2-7 on page 2-15). The same issue applies to the supplier association end and its documentation. Discussion: In the FAS, the relevant figure was renumbered as 51, and the section from which the quoted text comes is 7.14.3, page 108 as printed, 122 in pdf electronic form . The full text in context from page 108(122) is: Associations . client: NamedElement [1..*] The element that is affected by the supplier element. In some cases (such as a Trace Abstraction) the direction is unimportant and serves only to distinguish the two elements. . supplier: NamedElement [1..*] Designates the element that is unaffected by a change. In a two-way relationship (such as some Refinement Abstractions) this would be the more general element. In an undirected situation, such as a Trace Abstraction, the choice of client and supplier is not relevant. There is indeed a disagreement between the text and the multiplicity. The text for both client and supplier must be in the plural, since the same dependency may have many clients and/or many suppliers. An alternative solution would be to decide that the multiplicity in the diagram is at fault, and that every Dependency Relationship is binary, with exactly one client and exactly one supplier, but this does not seem to be the intent of the metamodel, so we propose changing the nouns to allow a plural form. This one change is sufficient to address the issue, but examination of the text quoted above reveals other significant defects. Another defect in the text is the unexplained switch in terminology between the texts defining client and the text defining supplier. In one case, the other element is what does or does not affect, and in the other case it is a .change., with no indication of what the change is. Since there is no .change. identified in the context, this second definition is the defective one. A third defect is the affront to logic involved in three asseritions that contradict the premise that directed dependency relationships are being defined. These confused and inconsistent assertions are: 1) that .. undirected situations. can arise in a directed dependency relationship, and 2) that .. the choice of client does not matter. in a relationship In which the client is the role of the element(s) that are affected by the other, and the supplier(s) are the element(s) that are not affected. There is also evident confusion of the text in its 3) assertion that directed dependency relationships incllude .two-way. relationships. Two way relationships are symmetric, and directed dependency is most certainly not symmetric. Assertions such as these, if allowed to stand, may bring the specification into disrepute. It has been many centuries since the logic of relations differentiated symmetric relationships. No Directed Dependency is symmetric, and all are transitive, which the assertion that some are .two-way. appears to contradict. Obviously, a client who is dependent on a supplier in one respect, may also be a supplier with respect to that other in some other respect, but this does not make a directed dependency relationship symmetric. In such cases there are two dependency relationships, based on different semantic criteria, not one .two-way. symmetric dependency. The resolution is to rewrite the quoted text (see above, from page 108/122) as shown below Revised Text Associations . client: NamedElement [1..*] The element(s) dependent on the supplier element(s). In some cases (such as a Trace Abstraction) the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler, and is a stipulation. . supplier: NamedElement [1..*] The element(s) independent of the client element(s), in the same respect and in the same dependency relationship. In some directed dependency relationships (such as Refinement Abstractions), a common convention in the domain of class-based OO software is to put the more general element in this role because of inheritance issues. However, other domains may consider generalizations to be derived from and therefore dependent on, that which is more specific. Real-world modeling and object based programming are examples of such domains, in which many practioners regard the general as derived from and dependentant on the specific cases. In some specializations of Dependency, such as a Trace Abstraction, the choice of client and supplier is stipulated by the model. Disposition: Resolved To: "Karl Frank" Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,cb cs,One Proposed resolution for 15 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 24 May 2004 15:15:41 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/24/2004 15:16:11 Karl, This is good, but I have one minor nit, that I hope will be easy to fix: In your discussion there is a bit about generalization that I think should be removed. While correct, it leaves the impression that generalization is somehow related to the notion of Dependency in UML -- which is not the case. Thanks, Bran "Karl Frank" 05/23/2004 09:40 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: ,cb cs,One Proposed resolution for 15 The attached is just one issue, but it may be problematic, as it proposes to go beyond the particular issue and fix other defects in the same text that the issue was raised against. - Karl Frank (in Pacific time zone for this week) Subject: RE: ,cb cs,One Proposed resolution for 15 Date: Mon, 24 May 2004 20:20:46 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ,cb cs,One Proposed resolution for 15 Thread-Index: AcRBw6eledUBJf3xSpWQl0X2RC5PeQAJRNrA From: "Karl Frank" To: "Branislav Selic" Cc: X-OriginalArrivalTime: 25 May 2004 00:20:48.0416 (UTC) FILETIME=[20F4EA00:01C441EE] The mention of "the more general element" being the supplier in dependency originate in the FAS current text that issue 5802 was raised against. I agree that it is troublesome, and in my proposed revision (see the attached V2) I have used the terminology of the "more abstract" element instead. The point of that bit in the text seems to be to acknowledge a common practice with respect to refinement of viewing the more detailed model element as being somehow methodologically derived from and the less detailed. How do people feel about the attached revision? - karl -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, 24 May, 2004 12:16 PM To: Karl Frank Cc: uml2-superstructure-ftf@omg.org Subject: RE: ,cb cs,One Proposed resolution for 15 Karl, This is good, but I have one minor nit, that I hope will be easy to fix: In your discussion there is a bit about generalization that I think should be removed. While correct, it leaves the impression that generalization is somehow related to the notion of Dependency in UML -- which is not the case. Thanks, Bran "Karl Frank" 05/23/2004 09:40 PM To Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: ,cb cs,One Proposed resolution for 15 The attached is just one issue, but it may be problematic, as it proposes to go beyond the particular issue and fix other defects in the same text that the issue was raised against. - Karl Frank (in Pacific time zone for this week) documentation.