Lecture10

58
ECE 452- Introduction to Software Engineering Lecture 10: Object-Oriented Analysis (System Sequence Diagrams, Conceptual Model) Manish Parashar [email protected] Department of Electrical & Computer Engineering Rutgers University

description

uml for library managment system

Transcript of Lecture10

Page 1: Lecture10

ECE 452- Introduction to Software Engineering

Lecture 10: Object-Oriented Analysis (System Sequence Diagrams,

Conceptual Model)

Manish [email protected] of Electrical &

Computer EngineeringRutgers University

Page 2: Lecture10

ECE 452 - Introduction to Software Engineering

The Unified Analysis Process & UML♦ Use Case - What are the domain processes ?

− Use Case Diagram ♦ high-level/expanded, essential/real

♦ Conceptual Model - What are the domain concepts, terms ?− Class Diagram (conceptual)

♦ classes, associations, attributes♦ System Sequence Diagram - What are the system events

and operations ?− Interaction Diagram - Sequence Diagram

♦ Contracts - What do the system operations do ?− Contract Specs.

Page 3: Lecture10

ECE 452 - Introduction to Software Engineering

Glossary

SoftwareArchitecture Doc.

DomainModel

Requirements

ProjectManagement

BusinessModeling

Design

Sample UP Artifacts Partial artifacts,refined in each

iteration.

Test

TestPlan

SoftwareDev. Plan

. . .

Use-Case Model

textuse

cases

:System

foo( x )

systemoperationcontracts

systemsequencediagrams

systemevents &data

systemoperations

design objectsto handle thesystem events

parameter orreturn data may beelaborated in theGlossary

Design Model

bar( y )

Environment

DevelopmentCase

Page 4: Lecture10

ECE 452 - Introduction to Software Engineering

From Analysis to Design

♦ Use Cases− What are the domain processes ?

♦ Conceptual Model− What are the concepts, terms ?

♦ System sequence diagrams− What are the system events and operations ?

♦ Contracts− What do the system operations do ?

Page 5: Lecture10

ECE 452 - Introduction to Software Engineering

System Sequence Diagrams

♦ Determine system events and operations♦ Derived from Use Cases – Typical course of

events♦ Identify system functionality (operations) to

be designed♦ System boundary is critical

Page 6: Lecture10

ECE 452 - Introduction to Software Engineering

System Sequence Diagrams

♦ Illustrate events from actors to systems♦ System sequence diagrams describe scenarios

− a scenario is an instance of a use case Ivar Jacobson

− a real example of the enactment of a use case− e.g. Process Sale

♦ Some UML notation for a sequence diagram is shown on the next slide

Page 7: Lecture10

ECE 452 - Introduction to Software Engineering

System Sequence Diagrams

♦ Draw a line representing the system as a black box.

♦ Identify each actor that directly operates on the system. Draw a line for each such actor.

♦ From expanded use case identify system events that each actor generates. Ilustratethem.

♦ Optionally include use case text on left.

Page 8: Lecture10

ECE 452 - Introduction to Software Engineering

A System Sequence Diagramsystem as black box

enterItem(UPC, quantity)

:SystemCashier

endSale()

Repeat until nomore items

makePayment(amount)

Text which clarifiescontrol, logic, iteration,etc.

May be taken from theuse case.

ActorBuy Items-version 1

system event

it triggers a system operation

Page 9: Lecture10

ECE 452 - Introduction to Software Engineering

System events

♦ System Event− An external input event generated by an actor to a system− the system is seen as a black box

♦ System operation− the method invoked in response to a system event

♦ Use the same names for system event and system operation

♦ System events may have arguments♦ enterItem( UPC, quantity )♦ raise( money )

Page 10: Lecture10

ECE 452 - Introduction to Software Engineering

System Sequence Diagrams from Use Cases

: Cashier :System

Simple cash-only Process Sale scenario:

1. Customer arrives at a POS checkoutwith goods and/or services to purchase.2. Cashier starts a new sale.3. Cashier enters item identifier.4. System records sale line item andpresents item description, price, andrunning total.Cashier repeats steps 3-4 until indicatesdone.5. System presents total with taxescalculated.6. Cashier tells Customer the total, andasks for payment.7. Customer pays and System handlespayment....

enterItem(itemID,quantity)

endSale()

makePayment(amount)

description,total

total withtaxes

change due,receipt

* [more items]

makeNewSale()

Page 11: Lecture10

