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

[Francis McCabe <frankmccabe@mac.com>]

Certainly for some sections, using a stick figure may sufficient for  
participant.
It is not sufficient for the serviceasbusiness view.
Frank

On Oct 18, 2006, at 10:17 AM, Jeffrey A. Estefan 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.
> <UML-ProfileForSOA.pdf>
> <stakeholder.png>