comp2110 Software Design lecture 13Detailed Design 1

1
comp2110 Software Designlecture 13 Detailed
Design (1)

• detailed design contrasted with high level design
• introducing the Observer Design Pattern
• information resources
• lecture 6 2003 and Tetris design lecture from
  2002
• http//cs.anu.edu.au/student/comp2110/archive-2002
  /lectures/lec03/lec03-notes.html
• Braude Software Design
• chapters 4 5 background
• chapter 6 Design Patterns
• chapter 9 Observer
• No lectures next 2 weeks (weeks 8 9)gives time
  for your presentations in lab class times

2
Process Phase for this module
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 andthe design
  responsibility for a moduleby 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 modulesand treating each module in the
  same wayuntil all modules are "quite small"
• Note
• we also call this the system architecture or
  high-level design
• there are other ways to choose and describe the
  architecture

4
Design (1) Module structure/architecture

• 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.

5
Module relationships
uses relationships...
between modules
...between classes
6
Class relationships and interfaces
7
Class relationships control sequence
8
Key Concept ? Flexibility ?
We design flexibly, introducing parts, because
change and reuse are likely.
9
Making a Method Re-usable

• Specify completely
• Preconditions etc (see Braude section 1.2.2)
• Avoid unnecessary coupling with the enclosing
  class
• Make static if feasible
• Include parameterization
• i.e., 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

10
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
11
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.

(from chapter 1.4.1)
12
A More Flexible Design for Calculator Application
New Design
Existing Design
13
Two kinds of reuse

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

14
Design Patterns

• Design Patterns have namesother designers can
  recognise what you are doing and playing
  variations on
• Design Patterns have documented propertieswhere
  and how they work, what performance problems,
  what other restrictions
• Design patterns can save lots of time learning by
  (bad) experiencepre-packaged (good) experiences
• thinking in design patterns pushes us to think
  generally, more abstractly, more productively

15
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.

16
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

17
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)

18
Observer pattern

• see also Braude 9.5
• ProblemChanges 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 charts and graphs
• a set of different views (render, edit, window)
  over a single complex structured text-like file
  (e.g. HTML)

19
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 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)

20
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.

21
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.