1. Module 3: UML In Action - Design Patterns

2. Overview Books Design Patterns – Basics Creational Design Patterns
Structural Design Patterns
Behavioral Design Patterns

3. Book
Design Patterns : Elements of Reusable Object-Oriented Software (1995)
(The-Gang-of-Four Book)
The-Gang-of-Four (GoF) - Gamma, Helm, Johnson , Vlissides

4. Life Challenges
Software Design!!!

5. Design Patterns “Each pattern describes
a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”.
--- Christopher Alexander, 1977
This was in describing patterns in buildings and towns.
In SE, design patterns are in terms of objects and interfaces, not walls and doors.
The manner in which a collection of interacting objects collaborate to accomplish a specific task or provide some specific functionality.

6. Architecture vs. Design Patterns
High-level framework for structuring an application
“client-server based on remote procedure calls”
“abstraction layering”
“distributed object-oriented system based on CORBA”
Defines the system in terms of computational components & their interactions
Design Patterns
Lower level than architectures (Sometimes, called micro-architecture)
Reusable collaborations that solve subproblems within an application
how can I decouple subsystem X from subsystem Y?
Why Design Patterns?
Design patterns support object-oriented reuse at a high level of abstraction
Design patterns provide a “framework” that guides and constrains object-oriented implementation

7. 4 Essential Elements of Design Patterns
Name: identifies a pattern
Problem: describes when to apply the pattern in terms of the problem and context
Solution: describes elements that make up the design, their relationships, responsibilities, and collaborations
Consequences: results and trade-offs of applying the pattern

8. Design Patterns in MVC Model: the application object
View: its screen presentation
Controller : defines the way the user interface reacts to user input
MVC decouples views and models by establishing a subscribe/notify protocol between them

9. How to Describe Design Patterns more fully
This is critical because the information has to be conveyed to peer developers in order for them to be able to evaluate, select and utilize patterns.
A format for design patterns
Pattern Name and Classification
Intent
Also Known As
Motivation
Applicability
Structure
Participants
Collaborations
Consequences
Implementation
Sample Code
Known Uses
Related Patterns

10. Organizing Design Patterns
By Purpose (reflects what a pattern does):
Creational Patterns
Structural Patterns
Behavioral Patterns
By Scope: specifies whether the pattern applies primarily to
classes or to
objects.

11. Design Patterns Space Purpose Creational Structural Behavioral Scope
Class
Factory Method
Adapter
Interpreter
Template
Object
Abstract Factory
Builder
Prototype
Singleton
Adapter
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Chain of
Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

12. How Design Patterns Solve Design Problems (1)
Finding Appropriate Objects
encapsulation, granularity, dependency, flexibility, performance, evolution, reusability, …
Determining Object Granularity
Specifying Object Interfaces
Signature
Interface
Type
Dynamic Binding
Polymorphism
Specifying Object Implementations

13. How Design Patterns Solve Design Problems (2)
Specifying Object Implementations

14. Principles of Object-Oriented Design
Programming to an Interface, not an Implementation
Design for Reuse
White-box reuse
Black-box reuse
Favor object composition over class inheritance
Delegation
Inheritance versus Parameterized Types
e.g., Templates in C++

15. Software Design Big problems in practice Big opportunities in research
Have Fun!!

16. Why modularization?
Managerial
Changeability
Comprehensibility

17. What is a “Modularization”?
Making design decisions before the work on independent modules can begin.
Quite different decisions are included for each alternative
In all cases, the intention is to describe all "system level" decisions (i.e. decisions which affect more than one module).

18. A Canonical Topic
“On the Criteria To Be Used in Decomposing Systems into Modules”
David Parnas, 1972

19. Key Word in Context [Parnas72]
A Canonical Example
Key Word in Context [Parnas72]
“The KWIC index system accepts an ordered set of lines, each line is an ordered set of words, and each word is an ordered set of characters. Any line may be "circularly shifted" by repeatedly removing the first word and appending it at the end of the line. The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order. “

20. Key Word in Context [Parnas72]
A Canonical Example
Key Word in Context [Parnas72]
Software Architecture
Sense and Sensibility
Crouching Tiger Hidden Dragon
Architecture Software
and Sensibility Sense
Sensibility Sense and
Tiger Hidden Dragon Crouching
Hidden Dragon Crouching Tiger
Dragon Crouching Tiger Hidden
Input
Circular Shift
Alphabetizing
Output

