Lecture 10

ECE 452- Introduction to Software Engineering
Lecture 10: Object-Oriented Analysis

(System Sequence Diagrams,
Conceptual Model)
Manish Parashar
parashar@ece.rutgers.edu
Department of Electrical &
Computer Engineering
Rutgers University
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.
ECE 452 - Introduction to Software Engineering

Sample UP Artifacts Partial artifacts,
Domain refined in each
Business Model iteration.
Modeling
parameter or
return data may be
elaborated in the
Glossary
Use-Case Model
:System
foo( x )
Requirements Glossary ...
bar( y )
system system
text events & system operations
system
use data sequence operation
cases diagrams contracts
Software
Design Model design objects
Architecture Doc.
to handle the
Design system events
Software
Dev. Plan
Project
Management
Test
Plan Development
Case
Test Environment

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 ?

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

♦ 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

♦ 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. Ilustrate
them.
♦ Optionally include use case text on left.

A System Sequence Diagram
system as black box
Buy Items-version 1
Actor
Cashier :System
Repeat until no enterItem(UPC, quantity)

more items
endSale()
Text which clarifies

control, logic, iteration,
makePayment(amount)
etc.
May be taken from the

use case.
system event
it triggers a system operation

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 )

System Sequence Diagrams from Use Cases
: Cashier :System
makeNewSale(
Simple cash-only Process Sale scenario: )
1. Customer arrives at a POS checkout enterItem(itemID,

with goods and/or services to purchase. quantity)
2. Cashier starts a new sale.
3. Cashier enters item identifier. description,
4. System records sale line item and total
presents item description, price, and * [more items]
running total.
Cashier repeats steps 3-4 until indicates
done. endSale(
5. System presents total with taxes )
calculated.
6. Cashier tells Customer the total, and total with
asks for payment. taxes
7. Customer pays and System handles
payment. makePayment(amount
... )
change due,
receipt
Naming System Events and Operations
:System
: Cashier
better name
enterItem(itemID, quantity)
scan(itemID, quantity)
worse name

SSD with Use Case Text
Simple cash-only Process Sale scenario:
1. Customer arrives at a POS checkout :System

with goods and/or services to purchase. : Cashier
2. Cashier starts a new sale. makeNewSale(
)
3. Cashier enters item identifier. enterItem(itemID,

4. System records sale line item and quantity)
presents item description, price, and
running total. description,
total
* [more items]
Cashier repeats steps 3-4 until indicates endSale(

done. )
5. System presents total with taxes total with
calculated. taxes
6. Cashier tells Customer the total, and

asks for payment. makePayment(amount
7. Customer pays and System handles )
payment.
...
change due,
receipt
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
The Conceptual Model- Introduction
− 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)

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

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

Conceptual Models
− 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
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

Conceptual Modeling
♦ Associations
− less important than identifying concepts
− show only “need-to-know” association (avoid
redundant or derivable associations)
− name, multiplicity, navigability
− multiple associations

Conceptual Model
♦ Attributes
− Attributes Vs. Concepts
♦ keep attributes simple
♦ if in doubt define it as a concept
♦ no attributes as foreign keys (use associations)

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
Concept Sales
Item
LineItem Records-sale-of
0..1 1
quantity
1.. * *
Stocked-in
Association Contained-in
1 1
Sale Store
Attributes date address

time 1 name
1
1
Houses
We're shooting
Paid-by 1.. *
for something
like this for your 1 POST
Captured-on 4
final project Payment
1
amount
Conceptual Model
♦ Conceptshelp 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
Example Concept
♦ POST Sale Sale concept's symbol
date
− symbol: Sale time
− definition
represents the event "A sale represents the event concept's definition
of a purchase transaction. It
of a purchase has a date and time."
transaction, and has

a date and time
− extension: the set sale-1
sale-2 concept's extension

of all sales sale-3
sale-4

Example Concept
♦ POKER Card CardDeck concept's symbol
rank
− symbol: Card suit
− definition:
represents one card A card represents one of the
entities to make up a hand concept's definition
in a poker deck that in a poker game
has a rank (2..14),

and a suit ♣♦♥♠
− extension: the set Ace ♥
concept's extension
of all cards 3♣
King ♦
5♠

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)

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
Concept Category
♦ Physical or tangible things

− POST A Point of Sale Terminal
♦ Specifications
− POST ProductDescription
♦ Transactions
− POST Sale, Payment

More Concept Categories
♦ Things in a container
− POST Sales Line Item
♦ Abstract noun concepts
− POST Waiting line rage
♦ Events
− POST Sale

More Concept Categories
♦ Rules and Policies

− POST RefundPolicy
♦ Organizations
− POST SalesDepartment
For more, see pages 91-93

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

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

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

Resolving Similar Concepts
♦ Naming things correctly is

similar concepts with
− important different names
− sometimes hard to agree:
POST or? Register
1 1
Records 6 Records6
* *
Sale Sale

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

Credit Credit Check
Approval
POST Concepts Authorization
Service
Approval
Request Request
Check Credit Check

Accounts Drivers Authorization Approval Approval
Receivable License Service Reply Reply
Cash Credit Check Credit

Check
Payment Payment Payment Card
Product
POST Item Store Sale
Catalog
Sales Product
Cashier Customer Manager
LineItem
Specification
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

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

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-current
POST Sale
1 1
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?

The UML Association Notation
♦ UML Association:
− a line between two concepts and a name
− they are bi-directional * T
zero or more;
"many"
− can have a multiplicity
− exist in conceptual 1..*
T one or more
models and
1..40
class diagrams T one to forty
5
T exactly five
Multiplicity
adornments
3, 5, 8 exactly three,
T
five or eight
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
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

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

