Anniversary Celebration: Does UML allow an interface on an object?



Date view Thread view Subject view Author view

Joaquin Miller (miller@joaquin.net)
Fri, 24 Aug 2001 19:23:18 -0700


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 view Thread view Subject view Author view