In this example we are working to realize a Purchase Order Process. We are dealing with one business
functional area, that being OrderManagement. This functional area is solely responsible for executing the Purchase
Order Process.
Our Template: Service Solution Design Model partitions the information for a given
service-oriented solution between two perspective packages -- Service Collaborations
and ServicesArchitectures -- as is seen here. Each perspective has a package for
the functional area, which itself owns a package for each service-oriented solution that is assigned to it.
There is logic for dividing the information for a given service-oriented solution between two perspectives. As is
discussed in Concept: Service Composition and Choreography, <<perspective>> Service
Collaborations is used as the home for "analysis-style" informal modeling of services and their interactions, while
more formal specification of the communities of Participants that are involved in each service-oriented solution is performed
in <<perspective>> ServicesArchitectures.
Figure 1. Parallel structure between Service Collaboration and ServicesArchitecture portions of the
service solution design template model
Figure 2 shows how the information for a given ServicesArchitecture -- which is a stereotyped UML Collaboration
-- is organized within the template. The information for a Service Collaboration is organized
similarly. In the Service Collaboration, the instances generally will be Capabilities, Interfaces, or ServiceInterfaces, and the Service Collaboration usually has no ServiceContract
instances.
Figure 2. Organization of the content for a ServicesArchitecture
Full details for the model used in this example are provided in Example: Sample SoaML Design Model.
|