OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] On UML


Hi All,

I went considerably farther than others in my suggestion for how to 
use UML, being very specific with the methodology of starting with 
real-world scenarios and developing a set of Use-Cases from which to 
derive a formal requirements document, with UML Use-Cases. While I do 
not think mind modeling or concept maps are nearly as useful as 
others seem to, I do think that they can be valuable as a starting 
point, so I don't wave them off as long as the specification writing 
moves to UML and formal Requirements before starting to build the 
specification(s).

My reason for this is to keep the effort grounded in the real world 
AND to maintain a testable set of requirements against which we 
ensure that we have covered all of those requirements. I have just 
seen too many groups start out in the weeds, dream up requirements 
that don't really reflect any reality in which their proposed 
standards will actually be tested, let alone adopted, and then get 
further lost in the weeds while they try to make the darn things 
operational. If you haven't experienced that, I don't know how to 
help you understand the pitfalls of a too-conceptual approach.

If we start at the real-world level and refrain from abstracting away 
from that more than one or two levels, we deliver a useful standard 
that will, in fact, be adopted. Remember, please, a standard that 
isn't adopted is no standard, while a de facto standard that gets 
used will trump any specification that sits up on a shelf somewhere. 
There is no shortage of examples out there.

However, pointing out bad examples as a way to make a point tends 
reinforce the legitimacy of those bad examples, and I don't want to 
do that. For my $.02 I would like to see an easily understood and 
easily implementable SOA RM that enforces the compliance with 
existing standards.

Ciao,
Rex

Admittedly, I don't see much usefulness in grand philosophical
At 9:59 AM +0100 3/24/05, Gregory A. Kohring wrote:
>Hi,
>
>As the one who raised the issue of using UML, let me clarify my
>concerns. The main issue is whether to use a standard, formal modeling
>language versus an ad-hoc, informal modeling language.  There are
>two major advantages to of using a standard modeling language:
>
>1) If it is a widely accepted standard language, then people can be
>expected to know it and do not have to learn it first to understand
>the model.
>
>2) It allows you to compare different models for their compatibility;
>a task which is very difficult if each party creates their own
>modeling language to describe their model.
>
>I nominated UML for the language to build our SOA-RM as it is a well
>known modeling language.  The concept maps shown in documents like
>those from the w3c, seem to me to be similar in conception to a UML
>domain model; hence, they could be cast into UML without the need of
>yet another informal modeling language. (Personally, I think we need
>to move beyond domain models if we are to make any impact; but a
>domain model makes a good starting point.)
>
>Now I know many people do not like UML, because
>it is quite a large language, but you do not need to use much of it
>to create a reasonable domain model.
>
>One way to move forward would be to create two parallel models, one
>formal (using UML) and one informal (using Concept Maps). Initially
>you would probably not notice the difference between the two, except
>that they looked different when printed on paper. Later,
>the UML model could be expanded to produce different views for
>expert audiences. (I think we do need a model for experts with
>more details than that contained in the model for non-experts.)
>
>
>Cheers,
>
>Greg
>
>
>Duane Nickull wrote:
>>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
>>
>
>
>--
>======================================================================
>G.A. Kohring
>C&C Research Laboratories, NEC Europe Ltd.
>======================================================================


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]