1COMP5028
Object Oriented Analysis & Design
Week 12: Subsystems & Patterns
Today’s Topics
• Subsystems, interfaces, packages (from
week 9)
• Design patterns
• Not covering components and deployment
– Analogous to packages and subsystems but at
the installation phase
Interfaces
• Separates functionality (contract) from
implementation
• Offers a “service” to clients
• Contains
– Operation signatures
– Constants (Java, not UML)
• Does not contain
– attributes
– implementations
– relationships from the interface to anything
else
<>
Employee
Employee
Packages
• Portions of your system that offer a
“complete” service
• Can contain any of the UML
diagrams discussed so far +
statecharts
• Used to separate design concerns
• Have 3 compartments which we
won’t discuss. See textbooks.
Database
Metadata
Database
Metadata
Anchor
Containment
2Subsystems
• Can contain any of the UML
diagrams discussed so far +
statecharts
• Used to separate design concerns
• A package that is an independent part
of the system being modelled
– Stereotyped package
– Other stereotypes available, e.g. façade,
stub
• Have 3 compartments which we
won’t discuss. See textbooks.
Database
<>
Database
Using these
• Find classes that form cohesive clusters
– Offer a service
– Inheritance hierarchies
• Form these into packages / subsystems
• Expose interfaces of functionality only
• Hide implementation / detail inside
• Do this and you’ve created an API!
Example: Flight Reservations
Flight Manager
SQLQuery
<> Flight Database
Flight Manager
SQLQuery
Flight Database
Example: Java Collections API
Collection
Set
SortedSet
List
java.util
3Design Patterns
• “Templates” to solve common problems
• Elegant solutions that have been used in
similar situations before
– Don’t reinvent the wheel
– Use Design Patterns the same way that you’d
use an API or algorithm
• Originated in architecture
• Adapted for software by the “Gang of Four”
• Use them when appropriate, don’t overuse
Example: Last Week’s Lab
• What is special about this pattern?
LockState
+LOCKED[1]: LockState
+UNLOCKED[1]: LockState
-LockState(locked: Boolean)
+getState(): String
Lock
-status: LockState
+Lock(initial: LockState)
+getStatus(): String
Code from Last Week’s Lab
class LockState {
public static final LockState LOCKED = new LockState(true);
public static final Lockstate UNLOCKED = new LockState(false);
private boolean locked;
private LockState(boolean locked) {
this.locked = locked;
}
public String getState() {
// return locked as String
}
}
class Lock {
private LockState status;
public Lock(LockState initial) {
status = initial;
}
public String getStatus() {
return status.getState();
}
}
Last Week’s Lab cont.
• Singleton pattern
• a.k.a. Typesafe Enum
• Often used together with factory method
pattern (set instances to private)
public LockState getLockState(boolean locked)
{
if (locked)
return LOCKED;
return UNLOCKED;
}
4Handle-body pattern
• Asymmetric bridge pattern
• Role is a servant class to Person
• Encapsulate complex properties into a single
handle
Person Trader
Seller Buyer
*
Adapter pattern
• Analogous to fitting a “square peg in a
round hole”
• Often used with event listeners / GUIs
JButton
ActionListener
MyPanel
<>
ActionListener
Notes
• Don’t forget the other design patterns we
covered earlier
– esp. Bridge and Decorator
• Use common sense when applying
• Lots of different types of patterns for
different applications, e.g. J2SE, J2EE, web
• They will make your life easier in the long
run