Tool Mentor: Analyze Service Collaborations
We use service collaborations to think through the services that must interact
to realize business process and system use cases.
Tool: Rational Software Architect
Relationships
Main Description

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.

Review the model structure

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.

 

Identify the necessary service collaborations

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.

Create service collaborations

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.

  1. 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.
  2. 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. 

Create behaviors

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 collaboration structure diagrams

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:

  1. Select the Collaboration model element.
  2. 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:  

  1. Open the Overview diagram.
  2. From the Project Explorer, drag the collaboration model element onto the diagram.
  3. If the Structure Compartment is not revealed, select the collaboration on the diagram, right-click, and select Filters > Show/Hide Compartment > Structure Compartment.
  4. 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.

Identify and create new ServiceInterfaces

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.
 

More Information