Konsep SQ 1

CHAPTER 5 ■ Use Case Modeling 139
Figure 5-6 Activity diagram for

Fill shopping cart showing richer Customer System
user experience
Search for product
Look at product
reviews
Select options
and quantity
Search and view Add to cart

accessories
Select accessory
options and quantity
Add to cart
© CengageLearning ®
■■ The System Sequence Diagram—Identifying
Inputs and Outputs
In the object-oriented approach, the flow of information is achieved through
sending messages either to and from actors or back and forth between internal
system sequence diagram (SSD) objects. A system sequence diagram (SSD) is used to describe this flow of
a diagram showing the sequence of messages information into and out of the automated portion of the system. Thus, an SSD
between an actor and the automated part of documents the inputs and the outputs and identifies the interaction between
the system during a use case or scenario
actors and the system. It is an effective tool to help in the initial design of the
user interface by identifying the specific information that flows from the user
into the system and the information that flows out of the system back to the
user. An SSD is a special type of UML sequence diagram. You will learn more
about detailed sequence diagrams in Chapter 13.
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
140 PART 2 ■ Systems Analysis Activities
■■ SSD Notation
Figure 5-7 shows a generic SSD with callouts annotating the diagram. As with
a use case diagram, the stick figure represents an actor—a person (or role) who
interacts with the system. 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. The box labeled :System is an
object that represents the entire automated system. In SSDs and all other inter-
action diagrams, analysts use object notation instead of class notation. In object
notation, a box refers to an individual object, not the class of all similar objects.
The notation is simply a rectangle with the name of the object underlined. The
colon before the underlined class name is a frequently used but optional part of
the object notation to indicate that the object is an unnamed object of the class.
In an SSD, the only object included is one representing the entire system: an
unnamed object of the System class.
Underneath the actor and :System are vertical dashed lines called lifelines.
lifeline, or object lifeline the vertical line A lifeline, or object lifeline, is simply the extension of that object—either actor
under an object on a sequence diagram to or object—during the use case. The arrows between the lifelines represent the
show the passage of time for the object messages that are sent by the actor. Each arrow has an origin and a destination.
The origin of the message is the actor or object that sends it, as indicated by the
lifeline at the arrow’s tail. Similarly, the destination actor or object of a message
is indicated by the lifeline that is touched by the arrowhead. The purpose of
lifelines is to indicate the sequence of the messages sent and received by the actor
and object. The sequence of messages is read from top to bottom in the diagram.
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 syntax of the message label has several options; the simplest forms are
shown in Figure 5-7. Remember that the arrows are used to represent a message
and input data. But what is meant by the term message here? In a sequence dia-
gram, a message is an action that is invoked on the destination object, much like
a command. Notice in Figure 5-7 that the input message is called inquireOnItem.
Figure 5-7 Sample system

sequence diagram (SSD) An object
The actor
interacting with (underlined)
the system representing the
automated system
:System
An input message
Clerk
inquireOnItem (catalogID, prodID, size) The object lifeline; shows

the“sequence” of messages,
top to bottom
item information item information:

description, price, quantity
A returned value
Optional note to explain
something in a diagram
The clerk is sending a request (a message) to the system to find an item. The
input data that is sent with the message is contained within the parentheses, and
in this case, it is data to identify the particular item. The syntax is simply the
name of the message followed by the input parameters in parentheses. This form
of syntax is attached to a solid line with arrow.
The returned value has a slightly different format and meaning. Notice that
the line with arrow is dashed. A dashed arrow indicates a response or an answer
(in programming, a return), and as shown in the figure, it immediately follows the
initiating message. The format of the label is also different. Because it is a response,
only the data that are sent on the response are noted. There is no message request-
ing a service—only the data being returned. In this case, a valid response might
be a list of all the information returned—for example, the description, price, and
quantity of an item. However, an abbreviated version is also satisfactory. In this
case, the information returned is named item information. Additional documen-
tation is required to show the details. In Figure 5-7, this additional information is
shown as a note. A note can be added to any UML diagram to add explanations.
The details of item information could also be documented in supporting narra-
tives or even simply referenced by the attributes in the Customer class.
Frequently, the same message is sent multiple times in a loop, as shown in
Figure 5-8. For example, when an actor enters items on an order, the message
Figure 5-8 Repeating message in

