- From: Walden Mathews <waldenm@optonline.net>
- Date: Fri, 30 May 2003 15:07:06 -0400
- To: Martin Chapman <martin.chapman@oracle.com>, www-ws-arch@w3.org
+1 (and extra credit for brevity!) ----- Original Message ----- From: "Martin Chapman" <martin.chapman@oracle.com> To: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>; "Francis McCabe" <fgm@fla.fujitsu.com>; <www-ws-arch@w3.org> Sent: Friday, May 30, 2003 2:33 PM 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 15:02:53 UTC