21. Making your First Decision
How should such a system be designed? Modularized?
What are the factors to consider?

22. Thinking in the perspective of
Software Design!
What does it mean?
1. Elements
2. Relations

23. Describe the Design:
1. Plain English
2. Elements and Relations

24. Main Program/Subroutine

25. Module1: Input
“This module reads the data lines from the input medium and stores them in core for processing by the remaining modules. The characters are packed four to a word, and an otherwise unused character is used to indicate the end of a word. An index is kept to show the starting address of each line. “

26. Build KWIC Architecture
Input
Characters
Line Index
Input Medium
System I/O
Data Repr in Memory
Direct Memory Access

27. Module 2: Circular Shift
“This module is called after the input module has completed its work. It prepares an index which gives the address of the first character of each circular shift, and the original index of the line in the array made up by module 1. It leaves its output in core with words in pairs (original line number, starting address) “

28. Build KWIC Architecture
Input
Circular Shifter
Characters
Line Index
Shifts Index
Input Medium

29. Module 3: Alphabetizing
“This module takes as input the arrays produced by modules 1 and 2. It produces an array in the same format as that produced by module 2. In this case, however, the circular shifts are listed in another order (alphabetically). “

30. Build KWIC Architecture
Input
Circular Shifter
Alphabetizer
Characters
Line Index
Shifts Index
Sorted
Shifts Index
Input Medium

31. Module 4: Output
“Using the arrays produced by module 3 and module 1, this module produces a nicely formatted output listing all of the circular shifts. In a sophisticated system the actual start of each line will be marked, pointers to further information may be inserted, and the start of the circular shift may actually not be the first word in the line, etc. “

32. Build KWIC Architecture
Input
Circular Shifter
Alphabetizer
Output
Characters
Line Index
Shifts Index
Sorted
Shifts Index
Output Medium
Input Medium

33. Module 5: Master Control
“This module does little more than control the sequencing among the other four modules. It may also handle error messages, space allocation, etc . “

34. Build KWIC Architecture

35. Is this a good design? What if: Memory Size change? Input Size change?
Input Format change?
Alphabetizing Policy change?

36. Consider the Following Changes:
1. Input Format
Module 1

37. 2. The decision to have all lines stored in core
2. The decision to have all lines stored in core. For large jobs it may prove inconvenient or impractical to keep all of the lines in core at any one time.
All Modules!!!

38. 3. The decision to pack the characters four to a word
3. The decision to pack the characters four to a word. In cases where we are working with small amounts of data it may prove undesirable to pack the characters; time will be saved by a character per word layout. In other cases we may pack, but in different formats.
All Modules!!!

39. 4. The decision to make an index for the circular shifts rather than actually store them as such. Again, for a small index or a large core, writing them out may be the preferable approach.
Module 2, 3

40. 5. The decision to alphabetize the list once, rather than either (a) search for each item when needed, or (b) partially alphabetize as is done in Hoare's FIND [2]. In a number of circumstances it would be advantageous to distribute the computation involved in alphabetization over the time required to produce the index. .
Module 3

41. In Summary A Canonical Example Describe its Architecture
Evaluate its Changeability

42. Data Abstraction Elements Relations Objects Interfaces I/O Medium
Method Invocation
System I/O

43. Parnas’s Modularization 2
Module 1: Line Storage
Module 2: Input
Module 3: Circular Shift
Module 4: Alphabetizer
Module 5: Output
Module 6: Master Control

44. Our 3-Step Exercise Read module description
Identify architecture elements and relations
Analyze changeability

45. Module 1: Line Storage
“This module consists of a number of functions or subroutines which provide the means by which the user of the module may call on it. The function call CHAR(r,w,c) will have as value an integer representing the cth character in the rth line, wth word. A call such as SETCHAR(rpv,c,d) will cause the cth character in the wth word of the rth line to be the character represented by d (i.e. CHAR(r,w,c) = d). WORDS(r) returns as value the number of words in line r. …“

46. Build OO Architecture Module 1: Line Storage Public Interface addWord
addLine
getWord
getLine
Modules (Objects)
1.LineStorage

47. Module 2: Input
“This module reads the original lines from the input media and calls the line storage module to have them stored internally. “

48. Build OO Architecture Module 2: Input 2. Input System I/O
Method Invocation
addLine
addWord
getLine
getWord
Public Interface
1.LineStorage
I/O Medium
Modules (Objects)
Input Medium