(a) detailed loop frame notation and
(b) alternate notation
Test condition for :System
repeatability
Clerk
Loop
[more items] Repeat everything
addItem (itemID, quantity) in the rectangle
description, price, extendedPrice
(a) Detailed notation
:System
Clerk
* [another item] description, price, extendedPrice

:= addItem (itemID, quantity)
(b) Alternate notation
to add an item to an order may be sent multiple times. Figure 5-8(a) illustrates
the notation to show this repeating operation. The message and its return are
loop frame notation on a sequence located inside a larger rectangle called a loop frame. In a smaller rectangle at
diagram showing repeating messages the top of the frame is the descriptive text to control the behavior of the mes-
sages within the larger rectangle. The condition loop for all items indicates
that the messages in the box repeat many times or are associated with many
instances.
Figure 5-8(b) shows an alternate notation. Here, the square brackets
true/false condition part of a message and text inside them are called a true/false condition for the messages.
between objects that is evaluated prior The asterisk (*) preceding the true/false condition indicates that the message
to transmission to determine whether the repeats as long as the true/false condition evaluates to true. Analysts use this
message can be sent
abbreviated notation for several reasons. First, a message and the returned
data can be shown in one step. Note that the return data is identified as a
return value on the left side of an assignment operator—the := sign. This alter-
native simply shows a value that is returned. Second, the true/false condition is
placed on the message itself. Note that in this example, the true/false condition
is used for the control of the loop. True/false conditions are also used to evalu-
ate any type of test that determines whether a message is sent. For example,
consider the true/false condition [credit card payment]. If it is true that the
thing being tested is a credit card payment, the message is sent to the system
to verify a credit card number. Finally, an asterisk is placed on the message
itself to indicate the message repeats. Thus, for simple repeating messages,
the alternate notation is shorter. However, if several messages are included
within the repeat or there are multiple messages—each with its own true/false
condition—the loop frame is more explicit and precise.
Here is the complete notation for a message:
[true/false condition] return-value := message-name (parameter-list)
Any part of the message can be omitted. In brief, the notation components
do the following:
■■ 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 are 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 addition frames to depict processing logic,
opt frame notation on a sequence diagram as shown in Figure 5-9. The opt frame in Figure 5-9(a) is used when a message
showing optional messages or a series of messages is optional or based on some true/false condition. The alt
alt frame notation on a sequence diagram frame is used with if-then-else logic, as shown in Figure 5-9(b). The alt frame in
showing if-then-else logic this figure indicates that if an item is taxable, then add sales tax; otherwise, add
a tax exemption code for a sales tax exemption.
■■ Developing a System Sequence Diagram (SSD)

An SSD is usually used in conjunction with the use case descriptions to help doc-
ument the details of a single use case or scenario within a use case. To develop
an SSD, it is useful to have a detailed description of the use case—either in the
Figure 5-9 Sequence diagram

