Introduction to Software Engineering|| (Documenting Use Cases and Activity Diagrams)|| ISE

Introduction to Software Engineering

 (Documenting Use Cases and Activity Diagrams)

Objectives

·         Study how to document use cases in detail.

·         Know about scenarios (flow of events) and its importance.

·         A deeper understanding of UML activity diagrams.

·         Practicing flow of events and activity diagrams

Outline

·         Writing flow of events.

·         The flow of events template and example.

·         Activity diagrams.

·         Examples.

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.

Flow of Events

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.

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.

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.

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.

Flow of Events for the Select Courses to Teach Use Case

Preconditions

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

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, REVIEW, 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 REVIEW, the S-3: review schedule sub-flow is performed.

·         If the activity selected is PRINT, the S-4: print a schedule sub-flow is performed.

·         If the activity selected is QUIT, the use case ends.

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 (E6). The system removes the link to the professor (E-7). The use case then begins again.

S-3: Review a Schedule:

The system retrieves (E-8) and displays the following information for all course offerings for which the professor is assigned: course name, course number, course offering number, days of the week, time, and location. When the professor indicates that he or she is through reviewing, the use case begins again.

S-4: Print a Schedule

The system prints the professor schedule (E-9). The use case begins again.

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 system cannot retrieve schedule information. The use case then begins again.

E-9: The schedule cannot be printed. The user is informed that this option is not available at the current time. The use case begins again.

Use case flow of events documents are entered and maintained in documents.

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

·         Activities- performance of some behavior in the workflow.

·         Transition- passing the flow of control from activity to activity.

·         Decision- show where the flow of control branches based on a decision point:

o   Guard condition is used to determine which path from the decision point is taken.

·         Synchronization-what activities are done concurrently? What activities must be completed before processing may continue (join).

In-Class Example

Now you will learn how to apply the above-mentioned methods to write flow of events and drawing activity diagrams from the use case(s) flow of events.

Exercises

Apply to your Project

Deliverables

You should use these techniques to write flow of events and draw activity diagrams for your semester project.