Re: [soa-rm] On UML

[Frank McCabe <frank.mccabe@us.fujitsu.com>]

Personally, I do not think that mind maps/concept maps are 'informal'.  
They have at least as sound a basis as does UML. (More so in some 
cases).

However, UML does also come with some other kinds of diagrams: the 
sequence diagram, use case etc. There are other issues with sequence 
diagrams; (like the difficulty of modeling distributed systems) but 
they may well have uses for our work.

Here is another thought; about audiences: busy executives will not read 
very much; life is too short.

The WSA was structured into three main sections:

1. An introductory overview which tried to capture informally the 
'essence' of what was described. 2. A (long) section describing the 
architecture itself
3. A (not long enough) section analyzing the architecture from various 
perspectives: security, manageability, discovery, etc. This section was 
called the stakeholders' section: it tried to capture different 
stakeholders' perspectives.

The diagrams were used as a kind of index into the main text itself: 
they were not normative but merely there to help bring everything 
together. I think that a lot of people found the diagrams helpful for 
precisely that reason.

However, I would like to emphasize and defend the global structure. A 
busy executive (who is so busy that he/she will probably ask someone 
else to read our document) is most likely to read the overview and one 
or two of the stakeholder's sections.

The central part of the architecture, the technical meat of it, is 
where we, as presumed professionals, tried to hammer out the key issues 
and where the results ended up being most precisely expressed. In any 
case, no formal language (UML, logic, concept maps, English) can hope 
to capture everything intended. But often a concept is most clearly 
defined using a short English sentence. Concept maps (and UML for that 
matter) are not so good at definitions; but are good at illustrating 
relationships.

The stakeholders' sections are, IMO, very important. They explain to 
particular audiences the reasons for choices made in the architecture 
and they explain how the architecture addresses relevant issues.

Frank



On Mar 24, 2005, at 7:47 AM, Rex Brooks wrote:

> There is no question that the audience needs to be considered, and in 
> the course of developing a reference model, I think that the criteria 
> we adopt to qualify requirements and the criteria we adopt to assess 
> whether our specification satisfies those requirements ought to form a 
> compelling argument for the executives who need to make the business 
> case for SOA adoption as well as the others listed.
>
> However, those arguments will be much more convincing if they are 
> based on testable, trackable methods which a sound basis in UML 
> provides. I agree that consensus on basic SOA principles is required. 
> So far I have read nothing in the materials presented thus far that 
> isn't congruent with my own understanding of SOA principles. In fact, 
> with such material to hand, I would expect that our tasks would be 
> considerably streamlined.
>
> Ciao,
> Rex
>
> At 8:48 AM -0500 3/24/05, 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
>>>  ***********
>>>
>>>
>
>
> -- 
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309
>