notation for (a) opt frame and
(b) alt frame
:System
Customer
Opt
[accessory selected]
addAccessory (anAccessory)
accessary details
(a) Opt frame notation
:System
Sales clerk
Alt
[taxable item]
addSalesTax (locationCode)
sales tax details
[else]
addTaxExemptionCode (eCode)
tax exemption details
(b) Alt frame notation
fully developed form or as an activity diagram. These two models identify the
flow of activities within a use case, but they don’t explicitly identify the inputs
and outputs. An SSD will provide this explicit identification of inputs and out-
puts. One advantage of using activity diagrams is that it is easy to identify when
an input or output occurs. Inputs and outputs occur whenever an arrow in an
activity diagram goes from an external actor to the computer system.
Recall the activity diagram for Create customer account shown in
Figure 5-4. There are two swimlanes: the customer and the computer system. In
this instance, the system boundary coincides with the vertical line between the
customer swimlane and the system swimlane.
The development of an SSD based on an activity diagram falls into four steps:
1. Identify the input messages. In Figure 5-4, there are three locations with a
workflow arrow crossing the boundary line between the customer and the
system. At each location that the workflow crosses the automation bound-
ary, input data are required; therefore, a message is needed.
2. Describe the message from the external actor to the system by using the
message notation described earlier. In most cases, you will need a
message name that describes the service requested from the system and
the input parameters being passed. Figure 5-10—the SSD for the Create
customer account use case—illustrates the three messages based on
the activity diagram. Notice that the names of the messages reflect the
services that the actor is requesting of the system: createNewCustomer,
enterAddress, and enterCreditCard. Other names could also have
been used. For example, instead of enterAddress, the name could be
createAddress. The point to remember is that the message name
should describe the service requested from the system and should be
in verb-noun form.
The other information required is the parameter list for each message.
Determining exactly which data items must be passed in is more difficult.
In fact, developers frequently find that determining the data parameters
requires several iterations before a correct, complete list is obtained. The
important principle for identifying data parameters is to base it on the class
diagram. In other words, the appropriate attributes from the classes are
listed as parameters. Looking at the attributes, along with an understand-
ing of what the system needs to do, will help you find the right attributes.
With the first message just mentioned—createNewCustomer—the param-
eters should include basic information about the customer, such as name,
phone, and e-mail address. Note that when the system creates the cus-
tomer, it assigns a new customerId and returns it with the other customer
information.
In the second message—enterAddress—parameters are needed to
identify the full address. Usually, that would include street address, city,
state, and zip code. The SSD simplifies the message to show “address” as
the parameter.
The third message—based on the activity diagram—enters the credit
card information. The parameter—cc-info—represents the account number,
expiration date, and security code.
3. Identify and add any special conditions on the input messages, including
iteration and true/false conditions. In this instance, the enterAddress
message is repeated for each address needed for the customer. The asterisk
symbol in front of the message is shown.
4. Identify and add the output return messages. Remember that there are two
options for showing return information: as a return value on the message
itself or as a separate return message with a dashed arrow. The activity
diagram can provide some clues about return messages, but there is no
standard rule that when a transition arrow in the workflow goes from the
system to an external actor that an output always occurs. In Figure 5-4,
there are three arrows from the System swimlane to the Customer swim-
lane. In Figure 5-10, these are shown as return data on the dashed line for
two returns and as a returned value on the same line as the message for
enterAddress. Note that they are each named with a noun that indicates
what is being returned. Sometimes, no output data are returned.
Remember that the objective is discovery and understanding, so you should
be working closely with users to define exactly how the workflow proceeds and
Figure 5-10 SSD for the Create

customer account use case
:System
Customer
createNewCustomer (name, phones, emails)
cust ID, name, phones, emails
*address details := enterAddress (address)
enterCreditCard (cc-info)
credit card info details
exactly what information needs to be passed in and provided as output. This is

