Software Design
SOFTWARE DESIGN
Software Design
An iterative process
Provides details about components necessary to implement software
Classes
Data Structures
Software architecture, etc.
1
SOFTWARE DESIGN
Class Design:
Abstraction
An Abstraction of a Pipe.
(from Torczyner, Harry. Magritte:
Ideas and Images. p. 71)
2
SOFTWARE DESIGN
Class Design: Abstraction
Abstraction: set of information properties relevant to a stakeholder about an entity
Information Property: a named, objective and quantifiable aspect of an entity
Stakeholder: a real or imagined person (or a class of people) who is seen as the
audience for, or user of the abstraction being defined
3
SOFTWARE DESIGN
When you drive a car, you're shown
information on speed, fuel, and
RPMs. You have the choice of actions
like drive, park, reverse, etc.
As the driver of a car, you are not
concerned with the crankshaft &
spark plugs & cylinders & valves & ...
(For self-driving cars, Drive.java
might have a similar degree of
abstraction.)
4
SOFTWARE DESIGN
Class Design
Information Hiding: prevents client(s) from accessing some aspect of the class (or
software system) implementation
Information hiding can be achieved through:
Interfaces
Encapsulation
5
SOFTWARE DESIGN
Using an Interface to Hide Information
public interface Driveable {
void drive();
void park();
void reverse();
}
public class Car implements Driveable {
// ...
}
public class Motorcycle implements Driveable {
// ...
}
From a user's point of view, they do not need to care about how Car and Motorcycle
are implemented.
6
SOFTWARE DESIGN
Using an Interface to Hide Information
public class DriveableClient {
public static void main() {
Driveable car = new Car();
Driveable motorcycle = new Motorcycle();
car.drive();
motorcycle.drive();
}
}
From a user's point of view, they do not need to care about how Car and Motorcycle
are implemented. Just use them both as Driveable objects.
7
SOFTWARE DESIGN
Using Encapsulation to Hide
Information
public class BankAccount {
public double balance;
public BankAccount(double startingAmount, String owner) {...}
public double checkBalance() {...}
public void deposit(double amount) {...}
public void withdraw(double amount) {...}
}
Do you see any issues with the way this class is designed?
8
SOFTWARE DESIGN
Using Encapsulation to Hide
Information
public class BankAccountDemo {
public static void main(String[] args) {
BankAccount myAccount = new BankAccount(100.0, "Harry Smith");
myAccount.balance = 1000000.0;
myAccount.withdraw(1000000.0);
}
}
Public methods can be freely accessed and modified by other classes. This is not good!
9
Using Encapsulation
public class BankAccount {
private double balance;
public BankAccount(double startingAmount, String owner) {...}
public void deposit(double amount) {
if (verifyDepositAmount(amount)) {
balance += amount;
}
}
public void withdraw(double amount) {
if (balance >= amount) {
balance -= amount;
offerCash(amount);
}
}
}
SOFTWARE DESIGN
Class Design
Characteristics of a well-formed design class:
Complete and sufficient:
design should encapsulate all attributes and methods that are expected
Primitiveness:
methods in a class should accomplish one service for the class.
A class should not have more than one method to accomplish the
same function
Can you make an argument about why primitiveness is important for testing? For
making modifications in future iterations?
11
SOFTWARE DESIGN
Class Design
Characteristics of a well-formed design class:
High cohesion:
A cohesive design class has a small, focused set of responsibilities
A cohesive design class single-mindedly applies attributes and methods to
implement those responsibilities
12
SOFTWARE DESIGN
Class Design
Characteristics of a well-formed design class:
Low coupling:
Classes collaborate with each other
Collaboration should be kept to a minimum and mediated through interfaces
wherever possible
High coupling leads to software that is difficult to implement, to test, and to
maintain over time
13
SOFTWARE DESIGN
Unified Modeling Language (UML)
UML:
Modeling language intended to provide a standard way to visualize the design of a
software system.
Class diagram:
Static diagram
Describes the structure of a system by showing the system's classes, their
attributes, operations (or methods), and the relationships among objects
14
SOFTWARE DESIGN
Class Diagram
Upper section: Contains the name of
the class
Middle section: Contains the
attributes of the class
Bottom section: Includes class
operations (methods header).
Displayed in list format, each
operation takes up its own line
15
SOFTWARE DESIGN
Domain Model
Diagram
Emphasizes classes, interfaces,
associations, usage, realization,
& multiplicity
Used to show how all the
entities relate
Implementation details
totally abstracted
This example doesn’t show a
single method!
16
SOFTWARE DESIGN
Diagram of
Implementation
Classes
Emphasizes classes, interfaces,
associations, usage, realization
Gives a clear picture of how the
classes will be written
Will include fields & methods
Very dense!
17
SOFTWARE DESIGN
What to use?
Companies have different standards
Important to know the ideas of UML but frequency of use may be low
So:
For this course, use the domain model diagram since I know what methods
you’re using!
If you want to do the diagram of implementation classes, that is good practice
for the future!
18
SOFTWARE DESIGN
Class Diagram
Data fields visibility:
+ Public
- Private
# Protected
/ Derived
~ Package (default)
19
SOFTWARE DESIGN
Class Diagram
Methods:
Underline static methods
Parameter types listed as (name: type)
Do not include “return type” when it is void
20
SOFTWARE DESIGN
Class
Relationships
All relationships in UML are
considered associations
Specific kinds of relationships
are subtypes of associations and
have specific ways they should
be drawn on the page.
21
SOFTWARE DESIGN
Writing a
General
Association
22
SOFTWARE DESIGN
Class Relationships
Composition relationship (filled/black diamond):
When attempting to represent real-world whole-part relationships.
When the container is destroyed, the contents are also destroyed.
Usually refers to a collection (or data structure!) of some kind
23
SOFTWARE DESIGN
Class Relationships
Aggregation relationship (white diamond):
Weak form of aggregation.
When the container is destroyed, the contents are usually not destroyed.
Usually refers to a collection (or data structure!) of some kind
24
SOFTWARE DESIGN
Class
Relationships
Inheritance (hollow triangle,
solid line):
(sometimes called
generalization)
Omit trivial (get/set) methods
Do not include
inherited methods
25
SOFTWARE DESIGN
Class Relationships
Implementation (hollow triangle, dotted line):
(sometimes called realization)
Write <interface> on top of the interfaces' name
26
SOFTWARE DESIGN
Questions
27
Design Patterns:
Flyweight
28
SOFTWARE DESIGN
Design patterns
Embody and generalize important design concepts for a recurring problem
Reusable solution to a commonly occurring problem in software design
29
SOFTWARE DESIGN
Design patterns
23 patterns grouped in 3 categories:
Creational patterns: object creation patterns
Structural patterns: classes and objects organization patterns
Behavioral patterns: communication between objects patterns
30
SOFTWARE DESIGN
Flyweight Pattern
Structural pattern
Problem: We are building an application with many similar objects. Objects store
identical information and play the same role.
Goal: Minimize memory cost
31
Example: Memory &
Block Games
Each Block stores references to:
two Point objects: topLeft and
bottomRight (64 bits each)
a Color (32 bits)
a description String (unbounded size!)
four children IBlock objects (64 bits each)
Which of these values are wasteful to duplicate?
Example: Memory &
Block Games
Each Block stores references to:
two Point objects: topLeft and
bottomRight (64 bits each)
a Color (32 bits)
a description String (unbounded size!)
four children IBlock objects (64 bits each)
Each of the blocks comes from a standard set
of colors.
Example: Memory &
Block Games
Each of the colors comes from a standard set
of colors.
Keeping a single reference to each color and sharing
those references among all the Block objects would
save a lot of memory!
10 different blocks with 10 different colors 10
different blocks with 8 different colors
SOFTWARE DESIGN
A Better Example
Here's an example with much better savings:
many many references to just four different
color objects.
35
SOFTWARE DESIGN
Flyweight Pattern
Solution:
Shared memory space
A flyweight factory object is used to create and provide shared references
as needed
It is recommended to make shared references immutable
36
SOFTWARE DESIGN
Example
Flyweight:
Leaf nodes can be implemented using a reference to
a single instance of the flyweight (one per category)
to reduce memory costs.
Nodes in the same category share state: Color,
description, etc.
37
SOFTWARE DESIGN
Example: Class Design
Class Purpose
BlockCategory Enum type. Lists all the categories of Blocks
The Flyweight data type. Maintains a reference to the Block category, color, and
BlockType
description. Shared reference
Factory class. Creates new Flyweight objects or return existing ones. Flyweight objects
BlockFactory
are stored in a collection (Map) and are retrieved based on their category
38
SOFTWARE DESIGN
39
Design Patterns:
Visitor
40
SOFTWARE DESIGN
Visitor Pattern
Behavioral pattern
Problem: We want to perform an activity/operation on all objects in a collection
Goal: Separate the activity from the object’s specification
41
SOFTWARE DESIGN
Visitor Pattern
Solution:
Create a separate object called "visitor" that will implement the activity
operation to be performed on the objects
The objects in the collection "accept" the visitor and the visitor objects perform
the activity
42
SOFTWARE DESIGN
Example
We have 2 types of students (undergraduate and graduates) stored in a BST database
for a class' gradebook
We want to update the grade of all students in the class to "curve" it using the
following formula:
Add 1 point to all undergraduate student GPAs
Add 0.5 point to all graduate student GPAs
43
SOFTWARE DESIGN
Example
We don’t want to include the “update” operation in the Student class definition.
Why?
44
SOFTWARE DESIGN
Example
We don’t want to include the “update” operation in the Student class definition.
There are multiple ways that we might want to visit students in the future!
print out all the grades? drop certain assignments?
Poor cohesion if a student is resposible for storing its own information and
updating itself subject to external criteria
45
SOFTWARE DESIGN
Class Design
Name Type Purpose
VisitorStudent Interface Defines the activity to be performed ( visit method)
Visitor Class Implements the VisitorStudent activity ( visit method)
VisitableStudent Interface Defines the accept method to pass the visitor
Student Class implements VisitableStudent operation ( accept )
46
SOFTWARE DESIGN
Extensibility & Anonymous Classes
The Visitor pattern means that we don't have to modify existing classes anytime we
want to define a new way of visiting
We can just implement VisitorStudent a new way
We don't even have to write a new class: we can use an anonymous class
48
SOFTWARE DESIGN
Grade Deflation!
Using an anonymous class, we can create a new instance of a VisitorStudent at
the same time that we use it.
Database students = queryStudents();
students.visit(new VisitorStudent() {
@Override
public void visit(GradStudent student) {
student.gpa -= 0.5;
}
@Override
public void visit(UGStudent student) {
student.gpa -= 1;
}
});
49
SOFTWARE DESIGN
Anonymous Classes
How to use:
MyInterface
Make sure you have some interface, e.g.
Pass a reference to new MyInterface() {...} wherever an instance of
MyInterface is expected
Specify in the braces an implementation of each of the required methods
Avoid if:
The implementation is long
The implementation is used in multiple places
50
