Re: [soa-rm] On UML

["Gregory A. Kohring" <kohring@ccrl-nece.de>]

If the goal is to cover all of these different levels, then a simple
model will not suffice. What you are describing here is the need for
a multi-level, multi-view model with increasing resolution as you
traverse from level to level. (By increasing resolution, I mean
concepts which might be important at the "developer" level will not
even appear at the "CIO" level.) Is it possible to
capture such a model using a "simple" modeling language?

At any rate, I think you have a valid point, namely we need
to fix the goal (multi-level model vs single-level model vs ?) as
this may put more constrains on how the TC should operate and what
tools are appropriate.


Cheers,

Greg




Metz Rebekah wrote:
> I am all for the using the simplest presentation for the intended
> audience.  I do believe that we'll eventually need to reach into the UML
> toolbox to provide useful information for those that "design and
> implement of service oriented architecture."  I wonder though, will we
> successfully reach others who are involved in SOA, say the executive who
> needs to make a business case decision for re-engineering business
> processes along SOA principles, by presenting what they perceive to be a
> technical model?  Will they relegate it to the IT domain without further
> consideration?  
> 
> If we take Joe's recommendation to reach back to the charter, I see
> several potential categories of audience that we need to reach some
> agreement on:
> 1)  Those that pay for SOA initiatives
> 2)  Those that design SOA (or design according to service oriented
> principles)
> 3)  Those that implement above the line services 
> 4)  Those that implement service oriented infrastructure
> 5)  Those that document SOA
> 6)  Those that must govern services and/or SOA
> 7)  Those that must re-engineer their processes to align with a service
> oriented model
> 8)  Those that want to sell service orientation (consultants and
> vendors)
> 9)  Those that want to leverage the SOA-RM for further standards work.
> 
> 
> Looking at this list, we need to come to some common basis of SOA
> principles too.  Most of us involved in the technical aspects of service
> oriented evolution are familiar enough with  SOA principles to almost
> take them for granted, but reaching the larger audience, both technical
> and non-technical, beyond early adopters will probably require coverage
> of the very basics.
> 
> Rebekah
> 
> 
>>-----Original Message-----
>>From: Duane Nickull [mailto:dnickull@adobe.com] 
>>Sent: Wednesday, March 23, 2005 7:53 PM
>>Cc: soa-rm@lists.oasis-open.org
>>Subject: Re: [soa-rm] On UML
>>
>>My thoughts on UML and Concepts Maps are that it is best to 
>>start with the simplest presentation (Concept map) and see if 
>>we have a firm need for UML.  A concept map often groups many 
>>things that may not appear in the same UML diagram which 
>>often make them easier to grok than UML.
>>
>>The position paper Matt and I submitted uses the concept maps 
>>that we used in the W3C Web Services Architecture document.  
>>Concept maps are easy to compose, however they can also be 
>>the death of a standard since they are often very open ended. 
>> It is very easy to keep adding concepts until you get 
>>something that looks like the large concept map in the W3C 
>>WSAG Technical Note.  UML, by comparison, is far more strict 
>>however leads to multiple views of the same things in 
>>attempts to relay information about them.
>>
>>I encourage everyone to read the 3 different submissions so 
>>far into the group to see how the concept/mind maps work and 
>>analyze how they can also be open ended.
>>
>>Some basic modelling conventions for keeping things simple 
>>are to use no more than 5-6 concepts per model, then layer 
>>the more technical aspects in UML.  You can use concept maps 
>>and UML to show architectural patterns too.
>>
>>Let's start with concept/mind maps to model "what" we are 
>>going to be dealing with, then delve into whether or not we 
>>need UML based on that.
>>
>>Duane
>>
>>
>>--
>>***********
>>Senior Standards Strategist - Adobe Systems, Inc. - 
>>http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary - 
>>http://www.unece.org/cefact/ Adobe Enterprise Developer 
>>Resources  - http://www.adobe.com/enterprise/developer/main.html
>>***********
>>
>>
> 
> 


-- 
======================================================================
G.A. Kohring
C&C Research Laboratories, NEC Europe Ltd.
======================================================================