and Professional Practice Structured Design and More...
Transcript of 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.
CS 292 Design Principles 3
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.
CS 292 Design Principles 4
Design Practices
Structured Design Also known as top-down design
Stepwise refinement (Wirth) Modular decomposition (Parnas)
CS 292 Design Principles 5
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.
CS 292 Design Principles 6
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).
CS 292 Design Principles 7
Refining…
refinement can proceed in two ways Top-down Bottom-up
CS 292 Design Principles 8
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)
CS 292 Design Principles 9
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.
CS 292 Design Principles 10
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.
CS 292 Design Principles 11
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.
CS 292 Design Principles 12
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.
CS 292 Design Principles 13
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
CS 292 Design Principles 15
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)
CS 292 Design Principles 16
Decomposition into Modules
Important factors in Modules Strong Cohesion Loose coupling Information Hiding
CS 292 Design Principles 17
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!)
CS 292 Design Principles 18
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.
CS 292 Design Principles 19
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.
CS 292 Design Principles 20
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...
CS 292 Design Principles 21
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.
CS 292 Design Principles 22
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.
CS 292 Design Principles 23
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.
CS 292 Design Principles 24
KWIC
Let’s go to the assignment…
CS 292 Design Principles 25
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!
CS 292 Design Principles 26
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
CS 292 Design Principles 27
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.
CS 292 Design Principles 28
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.
CS 292 Design Principles 29
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