SOEN 6011
Software Engineering Processes
Section SS Fall 2007
Dr Greg Butler
http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html
Week 5
• Larman’s OO Development Process
• Requirements
– Use cases, domain models, system operation
Objectives
• “Think in Objects”
• Practice
• Analyze requirements with • Apply agile modeling
use cases
• Design object solutions
• Create domain models
– Assign responsibilities to
objects
• Apply an iterative & agile
Unified Process (UP)
• Relate analysis and
design artifacts
• Read & write highfrequency UML
– Design collaborations
– Design with patterns
– Design with architectural
layers
– Understand OOP (e.g.,
Java) mapping issues
Basic Questions
What is software design?
How is it different from software programming?
Software development?
How do we design software?
What is the role of objects, layers, architecture, ..?
What is the role of tests, responsibilities, patterns,
models, …?
How does design fit into the software lifecycle?
What is good design?
How does software design differ from … design?
Larman’s Design Process
Sample UP Artifact Relationships
Domain Model
Sale
Business
Modeling
Sales
LineItem
1..*
1
date
...
...
...
quantity
Use-Case Model
Process Sale
Process
Sale
use
case
names
Cashier
Requirements
Use Case Diagram
starting events to
design for, and
detailed postcondition to
satisfy
Design
non-functional
requirements
functional
requirements
that must be
realized by
the objects
Use Case Text
system
events
ideas for
the postconditions
inspiration for
names of
some
software
domain
objects
Supplementary
Specification
1. Customer
arrives ...
2. ...
3. Cashier
enters item
identifier.
domain rules
: System
Glossary
Operation:
enterItem(…)
Post-conditions:
-...
: Cashier
system
operations
make
NewSale()
enterItem
(id, quantity)
item details,
formats,
validation
System Sequence Diagrams
Operation Contracts
Design Model
: Register
: ProductCatalog
enterItem
(itemID, quantity)
d = getProductDescription(itemID)
addLineItem( d, quantity )
Register
ProductCatalog
...
makeNewSale()
enterItem(...)
...
...
*
1
getProductDescription(...)
...
: Sale
Artifacts in the UP Use-Case Model
Sample UP Artifact Relationships
Domain Model
Sale
Business
Modeling
1..*
1
date
...
Sales
LineItem
...
...
quantity
objects, attributes,
associations
scope, goals,
actors, features
Use-Case Model
Vision
Process Sale
Process
Sale
use
case
names
Cashier
Requirements
Use Case Diagram
1. Customer
arrives ...
2. Cashier
makes new
sale.
3. ...
terms, attributes,
validation
Glossary
Use Case Text
system
events
: System
Operation:
enterItem(…)
Post-conditions:
-...
: Cashier
system
operations
make
NewSale()
Supplementary
Specification
enterItem
(id, quantity)
non-functional reqs,
quality attributes
System Sequence Diagrams
Operation Contracts
requirements
: Register
Design
Design Model
: ProductCatalog
enterItem
(itemID, quantity)
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
Artifacts in the UP Use-Case
Model
Partial artifacts, refined in each iteration.
Use-Case Model
:System
foo( x )
Requirements
bar( y )
text
use
cases
use
case
diagrams
system
sequence
diagrams
system
operations
system
operation
contracts
DEFINITION: Use Case
• Informally, a use case is a story of using a
system to fulfill a goal.
– Rent Videos
• Used by primary actors
– E.g., Clerk
– External agents
– something with behavior
• Use supporting actors.
– CreditAuthorizationSystem
DEFINITION: Scenario
• Informally, a scenario is a specific sequence of
actions and interactions in a use case.
– One path through the use case.
– E.g., The scenario of renting videos and first
having to pay overdue fines.
• More formally, a use case is a collection of
success and failure scenarios describing a
primary actor using a system to support a goal.
Use Case Diagrams
Video Store
Information System
Clerk
Pay Fines
Rent Items
«actor»
Credit
Authorization
Service
Manage
Memberships
Customer
Log In
Manage
Inventory
Administrator
Manage Users
Warning: Don’t spend
much time on
diagramming.
Use case work means
to write text, not draw
diagrams
Guidelines: Use Case Diagrams
Show computer system actors
with an alternate notation to
human actors.
Prefer use cases at the EBP level.
Video Store Information System
«actor»
Credit
Authorization
Service
Rent Videos
Clerk
...
primary actors on
the left
supporting actors
on the right
Guidelines: Use Case Diagrams
Types of Actors
Primary actor – has goal, initiates task
Supporting actor – involved in dialogue, provide
services or information
Off-stage actor – has an interest in the use case
Guidelines: Use Case Modeling
•
It is common to group CRUD (Create, Read,
Update, Delete) operations into one use case.
– Manage Users
•
Name starts with a verb.
– Manage Users
•
All systems have a Start Up and Shut Down
use case (perhaps trivial and low level).
– But sometimes, important.
• an avionics system
Detail in Use Cases
Iterative writing of use cases: idea, basics,
scenarios, fully dressed description
“brief” format = terse one-paragraph summary
“casual” format = one informal paragraph per
scenario
“fully dressed” format = everything you want
Use Cases: non-functional requirements
Note that use cases can capture non-functional
requirements
Performance: indicate performance constraints on
individual scenarios
Security: indicate which tasks must be secure
Usability: indicate user characteristics with actor
definitions; indicate frequency of user events
with use case, …
Portability, etc: These are “developer” use cases,
not “user” use cases
DEFINITION: Essential & Concrete
Use Cases
• “Keep the UI out”
• Essential use cases defer the details of the UI,
and focus on the intentions of the actors.
• Essential: Clerk enters Customer ID.
• Concrete/worse: Clerk takes Customer ID card
and reads the bar code with laser scanner.
GUIDELINES: Types of
Scenarios
Main scenario
Alternative scenario – other ways of
achieving the goal
Exceptional scenario – where something
goes wrong
Recovery scenario – but we can recover
Failure scenario – alas, we cannot recover
MOTIVATION: Comprehensible
& Familiar
• Use cases are
stories.
• A simple and familiar
model that many
people, especially
non-technical, can
easily relate to.
DEFINITION & MOTIVATION: Domain Model
• A Domain Model visualizes, using UML class
diagram notation, noteworthy concepts or
objects.
– It is a kind of “visual dictionary.”
– Not a picture of software classes.
• It helps us identify, relate and visualize
important information.
• It provides inspiration for later creation of
software design classes, to reduce
“representational gap.”
Domain Model
Pays-for-overdue-charges 
VideoRental
CashPayment
Pays-for 
amount : Money
1
1
date
1
1
1
*
dueDate
returnDate
returnTime
1..*
*
Initiates 
1
0..1
RentalTransaction
Records-rental-of 
1
Rents
1..*
Customer
VideoStore
Rents-from  address
name
1
phoneNumber
address
name
phoneNumber
1
*
1
1
Maintains
Has 
Video
Stocks
*
ID
*
1
Owns-a 
1
1
*
Membership
Catalog
ID
startDate
1
Described-by 
1
1..*
VideoDescription
LoanPolicy
1
Defines
perDayRentalCharge
perDayLateCharge
1..*
1
1..*
1
title
subjectCategory
Determines-rental-charge 
*
Domain Model and Domain Layer
Low representational gap
UP Domain Model
Stakeholder's view of the noteworthy concepts in the domain.
A Payment in the Domain Model
is a concept, but a Payment in
the Design Model is a software
class. They are not the same
thing, but the former inspired the
naming and definition of the
latter.
Sale
Payment
1
1
Pays-for
date
time
amount
inspires
objects
and
names in
This reduces the representational
gap.
Sale
This is one of the big ideas in
object technology.
Payment
amount: Money
getBalance(): Money
1
Pays-for
1
date: Date
startTime: Time
getTotal(): Money
...
Domain layer of the architecture in the UP Design Model
The object-oriented developer has taken inspiration from the real world domain
in creating software classes.
Therefore, the representational gap between how stakeholders conceive the
domain, and its representation in software, has been lowered.
Conceptual classes
Fig. 9.5
concept's symbol
Sale
date
time
"A sale represents the event
of a purchase transaction. It
has a date and time."
concept's intension
sale-1
sale-2
sale-3
sale-4
concept's extension
Guidelines
9.5
reuse existing model;
use category list (see Table 9.1)
identify noun phrases
9.9 Include Report Objects, eg Receipt
9.10 Think like a mapmaker
9.11 How to model the ‘unreal’ world
9.13 Description class, eg ProductDescription
GUIDELINES: Associations
• Only add associations for noteworthy
relationships. Literally, those for which making a
“note” is worthy or business motivated.
1..*
1
Customer
...
...
Rents
Important association.
Need to remember.
Influenced-by 
Low value association.
Possible, but so what?
Video
1
Loan Policy
...
Associations
See Table 9.2
UML and GUIDELINES: Attributes
• Show only “simple” relatively primitive types as
attributes.
• Connections to other concepts are to be represented as
associations, not attributes.
Payment
date : Date
time : Time
amount : Money
attributes
SSDs, System Operations & Layers
UI
Swing
:System
: Cashier
...
ProcessSale
Frame
makeNewSale()
enterItem()
endSale()
makeNewSale()
: Cashier
enterItem(id, quantity)
makeNewSale()
enterItem()
endSale()
description, total
Domain
endSale()
...
Register
makeNewSale()
enterItem()
...
the system operations handled by the system in an SSD represent the
operation calls on the Application or Domain layer from the UI layer
Context – Organisational
Enterprise Selling Things
Checkout Service
Sales Tax
Agency
Goal: Collect
taxes on sales
POS System
Sales Activity
System
Cashier
Customer
Goal: Buy items
iterative requirements
Goal: Analyze sales
and performance data
use cases
Goal: Process sales
sys. sequence diagrams
domain models
Context – System Subsystem
User-level use cases
User work tasks
User goals for task
(External) actor-system
dialogue
Target system being
modeled is the whole
system
But … can model use
iterative requirements
use cases
Subsystem as target
system
Means other
subsystems are
actors external to the
subsystem
Means that a client of
the service of the
subsystem is an actor
(client is another
sys. sequence diagrams
domain models
Context within artefacts
Sample UP Artifact Relationships
Domain Model
Sale
Business
Modeling
1..*
1
date
...
Sales
LineItem
...
...
quantity
Vision
Use-Case Model
Process Sale
Process
Sale
use
case
names
Cashier
Requirements
Use Case Diagram
1. Customer
arrives ...
2. ...
3. Cashier
enters item
identifier.
Use Case Text
system
events
ideas for
the postconditions
the domain
objects,
attributes,
and
associations
that undergo
changes
Glossary
requirements
that must be
satisfied by
the software
: System
Operation:
enterItem(…)
Post-conditions:
-...
: Cashier
system
operations
Design
Supplementary
Specification
enterItem
(id, quantity)
System Sequence Diagrams
Operation Contracts
starting events to
design for, and
more detailed
requirements that
must be satisfied
by the software
make
NewSale()
: Register
Design Model
: ProductCatalog
enterItem
(itemID, quantity)
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
Context with SSDs
Process Sale Scenario
:System
: Cashier
makeNewSale()
loop
[ more items ]
enterItem(itemID, quantity)
these input system events
invoke system operations
description, total
the system event enterItem
invokes a system operation
called enterItem and so forth
endSale()
this is the same as in objectoriented programming when
we say the message foo
invokes the method (handling
operation) foo
total with taxes
makePayment(amount)
change due, receipt
Ch 11: Operation Contracts
Aim: Define system operations via contracts
Operation
Method
Invariant
Precondition
Postcondition
Definitions
Contract
A contract specifies detailed changes, as a result of a system
operation, to objects in the domain model using pre-conditions
and post-conditions.
Contract Format
– Operation: name and parameters of operation.
– Cross References: use cases that involve the operation.
– Preconditions: noteworthy assumptions about the state of the
system or object in the domain model before execution of the
operation.
– Postconditions: The state of objects in the domain model after
completion of the operation.
State
A state is the condition of an object (or system) at a moment in
time.
Describing the State of a System
Describe the objects in the system
Describe the links (relationships) between
the objects
Describe the properties of each object (ie
the state of the object)
= the (abstract) values of the object attributes
[as in a state machine]
Invariant of a System or Object
Invariant
Is a condition which is always true about the
state of the system (or object)
Note: the state is only defined in between
execution of operations
Hence, invariant only has to be true before
and after each operation, not during an
operation
Postcondition
Definition
The postconditions describe changes in the state of
objects in the domain model. Domain model state
changes include instances created, associations
formed or broken, and attributes changed.
Note: postconditions are not actions to be
performed during the operation
They are the effect, ie observations about state of
domain objects when the operation is finished.
Ie, “what” not “how”
Writing Postconditions
Document
1. Instance creation and deletion
“A SalesLineItem sli was created”
2. Attribute change of value
“sli.quantity became quantity”
Note: quantity is an operation parameter
3. Association links formed and broken
“sli was linked to the current Sale”
“sli was linked with a productDescription based on
itemID match”
Use past tense.
Guidelines
1. Identify system operations from the SSDs.
2. For system operations that are complex and
perhaps subtle in their results, or which are not
clear in the use case, construct a contract.
3. To describe the postconditions, document
1. Instance creation and deletion
2. Attribute modification
3. Links formed and broken
Use past tense for postconditions.
Remember to document the forming of links!