Issue 6173: 7.14.1 Abstraction (uml2-superstructure-ftf) Source: SSA (Mr. Arthur Culbertson, nobody) Nature: Uncategorized Issue Severity: Summary: Examples The dependency arrow should be reversed in Figure 52. The client should be the element that is more developed (i.e., Employee Record) and supplier should be the element that is the base for refinement (i.e., Employee). This is analogous to realization where the supplier is the specification and the client the implementation. Resolution: see above Revised Text: Actions taken: September 3, 2003: received issue March 8, 2005: closed issue Discussion: The Figure 52 in question is on page 108 of the FAS as printed, page 123 in the electronic pdf pagination, at the end of section 7.14.1 Abstraction. This figure shows a dashed arrow with a stereotype <<refine>> pointing from the Employee, stereotyped as <<type>> as client to the Employee Record, stereotyped as <<implemention class>> as supplier. Remove the example figure 52. Do not replace, reposition it or fix it. The context for this resolution includes the definition of the client and supplier roles in a directed dependency. That definition states that the choice of client and supplier can be stipulated by the modeler, and is not predetermined by a standard semantic for dependency. In fact, the FAS goes so far as to say that the choice of direction “doesn’t matter”. We (various members of the FTF) have tried to come up with a better example, and found that it is difficult to agree on a good one, because in fact clever people can think of some respects in which A is dependent on B, and also other respects in which B is dependent on A, for the same A and B. The authors of this proposed resolution agree (in part) with Mr. Arthur Culbertson about this figure. We too would have put the EmployeeRecord in the role of that which refines and depends upon the type Employee. The fact that the original author of this example had it the other way around proves the point that the choice of direction can be an arbitrary stipulation of the modeler, and in that case there is NOTHING to be gained by putting in an example. End of Annotations:===== From: "Culbertson, Arthur" To: "'issues@omg.org'" , "'uml2-superstructure-ftf@omg.org'" Subject: UML 2.0 Superstructure Issues (Part I -Structure) Date: Wed, 3 Sep 2003 10:43:47 -0400 X-Mailer: Internet Mail Service (5.5.2654.52) Dear Sirs: The following are some potential issues that I have found while reviewing Part I - Structure portion of the UML 2.0 Superstructure Specification (document pct/03-08-02) dated August 2003. As some of these issues could impact performance on the UML certification exams, I would appreciate feedback as soon as possible. 6) 7.14.1 Abstraction Examples The dependency arrow should be reversed in Figure 52. The client should be the element that is more developed (i.e., Employee Record) and supplier should be the element that is the base for refinement (i.e., Employee). This is analogous to realization where the supplier is the specification and the client the implementation. OMG Issue No: 6173 Title: 7.14.1 Abstraction Source: Lockheed Martin (Mr. Arthur Culbertson, arthur.culbertson@ssa.gov) Summary: Examples The dependency arrow should be reversed in Figure 52. The client should be the element that is more developed (i.e., Employee Record) and supplier should be the element that is the base for refinement (i.e., Employee). This is analogous to realization where the supplier is the specification and the client the implementation. Discussion: Proposed Resolution: Remove Figure 52 A bad example is worse than no example. As the example is non-normative, the effort to find and agree upon a good example is not worth the effort in the current FTF context. Whoever created this example will probably resist changing it and the simple removal of the example will occasion less delay. Disposition: Unresolved :wq OMG Issue No: 6173 Title: 7.14.1 Abstraction Source: Lockheed Martin (Mr. Arthur Culbertson, arthur.culbertson@ssa.gov) Summary: Examples The dependency arrow should be reversed in Figure 52. The client should be the element that is more developed (i.e., Employee Record) and supplier should be the element that is the base for refinement (i.e., Employee). This is analogous to realization where the supplier is the specification and the client the implementation. Discussion: Proposed Resolution: Remove Figure 52 from Section 7.14.1, and remove its supporting text: the heading .Examples. ; the sentence .In the example below, the Employee class identified in analysis (i.e. the <>) maps to the same concept in the design model called Employee Record; the Figure title .Figure 52 . An example of a refine abstraction A bad example is worse than no example. As the example is non-normative, the effort to find and agree upon a good example is not worth the effort in the current FTF context. Whoever created this example will probably resist changing it and the simple removal of the example will occasion less delay. BRAN: First of all, Figure 52 in the spec is actually correct, if one formally follows the definition of Abstraction. In that definition, the supplier is the more abstract thing and the client is the more concrete thing. But, it is certainly confusing. A reasonable interpretation of the figure is that Employee refines EmployeeRecord, (which is obtained by following the direction of the dependency line) which is turns out to be incorrect. In fact, the .refine. word above the dashed line, simply qualifies the dependency as a Refine Abstraction. That is, the stereotype name was intentionally chosen to be direction-neutral. Nice try, but it doesn.t work. I suggest that, when it comes to abstraction, we leave out the waffle about directionality (e.g., the one about Trace being bi-directional). Abstraction is generally not a bi-directional relationship. With that, we should then change the names of the three standard Abstraction stereotypes to be directional and to match the direction of the arrow. Hence, instead of .refine. we should use .refinedAs. (or .refinedBy.), instead of .derive. use .derives., and instead of .trace. use .tracedTo. (BTW, it could be argued that trace is not a kind of abstraction at all and, hence, should not be a stereotype of Abstraction, but perhaps of Dependency.) Alternatively, we could change spec so that the client and supplier exchange roles for the case of Abstraction and use terms such as .refinedFrom., .derivedFrom. and .tracedFrom.. Disposition: Unresolved To: "Karl Frank" Cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sat, 31 Jan 2004 08:15:36 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/31/2004 08:15:48, Serialize complete at 01/31/2004 08:15:48 Let me concede on the naming issue -- especially since there does not seem to be any disagreement on the substantive issue (i.e., what are the things that we need to name). It seems that there is a consensus building up around Karl's, Joaquin's, and Jim's consolidated proposal. There is another advantage that I found while checking out the spec: almost the only place in the entire spec where "event" is used to mean "event occurrence" is in the CommonBehaviors chapter. Thus, from a purely practical point of view, if we change the text in CommonBehaviors chapter rather than the other way around, there is significantly less work and a lot less impact on the spec. Regards, Bran "Karl Frank" 01/30/2004 08:08 PM To: Branislav Selic/Ottawa/IBM@IBMCA cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) My concern was with using familiar terms for familiar concepts. There are many many books and articles by Mealy, Moore, Harel, Lamport, Douglass, (Selic, Rumbaugh) and countless UML 1.n statechart models, that use 'event' in the way Jim was endorsing and which I tried to exemplify in my text sample. The idea that we can stipulate that "whateverwewant" shall henceforth be the term for event is the way to make UML 2 ridiculed.' My objective is to make UML used and usable without putting unnecessary roadblocks in its path by arbitrary and novel choices of words for familiar concepts. I am not raising any question about the need to differentiate the time when an action begins to execute and whether (for example) other actions are on the same or other process threads, etc....) - Karl -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Fri 1/30/2004 4:21 PM To: Karl Frank Cc: Guus Ramackers; Joaquin Miller; James E Rumbaugh; UML Superstructure FTF Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Karl, is your concern about terminology or what is being modeled? In my proposal, I suggested that we need to differentiate at least three kinds of things, because I saw a clear need for each one. Are you suggesting that we do not need to differentiate them? For example, in doing performance analysis of a UML model (something that people are already doing), it becomes quite important to differentiate the point in time when an action starts to execute and the point when it finishes. This means that we need the notion of start of execution and the notion of end of execution. It is also often necessary to talk about messages and their arrival rates and propagation time distributions. We can call these things anything we like, but we need to be able to talk about them and, often, to model them explicitly. I really think that this is the baseline that we need to agree to first. Once we have an agreement, we can tackle the names. What do you think? Cheers, Bran "Karl Frank" 01/30/2004 03:51 PM To: Branislav Selic/Ottawa/IBM@IBMCA cc: "Guus Ramackers" , "Joaquin Miller" , "James E Rumbaugh" , "UML Superstructure FTF" Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) Good work in researching this. Before we go further I would like to take Guus' approach one step further and establish what our agreed baseline is. Consider this simple description of ordinary state-transition modeling and possibly familiar terminology. A statemachine modeled in a statechart shows how an automaton changes state in response to certain events. The automaton modeled in this way is not any particular instance of this statemachine, but is the general case, and the events that are cited in the model are not particular occurrences in actual time, but are types of such occurrences, such that ANY occurenc of the modeled type at ANY time in history will cause ANY instance of this statemachine to change state as described by the model, according to the state it was in when an event of the given type occurs. Is not this the way most people use the term 'event'? If so, should our UML terminology agree with this? My answers to both questions are in the affirmative. Karl -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Fri 1/30/2004 3:22 PM To: Karl Frank Cc: Guus Ramackers; Joaquin Miller; James E Rumbaugh; UML Superstructure FTF Subject: RE: ,gi, ,cb, Issue 6682 suggestions on events (Includes a proposal) OK, I've done a review of the situation with "events" and it's even messier than I thought. * There is much inconsistency throughout the document in the use of the terms "event", "event occurrence" (in Interactions), "request", "stimulus", "trigger", and "message". * One of the main ones comes from folding in the Action semantics chapters. In these chapters "event" is most definitely not used to mean "event occurrence" but, instead, denotes the communication vehicle that some communication action was executed (a call action or a signal received action). * The Interactions chapter introduces an explicit "event occurrence" concept -- which if we are to follow the philosophy that we set out in Common Behavior (which we had agreed on in U2P) -- is redundant, since "event" already means "event occurrence". To make things more confusing, it also uses the term "event" which, from what I can see, is synonymous with event occurrence. The actual action names, also use "event" rather than "event occurrence" (e.g., ReceiveEventAction). It also uses the term "message" for denoting what the Actions chapter calls "event". * The Activities chapter (including some OCL constraints) and the glossary still talk about "stimulus". * I have not seen any occurrences of the old interpretation of "event" as "event type", but I suspect it is there. As I see it, we need at least the following basic concepts to describe the run-time semantics of UML: 1. the notion of an observable and instantaneous change of state (e.g., change of the value of a variable, a time out, a message send) 2. the notion of something that causes a behavior to execute; this is always the result of some change of state, but not all changes of state will necessarily result in behavior execution (e.g., the receipt of a message or the creation of an object) 3. the notion of a communications vehicle that carries information between objects, including information about a change of state We may also need other things that build on these two basic things, such as types for the above and classifications of different kinds of change of state (not all of these necessarily have to be reflected in the metamodel, but should be properly defined in the spec). To get things going, I propose the following: 1. call the observable and instantaneous change of state an "event" -- because that fits most people's intuition of what an event is 2. do NOT use the pleonasm "event occurrence" (this means changing Interactions in particular) 3. call the notion of something that causes a behavior to execute a "stimulus" (this will probably not be an actual metamodel element) 4. call the communications vehicle "message" This is my proposal for the Tuesday afternoon discussion on the topic of events. If you have an alternative proposal, please send it out. Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Date: Thu, 29 Jan 2004 15:24:41 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 10 Issues from Classes Chapter with Proposed Resolutions Thread-Index: AcPmh5uGltZtehulRgKUkTMUqSHTugAFtChgAAGTiAE= From: "Karl Frank" To: "Pete Rivett" , "Branislav Selic" Cc: "Guus Ramackers" , X-OriginalArrivalTime: 29 Jan 2004 20:24:43.0274 (UTC) FILETIME=[EDF4C6A0:01C3E6A5] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i0TKIeJN008651 It could go either way, that is why it is a bad example, and why it is better to have no example. In every project I have been associated with, the methodology prescribes that implementation classes are defined on the basis of, with reference to, and in conformance with, the analysis view of the same object. Hence it is intuitive to view the employeeRecord as the dependent client. maybe the analysis view is reverse engineering the implementation, so the dependency may go the other way round, and the analysis Emloyee is an abstraction derived from In OO, the instance is generated from the classier, hence particular depends on classifier, but in the real world (unless you are Plato) the classificatoin is derived from experience of the instances. To repeat the initial discussion, a bad example just get rid of it. There is no question that ANY example can be in formal agreement with the spec, since the spec says it doesn't really matter! -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thu 1/29/2004 2:40 PM To: Branislav Selic; Karl Frank Cc: Guus Ramackers; uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Bran, For Issue 6173, related to Figure 52, you wrote: BRAN: First of all, Figure 52 in the spec is actually correct, if one formally follows the definition of Abstraction. In that definition, the supplier is the more abstract thing and the client is the more concrete thing. But, it is certainly confusing. A reasonable interpretation of the figure is that Employee refines EmployeeRecord, (which is obtained by following the direction of the dependency line) which is turns out to be incorrect. As I read the figure <>Employee is the more abstract design-level element and <>EmployeeRecord the more concrete thing. So by your argument Employee is the supplier and EmployeeRecord the client. According to the notation section of Dependencies "The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." So the arrow should go *from* EmployeeRecord (the client). It does not - hence the issue. Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 29, 2004 4:41 PM To: Karl Frank Cc: Guus Ramackers; uml2-superstructure-ftf@omg.org Subject: Re: 10 Issues from Classes Chapter with Proposed Resolutions And here are my comments on Karl's resolutions (apologies if duplicate). Cheers, Bran "Karl Frank" 01/28/2004 10:57 AM To: Branislav Selic/Ottawa/IBM@IBMCA, "Guus Ramackers" , cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions This attached item was the subject of my comments on the conference call wrt my experience in finding it difficult to get unanimity of opinion on what I had thought were 10 easy pieces. Apologies to Jack N. One of my sendings evidently did not get through, see "undeliverable" below, so maybe I was wrong to think everyone had seen it. FW: Undeliverable: 10 Issues from Classes Chapter with Proposed Resolutions -----Original Message----- From: Karl Frank Sent: Sat 1/24/2004 11:07 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; Guus Ramackers Cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions Your message did not reach some or all of the intended recipients. Subject: 10 Issues from Classes Chapter with Proposed Resolutions Sent: 1/24/2004 11:07 AM The following recipient(s) could not be reached: uml2-superstructure-ftf@omg.org on 1/26/2004 11:24 AM Could not deliver the message in the time limit specified. Please retry or contact your administrator. #### FTFIssues_Super_Classes_KF_04-01-23.doc has been removed from this note on January 29, 2004 by Branislav Selic To: "Pete Rivett" Cc: "Guus Ramackers" , "Karl Frank" , uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 29 Jan 2004 16:41:00 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/29/2004 16:41:03, Serialize complete at 01/29/2004 16:41:03 First of all, I am not arguing that we should keep the example. Second, let's make sure we are all in the same context. The issue is raised in the context of Figure 52, which is an illustration of the Abstraction concept. So, we are talking about Abstraction. In an abstraction, it is not clear what depends on what. There are both deductive (from the general to the particular) and inductive (from the particular to the general) approaches, implying that the arrow changes direction depending on which approach we used. If you read the spec carefully it says in the semantics section of Abstraction: "If an Abstraction element has more than one client element, the supplier element maps into the set of client elements as a group. For example, an analysis-level class might be split into several design-level classes. " The implication here is that the abstraction is the supplier and the specializations are clients -- that is going form the abstract to the particular (deduction). The diagrammatic form of this would be a dashed multiheaded arrow, with the keyword <> above it, going from the analysis-level class and pointing to a set of design-level classes. This is why I said that the example was technically correct (but confusing). So, we can conclude that the original definition presumes deductive thinking. The direction-neutral label (<>) is simply used to identify that the dashed line represents an abstraction and is not saying that the design-level classes are abstractions of the analysis-level classes. However, this is probably how most people would interpret it. My proposal was to eliminate the need to worry about whether deductive reasoning or inductive reasoning is assumed -- just make the label absolutely clear: if we used "abstractionOf" for the keyword, the direction of the arrow would always be clear. This word is not direction neutral the way that "abstraction" is. I hope this clarifies it. Cheers, Bran "Pete Rivett" 01/29/2004 02:40 PM To: Branislav Selic/Ottawa/IBM@IBMCA, "Karl Frank" cc: "Guus Ramackers" , Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Bran, For Issue 6173, related to Figure 52, you wrote: BRAN: First of all, Figure 52 in the spec is actually correct, if one formally follows the definition of Abstraction. In that definition, the supplier is the more abstract thing and the client is the more concrete thing. But, it is certainly confusing. A reasonable interpretation of the figure is that Employee refines EmployeeRecord, (which is obtained by following the direction of the dependency line) which is turns out to be incorrect. As I read the figure <>Employee is the more abstract design-level element and <>EmployeeRecord the more concrete thing. So by your argument Employee is the supplier and EmployeeRecord the client. According to the notation section of Dependencies "The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." So the arrow should go *from* EmployeeRecord (the client). It does not - hence the issue. Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 29, 2004 4:41 PM To: Karl Frank Cc: Guus Ramackers; uml2-superstructure-ftf@omg.org Subject: Re: 10 Issues from Classes Chapter with Proposed Resolutions And here are my comments on Karl's resolutions (apologies if duplicate). Cheers, Bran "Karl Frank" 01/28/2004 10:57 AM To: Branislav Selic/Ottawa/IBM@IBMCA, "Guus Ramackers" , cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions This attached item was the subject of my comments on the conference call wrt my experience in finding it difficult to get unanimity of opinion on what I had thought were 10 easy pieces. Apologies to Jack N. One of my sendings evidently did not get through, see "undeliverable" below, so maybe I was wrong to think everyone had seen it. FW: Undeliverable: 10 Issues from Classes Chapter with Proposed Resolutions -----Original Message----- From: Karl Frank Sent: Sat 1/24/2004 11:07 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; Guus Ramackers Cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions Your message did not reach some or all of the intended recipients. Subject: 10 Issues from Classes Chapter with Proposed Resolutions Sent: 1/24/2004 11:07 AM The following recipient(s) could not be reached: uml2-superstructure-ftf@omg.org on 1/26/2004 11:24 AM Could not deliver the message in the time limit specified. Please retry or contact your administrator. #### FTFIssues_Super_Classes_KF_04-01-23.doc has been removed from this note on January 29, 2004 by Branislav Selic To: "Karl Frank" Cc: "Guus Ramackers" , "Pete Rivett" , uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 29 Jan 2004 16:54:33 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/29/2004 16:54:34, Serialize complete at 01/29/2004 16:54:34 My point is that the real issue is not that the example is bad (it is), but the notation -- specifically, the keywords that are used for the various kinds of abstractions.So, removing the example is not a solution to the problem. The authors of that part of the spec, somewhat arbitrarily decided to define abstraction (of which refinement is a special case) as going from the abstract (the supplier) to the concrete (the client). I am suggesting that we switch that around and also clarify things further by a more appropriate choice of keywords. I actually think that we are in agreement here. Bran "Karl Frank" 01/29/2004 03:24 PM To: "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc: "Guus Ramackers" , Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions It could go either way, that is why it is a bad example, and why it is better to have no example. In every project I have been associated with, the methodology prescribes that implementation classes are defined on the basis of, with reference to, and in conformance with, the analysis view of the same object. Hence it is intuitive to view the employeeRecord as the dependent client. maybe the analysis view is reverse engineering the implementation, so the dependency may go the other way round, and the analysis Emloyee is an abstraction derived from In OO, the instance is generated from the classier, hence particular depends on classifier, but in the real world (unless you are Plato) the classificatoin is derived from experience of the instances. To repeat the initial discussion, a bad example just get rid of it. There is no question that ANY example can be in formal agreement with the spec, since the spec says it doesn't really matter! -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thu 1/29/2004 2:40 PM To: Branislav Selic; Karl Frank Cc: Guus Ramackers; uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Bran, For Issue 6173, related to Figure 52, you wrote: BRAN: First of all, Figure 52 in the spec is actually correct, if one formally follows the definition of Abstraction. In that definition, the supplier is the more abstract thing and the client is the more concrete thing. But, it is certainly confusing. A reasonable interpretation of the figure is that Employee refines EmployeeRecord, (which is obtained by following the direction of the dependency line) which is turns out to be incorrect. As I read the figure <>Employee is the more abstract design-level element and <>EmployeeRecord the more concrete thing. So by your argument Employee is the supplier and EmployeeRecord the client. According to the notation section of Dependencies "The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." So the arrow should go *from* EmployeeRecord (the client). It does not - hence the issue. Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 29, 2004 4:41 PM To: Karl Frank Cc: Guus Ramackers; uml2-superstructure-ftf@omg.org Subject: Re: 10 Issues from Classes Chapter with Proposed Resolutions And here are my comments on Karl's resolutions (apologies if duplicate). Cheers, Bran "Karl Frank" 01/28/2004 10:57 AM To: Branislav Selic/Ottawa/IBM@IBMCA, "Guus Ramackers" , cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions This attached item was the subject of my comments on the conference call wrt my experience in finding it difficult to get unanimity of opinion on what I had thought were 10 easy pieces. Apologies to Jack N. One of my sendings evidently did not get through, see "undeliverable" below, so maybe I was wrong to think everyone had seen it. FW: Undeliverable: 10 Issues from Classes Chapter with Proposed Resolutions -----Original Message----- From: Karl Frank Sent: Sat 1/24/2004 11:07 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; Guus Ramackers Cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions Your message did not reach some or all of the intended recipients. Subject: 10 Issues from Classes Chapter with Proposed Resolutions Sent: 1/24/2004 11:07 AM The following recipient(s) could not be reached: uml2-superstructure-ftf@omg.org on 1/26/2004 11:24 AM Could not deliver the message in the time limit specified. Please retry or contact your administrator. #### FTFIssues_Super_Classes_KF_04-01-23.doc has been removed from this note on January 29, 2004 by Branislav Selic Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Date: Thu, 29 Jan 2004 17:40:16 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 10 Issues from Classes Chapter with Proposed Resolutions Thread-Index: AcPmsx92wc8JyC0IQfKsqs4Nzb8TDAAAaNcg From: "Pete Rivett" To: "Branislav Selic" , "Karl Frank" Cc: "Guus Ramackers" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i0TMTsJN010873 Bran, I'm puzzled you say "The authors of that part of the spec, somewhat arbitrarily decided to define abstraction (of which refinement is a special case) as going from the abstract (the supplier) to the concrete (the client). " since in the Description section of Dependency (7.14.3) the client property is described as: "The element that is affected by the supplier element." and the supplier property as: "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." and, as I quoted in my email the Notation says ""The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." Assuming that we want UML to naturally support MDA then I would expect the more concrete (e.g. a PSM generated by a transformation) to be modeled as dependent on the less concrete (e.g. a PIM): reflecting the fact that if the PIM changes then the PSM should be regenerated (to remain consistent with it). This is what the spec currently seems to say (apart from in Fig 52): although we seem to have different readings of the current spec the good news is that we agree what it should be - and we should reflect that clearly in order to avoid the possibility of such inconsistent interpretations (and of course change the arrow direction in the infamous Fig 52). I also agree with your suggestion to change the keywords to make things more obvious. MDA makes it far more important to get such Dependencies clear and very consistent - they will be read not only by humans but by tools to automate regeneration etc. Cheers Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 29, 2004 9:55 PM To: Karl Frank Cc: Guus Ramackers; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions My point is that the real issue is not that the example is bad (it is), but the notation -- specifically, the keywords that are used for the various kinds of abstractions.So, removing the example is not a solution to the problem. The authors of that part of the spec, somewhat arbitrarily decided to define abstraction (of which refinement is a special case) as going from the abstract (the supplier) to the concrete (the client). I am suggesting that we switch that around and also clarify things further by a more appropriate choice of keywords. I actually think that we are in agreement here. Bran "Karl Frank" 01/29/2004 03:24 PM To: "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc: "Guus Ramackers" , Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions It could go either way, that is why it is a bad example, and why it is better to have no example. In every project I have been associated with, the methodology prescribes that implementation classes are defined on the basis of, with reference to, and in conformance with, the analysis view of the same object. Hence it is intuitive to view the employeeRecord as the dependent client. maybe the analysis view is reverse engineering the implementation, so the dependency may go the other way round, and the analysis Emloyee is an abstraction derived from In OO, the instance is generated from the classier, hence particular depends on classifier, but in the real world (unless you are Plato) the classificatoin is derived from experience of the instances. To repeat the initial discussion, a bad example just get rid of it. There is no question that ANY example can be in formal agreement with the spec, since the spec says it doesn't really matter! -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thu 1/29/2004 2:40 PM To: Branislav Selic; Karl Frank Cc: Guus Ramackers; uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Bran, For Issue 6173, related to Figure 52, you wrote: BRAN: First of all, Figure 52 in the spec is actually correct, if one formally follows the definition of Abstraction. In that definition, the supplier is the more abstract thing and the client is the more concrete thing. But, it is certainly confusing. A reasonable interpretation of the figure is that Employee refines EmployeeRecord, (which is obtained by following the direction of the dependency line) which is turns out to be incorrect. As I read the figure <>Employee is the more abstract design-level element and <>EmployeeRecord the more concrete thing. So by your argument Employee is the supplier and EmployeeRecord the client. According to the notation section of Dependencies "The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." So the arrow should go *from* EmployeeRecord (the client). It does not - hence the issue. Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 29, 2004 4:41 PM To: Karl Frank Cc: Guus Ramackers; uml2-superstructure-ftf@omg.org Subject: Re: 10 Issues from Classes Chapter with Proposed Resolutions And here are my comments on Karl's resolutions (apologies if duplicate). Cheers, Bran "Karl Frank" 01/28/2004 10:57 AM To: Branislav Selic/Ottawa/IBM@IBMCA, "Guus Ramackers" , cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions This attached item was the subject of my comments on the conference call wrt my experience in finding it difficult to get unanimity of opinion on what I had thought were 10 easy pieces. Apologies to Jack N. One of my sendings evidently did not get through, see "undeliverable" below, so maybe I was wrong to think everyone had seen it. FW: Undeliverable: 10 Issues from Classes Chapter with Proposed Resolutions -----Original Message----- From: Karl Frank Sent: Sat 1/24/2004 11:07 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; Guus Ramackers Cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions Your message did not reach some or all of the intended recipients. Subject: 10 Issues from Classes Chapter with Proposed Resolutions Sent: 1/24/2004 11:07 AM The following recipient(s) could not be reached: uml2-superstructure-ftf@omg.org on 1/26/2004 11:24 AM Could not deliver the message in the time limit specified. Please retry or contact your administrator. #### FTFIssues_Super_Classes_KF_04-01-23.doc has been removed from this note on January 29, 2004 by Branislav Selic Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Date: Fri, 30 Jan 2004 00:29:37 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 10 Issues from Classes Chapter with Proposed Resolutions Thread-Index: AcPmsKuy35FjAFItSTabOJV9CzBlFQAPes56 From: "Karl Frank" To: "Branislav Selic" , "Pete Rivett" Cc: "Guus Ramackers" , X-OriginalArrivalTime: 30 Jan 2004 05:29:39.0253 (UTC) FILETIME=[0E473E50:01C3E6F2] X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id i0U5NxJN012478 As Bran said in another email, we are in agreement -- except for one thing. I thought and still think the issue was not worth this effort on, and so proposed getting rid of the example, and I still think it would have been best to delete the example and get on with matters of more import. - Karl .-----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thu 1/29/2004 4:41 PM To: Pete Rivett Cc: Guus Ramackers; Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions First of all, I am not arguing that we should keep the example. Second, let's make sure we are all in the same context. The issue is raised in the context of Figure 52, which is an illustration of the Abstraction concept. So, we are talking about Abstraction. In an abstraction, it is not clear what depends on what. There are both deductive (from the general to the particular) and inductive (from the particular to the general) approaches, implying that the arrow changes direction depending on which approach we used. If you read the spec carefully it says in the semantics section of Abstraction: "If an Abstraction element has more than one client element, the supplier element maps into the set of client elements as a group. For example, an analysis-level class might be split into several design-level classes. " The implication here is that the abstraction is the supplier and the specializations are clients -- that is going form the abstract to the particular (deduction). The diagrammatic form of this would be a dashed multiheaded arrow, with the keyword <> above it, going from the analysis-level class and pointing to a set of design-level classes. This is why I said that the example was technically correct (but confusing). So, we can conclude that the original definition presumes deductive thinking. The direction-neutral label (<>) is simply used to identify that the dashed line represents an abstraction and is not saying that the design-level classes are abstractions of the analysis-level classes. However, this is probably how most people would interpret it. My proposal was to eliminate the need to worry about whether deductive reasoning or inductive reasoning is assumed -- just make the label absolutely clear: if we used "abstractionOf" for the keyword, the direction of the arrow would always be clear. This word is not direction neutral the way that "abstraction" is. I hope this clarifies it. Cheers, Bran "Pete Rivett" 01/29/2004 02:40 PM To: Branislav Selic/Ottawa/IBM@IBMCA, "Karl Frank" cc: "Guus Ramackers" , Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Bran, For Issue 6173, related to Figure 52, you wrote: BRAN: First of all, Figure 52 in the spec is actually correct, if one formally follows the definition of Abstraction. In that definition, the supplier is the more abstract thing and the client is the more concrete thing. But, it is certainly confusing. A reasonable interpretation of the figure is that Employee refines EmployeeRecord, (which is obtained by following the direction of the dependency line) which is turns out to be incorrect. As I read the figure <>Employee is the more abstract design-level element and <>EmployeeRecord the more concrete thing. So by your argument Employee is the supplier and EmployeeRecord the client. According to the notation section of Dependencies "The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." So the arrow should go *from* EmployeeRecord (the client). It does not - hence the issue. Pete Rivett (mailto:pete.rivett@adaptive.com ) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 29, 2004 4:41 PM To: Karl Frank Cc: Guus Ramackers; uml2-superstructure-ftf@omg.org Subject: Re: 10 Issues from Classes Chapter with Proposed Resolutions And here are my comments on Karl's resolutions (apologies if duplicate). Cheers, Bran "Karl Frank" 01/28/2004 10:57 AM To: Branislav Selic/Ottawa/IBM@IBMCA, "Guus Ramackers" , cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions This attached item was the subject of my comments on the conference call wrt my experience in finding it difficult to get unanimity of opinion on what I had thought were 10 easy pieces. Apologies to Jack N. One of my sendings evidently did not get through, see "undeliverable" below, so maybe I was wrong to think everyone had seen it. FW: Undeliverable: 10 Issues from Classes Chapter with Proposed Resolutions -----Original Message----- From: Karl Frank Sent: Sat 1/24/2004 11:07 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; Guus Ramackers Cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions Your message did not reach some or all of the intended recipients. Subject: 10 Issues from Classes Chapter with Proposed Resolutions Sent: 1/24/2004 11:07 AM The following recipient(s) could not be reached: uml2-superstructure-ftf@omg.org on 1/26/2004 11:24 AM Could not deliver the message in the time limit specified. Please retry or contact your administrator. #### FTFIssues_Super_Classes_KF_04-01-23.doc has been removed from this note on January 29, 2004 by Branislav Selic To: "Pete Rivett" Cc: "Guus Ramackers" , "Karl Frank" , uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 30 Jan 2004 08:13:15 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/30/2004 08:13:18, Serialize complete at 01/30/2004 08:13:18 Pete, I explicitly said that we should make the supplier the more concrete element and the client the abstract element -- in other words, you, Karl, and I are in full agreement there. (It must be my writing style that is confusing -- apologies). On top of that, I am suggesting that we should change the name of the keywords so that there is no ambiguity about the direction. (I am claiming that the current names are confusing.) The only thing that we are disagreeing on is what the current spec actually says. We both have quotes that back up our case, indicating that the spec is ambiguous at the very least. So, let's not argue about this any more and let's just clarify the spec text and get rid of the ambiguity. I don't believe that the issue is fixed by removing the example. Cheers, Bran "Pete Rivett" 01/29/2004 05:40 PM To: Branislav Selic/Ottawa/IBM@IBMCA, "Karl Frank" cc: "Guus Ramackers" , Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Bran, I'm puzzled you say "The authors of that part of the spec, somewhat arbitrarily decided to define abstraction (of which refinement is a special case) as going from the abstract (the supplier) to the concrete (the client). " since in the Description section of Dependency (7.14.3) the client property is described as: "The element that is affected by the supplier element." and the supplier property as: "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." and, as I quoted in my email the Notation says ""The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." Assuming that we want UML to naturally support MDA then I would expect the more concrete (e.g. a PSM generated by a transformation) to be modeled as dependent on the less concrete (e.g. a PIM): reflecting the fact that if the PIM changes then the PSM should be regenerated (to remain consistent with it). This is what the spec currently seems to say (apart from in Fig 52): although we seem to have different readings of the current spec the good news is that we agree what it should be - and we should reflect that clearly in order to avoid the possibility of such inconsistent interpretations (and of course change the arrow direction in the infamous Fig 52). I also agree with your suggestion to change the keywords to make things more obvious. MDA makes it far more important to get such Dependencies clear and very consistent - they will be read not only by humans but by tools to automate regeneration etc. Cheers Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 29, 2004 9:55 PM To: Karl Frank Cc: Guus Ramackers; Pete Rivett; uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions My point is that the real issue is not that the example is bad (it is), but the notation -- specifically, the keywords that are used for the various kinds of abstractions.So, removing the example is not a solution to the problem. The authors of that part of the spec, somewhat arbitrarily decided to define abstraction (of which refinement is a special case) as going from the abstract (the supplier) to the concrete (the client). I am suggesting that we switch that around and also clarify things further by a more appropriate choice of keywords. I actually think that we are in agreement here. Bran "Karl Frank" 01/29/2004 03:24 PM To: "Pete Rivett" , Branislav Selic/Ottawa/IBM@IBMCA cc: "Guus Ramackers" , Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions It could go either way, that is why it is a bad example, and why it is better to have no example. In every project I have been associated with, the methodology prescribes that implementation classes are defined on the basis of, with reference to, and in conformance with, the analysis view of the same object. Hence it is intuitive to view the employeeRecord as the dependent client. maybe the analysis view is reverse engineering the implementation, so the dependency may go the other way round, and the analysis Emloyee is an abstraction derived from In OO, the instance is generated from the classier, hence particular depends on classifier, but in the real world (unless you are Plato) the classificatoin is derived from experience of the instances. To repeat the initial discussion, a bad example just get rid of it. There is no question that ANY example can be in formal agreement with the spec, since the spec says it doesn't really matter! -----Original Message----- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thu 1/29/2004 2:40 PM To: Branislav Selic; Karl Frank Cc: Guus Ramackers; uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Bran, For Issue 6173, related to Figure 52, you wrote: BRAN: First of all, Figure 52 in the spec is actually correct, if one formally follows the definition of Abstraction. In that definition, the supplier is the more abstract thing and the client is the more concrete thing. But, it is certainly confusing. A reasonable interpretation of the figure is that Employee refines EmployeeRecord, (which is obtained by following the direction of the dependency line) which is turns out to be incorrect. As I read the figure <>Employee is the more abstract design-level element and <>EmployeeRecord the more concrete thing. So by your argument Employee is the supplier and EmployeeRecord the client. According to the notation section of Dependencies "The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." So the arrow should go *from* EmployeeRecord (the client). It does not - hence the issue. Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 29, 2004 4:41 PM To: Karl Frank Cc: Guus Ramackers; uml2-superstructure-ftf@omg.org Subject: Re: 10 Issues from Classes Chapter with Proposed Resolutions And here are my comments on Karl's resolutions (apologies if duplicate). Cheers, Bran "Karl Frank" 01/28/2004 10:57 AM To: Branislav Selic/Ottawa/IBM@IBMCA, "Guus Ramackers" , cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions This attached item was the subject of my comments on the conference call wrt my experience in finding it difficult to get unanimity of opinion on what I had thought were 10 easy pieces. Apologies to Jack N. One of my sendings evidently did not get through, see "undeliverable" below, so maybe I was wrong to think everyone had seen it. FW: Undeliverable: 10 Issues from Classes Chapter with Proposed Resolutions -----Original Message----- From: Karl Frank Sent: Sat 1/24/2004 11:07 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; Guus Ramackers Cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions Your message did not reach some or all of the intended recipients. Subject: 10 Issues from Classes Chapter with Proposed Resolutions Sent: 1/24/2004 11:07 AM The following recipient(s) could not be reached: uml2-superstructure-ftf@omg.org on 1/26/2004 11:24 AM Could not deliver the message in the time limit specified. Please retry or contact your administrator. #### FTFIssues_Super_Classes_KF_04-01-23.doc has been removed from this note on January 29, 2004 by Branislav Selic To: "Karl Frank" Cc: "Guus Ramackers" , "Pete Rivett" , uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 30 Jan 2004 08:28:17 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/30/2004 08:28:19, Serialize complete at 01/30/2004 08:28:19 As I said, I think that it is important because the example is correct (see the quote I cited in a previous e-mail) and the spec is confusing. We are supposedly the experts and we cannot agree on what it means. Bran "Karl Frank" 01/30/2004 12:29 AM To: Branislav Selic/Ottawa/IBM@IBMCA, "Pete Rivett" cc: "Guus Ramackers" , Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions As Bran said in another email, we are in agreement -- except for one thing. I thought and still think the issue was not worth this effort on, and so proposed getting rid of the example, and I still think it would have been best to delete the example and get on with matters of more import. - Karl .-----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thu 1/29/2004 4:41 PM To: Pete Rivett Cc: Guus Ramackers; Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions First of all, I am not arguing that we should keep the example. Second, let's make sure we are all in the same context. The issue is raised in the context of Figure 52, which is an illustration of the Abstraction concept. So, we are talking about Abstraction. In an abstraction, it is not clear what depends on what. There are both deductive (from the general to the particular) and inductive (from the particular to the general) approaches, implying that the arrow changes direction depending on which approach we used. If you read the spec carefully it says in the semantics section of Abstraction: "If an Abstraction element has more than one client element, the supplier element maps into the set of client elements as a group. For example, an analysis-level class might be split into several design-level classes. " The implication here is that the abstraction is the supplier and the specializations are clients -- that is going form the abstract to the particular (deduction). The diagrammatic form of this would be a dashed multiheaded arrow, with the keyword <> above it, going from the analysis-level class and pointing to a set of design-level classes. This is why I said that the example was technically correct (but confusing). So, we can conclude that the original definition presumes deductive thinking. The direction-neutral label (<>) is simply used to identify that the dashed line represents an abstraction and is not saying that the design-level classes are abstractions of the analysis-level classes. However, this is probably how most people would interpret it. My proposal was to eliminate the need to worry about whether deductive reasoning or inductive reasoning is assumed -- just make the label absolutely clear: if we used "abstractionOf" for the keyword, the direction of the arrow would always be clear. This word is not direction neutral the way that "abstraction" is. I hope this clarifies it. Cheers, Bran "Pete Rivett" 01/29/2004 02:40 PM To: Branislav Selic/Ottawa/IBM@IBMCA, "Karl Frank" cc: "Guus Ramackers" , Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Bran, For Issue 6173, related to Figure 52, you wrote: BRAN: First of all, Figure 52 in the spec is actually correct, if one formally follows the definition of Abstraction. In that definition, the supplier is the more abstract thing and the client is the more concrete thing. But, it is certainly confusing. A reasonable interpretation of the figure is that Employee refines EmployeeRecord, (which is obtained by following the direction of the dependency line) which is turns out to be incorrect. As I read the figure <>Employee is the more abstract design-level element and <>EmployeeRecord the more concrete thing. So by your argument Employee is the supplier and EmployeeRecord the client. According to the notation section of Dependencies "The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier)." So the arrow should go *from* EmployeeRecord (the client). It does not - hence the issue. Pete Rivett (mailto:pete.rivett@adaptive.com ) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com _____ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, January 29, 2004 4:41 PM To: Karl Frank Cc: Guus Ramackers; uml2-superstructure-ftf@omg.org Subject: Re: 10 Issues from Classes Chapter with Proposed Resolutions And here are my comments on Karl's resolutions (apologies if duplicate). Cheers, Bran "Karl Frank" 01/28/2004 10:57 AM To: Branislav Selic/Ottawa/IBM@IBMCA, "Guus Ramackers" , cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions This attached item was the subject of my comments on the conference call wrt my experience in finding it difficult to get unanimity of opinion on what I had thought were 10 easy pieces. Apologies to Jack N. One of my sendings evidently did not get through, see "undeliverable" below, so maybe I was wrong to think everyone had seen it. FW: Undeliverable: 10 Issues from Classes Chapter with Proposed Resolutions -----Original Message----- From: Karl Frank Sent: Sat 1/24/2004 11:07 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org; Guus Ramackers Cc: Subject: 10 Issues from Classes Chapter with Proposed Resolutions Your message did not reach some or all of the intended recipients. Subject: 10 Issues from Classes Chapter with Proposed Resolutions Sent: 1/24/2004 11:07 AM The following recipient(s) could not be reached: uml2-superstructure-ftf@omg.org on 1/26/2004 11:24 AM Could not deliver the message in the time limit specified. Please retry or contact your administrator. #### FTFIssues_Super_Classes_KF_04-01-23.doc has been removed from this note on January 29, 2004 by Branislav Selic From: Edwin Seidewitz To: "'Branislav Selic'" , Pete Rivett Cc: Guus Ramackers , Karl Frank , uml2-superstructure-ftf@omg.org Subject: RE: 10 Issues from Classes Chapter with Proposed Resolutions Date: Mon, 2 Feb 2004 11:03:18 -0500 X-Mailer: Internet Mail Service (5.5.2655.55) Bran -- I have finally caught up on this thread. As I did, I noticed one inconsistency in a message from you that might be causing some confusion. In you 1/29 message, you wrote; The implication here is that the abstraction is the supplier and the specializations are clients -- that is going form the abstract to the particular (deduction). The diagrammatic form of this would be a dashed multiheaded arrow, with the keyword <> above it, going from the analysis-level class and pointing to a set of design-level classes. This is why I said that the example was technically correct (but confusing). This paragraph seems to argue that the arrow tail should be at the analysis-level class (abstraction, hence supplier) with the arrowhead at the design-level class (specialization, hence client). But this is not correct -- the arrowhead goes with the supplier and the arrow tail goes with the client (i.e., client - - - > supplier). This was pointed out by Pete in one of in his message on the same day: "...the Notation says 'The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier).' " So, your argument actually indicates that the arrowhead should go from EmployeeRecord (client, design class) to Employee (supplier, analysis class) (i.e., EmployeeRecord - - - > Employee). I don't think there is really any ambiguity here. I also think that Figure 52 is actually not such a bad example -- the arrow is just going in the wrong direction and that is just an error. -- Ed Subject: TwoMoreProposedClassesIssues for 15 Date: Wed, 26 May 2004 18:31:34 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: TwoMoreProposedClassesIssues for 15 Thread-Index: AcRDWF7YdarZyYxfS6KbzeuZXg8bJQAGEVaA From: "Karl Frank" To: X-OriginalArrivalTime: 26 May 2004 22:31:35.0882 (UTC) FILETIME=[342B12A0:01C44371] Please see attached. 6173 will (I predict) immediately make each person want to create his own new better example. Let's not go there. I have tried that, and it turns out no-one then agrees on what a good example is. The FAS spec says the direction "doesn't matter" so lets not waste time on what the "right" direction is. 6183 is, I hope, not a problem. ClassesIssues6173_6183.doc OMG Issue No: 6173 Title: 7.14.1 Abstraction Source: Lockheed Martin (Mr. Arthur Culbertson, arthur.culbertson@ssa.gov) Summary: Examples The dependency arrow should be reversed in Figure 52. The client should be the element that is more developed (i.e., Employee Record) and supplier should be the element that is the base for refinement (i.e., Employee). This is analogous to realization where the supplier is the specification and the client the implementation. Discussion: The Figure 52 in question is on page 108 of the FAS as printed, page 123 in the electronic pdf pagination, at the end of section 7.14.1 Abstraction. This figure shows a dashed arrow with a stereotype <> pointing from the Employee, stereotyped as <> as client to the Employee Record, stereotyped as <> as supplier. Remove the example figure 52. Do not replace it, do not reposition it, just remove it altogether from the spec. The context for this resolution includes the definition of the client and supplier roles in a directed dependency. That definition states that the choice of client and supplier can be stipulated by the modeler, and is not predetermined by a standard semantic for dependency. In fact, the FAS goes so far as to say that the choice of direction .doesn.t matter.. Therefore we propose to resolve this issue by removing the example entirely. We (various members of the FTF) have tried to come up with a better example, and found that it is difficult to agree on a good example, because in fact clever people can think of some respects in which A is dependent on B, and also other respects in which B is dependent on A, for the same A and B. The author of this proposed resolution agrees (in part) with Mr. Arthur Culbertson about this figure, in that I too would have chosen the Employee record as playing the role of that which refines and depends upon the type Employee, but that agreement is irrelevant. I have tried the experiment of asking other experienced UML modelers their opinion on this, and have found no general agreement. We have too much to do to waste time on debating a non-normative example. Disposition: Resolved Subject: two Classes resolutions for ballot 16 Date: Sun, 30 May 2004 21:32:39 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: two Classes resolutions for ballot 16 Thread-Index: AcRGjDXBC7ofg3fYQWKZKGkUKd+pVgAIa2gQ From: "Karl Frank" To: X-OriginalArrivalTime: 31 May 2004 01:32:40.0753 (UTC) FILETIME=[29C9D210:01C446AF] Here are two Classes issues that did not make it into Ballot 15. Bran thought there was some potential for disagreement about these, so do take a look at them. They are not difficult to understand, so no great mental effort is required in this. - Karl ClassesIssues6173_6183.doc OMG Issue No: 6173 Title: 7.14.1 Abstraction Source: Lockheed Martin (Mr. Arthur Culbertson, arthur.culbertson@ssa.gov) Summary: Examples The dependency arrow should be reversed in Figure 52. The client should be the element that is more developed (i.e., Employee Record) and supplier should be the element that is the base for refinement (i.e., Employee). This is analogous to realization where the supplier is the specification and the client the implementation. Discussion: The Figure 52 in question is on page 108 of the FAS as printed, page 123 in the electronic pdf pagination, at the end of section 7.14.1 Abstraction. This figure shows a dashed arrow with a stereotype <> pointing from the Employee, stereotyped as <> as client to the Employee Record, stereotyped as <> as supplier. Remove the example figure 52. Do not replace, reposition it or fix it. The context for this resolution includes the definition of the client and supplier roles in a directed dependency. That definition states that the choice of client and supplier can be stipulated by the modeler, and is not predetermined by a standard semantic for dependency. In fact, the FAS goes so far as to say that the choice of direction .doesn.t matter.. We (various members of the FTF) have tried to come up with a better example, and found that it is difficult to agree on a good one, because in fact clever people can think of some respects in which A is dependent on B, and also other respects in which B is dependent on A, for the same A and B. The authors of this proposed resolution agree (in part) with Mr. Arthur Culbertson about this figure. We too would have put the EmployeeRecord in the role of that which refines and depends upon the type Employee. The fact that the original author of this example had it the other way around proves the point that the choice of direction can be an arbitrary stipulation of the modeler, and in that case there is NOTHING to be gained by putting in an example. Disposition: Resolved Subject: RE: Ballot 16 -- vote starts Date: Mon, 14 Jun 2004 23:16:59 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 16 -- vote starts Thread-Index: AcRQAzvIrAz5g2d+S6STS2nSNJCD/gCFH8Ng From: "Pete Rivett" To: "Branislav Selic" , Cc: , Adaptive votes YES to all the proposed resolutions except 6173 to which it votes NO. For 6173, while removing the example might dispense with the immediate source of controversy, the spec is left with a feature which is even less well-defined and with even more room for misinterpretation. If, as the resolution says. the application of the concept of Abstraction/refines cannot be agreed by 'clever people' then there is something more fundamentally wrong with the concept or its definition. Moreover the resolution is incomplete - for consistency the 2nd sentence in the following text from Abstraction semantics should also be removed since it also implies the client is the analysis element: "If an Abstraction element has more than one client element, the supplier element maps into the set of client elements as a group. For example, an analysis-level class might be split into several design-level classes." The recent resolution of 5802 (affecting Dependency) had some appropriate wording: an example reflecting common conventional OO usage' woudl be appropriate for Abstraction - if only to illustrate the espected usage of Abstraction::mapping whihc is somewhat non-obvious. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, June 11, 2004 11:13 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Ballot 16 -- vote starts No changes to the ballot since my last posting -- but now it is official. You have 2 weeks until Friday, June 25. Cheers...Bran