[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 the SOA-RA
see www.magicdraw.com On Oct 18, 2006, at 1:21 PM, Duane Nickull wrote: > 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 * > ****************************************************** > > ------------------------------------------------------------------------ ------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]