9/18/01 1

Software Requirements Analysis and Design (Continued)

9/18/01 2

Use Case - Buy Item Version 1

Use Case Buy Items - version 1Actors Customer, CashierPurpose Capture a sale and its cash paymentOverview

A customer arrives at a checkout with items topurchase. The cashier records the purchase items and collectsa cash payment. On completion the customer leaves with the items.

Type Primary

Typical course of Events (please refer to Larman)

9/18/01 3

System Behavior

Objective– identify system events and system operations

– create system sequence diagrams for use cases

9/18/01 4

System sequence diagram-Example

:Cashier

:System

makeNewsale()

endSale()

Description, total

[* more items]

enterItem(itemID, quantity)

total with taxes

makePayment(amount)

change due, receipt

Box to enclosean iteration area.

9/18/01 5

System sequence diagram [1]

A system sequence diagram illustrates events from actors to systems and the external response of the system.

This activity occurs during the analysis phase of a development cycle; dependent on the creation of the use cases and identification of concepts.

UML notation - Sequence Diagram not System Sequence Diagram. One diagram depicts one scenario. This is the main success scenario. Frequent or complex alternate scenarios could also be illustrated. A system is treated as a black box. SSD is often accompanied by a textual description of the scenario to

the left of the diagram.

9/18/01 6

System sequence diagram [2]

Identify the system boundary…what is inside and what is outside.

System event: An external event that directly stimulates the (software) system.

Events are initiated by actors. Name an event at the level of intent and not using their

physical input medium or interface widgets.– enterItem() is better than scan().

Keep the system response at an abstract level.– description, total is preferred over display description and total

on the POS screen.

9/18/01 7

Conceptual (or Domain) model [1]

Illustrates meaningful concepts in the problem domain. Usually expressed in the form of static diagrams (in

Rational this implies a high-level class diagram). Is a representation of real-world things; not software

components (of the system under development). No operations are defined or specified in the conceptual

model. Should show concepts, associations between concepts, and

attributes of concepts. Serves as a source of software objects.

9/18/01 8

Conceptual model [2]

Objectives– identify concepts related to current development cycle

requirements

– create initial conceptual model

– Identify attributed

– add specification concepts

9/18/01 9

Partial domain model of POS

Concept

10..1

1..*

Records-sale-of

Contained-in

Saledatetime

11

Attributes

Sales LineItem

quantityItem

Storeaddressname

1

Stocked-in

Register

Houses1

1..*

Captured-on

1

1

9/18/01 10

Finding concepts [1]

Finding concepts using Noun Phrase identification in the textual description of the domain .

Finding concepts using the concept category list (refer to page p134 in Larman):– Physical objects: register, airplane, blood pressure monitor

– Places: airport, hospital

– Catalogs: Product Catalog

9/18/01 11

Finding concepts [2]

Examine use case descriptions. Example: Process Sale use case:

– Main success scenario:• Customer arrives at a POS checkout counter.

• Cashier starts a new sale.

• Cashier enters an item ID.

• System records sale line item. It then presents a description of the item, its price, and a running total.

• ….

• ….

Possible source of confusion: Is it an attribute or a concept?• If X is not a number or a text then it probably is a conceptual class.

9/18/01 12

Finding concepts [3]

•Concepts from “Unreal” world ?•Message•Connection•Port

•Use terms familiar to those in the problem domain.POST or register?

•Are these concepts or attributes:•Store•Flight•Price

9/18/01 13

Concepts in POS domain

POST Item Sale Store Payment SalesLineItem ProductCatalog

9/18/01 14

Specification Concepts

When are they needed?– Add a specification concept when:

• deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained

• it reduces redundant or duplicated information

9/18/01 15

Specification Example

Assume the following– an item instance represents a physical item in the store; as such it

has a serial number

– an item has a description, price and UPC which are not recorded anywhere else

– every time a real physical item is sold, a corresponding software instance of item is deleted from the database

With these assumptions, what happens when the store sells out of a specific item like “burgers”? How does one find out how much does the “burger” cost?

Notice that the price is stored with the inventoried instances

9/18/01 16

Specification Example – Contd.

Also notice the data is duplicated many times with each instance of the item

This example illustrates the need for a concept of objects that are specifications or descriptions of other things (often called a Proxy or Surrogate)

Description or specification objects are strongly related to the things they describe.

9/18/01 17

Specification - Example

ProductDesciption

descriptionpriceUPC

Item

Serial Number*1

describes

*1

Item

Serial NumberdescriptionPriceitemID

Which of these two is a better choice of concepts?

9/18/01 18

Conceptual Models - Association

Objective– Identify associations for a conceptual model

– distinguish between need-to-know associations from comprehension-only associations

9/18/01 19

Associations

Association - a relationship between concepts that indicates some meaningful and interesting connection

POST Sale

11

Records-current

11

Association

