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 08:42:17 UTC