1. COMP2110 Software Design in 2004 lecture 14 Patterns(1) /Detailed Design
detailed design contrasted with high level design
introducing the Observer Design Pattern
information resources:
lecture : How to design and Tetris example
Braude Software Design
chapters 4 & 5 – background
chapter 6: Design Patterns
chapter 9: Observer pattern
Gamma (book on reserve, chap 5 Behavioral Patterns on eReserve – see website Resources)

2. Process Phase for this module
Requirements
Analysis
Process Phase for this module
Design
Framework
Architecture
Detailed Design
Implementation
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

3. Recap from lecture 6: Design (1) Module structure
One way to describe the program's module structure is called a "module guide"
defines the name for each module and the design responsibility for a module by stating the design decisions/ areas of design responsibility that will be found within it (not the functional responsibility)
This is a decomposition of the solution
decompose the solution into modules, each module may consist of submodules
the document should reflect a tree structure, dividing the system into a small number of modules and treating each module in the same way until all modules are "quite small"

4. Module guide ctd.
we also call this the system architecture or high-level design
there are other ways to choose and describe the architecture

5. Design (1) recap Module structure/architecture
The system is event driven in a computational loop that generates and drives a series of falling bricks in soft real time, using interrupt events to process user command keystrokes.
The system includes a reusable generic playing field for games with coloured tiles.
The system design requires a generic GUI library.

6. Module relationships The “uses” relationship... ...between modules
...between classes

7. Class relationships and interfaces

8. Class relationships – control sequence

9. Key Concept:  Flexibility 
Good design?
Key Concept:  Flexibility 
We design flexibly, introducing parts, because change and reuse are likely.
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

10. Making a Method Re-usable
Specify the method completely
Preconditions etc (see Braude section 1.2.2)
Avoid unnecessary coupling with the enclosing class
Make static if this is feasible
Include parameterization
make the method functional
But limit the number of parameters
Make the names expressive
Understandability promotes re-usability
Explain the algorithm
Re-users need to know how the algorithm works
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

11. Making a Class Re-usable
Describe the class completely
Make the class name and functionality match a real world concept
Define a useful abstraction
attain broad applicability
Reduce dependencies on other classes
Elevate dependencies in the hierarchy
alternatives
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

12. Example: design of a Command Line Calculator-requirements
CommandLineCalculator begins by asking the user how many accounts he wants to open. It then establishes the desired number, each with zero balance.
CommandLineCalculator asks the user which of these accounts he wants to deal with.
When the user has selected an account, CommandLineCalculator allows the user to add whole numbers of dollars to, or subtract them from the account for as long as he requires.
When the user is done with an account, he is permitted to quit, or to pick another account to process.
(Braude chapter 1.4.1)
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

13. A More Flexible Design for Calculator Application
New Design
Existing Design
Calculator
solicitNumAccounts()
CalcDisplay
display()
CommandLineCalculator
main()
executeAdditions()
solicitNumberAccounts()
getAnInputFromUser()
interactWithUser()
CalcOperation
execute()
Add
Multiply
Divide
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

14. Two kinds of reuse
actual software (packages, classes) can be reused if designed well
but it is difficult to actually do design this well
existing ideas, concepts, general ways of putting components together can be adapted by the designer to new projects
Design Patterns are an excellent way of describing sets of well-known ideas for designers to reuse

15. Design Patterns
Design Patterns have names: other designers can recognise what you are doing and playing variations on
Design Patterns have documented properties: where and how they work, what performance problems, what other restrictions
Consequences:
Design patterns can save lots of time learning by (bad) experience: pre-packaged (good) experiences
thinking in design patterns pushes us to think generally, more abstractly, more productively

16. The point of studying design patterns
enable you to re-use great design ideas
create a common vocabulary for talking about design with designers, reviewers, programmers.
give you a higher-level perspective on design,
allow you to talk and think at a higher level of abstraction (Forest vs. trees)
The solutions in the standard patterns embody some important design principles
in particular many of them produce code that is much easier to modify than a more straightforward, simple-minded solution.

17. Patterns: from their inventor, a bricks-and-mortar Architect
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

18. Describing Software Design Patterns
Item Description
Name A unique name that identifies this pattern
Intent The purpose of this pattern
Problem The problem the pattern tries to solve
Solution How the pattern provides a solution to the problem
Participant and Collaborators The entities (usually classes) involved in the pattern
Consequences The consequences of using this pattern; discussion of the forces at play
Implementation How to implement it
GoF Page number in the Gang of Four book (Gamma et al)

19. Observer pattern see also Braude 9.5, GoF chap 5
Problem: Changes to one object require changes to others that depend on it, but you don't know how many objects will need to be changed.
Examples:
a networked file system
a spreadsheet program with multiple views: charts and graphs, cells and formulae
a set of different views (render, edit, window) over a single complex structured text-like file (e.g. HTML)

20. Observer (1) Here is the "standard" pattern outline [GoF pp 293-303]
Name Observer
Intent Define a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.
Problem You need to notify a varying list of objects that an event has occurred.
Solution The observers delegate the responsibility for monitoring for an event to a central object: the subject (or Source- [Braude])

21. Observer (2)
Participants and Collaborators The subject knows its observers because they register with it. The subject must notify the observers when the event occurs. The observers are responsible both for registering with the subject and for getting the information they need from the subject when notified.
Consequences Subjects may tell observers about events they do not need to know about, if some observers are only interested in a subset of events. Extra communication is needed when the observers ask the subject for more information.

22. Observer (3)
Implementation Have observers register with the subject. The subject is responsible for monitoring for (or generating) the interesting events. Observers need to keep a reference to the subject. The subject needs to keep a list of observers and to add observers or remove them from the list on request. When an interesting event occurs, the subject goes through its list and tells each observer to update itself.

23. Observer implementation – in UML
see separate diagrams:
Observer class diagram
Observer sequence diagram