The server swimlane contains activities representing a screen « MR ». These activities are bound to operations displayed by the activity diagram controller. The MR activities support a binary choice in output. This choice is materialized by a tagged value applied to outgoing flows.

Figure 1 : AS_SERVER Swimlane

Design items

 Initial pseudo-state.

 Activity, MR.

 Control flow.

Decision

Initial pseudo-state item

• Tagged value

An initial state item has no tagged value

• Incoming flow

An initial state item has no incoming flow

• Outgoing flow

Always go to the screen action in the AS_SCREEN swimlane or to a pre-controller.

• Rules

There must be one and only one initial state by activity diagram.

• Example

Activity, MR item :

• Origin

An MR action corresponding to an operation (Service defined in PK_SERVICE package).

• Tagged value

A screen item has no tagged value

• Pin in

Operation parameters.

• Pin out
  • Operation type.
  • There can’t be more than one pin out by action.
• Incoming flow
  • A MR action may have various incoming flows. These flows can either come from another MR action or from a screen action.
• Outgoing flow
  • Go to a decision, a screen action, an external screen or other MRs.
  • A MR action can have only one @SERVICE_RETURN stereotyped outgoing flow with a @SERVICE_RETURN tagged value at OK (specifying no @SERVICE_RETURN stereotype at all means the same thing (OK is default)).
  • A MR action can have at most one @SERVICE_RETURN stereotyped outgoing flow with a @SERVICE_RETURN tagged value at NOK.
  • @SERVICE_RETURN= « NOK » tagged flows may not point at other MRs.
  • A MR action may have any number of « Exception » stereotyped outgoing flows. In these flows, the @Message and @Exception_Type tagged values must be filled.
  • Tagged value for outgoing flow :
    • SERVICE_RETURN

Tagged value applied on a flow. It specifies the RG execution result through an enumeration. It can hold the values: NOK and OK.

• @Message

Tagged value applied on a flow. It specifies the error message to display when an exception occurs.

• @Exception_Type

Tagged value applied on a flow. It specifies the exception type through an enumeration. Possible exception types:

• DB_NON_UNIQUE_OBJECT_KEY : Duplicate identifier.
• DB_OBJECT_DELETED_KEY : Thrown when the user manipulates an object which has already been deleted.
• NULL_KEY_NOT_ALLOWED : Null value allocated to an identifier.
• NULL_COLUMN_NOT_ALLOWED_KEY : Null value allocated to a required column.
• CONSTRAINT_VIOLATION : Thrown when an insert or an update violates foreign key constraint.     
• INVALID_LOGIN_INFO_KEY : Invalid Login (authentication must be activated).
• ACTION_NOT_ALLOWED_KEY : The user lacks the authorization to execute the service.
• RESSOURCE_NOT_ALLOWED_KEY : The user lacks the authorization to access a resource.
• Rules
  • A MR action must have an operation that belongs to a service.
  • A MR action must be named.
  • A MR action (call operation action) is contained in the « AS_SERVER » stereotyped swimlane.
• Example

3.5.4.1Decision item

• Tagged value
  • A Decision item has no tagged value
• Incoming flow
  • Comes from a screen action or MR action.
• Outgoing flow
  • Goes to a MR, a screen action, an external screens or other Decision.
• Rules
  • When a MR activity decision is modeled it lies upon the MR outgoing instance produced by the service in use. The decision outgoing transitions carry the condition and are described in the [guard]. The action script should use the operators found in Java (==, <>, !=, etc.) in addition to simple operations such as getters
  • The guard must be filled in every outgoing flow
• Example