Page 90 - DCAP308_OBJECT_ORIENTED_ANALYSIS_AND_DESIGN

Object Oriented Analysis and Design

Notes
Example: The customer as an actor because the customer is using the ordering system.
The diagram takes the simple steps listed above and shows them as actions the customer might
perform. The salesperson could also be included in this use case diagram because the salesperson
is also interacting with the ordering system.
From this simple diagram the requirements of the ordering system can easily be derived. The
system will need to be able to perform actions for all of the use cases listed. As the project
progresses other use cases might appear. The customer might have a need to add an item to an
order that has already been placed. This diagram can easily be expanded until a complete
description of the ordering system is derived capturing all of the requirements that the system
will need to perform.

Each Use Case describes the functionality to be built in the proposed system, which can include
another Use Case’s functionality or extend another Use Case with its own behavior.

Figure 7.4: Extending Use Case

A Use Case description will generally includes:
General comments and notes describing the use case.
Requirements: The formal functional requirements of things that a Use Case must provide
to the end user, such as <ability to update order>. These correspond to the functional
specifications found in structured methodologies, and form a contract that the Use Case
performs some action or provides some value to the system.

Constraints: The formal rules and limitations a Use Case operates under, defining what
can and cannot be done. These include:

Pre-conditions that must have already occurred or be in place before the use case is
run.

Example: <create order> must precede <modify order>
Post-conditions that must be true once the Use Case is complete.

Example: <order is modified and consistent>
Invariants that must always be true throughout the time the Use Case operates.

84 LOVELY PROFESSIONAL UNIVERSITY