IT2013 004

_____________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ _____

USE CASE MODELING (PART 1) - To create a comprehensive, robust system that truly meets
users’ needs, the developers must understand each use
USE CASE DESCRIPTIONS case’s detailed steps.

- A use case description is a textual model that lists and

describes the processing details for a use case
- Use case descriptions tend to be written on two (2) separate
levels of details:
• Brief use case description
• Fully developed use case description

Brief Use Case Descriptions

- A brief use case description gives enough detail for very
simple use cases, especially when the system to be
developed is a small, well-understood application.
- Examples of simple use cases are Add product comment or
Send message.

Use Case Brief use case description

Create customer The user/actor enters new customer account
account data, and the system assigns an account
number, creates a customer record, and
creates an account record.
Look up customer The user/actor enters the customer's account
number, and the system retrieves and displays
customer and account data.
Process account The user/actor enters the order number. The
adjustment system retrieves customer and order data;the
actor enters the adjustment amount, and the
system creates a transaction record for the
adjustment.
Table 1. Use cases and brief use case descriptions
Table 2. Fully developed use case description for 'Create customer
Fully Developed Use Case Descriptions account'

- The most formal method for documenting a use case. - Table 2 is an example of a fully developed use case
- Creating a fully developed use case description increases the description of the use case, Create customer account.
probability of understanding the business processes and how - Table 3 also serves as a standard template for documenting
the system can support the developers. a fully developed description for other use cases.

06 Handout 1 *Property of STI

 student.feedback@sti.edu Page 1 of 6
 IT2013 004

_____________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ _____

- Sixth compartment – identifies other use cases and the way

they are related to the use case
- Seventh compartment – identifies stakeholders who are
interested parties other than specific actors
- Eighth and ninth compartments – the preconditions and
postconditions that provide critical information about the
system’s state before and after the use case executes.
• Preconditions – identify the state of the system for the
use case to begin, including what objects must
already exist, what information must be available, and
even the actor’s condition before beginning the use
case.
• Postconditions – identify what must be true upon
completion of the use case. These indicate what new
objects are created or updated by the use case and
how objects need to be associated.
• Two (2) reasons why postconditions are important:
1. They form the basis for starting the expected
results for test cases that will be used for testing
the use case after it is implemented.
2. The objects in postconditions indicate which
objects involved in the use case are important for
design.
- Tenth compartment – describes the detailed flow activity of
the use case.
- The scenario in Table 3 is shipping a new sale rather than
back-ordered items from a previous sale. In this use case, the
preconditions show what existing objects must exist before
the use case can execute. The postconditions indicate what
to look for when stating the expected results for a test case
Table 3. Fully developed use case description for 'Ship item' and show the objects that will need to collaborate in the design

- First and Second compartment (Scenarios/use case ACTIVITY DIAGRAM FOR USE CASES
instances) – a unique set of internal activities within a use
case - Activity diagrams are also used to document the flow of
- Third compartment – identifies the event that triggers the use activities for one use case.
case - An activity diagram can take the place of the flow of activities
- Fourth compartment – a brief description of the use case section of a use case description and created to supplement
- Fifth compartment – identifies the actor or actors the use case description.

06 Handout 1 *Property of STI

 student.feedback@sti.edu Page 2 of 6
 IT2013 004

_____________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ _____

- Figure 3 shows the Fill shopping cart use case flow of

activities. The shaded ovals show the other use cases that are
invoked while filling the shopping cart.
- The activity diagram can be used to show a richer user
experience in this way.

Figure 1. Activity diagram for ‘Create customer account’

showing an alternate way to model the flow of activities.

- Figure 1 is an activity diagram that documents the flow of

activities for the Create customer account use case. In this
example, there are two (2) swimlanes: for the customer and
the system. The customer has three activities, and the system
has five activities. Figure 3. Activity diagram for ‘Fill shopping cart’ showing richer user
- Figure 2 illustrates an activity diagram for Ship items. It experience
illustrates both repeating steps for each SaleItem in the Sale
and a decision point to choose which set of steps to perform. THE SYSTEM SEQUENCE DIAGRAM (SSD) – Identifying Inputs
- Figure 2 illustrates the correct use of the beginning and ending and Outputs
synchronization bars and the decision diamond.
Figure 2. Activity diagram for ‘Ship items’ use case - A system sequence diagram shows the sequence of
messages between an actor and the automated part of the
system during a use case or scenario.

