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: [soa-rm] Figure Captions & Notes Needed (Re: [soa-rm] Diagam)


Hi Duane,

You certainly know I'm a fan of the UML but whether we wish use concept maps
or UML diagrams or puzzle charts or whatever, the specification needs figure
captions and, more importantly, figure notes to describe the semantics of
the illustrations if it is not intuitively obvious.  An excellent example of
this can be found in the ANSI/IEEE Std 1471-2000 standard, which is the
"IEEE Recommended Practice for Architectural Description of
Software-Intensive Systems," (see:
http://standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html).

[I do not think I'm allowed to upload a copy of this document to our OASIS
groupware site because that would probably violate an IEEE copyright law,
but you might already have a copy or can at least get your hands on one
(Working Draft editors too!).]  Needless to say, the IEEE standards board
responsible for crafting this formal standard used a simple UML class
diagram to depict a conceptual model of architecture description.  This
includes a figure caption as well as a very detailed note describing the
figure elements, i.e., what the boxes mean, what the lines connecting boxes
mean, roles, multiplicity etc. and then they refer to the UML specification
as the source of this notational standard (in this case UML v1.1).

So in summary, we should probably keep the number of figures in the SOA-RM
spec to a minimum and when we do use them (whatever the notational standard
or approach the TC agrees on), we need to include a figure caption and a
detailed note explaining the semantics of the diagram elements, and any
reference to an industry standard if one applies.

Regards...

 - Jeff E., JPL

----- Original Message ----- 
From: "Duane Nickull" <dnickull@adobe.com>
To: <McGregor.Wesley@tbs-sct.gc.ca>; <soa-rm@lists.oasis-open.org>
Sent: Wednesday, December 07, 2005 10:28 AM
Subject: RE: [soa-rm] Diagram


> The graph cannot be interpreted without the context of the accompanying
> text in the RM for SOA rev 10.  Accordingly, all concepts are abstract
> in nature.
>
> Your comments have illustrated another potential pitfall which is the
> lack of a formal reference for interpreting concept maps.  Individuals
> may accordingly make inconsistent interpretations of the concept map or
> mind maps.
>
> Perhaps we might revisit the use of UML?
>
> Duane
>
> *******************************
> Adobe Systems, Inc. - http://www.adobe.com
> Vice Chair - UN/CEFACT  http://www.uncefact.org/
> Chair - OASIS SOA Reference Model Technical Committee
> Personal Blog - http://technoracle.blogspot.com/
> *******************************
>
>
> -----Original Message-----
> From: McGregor.Wesley@tbs-sct.gc.ca
> [mailto:McGregor.Wesley@tbs-sct.gc.ca]
> Sent: Wednesday, December 07, 2005 10:18 AM
> To: Duane Nickull; soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] Diagram
>
> Thanks for the reply Duane.
>
> Here are my comments.
>
> 1. It is unclear from the diagram what is a realizable concept and what
> is completely abstract. If a service is virtual, it cannot have real
> associations hence my comment. Was it ever decided what a service is? As
> I recall it was not.
> 2. It is not the level of granularity that bothers me but the
> consolidation of static and dynamic states of existence. Mixing the two
> in the same diagram merely creates confusion.
>
> Wes
>
>  -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com]
> Sent: December 7, 2005 1:02 PM
> To: McGregor, Wesley; soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] Diagram
>
>
> Wes wrote:
>
> I would add a reference to the policy from the Service Description to
> indicate association. I agree services have policy, but it is the
> Service Description that points to the policy at design time and the
> services use them at run-time.
>
> DN: This is not needed since if a service has a policy, and a service
> description described a service, then the service description can
> described the service policy.  It is not necessary to make lines between
> every concept.
>
> I would also add a transient run-time agreement (with a lifetime
> attribute) entity as part of the interaction within the execution
> context.
>
> DN:  That can be described in the text.  With graphics like these, we
> have to stick to a consistent level of granularity for all elements of
> the graph.  The text accompanying them can describe each one on more
> detail.
>
> Duane
>
>
>




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