ECE 452 - Introduction to Software Engineering

Naming System Events and Operations

enterItem(itemID, quantity)

scan(itemID, quantity)

: Cashier

worse name

better name

:System

Page 12: Lecture10

ECE 452 - Introduction to Software Engineering

SSD with Use Case Text

: Cashier:System

Simple cash-only Process Sale scenario:

1. Customer arrives at a POS checkoutwith goods and/or services to purchase.2. Cashier starts a new sale.

3. Cashier enters item identifier.4. System records sale line item andpresents item description, price, andrunning total.

Cashier repeats steps 3-4 until indicatesdone.

5. System presents total with taxescalculated.

6. Cashier tells Customer the total, andasks for payment.7. Customer pays and System handlespayment....

enterItem(itemID,quantity)

endSale()

makePayment(amount)

description,total

total withtaxes

change due,receipt

* [more items]

makeNewSale()

Page 13: Lecture10

ECE 452 - Introduction to Software Engineering

System Behavior - Contracts

♦ Contracts help define system behavior♦ Contracts are defined in part by preconditions

and postconditions♦ Examples in this chapter document system

operations such as − enterItem− endSale− makePayment

♦ However, contracts also apply to low-level methods

Page 14: Lecture10

ECE 452 - Introduction to Software Engineering

The Conceptual Model- Introduction

♦ Conceptual Model− illustrates meaningful concepts− most important artifact in OO analysis− need use cases as input

♦ but can develop uses cases as you do conceptual model

♦ Question:− Provide names for the uses cases you found

♦ let's share this information now (use whiteboard)

Page 15: Lecture10

ECE 452 - Introduction to Software Engineering

Domain Analysis

♦ Object oriented analysis at the “business area level”

♦ Objective: Create a library of reusable components for a particular domain

♦ Ongoing activity of the software process (not tied to a specific project)

♦ Domain analysis model specifies objects and classes that characterize the domain

Page 16: Lecture10

ECE 452 - Introduction to Software Engineering

Domain Analysis

♦ Define domain to be investigated♦ Categorize the items extracted from the

domain♦ Collect a representative sample of applications

in the domain♦ Analyze each application in the sample♦ Develop an analysis model for the objects♦ Define reuse guidelines

Page 17: Lecture10

ECE 452 - Introduction to Software Engineering

Conceptual Models

♦ Conceptual Model− created for the use cases of the current cycle in the

language of the problem domain ♦ Must identify

− concepts - objects in our system− associations between concepts

♦ is part of, contains, manages, is-a, ...

− attributes of concepts ♦ instance variables needed to hold state

Page 18: Lecture10

ECE 452 - Introduction to Software Engineering

Conceptual Modeling...

♦ Conceptual models should not contain design information− software artifacts, methods, etc.

♦ Better to over specify then under specify♦ Concepts v/s attributes

− when in doubt make it a concept♦ Specification/Description concepts

Page 19: Lecture10

ECE 452 - Introduction to Software Engineering

Conceptual Modeling

♦ Associations− less important than identifying concepts− show only “need-to-know” association (avoid

redundant or derivable associations)− name, multiplicity, navigability− multiple associations

Page 20: Lecture10

ECE 452 - Introduction to Software Engineering

Conceptual Model

♦ Attributes− Attributes Vs. Concepts

♦ keep attributes simple♦ if in doubt define it as a concept♦ no attributes as foreign keys (use associations)

Page 21: Lecture10

ECE 452 - Introduction to Software Engineering

A Partial Conceptual Model

♦ See example for POST on page 88 also on next slide

− Figure 9.1 ♦ shows attributes name some instance variables now ________

♦ shows associations name a label now

♦ contains multiplicity• numbers at the ends of the association lines

– 1, 0..1, 1..4 (one to four players), * means many• direction reading arrow which could be left-to-right and top-

to-bottom by default (but this is not a standard rule)• Arrows help readability

♦ typically can read the multiplicity both ways

♦ More on associations and multiplicity later

Page 22: Lecture10

ECE 452 - Introduction to Software Engineering

POST

Item

Store

addressname

Sale

datetime

Payment

amount

SalesLineItem

quantity

1..*

1..*

Records-sale-of

1

1

1

Captured-on 4

Concept

10..1

*Stocked-in

Association Contained-in

1

Attributes

1Houses

We're shooting for something like this for your final project

Paid-by

1

1

Page 23: Lecture10

