RE: Proposal to Simplify the UML

+1 Mark,

These diagrams should contain as much of the modeling detail as possible as articulated by XMLP and WSD. The wsdl diagrams which Martin and I are working jointly on is doing just this and should be ready soon. After this exercise, the group may wish to apply an abstract exercise. These 2 activities should be kept separate.

MikeM
 


>-----Original Message-----
>From: ext Mark A. Jones [mailto:jones@research.att.com]
>Sent: June 13, 2003 03:45 PM
>To: Cutler, Roger (RogerCutler)
>Cc: Martin Chapman; www-ws-arch@w3.org
>Subject: 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 17:13:17 UTC