49. Module 3: Circular Shifter
“The principal functions provided by this module are analogs of functions provided in module 1. The module creates the impression that we have created a line holder containing not all of the lines but all of the circular shifts of the lines. Thus the function call CSCHAR(I,w,c) provides the value representing the cth character in the wth word of the Ith circular shift. It is specified that (1) if i < j then the shifts of line i precede the shifts of line j, and (2) for each line the first shift is the original line, the second shift is obtained by making a one-word rotation to the first shift, etc. A function CSSETUP is provided which must be called before the other functions have their specified values. “

50. Module 3: Circular Shifter
Build OO Architecture
Module 3: Circular Shifter
2. Input
addLine
addWord
getLine
getWord
setup
getLine
1. LineStorage
3. Circular Shifter
Input Medium

51. Module 4: Alphabetizer
“This module consists principally of two functions. One, ALPH, must be called before the other will have a defined value. The second, ITH, will serve as an index. ITH(i) will give the index of the circular shift which comes ith in the alphabetical ordering. “

52. Build OO Architecture Module 4: Alphabetizer 2. Input addLine addWord
getLine
getWord
setup
getLine
Alpha
getLine
1. LineStorage
3. Circular Shifter
4. Alphabetizer
Input Medium

53. Module 5: Output
“This module will give the desired printing of set of lines or circular shifts. “

54. Build OO Architecture Module 5: Output 5. Output 2. Input addLine
addWord
getLine
getWord
setup
getLine
Alpha
getLine
1. LineStorage
3. Circular Shifter
4.Alphabetizer
Output Medium
Input Medium

55. Module 6: Master Control
“Similar in function to the modularization above “ (The first modularization)

56. Module 6: Master Control
Build OO Architecture
Module 6: Master Control

57. Is this a good design? What if: Memory Size change? Input Size change?
Input Format change?
Alphabetizing Policy change?

58. Consider the Following Changes:
1. Input Format change
Input module

59. 2. The decision to have all lines stored in core
2. The decision to have all lines stored in core. For large jobs it may prove inconvenient or impractical to keep all of the lines in core at any one time.
LineStorage Module

60. 3. The decision to pack the characters four to a word
3. The decision to pack the characters four to a word. In cases where we are working with small amounts of data it may prove undesirable to pack the characters; time will be saved by a character per word layout. In other cases we may pack, but in different formats.
LineStorage Module

61. 4. The decision to make an index for the circular shifts rather that actually store them as such. Again, for a small index or a large core, writing them out may be the preferable approach.
Circular Shift Module

62. Changeability Analysis Summary
Changes
Affected Modules
1. Input Format
Input
2. Not to store all lines in core
Line Storage
3. Not to pack characters
4. Store full shifted lines
Circular Shift
5. Different Alphabetizing
Alphabetizer

63. Changeability Analysis Summary
A much better choice than the main program/subroutine style under these changes!!

64. High-level Design  Detailed Design
Architecture  UML

65. OO Architecture and UML
Class Diagram: System Statics
Sequence Diagram: System Dynamics

66. OO Architecture  UML Class Diagram
Describes how modules from the original architectural solution map onto classes.
Depicts all classes from the system we are implementing.
For each class it depicts its public interface, i.e., public methods that we may invoke to manipulate instances of that class.
For each class it depicts its instance variables.
Shows how classes relate to each other. Class relations are represented with so-called associations, their type and attributes.

67. OO Architecture  UML Class Diagram
Each module one class.
Public interfacethe bottom sub-box, as a list of method declarations.

68. OO Architecture  UML Class Diagram
Class Relations
A directed association: the originating class has as an instance variable an object of the associated class. For example, the Alphabetizer class has an association with the CircularShift class.

69. UML Sequence Diagram: System Dynamics
Describe how group of objects collaborate to execute a certain task in a running program.
Describes the time sequence of method invocations on the run-time:
Objects are shown as boxes at the top of the diagram.
Time is represented with the so-called object's lifeline.
Method invocation is symbolized through a horizontal line connecting two vertical object's lifelines.
Conditions for method invocation and iterative method invocations may be symbolized with special signs.

70. UML Sequence Diagram: System Dynamics

71. Design for Change Creating an object by specifying a class explicitly
Dependence on specific operations
Dependence on hardware and software platform
Dependence on object representations or implementations
Algorithmic dependencies
Tight coupling
Extending functionality by subclassing
Inability to alter classes conveniently