ECE 452 - Introduction to Software Engineering

Conceptual Model

♦ Concepts help with domain vocabulary♦ Conceptual models are not models of software

designs− don’t be thinking windows and files here− no responsibilities yet, do this in design

♦ Concept: an idea, thing, or object− symbol: a word or image representing a concept− definition− extension: set of examples to which the concept applies

Page 24: Lecture10

ECE 452 - Introduction to Software Engineering

Example Concept

♦ POST Sale − symbol: Sale− definition

represents the event of a purchase transaction, and has a date and time

− extension: the set of all sales

Sale

datetime

"A sale represents the eventof a purchase transaction. Ithas a date and time."

sale-1

sale-3sale-2

sale-4

concept's symbol

concept's definition

concept's extension

Page 25: Lecture10

ECE 452 - Introduction to Software Engineering

Example Concept

♦ POKER Card− symbol: Card− definition:

represents one card in a poker deck that has a rank (2..14), and a suit ♣♦♥♠

− extension: the set of all cards

CardDeck

A card represents one of theentities to make up a hand

Ace ♥

3 ♣ King ♦

5 ♠

ranksuit

in a poker game

concept's symbol

concept's definition

concept's extension

Page 26: Lecture10

ECE 452 - Introduction to Software Engineering

Conceptual model and partitioning

♦ Structured Analysis (still in use today)− Divide and Conquer

♦ at the function level

♦ Object-Oriented Analysis (still growing)− Partition

♦ at the level of concepts (objects)

Page 27: Lecture10

ECE 452 - Introduction to Software Engineering

Identifying Concepts

♦ One strategy for getting concepts− Look for the concepts in the problem specification

and in your uses cases♦ read the final project specification

− It is better to have too many at first than too few♦ specifying too many concepts is good♦ is is better too have too many than too few♦ concepts may have no attributes

♦ Try not to think of Java classes as you do this− later on, think of some classes to implement

Page 28: Lecture10

ECE 452 - Introduction to Software Engineering

Concept Category

♦ Physical or tangible things− POST A Point of Sale Terminal

♦ Specifications− POST ProductDescription

♦ Transactions− POST Sale, Payment

Page 29: Lecture10

ECE 452 - Introduction to Software Engineering

More Concept Categories

♦ Things in a container− POST Sales Line Item

♦ Abstract noun concepts− POST Waiting line rage

♦ Events− POST Sale

Page 30: Lecture10

ECE 452 - Introduction to Software Engineering

More Concept Categories

♦ Rules and Policies− POST RefundPolicy

♦ Organizations− POST SalesDepartment

For more, see pages 91-93

Page 31: Lecture10

ECE 452 - Introduction to Software Engineering

Concepts? page 96-97

♦ Use vocabulary of the users − Users are not usually present for college programming

projects− However, Poker has users

♦ the users are you this isn't a Library with Patrons and Librarians

♦ Do not include irrelevant things − no casino, no pit boss

♦ Do not include things that don't belong− no Lottery System, no Starship Enterprise, no pit bull

Page 32: Lecture10

ECE 452 - Introduction to Software Engineering

Finding Concepts

♦ Make a list of candidate concepts (objects)− look for noun phrases

♦ be careful to avoid ambiguities♦ see page 95 POST Item, Store, Sale, Payment, Customer

Page 33: Lecture10

ECE 452 - Introduction to Software Engineering

Common Mistake

♦ Do not mistake an attribute for a concept− Attributes are numbers, booleans, strings, date

♦ All others things are likely a concept− if in doubt, make it a concept

♦ Example: Payment in the POST problem could be thought of as the amount of a Sale− a primitive attribute like 9.75− But a payment could be made by check, cash, credit card,

could be in various currencies of the world, could require change

− This outgrows being a simple attribute

Page 34: Lecture10

ECE 452 - Introduction to Software Engineering

Resolving Similar Concepts

♦ Naming things correctly is − important− sometimes hard to agree:

similar concepts withdifferent names

POST Registeror?

Sale*

Records 61

Sale*

1

Records 6

Page 35: Lecture10

ECE 452 - Introduction to Software Engineering

Abstract Concepts

♦ Some concepts don't feel real and that is okay− Telecommunications

♦ Connection, Route, Protocol− Poker

♦ Strategy, View− Encoding images with some compression scheme or

encrypting messages for privacy♦ Compression, Encryption, Privacy

♦ Concepts in the problem domain exist even if they do not seem to be part of the real world

