Chapter 5

alt frame

notation on a sequence diagram showing if-then-else logic

opt frame

notation on a sequence diagram showing optional messages

What are two ways to show repetition on a sequence diagram?

- An iteration expression may be used at the top-inside or bottom-inside of the rectangle to indicate the number of times the communications inside the rectangle occur. - Alternatively, a guard expression may be used at the top-inside or bottom-inside of the rectangle to indicate the condition that must be satisfied in order to terminate the repetition.

What are the steps required to develop an SSD?

- Identify the input message - Describe the message from the external actor to the system by using the message notation described earlier - Identify and add any special conditions on the input messages, including iteration and true/false conditions. - Identify and add the output return messages.

What are the two ways to show a returned value on a sequence diagram?

- On message itself: aValue: = get value (value ID) - As explicit return on separate dashed line.

What are the three types of frames used on a sequence diagram?

- Opt frame: notation on a sequence diagram showing optional messages - Alt frame: notation on a sequence diagram showing if-then-else logic. - Loop frame: notation on a sequence diagram showing repeating messages.

Compare/contrast business process and flow of activities for a use case. Explain how an activity diagram can be used to model both.

A business process is larger than a use case. A business process might include various manual business procedures both before and after the "business event" that causes the use case to occur. However, an activity diagram is a powerful model to describe all types of sequences of tasks and activities. The various swimlanes can represent various users or user groups as well as system activities

lifeline or object lifeline

A lifeline, or object lifeline, is simply the extension of that object—either actor or object—during the use case. The arrows between the lifelines represent the 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.

Compare/contrast postcondition and exception condition.

A post condition, as explained about describes states of the data and the system. An exception condition describes some non-normal situation in the processing, i.e. in the flow of activities, that must be handled in some way

Compare/contrast precondition and postcondition.

A precondition describes the "states" of data and the system that must exist before the use case can begin. For example to add an item to a shopping cart, the item must exist in the database. A postcondition describes the states of data and the system that must exist after the use case completes. For example after Create a customer account use case, a customer account object (record) must exist

system sequence diagram (SSD)

A system sequence diagram (SSD) is used to describe this flow of information into and out of the automated portion of the system. Thus, an SSD documents the inputs and the outputs and identifies the interaction between 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.

Explain the difference between a use case and a scenario. Give a specific example of a use case with a few possible scenarios.

A use case is the entire function or user goal or event. A scenario is one specific version or instance of that use case. From RMO we have Create customer account as a use case. But we might have Create online Customer account and Create instore customer account and even Create phone customer account as different scenarios

What is the purpose of an SSD? What symbols are used in an SSD?

An SSD (system sequence diagram) is used to describe the messages that flow into and out of a system, i.e. between the system and the use case user. The symbols include: Stick figure for the actor Box with object name for the system object Vertical dashed lines for object lifelines Horizontal arrows for messages Horizontal dashed arrows for return data Comment box for comment

CRUD technique

An acronym for Create, Read/Report, Update, and Delete; a technique to validate or refine use cases

CRUD technique

Another important technique used to validate use cases is the CRUD technique, which involves verifying that all of the needed use cases have been identified to 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 the other application that is responsible for creating, updating, or deleting the data to be clear about the scope of each system.

What is the symbol for a true/false condition on a sequence diagram?

Brackets [ ] indicate a true/false condition.

Brief Description

Depending on an analyst's needs, use case descriptions tend to be written at two separate levels of detail: brief description and fully developed description. Some brief use case descriptions were shown in Chapter 3 (repeated again as Figure 5-1). A brief description gives enough detail for very simple use cases, especially when the system to be developed is a small, well-understood applica- tion. Examples of simple use cases are Add product comment or Send message. A use case such as Fill shopping cart is complex enough that a fully developed description is also written after the initial brief use case description is finalize

scenarios or use case instances

