Re: Proposal to Simplify the UML

(Sorry, Roger for the dup.  I hit Reply instead of Reply All)

I'd like to clarify a position that I thought was closer to consensus in
the call yesterday.  There is no substitute for careful engineering in
the creation of the UML diagram.  I don't think it helps to be vague
about the cardinalities where we have bothered to include the concepts.
We are not obliged, however, to include every possible slice of reality
in a single diagram.  At this point, I would argue for including the
leading core components and concepts from SOAP/WSDL with as much
precision as possible.  The cardinality discussions have already
uncovered some interesting issues (the recent multicast discussion).  We
can decide later whether to prune or expand or factor the diagram given
a particular editorial context for this work.

Mark Jones
AT&T


Cutler, Roger (RogerCutler) wrote:

> 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.
> 
>  
> 
> 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.
> 
>  
> 
> 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. 
> 


-- 
Mark A. Jones
AT&T Labs
Shannon Laboratory
Room 2A-02
180 Park Ave.
Florham Park, NJ  07932-0971

email: jones@research.att.com
phone: (973) 360-8326
   fax: (973) 236-6453

Received on Friday, 13 June 2003 15:45:28 UTC