These services have an implementation described in activity. These models represent the « business rules », manipulating the « business objects » through method calls, loop calls, existing service calls….

Then, it is possible to create services with various input parameters and to define a type for each of them, as well as the service return type.

The service as well as its activity diagram must have the same name.

Figure 1 : process stereotyped service representation

Stereotype applicable to process operation

• process

Operation described in an activity diagram.

Rules

• Parameters are optional.
• The return type must be filled, but may be “void”.
• A process service must be represented by an activity diagram: For each process service there must be an activity diagram with the same name as the operation included in the service. Inversely, an activity diagram must be associated with a process service.

Activity diagrams and process services

Activity diagrams are used to represent a process service implementation modeling. Activity diagram elements are contained in a « PK_SERVICE » stereotyped package.

Figure 2 : A process service representation

Design items

 Initial node

 Call operation action

 Object declaration

 Control flow.

 Final node

Rules

• Diagrams always start with an initial node and finish with a final node.
• The first call must be the operation stereotyped “Process”.
• A parameter call in a pin in must by declared in an “Object declaration” or in a previous pin out.
• Collaborations containing activity diagrams must be contained in a « PK_SERVICE » stereotyped package.

Call composition and rules

Calls are made of « Business Object » methods or of other methods coming from other services. A call return must contain an instance name put in the « recurrence ». The instance name can be used again as parameter for another call.

Figure 3 : Instance name in process service

Condition

 Decision.

After a Call operation action, a decision can be modeled. The decision outgoing transitions carry the condition and are described in the [guard]. The action script in use is the operators found in Java (==, <>, !=, etc.) in addition to simple operation such as getters. The [weight] is used to define the order of the decision, min weight to max weight.

• All decisions must be associated to a corresponding junction.
• The weight property must be filled for all the outgoing transitions.

Figure 4 : Condition in process service

Loop

Expansion region.

An expansion region is used in an activity diagram to create a loop. It takes a list to scan as input.

An expansion region must have an incoming flow and an outgoing flow. Possible incoming flows are: Initial node, Call operation Action, decision node and another expansion region. Possible outgoing flows are: final node, Call operation Action, decision node and another expansion region.

In the Expansion region body a sub-part of the activity diagram is defined. This sub-diagram contains the detailed actions to process inside the loop. It starts with an initial node and finishes by a call operation action.

Figure 5 : Loop in process service

Specific code

• Opaque action

An opaque action is an operation that contains raw code.