Figure 5-2 also serves as a standard template for documenting a fully developed description for other use cases. The first and second compartments are used to identify the use case and the specific scenario within the use case (if needed) that is being documented. Frequently, several variations of the busi- ness steps exist within a single use case. These different flows of activities are called scenarios or sometimes use case instances. The use case Create cus- tomer account will have a separate flow of activities depending on which actor invokes the use case. The processes for a customer service representative updat- ing information over the phone might be quite different from the processes for a customer updating the information him or herself. Figure 5-2 shows an online customer creating a customer account, so the scenario indicated is Create online customer account. Another use case description would be written for the Create customer account by phone scenario. Each flow of activities is a valid sequence for the Create customer account use case. Thus, a scenario is a unique set of inter- nal activities within a use case and represents a unique path through the use case. In larger or more formal projects, a unique identifier can also be added for the use case, with an extension identifying the particular scenario. Sometimes, the name of the system developer who produced the form is added. The third compartment identifies the event that triggers the use case. The fourth compartment is a brief description of the use case. Analysts may just duplicate the brief description they constructed earlier here. The fifth compart- ment identifies the actor or actors. Implied in all use cases is a person who uses the system called an actor. Actors are shown as stick figures on use case dia- grams. An actor is always outside the automation boundary of the system but may be part of the manual portion of the system. By defining actors that way— as those who interact with the automated part of the system—you can more pre- cisely define the exact interactions to which the automated system must respond. The sixth compartment identifies other use cases and the way they are related to this use case. These cross-references to other use cases help document all aspects of the users' requirements. The seventh compartment identifies stakeholders who are interested parties other than specific actors. They might be users who don't actually invoke the use case but who have an interest in results produced from the use case. For example, in Figure 5-2, the Accounting Department is interested in accurately capturing billing and credit card information. Although no one in the Market- ing Department actually creates new customer accounts, they do perform sta- tistical analysis of the new customers and create marketing promotions. Thus, marketers have an interest in the data that are captured and stored from the Create customer account use case. The Sales Department is interested in having an easy-to-use and attractive user interface to ensure sales aren't lost because of poor user experience. Considering all the stakeholders is important for system developers so they ensure they have understood all requirements.

What is the name of the sequence diagram symbol used to represent the object's existence throughout the duration of a use case?

Lifeline

Explain what parameters of a message are.

Shows the data that is passed with the message.

postcondition

Postconditions identify what must be true upon completion of the use case.

Postconditions

Postconditions identify what must be true upon completion of the use case. Most important, they indicate what new objects are created or updated by the use case and how objects need to be associated. The postconditions are important for two reasons. First, they form the basis for stating the expected results for test cases that will be used for testing the use case after it is imple- mented.

preconditions

Preconditions identify what the state of the system must be for the use case to begin, including what objects must already exist, what infor- mation must be available, and even the condition of the actor prior to beginning the use case.

What is the purpose of using the CRUD technique?

The CRUD technique is used to validate that all of the use cases have been identified that are neces- sary to maintain the data represented by the domain model class diagram. Use cases must be identified that create, read or report, update, and delete or archive in- stances of all classes. Alternatively, other systems that maintain the data must be identified when integrated systems share the same database. All the models dis- cussed in this chapter are interrelated, and informa- tion in one model explains information in others.

Fully Developed Use Case Descriptions

The fully developed description is the most formal method for documenting a use case. One of the major difficulties for software developers is that they often struggle to obtain a deep understanding of the users' needs. But if you create a fully developed use case description, you increase the probability that you thor- oughly understand the business processes and the ways the system must support them. To create a comprehensive, robust system that truly meets users' needs, you must understand the detailed steps of each use case. Internally, a use case includes a whole sequence of steps to complete a business process. Figure 5-2 is an example of a fully developed use case description of the use case Create customer account.

Loop frame

The message and its return are located inside a larger rectangle called a loop frame.

loop frame

The message and its return are located inside a larger rectangle called a loop frame.

true/false condition

The square brackets and text inside them are called a true/false condition for the messages. The asterisk (*) preceding the true/false condition indicates that the message repeats as long as the true/false condition evaluates to true. Part of a message between objects that is evaluated prior to transmission to determine whether the message can be sent

What are the models that describe use cases in more detail?

Use case descriptions - a textual model that lists and describe the processing details for a use case.

List the parts or compartments of a fully developed use case description.

Use case name Scenario Triggering event Brief description Actors Related use cases Stakeholders Preconditions Postconditions Flow of activities Exception conditions

system sequence diagram (SSD)

a diagram showing the sequence of messages between an actor and the automated part of the system during a use case or scenario

use case description

a textual model that lists and describes the processing details for a use case

scenarios or use case instance

a unique set of internal activities within a use case

precondition

conditions that must be true before a use case begins

true/false condition

part of a message between objects that is evaluated prior to transmission to determine whether the message can be sent

lifeline, or object lifeline

the vertical line under an object on a sequence diagram to show the passage of time for the object