an iterative process, and you will probably need to refine these diagrams several
times before they accurately reflect the needs of the users.
Let us develop an SSD for the Ship items use case that is shown as a fully devel-
oped use case description in Figure 5-3 and as an activity diagram in Figure 5-5.
Note that the actor has five numbered steps in the flow of activities, so there will
be five input messages in the SSD shown in Figure 5-11: getNextSale, setShip-
per, recordShippedItem, initiateBackorder, and getShippingLabel. No parameter is
needed for getNextSale because the system will automatically return the informa-
tion for the next sale to be shipped. The shipper is selected by the actor—probably
from a list on the form or page—so the parameter is shipperID.
There is a loop frame that repeats for each sale item in the sale. Inside the
loop frame is an alt frame that tests the whether each sale item is available to
ship. If the item can be shipped, the recordShippedItem message is sent to the
system. If the item cannot be shipped because it is out of stock or perhaps dam-
aged, the initiateBackorder message is sent to the system. Finally, the getShip-
pingLabel message requires two parameters: the size of the package and the
weight. The system uses that information, along with the shipper and address,
to produce the shipping label and record the cost.
These first sections of this chapter have explained the models that are used
in object-oriented development to specify the processing aspects of the new
system. The use case descriptions, as provided by written narratives or activity
diagrams, give the details of the internal steps within each use case. Precondi-
tion and postcondition statements help define the context for the use case—that
is, what must exist before and after processing. Finally, the SSD describes the
inputs and outputs that occur within a use case. Together, these models provide a
comprehensive description of the system-processing requirements and give the
foundation for systems design.
Figure 5-11 SSD for the Ship

items use case
:System
Shipping clerk
getNextSale()
customer, address, sale, and sale item info
setShipper(shipperID)
Loop
[more sale items]
Alt
[shipped item]
recordShippedItem(saleItem)
shipping confirmation
[else]
initiateBackorder(saleItem)
backorder confirmation
getShippingLabel(packageSize, weight)
shipping label details
■■ Use Cases and CRUD

CRUD technique an acronym for Create, Another important technique used to validate use cases is the CRUD technique,
Read/Report, Update, and Delete; a technique which involves verifying that all of the needed use cases have been identified to
to validate or refine use cases
maintain the data represented by the domain model class diagram. CRUD is an
acronym for Create, Read or Report, Update, and Delete, and it is often introduced
with respect to database management. The analyst starts by looking at the types
of data stored by the system, which are modeled as domain classes, as described
in Chapter 4. In the RMO Tradeshow System discussed in Chapter 1, the types of
data included Supplier, Contact, Product, and ProductPicture. In the RMO CSMS,
the types of data include Customer, Sale, Inventory Item, Promotion, Shipment,
and many others. To validate and refine use cases, the analyst looks at each type
of data and verifies that use cases have been identified that create the data, read or
report on the data, update the data, and delete (or archive) the data.
The CRUD technique is most useful when used as a cross-check along with
the user goal technique. Users will focus on their primary goals, and use cases
that update or archive data will often be overlooked. The CRUD technique
makes sure all possibilities are identified. Sometimes, domain classes are shared
by a set of integrated applications. For example, RMO has a supply chain man-
agement application that is responsible for managing inventory levels and add-
ing products. The RMO CSMS will not need to create or delete products, but it
will need to look up and update product information. It is important to identify

Konsep SQ 1

Uploaded by

Copyright:

Available Formats

You might also like

Konsep SQ 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Konsep SQ 1

Uploaded by

Copyright:

Available Formats

CHAPTER 5 ■ Use Case Modeling 139

Figure 5-6 Activity diagram for

Search for product

Search and view Add to cart

Figure 5-7 Sample system

inquireOnItem (catalogID, prodID, size) The object lifeline; shows

item information item information:

Figure 5-8 Repeating message in

description, price, extendedPrice

(a) Detailed notation

* [another item] description, price, extendedPrice

(b) Alternate notation

■■ An asterisk (*) indicates repeating or looping of the message.

■■ Developing a System Sequence Diagram (SSD)

Figure 5-9 Sequence diagram

(a) Opt frame notation

sales tax details

tax exemption details

Figure 5-10 SSD for the Create

createNewCustomer (name, phones, emails)

cust ID, name, phones, emails

*address details := enterAddress (address)

exactly what information needs to be passed in and provided as output. This is

Figure 5-11 SSD for the Ship

customer, address, sale, and sale item info

shipping label details

■■ Use Cases and CRUD

You might also like