6/8/99 1

Analysis

Tuesday 09/14/99

Revised: September 11, 2000 (APM)

6/8/99 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 theitems.Type: Primary

Typical course of Events (please refer to page 79 T1)

6/8/99 3

Building a conceptual model

Objectives– identify concepts related to current development cycle

requirements

– create initial conceptual model

– distinguish between correct and incorrect attributes

– add specification concepts

6/8/99 4

Conceptual model

Illustrates meaningful concepts in a problem domain the most important artifact to create during OO analysis 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 no operations are defined in conceptual model should show concepts, associations between

concepts,attributes of concepts

6/8/99 5

Partial conceptual model

Concept

ItemSales LineItem

10..1

Saledatetim e

1

1..*

Records-sale-of

10..1

Contained-in

1

1..*

Attributes

No responsibilities or methods

6/8/99 6

Concepts - definition

Concept - an idea, thing or object Primary distinction of object oriented analysis - division by

concepts rather than division by functions

6/8/99 7

Concepts in POS domain

Store, POST, Sale better to over specify the conceptual model than to under

specify it is common to miss some in the initial phase; discover

them later finding concepts using the concept category list (refer to

page 91, UML) finding concepts using Noun Phrase identification -

example in Buy Items version 1 - sales transaction

6/8/99 8

Candidate concepts POS domain

POST Item Sale Store Payment SalesLineItem ProductCatalog

6/8/99 9

Report Objects - Include?

Receipt - record of a sale and payment; important concept in the problem domain

Should it be included in the model? Some factors to consider:

– receipt is a record of a sale - generally not useful, since all its information is derived from other sources

– receipt has a special role in terms of the business - the buyer is entitled to a receipt of the sale

– So how do we make a decision?

6/8/99 10

POS Conceptual Model

Item

Sales LineItem SalePOST

Store Paym ent

6/8/99 11

Conceptual Modeling Guidelines

List the candidate concepts using the concept category list add associations necessary to record the relationships for

which there is a need to preserve some memory add the attributes necessary Use the mapmaker strategy (leave irrelevant features,

name using the business terms, UML page 96) if a thing X cannot be thought of either number or text,

then X is probably a concept (example, destination airport) if in doubt, make it a concept (hmm)

6/8/99 12

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

6/8/99 13

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

6/8/99 14

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.

6/8/99 15

Specification - Example

ProductDesciption

descriptionpriceUPC

Item

Serial Number*1

describes

*1

6/8/99 16

UML definitions

Class - a description of a set of objects that share the same attributes, operations, methods, relationships and semantics

operation - a service that can requested from an object to effect behavior

6/8/99 17

Conceptual Models - Association

Objective– Identify associations for a conceptual model

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

6/8/99 18

Associations

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

POST Sale

11

Records-current

11

Association

6/8/99 19

Finding Associations

Refer to page 108 (larman) 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

Finding concepts is much more important than finding associations. The majority of time spent in conceptual model creation should be devoted to identifying concepts, not associations

6/8/99 20

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

6/8/99 21

Roles in Associations

Each end of an association is called a role. Roles have– name

– multiplicity expression

– navigability

6/8/99 22

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

6/8/99 23

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

6/8/99 24

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

6/8/99 25

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

6/8/99 26

Point of Sale Association

Refer to pages 113 - 117

6/8/99 27

Conceptual Model - Attributes

Objectives– identify attributes in a conceptual model

– distinguish between correct and incorrect attributes

6/8/99 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

6/8/99 29

Attributes

Attribute: Named property of a class describing values held by each object of the classAttribute Type: A specification of the external behavior and/or the implementation of the attribute

Attribute Name:attribute Type

6/8/99 30

Attributes

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

Very common simple attribute types include– boolean, date, number, string, time

6/8/99 31

Attributes

Cashier

namecurrentPost

not a "simple"

worse

Cashier

name

POST

number11

uses

11

better

Relate with associations, not attributes, in conceptualmodel

6/8/99 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)

6/8/99 33

Complex Attributes

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

Product specification UPC

1* 1*

6/8/99 34

Attributes for the POS system

Refer to page 126 - 129 T1

6/8/99 35

Recording terms in Glossary

Define all terms that need clarification in a glossary or model dictionary (refer to T2 glossary, T1 page 131)

6/8/99 36

System Behavior

Objective– identify system events and system operations

– create system sequence diagrams for use cases

6/8/99 37

System sequence diagram

A system sequence diagram illustrates events from actors to systems

UML notation - sequence diagram This activity occurs during the analysis phase of a

development cycle; dependent on the creation of the use cases and identification of concepts

6/8/99 38

Sequence diagram

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

6/8/99 39

Sequence Diagram

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)

6/8/99 40

Sequence Diagram - POS

Refer to page 138 T1 for an example of a system sequence diagram.

Note that the System Sequence Diagram is different from the Collaboration Diagrams that are described later with design.

6/8/99 41

System Events, Operations

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

in response

6/8/99 42

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)

6/8/99 43

System behavior - Contracts

Objective– create contracts for system operations

6/8/99 44

System behavior - contracts

Help define system behavior describe the effect of operation(s) on the system UML notation - pre and post conditions of operations contracts are useful documentation of the system behavior

in terms of what a system’s state changes are when a system operation is invoked

6/8/99 45

Contracts - Example

Refer to page 148