[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Some visual (UML/SysML) modeling suggestions for theSOA-RA
The general rule is that stick men are only used in certain types of diagrams. In these diagrams, they only represent the entity with no further knowledge captured in the lexicon. "actor" hence has no attributes or other information associated with it other than written notes. In CVD's, you may assign attributes to a class to fill in more detail. D On 10/18/06 10:33 AM, "Francis McCabe" <frankmccabe@mac.com> wrote: > 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> > -- ****************************************************** Sr. Technical Evangelist - Adobe Systems, Inc. * Chair - OASIS SOA Reference Model Technical Committee* Blog: http://technoracle.blogspot.com * ******************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]