9/18/01 20

Finding Associations

High priority associations– A is a physical or logical part of B

– A is physically or logically contained in/on B

– A is recorded in B

Other associations– A uses or manages or controls B (Pilot -airplane)

– A owns B (Airline -airplane)

9/18/01 21

Association Guidelines

Focus on those associations for which knowledge of the relationship needs to be preserved for some duration (need-to-know associations)

more important to identify concepts than associations too many associations tend to confuse the conceptual

model avoid showing redundant or derivable associations

9/18/01 22

Roles in Associations

Each of the two ends of an association is called a role. Roles have– name

– multiplicity expression

– navigability

9/18/01 23

Multiplicity

Multiplicity defines how many instances of type A can be associated with one instance of type B at a particular moment in time

POST Sale

11

Records-current

11

Multiplicity of the role

9/18/01 24

Association - Multiplicity

Multiplicity: indicates the number of objects of one class the may be related to a single object of an associated class

can be one of the following types– 1 to 1, 1 to 0..*, 1 to 1..*, 1 to n, 1 to 1..n

9/18/01 25

Associations - Contd.

Sale paym ent

11

Paid-by

11

Store

POST

11 11

Records-current1..*

1

Contains

1..*

1

Associations are generally read left to right, top to bottom

9/18/01 26

Associations - Contd.

Flight Airport0..1

*

0..1*flies-to

0..1*

flies-from0..1

*

Multiple associations between two types

During analysis phase, an association is not a statementabout data flows, instance variables, or object connectionsin the software solution.

9/18/01 27

Conceptual Model - Attributes

Objectives– identify attributes in a conceptual model

– distinguish between correct and incorrect attributes

9/18/01 28

Attributes

Attribute - is a logical data value of an object Include the following attributes in a conceptual model

– those for which the requirements suggest or imply a need to remember information

For example, a sale receipt normally includes a date and time attribute

9/18/01 29

Attributes

Attribute: Named property of a class describing values held by each object of the class

Attribute Type: A specification of the external behavior and/or the implementation of the attribute

Attribute Name:attribute Type

9/18/01 30

Attributes

Attributes in a conceptual model should preferably be simple attributes or pure data values

Common simple attribute types include– boolean, date, number, string, time

9/18/01 31

Attributes

worse

better

Relate with associations, not attributes, in conceptualmodel

Cashier

namecurrentPost

not a "simple"

Cashier

name

POST

number11

uses

1

9/18/01 32

Complex Attributes

Pure data values - expressed as attributes; they do not illustrate specific behaviors;– Example - Phone number

– A Person can have many Phone numbers

Non-primitive attribute types– represent attributes as non-primitive types (concepts or objects) if

• it is composed of separate sections (name of a person)

• there are operations associated with it such as validation

• it is a quantity with a unit (payment has a unit of currency)

9/18/01 33

Complex Attributes

It is desirable to show non-primitive attributes as concepts in a conceptual model

Product specification UPC

11*

9/18/01 34

Recording terms in Glossary

Define all terms that need clarification in a glossary or model dictionary.

9/18/01 35

System Sequence diagram [1]

Use cases suggest how actors interact with the software system

an actor generates events to a system, requesting some operation in response

Example - when a cashier enters an item’s UPC, the cashier requests the POST system to record that item purchase. That request event initiates an operation upon the system

desirable to isolate and illustrate the operations that an actor requests of a system

9/18/01 36

System Sequence Diagram [2]

Shows for a particular scenario of a use case, the events that external actors generate, their order and inter-system events

A scenario of a use case is a particular instance or realized path

should be done for a typical course of events of the use case (usually for the most interesting ones)

9/18/01 37

System Events, Operations

System event - external input event generated by an actor system operation - operation of the system that executes

in response

9/18/01 38

Recording System operations

Set of all required systems operations is determined by identifying the system events

Examples: enterItem(UPC,quantity); endSale(); makePayment(amount)

UML notation -

Operation(arg:ArgType=defaultvalue,,,):ReturnType(s)

9/18/01 39

Contracts

A contract describes detailed system behavior in terms of state changes to objects in the domain model.

A contract is a system operation. It is offered in the system’s public interface.

Note that one use case may require one or more system operations (events) to complete a scenario.

9/18/01 40

Contract: Example

Operation: enterItem(itemID: ItemID, quantity: integer)

Cross References: Use case: Process sale

Preconditions: There is a sale underway.

Postconditions:• A salesLineItem instance, sli, was created.

• sli was associated with the current Sale.

• sli.qty becomes quantity (attribute modification).

• sli was associated with ProductSpecification based on itemID match.

9/18/01 41

Artifacts of Analysis

Analysis Artifact Questions Answered

Use Cases What are the domain processes?

Conceptual model

What are the concepts and terms?

Interaction diagrams

What are system events and operations?

Contracts What are the semantics of system operations?