CSC/ECE 517 Fall 2010/ch4 4a RJ

2010-10-20T00:09:18Z

Jmfoste2:

Use Cases 
== Introduction ==
== Use Case Basics ==
== Writing Use Cases ==
Writing Use Cases for a system is a process taken between those designing the system and the Stakeholders. There are many different ways to write Use Cases [SOURCE]. Because of this, there are many different formats that Use Cases can take when they are written. There are, however, certain guidelines that should be followed in the process of writing Use Cases. In general, these guidelines are:
<ol>
<li>Never include implementation specific terminology in the Use Case [SOURCE]</li>
<li>Each Use Case should be a set of scenarios, which include different flows of events [SOURCE]</li>
</ol>
Normally, this process is done iteratively, so that the iterations can build upon each other [SOURCE]. Below is an example of three iterations of the Use Case writing process to illustrate how it can reveal things about a system and layout the functional requirements. 

For this example, we will be creating Use Cases to solve the following problem statement:

Develop a system to allow users to schedule meetings with each other.

In this system, the stakeholders will be the users of the system. The Users will also be the only Actors in the system. 

For the first iteration, we will write out short sentences to describe the functionality that the system will have. Some use cases could be:
<table border=1>
<tr>
<td>Use Case #</td>
<td>Description</td>
<td>Actor</td>
</tr>
<tr>
<td>1</td>
<td>Request a Meeting</td>
<td>User</td>
</tr>
<tr>
<td>2</td>
<td>Approve a meeting request</td>
<td>User</td>
</tr>
<tr>
<td>3</td>
<td>Suggest a new time</td>
<td>User</td>
</tr>
<tr>
<td>4</td>
<td>View a User's schedule</td>
<td>User</td>
</tr>
</table>

In this example, the fourth Use Case may not have been an obvious requirement that could be derived from the original problem statement, but in the process of creating the Use Cases, it was discovered that it would be a good requirement for the system to have.

The next iteration would involve writing out longer descriptions for each. This could be done in paragraph form, or by writing a list. Below are the Use Cases in paragraph form:

'''Use Case 1 – Request a meeting'''
User A chooses the date and time for a meeting with User B. User A chooses User B as the recipient of the meeting request.
User A sends the meeting request to User B through the system. 
'''Use Case 2 – Approve a Meeting Request'''
User A receives a meeting request from User B and accepts the user request. A notification that User A has accepted the meeting is sent to User B. 
'''Use Case 3 – Suggest a different meeting time'''
User A receives a meeting request from User B and suggests a different time and/or date for the meeting. The response is sent to User B through
the system. 
'''Use Case 4 – View a User's schedule'''
User A would like to schedule a meeting with User B. User A starts the system and opens up User B's schedule.
User A can see when User B has already scheduled meetings and User A can then use that information to send User B a meeting request.
Use A can also access their own schedule to view when User A has scheduled meetings. 

From writing out the Use Cases with more description, it should become clear that Use Case 2 and Use Case 3 are very similar. In both Use Cases, User A responds to a meeting request and a response/notification is sent to User B. This might lead the designers of the system to combine these two Use Cases into one Use Case for "Respond to Request."

In the next iteration, we're going to use a Use Case template. There are many different Use Case templates, which include different information [SOURCES]. A template can be created that is unique for the system being described, provided each Use Case uses the same template. The template we will use will include:

Use Case <Number>: Title 
<Number>.1: <Summary/Goal> 
<Number>.2: <Actors> 
<Number>.3: <Preconditions> 
<Number>.4: <Main Path> 
<Number>.5: <Alternate Paths – including sub-flows [S] and error-flows [E]> 

Writing Use Case 1 in this format yields:

Use Case 1: Request a meeting 
1.1: Summary/Goal
User A can choose the date and time for a meeting with User B [Main]. User A can choose User B as the recipient of the meeting
request [Main], or multiple Users as the recipient [S.2]. User A sends the meeting request to User B through the system [Main].
Before User A sends the meeting request, User A can opt not to send the request and delete it [S.1]. If User B is no longer in
the system, User A receives notification that the meeting request cannot be sent [E.1]. 
1.2: Actors
Users 
1.3: Preconditions
- User A and User B are recorded as Users in the system
- User A has logged into the system 
1.4: Main Path
1) User A chooses a date for a meeting
2) User A chooses a time for a meeting
3) User A chooses User B as the recipient for the meeting request
4) User A submits the meeting request
5) User B receives the meeting request the next time User B logs into the system 
1.5: Alternative Path
S.1
User A creates a meeting request, but down not submit it. A meeting request is not sent to User B 
S.2
User A creates a meeting request for more than one User. User A submits the meeting request and each User receives it the next
time they log in 
E.1
User B is no longer a User in the system. User A receives notification that the meeting request cannot be sent. 

There are a few interesting things revealed about the system by re-writing the Use Case in this format. The most important is likely that Users will need to "log-in" to the system. This implies that there could be another Actor in the system, namely an Admin. This leads to these additional Use Cases:
<table border=1>
<tr>
<td>Use Case #</td>
<td>Description</td>
<td>Actor</td>
</tr>
<tr>
<td>5</td>
<td>Log into the system</td>
<td>User</td>
</tr>
<tr>
<td>6</td>
<td>Create a User in the system</td>
<td>Admin</td>
</tr>
</table>

Each of these new Use Cases would then go through the iterations listed above until they are in the template form. 

As you can see from the example, each iteration refines the Use Case and helps to clarify the requirements of the system.

== Use Case Diagrams ==

Use Case Diagrams are useful for showing how each component in a system will interact with other components of the system [SOURCE]. They are not good for showing the flow of events that a system will have, like the written Use Cases are [SOURCE]. Also, unlike written Use Cases, Use Case Diagrams use UML so that there is a standard.

DEFINE UML HERE

=== Components of a Use Case Diagram ===

UCDs have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements.[SOURCE: http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html#uses – DIRECT QUOTE]

'''Actors''' in Use Case Diagrams are represented by stick figures:

[[Image:Actor.png]]

'''Use Cases''' are represented by ovals:

[[Image:UseCase.png]]

'''Relationships''' are represented by Solid Lines. Sometimes, arrowheads are added to the lines to indicate the direction of the invocation, or to show which actor is the primary actor [SOURCE: http://www.agilemodeling.com/artifacts/useCaseDiagram.htm]

[[Image:Lines.png]]

Two special relationships that can be shown in a Use Case Diagram are the ''Extends'' and ''Includes'' relationships. These relationships are usually shown with a dotted line with an arrowhead and <<extend>> or <<include>> written near the line.

The ''Extends'' relationship is used to show when Use Case X is a special case of Use Case Y [SOURCE]. In this situation, the dotted line is drawn from Use Case X to Use Case Y with the arrowhead pointing to Use Case Y.

The ''Includes/Uses'' relationship is used to show that every time Use Case X is done, Use Case Y must also be done [SOURCE]. In this case, the arrow points to Use Case Y.

=== Creating a Use Case Diagram ===

A Use Case Diagram for the same system described in the Writing a Use Case might look something like:

[[Image:UCDiagram.png]]

As you can see, "Accept Meeting" and "Suggest new time" are special cases of "Respond to request". Also, from this diagram, the system designers are saying that in order to "Request a Meeting" the user must "View Schedule".

== Advanced Topics ==
== Tools and Examples ==
== Further Reading ==

== References ==