Step 5 to Step 6
Use Case Modeling – Step 5: Performing a Textual Analysis
A textual analysis need to be performed for each of all the use cases based on their descriptions, yielding a set of candidate classes in the process. These classes will then be considered for inclusion in the domain class model which serves as a preliminary class model for the future development of the initial class model.
A textual analysis on the Process Order use case is demonstrated in Table 4. All the nouns and noun phrases have been underlined in the brief use case description.
Use Case:
Schedule Delivery
Use Case ID:
UC-300
Actor:
Order Processing Clerk
Description:
The Order Processing Clerk selects an order from the list of filled sales orders. The system displays the sales order details, and the member’s telephone number and address are displayed. The Order Processing Clerk enters the delivery date and time after talking with the member over the phone. The system records the delivery date and time in a dispatch request to the delivery team.
Table 4 – Textual Analysis on the Schedule Delivery Use Case
|
Note: Recall that a use case model often consists of several use cases. Each of the use cases has its own corresponding use case description, including its brief description and the flow of events, providing more details. As you progress in the development of the project, more and more use case will be developed according to the use case schedule. Refine and enrich the initial class model iteratively and incrementally by performing the textual analysis for each of the use cases that you have developed. |

Figure 6 – Initial Class Model
Expanding on the Initial Use Case Model
The initial use case model is expanded incrementally in subsequent phases of the system development life cycle. In each phase, some use cases are selected and analyzed to produce detailed specifications of the necessary behavioral and functional requirements. Common behaviors and alternative behaviors of use cases are identified when the use cases are expanded and analyzed. These behaviors are extracted to become inclusion, extension and generalization use cases. The inclusion, extension and generalization use cases help to make the use case model more maintainable. The classes identified in the analysis of the use cases are used to update and refine the class model.
Use Case Modeling – Step 6: Developing Base Use Case Descriptions
Table 5 shows a use case description for an order processing system. In this example, the use case name is Place Order. Along with the name, you need to provide a brief description of each use case. The pre-condition can effectively reduce the complexity of the use case. For example, as a registered member, one must already have a valid account. Consequently, many alternative situations such as invalid account, account on-hold etc will not be applicable to valid members.
| Use case name: | Place Order |
| Use case ID: | UC 100 |
| Super Use Case: |
The name of the generalized use case to which this use case belongs. |
| Actor(s): | Customer Service Assistant |
| Brief description: | A Customer Service Assistant places an order and then submits it for processing. |
| Pre-conditions: | The member must have registered with the system. |
| Post-conditions: | The Customer’s order will be directed to the order process department for processing. |
| Flow of events: |
The Customer Service Assistant finds the member’s record by entering the member’s ID or name. The system displays a list of members which match the information entered by the Customer Service Assistant. The Customer Service Assistant selects the required member record. The system displays the details of the member. The Customer Service Assistant selects “Place Order”. A new order form and order ID are then generated and displayed. The Customer Service Assistant selects items from the catalog and adds them to the order. The Customer Service Assistant submits the order for processing. The system records the order and forwards it to the Order Processing Clerk. |
| Alternative flows and exceptions: |
At any time the Customer Service Assistant can decide to suspend the ordering process and come back to it later, or to cancel the order. |
| Priority: | High |
| Non-behavioral requirements: | The system should be able to handle 20,000 new orders per day. |
| Assumptions: | |
| Issues: | Is there any limit on the amount of an order? |
| Source: | User Interview Memo 21, 8/9/01 |
Table 5 – Description for the Place Order Use Case

