and professional practice structured design and more...

CS 292 Design Principles 1

CS 292 Software Developmentand Professional Practice

Structured Designand

More Design Principles

Intro to Development 2

Unless otherwise expressly stated, all original material of whatever nature created by John F. Dooley and included in this web site and any related pages, including the site's archives, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

http://creativecommons.org/licenses/by-nc-sa/3.0/

http://creativecommons.org/licenses/by-nc-sa/3.0/


References

McConnell, S., Code Complete, V2, Microsoft Press, 2004, Chapter 5.

Wirth, N. “Program Development by Stepwise Refinement,” CACM 14:4, April, 1971.

Parnas, D., “On the Criteria To Be Used in Decomposing Systems into Modules,” CACM 15:12, December, 1972.

Davis, A., “201 Principles of Software Development,” McGraw-Hill, 1995.

Dooley, J.F., “Software Development,” Chapter 7.


Design Practices

Structured Design Also known as top-down design

Stepwise refinement (Wirth) Modular decomposition (Parnas)


Stepwise Refinement (Wirth)

Program construction consists of a sequence of refinement steps.

In each step a given task is broken up into a number of subtasks.Each refinement of a task must be accompanied by a refinement of the data description and the interface.

The degree of modularity obtained above will determine the ease or difficulty with which a program can be adapted to changes in requirements or environment.


More steps toward refinement

1. During refinement, use a notation that is natural to the problem space. Avoid using a programming language for description as long as possible.

2. Each refinement implies a number of design decisions based on a set of design criteria. These criteria include1. Efficiency of time and space,2. Clarity, and3. Regularity of structure (simplicity).


Refining…

refinement can proceed in two ways Top-down Bottom-up


Top-Down refinement Characterized by moving from a general

description of the problem to detailed statements of what individual modules or routines do. (the results of Wirth’s work) Design the top levels first

Steer clear of language-specific details

Postpone working out the details to the lower levels

Formalize each level

Verify each level

Move to the next lower level to make the next set of refinements.(That is, repeat)


Top-Down refinement

Guiding principle is that humans can only concentrate on a few details at a time. (Miller’s famous 7 +/- 2 result)

Continue refining the solution until It seems as if it would be easier to code than to

decompose Work until you become impatient at how obvious and

easy the design becomes. the down-side here is that you really have no good

metric on “when to stop”. It just takes practice.


Bottom-Up refinement?

If you can’t get started at the top, then start at the bottom. Ask yourself “What do I know that the system needs

to do?” Identify low-level functions & components from that

question Identify common aspects of the low level components

and group them together. Continue with the next level up, or go back to the top

and try again to work down. this isn’t really stepwise refinement, but it can help

get you started.


Bottom-up Assessment

Pros Results in early identification of utility routines, which can

lead to a more compact design. Promotes reuse.

Cons It’s hard to use exclusively (you always end up switching to a

top-down approach at some point.) Sometimes you find you can’t build a program from the

pieces.

Fortunately, top-down and bottom-up design methodologies can be very complementary.


Overall stepwise refinement analysis

pros - It’s easy You can defer implementation details It naturally models problems that are hierarchical it can be done using just pseudo-code it forces you to think hierarchically (which can be

good, but not always) it’s concentration on the function of each step is good

for algorithm design. its easier for beginners to use because it usually uses a

simple syntax; you can focus on the problem.


Overall swr analysis

cons - according to some it’s too unsystematic and loosely

defined to really be called a ‘design method’ it can be really hard to get started with it on a

problem (that first iteration or two can be killers) it assumes that all problems can be solved using a top-

down hierarchical expansion. Many systems aren’t naturally hierarchical so they may not decompose well (e.g. event-driven systems)

modularity is not built-in; you have to do it yourself (like doing ADTs in C)

it is difficult to use when the problem’s complexity lies in the data rather than the algorithms.

CS 292 Design Principles

Stepwise refinement example

lets flip some pancakes!

14


Decomposing modules

Parnas’ 1972 paper… Cited the differences between a top-down

decomposition based on the flow of control of a problem solution

And a decomposition that uses encapsulation and information hiding to isolate data definitions and their operations. (sound familiar???)

(See also Dahl and Nygaard - Simula-67)


Decomposition into Modules

Important factors in Modules Strong Cohesion Loose coupling Information Hiding


Strong Cohesion

A module should offer a group of services that clearly belong together.

Ideally, a module, like a function should do one thing (it’s just a bigger thing!)


Strong Cohesion

Types of cohesion Functional cohesion - the module (or routine) performs

one function.

Sequential cohesion - the module performs several (possibly related) operations in a specific order

Communicational cohesion (is that a word?) - operations in the module make use of the same data, but aren’t otherwise connected, i.e. they pass data but do other stuff.

Temporal cohesion - all operations done at the same time.


Loose Coupling

Coupling is the complement of cohesion. It describes how strongly two modules are related

to each other. The goal is to create modules with internal integrity

(strong cohesion) and small (few), direct, visible and flexible connections to other modules (loose coupling).

Good coupling between modules is loose enough that one module can easily be called by others.


Types of Coupling

Simple-data coupling - non-structured data passed via parameter lists. Best.

Data-structure coupling - structured data passed via parameter lists. Good.

Control coupling - data from module A is passed to module B and tells B what to do. Bad.

Global-data coupling - the two modules make use of the same global data. Quite Bad - what the heck are you doing using

global variables? well, sometimes you just have to...


Information Hiding

Information hiding comes into play at all levels of design.

It is the foundation upon which both modular decomposition and object-oriented design are built.

Large programs that use information hiding are 4 times easier to maintain than those that don’t use it.


Information Hiding

Basic idea is that of a “secret”. Either a piece of data or a process that you want to hide from the

user.

Key task is deciding which features of a module should be known outside the module and which should be kept secret.

The interface is the key.

The interface to a module should reveal as little as possible about its inner workings.

Designing the interface is an iterative process.


Common Types of Secrets

Things that are likely to change The goal is to isolate areas of instability to a single module.

Complex data Complex data structures should be hidden so you can change them

if needed to simplify the code.

Complex logic Complex algorithms are great to hide. Again, so you can isolate the

later changes if necessary.

Operations and the programming language level The more you make your solution look like a solution to a real-world

problem and less like a bunch of programming language constructs, the easier your program is to maintain.


KWIC

Let’s go to the assignment…


More Design Rules…from Alan Davis

Evaluate alternatives What is it you want to optimize in your design? Throughput?

Reliability? Safety? Portability? Modifiability?

Write it down Especially for larger programs!


Don’t re-invent the wheel

In software, stealing is good!

DRY - Don’t Repeat Yourself. (from Hunt & Thomas) anytime you find yourself writing the same code again

make a method, or make a new class/module, or make an interface, or make an abstract class


Minimize intellectual distance

Dijkstra defined intellectual distance as the distance between the real-world problem and the computerized solution.

Minimizing this distance helps to ensure that your solution is correct and maintainable.

The structure of your software should as closely as possible mimic the structure of the real world.


Maintain conceptual integrity

Conceptual integrity implies that a limited number of design forms were used and that they were used uniformly. This includes they way in which functions report errors, how

data structures are organized, the order of parameters in interface definitions, etc.

When a design is complete, it should look as if one person created it.


And finally…

“There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” -- Tony Hoare

and professional practice structured design and more...

Documents