Multiplicity
♦ Multiplicitydefines how many instances of

type A can be associated with one instance of
type B at some point can differ
Game Player
1 1..6
Mother Child
1 1+
performs-in Actor is associated

Actor Film with 0 to many films.
* * A film is associated
can optionally name an association with 0 to many actors
Depends on Context
♦ Are all three associations possible?
Car Wheel
1 4
Car Wheel
1 5
Car Wheel
1 3

Association Names Upcase / hyphenate
♦ Try reading this Type-VerbPhrase-Type
Store
1
Contains
1..*
POST Captures Sale Paid-by Payment

1 1..* 1 1
♦ Not yet worrying about messages, instance variables,

data flow, or software objects
♦ Just show some concepts are connected
No Implementation Yet
♦ Theassociations 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
♦ ConceptualModel should have associations
suggested by requirements and use cases
Any unforgettable Relationships?
♦ POST
− Post Captures Sale
− Sale Paid-By Payment
− ProductCatalog Records Specification

Conceptual Model for the POST associations are not all need to know
Records-sale-of
Described-by 1
Product
Product Specification
Catalog Contains
1 1.. *
1
0..1 Used-by
* Describes
Sales * *
LineItem Store
Item
Stocks
1 1 1
*
1.. *
Logs- 1
Contained-in Houses
completed
1 6 1.. *
Sale * POST
Manager
Captured-on Started-by
1 1 1 1
1
1
1 Initiated-by 1
Paid-by 3 Records-sales-on
1 1 1 see pages
Initiated-by
Payment Customer Cashier 116-117
1

Not need to know No need yet to have POST Started-By Manager
Records-sale-of
Described-by 1
Product
Catalog Contains
1 1.. *
1
0..1 Used-by
* Describes
Sales * *
LineItem Store
Item
Stocks
1 1 1
*
1.. *
Logs- 1
Contained-in Houses
completed
1 6 1.. *
Sale * POST
Captured-on
1 1
1
1
1 Initiated-by 1
1 1 1 see pages
Initiated-by
1

Not need to know No one said Store Stocks Items
Records-sale-of
Described-by 1
Product
Catalog Contains
1 1.. *
1
0..1 Used-by
* Describes
Sales * *
LineItem Store
Item
1 1
1.. *
Logs- 1
Contained-in Houses
completed
1 6 1.. *
Sale * POST
Captured-on
1 1
1
1
1 Initiated-by 1
1 1 1 see pages
Initiated-by
1

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

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?
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
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
box
Sale
attributes
date
startTime : Time

Attribute or Association?
♦ Easy to mistake a concept as an attribute

Cashier
Worse not a "simple" attribute
name
currentPOST
Cashier POST
Better 1 Uses 1
name number

Attribute or Association?
♦ Attributes should be simple, if complex, write

it as a concept with an association
Flight destination is a complex
Worse concept
destination
Flight 1 Flies-to 1 Airport

Better

Lecture 10

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Lecture 10

Hochgeladen von

Copyright:

Verfügbare Formate

ECE 452- Introduction to Software Engineering

Lecture 10: Object-Oriented Analysis

ECE 452 - Introduction to Software Engineering

ECE 452 - Introduction to Software Engineering

ECE 452 - Introduction to Software Engineering

♦ Determine system events and operations

ECE 452 - Introduction to Software Engineering

ECE 452 - Introduction to Software Engineering

♦ Draw a line representing the system as a black

ECE 452 - Introduction to Software Engineering

Repeat until no enterItem(UPC, quantity)

Text which clarifies

May be taken from the

it triggers a system operation

ECE 452 - Introduction to Software Engineering

ECE 452 - Introduction to Software Engineering

1. Customer arrives at a POS checkout enterItem(itemID,

ECE 452 - Introduction to Software Engineering

1. Customer arrives at a POS checkout :System

3. Cashier enters item identifier. enterItem(itemID,

Cashier repeats steps 3-4 until indicates endSale(

6. Cashier tells Customer the total, and

ECE 452 - Introduction to Software Engineering

♦ Object oriented analysis at the “business area

ECE 452 - Introduction to Software Engineering

♦ Define domain to be investigated

ECE 452 - Introduction to Software Engineering

♦ Conceptual models should not contain design

ECE 452 - Introduction to Software Engineering

ECE 452 - Introduction to Software Engineering

ECE 452 - Introduction to Software Engineering

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

Attributes date address

♦ Conceptshelp with domain vocabulary

♦ POST Sale Sale concept's symbol

transaction, and has

sale-2 concept's extension

ECE 452 - Introduction to Software Engineering

♦ POKER Card CardDeck concept's symbol

has a rank (2..14),

ECE 452 - Introduction to Software Engineering

♦ Structured Analysis (still in use today)

ECE 452 - Introduction to Software Engineering

♦ One strategy for getting concepts

♦ Physical or tangible things

ECE 452 - Introduction to Software Engineering

ECE 452 - Introduction to Software Engineering

♦ Rules and Policies

For more, see pages 91-93

ECE 452 - Introduction to Software Engineering

♦ Use vocabulary of the users

♦ Do not include irrelevant things

ECE 452 - Introduction to Software Engineering

♦ Make a list of candidate concepts (objects)

ECE 452 - Introduction to Software Engineering

ECE 452 - Introduction to Software Engineering

♦ Naming things correctly is

POST or? Register

ECE 452 - Introduction to Software Engineering

ECE 452 - Introduction to Software Engineering

Check Credit Check

Cash Credit Check Credit

ECE 452 - Introduction to Software Engineering