Page 36: Lecture10

ECE 452 - Introduction to Software Engineering

CheckApprovalRequest

CreditAuthorization

Service

CreditApprovalRequestPOST Concepts

CheckAuthorization

Service

CreditApproval

Reply

CheckApproval

ReplyAccounts

ReceivableDriversLicense

CashPayment

CreditPayment

CheckPayment

CreditCard Check

POST Item Store Sale ProductCatalog

SalesLineItem Cashier Customer Manager Product

Specification

Page 37: Lecture10

ECE 452 - Introduction to Software Engineering

Defining Terms in the UML

♦ The Software class diagram will look a lot like the conceptual model

♦ You will see associations, boxes, multiplicity...♦ Larman uses concept to refer to real world things and

unreal things

♦ Classes refer to software specifications and implementations. UML defines class as− a description of a set of a objects that share the same

attributes, relationships, and semantics the three Amigos: Grady Booch, Ivar Jacobsen, Jim Rumbaugh

Page 38: Lecture10

ECE 452 - Introduction to Software Engineering

Other UML terms

♦ Operation− a service that can be requested from an object to

affect behavior♦ Type

− either a class or an interface specification with no methods

♦ Interface − the set of externally visible operations

♦ Could mean a Java interface

Page 39: Lecture10

ECE 452 - Introduction to Software Engineering

Adding Associations

♦ Next step in the conceptual model− adding associations between two concepts − an association is

♦ a relationship between concepts that indicates some meaningful and interesting connection

− Name the association with a hyphen connected verb phrase which reads well between concepts

association

Records-currentPOST Sale

1 1

Page 40: Lecture10

ECE 452 - Introduction to Software Engineering

Associations

♦ Associations imply− our knowledge of the relationship must be

preserved for some time (1 ms to forever)♦ between what objects do we need to remember a

relationship?• POST: does a driver's license remember a product catalog?• Poker: does a game need to remember it's Player(s)?• Poker: does the winner need to know the card image

collection?

Page 41: Lecture10

ECE 452 - Introduction to Software Engineering

The UML Association Notation

♦ UML Association: − a line between two concepts and a name− they are bi-directional− can have a multiplicity− exist in conceptual

models and class diagrams

zero or more;"many"

one or more

one to forty

exactly five

T

T

T

T

*

1..*

1..40

5

T3, 5, 8 exactly three,

five or eight

Multiplicity adornments

Page 42: Lecture10

ECE 452 - Introduction to Software Engineering

Possible Associations

♦ A is a physical part of B Drawer - POST♦ A is a logical part of B SalesLineItem - Sale♦ A is physically contained in B POST-Store♦ A is logically contained in B ItemDescription-Catalog♦ A is recorded in B Sale - POST♦ A uses or manages B Cashier - POST♦ A communicates with B Customer - Cashier♦ A is related to a transaction B Customer - Payment

− Draw some poker associations now♦ Let's try to get one for each of the bullets above

Page 43: Lecture10

ECE 452 - Introduction to Software Engineering

Associations

♦ Some useful associations − A is a physical or logical part of B− A is physically or logically contained in/on B− A is recorded in B

Page 44: Lecture10

ECE 452 - Introduction to Software Engineering

Association Guidelines

♦ Concepts are more important than associations♦ Focus on need to know associations

− the relationship must be preserved for some time♦ Better to have too few associations than too

many

Page 45: Lecture10

ECE 452 - Introduction to Software Engineering

Multiplicity

♦ Multiplicity defines how many instances of type A can be associated with one instance of type B at some point can differ

Game Player1 1..6

Mother Child1 1+

Actor is associated with 0 to many films. A film is associated with 0 to many actors

performs-inActor Film**

can optionally name an association

Page 46: Lecture10

ECE 452 - Introduction to Software Engineering

Depends on Context

♦ Are all three associations possible?

Car Wheel1 4

Car Wheel51

Car Wheel1 3

Page 47: Lecture10

ECE 452 - Introduction to Software Engineering

Association Names Upcase / hyphenate

♦ Try reading this Type-VerbPhrase-Type

♦ Not yet worrying about messages, instance variables, data flow, or software objects

♦ Just show some concepts are connected

Store

Contains

SalePOST Captures1..*

1..*

PaymentPaid-by1

1

1 1

Page 48: Lecture10

ECE 452 - Introduction to Software Engineering

No Implementation Yet

