Issue 3783: Interface of an object (uml2-superstructure-ftf) Source: XTG, LLC (Mr. Joaquin Miller, nobody) Nature: Uncategorized Issue Severity: Summary: This is a request for an interpretation of UML 1.3. The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object? -------- Background ------- Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation." The UML submission said: "... An interface is only a collection of operations with a name; it cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." "UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object." UML 1.3 says: "2.5.4 Semantics "Interface "... An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any model element that is a subtype of Instance and corresponds to Interface. (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.) [It is clear that a UML model may include an object that is an instance of a class that realizes an interface.] -------- I am hoping this is easy to interpret and can be resolved quickly. Resolution: see below Revised Text: An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface. Since interfaces are declarations, they are not instantiable. Instead, an interface may be implemented by an instance of an instantiable classifier, which means that the instantiable classifier presents a public facade that conforms to the interface specification. Note that a given classifier may implement more than one interface and that an interface may be implemented by a number of different classifiers. (see “Implementation (from Interfaces)”). Actions taken: August 15, 2000: received issue March 8, 2005: closed issue Discussion: The answer is to the question at the beginning of the issue descripion is that there is no such model element, as objects in the UML do not have interfaces. Instead, interfaces are realized by classifiers which implies that the instances specified by that classifier will provide the services described by the interface. The issue originally asked for an interpretation of UML 1.3. Our answer will make no claim regarding UML 1.3. Our resolution will settle the issue in UML 2 by providing a clarified text on the subject. The UML 2 metamodel is clear in showing 1. Behaviored Classifiers are optionally related to Interfaces as the implementing classifier, where the implementation relationship is a specialization of realization. 2. Classes and Objects do not “have” Interfaces. Six ambiguous, misleading, and inappropriate usages on this topic remain in the UML 2 specification text, as identified in email discussion. Our resolution of this issue proposes some wordsmithing improvement. Interface is defined in the Classes chapter, Section 7.15 The Description subsection includes this text: An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. In a sense, an interface specifies a kind of contract which must be fulfilled by any instance of a classifier that realizes the interface. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface. Since interfaces are declarations, they are not directly instantiable. Instead, an interface specification is realized by an instance of a classifier, such as a class, which means that it presents a public facade that conforms to the interface specification. Note that a given classifier may realize more than one interface and that an interface may be realized by a number of different classifiers. There are six problems with this. 1. “In a sense is inappropriate language for a spec. We remove it. 2. The scope of the modal “must” is ambiguous in the statement “an interface specifies a kind of contract which must be fulfilled by any instance of a classifier that realizes the interface” The author did not mean that the contract must be fulfilled, but that if a classifier realizes the interface, then all instances of that classifier must fulfill the contract. 3. The phrase “a kind of” in the above is inappropriate. A revision that fixes these was agreed after discussion, would read as follows: An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract. 4. The term “specification” is redundant in the phrase “an interface specification”. 5. Another inadequacy is “an interface specification is realized by an instance of a classifier, such as a class…” The problem with this is that an interface is itself a classifier. The qualifier “instantiable” should be inserted. 6 In the abstract syntax, the relationship of an interface to the insta ntiable classifier is not realization, but implementation. Which specializes realization. The most specific applicable characterization is always the right one to use in a specification. Other examples of this misuse of realization have also been reported – here we only address those that are local to the Interfaces section of Chapter 7. Resolution Modify the text of the description subsection, for Interface in the Classes chapter to improve the 3 points discussed above. End of Annotations:===== Reply-To: Joaquin Miller Message-Id: <4.3.2.7.2.20000815110943.0210e420@pop3.joaquin.net> X-Sender: miller@joaquin.net@pop3.joaquin.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Aug 2000 16:29:00 -0700 To: juergen@omg.org From: Joaquin Miller Subject: UML 1.4 RTF issue Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: `]*!!)mF!!%9Ce9gG\!! Issue: Interface of an object This is a request for an interpretation of UML 1.3. The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object? -------- Background ------- Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation." The UML submission said: "... An interface is only a collection of operations with a name; it cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." "UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object." UML 1.3 says: "2.5.4 Semantics "Interface "... An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any model element that is a subtype of Instance and corresponds to Interface. (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.) [It is clear that a UML model may include an object that is an instance of a class that realizes an interface.] -------- I am hoping this is easy to interpret and can be resolved quickly. Cordially, Joaquin Miller Chief Architect Financial Systems Architects mailto:joaquin@acm.org San Francisco phone: +1 (510) 336-2545 fax: +1 (510) 336-2546 PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Reply-To: Joaquin Miller Message-Id: <5.1.0.14.2.20010815135621.01c59930@pop3.joaquin.net> X-Sender: miller@joaquin.net@pop3.joaquin.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 Aug 2001 14:07:09 -0700 To: UML-RTF From: Joaquin Miller Subject: issue 3783 -- First Anniversary Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_26957462==_.ALT" X-UIDL: kjBe9V)3!!L<&e9: ] ================================================================ Juergen Boldt Senior Member of Technical Staff Object Management Group Tel. +1-781 444 0404 ext. 132 250 First Avenue, Suite 201 Fax: +1-781 444 0320 Needham, MA 02494, USA Email: juergen@omg.org ================================================================ Subject: RE: issue 3783 -- First Anniversary Date: Thu, 16 Aug 2001 09:15:18 +0200 MIME-Version: 1.0 Message-ID: <2925F4D053DFBE44BC02176424D719BC023F04@dsserver2.datasim.nl> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 X-MS-TNEF-Correlator: Thread-Topic: issue 3783 -- First Anniversary Thread-Index: AcEl1taZDiSS/dIMS2+Rgen7obMFGwASz9xw From: "Daniel Duffy" To: "Joaquin Miller" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id f7G7Cgt04169 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: M8e!!Rbh!!?gO!!%]b!! The current definition includes those operations that an object offers (service providers) but does but does not include operations that an object *requires*. This may or may not be serious but the application of the definition preclude UML capsules and protocols. [It is clear that a UML model may include an object that is an instance of a class that realizes an interface.] IMO, this is a dangerous statement; are we talking about classic objects or about componets or both? UML needs to be precise otherwise we get the same discussions that we got in the early 90's about what the real definition of an object is. I find the definitions advocated by Selic and Rumbaugh a good starting point (capsules, protocols). Daniel Duffy -----Original Message----- From: Joaquin Miller [mailto:miller@joaquin.net] Sent: 15 August 2001 23:07 To: UML-RTF Subject: issue 3783 -- First Anniversary We celebrate today the first anniversary of the initial submission of issue 3783. Any news? ............ This is issue # 3783 Interface of an object This is a request for an interpretation of UML 1.3. The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object? -------- Background ------- Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation." The final UML submission said: "... An interface is only a collection of operations with a name; it cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." "UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object." UML 1.3 says: "2.5.4 Semantics "Interface "... An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any model element that is a subtype of Instance and corresponds to Interface. (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.) [It is clear that a UML model may include an object that is an instance of a class that realizes an interface.] -------- I am hoping this is easy to interpret and can be resolved quickly. [ Joaquin Miller ] ================================================================ Juergen Boldt Senior Member of Technical Staff Object Management Group Tel. +1-781 444 0404 ext. 132 250 First Avenue, Suite 201 Fax: +1-781 444 0320 Needham, MA 02494, USA Email: juergen@omg.org ================================================================ Reply-To: Joaquin Miller Message-Id: <5.1.0.14.2.20010824105330.02aeec88@pop3.joaquin.net> X-Sender: miller@joaquin.net@pop3.joaquin.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 Aug 2001 19:23:18 -0700 To: A&D TF , P UML , communityUML From: Joaquin Miller Subject: Anniversary Celebration: Does UML allow an interface on an object? Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_132809209==_.ALT" X-UIDL: J%-e9Z[$"!L5Be9GhJe9 Status: RO Today we celebrate the first anniversary of UML Issue 3783! Please join us by lighting a candle. ----------- This is the text of the issue and the list of actions taken by the UML RTF, copied today from the OMG web site: http://cgi.omg.org/issues/uml-rtf.html#Issue3783 Issue 3783: Interface of an object (uml-rtf) Click here for this issue's archive. Source: Financial Systems Architects (Mr. Joaquin Miller, joaquin@acm.org) Nature: Uncategorized Issue Severity: Summary: This is a request for an interpretation of UML 1.3. The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object? -------- Background ------- Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation." The UML submission said: "... An interface is only a collection of operations with a name; it cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." "UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object." UML 1.3 says: "2.5.4 Semantics "Interface "... An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any model element that is a subtype of Instance and corresponds to Interface. (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.) [It is clear that a UML model may include an object that is an instance of a class that realizes an interface.] I am hoping this is easy to interpret and can be resolved quickly. Resolution: Revised Text: Actions taken: August 15, 2000: received issue ======= end of issue as submitted ============== [ The issue was sent to OMG August 15th; the UML 1.4 RTF received the issue on August 23rd. We celebrate the anniversary of the day the RTF actually received the issue.] As we all know, in the CORBA Object Model, in the CORBA Component Model, and in architecture specifications, objects (or components) all do have interfaces. Though Big Bill denies it, even COM objects (or whatever he is calling them this year) have interfaces. Issue 3783 is a request for an answer to the question: Is this allowed in UML? ======== end of celebratory message =========== FAQs Q: Why does FSA ask this question? A: Well, for several reasons. The question has recently become more pressing as Financial Systems Architects is a submitter for UML 2.0 and the RFP requires that: "proposals shall ... provide a precise mapping between the current UML 1.x and the UML 2.0..." We need to know what the UML 1.4 specification means, so we can provide that mapping. Q: Anyway, isn't it clear from the UML 1.4 specification that an object {can | cannot } have interfaces? A: It sure looks like they can't. We just ask for a simple yes or know answer. So we can be sure we tell our clients the truth about UML. And so we can make a UML 2.0 submission responsive to Mandatory Requirement 6.5.2 (second bullet). Q: So, if FSA just wanted an answer, why did FSA file this with OMG as an issue for the RTF? A: Because, we asked how to get an interpretation and learned that the OMG procedure for getting a definitive interpretation of a specification is to file an issue (or so the OMG Technical Director and chief architect tells us, as quoted in the issue text). Q: I'm not familiar with the idea of an interface on an object? How would FSA use that? A: As architects, we want our blueprints to have objects representing specific systems and we want those object to have identifiable interfaces for communication with other objects. (We tend to use objects a lot; others might prefer to use subsystems or components.) Q: Can you give an example of why you want that? A: We have been working with a bank, planning a replacement for their system that handles some of the trades in USA Federal government securities. The bank clears trades for their clients, government security dealers and also clears trades on behalf of other banks. This particular system clears trades amounting to about four hundred billion dollars a day ($400,000,000). Problems can be caused when this system fails. We want to prepare blueprints that are as exact as we can make them (being architects, not engineers, abstract, but still: exact) and crystal clear. Now, each Federal Reserve Bank has interfaces of different types for exchanging messages with member banks. One type of interface is for settling security trades. The Bank deals with the FRB New York, and, on behalf of other banks, with the FRB Atlanta and other FRBs. Because the volume from their Wall Street customers is so large, and for reliability, the Bank has two securities clearance connections to interfaces at FRB New York. These two interfaces are dedicated by the FRB to the Bank. (Other member banks that clear security trades each have their own dedicated interface.) The bank must keep a record of which connection is used for each trade. They also have connections to interfaces of different types at FRB New York (for example, for money transfers), and of the same type at different FRBs. We want our blueprint to have: -- a specific, identified object, representing the FRB New York, (not FRB Atlanta; messages with that object are handled differently.) -- which object has two interfaces (two, not one.) -- and which two interfaces are of the same type (securities settlement, not money transfer) -- and which two interfaces are distinguished in the model (the model shows two of them, of the same type, with different names.) This is the only way we can represent, in our model, the actual situation. (We may someday, on another project at the Bank, need to show the same object (we call it frbNewYork:FRB) with a different type of interface, say one of its many money transfer interface. (After all, our client does, each day, transfer a lot of that $400 billion to other banks. And it handles other sums of money, too, for example for stock trade clearances or wire transfers for bank customers. So it uses interfaces of that type, too.)) That's one example. We have many others. Q: Why would I want to have a model like that? I mean one with interfaces on object, for crying out loud? A: For reasons that seem good to you. Or, quite possibly, you would not want to ever have any model like that. It might not suit your style. Or it might not agree with your idea of what an interface is. Q: But suppose the answer is yes. Or what if we (the ADTF) recommend adoption of a UML 2.0 with such a feature. Won't I then have to show interfaces on my objects? A: No. As they used to say: It's a free country. All we ask is the freedom to build models that accurately represent the practical needs of our clients. It's how we make our living. Please think of this as like freedom of religion. Q: But I don't want our architects to do that. If the answer is yes, or if we put that in UML 2.0, how can I prevent them? A: We propose prefaces in our UML 2.0 submission. They will do the job. Other submitters propose other extension mechanisms; they might do the job, too. Meanwhile, if the answer is yes: jawbone, or get them to use a profile that disallows that (if profiles can introduce restrictions). Q: So what does FSA really want? A: We will take 'no' for answer. Or yes. Cordially, Joaquin Miller Financial Systems Architects Date: Sat, 25 Aug 2001 13:20:01 -0700 From: Cris Kobryn Subject: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UML allow an interface on an object? In-reply-to: To: Thomas Weigert Cc: UML RTF , A&D TF , Joaquin Miller , P UML , communityUML , Thomas Weigert Reply-to: Cris.Kobryn@telelogic.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Type: text/plain; charset=iso-8859-1 X-UIDL: al2e9\>:!!M$ad9Ekf!! Status: RO > > at the RTF meeting on Thursday it was discussed that issue > http://cgi.omg.org/issues/uml-rtf.html#Issue3783 > (the issue with the one year birthday) had already been dispensed >with in > the 1.4 RTF. Please confirm that this was in fact the case. If not, >I > propose to resolve it in this RTF by providing a >clarification. Please let > me know whether this issue has or has not been resolved, and I > will provide the added text. This text should not go into the specification, but should > just be provided to the submitter of the issue. Thomas, I have already checked on the issues appendix for the UML 1.4 RTF final report (OMG document ad/01-02-11), and it appears that issue# 3783 was not addressed as it should have been. We will, of course, double check to make sure that no additional issues were missed. Please provide clarification asap, including recommended revision text as appropriate. Joaquin: Thanks for bringing this oversight to our attention. In the future, please feel free to do this immediately; you needn't wait for an anniversary. In any case, Happy Birthday, #3783! Thanks, Cris ------------------------------------------------------------------- Cris Kobryn Chief Technologist Telelogic Technologies Phone: +1-760-728-9747 Fax: +1-760-728-9749 E-mail: mailto:cris.kobryn@telelogic.com www: http://www.telelogic.com ------------------------------------------------------------------- Reply-To: From: "Thomas Weigert" To: "Thomas Weigert" , Cc: "UML RTF" Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UMLallow an interface on an object? Date: Sat, 25 Aug 2001 15:43:07 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01C12D7C.A343AAC0" X-UIDL: R;l!!)ff!!(+U!!ojf!! Status: RO I have attached an updated issue list with issue #3783 addressed. This issue requests a clarification and asks the question "Is there a UML 1.3 model element that represents the concept of an interface on an object?" I propose to answer "No". That is, there is no such model element, neither in UML 1.4, nor in UML 1.3. Instead, interfaces must be realized by classifiers which means that every instance of that classifier must have the features that are described in the interface. In terms of the RTF, I propose to reject this issue as no change to the UML is required. The text of the specification is quite clear on this issue. The description of issue #3783 quotes this text extensively and did not show any confusion or unclarity in the text of the specification. Th. > -----Original Message----- > From: Cris Kobryn [mailto:Cris.Kobryn@telelogic.com] > > at the RTF meeting on Thursday it was discussed that issue > > http://cgi.omg.org/issues/uml-rtf.html#Issue3783 > > (the issue with the one year birthday) had already been > dispensed with in > > the 1.4 RTF. Please confirm that this was in fact the case. If not, I > > propose to resolve it in this RTF by providing a clarification. > Please let > > me know whether this issue has or has not been resolved, and I > > will provide the added text. This text should not go into the > specification, but should > > just be provided to the submitter of the issue. > > Thomas, > > I have already checked on the issues appendix for the UML 1.4 RTF final > report (OMG document ad/01-02-11), and it appears that issue# 3783 was not > addressed as it should have been. > > We will, of course, double check to make sure that no additional > issues were > missed. > > Please provide clarification asap, including recommended revision text as > appropriate. > > Joaquin: Thanks for bringing this oversight to our attention. In > the future, > please feel free to do this immediately; you needn't wait for an > anniversary. In any case, Happy Birthday, #3783! > [] UML_1.5_RTF_Issues_010708_gr_byWG-jw-tw1.zip Date: Sat, 25 Aug 2001 13:46:03 -0700 From: Cris Kobryn Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UML allow an interface on an object? In-reply-to: To: Thomas Weigert , UML RTF , A&D TF , Joaquin Miller , P UML , communityUML Reply-to: Cris.Kobryn@telelogic.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Type: text/plain; charset=iso-8859-1 X-UIDL: *(6!!PFI!!NdCe9'N%e9 Status: RO > > I have already checked on the issues appendix for the UML 1.4 RTF > final report (OMG document ad/01-02-11), and it appears that > issue# 3783 was not addressed as it should have been. Clarification: please note that the final report doc# is ad/01-02-11, and the issues appendix is ad/01-02-12. Thanks, Cris Reply-To: From: "Conrad Bock" To: , "Thomas Weigert" , Cc: "UML RTF" , "Eran Gery" Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UMLallow an interface on an object? Date: Mon, 27 Aug 2001 15:24:38 -0700 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: -0md9Raj!!Ri@!!m9Me9 Status: RO Thomas, et al, > This issue requests a clarification and asks the question "Is there a UML > 1.3 model element that represents the concept of an interface on an object?" > I propose to answer "No". That is, there is no such model element, neither > in UML 1.4, nor in UML 1.3. Instead, interfaces must be realized by > classifiers which means that every instance of that classifier must have the > features that are described in the interface. > > In terms of the RTF, I propose to reject this issue as no change to the UML > is required. The text of the specification is quite clear on this issue. The > description of issue #3783 quotes this text extensively and did not show any > confusion or unclarity in the text of the specification. The last resolution I saw in the spreadsheet was defer to 2.0. I think this still should be the resolution. It is part of the larger discussion of how to properly model interfaces. In all component models, you can get a handle on an interface to an object, that is distinct from the interface supported by the class of the object. Conrad From: "Thomas Weigert" To: , "Thomas.Weigert" , Cc: "UML RTF" , "Eran Gery" Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UMLallow an interface on an object? Date: Mon, 27 Aug 2001 18:07:51 -0500 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: M?A!![7U!!Y"R!!7p!!! Status: RO This issue was new for 1.5, according to the issues dump. It was not in defer to 2.0. This issue simply asks a question: "Is there a UML 1.3 model element that represents the concept of an interface on an object?" This question can be simply answered. My conclusion is that the answer to this question is clear from the specification, so no change to the specification is required. Also, it is not necessary to defer to 2.0 to answer this question. The issue specifically did not ask for that feature to be added to UML. I conclude that there is no need to defer this issue to 2.0, and propose to resolve it as part of 1.5. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@kabira.com] > Sent: Monday, August 27, 2001 5:25 PM > The last resolution I saw in the spreadsheet was defer to 2.0. I > think this > still should be the resolution. It is part of the larger > discussion of how > to properly model interfaces. In all component models, you can > get a handle > on an interface to an object, that is distinct from the interface > supported > by the class of the object. > > Conrad > From: Edwin Seidewitz To: "'Guus Ramackers'" Cc: UML RTF Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Do es UMLallow an interface on an object? Date: Tue, 4 Sep 2001 11:44:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 4;3!!jP4e9lN?e9iI6!! Guus -- > -----Original Message----- > From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] > Sent: Tuesday, September 04, 2001 9:35 AM > To: Thomas Weigert > Cc: conrad.bock@kabira.com; Thomas.Weigert; Cris.Kobryn@telelogic.com; > UML RTF; Eran Gery > Subject: Re: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: > Does UMLallow an interface on an object? > > > Thomas, > > I agree (in principle) that we should not add anything to the > metamodel to > address this issue. > > Whilst the exact formulation of the issue might justify > simply closing it with > "rejected", I would propose to address this issue by: > > - clarifying in the text of the 1.5 specification that > indeed, objects can have > interfaces if the class realizes an interface > (and this should include a reference to "interface handles" > as Conrad raises, > as has been a long-term IDL/Corba issue) I think this is more than a "clarification". The reading of the specification to which Thomas refers seems to me to clearly indicate that objects CANNOT have interfaces. An object being an instance of a class that realizes an interface is NOT the same as the object having the interface. And it is certainly not the same as an "interface handle" to the object, since the handle effectively has an referencable "identity" separate from the object. > - clarifying the instance notation section to indicate how > this is diagrammed > (either explicitly in text or with a miniature example). I do not believe there is any clear way to diagram this at all in UML 1.4, at least not at the instance level. This is because there is no concrete subclass of the Instance metaclass that is tied to an interface (and Instance is abstract). Therefore, it is not possible to notate an "instance of an unspecified classifier that realizes a given interface" on an instance diagram. Interestingly enough, I do not believe this is a problem with collaboration diagrams using classifier roles. This is because a classifier role can have ANY classifier as its base, including an interface. Therefore it IS possible to notate "a role that may be filled by an instance of any classifier that realizes a given interface" and even show it involved in an interaction (though I am not sure the semantics of this are clearly described in the current specification). To me, this is just another indication that we really don't need instance-level modeling at all in UML, just collaboration modeling ("instances" as such should be an "execution" concept, not a modeling concept). But this is something to be addressed in UML 2.0, not UML 1.5. (Of course, I'm not even on the RTF any more!) -- Ed Ed Seidewitz, Chief Architect InteliData Technologies Office: +1.703.259.3076 Mobile: +1.301.455.3681 From: "Thomas Weigert" To: "Guus Ramackers" , "Thomas Weigert" Cc: , "Thomas.Weigert" , , "UML RTF" , "Eran Gery" Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UMLallow an interface on an object? Date: Tue, 4 Sep 2001 10:50:00 -0500 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3B94D899.7F78546C@oracle.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Type: text/plain; charset="us-ascii" X-UIDL: Z_L!!5@)!!ao\d98WKe9 Guus, I believe we should mark this item as "rejected" as it does not require any further clarification. It is clear from the specification, that objects do not have interfaces. The issue asked for a yes/no answer to the question whether there is a metamodel element representing interfaces on objects. The answer is clearly "No". My recommendation, as seconded by Jim, is to reject this issue. The issue did not request for any new features to be added to the UML, so we should not either. If interfaces on objects are required (albeit I don't understand what that would mean) somebody should open such an issue. Issue #3783 does not request this. Regards, Thomas. > -----Original Message----- > From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] > I agree (in principle) that we should not add anything to the metamodel to > address this issue. > > Whilst the exact formulation of the issue might justify simply > closing it with > "rejected", I would propose to address this issue by: > > - clarifying in the text of the 1.5 specification that indeed, > objects can have > interfaces if the class realizes an interface > (and this should include a reference to "interface handles" as > Conrad raises, > as has been a long-term IDL/Corba issue) > - clarifying the instance notation section to indicate how this > is diagrammed > (either explicitly in text or with a miniature example). > > Thanks, Guus > > > Thomas Weigert wrote: > > > This issue was new for 1.5, according to the issues dump. It was not in > > defer to 2.0. > > > > This issue simply asks a question: "Is there a UML 1.3 model > element that > > represents the concept of an interface on an object?" This > question can be > > simply answered. My conclusion is that the answer to this > question is clear > > from the specification, so no change to the specification is > required. Also, > > it is not necessary to defer to 2.0 to answer this question. > > > > The issue specifically did not ask for that feature to be added to UML. > > > > I conclude that there is no need to defer this issue to 2.0, > and propose to > > resolve it as part of 1.5. Date: Tue, 04 Sep 2001 10:07:28 -0700 From: Cris Kobryn Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UMLallow an interface on an object? In-reply-to: <3B94D6E0.BAEACD40@oracle.com> To: Guus Ramackers Cc: Thomas Weigert , UML RTF , A&D TF , Joaquin Miller , P UML , communityUML , Thomas Weigert Reply-to: Cris.Kobryn@telelogic.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Type: text/plain; charset=Windows-1252 X-UIDL: lpG!!dLQ!!!31e979%!! > > For the record, issue# 3783 was not addressed in the RTF 1.4 > exercise because it > was submitted beyond the May 2000 deadline. > It is therefore appropriately labeled "new for 1.5" and will be > addressed by the > 1.5 RTF. Guus, Thanks for the correction and clarification. -- Cris > > > > > > at the RTF meeting on Thursday it was discussed that issue > > > http://cgi.omg.org/issues/uml-rtf.html#Issue3783 > > > (the issue with the one year birthday) had already been > dispensed with in > > > the 1.4 RTF. Please confirm that this was in fact the case. If > > >not, I > > > propose to resolve it in this RTF by providing a > clarification. Please let > > > me know whether this issue has or has not been resolved, and I > > > will provide the added text. This text should not go into the > > specification, but should > > > just be provided to the submitter of the issue. > > > > Thomas, > > > > I have already checked on the issues appendix for the UML 1.4 RTF > > >final > > report (OMG document ad/01-02-11), and it appears that issue# > 3783 was not > > addressed as it should have been. > > > > We will, of course, double check to make sure that no > additional issues were > > missed. > > > > Please provide clarification asap, including recommended > revision text as > > appropriate. > > > > Joaquin: Thanks for bringing this oversight to our attention. > In the future, > > please feel free to do this immediately; you needn't wait for an > > anniversary. In any case, Happy Birthday, #3783! > > > > Thanks, > > > > Cris > > > > > > >------------------------------------------------------------------- > > Cris Kobryn > > Chief Technologist > > Telelogic Technologies > > > > Phone: +1-760-728-9747 > > Fax: +1-760-728-9749 > > E-mail: mailto:cris.kobryn@telelogic.com > > www: http://www.telelogic.com > > > > >------------------------------------------------------------------- > > -- > Guus Ramackers > Product Manager UML Products, Oracle > JDeveloper Tools group > 520 Oracle Parkway, TVP > Reading RG6 1RA, UK > e-mail: guus.ramackers@oracle.com > work: +44-(0)1189-245101 > fax: +44-(0)1189-245148 > > > Date: Tue, 04 Sep 2001 13:22:02 -0400 From: Jim Logan Organization: Longitude Systems, Inc. X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Edwin Seidewitz CC: "'Guus Ramackers'" , UML RTF Subject: Re: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UMLallow an interface on an object? References: Content-Type: multipart/mixed; boundary="------------2311BB75225F28F8591A72E1" X-UIDL: /4Ce9 Message-Id: <5.1.0.14.2.20010904111940.0361ef20@pop3.joaquin.net> X-Sender: miller@joaquin.net@pop3.joaquin.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 11:37:31 -0700 To: UML RTF From: Joaquin Miller Subject: Re: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UML allow an interface on an object? Cc: Trygve Reenskaug In-Reply-To: <3B950DBA.19509DCD@longsys.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_17682906==_.ALT" X-UIDL: LAh!!R<0!!"OU!!=:Ee9 Edwin Seidewitz wrote: To me, this is just another indication that we really don't need instance-level modeling at all in UML, just collaboration modeling ("instances" as such should be an "execution" concept, not a modeling concept). But this is something to be addressed in UML 2.0, not UML 1.5. (Of course, I'm not even on the RTF any more!) Jim Logan wrote: One thing I often find helpful in communicating a design is a worked example in the form of an instance diagram. I would hate to have it removed from the UML. Collaboration diagrams are only partially helpful because the focus of the diagram is on the messages, not the instances' states. As architects, we need to specify the actual system. We have never been able to see any way to do that except for one: to have items in the model that represent particular parts of the system. If we are going to specify a system with TheBankClearanceServer, FRBNewYork, and FRBAtlanta, we are sure there are hacks that allow us to do this with Classes or Roles, but we, as a matter of good style, prefer to do it with three Objects (or SubSystemInstances). (Two of one class and one of another: TheBankClearanceServer:ClearanceServer, FRBNewYork:FedWireHub, and FRBAtlanta:FedWireHub). We certainly also make use of the truth that Ed points out: Collaboration models serve most purposes. (Trygve tells us that we really don't need class-level modeling at all in UML, just collaboration modeling.) We will specify most of the details of interaction between /aClearanceServer and /aFedWireHub using collaborations. The differences between interacting with the big Fed in New York and with the country Fed in Atlanta, well, we sure do like the idea of showing that in a model using objects to represent the different Federal Reserve Banks. Just as Jim suggests. For example, TheBank has different credit limits at the two FRBs, and handles the management of these credit lines differently. (Jim's focus on the state of instances.) .......... Question: Does the UML specification really need three boxes for every concept: Type, Role, Instance? Maybe it does. But the question may be worth some thought. From: Edwin Seidewitz To: UML RTF Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Do es UMLallow an interface on an object? Date: Tue, 4 Sep 2001 17:39:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1358A.04299EC0" X-UIDL: JZ5!!\o4e9&Ob!!+bc!! -----Original Message----- From: Selic, Bran [mailto:bselic@rational.com] Sent: Tuesday, September 04, 2001 5:18 PM To: 'Jim Logan'; Edwin Seidewitz Cc: 'Guus Ramackers'; UML RTF Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Do es UMLallow an interface on an object? One other argument for modeling instances: in many analyses methods used in real-time systems (schedulability, performance analyses, etc.), it is absolutely fundamental to differentiate specific instances and their characteristics. Roles don't do the job, unless you overload roles with instance semantics (i.e., each role represents a specific instance). This may be what Ed meant -- you can always choose to interpret (constrain) a role model as an instance model. I have, indeed, argued in the past that modeling an instance is just a tightly constrained role. I think you can actually combine the concepts of "instance role" ("classifier" role is really a misnomer) and "modeled instance" and have one kind of instance/collaboration modeling notation. And this should be kept distinct from the concept of "instance in execution". (Bran, I actually remember you making a point about this latter distinction way, way back in the UML 1.3 RTF...) But, who cares what Ed meant, he's not in the RTF anyway ;-) And I'm not a UML 2.0 submitter either! -- Ed Ed Seidewitz, Chief Architect InteliData Technologies Office: +1.703.259.3076 Mobile: +1.301.455.3681 Reply-To: Joaquin Miller Message-Id: <5.1.0.14.2.20010904153019.0b50a008@pop3.joaquin.net> X-Sender: miller@joaquin.net@pop3.joaquin.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Sep 2001 16:08:29 -0700 To: UML RTF From: Joaquin Miller Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UML allow an interface on an object? In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_34284768==_.ALT" X-UIDL: P#*!!4?3e9c_Y!!S<$!! [Bran Selic] One other argument for modeling instances: in many analyses methods used in real-time systems (schedulability, performance analyses, etc.), it is absolutely fundamental to differentiate specific instances and their characteristics. Roles don't do the job, unless you overload roles with instance semantics (i.e., each role represents a specific instance). This may be what Ed meant -- you can always choose to interpret (constrain) a role model as an instance model. [Edwin Seidewitz] I have, indeed, argued in the past that modeling an instance is just a tightly constrained role. I think you can actually combine the concepts of "instance role" ("classifier" role is really a misnomer) and "modeled instance" and have one kind of instance/collaboration modeling notation. And this should be kept distinct from the concept of "instance in execution". (Bran, I actually remember you making a point about this latter distinction way, way back in the UML 1.3 RTF...) We'll remember that Trygve gave us this metaphor for role (UML classifier role): a role is an object, but we are not saying which one. In that sense, Ed is certainly right. Since Ed is such a swell guy, he won't take offense if i put it this way: Rather than limiting UML 2.0 users to that hack, an alternative is to accept what Ed proposes and then to define an object (or instance) model (as opposed to a regular role model or collaboration) as a special case of collaboration in which we _are_ saying which one. We get the simplification that Ed proposes, and the more comfortable feeling of Bran's way, where we actually get to call them boxes objects. An alternative simplification is to start with the instances (objects) and use Trygve's approach to defining role.* Either way, Ed is right, we can combine the notations. And, either way, Trygve is certainly right: we do not need to specify two "levels" of collaboration. [ * or use an axiomatic approach. ] ================== " role: a named slot within an object structure that represents behavior of an element that participates in a context (as opposed to the inherent qualities of the element across all usages)... " Jim Rumbaugh, Reference Manual From: "Desmond D'Souza" To: "Edwin Seidewitz" , "UML RTF" Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Do es UMLallow an interface on an object? Date: Tue, 4 Sep 2001 21:49:44 -0500 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C1358B.821ADF50" X-UIDL: IPb!!6BVd9%a"e9pM9e9 Ed, I think your proposal is a good one (we might still need a way to indicate your "tightly constrained" role). To Jim Logan's earlier comment: imo, "snapshot" and "collaboration" are distinct concepts, though they should share some bits of both notation and semantics. - Desmond -----Original Message----- From: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] Sent: Tuesday, September 04, 2001 4:39 PM To: UML RTF Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Do es UMLallow an interface on an object? -----Original Message----- From: Selic, Bran [mailto:bselic@rational.com] Sent: Tuesday, September 04, 2001 5:18 PM To: 'Jim Logan'; Edwin Seidewitz Cc: 'Guus Ramackers'; UML RTF Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Do es UMLallow an interface on an object? One other argument for modeling instances: in many analyses methods used in real-time systems (schedulability, performance analyses, etc.), it is absolutely fundamental to differentiate specific instances and their characteristics. Roles don't do the job, unless you overload roles with instance semantics (i.e., each role represents a specific instance). This may be what Ed meant -- you can always choose to interpret (constrain) a role model as an instance model. I have, indeed, argued in the past that modeling an instance is just a tightly constrained role. I think you can actually combine the concepts of "instance role" ("classifier" role is really a misnomer) and "modeled instance" and have one kind of instance/collaboration modeling notation. And this should be kept distinct from the concept of "instance in execution". (Bran, I actually remember you making a point about this latter distinction way, way back in the UML 1.3 RTF...) From: Kondo Ilir To: "'Desmond D'Souza '" , "'Edwin Seidewitz '" , "'UML RTF '" Subject: AW: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Do es UMLallow an interface on an object? Date: Wed, 5 Sep 2001 22:38:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-UIDL: bi$!!/j2!!CB]!!i38e9 Perhaps my position might be ruther simplistic, but anyway: I think the real issue is the meaning of *role* and its relationship to the interface (cf. *type*) concept. After my opinion, role == type. In the context of a collaboration one prefers to speak in term of roles rather then interfaces or better to say types or set of objects with a specific behavior(1). So the question if UML allows an interface on an object may be answered with an *almost* YES while: - An object can have a isInstanceOf (dependecy) relationship to a proper type (I do not intend here to branch into the other discussion and speak about how types in UML can be represented using <>class - see the recent discussion about the stereotype semantic) - There is already an *almost* clear convention/notation how to relate domain classes in a collaboration (dashed line + binding, i.e. role name of a specific domain class that its object participate in collaboration). A defintive solution to the problem would be: - When speaking about collaboration relate them to roles (== types) only. This would make 'binding' obsolete and even misleading. The dashed line alone will do. - Introduce role cardinalities and even use isInstanceOf to relate an object to its role (== type) if necessary; this would resolve the "tightly constrained" role problem. regards, ilir (kondo) (1) "Type: A set of objects that conforms to a given type spec throughout their lives....Type spec: A description of object behavior. It typically consists of of a collection of action specs and a static model of attributes that help describe the effects of those actions. A type spec makes no statement about implementation." - from "Objects, Components and Frameworks with UML - The Catalysis Approach". -----Originalnachricht----- Von: Desmond D'Souza An: Edwin Seidewitz; UML RTF Gesendet: 05.09.01 04:49 Betreff: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Do es UMLallow an interface on an object? Ed, I think your proposal is a good one (we might still need a way to indicate your "tightly constrained" role). To Jim Logan's earlier comment: imo, "snapshot" and "collaboration" are distinct concepts, though they should share some bits of both notation and semantics. - Desmond -----Original Message----- From: Edwin Seidewitz [mailto:eseidewitz@intelidata.com] Sent: Tuesday, September 04, 2001 4:39 PM To: UML RTF Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Do es UMLallow an interface on an object? -----Original Message----- From: Selic, Bran [mailto:bselic@rational.com] Sent: Tuesday, September 04, 2001 5:18 PM To: 'Jim Logan'; Edwin Seidewitz Cc: 'Guus Ramackers'; UML RTF Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Do es UMLallow an interface on an object? One other argument for modeling instances: in many analyses methods used in real-time systems (schedulability, performance analyses, etc.), it is absolutely fundamental to differentiate specific instances and their characteristics. Roles don't do the job, unless you overload roles with instance semantics (i.e., each role represents a specific instance). This may be what Ed meant -- you can always choose to interpret (constrain) a role model as an instance model. I have, indeed, argued in the past that modeling an instance is just a tightly constrained role. I think you can actually combine the concepts of "instance role" ("classifier" role is really a misnomer) and "modeled instance" and have one kind of instance/collaboration modeling notation. And this should be kept distinct from the concept of "instance in execution". (Bran, I actually remember you making a point about this latter distinction way, way back in the UML 1.3 RTF...) Sender: bg_wenzel@csi.com Received: from esdepc11 (fra-tgn-oyd-vty13.as.wcom.net [212.211.83.13]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with SMTP id OAA09768; Thu, 6 Sep 2001 14:18:41 -0400 (EDT) Message-ID: <005801c13700$7f890b60$4d540ec1@esdepc11> Reply-To: "Bernd G. Wenzel" From: "Bernd G. Wenzel" To: "Joaquin Miller" Cc: "UML RTF" References: Subject: Re: [communityUML] RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UML allow an interface on an object? Date: Thu, 6 Sep 2001 20:17:42 +0200 Organization: Eurostep GmbH MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ]_ld9lS=!!X`;!!I\Nd9 Joaquin, being an expert for the structuring of physical products, I consider the distinction between roles and instances fairly important. If the UML community can agree on an approach, which is consistent with the structures for physical products, we'll improve the applicability of UML for embedded software, but also for other engineering disciplines quite a lot. The fundamental difference between role and instance is, that role is conceptual while instance is physical. As a consequence, roles define requirements and behaviour, but it is the task of an instance implementing a role to fulfil the requirements and to deliver the behaviour. Very often we use the role identity to refer to the instance implementing the role at present. The computer network of a small company may for instance contain a print server (role). The fact, that this same machine (now I'm talking about the instance) served as the system administrator's desk top computer (another role) until a year ago doesn't matter. When I ask the system administrator to defragment the disk of the print server, he will know what to do. But we must never forget the fundamental integrity constraint for roles: A system can only be put into operation, if there are instances implementing each and every role. I may run a simulation of my system, if the definition of my roles is sufficiently complete, but not my physical system itself. This is what we software guys should learn. I our world, this distinction is fading away. If my role definition is sufficiently complete, I can compile it into executable code. But let's not forget, that this is not the case for hardware. Here the difference between a complete specification and the real product is critical. BTW, this distinction is also quite important in the software domain, at least when it comes to software re-usability. Simply speaking, re-usable software is software, which can implement more than one role. If I wasn't clear enough, please ask questions. :-) Bernd --------------------------------- Bernd G. Wenzel Ganghoferstrae 7b D-83043 Bad Aibling Germany Phone: +49-8061-37232 Fax: +49-8061-92018 Mobile: +49-170-9983565 Email: bg_wenzel@csi.com ----- Original Message ----- From: Joaquin Miller To: UML RTF Sent: Wednesday, September 05, 2001 1:08 AM Subject: [communityUML] RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UML allow an interface on an object? > > > > >>[Bran Selic] One other argument for modeling instances: in many analyses > >>methods used in real-time systems (schedulability, performance analyses, > >>etc.), it is absolutely fundamental to differentiate specific instances > >>and their characteristics. Roles don't do the job, unless you overload > >>roles with instance semantics (i.e., each role represents a specific > >>instance). This may be what Ed meant -- you can always choose to > >>interpret (constrain) a role model as an instance model. > >[Edwin Seidewitz] I have, indeed, argued in the past that modeling an > >instance is just a tightly constrained role. I think you can actually > >combine the concepts of "instance role" ("classifier" role is really a > >misnomer) and "modeled instance" and have one kind of > >instance/collaboration modeling notation. And this should be kept distinct > >from the concept of "instance in execution". (Bran, I actually remember > >you making a point about this latter distinction way, way back in the UML > >1.3 RTF...) > > We'll remember that Trygve gave us this metaphor for role (UML classifier > role): > a role is an object, but we are not saying which one. > > In that sense, Ed is certainly right. > > Since Ed is such a swell guy, he won't take offense if i put it this way: > > Rather than limiting UML 2.0 users to that hack, an alternative is to > accept what Ed proposes and then to define an object (or instance) model > (as opposed to a regular role model or collaboration) as a special case of > collaboration in which we _are_ saying which one. > > We get the simplification that Ed proposes, and the more comfortable > feeling of Bran's way, where we actually get to call them boxes objects. > > An alternative simplification is to start with the instances (objects) and > use Trygve's approach to defining role.* > > Either way, Ed is right, we can combine the notations. > And, either way, Trygve is certainly right: we do not need to specify two > "levels" of > > " role: a named slot within an object structure that represents behavior of > an element that participates in a context (as opposed to the inherent > qualities of the element across all usages)... " Jim Rumbaugh, Reference > Manual > > > --------------------------------------------------------------- -------------- > A reply will go only to the sender. > Reply all if you wish to send your message to the entire list. > A blank message to these addresses performs the following - > communityUML-on@mail-list.com gets you on the list. > communityUML-off@mail-list.com gets you off the list. > communityUML-switch@mail-list.com toggles you to/from the fancy digest version. > communityUML-vacation@mail-list.com toggles you to/from the vacation list. > > Post your message to the list by sending it to communityUML@mail-list.com. > > To contact the list owner, send your message to > communityUML-list-owner@mail-list.com. > > > Add to the wiki. http://www.community-ML.org < > Reply-To: Joaquin Miller Message-Id: <5.1.0.14.2.20010906112843.03a5edb0@pop3.joaquin.net> X-Sender: miller@joaquin.net@pop3.joaquin.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Sep 2001 11:38:54 -0700 To: "Bernd G. Wenzel" From: Joaquin Miller Subject: Re: [communityUML] RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UML allow an interface on an object? Cc: "UML RTF" In-Reply-To: <005801c13700$7f890b60$4d540ec1@esdepc11> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10822151==_.ALT" X-UIDL: gf1e9~P$!!3!*!!Sf[!! Bernd, i agree completely.* That is why i used 'metaphor.' > We'll remember that Trygve gave us this metaphor for role (UML classifier role): > a role is an object, but we are not saying which one. a role is not an object, but it is a good metaphor. ....... * you wrote: The fundamental difference between role and instance is, that role is conceptual while instance is physical. Yes, in the structuring of physical products., In software architecture models, the case is slightly different: The fundamental difference between role and object in a model is, that role represents something conceptual about the system specified while object represents something physical in the system (maybe some wave functions flittering in some potential wells: the slots of a Java object). We have no disagreement here. Just different viewpoints. A UML 2.0 that can not describe the world of physical products will have missed the mark. ========= original message ================ From: "Bernd G. Wenzel" To: "Joaquin Miller" Cc: "UML RTF" Subject: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UML allow an interface on an object? Date: Thu, 6 Sep 2001 20:17:42 +0200 Joaquin, being an expert for the structuring of physical products, I consider the distinction between roles and instances fairly important. If the UML community can agree on an approach, which is consistent with the structures for physical products, we'll improve the applicability of UML for embedded software, but also for other engineering disciplines quite a lot. The fundamental difference between role and instance is, that role is conceptual while instance is physical. As a consequence, roles define requirements and behaviour, but it is the task of an instance implementing a role to fulfil the requirements and to deliver the behaviour. Very often we use the role identity to refer to the instance implementing the role at present. The computer network of a small company may for instance contain a print server (role). The fact, that this same machine (now I'm talking about the instance) served as the system administrator's desk top computer (another role) until a year ago doesn't matter. When I ask the system administrator to defragment the disk of the print server, he will know what to do. But we must never forget the fundamental integrity constraint for roles: A system can only be put into operation, if there are instances implementing each and every role. I may run a simulation of my system, if the definition of my roles is sufficiently complete, but not my physical system itself. This is what we software guys should learn. I our world, this distinction is fading away. If my role definition is sufficiently complete, I can compile it into executable code. But let's not forget, that this is not the case for hardware. Here the difference between a complete specification and the real product is critical. BTW, this distinction is also quite important in the software domain, at least when it comes to software re-usability. Simply speaking, re-usable software is software, which can implement more than one role. If I wasn't clear enough, please ask questions. :-) Bernd --------------------------------- Bernd G. Wenzel Ganghoferstrae 7b D-83043 Bad Aibling Germany Phone: +49-8061-37232 Fax: +49-8061-92018 Mobile: +49-170-9983565 Email: bg_wenzel@csi.com ----- Original Message ----- From: Joaquin Miller To: UML RTF Sent: Wednesday, September 05, 2001 1:08 AM Subject: [communityUML] RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UML allow an interface on an object? > > > > >>[Bran Selic] One other argument for modeling instances: in many analyses > >>methods used in real-time systems (schedulability, performance analyses, > >>etc.), it is absolutely fundamental to differentiate specific instances > >>and their characteristics. Roles don't do the job, unless you overload > >>roles with instance semantics (i.e., each role represents a specific > >>instance). This may be what Ed meant -- you can always choose to > >>interpret (constrain) a role model as an instance model. > >[Edwin Seidewitz] I have, indeed, argued in the past that modeling an > >instance is just a tightly constrained role. I think you can actually > >combine the concepts of "instance role" ("classifier" role is really a > >misnomer) and "modeled instance" and have one kind of > >instance/collaboration modeling notation. And this should be kept distinct > >from the concept of "instance in execution". (Bran, I actually remember > >you making a point about this latter distinction way, way back in the UML > >1.3 RTF...) > > We'll remember that Trygve gave us this metaphor for role (UML classifier > role): > a role is an object, but we are not saying which one. > > In that sense, Ed is certainly right. > > Since Ed is such a swell guy, he won't take offense if i put it this way: > > Rather than limiting UML 2.0 users to that hack, an alternative is to > accept what Ed proposes and then to define an object (or instance) model > (as opposed to a regular role model or collaboration) as a special case of > collaboration in which we _are_ saying which one. > > We get the simplification that Ed proposes, and the more comfortable > feeling of Bran's way, where we actually get to call them boxes objects. > > An alternative simplification is to start with the instances (objects) and > use Trygve's approach to defining role.* > > Either way, Ed is right, we can combine the notations. > And, either way, Trygve is certainly right: we do not need to specify two > "levels" of > > " role: a named slot within an object structure that represents behavior of > an element that participates in a context (as opposed to the inherent > qualities of the element across all usages)... " Jim Rumbaugh, Reference > Manual > > > --------------------------------------------------------------- -------------- > A reply will go only to the sender. > Reply all if you wish to send your message to the entire list. > A blank message to these addresses performs the following - > communityUML-on@mail-list.com gets you on the list. > communityUML-off@mail-list.com gets you off the list. > communityUML-switch@mail-list.com toggles you to/from the fancy digest version. > communityUML-vacation@mail-list.com toggles you to/from the vacation list. > > Post your message to the list by sending it to communityUML@mail-list.com. > > To contact the list owner, send your message to > communityUML-list-owner@mail-list.com. > > > Add to the wiki. http://www.community-ML.org < > PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 From: LONJON Antoine To: "'Joaquin Miller'" , "Bernd G. Wenzel" Cc: UML RTF Subject: RE: [communityUML] RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversa ry Celebration: Does UML allow an interface on an object? Date: Thu, 6 Sep 2001 16:57:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: GJ5!!Q1#!! > We'll remember that Trygve gave us this metaphor for role (UML > classifier role): > > a role is an object, but we are not saying which one. a role is not an object, but it is a good metaphor. ....... * you wrote: > The fundamental difference between role and instance is, that role is > conceptual while instance is physical. Yes, in the structuring of physical products., In software architecture models, the case is slightly different: The fundamental difference between role and object in a model is, that role represents something conceptual about the system specified while object represents something physical in the system (maybe some wave functions flittering in some potential wells: the slots of a Java object). We have no disagreement here. Just different viewpoints. A UML 2.0 that can not describe the world of physical products will have missed the mark. ========= original message ================ From: "Bernd G. Wenzel" To: "Joaquin Miller" Cc: "UML RTF" Subject: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UML allow an interface on an object? Date: Thu, 6 Sep 2001 20:17:42 +0200 Joaquin, being an expert for the structuring of physical products, I consider the distinction between roles and instances fairly important. If the UML community can agree on an approach, which is consistent with the structures for physical products, we'll improve the applicability of UML for embedded software, but also for other engineering disciplines quite a lot. The fundamental difference between role and instance is, that role is conceptual while instance is physical. As a consequence, roles define requirements and behaviour, but it is the task of an instance implementing a role to fulfil the requirements and to deliver the behaviour. Very often we use the role identity to refer to the instance implementing the role at present. The computer network of a small company may for instance contain a print server (role). The fact, that this same machine (now I'm talking about the instance) served as the system administrator's desk top computer (another role) until a year ago doesn't matter. When I ask the system administrator to defragment the disk of the print server, he will know what to do. But we must never forget the fundamental integrity constraint for roles: A system can only be put into operation, if there are instances implementing each and every role. I may run a simulation of my system, if the definition of my roles is sufficiently complete, but not my physical system itself. This is what we software guys should learn. I our world, this distinction is fading away. If my role definition is sufficiently complete, I can compile it into executable code. But let's not forget, that this is not the case for hardware. Here the difference between a complete specification and the real product is critical. BTW, this distinction is also quite important in the software domain, at least when it comes to software re-usability. Simply speaking, re-usable software is software, which can implement more than one role. If I wasn't clear enough, please ask questions. :-) Bernd --------------------------------- Bernd G. Wenzel Ganghoferstrae 7b D-83043 Bad Aibling Germany Phone: +49-8061-37232 Fax: +49-8061-92018 Mobile: +49-170-9983565 Email: bg_wenzel@csi.com ----- Original Message ----- From: Joaquin Miller To: UML RTF Sent: Wednesday, September 05, 2001 1:08 AM Subject: [communityUML] RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UML allow an interface on an object? > > > > >>[Bran Selic] One other argument for modeling instances: in many analyses > >>methods used in real-time systems (schedulability, performance analyses, > >>etc.), it is absolutely fundamental to differentiate specific instances > >>and their characteristics. Roles don't do the job, unless you overload > >>roles with instance semantics (i.e., each role represents a specific > >>instance). This may be what Ed meant -- you can always choose to > >>interpret (constrain) a role model as an instance model. > >[Edwin Seidewitz] I have, indeed, argued in the past that modeling an > >instance is just a tightly constrained role. I think you can actually > >combine the concepts of "instance role" ("classifier" role is really a > >misnomer) and "modeled instance" and have one kind of > >instance/collaboration modeling notation. And this should be kept distinct > >from the concept of "instance in execution". (Bran, I actually remember > >you making a point about this latter distinction way, way back in the UML > >1.3 RTF...) > > We'll remember that Trygve gave us this metaphor for role (UML classifier > role): > a role is an object, but we are not saying which one. > > In that sense, Ed is certainly right. > > Since Ed is such a swell guy, he won't take offense if i put it this way: > > Rather than limiting UML 2.0 users to that hack, an alternative is to > accept what Ed proposes and then to define an object (or instance) model > (as opposed to a regular role model or collaboration) as a special case of > collaboration in which we _are_ saying which one. > > We get the simplification that Ed proposes, and the more comfortable > feeling of Bran's way, where we actually get to call them boxes objects. > > An alternative simplification is to start with the instances (objects) and > use Trygve's approach to defining role.* > > Either way, Ed is right, we can combine the notations. > And, either way, Trygve is certainly right: we do not need to specify two > "levels" of > > " role: a named slot within an object structure that represents behavior of > an element that participates in a context (as opposed to the inherent > qualities of the element across all usages)... " Jim Rumbaugh, Reference > Manual > > > --------------------------------------------------------------- -------------- > A reply will go only to the sender. > Reply all if you wish to send your message to the entire list. > A blank message to these addresses performs the following - > communityUML-on@mail-list.com gets you on the list. > communityUML-off@mail-list.com gets you off the list. > communityUML-switch@mail-list.com toggles you to/from the fancy digest version. > communityUML-vacation@mail-list.com toggles you to/from the vacation list. > > Post your message to the list by sending it to communityUML@mail-list.com. > > To contact the list owner, send your message to > communityUML-list-owner@mail-list.com. > > > Add to the wiki. http://www.community-ML.org < > PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Date: Thu, 06 Sep 2001 16:58:05 -0400 From: Jim Logan Organization: Longitude Systems, Inc. X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joaquin Miller , "Bernd G. Wenzel" CC: UML RTF Subject: Re: [communityUML] RE: UML RTF: Issue 3783 | a.k.a. RE:Anniversary Celebration: Does UML allow an interface on an object? References: Content-Type: multipart/mixed; boundary="------------ECE736B58EF858BCBCAD94AB" X-UIDL: Go-e9-I/e9gI$e9 Joaquin Miller wrote: Bernd, i agree completely.* That is why i used 'metaphor.' > > We'll remember that Trygve gave us this metaphor for role (UML > classifier role): > > a role is an object, but we are not saying which one. a role is not an object, but it is a good metaphor. ....... * you wrote: > The fundamental difference between role and instance is, that role is > conceptual while instance is physical. Yes, in the structuring of physical products., In software architecture models, the case is slightly different: The fundamental difference between role and object in a model is, that role represents something conceptual about the system specified while object represents something physical in the system (maybe some wave functions flittering in some potential wells: the slots of a Java object). We have no disagreement here. Just different viewpoints. A UML 2.0 that can not describe the world of physical products will have missed the mark. Bernd says, "The fundamental difference between role and instance is, that role is conceptual while instance is physical." I don't understand what you would call an object in memory that represents a physical entity, like a real airplane. I could call the UML-modeled instance a role, the memory object a logical instance, and the airplane a physical instance. What would you two call these things? FWIW, I have had the same problem with the 4-layer architecture in the UML and MOF specs. Object instances can model real-life instances, which would imply there is a layer M -1. For example, I can have a physical network, a model of my network in some system, and a model of that system in UML. The OMG definition of the word model used to cause an "impedance mismatch" with some people until I discovered the cause. Cheers, -Jim -- Wisdom begins when we discover the difference between "That makes no sense", and "I don't understand". -- Mary Doria Russell [] logan.vcf Sender: bg_wenzel@csi.com Received: from esdepc11 (fra-tgn-ozc-vty11.as.wcom.net [195.232.61.11]) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with SMTP id IAA23216; Fri, 7 Sep 2001 08:21:27 -0400 (EDT) Message-ID: <005b01c13797$c05882a0$4d540ec1@esdepc11> Reply-To: "Bernd G. Wenzel" From: "Bernd G. Wenzel" To: "Jim Logan" Cc: "UML RTF" References: <3B97E35C.23DC0001@longsys.com> Subject: Re: [communityUML] RE: UML RTF: Issue 3783 | a.k.a. RE:Anniversary Celebration: Does UML allow an interface on an object? Date: Fri, 7 Sep 2001 13:52:03 +0200 Organization: Eurostep GmbH MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 4RM!!@\T!!OS"e9^O!"! Jim, I knew, I shouldn't have got myself into this exchange when I wrote my message. I couldn't resist and now should follow it through. One thing I forgot to mention yesterday is, that roles have only meaning in the context of a system, a process, a collaboration, - maybe more - even though this context is implicit occasionally. A role is an identified subset of the functionality of a system. As such, it is associated with the definition of the required and/or expected characteristics of the instance (thing or process) implementing this functionality, including its behavioural and performance characteristics. Based on my attempt for a definition of "role" above, I do not see any roles in your question below. What I see are three objects (one in the UML model, one in memory, and one in the air somewhere). In addition, I see relations between them, such as - the aircraft in the air is represented by the object in memory. - the aircraft in the air is represented by the object in the UML model. - the object in memory is derived from the object in the UML model. What I cannot derive from your message is the existence of an implementation relation, as compared to the representation and derivation relations above. You may for example have written your message within the implicit context of a flight scheduling system. Then the object in your UML model may be the aircraft to be used for flight UA2345 today. That would be a role according to my understanding. I may however totally missed your point, because all I've said so far must be understood in the context of instances. I'm talking about an aircraft identified by frame number 4722 and the memory object on address 38348485 on my computer. This is consistent with what you wrote, but natural languages are imprecise, when it comes to the distinction between types and their elements. So, if your UML object and/or your memory object was a representation of the type B777 I have not answered your question. In this case, please let me know and I will try to do so. :-) Bernd ----- Original Message ----- From: Jim Logan To: Joaquin Miller ; Bernd G. Wenzel Cc: UML RTF Sent: Thursday, September 06, 2001 10:58 PM Subject: Re: [communityUML] RE: UML RTF: Issue 3783 | a.k.a. RE:Anniversary Celebration: Does UML allow an interface on an object? Joaquin Miller wrote: Bernd, i agree completely.* That is why i used 'metaphor.' > > We'll remember that Trygve gave us this metaphor for role (UML > classifier role): > > a role is an object, but we are not saying which one. a role is not an object, but it is a good metaphor. ....... * you wrote: > The fundamental difference between role and instance is, that role is > conceptual while instance is physical. Yes, in the structuring of physical products., In software architecture models, the case is slightly different: The fundamental difference between role and object in a model is, that role represents something conceptual about the system specified while object represents something physical in the system (maybe some wave functions flittering in some potential wells: the slots of a Java object). We have no disagreement here. Just different viewpoints. A UML 2.0 that can not describe the world of physical products will have missed the mark. Bernd says, "The fundamental difference between role and instance is, that role is conceptual while instance is physical." I don't understand what you would call an object in memory that represents a physical entity, like a real airplane. I could call the UML-modeled instance a role, the memory object a logical instance, and the airplane a physical instance. What would you two call these things? FWIW, I have had the same problem with the 4-layer architecture in the UML and MOF specs. Object instances can model real-life instances, which would imply there is a layer M -1. For example, I can have a physical network, a model of my network in some system, and a model of that system in UML. The OMG definition of the word model used to cause an "impedance mismatch" with some people until I discovered the cause. Cheers, -Jim -- Wisdom begins when we discover the difference between "That makes no sense", and "I don't understand". -- Mary Doria Russell From: Edwin Seidewitz To: "'Joaquin Miller'" , Jim Logan Cc: UML RTF Subject: RE: [communityUML] RE: UML RTF: Issue 3783 | a.k.a. RE:Anniversar y Celebration: Does UML allow an interface on an object? Date: Fri, 7 Sep 2001 11:12:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C137AF.8F5DD3E0" X-UIDL: D(J!!@!6!!e Organization: Oracle Corporation X-Mailer: Mozilla 4.7 [en-gb] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Edwin Seidewitz CC: UML RTF Subject: Re: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Does UMLallow an interface on an object? References: Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii X-UIDL: o>(!!=`7!!b?/!!K5"e9 Ed, > an instance is just a tightly constrained role This is certainly possible in theory (and might also piggyback on the Collaboration notation), but I'm not sure that one would end up overloading Roles with instance semantics (as Bran eloquently puts it). NB: when I refer to "instance" I do not mean m0 instance at run-time, but instance in the UML model, as diagrammed in Structure diagrams and interchanged in XMI. Some questions: - How would one model 2 Instances playing the same Role (I can see that as a workaround I can define two identical roles, but that is not the intended semantics: 1 Role, 2 Instances) - How would one model values for Instances (Roles do not have any values for properties, whereas Instances do ; I might be able to use AssociationRoles between "constrained Roles" to mimic Links, but there is no equivalent for attribute values) For UML 2 timeframe I think linking instances to roles in a collaboration is an essential aspect because it ties together full structure (class - role - instance) with a specific * context * (something that Structure diagrams per se can't do). However, it requires non-trivial extension of the meta model beyond "constrained roles". For UML 1.5 we may have to focus on a more directed solution to the problem. Thanks, Guus Edwin Seidewitz wrote: -----Original Message----- From: Selic, Bran [mailto:bselic@rational.com] Sent: Tuesday, September 04, 2001 5:18 PM To: 'Jim Logan'; Edwin Seidewitz Cc: 'Guus Ramackers'; UML RTF Subject: RE: UML RTF: Issue 3783 | a.k.a. RE: Anniversary Celebration: Do es UMLallow an interface on an object? One other argument for modeling instances: in many analyses methods used in real-time systems (schedulability, performance analyses, etc.), it is absolutely fundamental to differentiate specific instances and their characteristics. Roles don't do the job, unless you overload roles with instance semantics (i.e., each role represents a specific instance). This may be what Ed meant -- you can always choose to interpret (constrain) a role model as an instance model. I have, indeed, argued in the past that modeling an instance is just a tightly constrained role. I think you can actually combine the concepts of "instance role" ("classifier" role is really a misnomer) and "modeled instance" and have one kind of instance/collaboration modeling notation. And this should be kept distinct from the concept of "instance in execution". (Bran, I actually remember you making a point about this latter distinction way, way back in the UML 1.3 RTF...) But, who cares what Ed meant, he's not in the RTF anyway ;-) And I'm not a UML 2.0 submitter either!-- Ed Ed Seidewitz, Chief Architect InteliData Technologies Office: +1.703.259.3076 Mobile: +1.301.455.3681 -- Guus Ramackers Product Manager UML Products, Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK e-mail: guus.ramackers@oracle.com work: +44-(0)1189-245101 fax: +44-(0)1189-245148 Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 08 May 2004 14:49:09 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: ,cl, Issue 3783 One more proposed resolution for ballot 14 from Karl From: "Karl Frank" Joaquin, this is an issue you submitted, so pay special attention. My comments: [jm] I prefer the quoted original text, or this revision: .In a sense, an interface specifies a kind of contract; any instance of a classifier that realizes the interface must fulfill that contract. [jm] .in a sense. and .a kind of. are unnecessary and add a flavor of vagueness; how about: .An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract .. These comments are also in the attachment. [Of course, as everyone knows, i reject the hard line doctrine that 'interface' should mean only and merely Java-and-the-like-interface (rather than having its ordinary meaning). [My comments here are only suggestions to improve the proposed hard line resolution.] Cordially, Joaquin 3783_proposed for Ballot141.doc OMG Issue No: 3783 Title: Interface of an object Source: X-Change Technologies Group, LLC (Mr. Joaquin Miller, joaquin.no.spam@acm.org miller@joaquin.net) Summary: This is a request for an interpretation of UML 1.3. The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object? -------- Background ------- Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation." The UML submission said: "... An interface is only a collection of operations with a name; it cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." "UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object." UML 1.3 says: "2.5.4 Semantics "Interface "... An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any model element that is a subtype of Instance and corresponds to Interface. (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.) [It is clear that a UML model may include an object that is an instance of a class that realizes an interface.] -------- I am hoping this is easy to interpret and can be resolved quickly. Discussion: The issue originally asked for an interpretation of UML 1.3. Our answer will make no claim regarding UML 1.3. Our resolution will settle the issue in UML 2 by providing a clarified text on the subject. The UML 2 metamodel is clear in showing 1. Behaviored Classifiers are optionally related to Interfaces as the implementing classifier, where the implementation relationship is a specialization of realization. 2. Classes and Objects do not .have. Interfaces. Three ambiguous, misleading, and vague statements on this topic remain in the UML 2 specification text. Our resolution of this issue proposes some clarification the. Interface is defined in the Classes chapter, Section 7.15 The Description subsection includes this text: An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. In a sense, an interface specifies a kind of contract which must be fulfilled by any instance of a classifier that realizes the interface. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface. Since interfaces are declarations, they are not directly instantiable. Instead, an interface specification is realized by an instance of a classifier, such as a class, which means that it presents a public facade that conforms to the interface specification. Note that a given classifier may realize more than one interface and that an interface may be realized by a number of different classifiers. There are three problems with this. 1 The scope of the modal .must. is ambiguous in the statement .an interface specifies a kind of contract which must be fulfilled by any instance of a classifier that realizes the interface. The author did not mean that the contract must be fulfilled, but that if a classifier realizes the interface, then all instances of that classifier must fulfill the contract. A revision that is not ambiguous would read as follows: .an interface specifies a kind of contract that can only be fulfilled by instances of a classifier that realizes the interface.. >>>> [jm] I prefer the quoted original text, or this revision: .an interface specifies a kind of contract; any instance of a classifier that realizes the interface must fulfill that contract. >>>> [jm] .in a sense. and .a kind of. are unnecessary and add a flavor of vagueness; how about: .An interface specifies a contract; any instance of a classifier that realizes the interface must fulfil that contract .. 2 Another inadequacy is .an interface specification is realized by an instance of a classifier, such as a class.. The problem with this is that an interface is itself a classifier. The qualifier .instantiable. should be inserted. 3 In the abstract syntax, the relationship of an interface to the instantiable classifier is not realization, but implementation. Which specializes realization. The most specific applicable characterization is always the right one to use in a specification. Resolution Modify the text of the description subsection, for Interface in the Classes chapter to improve the 3 points discussed above. Revised Text: An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. In a sense, an interface specifies a kind of contract which can only be fulfilled by instances of a classifier that implements the interface. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface. Since interfaces are declarations, they are not instantiable. Instead, an interface specification may be implemented by an instance of an instantiable classifier, which means that the instantiable classifier presents a public facade that conforms to the interface specification. Note that a given classifier may implement more than one interface and that an interface may be implemented by a number of different classifiers. (see .Implementation (from Interfaces).). Disposition: Resolved From: "Thomas Weigert" To: "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: ,cl, Issue 3783 One more proposed resolution for ballot 14 from Karl Date: Sat, 8 May 2004 17:27:21 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Formulations such as "in a sense..." are inappropriate. I think the sentence "An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract " is pretty much what we had in the original text? Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Saturday, May 08, 2004 4:49 PM To: UML Superstructure FTF Subject: ,cl, Issue 3783 One more proposed resolution for ballot 14 from Karl From: "Karl Frank" Joaquin, this is an issue you submitted, so pay special attention. My comments: [jm] I prefer the quoted original text, or this revision: [jm ] an d are unnecessary and add a flavor of vagueness; how about: These comments are also in the attachment. [Of course, as everyone knows, i reject the hard line doctrine that 'interface' should mean only and merely Java-and-the-like-interface (rather than having its ordinary meaning). [My comments here are only suggestions to improve the proposed hard line resolution.] Cordially, Joaquin Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 08 May 2004 16:23:36 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,cl, Issue 3783 One more proposed resolution for ballot 14 from Karl Thomas Weigert wrote: Formulations such as "in a sense..." are inappropriate. I think the sentence "An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract " is pretty much what we had in the original text? The original text is: "In a sense, an interface specifies a kind of contract which must be fulfilled by any instance of a classifier that realizes the interface." Joaquin -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Saturday, May 08, 2004 4:49 PM To: UML Superstructure FTF Subject: ,cl, Issue 3783 One more proposed resolution for ballot 14 from Karl From: "Karl Frank" Joaquin, this is an issue you submitted, so pay special attention. My comments: [jm] I prefer the quoted original text, or this revision: In a sense, an interface specifies a kind of contract; any instance of a classifier that realizes the interface must fulfill that contract [jm] in a sense and a kind of are unnecessary and add a flavor of vagueness; how about: An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract . These comments are also in the attachment. [Of course, as everyone knows, i reject the hard line doctrine that 'interface' should mean only and merely Java-and-the-like-interface (rather than having its ordinary meaning). [My comments here are only suggestions to improve the proposed hard line resolution.] Cordially, Joaquin Subject: RE: ,cl, Issue 3783 One more proposed resolution for ballot 14 from Karl Date: Sun, 9 May 2004 10:03:48 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ,cl, Issue 3783 One more proposed resolution for ballot 14 from Karl Thread-Index: AcQ1S0oiijVLDUZdT6GXg/4yj9GeIgAguHKw From: "Karl Frank" To: "Thomas Weigert" , "Joaquin Miller" , "UML Superstructure FTF" X-OriginalArrivalTime: 09 May 2004 14:03:49.0529 (UTC) FILETIME=[73C8C890:01C435CE] Combining Joaquin's suggestions and Thomas', I have rewritten the proposed resolution, found in the attached. Note the 'v2' in the filename. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, 08 May, 2004 6:27 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: ,cl, Issue 3783 One more proposed resolution for ballot 14 from Karl Formulations such as "in a sense..." are inappropriate. I think the sentence "An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract " is pretty much what we had in the original text? Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Saturday, May 08, 2004 4:49 PM To: UML Superstructure FTF Subject: ,cl, Issue 3783 One more proposed resolution for ballot 14 from Karl From: "Karl Frank" Joaquin, this is an issue you submitted, so pay special attention. My comments: [jm] I prefer the quoted original text, or this revision: [jm ] an d are unnecessary and add a flavor of vagueness; how about: These comments are also in the attachment. [Of course, as everyone knows, i reject the hard line doctrine that 'interface' should mean only and merely Java-and-the-like-interface (rather than having its ordinary meaning). [My comments here are only suggestions to improve the proposed hard line resolution.] Cordially, Joaquin 3783_v2_proposed for Ballot14.doc Subject: One more proposed resolution for ballot 14 from Karl Date: Sat, 8 May 2004 15:08:23 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: One more proposed resolution for ballot 14 from Karl Thread-Index: AcQ1DmjDFTiYBWLHSKiiGWMGpfZ30QAICokw From: "Karl Frank" To: "Branislav Selic" Cc: X-OriginalArrivalTime: 08 May 2004 19:08:25.0777 (UTC) FILETIME=[D6DD2A10:01C4352F] This one is in a file by itself, consider it as one to add to the 8 others for Classes. Joaquin, this is an issue you submitted, so pay special attention. Sorry the filename does not mean I have 3783 resolutions proposed. - Karl 3783_proposed for Ballot14.doc From: "Thomas Weigert" To: "Karl Frank" , "Branislav Selic" Cc: Subject: RE: One more proposed resolution for ballot 14 from Karl Date: Sat, 8 May 2004 14:42:59 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Karl, regarding your proposed clarifications: 1. The original text was clear and unambiguous. Your proposed change makes it more fuzzy. I suggest you do not make this change. If you have an interface on a classifier, the contract MUST be fulfilled by all instances of that classifier. 2. Good. But as long as we are word-smithing, you should drop "specification" from the sentence. It is not the interface specification that is realized, but the interface. 3. The term "realizes an interface" might occur at other places in the specification. We should scour the text for this. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, May 08, 2004 2:08 PM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: One more proposed resolution for ballot 14 from Karl This one is in a file by itself, consider it as one to add to the 8 others for Classes. Joaquin, this is an issue you submitted, so pay special attention. Sorry the filename does not mean I have 3783 resolutions proposed. - Karl From: "Thomas Weigert" To: "Thomas Weigert" , "Karl Frank" , "Branislav Selic" Cc: Subject: RE: One more proposed resolution for ballot 14 from Karl Date: Sat, 8 May 2004 15:32:33 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) By the way, "Implementation" is omitted as one of the legal and typical elements in the diagram section of the Classes chapter and should be added, both in the table and the list below. (Note that legality in diagrams is not inheritable, so just because Realization is legal does not mean Implementation is.) Th. -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, May 08, 2004 2:43 PM To: Karl Frank; Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Karl, regarding your proposed clarifications: 1. The original text was clear and unambiguous. Your proposed change makes it more fuzzy. I suggest you do not make this change. If you have an interface on a classifier, the contract MUST be fulfilled by all instances of that classifier. 2. Good. But as long as we are word-smithing, you should drop "specification" from the sentence. It is not the interface specification that is realized, but the interface. 3. The term "realizes an interface" might occur at other places in the specification. We should scour the text for this. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, May 08, 2004 2:08 PM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: One more proposed resolution for ballot 14 from Karl This one is in a file by itself, consider it as one to add to the 8 others for Classes. Joaquin, this is an issue you submitted, so pay special attention. Sorry the filename does not mean I have 3783 resolutions proposed. - Karl To: "Thomas Weigert" Cc: "Karl Frank" , uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Sat, 8 May 2004 17:47:30 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/08/2004 17:47:32, Serialize complete at 05/08/2004 17:47:32 Please note that I have submitted a resolution that deals with the "implements" versus "realizes" difference. I believe it is compatible with karl's resolution, but I think it is useful to draw people's attention to this. I like Karl's fixes, but prefer the term "must" to "can only" because I think the latter is too restrictive. I have no idea what else can "fulfill" an interface, but I don't want to prejudge that. I agree with Thomas' suggestion that the word "specification" should be omitted -- it adds nothing since an Interface is already a specification. The phrase "realizes an interface" may indeed be around in other places, but I think that Karl's refinement is a good one. regards, Bran "Thomas Weigert" 05/08/2004 03:42 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: One more proposed resolution for ballot 14 from Karl Karl, regarding your proposed clarifications: 1. The original text was clear and unambiguous. Your proposed change makes it more fuzzy. I suggest you do not make this change. If you have an interface on a classifier, the contract MUST be fulfilled by all instances of that classifier. 2. Good. But as long as we are word-smithing, you should drop "specification" from the sentence. It is not the interface specification that is realized, but the interface. 3. The term "realizes an interface" might occur at other places in the specification. We should scour the text for this. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, May 08, 2004 2:08 PM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: One more proposed resolution for ballot 14 from Karl This one is in a file by itself, consider it as one to add to the 8 others for Classes. Joaquin, this is an issue you submitted, so pay special attention. Sorry the filename does not mean I have 3783 resolutions proposed. - Karl From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: "Karl Frank" , Subject: RE: One more proposed resolution for ballot 14 from Karl Date: Sat, 8 May 2004 17:25:20 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Just to clarify... I am opposed to the change indicated by (1) in Karl's proposal as it makes unclear what was clear in the original text. Regarding the "realizes" I think we should look for other occurrences and replace them by implement where appropriate, consistently with Bran's other issue resolution. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, May 08, 2004 4:47 PM To: Thomas Weigert Cc: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Please note that I have submitted a resolution that deals with the "implements" versus "realizes" difference. I believe it is compatible with karl's resolution, but I think it is useful to draw people's attention to this. I like Karl's fixes, but prefer the term "must" to "can only" because I think the latter is too restrictive. I have no idea what else can "fulfill" an interface, but I don't want to prejudge that. I agree with Thomas' suggestion that the word "specification" should be omitted -- it adds nothing since an Interface is already a specification. The phrase "realizes an interface" may indeed be around in other places, but I think that Karl's refinement is a good one. regards, Bran "Thomas Weigert" 05/08/2004 03:42 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: One more proposed resolution for ballot 14 from Karl Karl, regarding your proposed clarifications: 1. The original text was clear and unambiguous. Your proposed change makes it more fuzzy. I suggest you do not make this change. If you have an interface on a classifier, the contract MUST be fulfilled by all instances of that classifier. 2. Good. But as long as we are word-smithing, you should drop "specification" from the sentence. It is not the interface specification that is realized, but the interface. 3. The term "realizes an interface" might occur at other places in the specification. We should scour the text for this. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, May 08, 2004 2:08 PM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: One more proposed resolution for ballot 14 from Karl This one is in a file by itself, consider it as one to add to the 8 others for Classes. Joaquin, this is an issue you submitted, so pay special attention. Sorry the filename does not mean I have 3783 resolutions proposed. - Karl Subject: RE: One more proposed resolution for ballot 14 from Karl Date: Sun, 9 May 2004 09:55:52 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: One more proposed resolution for ballot 14 from Karl Thread-Index: AcQ1Svn1tgurARu0SZmHcd+JGVRiOAAgfSgw From: "Karl Frank" To: "Thomas Weigert" , "Branislav Selic" Cc: X-OriginalArrivalTime: 09 May 2004 13:56:06.0676 (UTC) FILETIME=[5FE70540:01C435CD] Thoma, I agree with your proposal, which you formulated as follows, because it removes the ambiguous scope of the "must", making it clear that the "must" does not say that an interface must have instances of classifiers, etc. So I will rewrite my proposal with your language at that point. Thomas wrote: "An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract " is pretty much what we had in the original text? It is better than the original because it removes the ambiguity. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, 08 May, 2004 6:25 PM To: Branislav Selic; Thomas Weigert Cc: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Just to clarify... I am opposed to the change indicated by (1) in Karl's proposal as it makes unclear what was clear in the original text. Regarding the "realizes" I think we should look for other occurrences and replace them by implement where appropriate, consistently with Bran's other issue resolution. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, May 08, 2004 4:47 PM To: Thomas Weigert Cc: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Please note that I have submitted a resolution that deals with the "implements" versus "realizes" difference. I believe it is compatible with karl's resolution, but I think it is useful to draw people's attention to this. I like Karl's fixes, but prefer the term "must" to "can only" because I think the latter is too restrictive. I have no idea what else can "fulfill" an interface, but I don't want to prejudge that. I agree with Thomas' suggestion that the word "specification" should be omitted -- it adds nothing since an Interface is already a specification. The phrase "realizes an interface" may indeed be around in other places, but I think that Karl's refinement is a good one. regards, Bran "Thomas Weigert" 05/08/2004 03:42 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: One more proposed resolution for ballot 14 from Karl Karl, regarding your proposed clarifications: 1. The original text was clear and unambiguous. Your proposed change makes it more fuzzy. I suggest you do not make this change. If you have an interface on a classifier, the contract MUST be fulfilled by all instances of that classifier. 2. Good. But as long as we are word-smithing, you should drop "specification" from the sentence. It is not the interface specification that is realized, but the interface. 3. The term "realizes an interface" might occur at other places in the specification. We should scour the text for this. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, May 08, 2004 2:08 PM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: One more proposed resolution for ballot 14 from Karl This one is in a file by itself, consider it as one to add to the 8 others for Classes. Joaquin, this is an issue you submitted, so pay special attention. Sorry the filename does not mean I have 3783 resolutions proposed. - Karl Subject: RE: One more proposed resolution for ballot 14 from Karl Date: Sun, 9 May 2004 21:49:04 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: One more proposed resolution for ballot 14 from Karl Thread-Index: AcQ1Svn1tgurARu0SZmHcd+JGVRiOAAgfSgwABimbmA= From: "Karl Frank" To: "Thomas Weigert" , "Branislav Selic" , "Joaquin Miller" Cc: X-OriginalArrivalTime: 10 May 2004 01:49:05.0987 (UTC) FILETIME=[FA5BD930:01C43630] Yet another rewrite. The last one I sent had the new language in one place, but not in all places where it was needed. The attached file is complete in itself, including the 8 prior proposals, plus this newly reworked one, and hence is labeled 9_Ballot14 etc. From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, 09 May, 2004 9:56 AM To: Thomas Weigert; Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Thoma, I agree with your proposal, which you formulated as follows, because it removes the ambiguous scope of the "must", making it clear that the "must" does not say that an interface must have instances of classifiers, etc. So I will rewrite my proposal with your language at that point. Thomas wrote: "An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract " is pretty much what we had in the original text? It is better than the original because it removes the ambiguity. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, 08 May, 2004 6:25 PM To: Branislav Selic; Thomas Weigert Cc: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Just to clarify... I am opposed to the change indicated by (1) in Karl's proposal as it makes unclear what was clear in the original text. Regarding the "realizes" I think we should look for other occurrences and replace them by implement where appropriate, consistently with Bran's other issue resolution. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, May 08, 2004 4:47 PM To: Thomas Weigert Cc: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Please note that I have submitted a resolution that deals with the "implements" versus "realizes" difference. I believe it is compatible with karl's resolution, but I think it is useful to draw people's attention to this. I like Karl's fixes, but prefer the term "must" to "can only" because I think the latter is too restrictive. I have no idea what else can "fulfill" an interface, but I don't want to prejudge that. I agree with Thomas' suggestion that the word "specification" should be omitted -- it adds nothing since an Interface is already a specification. The phrase "realizes an interface" may indeed be around in other places, but I think that Karl's refinement is a good one. regards, Bran "Thomas Weigert" 05/08/2004 03:42 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: One more proposed resolution for ballot 14 from Karl Karl, regarding your proposed clarifications: 1. The original text was clear and unambiguous. Your proposed change makes it more fuzzy. I suggest you do not make this change. If you have an interface on a classifier, the contract MUST be fulfilled by all instances of that classifier. 2. Good. But as long as we are word-smithing, you should drop "specification" from the sentence. It is not the interface specification that is realized, but the interface. 3. The term "realizes an interface" might occur at other places in the specification. We should scour the text for this. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, May 08, 2004 2:08 PM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: One more proposed resolution for ballot 14 from Karl This one is in a file by itself, consider it as one to add to the 8 others for Classes. Joaquin, this is an issue you submitted, so pay special attention. Sorry the filename does not mean I have 3783 resolutions proposed. - Karl 9_Ballot14ClassesResolutions.doc OMG Issue No: 3783 Title: Interface of an object Source: X-Change Technologies Group, LLC (Mr. Joaquin Miller, joaquin.no.spam@acm.org miller@joaquin.net) Summary: This is a request for an interpretation of UML 1.3. The question is: Is there a UML 1.3 model element that represents the concept of an interface on an object? -------- Background ------- Evidently the way to get an interpretation of the meaning of an OMG specification is this: "If you file the interpretation request as an issue against the relevant FTF/RTF then the resolution will be your interpretation." The UML submission said: "... An interface is only a collection of operations with a name; it cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." "UML objects are not modeled as presenting interfaces. A UML interface is not instantiable, so there is not a UML model element that corresponds directly to the interface of an OMG object." UML 1.3 says: "2.5.4 Semantics "Interface "... An interface is only a collection of operations with a name. It cannot be directly instantiated. Instantiable classifiers, such as class or use case, ..." In UML 1.3, there are Instance and Link, which stand for instances of Classifier and Association. Instance includes DataValue, NodeInstance, ComponentInstance, Object, and LinkObject. SubsystemInstance has been proposed for UML 1.4. There is not any model element that is a subtype of Instance and corresponds to Interface. (That is, the association, classifier, of Instance and Classifier does not associate any model element with Interface.) [It is clear that a UML model may include an object that is an instance of a class that realizes an interface.] -------- I am hoping this is easy to interpret and can be resolved quickly. Discussion: The issue originally asked for an interpretation of UML 1.3. Our answer will make no claim regarding UML 1.3. Our resolution will settle the issue in UML 2 by providing a clarified text on the subject. The UML 2 metamodel is clear in showing 1. Behaviored Classifiers are optionally related to Interfaces as the implementing classifier, where the implementation relationship is a specialization of realization. 2. Classes and Objects do not .have. Interfaces. Three ambiguous, misleading, and vague statements on this topic remain in the UML 2 specification text. Our resolution of this issue proposes some clarification the. Interface is defined in the Classes chapter, Section 7.15 The Description subsection includes this text: An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. In a sense, an interface specifies a kind of contract which must be fulfilled by any instance of a classifier that realizes the interface. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface. Since interfaces are declarations, they are not directly instantiable. Instead, an interface specification is realized by an instance of a classifier, such as a class, which means that it presents a public facade that conforms to the interface specification. Note that a given classifier may realize more than one interface and that an interface may be realized by a number of different classifiers. There are three problems with this. 1 The scope of the modal .must. is ambiguous in the statement .an interface specifies a kind of contract which must be fulfilled by any instance of a classifier that realizes the interface. The author did not mean that the contract must be fulfilled, but that if a classifier realizes the interface, then all instances of that classifier must fulfill the contract. A revision that is not ambiguous would read as follows: .an interface specifies a kind of contract that can only be fulfilled by instances of a classifier that realizes the interface.. 2 Another inadequacy is .an interface specification is realized by an instance of a classifier, such as a class.. The problem with this is that an interface is itself a classifier. The qualifier .instantiable. should be inserted. 3 In the abstract syntax, the relationship of an interface to the instantiable classifier is not realization, but implementation. Which specializes realization. The most specific applicable characterization is always the right one to use in a specification. Resolution Modify the text of the description subsection, for Interface in the Classes chapter to improve the 3 points discussed above. Revised Text: An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. In a sense, an interface specifies a kind of contract which can only be fulfilled by instances of a classifier that implements the interface. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface. Since interfaces are declarations, they are not instantiable. Instead, an interface specification may be implemented by an instance of an instantiable classifier, which means that the instantiable classifier presents a public facade that conforms to the interface specification. Note that a given classifier may implement more than one interface and that an interface may be implemented by a number of different classifiers. (see .Implementation (from Interfaces).). Disposition: Resolved To: "Karl Frank" , "Moore, Alan" Cc: "Joaquin Miller" , "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Tue, 11 May 2004 18:02:56 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/11/2004 18:03:05, Serialize complete at 05/11/2004 18:03:05 Hi Karl (and Alan), I have a few comments (nothing serious): Issue 3783: (I see nothing wrong with using the term "in a sense" in the description part of the spec -- but let's leave it as is. I am not sure that using the term "contract" to define an interface is really helpful. I can think of several ways in which that term can be interpreted -- it's not a formally defined term in UML. Again, this is a nitpick and I am not asking that something be done about it. Lastly, I suggest replacing the word "coherent" by the word "related". The former is actually a good word, but most people I think will not know what it means (the opposite of "incoherent"?) since the intended meaning is not common usage in American English. Issue 5978: I think there should be at least 1 example figure showing the "unfilled" diamond. BTW, I prefer "unfilled" to "open" and suggest it be used instead. "Open" to me sounds like one of the sides of the diamond is missing. Issue 6160: The first sentence refers to issue 6160 -- it should be 6170. Issue 6218: Please specify more precisely which text is being removed (i.e., which pages, paragraphs, figure numbers, etc.). As it stands, it is not clear and it can easily be misinterpreted. (As an editor, I would really appreciate it.) Issue 6437: I recall that Conrad had some comment about there being a difference between "ownerScope" and "targetScope" -- is that not an issue? Issue 6442: Please draw the attention of Alan Moore to this particular solution -- I believe that he is working on the SysML model of what they call "parametrization" and he may have some feedback on your resolution. I have copied Alan on this e-mail just in case. Also, I am not sure what I am supposed to do with the sentence following the "closed, no change" resolution -- this field of a resolution should not contain any other text. Please either remove it or put it somewhere in the resolution or discussion. Issue 6509: this looks like a Duplicate of 6507 to me. Your choice whether you want to deal with it as a duplicate or as a closed no change. The usual convention is to deal with it as a duplicate (it gives us a bit more precise statistics at the end). Cheers, Bran "Karl Frank" 05/09/2004 09:49 PM To "Thomas Weigert" , Branislav Selic/Ottawa/IBM@IBMCA, "Joaquin Miller" cc Subject RE: One more proposed resolution for ballot 14 from Karl Yet another rewrite. The last one I sent had the new language in one place, but not in all places where it was needed. The attached file is complete in itself, including the 8 prior proposals, plus this newly reworked one, and hence is labeled 9_Ballot14 etc. From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Sunday, 09 May, 2004 9:56 AM To: Thomas Weigert; Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Thoma, I agree with your proposal, which you formulated as follows, because it removes the ambiguous scope of the "must", making it clear that the "must" does not say that an interface must have instances of classifiers, etc. So I will rewrite my proposal with your language at that point. Thomas wrote: "An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract " is pretty much what we had in the original text? It is better than the original because it removes the ambiguity. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Saturday, 08 May, 2004 6:25 PM To: Branislav Selic; Thomas Weigert Cc: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Just to clarify... I am opposed to the change indicated by (1) in Karl's proposal as it makes unclear what was clear in the original text. Regarding the "realizes" I think we should look for other occurrences and replace them by implement where appropriate, consistently with Bran's other issue resolution. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Saturday, May 08, 2004 4:47 PM To: Thomas Weigert Cc: Karl Frank; uml2-superstructure-ftf@omg.org Subject: RE: One more proposed resolution for ballot 14 from Karl Please note that I have submitted a resolution that deals with the "implements" versus "realizes" difference. I believe it is compatible with karl's resolution, but I think it is useful to draw people's attention to this. I like Karl's fixes, but prefer the term "must" to "can only" because I think the latter is too restrictive. I have no idea what else can "fulfill" an interface, but I don't want to prejudge that. I agree with Thomas' suggestion that the word "specification" should be omitted -- it adds nothing since an Interface is already a specification. The phrase "realizes an interface" may indeed be around in other places, but I think that Karl's refinement is a good one. regards, Bran "Thomas Weigert" 05/08/2004 03:42 PM To "Karl Frank" , Branislav Selic/Ottawa/IBM@IBMCA cc Subject RE: One more proposed resolution for ballot 14 from Karl Karl, regarding your proposed clarifications: 1. The original text was clear and unambiguous. Your proposed change makes it more fuzzy. I suggest you do not make this change. If you have an interface on a classifier, the contract MUST be fulfilled by all instances of that classifier. 2. Good. But as long as we are word-smithing, you should drop "specification" from the sentence. It is not the interface specification that is realized, but the interface. 3. The term "realizes an interface" might occur at other places in the specification. We should scour the text for this. Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Saturday, May 08, 2004 2:08 PM To: Branislav Selic Cc: uml2-superstructure-ftf@omg.org Subject: One more proposed resolution for ballot 14 from Karl This one is in a file by itself, consider it as one to add to the 8 others for Classes. Joaquin, this is an issue you submitted, so pay special attention. Sorry the filename does not mean I have 3783 resolutions proposed. - Karl [attachment "9_Ballot14ClassesResolutions.doc" deleted by Branislav Selic/Ottawa/IBM]