Experiment 9 (Documenting Use Cases and Activity Diagram)

Objectives:

 Study how to document use cases in detail.

 Know about scenarios (flow of events) and its importance.
 Deeper understanding of UML activity diagrams.
 Practicing flow of events and activity diagrams using Violet UML Editor.

Estimated Time: 30 minutes

1. Background

Each use case is documented with a flow of events. The flow of events for a use case is a
description of the events needed to accomplish the required behavior of the use case. Activity
diagrams may also be created at this stage in the life cycle. These diagrams represent the
dynamics of the system. They are flow charts that are used to show the workflow of a system;
that is, they show the flow of control from one activity to another in the system.

2. Flow of events

2.1 A description of events required to accomplish the behavior of the use case, that:
 Show WHAT the system should do, not HOW the system does it.
 Written in the language of the domain, not in terms of implementation.
 Written from an actor point of view.

2.2 A flow of events document is created for each use case:

 Actors are examined to determine how they interact with the system.
 Break down into the most atomic actions possible.

2.3 Contents of Flow of Events

 When and how the use case starts and ends.

 What interaction the use case has with the actors.
 What data is needed by the use case.
 The normal sequence of events for the use case.
 The description of any alternate or exceptional flows.

2.4 Template for the flow of events document

Each project should use a standard template for the creation of the flow of events
document. The following template seems to be useful.

X Flow of events for the <name> use case

X.1 Preconditions
X.2 Main flow
X.3 Sub-flows (if applicable)
X.4 Alternative flows

where X is a number from 1 to the number of use cases.

A sample completed flow of events document for the Select Courses to Teach use case follows.

1. Flow of Events for the Select Courses to Teach Use Case

1.1 Preconditions
Create course offerings sub-flow of the maintain course information use case must
execute before this use case begins.

1.2 Main Flow

This use case begins when the professor logs onto the registration system and enters
his/her password. The system verifies that the password is valid (E-1) and prompts the
professor to select the current semester or a future semester (E-2). The professor
enters the desired semester. The system prompts the Professor to select the desired
activity: ADD, DELETE, PRINT, or QUIT.

 If the activity selected is ADD, the S-1: add a course offering sub-flow is performed.
 If the activity selected is DELETE, the S-2: delete a course offering sub-flow is
performed.
 If the activity selected is PRINT, the S-3: print a schedule sub-flow is performed.
 If the activity selected is QUIT, the use case ends.

1.3 Sub-flows

S-1: Add a Course Offering:

The system displays the course screen containing a field for a course name and
number. The professor enters the name and number of a course (E-3). The system
displays the course offerings for the entered course (E-4). The professor selects a
course offering. The system links the professor to the selected course offering (E-5).
The use case then begins again.

S-2: Delete a Course Offering:

The system displays the course offering screen containing a field for a course offering
name and number. The professor enters the name and number of a course offering (E-
6). The system removes the link to the professor (E-7). The use case then begins
again.

S-3: Print a Schedule

The system prints the professor schedule (E-8). The use case begins again.
 1.4 Alternative Flows

E-1: An invalid professor ID number is entered. The user can re-enter a professor ID
number or terminate the use case.

E-2: An invalid semester is entered. The user can re-enter the semester or terminate
the use case.

E-3: An invalid course name/number is entered. The user can re-enter a valid
name/number combination or terminate the use case.

E-4: Course offerings cannot be displayed. The user is informed that this option is not
available at the current time. The use case begins again.

E-5: A link between the professor and the course offering cannot be created. The
information is saved and the system will create the link at a later time. The use case
continues.

E-6: An invalid course offering name/number is entered. The user can re-enter a valid
course offering name/number combination or terminate the use case.

E-7: A link between the professor and the course offering cannot be removed. The
information is saved and the system will remove the link at a later time. The use case
continues.

E-8: The schedule cannot be printed. The user is informed that this option is not
available at the current time.

3. Activity Diagrams

Activity diagrams are flow charts that are used to show the workflow of a system.
They also:

 Represent the dynamics of the system.

 Show the flow of control from activity to activity in the system.
 Show what activities can be done in parallel, and any alternate paths through the flow.

Activity diagrams may be created to represent the flow across use cases or they may
be created to represent the flow within a particular use case. Later in the life cycle,
activity diagrams may be created to show the workflow for an operation.
Activity Diagram Notation

 Initial State or Start Point. A small filled circle followed by an arrow represents the
initial action state or the start point for any activity diagram. For activity diagram using
swimlanes, make sure the start point is placed in the top left corner of the first column.

 Activity or Action State. An action state represents the non-interruptible action of objects.
You can draw an action state in SmartDraw using a rectangle with rounded corners.

 Action Flow. Action flows, also called edges and paths, illustrate the transitions from one
action state to another. They are usually drawn with an arrowed line.

 Object Flow. Object flow refers to the creation and modification of objects by activities.
An object flow arrow from an action to an object means that the action creates or
influences the object. An object flow arrow from an object to an action indicates that the
action state uses the object.

 Decisions and Branching. A diamond represents a decision with alternate paths. When
an activity requires a decision prior to moving on to the next activity, add a diamond
between the two activities. The outgoing alternates should be labeled with a condition or
guard expression. You can also label one of the paths "else."
  Guards. In UML, guards are a statement written next to a decision diamond that must be
true before moving next to the next activity. These are not essential, but are useful when a
specific answer, such as "Yes, three labels are printed," is needed before moving forward.

 Synchronization. A fork node is used to split a single incoming flow into multiple
concurrent flows. It is represented as a straight, slightly thicker line in an activity
diagram. A join node joins multiple concurrent flows back into a single outgoing flow. A
fork and join mode used together are often referred to as synchronization.

 Sent and Received Signals. Signals represent how activities can be modified from
outside the system. They usually appear in pairs of sent and received signals, because the
state can't change until a response is received, much like synchronous messages in a
sequence diagram. For example, an authorization of payment is needed before an order
can be completed.

 Final State or End Point. An arrow pointing to a filled circle nested inside another circle
represents the final action state.

4.1 Lab Exercise

Estimated Time: 45 minutes
Open Violet UML Editor and draw the following diagram. Note that a full tutorial for how
to use Violet to draw this diagram is provided in the document entitled Activity Diagram
Violet Tutorial.

4.2 Lab task:

Estimated Time: (To be submitted in the given due date)

- Draw the activity diagram for the flow of events for the Select Courses to Teach Use
Case that was defined in this lab manual.
- Consider all the flow of events that was defined in the use case document and reflect it in
your activity diagram.
- You can create individual activity diagram for each flow of events.

4.3 Deliverables

- Take a screenshot of your activity diagram and paste it in MS word document with your
name and ID number.
- Submit your work in Blackboard on or before the given due date.