One of the most important artifacts is the activity diagram associated with a use case. During functional analysis, the use case black-box activity diagram describes the functional flow (storyboard) of a use case. It groups functional requirements in actions (equivalent of operations) and shows the associated flow of information within the system and between the system and its environment (actors). During architectural design, the use case white-box activity diagram supports the allocation of actions/operations to an architectural structure.

By definition, a system-level use case and the associated black-box activity diagram describe the required functionality at a high level of abstraction, in this section referred to as logical decomposition level 0. In order to provide the relevant information for the implementation, actions/operations identified at this level may need to be detailed further. Experiences show, that if a level 0 action/operation needs to be logically decomposed, the decomposition seldom exceeds level 2.

This guideline describes the workflow, associated work products, and the specific instructions that should be followed when activities/operations of a use case black-box activity diagram are logically decomposed. The different steps are outlined using an industrial automation example

The system is a complex multi-axis manufacturing machine. Key components of this machine are 10 movable axes with partly overlapping working envelopes. For the case study the use case covering the Homing And Manual Mode was chosen.

The next figure shows the functional and state-based behavior of the use case at the top-level, also referred to as decomposition level 0. The sequence diagram describes the use case scenario of a manual movement of AxisB. The associated operation will be decomposed in the following paragraphs.

Step 1: Identify operations which need to be decomposed 

A prerequisite for this step is that the use case block behavior at the chosen system decomposition level was verified through model execution.

Step 2: Rank the identified operations

In order to achieve a common level of decomposition, the identified operations need to be ranked according to their importance. Each of the selected operations then will be decomposed by only one level before the next level of decomposition is considered.

The next steps are iteratively repeated for each selected operation.

Step 3: Decompose the selected operation

The workflow is shown for the operation moveAxisB in the figure above.

Step 3.1: Create a reference activity diagram

The decomposition of an operation is described in a new Activity Diagram, in the following referred to as Reference Activity Diagram. Note: do not use the Rhapsody feature subactivity. The reason for this is that a subactivity chart cannot be partitioned into swim lanes. The capability to allocate the decomposed operations to swim lanes is crucial during architectural design.

1. Right click Uc1HomingAndManualBlackBoxView > Add New > Diagrams > Activity Diagram
2. Name the original Activity Diagram Level0 and name the new Activity Diagram Level1_moveAxisB

Note: Throughout this section the term “level” refers to a logical decomposition hierarchy, not to an architectural decomposition hierarchy.

Step 3.2: Define the functional flow at the decomposed level

Step 3.3: Derive scenarios from the reference activity diagram

Capture the essential scenarios by means of the SE-Toolkit feature Create New Scenario From Activity Diagram. Check the consistency between the actions in the Reference Activity Diagram and the operations in the derived scenarios by means of the SE-Toolkit feature Perform Activity View Consistency Check.

Step 4: Link the reference activity diagram to the parent activity diagram

1. Move the Reference Activity Diagram Level1_moveAxisB into the parent activity diagram. Note: Rhapsody creates in the parent activity diagram a Call Behavior Activity with the name of the reference activity diagram.
2. Replace the action that was decomposed by the call behavior activity. Note: Do not add actor pins to the activity as the interactions with the actors is captured in the lower hierarchy.

Verify the link by creating an extended black-box use case scenario by means of the SE-Toolkit feature Create New Scenario from Activity Diagram.

Note: There is no need to manually complete the service request messages in the automatically generated sequence diagram. For the verification of the link only the correct sequence of operations is relevant.

Step 5: Link reference activity diagram's scenarios to parent black-box use case scenarios

In the use case black-box scenarios replace the operation that was decomposed and its associated service request message by an Interaction Operator that references to the RefAD scenarios. Name it <DecomposedOperationName>_Scenarios. The interaction operator contains the links to the scenarios that were derived from the Reference Activity Diagram.

Step 6: Update port(s) and interface(s) of the use case block

Update the use case block port(s) and interface(s) by means of the SE-Toolkit feature Create Ports And Interfaces.

Step 7: Extend the state-based behavior of the use case block

There are two ways to proceed:

• Alternative 1: Modify/extend the existing use case block statechart.
• Alternative 2: Create a copy of the existing use case block statechart and modify/extend the copy.

It is recommended to create a new use case block statechart and make it Main Behavior as shown below. 

The next figure shows the extended statechart of the use case block. Note the EnterExit point (UnsafePos) that was added to the state movingAxisB in the top-level statechart. It captures the exit from the substate in case of an anticipated envelope conflict with other axes.

Step 8: Execute the use case model

Verify the correctness of the extended use case block through use case model execution.

Outlook: Allocation of the decomposed operations during architectural design

During architectural design, the level 0 use case black-box activity diagram and its associated Reference Activity Diagram(s) are partitioned into swim lanes that represent the components of the architectural structure. Based on the chosen design concept, the operations then are “moved” into respective swim lanes. Next figure shows the allocation of the constituents of the decomposed operation moveAxisB.