RE: hasa in UML

OK by me.  And the current usage in the document is OK by me.  Both seem
clear and usable to me.

-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
Sent: Saturday, May 31, 2003 7:42 AM
To: www-ws-arch@w3.org
Subject: RE: hasa in UML



I agree, good grief! indeed. This is sounding like Bill Clinton's 
deposition... "it depends upon
what the definition of is is."

http://dictionary.reference.com/search?q=have

See the first two definitions. I think that they will do just fine. I 
really don't think that
we have to define Dick and Jane terms for our readers, but if some
insist, 
then let's
use REAL definitions please? I would rather we not become employees of
the 
Research 
Department of the Ministry of Truth developing the Eleventh Edition of
the 
Newspeak 
Dictionary.

The concepts in the architecture seem to me to have two relationships
that 
roughly
correspond to the first two forms of the definition of "have"; the first

is a possessive
relationship of a property such as in "X has a property Y"  and the
second 
is an 
associative relarionship as in "X has an association with Z".

In UML, these are modeled separately, with objects having associations 
with
other objects and objects having properties. Why don't we simply use the

same
concepts to model our architecture?

In our architecture, we could have separate subsections for each type of
*has a*. For instance:

Service

        Associations:
                a service has a description

        Properties:
                a service has an identifier 

Of course, in UML, you can assign names to the associations at each end
of the association. e.g. "a service is described by a description" and
"a description describes a service". Maybe we might want to do that, I
don't know (couldn't hurt)... it might actually be useful so that 
we
could use the terms and their named associations in the prose of the
architecture (and elsewhere) so that we could be somewhat certain that
we are being as clear as possible in what we mean.

Granted, I am not the worlds foremost authority on UML. Indeed, I have 
probably
just unloaded my complete knowledge of UML ;-P However, I would like to
propose that we adopt the proposal above and move on. This discussion is
leading us nowhere.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 05/30/2003 10:54:06 PM:

> 
> Good grief.
> 
> I had assumed from Martin's posting that aggregation is a well-known, 
> standard term in UML.  If it is, and you have just missed it, perhaps 
> he should chime in.  If not ...
> 
> If not, perhaps somebody -- anybody -- could give us some rough idea 
> what "has a" means to UML people?  I recall that the UML folk seemed 
> to be real clear (well, at least Martin seemed to be real clear) that 
> usages of "has a" consistent with your definition were inconsistent 
> with UML usage -- so surely SOMEBODY must have some idea why or 
> how????  If it is clearly different, could somebody give a hint in 
> what way it is different?
> 
> If not -- could we please just forget about it?
> 
> On another tack -- did your definitions of "is-a" and "has-a" just 
> come out of your imagination, or are they consistent with some 
> standard usage in a discipline other than UML?  If the latter, would 
> it be possible to provide citations?
> 
> -----Original Message-----
> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> Sent: Friday, May 30, 2003 4:42 PM
> To: www-ws-arch@w3.org
> Subject: hasa in UML
> 
> 
> 
> UML does not, in fact, has a direct notion of aggregation.
> 
> There are three concepts that might be pressed into the service of
> aggregation:
> 
> Association (3.41 and following)
> Composite Object (3.40)
> Collaboration diagrams (3.65 and following)
> 
> Association is simply a relationship. There is no additional semantics
> built-in. We can define our own form of association called has-a (but 
> we are trying to avoid that right?)
> 
> "A composite object represents a high-level object made of tightly
> bound parts. This is an instance of a composite class, which implies 
> the composition aggregation between the class and its parts. A 
> composite object is similar to (but simpler and more restricted than)
a 
> collaboration; ..."
> 
> I do not think that this meets our needs. It is not accurate to say
> that a service is composed of X + an identifier.
> 
> Collaborations on the other hand are not what is going on either:
> 
> "A collaboration is used for describing the realization of an 
> Operation
> or Classifier."
> 
> Frank
> 
> On Friday, May 30, 2003, at 02:10  PM, Cutler, Roger (RogerCutler)
> wrote:
> 
> >
> > Well, that's progress of a sort.  Now what do "generalization" and
> > "aggregation" mean, and how does this differ from the current 
> > definition?
> >
> 
> 
> 
>

Received on Saturday, 31 May 2003 15:08:06 UTC