06 Handout 1 *Property of STI

 student.feedback@sti.edu Page 3 of 6
 IT2013 004

_____________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ _____

- It is an effective tool that helps in the user interface’s initial - The origin of the message is an actor or object that sends it,
design by identifying the specific information that flows from as indicated by the lifeline at the arrow’s tail.
the user into the system and the information that flows out of - The purpose of lifeline is to indicate the sequence of the
the system back to the user. messages sent and received by the actor and object.
- A message is labeled to describe its purpose and any input
data being sent. The message name should follow the verb-
noun syntax to make the purpose clear.
- The term message in a sequence diagram is an action that is
invoked on the destination object, much like a command.

System Sequence Diagram (SSD) Notation

Figure 4. Sample system sequence diagram (SSD)

- Figure 4 shows a generic SSD with callouts annotating the

diagram.
- In a use case diagram, the actor “uses” the system, but the
emphasis in an SSD is on how the actor “interacts” with the
system by entering input data and receiving output data.
- In object notation, a box refers to an individual object and not
the class of all similar objects.
- The notation is simply a rectangle with the name of the objects
underlined.
- Lifeline or object lifeline – a vertical dashed lines underneath Figure 5. Repeating message in (a) detailed loop frame notation and
the actor and object is simply the extension of that object – (b) alternate notation
either actor or object during the use case.
- The arrows between the lifelines represent the messages that
the actor sends. Each arrow has an origin and destination.

06 Handout 1 *Property of STI

 student.feedback@sti.edu Page 4 of 6
 IT2013 004

_____________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ _____

- Figure 5(a) illustrates the notation to show repeating

operations. The message and its return are located inside a
larger rectangle called the loop frame.
- A loop frame is a notation on a sequence diagram showing
repeating messages.
- Figure 5 (b) shows an alternate notation. The square
brackets and texts inside them are called true/false
conditions for the messages.
- Complete notation for a message:
[true/false condition] return-value :=message-name
(parameter-list)
- The notation components and their functions are as follows:
• An asterisk (*) indicates repeating or looping of the
message,
• Brackets [ ] indicate a true/false condition. This is a
test for that message only. If it evaluates to true, the
message is sent. If it evaluates to false, the
message isn’t sent.
• Message-name is the description of the requested
service written as a verb-noun.
• Parameter-list (with parentheses on initiating
messages and without parentheses on return
messages) shows the data that is passed with the
message.
• Return-value on the same line as the message
(requires :=) is used to describe data being returned
from the destination object to the source object in
response to the message.
- Sequence diagrams also use two (2) addition frames to
depict processing logic, as shown in Figure 6. Figure 6. Sequence diagram notation for (a) opt frame and (b) alt
• The opt frame in Figure 6(a) is used when a frame
message or series of messages is optional or based
on some true/false conditions. - The development of an SSD based on an activity diagram
• The alt frame in Figure 6(b) is used with if-then-else falls into four (4) steps:
logic.
1. Identify the input message

06 Handout 1 *Property of STI

 student.feedback@sti.edu Page 5 of 6
 IT2013 004

_____________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ _____________________________________________________________________________________________________________________________ ___________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ _____

2. Describe the message from the external actor to the

system by using the message notation
3. Identify and add any special conditions on the input
messages, including iteration and true/false
conditions.
4. Identify and add the output return message.

Figure 7. SSD for ‘Create Customer account’ use case Figure 8. SSD for the ‘Ship items’ use case

- Figure 7 shows a return data on the dashed line for two (2) REFERENCES:
returns and a returned value on the same line as the
message for enter address. Dennis, A. Wixom B and Tegarded, D. (2015). Systems analysis and design:
- Figure 8 shows an SSD for the Ship items use case, an An object oriented approach UML (5th ed.). USA: Wiley.
example of a fully developed use case.
Satzinger, J., Jackson R., & Burd, S. (2015). Systems analysis and design in a
changing world – Course Technology. USA. Cengage Learning.

06 Handout 1 *Property of STI

 student.feedback@sti.edu Page 6 of 6