Issue 6448: Inconsistent use of terms "implement" and "realize" (uml2-superstructure-ftf) Source: Pivot Point (Mr. Cris Kobryn, ) Nature: Uncategorized Issue Severity: Summary: Description: The terms “implement” and “realize” are used inconsistently throughout the specification. These terms should be defined in the glossary (Preface, Terms and Definitions) and applied consistently throughout the specification. Resolution: see above Revised Text: Actions taken: November 6, 2003: received issue March 8, 2005: closed issue Discussion: The confusion arises mostly because of the introduction of the new metaclass “Implementation”, which is a specialization of the “Realization” metaclass for the case where a classifier realizes an interface. This introduces a differentiation between two terms that were used synonymously in the past and also in other parts of the specification. The problem will be solved by renaming the concept of “Implementation” to “InterfaceRealization”. This frees up the term “implementation” from its very specialized semantics, allowing it to be used interchangeably with the term “realization”. (The alternative of revisiting the 600 or so occurrences of these two terms and adding clarifying text is impractical.) The following changes need to be made: ?? Replace the diagram in figure 58 on page 112 with the following diagram: Realization (from Dependencies) Property (from Kernel) Operation (from Kernel) Interface * 0..1 +nestedInterface {ordered, subsets ownedMember} {subsets namespace, subsets redefinitionContext} * * +redefinedInterface {subsets redefinedElement} * 0..1 +ownedAttribute {ordered, subsets attribute, subsets ownedMember} {subsets classifier, subsets namespace, subsets featuringClassifier} 0..1 * {subsets redefinitionContext} +ownedOperation {ordered, subsets feature, subsets ownedMember} InterfaceRealization ?? In the Description sub-section of the BehavioredClassifier class on page 113 replace the line: A BehavioredClassifier may have implementations. with the following line: A BehavioredClassifier may have interface realizations. ?? Replace the item for “implementation” in the Associations sub-section of BehavioredClassifier class on page 113 with the following entry: ?? interfaceRealizations : InterfaceRealization [*] (Specializes Element.ownedElement and Realization.clientDependency.) ?? Replace the title and Description section of Implementation on page 113: 7.15.2 Implementation (from Interfaces) Description An Implementation is a specialized Realization relationship between a Classifier and an Interface. The implementation relationship signifies that the realizing classifier conforms to the contract specified by the interface. with the following text fragment: 7.15.2 InterfaceRealization (from Interfaces) Description An InterfaceRealization is a specialized Realization relationship between a Classifier and an Interface. This relationship signifies that the realizing classifier conforms to the contract specified by the Interface. ?? Replace the last paragraph of the semantics section of Implementation on pages 113 and 114: An implementation relationship between a classifier and an interface implies that the classifier supports the set of features owned by the interface, and any of its parent interfaces. For behavioral features, the implementing classifier will have an operations or reception for every operation or reception, respectively, owned by the interface. For properties, the implementing classifier will provide functionality that maintains the state represented by the property. While such may be done by direct mapping to a propertyof the implementing classifier, it may also be supported by the state machine of the classifier or by a pair of operations that support the retrieval of the state information and an operation that changes the state information. with the following text fragment (no te that this also fixes several typos in the above): An interface realization relationship between a classifier and an interface implies that the classifier supports the set of features owned by the interface, and any of its parent interfaces. For behavioral features, the realizing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface. For properties, the realizing classifier will provide functionality that maintains the state represented by the property. While such may be done by direct mapping to a property of the realizing classifier, it may also be supported by the state machine of the classifier or by a pair of operations that support the retrieval of the state information and an operation that changes the state information. ?? Replace the first sentence of the second paragraph of the Notation sub-section of Interface on page 115: 2.0 Superstructure FTF Disposition: Resolved OMG Issue No: 6448 Document {Report document number} Page 323 The implementation dependency from a classifier to an interface is shown by representing the interface by a circle or ball, labelled with the name of the interface, attached by a solid line to the classifier that implements this interface (see Figure 59). with the following phrase (this also fixes some typos in the above text): The interface realization dependency from a classifier to an interface is shown by representing the interface by a circle or ball, labeled with the name of the interface, attached by a solid line to the classifier that realizes this interface (see Figure 59). ?? Replace the first sentence of the first paragraph of the “Presentation option” subsection of Interface on page 116: Alternatively, if an interface is shown using the rectangle symbol, their implementation and usage dependencies to provided and required interfaces, respectively, may be shown using dependency arrows (see Figure 62). with the following phrase (this also fixes some typos in the above text): Alternatively, in cases where interfaces are represented using the rectangle notation, interface realization and usage dependencies are denoted with appropriate dependency arrows (see Figure 62). ?? Replace the third bullet item in the “Component diagram” sub-section on page 149: o Realization, Implementation, Usage Dependencies with the following item: o Realization, Interface Realization, Usage dependencies End of Annotations:===== eference: UML 2 Superstructure, OMG doc# ptc/03-08-02 Issue: Inconsistent use of terms "implement" and "realize" Description: The terms “implement” and “realize” are used inconsistently throughout the specification. These terms should be defined in the glossary (Preface, Terms and Definitions) and applied consistently throughout the specification. From: "Thomas Weigert" To: "Branislav Selic" , Cc: Subject: RE: Bran's resolutions for ballot 17 Date: Thu, 17 Jun 2004 21:00:57 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, one comment: 6448: I do not quite understand the resolution. In the UML we have these two metaclasses: Realization and Implementation. When we say, for example, "a classifier implements an interface" that is different from some class realizing its target. I don't think the submitter was referring to the stereotypes but to the respective metaclasses, and I think there indeed is an issue. In particular, where we used "realize" now we need to use "implements" instead sometimes. I noticed that in the internal structure chapter and made the appropriate changes, but there may be more places... I would defer if you don't want to deal with this right now. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, June 17, 2004 4:03 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: Bran's resolutions for ballot 17 Attached, please find some proposed resolutions for ballot 17. They are a diverse lot related to a number of areas. Some of them may be contentious, so please have a look at them and raise any objections that you might have ASAP. Please don't wait for the ballot to start to do that. The issues addressed are: 5273: (resolved) discusses the handling of transitions to composite states that have no initial pseudostate 6447: (closed no change) issue requests changes to the glossary which was removed from the spec (no one stepped up to restore it and update it) 6448: (closed no change) issue requests better differentiation between "implement" and "realize" but these are now synonyms in the spec 6456: (deferred) issue complains about the misuse of the term "representation" in the spec. There are 446 references to the term that need to be revisited. 6918: (resolved) invalid diagram included in the Classes chapter 7045: (resolved) some invalid OCL fixed in state machines 7256: (resolved) clarification of completion transitions handling for the case of simple states (based on input from Eran G) 7365: (resolved) a whole slew of association ends constrained to be {ordered} that were not previously; included are diagrams from Interactions, Templates, Actions, Structured Classes, and Classes Cheers, Bran To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Bran's resolutions for ballot 17 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 18 Jun 2004 08:35:49 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 06/18/2004 08:35:50, Serialize complete at 06/18/2004 08:35:50 > 6448: I do not quite understand the resolution. In the UML we have > these two metaclasses: Realization and Implementation. I realize that ;-) However, Implementation is just a specialization of Realization. Which reminds me: I did ask Eran a long time ago to change the name of Implementation because it is not a good idea to appropriate such a widely-used term ("implementation") for such a narrowly defined concept. He never got around to it. So, I will raise an issue and I will propose that we refer to "Implementation" as "InterfaceRealization". That might be indirectly the solution to this issue as well. I will reformulate the resolution. Thanks...Bran To: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org Subject: Revised resolution to issue 6448 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 18 Jun 2004 15:15:30 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 06/18/2004 15:15:36 Here is the promised revised resolution to issue 6448 following Thomas feedback (it was a "closed, no change" before). There is no semantic change involved, merely a renaming of the concept that was called "Implementation" into "InterfaceRealization". Note that in the metamodel, Implemenation was a specialization of Realization, so the new name is appropriate. This eliminates the confusion between the generic use of the term "implementation", which is used informally in hundreds of places throughout the spec, and the very specialized technically precise concept of "realization of an interface". I hope to include this resolution in ballot 17. Cheers...Bran BranIssue.6448.resolution.doc OMG Issue No: 6448 Title: Inconsistent use of terms "implement" and "realize" Source: Telelogic AB (Mr. Cris Kobryn, ckobryn@acm.org) Summary: The terms .implement. and .realize. are used inconsistently throughout the specification. These terms should be defined in the glossary (Preface, Terms and Definitions) and applied consistently throughout the specification. Discussion: The confusion arises mostly because of the introduction of the new metaclass .Implementation., which is a specialization of the .Realization. metaclass for the case where a classifier realizes an interface. This introduces a differentiation between two terms that were used synonymously in the past and also in other parts of the specification. The problem will be solved by renaming the concept of .Implementation. to .InterfaceRealization.. This frees up the term .implementation. from its very specialized semantics, allowing it to be used interchangeably with the term .realization.. (The alternative of revisiting the 600 or so occurrences of these two terms and adding clarifying text is impractical.) The following changes need to be made: · Replace the diagram in figure 58 on page 112 with the following diagram: · In the Description sub-section of the BehavioredClassifier class on page 113 replace the line: A BehavioredClassifier may have implementations. with the following line: A BehavioredClassifier may have interface realizations. · Replace the item for .implementation. in the Associations sub-section of BehavioredClassifier class on page 113 with the following entry: · interfaceRealizations : InterfaceRealization [*] (Specializes Element.ownedElement and Realization.clientDependency.) · Replace the title and Description section of Implementation on page 113: 7.15.2 Implementation (from Interfaces) Description An Implementation is a specialized Realization relationship between a Classifier and an Interface. The implementation relationship signifies that the realizing classifier conforms to the contract specified by the interface. with the following text fragment: 7.15.2 InterfaceRealization (from Interfaces) Description An InterfaceRealization is a specialized Realization relationship between a Classifier and an Interface. This relationship signifies that the realizing classifier conforms to the contract specified by the Interface. · Replace the last paragraph of the semantics section of Implementation on pages 113 and 114: An implementation relationship between a classifier and an interface implies that the classifier supports the set of features owned by the interface, and any of its parent interfaces. For behavioral features, the implementing classifier will have an operations or reception for every operation or reception, respectively, owned by the interface. For properties, the implementing classifier will provide functionality that maintains the state represented by the property. While such may be done by direct mapping to a propertyof the implementing classifier, it may also be supported by the state machine of the classifier or by a pair of operations that support the retrieval of the state information and an operation that changes the state information. with the following text fragment (note that this also fixes several typos in the above): An interface realization relationship between a classifier and an interface implies that the classifier supports the set of features owned by the interface, and any of its parent interfaces. For behavioral features, the realizing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface. For properties, the realizing classifier will provide functionality that maintains the state represented by the property. While such may be done by direct mapping to a property of the realizing classifier, it may also be supported by the state machine of the classifier or by a pair of operations that support the retrieval of the state information and an operation that changes the state information. · Replace the first sentence of the second paragraph of the Notation sub-section of Interface on page 115: The implementation dependency from a classifier to an interface is shown by representing the interface by a circle or ball, labelled with the name of the interface, attached by a solid line to the classifier that implements this interface (see Figure 59). with the following phrase (this also fixes some typos in the above text): The interface realization dependency from a classifier to an interface is shown by representing the interface by a circle or ball, labeled with the name of the interface, attached by a solid line to the classifier that realizes this interface (see Figure 59). · Replace the first sentence of the first paragraph of the .Presentation option. sub-section of Interface on page 116: Alternatively, if an interface is shown using the rectangle symbol, their implementation and usage dependencies to provided and required interfaces, respectively, may be shown using dependency arrows (see Figure 62). with the following phrase (this also fixes some typos in the above text): Alternatively, in cases where interfaces are represented using the rectangle notation, interface realization and usage dependencies are denoted with appropriate dependency arrows (see Figure 62). · Replace the third bullet item in the .Component diagram. sub-section on page 149: o Realization, Implementation, Usage Dependencies with the following item: o Realization, Interface Realization, Usage dependencies Disposition: Resolved From: "Thomas Weigert" To: "Branislav Selic" , , Subject: RE: Revised resolution to issue 6448 Date: Fri, 18 Jun 2004 14:40:16 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) This raises the problem that we need to now change all the places where we used "implementation" to refer to the relationship between interface and classifier that realizes it. There are such places at least in internal structure... Probably also in interface and component... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, June 18, 2004 2:16 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Revised resolution to issue 6448 Here is the promised revised resolution to issue 6448 following Thomas feedback (it was a "closed, no change" before). There is no semantic change involved, merely a renaming of the concept that was called "Implementation" into "InterfaceRealization". Note that in the metamodel, Implemenation was a specialization of Realization, so the new name is appropriate. This eliminates the confusion between the generic use of the term "implementation", which is used informally in hundreds of places throughout the spec, and the very specialized technically precise concept of "realization of an interface". I hope to include this resolution in ballot 17. Cheers...Bran To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Revised resolution to issue 6448 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 18 Jun 2004 16:02:49 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 06/18/2004 16:02:52, Serialize complete at 06/18/2004 16:02:52 I've already done that, Thomas. I visited every reference to "implementation" (there were 120 of them) and checked it out. The only ones that needed fixing are the ones that are included in the resolution text. The vast majority were not using the technical meaning but the informal meaning. If you want, you can verify it by doing a search on "implementation" (not case sensitive, not full word) and checking them out. I'm pretty sure I got them all. Thanks...Bran "Thomas Weigert" 06/18/2004 03:40 PM To Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject RE: Revised resolution to issue 6448 This raises the problem that we need to now change all the places where we used "implementation" to refer to the relationship between interface and classifier that realizes it. There are such places at least in internal structure... Probably also in interface and component... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, June 18, 2004 2:16 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Revised resolution to issue 6448 Here is the promised revised resolution to issue 6448 following Thomas feedback (it was a "closed, no change" before). There is no semantic change involved, merely a renaming of the concept that was called "Implementation" into "InterfaceRealization". Note that in the metamodel, Implemenation was a specialization of Realization, so the new name is appropriate. This eliminates the confusion between the generic use of the term "implementation", which is used informally in hundreds of places throughout the spec, and the very specialized technically precise concept of "realization of an interface". I hope to include this resolution in ballot 17. Cheers...Bran From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , Subject: RE: Revised resolution to issue 6448 Date: Fri, 18 Jun 2004 15:13:39 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) I trust you... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, June 18, 2004 3:03 PM To: Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Revised resolution to issue 6448 I've already done that, Thomas. I visited every reference to "implementation" (there were 120 of them) and checked it out. The only ones that needed fixing are the ones that are included in the resolution text. The vast majority were not using the technical meaning but the informal meaning. If you want, you can verify it by doing a search on "implementation" (not case sensitive, not full word) and checking them out. I'm pretty sure I got them all. Thanks...Bran "Thomas Weigert" 06/18/2004 03:40 PM To Branislav Selic/Ottawa/IBM@IBMCA, , cc Subject RE: Revised resolution to issue 6448 This raises the problem that we need to now change all the places where we used "implementation" to refer to the relationship between interface and classifier that realizes it. There are such places at least in internal structure... Probably also in interface and component... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Friday, June 18, 2004 2:16 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Revised resolution to issue 6448 Here is the promised revised resolution to issue 6448 following Thomas feedback (it was a "closed, no change" before). There is no semantic change involved, merely a renaming of the concept that was called "Implementation" into "InterfaceRealization". Note that in the metamodel, Implemenation was a specialization of Realization, so the new name is appropriate. This eliminates the confusion between the generic use of the term "implementation", which is used informally in hundreds of places throughout the spec, and the very specialized technically precise concept of "realization of an interface". I hope to include this resolution in ballot 17. Cheers...Bran