RE: Proposal to Simplify the UML

Message
  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Cutler, Roger (RogerCutler)
  Sent: Friday, June 13, 2003 9:52 AM
  To: Martin Chapman; www-ws-arch@w3.org
  Subject: RE: Proposal to Simplify the UML


  OK, if you think cardinalities are really important, I think you should be
a lot more careful about whether you use * or 1,..  It appears to me, and I
think that Chris Ferris is agreeing, that 1,.. is actually correct in a
bunch of places you have *.  I tried to point out a few by asking questions
based on the existing *'s, but I did not try to do so exhaustively.  You
have a lot of *'s and I really suspect that a large number of them should be
1,..  If one actually is making the distinction they are not at all the
same -- one implies that a spec MUST require that something is there
(generally if something else is there), the other implies that a spec MUST
allow something to be missing (even if something else is there).  Both can
be non-trivial requirements.

  [mdc] i have changed the sender to be 1..*, the reciever is still *. If
you think other places need to change from * to 1..* please point them out.
  [mdc] and yes the distinction between * (may) and 1..* (must) is quite
important to capture.

  Yes, my suggestion below is indeed counter to the previous one, which was
to use the terms consistently as per standard definition.  I suggest below
that we define our own, non-standard usage that allows a looser cardinality
than in the standard but also supports the more restrictive terms when we
are sure that we mean them.

  [mdc] this make no sense to me. using *, 0..*, and 1..* are all part of
the uml standard. so aside from restricting ourselves to one form of zero or
more
  [mdc] what else is needed?

  I still think that putting in all these cardinalities is going to get us
involved in a bunch of discussions that are more detailed than they need to
be, but it seems to me that this is certainly a view upon which reasonable
people can differ.

  -----Original Message-----
  From: Martin Chapman [mailto:martin.chapman@oracle.com]
  Sent: Friday, June 13, 2003 11:19 AM
  To: Cutler, Roger (RogerCutler); www-ws-arch@w3.org
  Subject: RE: Proposal to Simplify the UML



    -----Original Message-----
    From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Cutler, Roger (RogerCutler)
    Sent: Thursday, June 12, 2003 6:02 PM
    To: www-ws-arch@w3.org
    Subject: Proposal to Simplify the UML


    In accordance with the expression on the concall today that we should
not incorporate excessive detail into the UML, I would like to propose the
following guidelines (which I am perfectly willing to admit are phrased
loosely):

    1 - Cardinalities should be omitted unless they are really obvious (and
contribute to understanding the sense of what is going on -- often where
there is a "1")  or where they are really non-trivial and we have discussed
and agreed on them (as one hopes will happen with the number of receivers or
paths).

    The tool I use doesn't give me much choice in eliminating some of the
"1", which I agree is redundant. If someone elee wishes to redraw in another
tool to eliminate the "1"s then they are welcome to do that,

    2 - We adopt a convention, for the purposes of this document only and
documented prominently (since it is nonstandard), that "*" means "0 or more
OR 1 or more, we are not specifying which".  When we really know which we
mean and want to make a point of it, we always use "0,.." or "1,..".

    What is not standard? * means 0 or more. This is now counter to the
changes you suggested yestereday (to elimitae 0..*)

    There are two reasons for this.  To avoid:

    1 - Endless fruitless arguments about arcane issues (like whether a
message exists if it has not been read . does a sender exist if he has not
sent . does a . uh, SLAP! . gotta stop .)

    Why is this fruitless. It helps to fully understand what is going on.

    2 - The possibility of people down the line saying things like:
       A:"The WSA DEMANDS that if a spec will allow a FOO it must in all
cases tell you how to have a BAR";
       B:"The WSA DEMANDS that the spec MUST be capable of having a MEAL
without a BARF".

    and the problem with this is?


    Well, maybe in the latter case it's reasonable, but surely you see what
I'm talking about.  Both cases are, in fact, silly if we never really
thought about how FOO's and MEAL's relate to BAR's and BARF's.

    The point of doing this execrise is exactly to consider all such issues.
Its not just about pretty pictures.

    Let's keep the detail down to things we really mean.

    So after we finish this current excercise of modelling soap, we need to
decuide what detail to elimiate for our doc.

    I suggest that cardinalities are imporant and we should be looking to
supress some of the boxes and relationships.