Re: [soa-rm] Some visual (UML/SysML) modeling suggestions for theSOA-RA

[Duane Nickull <dnickull@adobe.com>]

Jeff:

For CVD's we need to use classes with the actor stereotype IMO and for UCD
and others we can use the stickmen.

All - what UML tools are you using?  I heard one mentioned on the call today
but given we hve people on both Mac's and PC's and XMI is not perfected, we
might run in to problems trying to edit each others diagrams.  Perhaps each
diagram should have one owner?

D


On 10/18/06 10:17 AM, "Jeffrey A. Estefan" <jeffrey.a.estefan@jpl.nasa.gov>
wrote:

> RA Team,
> 
> As far as visual modeling is concerned, specifically, UML 2 modeling, I
> suggest the following:
> 
> 1) We model service participants (consumers and providers) as UML actors
> (either as classes with the "actor" stereotype or as stick figures, or both,
> depending on context of use)
> 
> 2) We model agents, services, and mediators as UML components.  [Note: I'm
> grounding the concepts of participants (as well as stakeholders), agents,
> and services based on the attached conceptual model from Frank.]  Agents
> should use the "agent" stereotype and services should use the "service"
> stereotype.  Service components should also reflect UML 2 interfaces and
> ports and these should be labeled.  Some good examples of this are
> illustrated in the attached recommended UML Profile for SOA.  Mediators
> should use a stereotype the most closely matches its function, e.g.,
> "registry" or "repository" or "discovery" just as an example.
> 
> 3) We model the higher-level (end state) Service Description as a UML
> artifact.  We can do this one of three ways.  As 1) UML class with the
> "artifact" stereotype, my least favorite, 2) UML component diagram with
> "artifact" stereotype, or my preferred method, provided UML tooling support
> exists, 3) UML component using dog-eared tag notation.  Unfortunately, not
> all UML modeling tools support the latter today even though its part of the
> UML 2 spec.  This higher-level model of the service description can be used
> in our Interaction models, which we can illustrate with UML activity,
> sequence, and communication diagrams to model behavior.
> 
> 4) We model architecture views and viewpoints based on the example depicted
> in the SysML 1 specification.  You can see an example of this applied to our
> work in the first figure of my initial write-up on interacting with services
> under TheArchitecture Wiki at:
> http://wiki.oasis-open.org/soa-rm/TheArchitecture/Interaction .   You will
> need to log in to see the diagram.
> 
> 5) Finally, that we decide as a team whether or not to include frames as
> part of our UML models.  The UML 2 spec does not mandate their use, but
> curiously, the SysML spec does.  This is not a big deal now but we'll need
> to settle on it before we go public with the first draft of the RA.
> 
> Modeling the conceptual model of the elements that comprise a Service
> Description should be modeled as a UML class diagram with the full set of
> associations between elements.
> 
> Currently, these are the major RM elements that are associated with the
> Service Description:
> 
> 1) Information Model
> 
> 2) Behavior Model
> 
> 3) Service Reachability
> 
> 4) Service Functionality
> 
> 5) Service Interface
> 
> 6) Contracts & Policies
> 
> Of course each of these elements, in turn, will need to be modeled.
> 
> There are some good examples of use of UML class diagrams for depicting
> information models.  See, for example, the following:
> 
> * ebXML Registry Information Model (ebXML RIM)
> http://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrim.pdf
> 
> * Java API for XML Registries (JSR 93)
> http://java.sun.com/xml/downloads/jaxr.html
> 
> (Leverages ebXML RIM and UDDI 2 data descriptions heavily)
> 
> * Modeling WSDL using UML
> http://www.ftponline.com/javapro/2003_10/online/wsdl_aparikh_10_24_03/
> http://ieeexplore.ieee.org/iel5/10610/33519/01592447.pdf?arnumber=1592447
> 
> With respect to principles associated with service descriptions and the
> minimum set of elements a service description should contain, there is a
> good discussion in the Newcomer/Lomow book (Understanding SOA with Web
> Services) pp. 109-117.  Due to copyright restrictions, I will not share them
> in this note.  I should point out that the authors actually use the term
> "service contracts" but the context in their use is really synonymous with
> what we mean by service descriptions.  There is some very useful reference
> material contained therein nonetheless, and more importantly (from pp.
> 109-112), material that is not necessarily specific to Web services and WSDL
> contracts.
> 
> Duane mentioned a number of potentially useful abstract models as resources
> (e.g., WS-Policy) and I hope that he and the rest of the team will share
> these references in forthcoming e-mail notes and Wiki entries.
> 
> If you have additional questions with respect to modeling guidance.
> 
> Regards...
> 
>  - Jeff E. 

-- 
******************************************************
Sr. Technical Evangelist - Adobe Systems, Inc.       *
Chair - OASIS SOA Reference Model Technical Committee*
Blog: http://technoracle.blogspot.com                *
******************************************************