- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Fri, 30 May 2003 13:39:50 -0500
- To: "Martin Chapman" <martin.chapman@oracle.com>, "Francis McCabe" <fgm@fla.fujitsu.com>, www-ws-arch@w3.org
There are concise definitions of is-a and has-a in the "old" doc. If you don't like them, it seems to me that you should come up with a better alternative. Failing that, I suggest that we continue with what we have. -----Original Message----- From: Martin Chapman [mailto:martin.chapman@oracle.com] Sent: Friday, May 30, 2003 1:34 PM To: Cutler, Roger (RogerCutler); Francis McCabe; www-ws-arch@w3.org Subject: RE: isa and hasa in UML and how is is-a and has-a as defined in our doc any less or more powerful than uml. its all about set theory and if you choose to model bad sets thats up to you. Martin. > -----Original Message----- > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On > Behalf Of Cutler, Roger (RogerCutler) > Sent: Friday, May 30, 2003 10:43 AM > To: Francis McCabe; www-ws-arch@w3.org > Subject: RE: isa and hasa in UML > > > > This is REALLY discouraging. I thought that the UML experts in the > room at Rennes were saying that "everybody knows" what has-a means in > UML, and all you have to do is strip it out of your favorite > undergraduate textbook. > > I have a strong feeling of distaste for ditching the definition of > "has-a" currently in the document, which at least has the virtue that > I can understand and apply it, in favor of a definition that appears > to be like the Indian rope trick -- something that everybody knows > exists because somebody else has seen it. > > -----Original Message----- > From: Francis McCabe [mailto:fgm@fla.fujitsu.com] > Sent: Friday, May 30, 2003 12:01 PM > To: www-ws-arch@w3.org > Subject: isa and hasa in UML > > > > This is in partial fulfillment of my action item re is-a and has-a > w.r.t. UML > > 0. There is a rather (unintentionally) funny comment in the UML 2.0 > spec: > > 2.3.2.3 Semantics > The meanings of the constructs are defined using natural language. > ... > > (This is after a lot of promises of being formal.) > > However, UML uses OCL for those cases where natural language is not > enough. OCL is similar to a first order predicate calculus. Having > said that, the spec does not use OCL very often; including for the > definition of relationships such as generalization (is-a) and > association (has-a kind of) > > 1. As I have indicated earlier, UML does not have a precise notion of > is-a. The closest is the generalization relationship. This is defined > in 3.50: > > Generalization is the taxonomic relationship between a more general > element and a more specific element that is fully consistent and that > adds additional information. > > A couple of comments: > > 1. Basing is-a on taxonomics raises some serious logical issues. This > is analogous to basing everything on sets: every member of the penguin > set is also a member of the bird set. > > The problem is that it becomes really difficult to talk about weird or > abstract sets. Basing is-a on this would lead to the following > counter-intuitive result: every unicorn is a yeti. (There are no > documented instances of either, so the set of unicorns and yetis is > indistinguishable.) > > A more serious issue, sticking with birds for the moment, is that it > is similarly hard to talk about properties of birds such as flying: we > could not express the fact that all birds except penguins fly. > > An even more serious issue is that we need to capture the following > situation: > > A service has an identifier > > A Web service is a service > A Web service has a URI > > The Web service's URI counts_as the service identifier > > It is that counts_as that is beyond the capabilities of UML's > generalization. We *could* extend UML's generalization, and that may > be the best overall approach. In fact, we would really need to do that > for all our relationships, use <is-a> and <has-a> and *never* rely on > UML's built-in relationships. <is-a> and <has-a> could probably be > defined in OCL. > > > More to follow.... > Frank > > > > > > >
Received on Friday, 30 May 2003 14:40:22 UTC