Issue 2613: Interfaces on Nodes (uml2-superstructure-ftf) Source: (, ) Nature: Severity: Summary: Summary: In looking through the UML 1.3 alpha R2 documentation set, I cannot determine if interfaces are allowed on Nodes. Since a Node is a kind of classifier, it seems possible that a Node can realize an interface. However, since this relationship is not explicitly mentioned as allowed or not, I am unclear as to the intention. Resolution: Revised Text: Actions taken: April 19, 1999: received issue March 9, 2005: closed issue Discussion: In UML 2.0, Node is a subtype of Class, so it can implement Interfaces, if desired. End of Annotations:===== From: "Geri Winters" To: Cc: Subject: Interfaces on Nodes Date: Mon, 19 Apr 1999 16:17:43 -0700 X-MSMail-Priority: Normal Dear sirs - In looking through the UML 1.3 alpha R2 documentation set, I cannot determine if interfaces are allowed on Nodes. Since a Node is a kind of classifier, it seems possible that a Node can realize an interface. However, since this relationship is not explicitly mentioned as allowed or not, I am unclear as to the intention. I'm not even sure this is something I'd want to do, but it seems potentially useful to some of my clients. I am interested in any feedback on this subject. Regards - Geri Schneider Winters Andrews Technology, Inc. Date: Tue, 20 Apr 1999 11:22:40 +0100 (BST) From: Perdita Stevens To: geri@txt.com CC: uml-rtf@omg.org Subject: Re: Interfaces on Nodes Reply-to: Perdita.Stevens@dcs.ed.ac.uk Yes, you can put an Interface on any Classifier, including a Node. More generally, things like this which are implied OK by the semantics -- in this case by the fact that an Interface goes on a Classifier and a Node is a Classifier -- are OK, whether or not they're illustrated in the Notation Guide. There are many examples. (Somebody correct me if I'm wrong but I think this is clear!) Perdita X-Sender: seidewitz@mail.dhr.com Date: Tue, 20 Apr 1999 10:02:24 -0400 To: geri@txt.com From: Ed Seidewitz Subject: Re: Interfaces on Nodes Cc: uml-rtf@omg.org References: <199904192317.QAA22428@grinch.txt.com> At 11:22 AM 4/20/99 +0100, Perdita Stevens wrote: >Yes, you can put an Interface on any Classifier, including a Node. More >generally, things like this which are implied OK by the semantics -- in >this case by the fact that an Interface goes on a Classifier and a Node is >a Classifier -- are OK, whether or not they're illustrated in the Notation >Guide. There are many examples. > >(Somebody correct me if I'm wrong but I think this is clear!) > > >Perdita There doesn't seem to be any well-formedness rule preventing it, so I would agree that it is allowed. This is an interesting point, though, because interfaces are only useful for classifiers with operations. And it is not entirely clear what it means to have operations on a node. Nevertheless, there are some intriguing possibilities (maybe to represent hardware-level protocols??). Is the original questioner (or anybody else listening) actually modeling nodes with operations? If so, I would be interested to hear your ideas. _______________________________________________________________________ Ed Seidewitz Manager, Enterprise Systems Group DHR Technologies (A division of OAO Technology Solutions) 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ X-Sender: joaquin.miller@postoffice.worldnet.att.net Date: Tue, 20 Apr 1999 09:34:23 -0500 To: Ed Seidewitz From: Joaquin Miller Subject: Re: Interfaces on Nodes Cc: geri@txt.com, uml-rtf@omg.org, ab@omg.org References: <12966.199904201022@shillay.dcs.ed.ac.uk> <199904192317.QAA22428@grinch.txt.com> [Regarding the discussion of interfaces on nodes in UML] During the development of UML we did a lot of refactoring of the model. The UML is a response to an RFP requesting a way for CASE tools to exchange models. It's an advantage for toolmakers, and generally regarded as good modeling in any area, to have abstract notions that provide a model part that can be reused. An example of a very abstract concept is Classifier. Classifier is a place to attach a number of different concepts, so that the entire collection of concepts can be reused in several places in the definition of UML. It combines some of the common characteristics of types, programming language classes, use cases, and other concepts, while hiding (abstracting away from) the very great differences between these concepts. Node, of course, represents yet another very different kind of thing. A type in a type system is an entirely different kind of thing from a use case in analysis, and both are entirely different kinds of things from a class in programming. And, whatever they have in common, they are all entirely different from a node out in the machine room or on the desktop. If you see what i mean, there is never going to be a Classifier in a model; Classifier is simply a place to stick some common things so they can be maintained in one place and reused in several places in making the definition of UML. Interface, on the other hand, is not a collection of various concepts put together for reuse. Interface is a single concept. Classifier being what it is, likes to be stretched to new uses, and since there will be no classifiers in a model (if you see what i mean) there will be no semantic clash when it is used in different ways. In essence Classifier is just there for the toolmakers. But interface is there for makers and users of models. It will be a disservice to users to stretch its meaning. Certainly UML as it stands allows classifiers on nodes. I suggest that any future RTF consider changing this. Software has interfaces. (Things used to build software specifications or implementations, like types, and classes, and in UML, use cases, have interfaces.) Nodes have software. To: Ed Seidewitz , geri@txt.com, uml-rtf@omg.org Subject: Re: Interfaces on Nodes Date: Tue, 20 Apr 1999 16:41:47 +0200 From: Gunnar Overgaard No, there is nothing that prevents you from using interfaces between nodes. Nodes are classifiers and as such they can have interfaces. I agree that most of the time you will not use operations when you define a node. However, to use operations to specify the communication protocol between nodes seems to be a reasonable thing to do (when needed!). Gunnar X-Sender: joaquin.miller@postoffice.worldnet.att.net Date: Tue, 20 Apr 1999 11:25:40 -0500 To: Bran Selic From: Joaquin Miller Subject: RE: Interfaces on Nodes Cc: uml-rtf@omg.org At 12:09 PM 4/20/99 , Bran Selic wrote: > Any direct manipulation of CPUs for example, > could fit into this category. For instance, > we may want to mask interrupts, reset a > processor, switch from kernel to user mode, > etc. It would be quite sensible to model > these as node operations. This makes sense. But this would be used only by a few users. For most users it makes sense to distinguish between a node and "an ... object which coordinates processing, storage and communications functions for use by other ... objects within the node to which it belongs," for example, an object representing an operating system, or, for system programmers, an OS kernel. That object will have interfaces. For almost all users, a UML node does not have interfaces. It is a place to put components, which have the interfaces. ...... [Side remark: If, instead of "a run-time physical object that represents a computational resource, generally having at least a memory and often processing capability as well, and upon which components may be deployed," the term 'node' meant "a configuration of ... objects forming a single unit for the purpose of location in space, and which embodies a set of processing, storage and communication functions... for example, a computer and the software it supports (operating system and applications)" then, of course, it would have interfaces.] From: Bran Selic To: "'Ed Seidewitz'" , geri@txt.com Cc: uml-rtf@omg.org Subject: RE: Interfaces on Nodes Date: Tue, 20 Apr 1999 13:09:53 -0400 > And it is not entirely clear what it means > to have operations on a node. Nevertheless, there are some > intriguing > possibilities (maybe to represent hardware-level protocols??). [Bran Selic] Any direct manipulation of CPUs for example, could fit into this category. For instance, we may want to mask interrupts, reset a processor, switch from kernel to user mode, etc. It would be quite sensible to model these as node operations. Bran Reply-To: From: "Grady Booch" To: "Gunnar Overgaard" , "Ed Seidewitz" , , Subject: RE: Interfaces on Nodes Date: Tue, 20 Apr 1999 11:30:33 -0600 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 I agree that most of the time you will not use operations when you define a node. However, to use operations to specify the communication protocol between nodes seems to be a reasonable thing to do (when needed!). egb> hm. I wouldn't do it that way. A communication protocol is a characteristic of a link between nodes, and so I would model that as an association class Gunnar X-Sender: seidewitz@mail.dhr.com Date: Tue, 20 Apr 1999 13:50:02 -0400 To: From: Ed Seidewitz Subject: RE: Interfaces on Nodes References: <199904201441.QAA19174@mail2.it.kth.se> At 11:30 AM 4/20/99 -0600, Grady Booch wrote: >I agree that most of the time you will not use operations when you define a >node. However, to use operations to specify the communication protocol >between >nodes seems to be a reasonable thing to do (when needed!). > >egb> hm. I wouldn't do it that way. A communication protocol is a >characteristic of a link between nodes, and so I would model that as an >association class This makes some sense, but even so, how would you model the dynamics of getting data from node to node? An instance of the protocol association class would still need to get data from one node and send it to another. It seems to me that a reasonable way to do this would be to model the protocol object as using operations on the nodes, since this is what the association would connect. _______________________________________________________________________ Ed Seidewitz Manager, Enterprise Systems Group DHR Technologies (A division of OAO Technology Solutions) 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ X-Sender: joaquin.miller@postoffice.worldnet.att.net Date: Tue, 20 Apr 1999 13:45:35 -0500 To: Ed Seidewitz From: Joaquin Miller Subject: RE: Interfaces on Nodes Cc: References: <006301be8b53$7eb83360$64c3a8c0@rational.com> <199904201441.QAA19174@mail2.it.kth.se> At 12:50 PM 4/20/99 , Ed Seidewitz wrote: >At 11:30 AM 4/20/99 -0600, Grady Booch wrote: >>egb> ... A communication protocol is a >>characteristic of a link between nodes, >>and so I would model that as an >>association class > >This makes some sense, but even so, how would you model >the dynamics of getting data from node to node? >An instance of the protocol association class would still >need to get data from one node and send it to another. >It seems to me that a reasonable way to do this would be >to model the protocol object as using operations on the >nodes, since this is what the association would connect. Good point. But, if we think of the communication as taking place between the objects (components) on the nodes, then your protocol association would use a protocol object on each node to get and put data. [App]--[Stub]--[ProtocolObj]----------[ProtocolObj]--[Stub]--[App] : ===========Node=========== : ===========Node=========== : [Connection] (Connection being the association class you introduced.] That way, the software is modelled as software, and the node is either the hardware (UML), or the collection that includes the software and the hardware it runs on (ODP), The picture is the same with either meaning, and is drawn according to the UML Notation. Then we can see the same setup from two viewpoints: One viewpoint: [App]--[Binding]--[App] An other viewpoint: [App]--[Stub]--[ProtocolObj]----------[ProtocolObj]--[Stub]--[App] : ===========Node=========== : ===========Node=========== : [Connection] Where Binding in the one viewpoint corresponds to Stub-ProtocolObj-Connection-ProtocolObj-Stub in the other viewpoint, if distributed, or, if not distributed, might be a local programming language binding made by a link editor (or dynamically by a loader), or might be an interprocess binding made by an operating system. Local binding: [App]--[App] ===Node=== Interprocess binding: Local binding: [App]--[IPCBinding]--[App] ==Ca== ==Ca== ==========Node========== (where the Ca are the processes) From: Bran Selic To: "'Joaquin Miller'" Cc: uml-rtf@omg.org Subject: RE: Interfaces on Nodes Date: Tue, 20 Apr 1999 15:18:09 -0400 Interesting: > [Side remark: If, instead of "a run-time physical object that > represents a > computational resource, generally having at least a memory and often > processing > capability as well, and upon which components may be deployed," the > term 'node' > meant "a configuration of ... objects forming a single unit for the > purpose of > location in space, and which embodies a set of processing, storage > and > communication functions... for example, a computer and the software > it > supports > (operating system and applications)" then, of course, it would have > interfaces.] [Bran Selic] My preferred interpretation of node actually is closer to Joaquin's latter formulation, but I do not see that it is precluded by the former. In other words, I am reading much more into the words "at least" than Joaquin. However, I do believe that we need a concept of node-like entity that is decoupled from physical objects. A sort of logical node, if you like that can be mapped to a physical node for deplyoment. The purpose of such a node is to define the environment that a component requires without being specific about the actual physical entity to which it is attached. Most of the time, when we write software, we do not construct it for a particular physical processor instance but for a class of processor instances since the program may be instantiated many times in many physical sites. This brings up the concept of node types (versus node instances), or better even, node roles. Stated differently, I need to interpret deplyoment diagrams as role (collaboration) diagrams rather than as instance diagrams. Joaquin...why do you open these cans? Bran X-Sender: seidewitz@mail.dhr.com Date: Tue, 20 Apr 1999 16:58:37 -0400 To: Bran Selic , "'Joaquin Miller'" From: Ed Seidewitz Subject: RE: Interfaces on Nodes Cc: uml-rtf@omg.org At 03:18 PM 4/20/99 -0400, Bran Selic wrote: >... > > This brings up the concept of node types (versus node > instances), or better even, node roles. Stated > differently, I need to interpret deplyoment diagrams > as role (collaboration) diagrams rather than as > instance diagrams. > > Joaquin...why do you open these cans? > > Bran Actually, I would say this is already covered. Nodes in UML are classifiers, and thus really represent node types (indeed, this is WHY they are classifiers). The metamodel now even explicitly includes node instances. Since nodes are classifiers, they can be the base type of classifier roles and so appear in collaboration diagrams. _______________________________________________________________________ Ed Seidewitz Manager, Enterprise Systems Group DHR Technologies (A division of OAO Technology Solutions) 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ Date: Tue, 20 Apr 1999 14:31:48 -0700 From: Conrad Bock To: Ed Seidewitz Cc: Bran Selic , "'Joaquin Miller'" , uml-rtf@omg.org Subject: RE: Interfaces on Nodes References: <72EB8D4CD4C0D111ACD50060085A23F5011D60D0@ott02.ObjecTime.c om> <4.1.19990420165410.00990b10@mail.dhr.com> Reply-To: bock@intellicorp.com Joaquin, et al, > At 03:18 PM 4/20/99 -0400, Bran Selic wrote: > >... > > > > This brings up the concept of node types (versus node > > instances), or better even, node roles. Stated > > differently, I need to interpret deplyoment diagrams > > as role (collaboration) diagrams rather than as > > instance diagrams. > > > > Joaquin...why do you open these cans? > > > > Bran > > Actually, I would say this is already covered. Nodes in UML are > classifiers, and thus really represent node types (indeed, this is WHY they > are classifiers). The metamodel now even explicitly includes node > instances. Since nodes are classifiers, they can be the base type of > classifier roles and so appear in collaboration diagrams. Another consequence of this is that you can't model the connection between instances of nodes and instances of components (ie, actual machines and files at the M0 level), at least not immediately. The meta-association deployment/resident between Node and Component has its links at the user-model level (M1), between classes of nodes and components. To get to the user-instance level, an association would need to be introduced at the user-model level. It would be best if this we were in some standard, reusable user-model library rather than redefined in each user model separately. Conrad X-Sender: seidewitz@mail.dhr.com Date: Tue, 20 Apr 1999 18:09:08 -0400 To: bock@intellicorp.com From: Ed Seidewitz Subject: RE: Interfaces on Nodes Cc: Bran Selic , "'Joaquin Miller'" , uml-rtf@omg.org References: <4.1.19990420165410.00990b10@mail.dhr.com> <72EB8D4CD4C0D111ACD50060085A23F5011D60D0@ott02.ObjecTime.c om> <4.1.19990420165410.00990b10@mail.dhr.com> At 02:31 PM 4/20/99 -0700, Conrad Bock wrote: >Another consequence of this is that you can't model the connection >between instances of nodes and instances of components (ie, actual >machines and files at the M0 level), at least not immediately. The >meta-association deployment/resident between Node and Component has its >links at the user-model level (M1), between classes of nodes and >components. > >To get to the user-instance level, an association would need to be >introduced at the user-model level. It would be best if this we were in >some standard, reusable user-model library rather than redefined in each >user model separately. Well, there is actually a separate residence meta-association between NodeInstance and ComponentInstance (see Figure 2-84 in V1.3beta). There actually isn't even a well-formedness rule right now to require that instance-level residence conform to classifer-level residence (that is, a component instance can only reside on a node instance when the corresponding component resides on the corresponding node). _______________________________________________________________________ Ed Seidewitz Manager, Enterprise Systems Group DHR Technologies (A division of OAO Technology Solutions) 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ X-Sender: joaquin.miller@postoffice.worldnet.att.net Date: Tue, 20 Apr 1999 17:10:20 -0500 To: uml-rtf@omg.org From: Joaquin Miller Subject: RE: Interfaces on Nodes References: <72EB8D4CD4C0D111ACD50060085A23F5011D60D0@ott02.ObjecTime.c om> At 03:58 PM 4/20/99 , you wrote: >Actually, I would say this is already covered. Nodes in UML are >classifiers, and thus really represent node types (indeed, this is WHY they >are classifiers). The metamodel now even explicitly includes node >instances. Since nodes are classifiers, they can be the base type of >classifier roles and so appear in collaboration diagrams. It may be that type and instance of Node is too simple a model to do what Bran wants. We want to be able to say: here is a specific chunk of application, infrastructure, and (abstraction of) hardware. Here is another specific chunk. We might want types here, too. The two specific chunks mentioned earlier in this paragraph may be of exactly the same type (e.g. redundant somethings). This is ODP node and type of node. Then later we want to plunk this down on a specific, perhaps already existing machine, when the abstraction of the hardware becomes specific hardware. An ODP compliant modeling language would then let us specify the location in space of the node, and also have a corresponding technology viewpoint specification. I agree that there is likely a way to do all that using collaborations, stereotypes, and other stuff of UML. I do find the "node" that combines software and hardware in one chunk to be more useful. Using that concept, there is a way to do all that by simply using abstraction. (Earlier we hide what specific machine is involved, and later we specify it, using "node" at all levels of abstraction.) Feels real clean. Does this do what you are getting at, Bran? If so, this will likely work with UML tools. It is just that the unit that is interesting to me is not the UML node, but instead the UML node with its components. And if i can put a class on a node, i suppose i can put an object on a node instance. This moves us a bit in the simpler everything is an object direction. Reply-To: From: "Grady Booch" To: "Ed Seidewitz" , Subject: RE: Interfaces on Nodes Date: Tue, 20 Apr 1999 16:18:48 -0600 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 This makes some sense, but even so, how would you model the dynamics of getting data from node to node? An instance of the protocol association class would still need to get data from one node and send it to another. It seems to me that a reasonable way to do this would be to model the protocol object as using operations on the nodes, since this is what the association would connect. Egb> the dynamics of any such collaboration would involve the association and the nodes at each end. Reply-To: From: "Grady Booch" To: "Bran Selic" , "'Joaquin Miller'" Cc: Subject: RE: Interfaces on Nodes Date: Tue, 20 Apr 1999 16:18:59 -0600 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 However, I do believe that we need a concept of node-like entity that is decoupled from physical objects. A sort of logical node, if you like that can be mapped to a physical node for deplyoment. Egb> I do not believe that we need yet another fine distinction of kinds of nodes. What you've described can probably be achieved by realizing that there are node classes and node instances. If you want to get yet more meta than that, you can always create your own stereotype This brings up the concept of node types (versus node instances), or better even, node roles. Stated differently, I need to interpret deplyoment diagrams as role (collaboration) diagrams rather than as instance diagrams. Egb> Bran, I still don't well accept your distinction of roles and classes and instances as it is. - it is still far to hand waving for my satisfaction. The UML general philosophy has been to distinguish essense and instance (classifier like stuff and instance) and that's enough, certainly for the scenarios that are being raised here Reply-To: From: "Grady Booch" To: "Ed Seidewitz" , "Bran Selic" , "'Joaquin Miller'" Cc: Subject: RE: Interfaces on Nodes Date: Tue, 20 Apr 1999 16:19:13 -0600 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Actually, I would say this is already covered. Nodes in UML are classifiers, and thus really represent node types (indeed, this is WHY they are classifiers). The metamodel now even explicitly includes node instances. Since nodes are classifiers, they can be the base type of classifier roles and so appear in collaboration diagrams. Egb> Agreed! Date: Fri, 23 Apr 1999 09:53:56 -0700 From: Conrad Bock To: Ed Seidewitz Cc: Bran Selic , "'Joaquin Miller'" , uml-rtf@omg.org Subject: RE: Interfaces on Nodes References: <4.1.19990420165410.00990b10@mail.dhr.com> <72EB8D4CD4C0D111ACD50060085A23F5011D60D0@ott02.ObjecTime.c om> <199904202131.OAA01185@bones.intellicorp.com> <4.1.19990420180617.009d3990@mail.dhr.com> Reply-To: bock@intellicorp.com Ed, > At 02:31 PM 4/20/99 -0700, Conrad Bock wrote: > >Another consequence of this is that you can't model the connection > >between instances of nodes and instances of components (ie, actual > >machines and files at the M0 level), at least not immediately. The > >meta-association deployment/resident between Node and Component has its > >links at the user-model level (M1), between classes of nodes and > >components. > > > Well, there is actually a separate residence meta-association between > NodeInstance and ComponentInstance (see Figure 2-84 in V1.3beta). There > actually isn't even a well-formedness rule right now to require that > instance-level residence conform to classifer-level residence (that is, a > component instance can only reside on a node instance when the > corresponding component resides on the corresponding node). Sorry for the late reply. Thanks for pointing out the above meta-association, but it still looks a bit broken. Normally an association at the user model level (M1) is connected to its links at the instance level (M0). In the case of the links between nodes and components in user models, there is no such connection supported in UML. A somewhat cumbersome workaround is possible, as described below, and the user can set up their own optimizations for it, but it's inconsistent with the normal way of doing things. The number of meta-levels involved will certainly confuse alot of people. I can't help being reminded of similar problems business modelers are having with extending the UML. One major vendor we work with subtyped Classifier into Person and Position, and made a meta-association between them at the UML meta-level. They expected to be able to instantiate these in user models, which ended up with, for example, Joe linked to Manager at the M1 level. Even when they accepted that only types could be in the user model, they expected the M3 meta-association to instantiate at the instance level (M0). The general issue seems to be as Joaquin pointed out, and you and I discussed a few weeks ago: subtypes of UML meta-types should only be for information modeling, that is, how to record facts and behavior. UML should not be subtyped for domain modeling, like the size and weight of PC cases, and so on. Information modeling is about the structure of facts and behavior themselves, not the domain the facts are about. If nodes are just a collection of components in the information modeling sense, then packages or collaborations would work fine for specifying them. If they are physical entities, like a computer, then they should be in a standard user-level library. The latter would eliminate the above problems with the association modeling. Conrad Workaround: To get the instance links of a user-model "association" between nodes and components (M1), you need to find all the instances of the node and components user model types (M1 to M0), then get the instances of the UML-level association between nodes and components meta-types (M3 to M0), and find the ones that apply to the node and component instances found in the first step (M0 to M1). Reply-To: From: "Grady Booch" To: , "Ed Seidewitz" Cc: "Bran Selic" , "'Joaquin Miller'" , Subject: RE: Interfaces on Nodes Date: Fri, 23 Apr 1999 12:47:30 -0600 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Another consequence of this is that you can't model the connection between instances of nodes and instances of components (ie, actual machines and files at the M0 level), at least not immediately. Egb> Your statement is incorrect. Check out the latest metamodel, in the diagram Common Behavior/Instances. There you will find an association that connects ComponentInstance and NodeInstance. X-Sender: seidewitz@mail.dhr.com Date: Fri, 23 Apr 1999 16:20:51 -0400 To: uml-rtf@omg.org From: Ed Seidewitz Subject: RE: Interfaces on Nodes References: <4.1.19990420180617.009d3990@mail.dhr.com> <4.1.19990420165410.00990b10@mail.dhr.com> <72EB8D4CD4C0D111ACD50060085A23F5011D60D0@ott02.ObjecTime.c om> <199904202131.OAA01185@bones.intellicorp.com> <4.1.19990420180617.009d3990@mail.dhr.com> Conrad -- Sorry, but I got pretty lost in your message. In both this case and our previous discussion, I don't really see that users (in these cases) should have any involvement in metamodeling at all and it doesn't seem to me that the metamodeling discussion on these issues is very fruitful. Specifically on the topic at hand, the only point I was trying to make is that there is a way to say that a component instance resides on a specific node instance. This is shown diagrammatically by nesting the component instance in the node instance on a deployment diagram (though the notation guide STILL has the mapping wrong on this!). If you have a further issue here, I'm afraid I just don't understand it... _______________________________________________________________________ Ed Seidewitz Chief Architect OAO Technology Solutions, Inc. E-Commerce and Web Enabling Services 10400 Little Patuxent Parkway, Suite 310 Voice: +1.410.992.4000 Columbia MD 21044 Fax: +1.410.992.4500 _______________________________________________________________________ From: Bran Selic To: "'Joaquin Miller'" , uml-rtf@omg.org Subject: RE: Interfaces on Nodes Date: Fri, 23 Apr 1999 16:57:56 -0400 In reply to: > -----Original Message----- > From: Joaquin Miller [SMTP:joaquin@acm.org] > Sent: Tuesday, April 20, 1999 6:10 PM > To: uml-rtf@omg.org > Subject: RE: Interfaces on Nodes > > At 03:58 PM 4/20/99 , you wrote: > >Actually, I would say this is already covered. Nodes in UML are > >classifiers, and thus really represent node types (indeed, this is > WHY they > >are classifiers). The metamodel now even explicitly includes node > >instances. Since nodes are classifiers, they can be the base type > of > >classifier roles and so appear in collaboration diagrams. [Bran Selic] Ed is correct. I was concentrating on deplyoment diagrams rather than the metamodel. > It may be that type and instance of Node is too simple a model to do > what Bran > wants. [Bran Selic] While this is true, one can always stereotype things to get a more sophisticated model. This is the approach that we are taking in our real-time work. The only problem that I see is if a metaclass is missing or if a well-formedness constraint prevents us from such refinement. > We want to be able to say: here is a specific chunk of application, > infrastructure, and (abstraction of) hardware. Here is another > specific > chunk. We might want types here, too. The two specific chunks > mentioned > earlier in this paragraph may be of exactly the same type (e.g. > redundant > somethings). This is ODP node and type of node. Then later we want > to plunk > this down on a specific, perhaps already existing machine, when the > abstraction > of the hardware becomes specific hardware. [Bran Selic] This is exactly what I was after -- in my view this can be done using roles. Until Ed reminded me, I had lost sight of the fact that, given that Nodes are Classifiers, we can define Node roles (remember also that roles are Classifiers as well). I believe that we can capture things such as ODP clusters using Node roles. > An ODP compliant modeling language would then let us specify the > location in > space of the node, and also have a corresponding technology > viewpoint > specification. > > I agree that there is likely a way to do all that using > collaborations, > stereotypes, and other stuff of UML. > > I do find the "node" that combines software and hardware in one > chunk > to be > more useful. Using that concept, there is a way to do all that by > simply using > abstraction. (Earlier we hide what specific machine is involved, > and > later we > specify it, using "node" at all levels of abstraction.) Feels real > clean. [Bran Selic] I agree. But, as I said before, the Node concept may be broad enough to cover that. In my view, a Node (or a Node role) is an abstraction for an execution environment (among other things). > Does this do what you are getting at, Bran? [Bran Selic] See my comments above. Bran From: Bran Selic To: "'egb@Rational.Com'" , "'Joaquin Miller'" Cc: uml-rtf@omg.org Subject: RE: Interfaces on Nodes Date: Fri, 23 Apr 1999 17:24:30 -0400 [Bran Selic] Just to clarify a point: > > This brings up the concept of node types (versus node > instances), or better even, node roles. Stated > differently, I need to interpret deplyoment diagrams > as role (collaboration) diagrams rather than as > instance diagrams. > > Egb> Bran, I still don't well accept your distinction of roles and > classes > and instances as it is. - it is still far to hand waving for my > satisfaction. The UML general philosophy has been to distinguish > essense and > instance (classifier like stuff and instance) and that's enough, > certainly > for the scenarios that are being raised here [Bran Selic] You are correct, but in some cases, the term "instance" stands for subtly different things. It usually makes no difference, but sometimes it does. For example, we often talk about "variables" and understand each other well without having to be specific about "l-values" and "r-values"; but, on occasion this difference is crucial. But, to clarify my point of view better: What I am looking for is a way of GENERICALLY specifying environments in which some software expects to run. In that situation, it is frequently better to not talk about specific hardware (e.g., processor 145.263.459.23) or even hardware types (e.g., Intel Pentium II), but, rather, the desired quality of service. In that case, it becomes possible to put the software on any environment that has at least the desired quality of service. For instance, in the design of a logically distributed system I may find that I will put two components in two logically separate environments. However, in practice, I may discover that it is possible to map both of them onto the same physical environment that satisfies both. Roles fit nicely here since it allows the same processor to play two distinct "environment" roles. Bran Subject: RE: Ballot 5 DRAFT Date: Wed, 21 Jan 2004 06:47:51 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 5 DRAFT Thread-Index: AcPfwZXpwOdTwQvMTCqyL9jFoPsPDgASECHw From: "Pete Rivett" To: "Branislav Selic" , Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i0LBcYSL022336 Here are comments on the draft. In general they are not about the content of the resolutions but about how they are expressed. IMHO those marked ** must be addressed, those marked * should be addressed to achieve resolutions that can be properly reviewed by the AB, and the others are more minor. The broader point I make about issue 2613 I think needs more general discussion at an FTF meeting/telecon. Issue 2613: this is an example of the more general problem of intended/unintended inheritance. This issue states that though Node inherits from Class (and thus inherits the ability to realise Interfaces) the spec does not make clear whether that is the intention. The proposed response is merely to say "In UML 2.0, Node is a subtype of Class, so it can implement Interfaces, if desired." and Closed no change. Personally I don't think addresses the original issue which is about the intention of the spec. More broadly, the structure of the metamodel - in particular the inheritance from very general classes such as Classifier, Behavior, Class - means that lots of capabilities are inherited into subclasses which make no sense at all: (I remember Steve Cook at one stage came up with a pretty long list of absurd examples which I cannot lay my hands on right now): it cannot be assumed that just because they're inherited that they're intended, useful or meaningful. It makes it very hard for tool vendors to achieve useful interchange: faced with a whole host on inherited features (on e.g. Node) it becomes a somewhat random choice as to which they will actually choose to populate into the XMI file. And of course each vendor is likely to make a somewhat different choice. This is not an easy issue to address but I think it's important to at least try. Approaches are: - List all the semantically valid inherited features against each class in the spec - Introduce/document an explicit redefinition for each semantically valid inherited feature - Introduce OCL constraints to explicitly state that all non-semantically-valid inherited features should be empty - Show a complete instance diagram in the spec for meaningfully-complex examples ** At some stage Super FTF needs to endorse the shared issues that Infra took the lead on and accepted resolutions for in Infra Ballot 2. * Issue 6209: It should be clearer where the abstract syntax changes are reflected in the specification text/diagrams Issue 6352: (Very picky point) This resolution refers to fixing the MDL: technically the MDL is not normative (since as a principal OMG does not want a proprietary tool representation as normative): the MOF XMI is the normative representation of the metamodel. Though the XMI is generated from the MDL (for the time being) I think it would be preferable in formal issue resolutions to refer to fixing the XMI. * Issue 6352: Should more clearly identify 'the corresponding figure': as far as I can see Figure 126 in the spec is correct. Issue 6358: The constraint should really have OCL Issue 6364: There is a typo in the first new sentence - it needs an 'of' after 'supertype' * Issue 6406: Should be more precise about where the spec should be updated; see above re 'MDL file' Issue 6441: Item a) in the issue does not seem unreasonable to address in the FTF Issue 6474: Should remove 'e.g.' from the resolution - the resolution must contain the actual replacement text not example replacement text ** Issue 6476: The resolution is far too vague as to which diagrams are to have the Stereotype added. This is not acceptable as a resolution. ** Issue 6480: There is another occurrence of 'return message' at bottom of p417 - this should presumably also be replaced to fully address the issue. Issue 6605: There is a typo in the discussion which I would not normally comment on but it seems to have a large effect on understanding: in the following there seems to be a word missing after "defining the": "either defining the in the namespace of the context classifier, where..." ** Issue 6680: The existing association is from Activity to StructuredActivityEdge not ActivityEdge as stated. When making an association derived I think it's essential to describe in the text how the derivation id defined - ideally by using OCL. General: is there any meaning attached to the fact that some Discussions (resolutions) are in red and some black? Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 21, 2004 1:51 AM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Ballot 5 DRAFT Attached please find a DRAFT of Ballot 5. The vote on this ballot is scheduled to start tomorrow at noon, so please make sure that it is correct (it took several hours to assemble requiring lots of editing and it is quite possible that I made a mistake somewhere). The list consists of 86 proposed resolutions that were mailed to the superstructure team. Note that I did not automatically include all the resolutions that were proposed, eliminating those that are likely to be challenged. Therefore, only the most trivial ones and the ones that have been officially vetted by the work group are included. So, work group leads need to go through this list very carefully to make sure they do not inadvertently retire issues that were excluded from the ballot. Thanks, Bran Selic Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 Subject: RE: Ballot 5 DRAFT Date: Wed, 21 Jan 2004 09:24:46 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ballot 5 DRAFT Thread-Index: AcPgIs2R/4AQnygHS7qNGgoYfRk45gABa67g From: "Pete Rivett" To: "Branislav Selic" Cc: , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i0LEFRSL023870 Hi Bran, Unfortunately I don't think I'll be able to make the teleconf today since I need to leave for a flight to Amsterdam which I could not get out of (I might be able to make the first few minutes). the problem of "unintended inheritance" which you discuss in the context of issue 2613 is endemic and a major problem throughout the spec. It has to do with what we called "overgeneralization" and is an explicit point in the list of compliance/package merge set of problems (the spreadsheet I sent out). However, to me it seems rather inappropriate to address that issue through a rather minor point raised by issue 2613. (Realistically, I think the problem is so fundamental that we will not be able to do much more than patch up some of the more obvious "howlers" in the FTF.) [Pete Rivett] Yes I agree about not addressing the general problem via this issue: however for this issue it would be useful to have a resolution that added some text to say that this ability for Nodes to realize Interfaces is indeed intended inheritance: obviously this particular case was important enough for someone to raise an issue about it, and we've already got the wording in the discussion so why not add it to the spec for everyone's benefit. I am not sure what you mean by "endorsing the shared issues that the Infra took the lead on". Can you please clarify (in an e-mail or at the telecon later today)? [Pete Rivett] Due to our process, in the same way that the Infra FTF had to vote on the shared issue resolutions proposed and agreed by Super (e.g. Super Ballots 1 and 2 were endorsed via Infra Ballot 1), then Super needs to endorse the resolutions proposed and agreed by Infra. In this case Infra Ballot 2 proposed and agreed resolutions for a number of issues where Infra had the lead - so now Super needs to also vote on them. Regards Date: Wed, 21 Jan 2004 15:46:09 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Pete Rivett , Branislav Selic CC: uml2-superstructure-ftf@omg.org, mu2i-ftf@omg.org, ocl2-ftf@omg.org Subject: Re: Ballot 5 DRAFT X-Brightmail-Tracker: AAAAAQAAAAI= X-White-List-Member: TRUE Pete, Thanks for your comments. Regarding the component ones, some comments below (preceded by "GR>" ) Issue 2613: this is an example of the more general problem of intended/unintended inheritance. This issue states that though Node inherits from Class (and thus inherits the ability to realise Interfaces) the spec does not make clear whether that is the intention. The proposed response is merely to say "In UML 2.0, Node is a subtype of Class, so it can implement Interfaces, if desired." and Closed no change. Personally I don't think addresses the original issue which is about the intention of the spec. More broadly, the structure of the metamodel - in particular the inheritance from very general classes such as Classifier, Behavior, Class - means that lots of capabilities are inherited into subclasses which make no sense at all: (I remember Steve Cook at one stage came up with a pretty long list of absurd examples which I cannot lay my hands on right now): it cannot be assumed that just because they're inherited that they're intended, useful or meaningful. It makes it very hard for tool vendors to achieve useful interchange: faced with a whole host on inherited features (on e.g. Node) it becomes a somewhat random choice as to which they will actually choose to populate into the XMI file. And of course each vendor is likely to make a somewhat different choice. This is not an easy issue to address but I think it's important to at least try. Approaches are: - List all the semantically valid inherited features against each class in the spec - Introduce/document an explicit redefinition for each semantically valid inherited feature - Introduce OCL constraints to explicitly state that all non-semantically-valid inherited features should be empty - Show a complete instance diagram in the spec for meaningfully-complex examples GR> This issue was known to the team when the UML2 meta model was constructed. Some users want interfaces on nodes, and the model supports that. The specification should not needlessly repeat features of supertypes under the label "intention" - books can do that. Note that this is not "unintended" inheritance, but actually "intended" inheritance. Perhaps there are other issues related to "unintended" inheritance in the specs, but 2613 is not one of them, I believe. Issue 6352: (Very picky point) This resolution refers to fixing the MDL: technically the MDL is not normative (since as a principal OMG does not want a proprietary tool representation as normative): the MOF XMI is the normative representation of the metamodel. Though the XMI is generated from the MDL (for the time being) I think it would be preferable in formal issue resolutions to refer to fixing the XMI. GR> Whether normative or not, the spec has the right name, and the XMI should be updated to use this name. * Issue 6352: Should more clearly identify 'the corresponding figure': as far as I can see Figure 126 in the spec is correct. GR> It appears you are referring to the wrong issue number. Issue 6474: Should remove 'e.g.' from the resolution - the resolution must contain the actual replacement text not example replacement text GR> Agreed. Bran has kindly agreed to update the ballot. ** Issue 6476: The resolution is far too vague as to which diagrams are to have the Stereotype added. This is not acceptable as a resolution. GR> Add to diagrams 85, 86, 87, 91. Bran has kindly agreed to update the ballot. Thanks, Guus Pete Rivett wrote: Here are comments on the draft. In general they are not about the content of the resolutions but about how they are expressed. IMHO those marked ** must be addressed, those marked * should be addressed to achieve resolutions that can be properly reviewed by the AB, and the others are more minor. The broader point I make about issue 2613 I think needs more general discussion at an FTF meeting/telecon. Issue 2613: this is an example of the more general problem of intended/unintended inheritance. This issue states that though Node inherits from Class (and thus inherits the ability to realise Interfaces) the spec does not make clear whether that is the intention. The proposed response is merely to say "In UML 2.0, Node is a subtype of Class, so it can implement Interfaces, if desired." and Closed no change. Personally I don't think addresses the original issue which is about the intention of the spec. More broadly, the structure of the metamodel - in particular the inheritance from very general classes such as Classifier, Behavior, Class - means that lots of capabilities are inherited into subclasses which make no sense at all: (I remember Steve Cook at one stage came up with a pretty long list of absurd examples which I cannot lay my hands on right now): it cannot be assumed that just because they're inherited that they're intended, useful or meaningful. It makes it very hard for tool vendors to achieve useful interchange: faced with a whole host on inherited features (on e.g. Node) it becomes a somewhat random choice as to which they will actually choose to populate into the XMI file. And of course each vendor is likely to make a somewhat different choice. This is not an easy issue to address but I think it's important to at least try. Approaches are: - List all the semantically valid inherited features against each class in the spec - Introduce/document an explicit redefinition for each semantically valid inherited feature - Introduce OCL constraints to explicitly state that all non-semantically-valid inherited features should be empty - Show a complete instance diagram in the spec for meaningfully-complex examples ** At some stage Super FTF needs to endorse the shared issues that Infra took the lead on and accepted resolutions for in Infra Ballot 2. * Issue 6209: It should be clearer where the abstract syntax changes are reflected in the specification text/diagrams Issue 6352: (Very picky point) This resolution refers to fixing the MDL: technically the MDL is not normative (since as a principal OMG does not want a proprietary tool representation as normative): the MOF XMI is the normative representation of the metamodel. Though the XMI is generated from the MDL (for the time being) I think it would be preferable in formal issue resolutions to refer to fixing the XMI. * Issue 6352: Should more clearly identify 'the corresponding figure': as far as I can see Figure 126 in the spec is correct. Issue 6358: The constraint should really have OCL Issue 6364: There is a typo in the first new sentence - it needs an 'of' after 'supertype' * Issue 6406: Should be more precise about where the spec should be updated; see above re 'MDL file' Issue 6441: Item a) in the issue does not seem unreasonable to address in the FTF Issue 6474: Should remove 'e.g.' from the resolution - the resolution must contain the actual replacement text not example replacement text ** Issue 6476: The resolution is far too vague as to which diagrams are to have the Stereotype added. This is not acceptable as a resolution. ** Issue 6480: There is another occurrence of 'return message' at bottom of p417 - this should presumably also be replaced to fully address the issue. Issue 6605: There is a typo in the discussion which I would not normally comment on but it seems to have a large effect on understanding: in the following there seems to be a word missing after "defining the": "either defining the in the namespace of the context classifier, where..." ** Issue 6680: The existing association is from Activity to StructuredActivityEdge not ActivityEdge as stated. When making an association derived I think it's essential to describe in the text how the derivation id defined - ideally by using OCL. General: is there any meaning attached to the fact that some Discussions (resolutions) are in red and some black? Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Consulting Architect, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, January 21, 2004 1:51 AM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org; ocl2-ftf@omg.org Subject: Ballot 5 DRAFT Attached please find a DRAFT of Ballot 5. The vote on this ballot is scheduled to start tomorrow at noon, so please make sure that it is correct (it took several hours to assemble requiring lots of editing and it is quite possible that I made a mistake somewhere). The list consists of 86 proposed resolutions that were mailed to the superstructure team. Note that I did not automatically include all the resolutions that were proposed, eliminating those that are likely to be challenged. Therefore, only the most trivial ones and the ones that have been officially vetted by the work group are included. So, work group leads need to go through this list very carefully to make sure they do not inadvertently retire issues that were excluded from the ballot. Thanks, Bran Selic Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 X-Envelope-From: oliver.sims@simsassociates.co.uk Reply-To: From: "Oliver Sims" To: "'Joaquin Miller'" , "'MOF UML Infrastructure FTF'" , "'UML Superstructure FTF'" , Subject: RE: ,gi, unintended inheritance Date: Wed, 21 Jan 2004 18:57:14 -0000 Organization: Sims Associates X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal Reference XMI: The use of default values for each model element may be useful. Thus if each feature has a default (which could be "not specified"), then non-existence of an xml element for a feature in an XMI stream means that the feature has the default value. Just a thought. Oliver -----Original Message----- From: Joaquin Miller [mailto:joaquin.no.spam@acm.org] Sent: 21 January 2004 17:11 To: MOF UML Infrastructure FTF; UML Superstructure FTF; ab@omg.org Subject: ,gi, unintended inheritance If the FTF is unable to correct the specification so it has no inheritance that is not intended, at the very least we must call out in the specification every occurrence of unintended inheritance. (We might miss some: this is life.) This might be done, for example, by using one of the alternative approaches suggested below: Introduce OCL constraints to explicitly [require that each unintended] inherited feature be empty. All remaining inheritance is part of the specification of UML, whether intended or unintended. It won't do to claim conformance-except-for-inheritance-we-judge-to-be-unintended. Cordially, Joaquin Issue 2613: this is an example of the more general problem of intended/unintended inheritance. This issue states that though Node inherits from Class (and thus inherits the ability to realise Interfaces) the spec does not make clear whether that is the intention. The proposed response is merely to say "In UML 2.0, Node is a subtype of Class, so it can implement Interfaces, if desired." and Closed no change. Personally I don't think addresses the original issue which is about the intention of the spec. More broadly, the structure of the metamodel - in particular the inheritance from very general classes such as Classifier, Behavior, Class - means that lots of capabilities are inherited into subclasses which make no sense at all: (I remember Steve Cook at one stage came up with a pretty long list of absurd examples which I cannot lay my hands on right now): it cannot be assumed that just because they're inherited that they're intended, useful or meaningful. It makes it very hard for tool vendors to achieve useful interchange: faced with a whole host on inherited features (on e.g. Node) it becomes a somewhat random choice as to which they will actually choose to populate into the XMI file. And of course each vendor is likely to make a somewhat different choice. This is not an easy issue to address but I think it's important to at least try. Approaches are: - List all the semantically valid inherited features against each class in the spec - Introduce/document an explicit redefinition for each semantically valid inherited feature - Introduce OCL constraints to explicitly state that all non-semantically-valid inherited features should be empty - Show a complete instance diagram in the spec for meaningfully-complex examples ----------------------------- This issue was known to the team when the UML2 meta model was constructed. Some users want interfaces on nodes, and the model supports that. The specification should not needlessly repeat features of supertypes under the label "intention" - books can do that. Note that this is not "unintended" inheritance, but actually "intended" inheritance. Perhaps there are other issues related to "unintended" inheritance in the specs, but 2613 is not one of them, I believe. PGP Fingerprint: CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3 Date: Wed, 21 Jan 2004 15:00:03 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en, fr, de, pdf, it, nl, sv, es To: Joaquin Miller CC: MOF UML Infrastructure FTF , UML Superstructure FTF , ab@omg.org Subject: Re: ,gi, unintended inheritance For what it's worth, I agree with Joaquin. The Meta-Model can have inheritances that are not always meaningful, and in that case, it should include OCL that requires the "unintended inheritance" to be empty under the conditions that identify the instances of the type for which any value of that property is invalid. Satisfying those conditions makes the instance an instance of a subclass that doesn't have the property, whether that subclass is explicitly modeled/named or not. Importantly, a conforming implementation cannot assume that it need not support some property that the implementor thinks was "unintended". Conformance to the meta-model implies support for all features that the model includes. The meta-model contains OCL (and other formal notations) to exclude the cases it means to exclude, and "support" (at least in the XMI) for any other case is required. A war story: In 1972-4 I was in the business of building COBOL compilers for Sperry-Univac (now Unisys). Under the guidance of one of the legends of computing -- Admiral Grace Hopper -- the U.S. Navy developed a test suite for conformance to DoD COBOL, a MilStd for the language. The test suite attempted to test every feature of the language. By using a pattern in writing a part of the standard (PICTURE clauses), the authors of DoD COBOL included a completely meaningless construct as a (pattern) variant of a meaningful construct -- specification of a value as currency -- an unintended inheritance. By eliminating that meaningless case, it was possible to construct an elegant algorithm for parsing PICTURE syntax, while including it required a trial-and-error technique. My compiler eliminated the meaningless case. The Navy test suite contained an example of the meaningless case, and we failed the test. I made a formal protest. Admiral Hopper told me to my face that she was fully aware that the case was meaningless, but the solution was to fix the standard! Her test suite tested what the Mil Std said I had to support, and the test would stand until the Mil Std changed! Expect that some 21st century ramrod will do the same thing to UML, especially when it becomes ISO/IEC 19501-1.2:200x! -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Mail Stop 8260 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8260 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST,