RE: hasa in UML

+1
[sorry just catching up after a mini-timeout i.e. friday afternoon off.]



> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Christopher B Ferris
> Sent: Saturday, May 31, 2003 5: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 Monday, 2 June 2003 17:13:30 UTC