>
> Perhaps we might revisit the use of UML?
>
For future considerations on this: I would like to recommend that we not
replace the concept map with a UML diagram, but rather that we offer a
UML diagram in addition to a concept map. The concept map can serve as
the primary format for "higher-level" users (i.e. business rather than
technical), while the UML diagram can serve as the primary format for
more technical users. We may also through in an E/R digram as well?
(assuming that by UML we mean UML class diagrams)
Joe
Joseph Chiusano
Associate
Booz Allen Hamilton
700 13th St. NW
Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
Visit us online@ http://www.boozallen.com
> -----Original Message-----
> From: Duane Nickull [mailto:]
> Sent: Wednesday, December 07, 2005 1:28 PM
> To: ;
> 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:
> [mailto:]
> Sent: Wednesday, December 07, 2005 10:18 AM
> To: Duane Nickull;
> 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:]
> Sent: December 7, 2005 1:02 PM
> To: McGregor, Wesley;
> 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
>
>
>
>
