Software Design and Modelling
Object-Oriented Design Models
Textbook: 15, 16, & 17
“A mathematician is a device for turning coffee into theorems.” — ̈s
Copyright By PowCoder代写 加微信 powcoder
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
Revisited: Object-Oriented Analysis, Design, and Development
Problem domain
• Concepts
• Relationships
Text stories
OO Domain Models
• Static: Domain Class Diagram
• Dynamic: System Sequence Diagram
Conceptual Classes
OO Design Models
• Static: Design Class Diagram
• Dynamic: Design Sequence Diagram
Software Classes
OO Implementation
Classes in Programming
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
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.
Require- ments
inspiration for names of some software domain objects
starting events to design for, and detailed post- condition to satisfy
Use Case Diagram
functional requirements that must be realized by the objects
non-functional requirements
domain rules
Relationship of OO Design Models in UP
Business Sale 1
Sales LineItem
… quantity …
Use-Case Model
Supplementary Specification
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
ideas for the post- conditions
system operations
: Register (itemID, quantity)
Operation: enterItem(…)
Post-conditions: – . . .
Operation Contracts
Register …
makeNewSale() enterItem(…)
ProductCatalog …
getProductDescription(…) …
Sample UP Artifact Relationships Domain Model
Process Sale
1. Customer arrives …
3. Cashier enters item identifier.
Use Case Text
system events
make NewSale()
enterItem (id, quantity)
UP artifacts influence the OO design
System Sequence Diagrams
Design Model
: ProductCatalog
item details, formats, validation
d = getProductDescription(itemID) addLineItem( d, quantity )
Object-oriented software design is a process of creating a co
and their collaboration.
• Structure and connectedness
– Levels, including Architecture
item details, formats, validation
• 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
– Design sequence diagram is one of UML interaction diagrams.
Another interaction diagram, i.e., communication diagram is not focused in this lecture
inspiration for
starting events to
Operation: enterItem(…)
enterItem (id, quantity)
design for, and detailed post-
condition to satisfy
Use Case Diagram
operations
Operation Contracts
System Sequence Diagrams
Design Model
Design Sequence
enters item identifier.
Use Case Text
system events
make NewSale()
l solution by defining software objects
Require- ments
Object-Oriented Software Design
functional requirements that must be realized by the objects
non-functional requirements
domain rules
: Register (itemID, quantity)
: ProductCatalog
conditions
d = getProductDescription(itemID) addLineItem( d, quantity )
Register …
makeNewSale() * 1 enterItem(…)
Design Class Diagram
ProductCatalog …
getProductDescription(…) …
Layers in OO Design
We focus on the core application logic layer
User Interface
Main focus:
application logic layer
other layers or components
Secondary focus (in future lectures)
technologies.
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.
pOrimtahryeforculas yers tend to be technology/platform of case studies
dependent.
explore how to design objects
Design approach/patterns for other layers tends to be technology constrained and changeable.
secondary focus
Logging …
Database Access …
inspiration for names of some software domain objects
starting events to design for, and detailed post- condition to satisfy
Operation: enterItem(…)
Post-conditions: – . . .
Operation Contracts
make NewSale()
system operations
enterItem (id, quantity)
: Register (itemID, quantity)
System Sequence Diagrams
Design Model
: ProductCatalog
item details, formats, validation
Static OO Design
Design Class Diagrams
d = getProductDescription(itemID) addLineItem( d, quantity )
Register …
makeNewSale() * 1 enterItem(…)
ProductCatalog …
getProductDescription(…) …
Textbook: 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 …
isComplete : Boolean
– illustrates class names, interfaces, and the associations of software objects
perspective
Class name
Association with multiplicity
currentSale
Interfaces, i.e., method signature
Attributes and data type
Design Model
DCD; software perspective
isComplete : Boolean /total
endSale() enterItem(…) makePayment(…)
makeLineItem(…)
Domain Models vs Design Models Both models use the same UML class 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
Domain Model
conceptual perspective
Inspire terms and associations
isComplete : Boolean /total
currentSale
Design Model
DCD; software perspective
isComplete : Boolean /total
endSale() enterItem(…) makePayment(…)
makeLineItem(…)
Designing Software Objects
• One popular way 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
Example: POS
• In the domain model, Sale has a (derived) 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)
1 name address
Sales LineItem
1..* Contained-in
dateTime / total
Records- accounts- for
Logs- completed
Captured-on 1 0..1
1 Houses 1..*
Register id
Partial domain model
1 Customer
Works-on
public class Sale
CashPayment
→ A Sale class will have ‘makeLineItem’ method
• The sale total is derived from the subtotals of sale line items private List lineItems = new ArrayList();
isComplete : Boolean
amountT endered
SalesLineItem
time : DateTime
lineItems quantity : Integer 1..*
getSubtotal()
Partial design model
– ‘getTotal’ of Sale is collaborating with ‘getSubtotal’ of
becomeComplete() makeLineItem() makePayment() getTtotal()
SaleLineItem
A collection class is necessary to maintain attribute visibility to all the SalesLineItems.
Records- accounts- for
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
Contained-in Logs-
1 completed
dateTime Captured-on 1 / total 0..1
1 Houses 1..*
Register id
Is-for 1 1
Partial domain model
Works-on
attribute { …
CashPayment Customer
lineItems 1..*
Partial design model
→ a software SaleLineItem class knows quantity private List lineItems = new ArrayList();
amountT endered
SalesLineItem quantity : Integer getSubtotal()
isComplete : Boolean
time : DateTime
becomeComplete() makeLineItem() makePayment() getTtotal()
A collection class is necessary to maintain attribute visibility to all the SalesLineItems.
Exercise: Lucky 7
“Player plays a game by rolling 2 dice. System presents the outcome (Win if the dice face value totals 7; Otherwise lose).”
Use Case Diagram
play() :wonOrLost
– fa c e V a l u e
Domain Class Diagram
System Sequence Diagram
Exercise: Lucky 7
Create a design class diagram
Help me complete the design class diagram!
Partial Domain Class Diagram
1 includes 2
– fac eV alue
play() :wonOrLost
System Sequence Diagram
Participate the online lecture using Zoom annotations
Exercise: Lucky 7
Create a design class diagram
Partial Domain Class Diagram
1 includes 2
– fac eV alue
includes 12
Design Class Diagram
– die1 :Die – die2 :Die
– faceValue :int
+ getFaceValue() :int + roll() :void
play() :wonOrLost
+ play() :boolean
System Sequence Diagram
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() { … }
ProductDescription
SalesLineItem quantity : Integer getSubtotal() : Money
description : Text
description
1 itemID : ItemID
price : Money …
*More detail is available in Workshop 3 supplementary materials
inspiration for names of some software domain objects
starting events to design for, and detailed post- condition to satisfy
Operation: enterItem(…)
Post-conditions: – . . .
Operation Contracts
make NewSale()
system operations
enterItem (id, quantity)
: Register (itemID, quantity)
System Sequence Diagrams
Design Model
: ProductCatalog
item details, formats, validation
Dynamic OO Design
Design Sequence Diagrams
d = getProductDescription(itemID) addLineItem( d, quantity )
Register …
makeNewSale() * 1 enterItem(…)
ProductCatalog …
getProductDescription(…) …
Textbook: 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
A message with
makePayment(cashTendered)
An activation bar or execution bar indicate the focus of control (Optional)
create(cashTendered)
A found message whose sender will not be specified
21 *Communication diagrams are not the focus of this lecture
ckout hase.
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
Process Sale Scenario
makeNewSale
loop [ more items ]
enterItem(itemID, quantity) description, total
: Register
makePayment(cashTendered)
makePayment(cashTendered)
create(cashTendered)
l, and ndles
endSale total with taxes
makePayment(amount) change due, receipt
System Sequence Diagram
Partial Design Sequence Diagram
RDD & Design Sequence Diagram
• Design Sequence Diagram helps in better realizing responsibilities of software objects – Concerning the responsibility assignment when drawing the diagram
: Register
makePayment(cashTendered)
Sale object creates Payment
makePayment(cashTendered)
create(cashTendered)
Implies that Sale object have a responsibility to create Payments
Exercise: Lucky 7
“Player plays a game by rolling 2 dice. System presents the outcome (Win if the dice face value totals 7; Lose otherwise).”
Use Case Diagram
play() :wonOrLost
– fa c e V a l u e
Domain Class Diagram
System Sequence Diagram
Exercise: Lucky 7
Create a design sequence diagram
“Player plays a game by rolling 2 dice. System presents the outcome (Win if the dice face value totals 7; Lose otherwise).”
Help me complete the design sequence diagram!
Partial Design Class Diagram
includes 12
– die1 :Die – die2 :Die
– faceValue :int
+ getFaceValue() :int + roll() :void
+ play() :boolean
play() :wonOrLost
System Sequence Diagram
Participate the online lecture using annotations
Exercise: Lucky 7
Create a design class diagram
Partial Design Class Diagram
includes 12
– die1 :Die – die2 :Die
+ play() :boolean
play() :boolean
“Player plays a game by rolling 2 dice. System presents the outcome (Win if the dice face value totals 7; Lose otherwise).”
fv1= getFaceValue() :int
play() :wonOrLost
fv2= getFaceValue() :int
System Sequence Diagram
:fv1+fv2==7
Design Sequence Diagram
– faceValue :int
+ getFaceValue() :int + roll() :void
Design Sequence Diagram To Code
public class A {
private B myB = new B(); public void doOne()
myB.doTwo();
myB.doThree();
doTwo doThree
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
More examples of creating a design model are available in Tony’s Pizza case study
Lecture Identification
Semester 1, 2022
© University of Melbourne 2022
These slides include materials from:
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, by , Inc., 2005.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com