COMP2110 Software Design in 2004 lecture 14 Patterns1 Detailed Design - PowerPoint PPT Presentation


PPT – COMP2110 Software Design in 2004 lecture 14 Patterns1 Detailed Design PowerPoint presentation | free to view - id: 915a3-ODViN


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

COMP2110 Software Design in 2004 lecture 14 Patterns1 Detailed Design


other designers can recognise what you are doing and playing variations on ... vocabulary for talking about design with designers, reviewers, programmers. ... – PowerPoint PPT presentation

Number of Views:87
Avg rating:3.0/5.0
Slides: 24
Provided by: csAn


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: COMP2110 Software Design in 2004 lecture 14 Patterns1 Detailed Design

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 6 2004 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)

Process Phase for this module
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
  • 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"

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

Design (1) recap 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.

Module relationships
The uses relationship...
...between modules
...between classes
Class relationships and interfaces
Class relationships control sequence
Key Concept ? Flexibility ?
Good design?
We design flexibly, introducing parts, because
change and reuse are likely.
Making a Method Re-usable
  • Specify the method completely
  • Preconditions etc (see Braude section 1.2.2)
  • Avoid unnecessary coupling with the enclosing
  • 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

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

Example design of a Command Line
  • CommandLineCalculator begins by asking the user
    how many accounts he wants to open. It then
    establishes the desired number, each with zero
  • 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

(Braude chapter 1.4.1)
A More Flexible Design for Calculator Application
New Design
Existing Design
Two kinds of reuse
  • actual software (packages, classes) can be reused
    if designed well
  • but it is difficult to actually do design this
  • 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

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

The point of studying design patterns
  • 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.

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

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)

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)

Observer (1)
  • Here is the "standard" pattern outline GoF pp
  • 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
  • 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)

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

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.

Observer implementation in UML
  • see separate diagrams
  • Observer class diagram
  • Observer sequence diagram