As seen in the Sample SoaML Design Model, we have created a Purchase Order Process
<<soSolutionPackage>> under the OrderManagement functional
area package to think through what is required to implement the Purchase Order
Process. Further, we have created a single Process Purchase Order service
collaboration under this service-oriented solution package. We decided
to model the collaboration by using an activity, as Figure 1 shows.
Figure 1. Sample design model of the collaboration,
using an activity
The activity diagram for the collaboration reveals that four roles -- invoicer,
orderProcessor, productions, and shipper -- are involved in realizing the Purchase
Order Process, and that the orderProcessor role uses the other three roles.
The structure diagram in Figure 2 reflects this information for the collaboration
and its activity diagram.
Figure 2. Structure diagram of the four roles in the
collaboration
Creating the package hierarchy for functional
areas, service-oriented solutions, and service collaborations
This was a small, simple problem. Here, we decided to name the service-oriented
solution after the process that was being addressed. By doing this, less expansion
of the overall package structure was required before we were able to see
where in the model a particular business process or use case was being
addressed.
If this had been a large design effort, we probably would have taken a different
approach. In this case, we would have created a service-oriented solution package
to manage each group of related business processes or use cases that a functional
area either owns or supports. Then each solution package could own multiple
service collaborations, each of which was mapped to a given business process
or use case.
|