Overview
This tool mentor describes how to create and use service collaborations
to reason through the services that are involved in realizing a business process
or a use case. The provided instructions apply to IBM® Rational® Software
Architect for WebSphere Software, Version 7.5.4 or later.
Model element creation techniques are described in Tool Mentor: Create SoaML Model Elements. Those instructions are not repeated
here.
The diagram that follows illustrates the portions of the service model
structure that are used in this tool mentor. These are among the notable aspects:
- Service collaborations are created and built under the "1 - Service Collaborations"
package structure. The collaborations are organized under Service-Oriented
Solution (SO Solution) packages.
- Each <<soSolutonsPackage>>
${soSolution.co} building block in the
<<modelLibrary>> includes a sub-building block for
a Service Collaboration.
- The <<modelLibrary>>
also includes a stand-alone <<Service
Collaboration>> building block.
Allocate a service collaboration to support each business process and use case
that your service solution modeling effort is addressing. You might find the need
for more service collaborations as your modeling progresses, but this initial
set provides a good starting point.
Tool Mentor: Identify Service-Oriented Solutions walked you through the
process of mapping SO Solution packages to the business processes and use cases
that your modeling effort supports. You leverage that previous work here.
All service collaborations are created within the package structure that is
rooted in the 1 - Service Collaborations package.
Under each SO Solution package, create a service collaboration for each business
process or use case that has been allocated to that package. Use standard building
block copy-and-paste and text find-and-replace procedures to create the packages.
- The SO Solution package building block includes a single service collaboration
sub-building block, so the structure for the first Service Collaboration already
exists for you. Use find-and-replace to name the provided elements of
this service collaboration appropriately.
- Create each subsequent service collaboration by using the <<Service
Collaboration>> ${soSolution.co) ${service.collab} sub-building
block that is found in the <<modelLibrary>>,
under the <<soSolutionPackage>>
${soSolution.co} building block. Use copy-and-paste to create this
under the SO Solution package. Use find-and-replace twice to name it appropriately:
- Perform the first round of find-and-replace to set the name of the SO
Solution into the service collaboration.
- Perform the second round of find-and-replace to assign a unique
name to the service collaboration.
Each service collaboration includes both an Activity and an Interaction. Use
one or the other for your behavioral modeling. To declutter the model, delete
the model elements that pertain to the behavioral representation that will not
be used. It helps if the members of each team collectively make a unified decision
regarding which type of behavioral modeling they will adopt.
In each service collaboration, model the interactions between model elements
that are needed to realize the business process, subprocess, or use case that
the collaboration is targeted to address. Follow the guidance in "Modeling
user workflow by using activity diagrams" if you are modeling behavior
using Activities. Use "Modeling
the interactions between objects in UML" if you are using interactions.
Example: Model Service Collaborations illustrates a sample Activity diagram.
In this case, Activity Partitions have been created for each of four capabilities. The
Actions represent services that must eventually be provided by a service
provider.
See Guideline: Considerations During Service Collaboration Modeling for further
advice.
Create a structure diagram to illustrate how the roles involved in the collaboration
are related to each other. Use the composition diagram that is part of the Service
Collaboration building block. When completed, this diagram will show
all of the roles that are involved in the collaboration and how they relate
to each other. See
"Defining the internal structure of classifiers by using composite structure
diagrams" for guidance on creating structure diagrams.
The act of sequence diagramming automatically creates a property in the owning
collaboration for each Lifeline. Opening the service collaboration's composition
diagram will show the diagram prepopulated with these properties. All that remains
is to connect the properties with UML connectors. Draw a connector between each
pair of properties with related Lifelines linked by a message.
Activity diagramming does not automatically create collaboration properties
to represent the partitions. To populate the composition diagram, you must manually
create a collaboration role for each partition. You can type this role
with an appropriate model element, such as a Capability
or a ServiceInterface. Create
a role with just two steps:
- Select the Collaboration model element.
- Right-click and select Add UML > Role.
The new roles will automatically be added to the collaboration's composition
diagram. Connect them appropriately with UML connectors. Draw a connector between
each pair of roles with related partitions that contain Actions connected by
a flow.
Optionally, build the Overview diagram of the service collaboration:
- Open the Overview diagram.
- From the Project Explorer, drag the collaboration model element onto
the diagram.
- If the Structure Compartment is not revealed, select the collaboration
on the diagram, right-click, and select Filters > Show/Hide Compartment
> Structure Compartment.
- Drag the collaboration's Activity (or Interaction) onto the diagram. If
you are dragging an Activity and its activity diagram compartment appears,
it will display the Activity diagram in a disorganized state. You can manually
reorganize this, though. As an alternative, do this:
- Select the Activity, right-click, and select Filters > Show/Hide
Compartment > Name Compartment Only.
- Drag the Activity diagram from the Project Explorer and place its icon
close to the Activity.
An example of this style of representation appears in the SoaML
service solution design sample model. In that model, see the Overview diagram
for the Process Purchase Order ServicesArchitecture.
Create either a new capability or a new ServiceInterface to support each role
that was not typed by a previously-identified element. The rigor of your governance
process might dictate that you create a capability (candidate service), so that
it can undergo service
litmus testing.
Use the rules and examples found in Guideline: Identify Service Interfaces from Collaboration Role Interaction Patterns to
determine whether to create a ServiceInterface as a simple ServiceInterface
or as a collaborating ServiceInterface.
Create new ServiceInterfaces using the building block-based approach described in Tool Mentor: Create Service Interfaces from Candidate Services.
It is possible that you created new ServiceInterfaces during the course
of building out sequence diagrams. If so, it is likely that such elements
were created under the parent of the Collaboration that owns your sequence
diagram. If this is true, relocate each such ServiceInterface to a proper
location within the implementation
package structure of the model. Ensure that this ServiceInterface is located within
a package structure which is equivalent to what is created using the ServiceInterface model
building block.
|