SWEN30006
Software Design and Modelling
Object-Oriented Design Models
Textbook: Larman Chapter 15, 16, & 17
“A mathematician is a device for turning coffee into theorems.” —Paul Erdös
Learning Objectives
On completion of this topic you should be able to:
• Be aware of the role of Object-Oriented design
• Be aware of the primary static and dynamic design models
• Understand the underlying relationship between domain and design models
• Have an awareness of the concepts of responsibility and responsibility-driven design
4
Revisited: Object-Oriented Analysis, Design, and Development
Problem domain
• Concepts
• Relationships
Use Cases
Text stories
OO Domain Models
• Static: Domain Class Diagram
• Dynamic: System Sequence Diagram
Conceptual Classes
Week 2
OO Design Models
• Static: Design Class Diagram
• Dynamic: Design Sequence Diagram
Software Classes
Week 3
OO Implementation
Classes in Programming
Week 3
Week 1
5
Analysis, Design, and Implementation
Object-oriented Domain Models
• Analysis: An investigation of the problem & requirements.
• Object-oriented software analysis emphases finding and describing objects and concepts in the problem
domain.
Object-oriented Design Models
• Design: A conceptual solution to a problem that meets the requirements.
• Object-oriented software design emphasises defining software objects and their collaboration.
Object-oriented Implementation
• Implementation: A concrete solution to a problem that meets the requirements.
• Object-oriented software implementation: implementation in object-oriented languages and technologies.
6
Require- ments
inspiration for names of some software domain objects
starting events to design for, and detailed post- condition to satisfy
Design
Use Case Diagram
functional requirements that must be realized by the objects
Glossary
non-functional requirements
domain rules
Relationship of OO Design Models in UP
Business Sale 1
Sales LineItem
Modeling
1..*
… quantity …
Use-Case Model
. . .
Supplementary Specification
Cashier
date
Process use Sale case
–
–
–
Use case text describes functional requirements that must be realized in the design models
Domain models provides inspiration for names of software objects in the design models
System Sequence Diagram indicates an interaction between users and system, i.e., user inputs and system responses
Operation: enterItem(…)
Post-conditions: – . . .
Operation Contracts
: Register (itemID, quantity)
: Cashier
enterItem
ideas for the post- conditions
system operations
Register …
makeNewSale() enterItem(…)
…
*
1
ProductCatalog …
getProductDescription(…) …
Sample UP Artifact Relationships Domain Model
Process Sale
1. Customer arrives …
2. …
3. Cashier enters item identifier.
Use Case Text
system events
: System
make NewSale()
enterItem (id, quantity)
•
UP artifacts influence the OO design
names
System Sequence Diagrams
Design Model
: ProductCatalog
item details, formats, validation
: Sale
d = getProductDescription(itemID) addLineItem( d, quantity )
7
Object-oriented software design is a process of creating a co
and their collaboration.
• Structure and connectedness
– Levels, including Architecture
– . . .
item details, formats, validation
: Sale
• Interfaces: methods, data types, and protocols – External and Internal
• Assignment of responsibilities – Principles and Patterns
Modelling the conceptual solution
• Static models: Design Class Diagram
• Dynamic models: Design Sequence Diagram
enterItem
– Design sequence diagram is one of UML interaction diagrams.
Another interaction diagram, i.e., communication diagram is not focused in this lecture
8
inspiration for
names of
some
software
starting events to
Operation: enterItem(…)
: Cashier
domain
objects
ns :
enterItem (id, quantity)
design for, and detailed post-
condition to satisfy
Diagram
Design
Use Case Diagram
ideas for
n
Po st
a
operations
c
e
-c on
p
dit io
Operation Contracts
System Sequence Diagrams
Design Model
Design Sequence
t
u
enters item identifier.
Use Case Text
system events
: System
make NewSale()
l solution by defining software objects
Require- ments
Object-Oriented Software Design
functional requirements that must be realized by the objects
Glossary
non-functional requirements
domain rules
: Register (itemID, quantity)
: ProductCatalog
the post-
system
conditions
d = getProductDescription(itemID) addLineItem( d, quantity )
Register …
makeNewSale() * 1 enterItem(…)
…
Design Class Diagram
ProductCatalog …
getProductDescription(…) …
User Interface
Main focus:
application logic layer
other layers or components
Secondary focus (in future lectures)
technologies.
Layers in OO Design
We focus on the core application logic layer
• • • •
OO design of core logic layer similar across
minor focus
explore how to connect to other layers
Essential OO design skills are applicable to other layers.
pOrimtahryeforcluasyers tend to be technology/platform of case studies
Sale
Payment
dependent.
explore how to design objects
Design approach/patterns for other layers tends to be technology constrained and changeable.
secondary focus
Logging …
Database Access …
9
inspiration for names of some software domain objects
starting events to design for, and detailed post- condition to satisfy
Design
: System
Glossary
Operation: enterItem(…)
Post-conditions: – . . .
Operation Contracts
: Cashier
make NewSale()
system operations
enterItem (id, quantity)
: Register (itemID, quantity)
System Sequence Diagrams
Design Model
: ProductCatalog
item details, formats, validation
: Sale
enterItem
Static OO Design
models:
Design Class Diagrams
d = getProductDescription(itemID) addLineItem( d, quantity )
Register …
makeNewSale() * 1 enterItem(…)
…
ProductCatalog …
getProductDescription(…) …
Textbook: Larman Chapter 16 & (partial) 17
Static Design Models
• Definition: A static design model is a representation of software objects which define class names, attributes, and method signatures (but not method bodies)
– Use UML Class Diagram to visualize the model
Domain Model
• Design Class Diagram Register 1
conceptual …
Captures
1
time
isComplete : Boolean
Sale
– illustrates class names, interfaces, and the associations of software objects
perspective
/total
Class name
Association with multiplicity
1
currentSale
Interfaces, i.e., method signature
Register
Sale
Design Model
DCD; software perspective
…
time
isComplete : Boolean /total
Attributes and data type
endSale() enterItem(…) makePayment(…)
makeLineItem(…)
11
•
Domain Models vs Design Models Both models use the same UML diagram, but their focuses are different
– Domain model focuses on a conceptual perspective of the problem domain ▸What are the noteworthy concepts, attributes, and associations in the problem domain
•
•
– Design model focuses on an implementation perspective of software ▸ What are the roles and collaborations of software objects
Domain models inspire the design of software objects To reduce the representational gap between
how stakeholders conceive the domain and its representation in software
Captures
1
Domain Model
conceptual perspective
1
Inspire terms and associations
Sale
Register
time
isComplete : Boolean /total
…
1
currentSale
Sale
Design Model
DCD; software perspective
…
Register
time
isComplete : Boolean /total
endSale() enterItem(…) makePayment(…)
makeLineItem(…)
12
Designing Software Objects
• One of popular ways to design software objects is using Responsibility-Driven Design or RDD
• RDD focuses on assigning responsibility to software objects
– Responsibility: The obligations or behaviours of an object in terms of its role • Two types of responsibility:
•
‣
‣ ‣
Knowing responsibilities include: • knowing about private
encapsulated data
knowing about related objects
knowing about things it can derive or calculate
Doing responsibilities include:
‣ doing something itself, such as creating an
object or doing a calculation
‣ initiating action in other objects
‣ controlling and coordinating activities in
other objects
• RDD also includes the idea of collaboration
– Responsibilities can be implemented by means of methods that either act alone or collaborate with other methods and objects
13
0..1
Records- accounts- for
Used-by *
1
Sales
LineItem Store
Example: POS
• In the domain model, Sale has the total attribute
– Let’s declare: A sale class is responsible for knowing its total (knowing)
→ A Sale class will have ‘getTotal’ method
• Based on the domain model and use case text, Sales Line Items will be contained in Sale and will be created when a product is entered
– Let’s declare: A sale class is responsible for creating a Sale Line Items (doing)
quantity 1 name
Stocks
*
address
1..*
Contained-in Logs-
1 completed
Sale *
dateTime Captured-on 1 / total 0..1
1
1 Houses 1..*
Register id
11
Is-for 1 1
Paid-by
Sale
1 Cashie
Partial domain model
Works-on
public class Sale
CashPayment Customer
→ A Sale class will have ‘makeLineItem’ method
{
…
• The sale total is derived from the sub total of sale line
isComplete : Boolean
SalesLineItem id quantity : Integer getSubtotal()
amountTendered
time : DateTime
item –
private List lineItems = new ArrayList();
}
‘getTotal’ of Sale is collaborating with ‘getSubtotal’ of SaleLineItem
lineItems becomeComplete() 1..*
makeLineItem() makePayment() getTtotal()
Partial design model
14
A collection class is necessary to maintain attribute visibility to all the SalesLineItems.
0..1
Records- accounts- for
Used-by *
1
Sales
LineItem Store
Example: POS
Some Remarks:
• A responsibility in RDD is not the same thing as a method—it’s an abstraction—but methods fulfill responsibilities
• The domain model often inspires responsibilities related to “knowing”, achieving low representational gap
– Ex: the domain model Sale class has a time attribute → a software Sale class knows time
– Ex: the domain SaleLineItem class has a quantity public class Sale
}
quantity 1 name
Stocks
*
address
1..*
Contained-in Logs-
1 completed
Sale *
dateTime Captured-on 1 / total 0..1
1
1 Houses 1..*
Register id
11
Is-for 1 1
Paid-by
Partial domain model
Works-on
Sale
1 Cashie
attribute { …
CashPayment Customer
lineItems 1..*
Partial design model
→ a software SaleLineItem class knows quantity private List lineItems = new ArrayList();
amountTendered
isComplete : Boolean
SalesLineItem id quantity : Integer getSubtotal()
time : DateTime
becomeComplete() makeLineItem() makePayment() getTtotal()
A collection class is necessary to maintain attribute visibility to all the SalesLineItems.
15
Exercise: Lucky 7
Dice Game
Play Game
Use Case:
“Player play a game by rolling 2 dice. System presents the outcome (Win if the dice face value totals 7; Otherwise lose).”
Use Case Diagram
Player
:DiceGame
rolls
:Player
play
2
play() :wonOrLost
Outcome
Player
– name
Die
12
1 plays 1
DiceGame
includes
– fa c e V a l u e
1
Domain Class Diagram
System Sequence Diagram
17
Exercise: Lucky 7
Create a design class diagram
Partial Domain Class Diagram
1 includes 2
System Sequence Diagram
outcome
DiceGame
:Player
Die
– fac eV alue
:DiceGame
play
play() :wonOrLost
18
19
Design Class Diagram To Code
•
•
• •
•
OO Designs provide information necessary to generate the code
OO Design can be mapped to OO Programming
Attributes in Design models = Java fields
Method signatures in Design models = Java methods
The Java constructor is derived from the create responsibility
public class SalesLineItem {
private int quantity;
private ProductDescription description;
public SalesLineItem(ProductDescription desc, int qty) { … } public Money getSubtotal() { … }
}
SalesLineItem quantity : Integer getSubtotal() : Money
description
ProductDescription
description : Text
price : Money 1 itemID : ItemID
…
*More detail is available in Workshop 3 supplementary materials
21
inspiration for names of some software domain objects
starting events to design for, and detailed post- condition to satisfy
Design
: System
Glossary
Operation: enterItem(…)
Post-conditions: – . . .
Operation Contracts
: Cashier
make NewSale()
system operations
enterItem (id, quantity)
: Register (itemID, quantity)
System Sequence Diagrams
Design Model
: ProductCatalog
item details, formats, validation
: Sale
enterItem
Dynamic OO Design
models:
Design Sequence Diagrams
d = getProductDescription(itemID) addLineItem( d, quantity )
Register …
makeNewSale() * 1 enterItem(…)
…
ProductCatalog …
getProductDescription(…) …
Textbook: Larman Chapter 15
Dynamic Design Models
• Definition: A dynamic design model is a representation of how software objects interact via messages – UML Sequence and communication* diagrams are commonly used to visualize the models
• Design Sequence diagram
– Illustrates sequence or time ordering of messages sent between software objects
Class name
makePayment(cashTendered)
: Register
: Sale
A message with
parameter
makePayment(cashTendered)
An activation bar or execution bar indicate the focus of control (Optional)
create(cashTendered)
: Payment
A found message whose sender will not be specified
23 *Communication diagram is not focused in this lecture
enario:
ckout hase.
nd nd
System Sequence Diagram vs Design Sequence Diagram
• System Sequence Diagram treats the system as a black box, focusing on the interaction between actors
and the system
• Design Sequence Diagram illustrates the behaviors within the system, focusing on the interaction between software objects
:System
: Cashier
Process Sale Scenario
makeNewSale
loop [ more items ]
enterItem(itemID, quantity) description, total
: Register
: Sale
makePayment(cashTendered)
makePayment(cashTendered)
create(cashTendered)
: Payment
icates s
l, and ndles
endSale total with taxes
makePayment(amount) change due, receipt
System Sequence Diagram
Partial Design Sequence Diagram
24
c
e c
a a
d e
RDD & Design Sequence Diagram
• Design Sequence Diagram helps in better realizing responsibilities of software objects – Concerning the responsibility assignment when drawing the diagram
: Register
: Sale
makePayment(cashTendered)
Sale object creates Payment
makePayment(cashTendered)
create(cashTendered)
: Payment
Implies that Sale object have a responsibility to create Payments
26
Exercise: Lucky 7
Dice Game
Play Game
Use Case:
“Player play a game by rolling 2 dice. System presents the outcome (Win if the dice face value totals 7; Lose otherwise).”
Use Case Diagram
Player
:DiceGame
rolls
:Player
play
2
play() :wonOrLost
Outcome
Player
– name
Die
12
1 plays 1
DiceGame
includes
– fa c e V a l u e
1
Domain Class Diagram
System Sequence Diagram
28
Exercise: Lucky 7
Create a design sequence diagram
Partial Domain Class Diagram
1 includes 2
System Sequence Diagram
outcome
DiceGame
:Player
Die
– fac eV alue
:DiceGame
play
play() :wonOrLost
29
30
Design Sequence Diagram To Code
public class A {
private B myB = new B(); public void doOne()
{
myB.doTwo();
myB.doThree();
}
// … }
:A
doOne
doTwo doThree
myB : B
32
Summary & Remarks
• Object-Oriented Design aims to create a conceptual solution by defining software objects and their collaboration.
• Static Design Model (Design Class Diagram) illustrates software objects which define class names, attributes, and method signatures (interfaces)
• Dynamic Design Model (Design Sequence Diagram) illustrates how software objects interact via messages
• Responsibility-Driven Design is a metaphor of designing software objects
– By seeing software objects as similar to people with responsibilities who collaborate with other
people to get work done
• To achieve low representational gap, domain models often inspires the class names, attributes, and responsibilities of software objects
33
34
Lecture Identification
Lecturer: Philip Dart
Semester 1, 2021
© University of Melbourne 2021
These slides include materials from:
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, by Craig Larman, Pearson Education Inc., 2005.