Writing Use Case Scenarios

After identifying all the different user roles and drawing a use case diagram for the software, the analyst writes a series of use case scenarios for each use case. Scenarios that describe the normal flow of events for a particular use case are called "normal" use case scenarios. It is also important to describe what happens when unexpected events occur (for example, disk-full errors, network connection errors, bad input data, etc.). Scenarios that describe the system's behavior in the face of unexpected conditions are called "abnormal" usage scenarios. It is important for the analyst to consider all possible normal and abnormal use case scenarios for a given use case [10].

Written scenarios are very important, for the following reasons:

Written scenarios help verify coverage and completeness of requirements.It is often the case that the process of gathering requirements with the customer focuses more on normal (expected) sequence of software behaviors, and does not consider all types of unexpected conditions that might occur. Before the design phase can begin, it is essential not only to identify all possible error conditions, but also to define precisely the desired system behavior when errors occur. It is quite common for the analyst to revisit the original requirements specification with the customer in order to discuss error conditions that were not anticipated in the original requirements analysis.

Use case modeling depends on detailed scenarios.The technique used to identify candidate objects in the object-oriented analysis phase, called noun extraction, depends on a detailed description of the desired system behavior. It is not possible to construct a preliminary object diagram using this technique unless detailed scenarios have been constructed.

Following text illustrates normal and abnormal use case scenarios. Although the cenarios are written in plain English, they are not particularly verbose; the focus is on short, concise sentences that detail the stepwise operation of a system in a particular context while carrying out a particular function. It is important to keep the language of the scenarios simple and unambiguous, wherever possible. Simplicity, especially when referring to various elements and actions, helps to avoid a proliferation of redundant objects that really only refer to a single object class. The analyst should review the use case scenarios after they are written to ensure that all of the steps are unambiguous. If any step is described in a way that could be interpreted as more than one concrete action on the part of the software, then the step is ambiguous and must be rewritten [11].

Actors: Driver, Admin, System

Authorization:

Normal:

1. Driver enters username and password

2. Driver clicks “Login” button

3. Driver clicks “Add new user” button, if never registry before

4. System display Main Screen – Work space

5. Admin enters username and password

6. Admin clicks “Login ” button

7. System displays Main Screen– Work space

Abnormal:

7.1 System displays incorrect of username or password

Goto 1 or Goto 3

7.2 System displays incorrect of username or password

Goto 4

 

Edit Information for new driver:

normal:

8. System display “Edit User Info” page

9. Driver fill personal information (first and last name, address, telephone)

10. Driver clicks “Save” button

11. System displays workspace

Abnormal:

11.1 System shows messg: “Missing one or more fields”. Goto 9

Input data:

normal:

12. Driver choice destinations (start, end place)

13. Driver enters id of car (car number)

14. Driver clicks “Start” button

15. System inputs driver’s information with real time

16. System shows “Driver workspace”, which has driver’s actions

Abnormal:

16.1 The destinations haven’t found on the DB Goto 12

16.2 The id can’t found on the DB Goto 13

Queue:

normal:

17. Driver clicks “Queue” button

18. System shows information pre and post drivers (driver’s name, car id, time interval)

19. Driver clicks “Back” button

20. System shows driver’s workspace

Abnormal:

20.1 System gives mssg: “Pre-driver isn’t, you are first in the queue”, or “Post-driver isn’t, you are last in the queue” Goto 18

20.2 System gives mssg: “System is updating, please wait” Goto 9

Send Request:

normal:

21. Driver clicks “Send Request” tab

22. Driver writes driver’s id, car id and problems (broke down or others) to the admin

23. Driver clicks “Send” button

24. System shows window with words “Message is sends successfully”

Abnormal:

24.1 Driver writes incorrect information Goto 22

24.2 Shows “Message is failed. Try again”, if the system has some errors (network or others)

Goto 23

Add:

normal

25. Admin clicks “Change” tab

26. Admin choice driver’s ids and ids of car for today’s job

27. Admin clicks “Add” button

28. System input information into the DB

Abnormal:

28.1 System gives “Driver or car can’t work today!” Goto 26

Delete:

normal:

29. Admin clicks “Change” tab

30. Admin choice driver’s ids and ids of car for today’s job

31. Admin clicks “Delete” button

32. System input information into the DB

Abnormal:

32.1 System gives “You can’t delete, driver or car is now hard-working!” Goto 26

Report:

normal:

33. Admin clicks “Report” button

34. System shows driver’s name, id of car, and place on the table

Abnormal:

34.1

Mapping:

normal:

35. Admin clicks “Mapping” button

36. System shows a map, which present all drivers

37. Admin clicks “back” button

Abnormal:

37.1

Requests:

normal:

38. Admin clicks “Request” button

39. Admin reads driver’s message with their problems

40. Admin change the information (add/delete)

41. Clicks “Save” button

42. System shows admin work space (table)

abnormal:

42.1 Incorrect changing Goto 40

42.2 System shows old information Goto 41

 

 

UML Class diagram

The Unified Modeling Language (UML) is a graphical language for modeling the static and dynamical aspects of a system. UML is a unification of the methodologies developed by Grady Booch, James Rumbaugh, and Ivar Jacobsen. The Object Management Group (OMG), a not-for-profit organization that promotes the use of object-oriented technology, has assumed responsibility for the further development of the UML standard [12].

UML is a language that unifies the best engineering practices for modeling systems. It defines different graphical diagrams that provide multiple perspectives of a system under development. UML defines the following diagrams:

Use case diagram

Class diagram

Behavior diagrams:

Ø Statechart diagram

Ø Activity diagram

Interaction diagrams:

Ø Sequence diagram

Ø Collaboration diagram

Implementation diagrams:

Ø Component diagram

Ø Deployment diagram

Throughout this course, we will use class diagrams to discuss the diverse elements of object-oriented design (Figure 2.2). Class diagrams show the internal structure of classes and their relationships with other classes and elements in a system [13].

 

Figure 2.2 - UML Class diagram of transport system