♦ The associations may later become implemented in software in terms of visibility− Related as an instance variable of a class− Related as an argument in a message− Related through an inheritance relationship

♦ Some associations will not be implemented− Others will be discovered during coding

♦ Conceptual Model should have associations suggested by requirements and use cases

Page 49: Lecture10

ECE 452 - Introduction to Software Engineering

Any unforgettable Relationships?

♦ POST − Post Captures Sale− Sale Paid-By Payment− ProductCatalog Records Specification

Page 50: Lecture10

ECE 452 - Introduction to Software Engineering

Conceptual Model for the POST associations are not all need to know

POST

ItemStore

Sale

Payment

SalesLineItem

CashierCustomer

Manager

ProductCatalog

ProductSpecification

Stocks

*

Houses1.. *

Used-by

*

Contains1.. *

Describes

*

1.. *

Described-by

*

Records-sale-of

0..1

Paid-by Initiated-by

Logs-completed

6

*

3 Records-sales-on

1

1

1

1

1

1

11

1

1

1

1

1

1

1

Initiated-by

1

1

Contained-in1

Captured-on Started-by1 1

see pages 116-117

Page 51: Lecture10

ECE 452 - Introduction to Software Engineering

Not need to know No need yet to have POST Started-By Manager

POST

ItemStore

Sale

Payment

SalesLineItem

CashierCustomer

ProductCatalog

ProductSpecification

Stocks

*

Houses1.. *

Used-by

*

Contains1.. *

Describes

*

1.. *

Described-by

*

Records-sale-of

0..1

Paid-by Initiated-by

Logs-completed

6

*

3 Records-sales-on

1

1

1

1

1

1

1

1

1

1

1

1

1

Initiated-by

1

1

Contained-in1

Captured-on1 1

see pages 116-117

Page 52: Lecture10

ECE 452 - Introduction to Software Engineering

POST

ItemStore

Sale

Payment

SalesLineItem

CashierCustomer

ProductCatalog

ProductSpecification

Houses1.. *

Used-by

*

Contains1.. *

Describes

*

Described-by

*

Records-sale-of

0..1

Paid-by Initiated-by

Logs-completed

6

*

3 Records-sales-on

1

1

1

1

1

1

1

1

1

1

1

1

Initiated-by

1

1

Not need to know No one said Store Stocks Items

1.. *Contained-in

1

Captured-on1 1

see pages 116-117

Page 53: Lecture10

ECE 452 - Introduction to Software Engineering

Need to Know vs. Comprehension

♦ Could do a strict need-to-know model− bounded by current requirements only− but it may not convey a full understanding

♦ By eliminating concepts and associations that are not currently required need to know− the conceptual model may not communicate key ideas and

relationships ♦ Make your conceptual model so it

− has need to know requirements what the system must do− clearly communicates important concepts

♦ could have View as a concept

Page 54: Lecture10

ECE 452 - Introduction to Software Engineering

Summary

♦ Doubting whether to keep a concept?− keep it

♦ Doubting whether to keep an association? − drop it

♦ Do not keep derived associations − Where A relates to B and B relates to C usually

leave out the A to C relationship♦ Does model satisfy all need to know associat-

ions and still present a clear complete picture?

Page 55: Lecture10

ECE 452 - Introduction to Software Engineering

Identifying Attributes

♦ The final piece to the conceptual model is to add the attributes needed to support use cases

♦ Attribute: a logical data value of an object− not necessarily in the final design, though some

attributes will end up in the code♦ Example: A bank customer has an account ID

and a balance− both could be attributes in the conceptual model− both could be instance variables in a class diagram

Page 56: Lecture10

ECE 452 - Introduction to Software Engineering

Keep attributes simple

♦ Look for simple data types as attributes − boolean, date, number, string like data base primitives

♦ Do not use complex ideas as attributes♦ UML puts attributes in 2nd row of concept

boxSale

datestartTime : Time

attributes

Page 57: Lecture10

ECE 452 - Introduction to Software Engineering

Attribute or Association?

♦ Easy to mistake a concept as an attribute

Cashier

namecurrentPOST

not a "simple" attributeWorse

Cashier POST

name numberUses 11Better

Page 58: Lecture10

ECE 452 - Introduction to Software Engineering

Attribute or Association?

♦ Attributes should be simple, if complex, write it as a concept with an association

Flight

destination

destination is a complexconceptWorse

FlightBetter AirportFlies-to1 1