comp 2110 Software Design lecture 13 Detailed Design

comp 2110 Software Design lecture 13 Detailed Design (1) detailed design contrasted with high level design introducing the Observer Design Pattern information resources: o lecture 6 2003 and Tetris design lecture from 2002 http: //cs. anu. edu. au/student/comp 2110/archive 2002/lectures/lec 03 -notes. html o Braude Software Design o chapters 4 & 5 – background o chapter 6: Design Patterns

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" o 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) o This is a decomposition of the solution o decompose the solution into modules, each module may consist of submodules o 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" Note: o we also call this the system architecture or high-level

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.

Module relationships uses relationships. . . between modules . . . between classes

Class relationships and interfaces

Class relationships – control sequence

Key Concept: Flexibility We design flexibly, introducing parts, because change and reuse are likely.

Making a Method Re-usable Specify completely o Preconditions etc (see Braude section 1. 2. 2) Avoid unnecessary coupling with the enclosing class 1. Make static if feasible 2. Include parameterization 1. i. e. , make the method functional 2. 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 Make the class completely the class name and functionality match a real world alternatives concept 1. Define a useful abstraction o attain broad applicability 2. Reduce dependencies on other classes • Elevate dependencies in the

Example: design of a Command Line Calculator-requirements 1. Command. Line. Calculator begins by asking the user how many accounts he wants to open. It then establishes the desired number, each with zero balance. 2. Command. Line. Calculator asks the user which of these accounts he wants to deal with. 3. When the user has selected an account, Command. Line. Calculator allows the user to add whole numbers of dollars to, or subtract them from the account for as long as he requires. 4. When the user is done with an account, he is 1. 4. 1) (from chapter

More Flexible Design for Calculator Application Existing Design New Design

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

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 Design patterns can save lots of time learning by (bad) experience:

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, o 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

Patterns: from their inventor, a bricks-andmortar 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;

Observer pattern see also Braude 9. 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 charts and graphs a set of different views (render, edit,

Observer (1) Here is the "standard" pattern outline [Go. F 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.

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

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.