1. Patterns Design
13 February

2. User Interfaces
Introducing the Book

3. Patterns

4. What is a Pattern? A solution to a problem in a context
A structured way of representing design information in prose and diagrams
A way of communicating design information from an expert to a novice
Requirement: shows when and how to apply

5. Origin of Patterns Came from architecture
Christopher Alexander, late 70s
The Timeless Way of Building
Describes
Common architectural motifs
How they come together to form a cohesive, livable environment
Patterns from town planning to decorative detail

6. Architectural Example: Door Placement
If room has two doors and people move through it, keep both doors at one end of the room

7. Alexander’s Patterns What do you need to change for software?
Entries have five parts:
Name: A short familiar, descriptive name or phrase, usually more indicative of the solution than of the problem or context.
Example: One or more pictures, diagrams, and/or descriptions that illustrate prototypical application.
Context: Delineation of situations under which the pattern applies.
Problem: A description of the relevant forces and constraints, and how they interact.
Solution: Static relationships and dynamic rules describing how to construct artifacts in accord with the pattern, often listing several variants.
What do you need to change for software?

8. Properties of Patterns
Independent, specific, and formulated precisely enough to make clear when they apply (encapsulation)
Describes how to build a realization (generativity)
Identifies a solution space containing an invariant that minimizes conflict among constraints (equilibrium)
Represent abstractions of empirical experience and everyday knowledge (abstraction)
May be extended down to arbitrarily fine levels of detail. Like fractals, patterns have no top or bottom (openness)
Hierarchically related. Coarse grained patterns are layered on top of, relate, and constrain fine grained ones (composibility)
What do you need to change for software?

9. Design Patterns All the same benefits are true in software The Book:
Cunningham and Beck recognized in late 80s
Community formed in early 90s
The Book:
Gamma, Helm, Johnson and Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software
Define 23 patterns
Three categories:
Structural – ways to represent ensembles of information
Creational – creating complex objects
Behavioral – capturing the behavior of object

10. Patterns at All Levels

11. “Software Architecture”
What is an architecture?
External view
What does that mean for software?
The highest level design
We’ll refer to it as “system design” – though not consistent in the industry

12. System Design Goals Extensibility: adding new features
Tradeoff of generality and time
How might it be extended?
Changeability: requirements changes
Simplicity: ease of understanding and implementing
Efficiency: speed and size

13. Key System Design Characteristics
Cohesion
degree to which communication takes place within the module
Coupling
degree to which communication takes place between modules
Min-max problem: minimize coupling while maximizing cohesion

14. Examples Role-playing game Personal finance application
Decompose into 4 modules: environment, game control, participants and artifacts
High cohesion and coupling
When two characters meet, all 4 modules are involved
Personal finance application
Decompose into user activities: accounts, bill playing, loans, investments
Low cohesion and high coupling
Accounts are pretty independent
Loan payment would involve the first 3 modules

15. Categorizing System Designs (Shaw and Garlan)
Model-View Controller
Data flows
Viewed as data flowing among processes
Independent components
Components operating in parallel and communicating occasionally
Virtual machines
Treats an application as a program written in a special-purpose language
Repository
Application built around data
Layered architectures
Packages of function with a strong hierarchical uses relationship

16. Why Categorize? Recognize patterns Reuse designs
Learn from other similar applications
Reuse classes

17. Data Flow Design Data flowing among processes Two categories:
Pipes and filters
Filters: processes
Pipes: input streams
Batch sequential
Pipe and filter where input streams are batches of data

18. Pipe and Filter filter pipe filter filter filter filter pipe filter
Filters: processes
Pipes: input streams

19. Example of Batch Sequential
Collect
mortgage funds
Mortgage
pool
Account
balances
Collect
unsecured funds
Unsecured
pool
Pipe: batch input
Processes
Pipe and filter where input streams are batches of data

20. Independent Components
Components operating in parallel and communicating occasionally
Three types
Client-server
Browser-web server most familiar example
Separate systems with narrow interface
Sometimes expanded to three tiers (why?)
Façade pattern (single unified interface)
Parallel communicating processes
Several processes executing at the same time
Typically modeled with sequence diagrams
Observer pattern (one-to-many dependencies)
Event systems
Set of components waiting for input
Example: word processor waiting for user input
State transition diagrams
State pattern (alter behavior depending on state)

21. Client-Server and Facade
«not exposed» P
Façade
«exposed»
Client 1 2
Browser-web server most familiar example:
Separate systems with narrow interface
Key concept: limit exposed interface
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

22. Parallel Communicating Processes
Customer:
customer n
withdraw
customer n+1
Session:
session k
session m
deposit
create
Account:
customer
n+1 saving
checking
retrieve
3 types of processes, 2 instances of each
Duration of process
processes
actions
sequence diagram
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

23. Observer Design Pattern
Single source of data with a number of clients that need to be updated
Client of this
system 1
Request others be notified
1..n
Source
notify()
Observer
update() 2
Notify all observers
ConcreteObserver
observerState
update()
ConcreteSubject
state
Determines if change needed 3
Gamma et al

24. Event Systems and State Transition Diagrams
Set of components waiting for input

25. Virtual machines
Treats an application as a program written in a special language
Payoff is that the interpreter code is the basis for multiple applications
Two types
Interpreters
Rule-based systems

26. Repository A system built around data Two types Databases
Hypertext systems

27. A Typical Repository System
Database
DBMS
GUI
Analysis
process 1 n
…...
Control
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

28. Iterator pattern void setToFirst(); points to first element
void increment(); causes the iterator to point to its next element
C getcurrentElement(); return the element pointed to by the iterator
boolean isDone(); true if all elements processed

29. Hypertext: Basis of the Web
Motivated by Vannevar Bush in 1945
“As We May Think” (Atlantic Monthly)
Theoretical machine, "memex," to enhance human memory by allowing the user to store and retrieve documents linked by associations
Invented by Ted Nelson in the 1960s
Popularized with HTML (Tim Berners-Lee)

30. Ted Nelson
"If computers are the wave of the future, displays are the surfboards."
Xanadu: 1974
"give you a screen in your home from which you can see into the world's hypertext libraries... offer high-performance computer graphics and text services at a price anyone can afford... allow you to send and receive written messages... [and] make you a part of a new electronic literature and art, where you can get all your questions answered...“
Computer Lib/Dream Machines

31. Layered Architecture Role-playing game layer Characters Layout
Encounter
Environment
Encounter Game
Application layer
3D engine layer
«uses»
Coherent collection of software artifacts, typically a package of classes
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

32. Recap Model-View-Controller Data flow systems Independent components
Pipes and filters
Batch sequential
Independent components
Client-server
Parallel communicating processes
Event systems
Virtual machines
Interpreters
Rule-based systems
Repositories
Databases
Hypertext systems
Layered architectures