Embed Size (px)
Citation preview
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.1
Faking the Design ProcessRuminations on the paper by Parnas and Clements
COMP2110/2510Software DesignSoftware Design for SEOctober 29, 2008
Alexei Khorev
Department of Computer Science
The Australian National University
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.2
1 The Classic Paper
2 David Parnas
3 The Ideal Software Process
4 A Mathematical Analogy
5 The Real Software Process
6 Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.3
A Rational Design Process
The purpose of this lecture is to discuss the paper “A Rational Design
process: How and Why to Fake It?" written in 1986 by David L Parnas and
Paul C Clements (IEEE Transactions on Software Engineering, SE–12(2),
pp. 251–257)
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.4
Who Is David Lorge Parnas?
Essentially: one of the fathers of Software Engineering
Currently: Professor of SE and Director of SQRL (Software
Quality Research Laboratory), at Dept. CS&IS, Faculty of In-
formatics and Electronics, University of Limerick (Ireland)
Previously: researcher at the Naval Research Laboratory
(USA), professor of McMaster University (Canada)
His most influential papers:
• “On the Crireria to Be Used in decomposing Systems into Modules”, 1972
(fundamentals of programming to interface and information hiding — before modular
and OO programming became the mainstream)
• “On the Design and Development of Program Families”, 1976 (anticipated the idea of
Design Patterns)
• “Designing Software for Ease of Extension and Contraction”, 1979 (put requirements to
the centre of the software development process, and introduced uses relationships for
their analysis)
• “A Rational Design process: How and Why to Fake It?”, 1986 (discussed the importance
of having a model of the design process which will guide creation of precise and opendocumentation of the software process)
David Parnas became a paragon of professional honesty and ethics for his stance on
perspectives of software development for the Strategic Defense Initiative (“Star Wars”) in 1980s
(see “Software Aspects of Strategic Defense Systems”, Comm. of ACM, 28(12), p. 1326–1335,
1985)
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.5
David Parnas Says
On the profession:
“There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This isentirely misleading. It is not a quantity problem; we have a quality problem. One bad programmercan easily create two new jobs a year. Hiring more bad programmers will just increase our perceivedneed for them. If we had more good programmers, and could easily identify them, we would needfewer, not more.”
On the most-repeated mistake in SE:
“People tend to underestimate the difficulty of the task. Overconfidence explains most of the poorsoftware that I see. Doing it right is hard work. Shortcuts lead you in the wrong direction and theyoften lead to disaster.”
On the modern UML fad:
Imprecisely defined notation leads to software that is almost right. Software that is “almost right”is wrong. Undefiened Modelling Languages are quicksand (and bad idea).
Advice for computer science/software engineering students:
“. . . pay more attention to the fundamental ideas rather than the latest technology. The technologywill be out-of-date before they graduate. Fundamental ideas never get out of date. However, whatworries me about what I just said is that some people would think of Turing machines and Goedel’stheorem as fundamentals. I think those things are fundamental but they are also nearly irrelevant.I think there are fundamental design principles, for example structured programming principles, thegood ideas in "Object Oriented" programming, etc”
Advice for his fellow professional:
“Stop the numbers game!” — Counting papers slows the rate of scientific progress.
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.6
The Ideal View of Software Process
The analysis stage in the Waterfall Model
Implementation
RequirementsAnalysis
Design
Phases (activities)
Testing
Maintenance
Processes-gathering requirements-verifying requirements
Product a SRS document describing information models
SoftwareRequirementsSpecification
Retirement
Processes and Products are well defined and implemented consistently
in a rational, error-free, way
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.6
The Ideal View of Software Process
The design stage in the Waterfall Model
Requirements
Analysis
Design
Phases (activities)
Testing
Maintenance
ProductSDD describing modules, classes, interfaces, algorithms, data structures:as text and diagrams
SoftwareDesignDocument
Processes - decide high-level architecture - do detailed design - reviews
Implementation
Processes and Products are well defined and implemented consistently
in a rational, error-free, way
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.7
What is “Rational” and why do we need it?
Oxford English Dictionary:
3a based on or in accordance with reason or logic : I’m sure there’s aperfectly rational explanation.
7 Descriptive of methods of analysis and planning that make use of
calculation to bring about a projected result.
Why do we want a rational design process?:
• the usual process of designing software is irrational ? and serious
problems result from this state of affairs: cost of success,
abandonment (and cost of failure), bloat
• we would like to derive our programs from a statement of
requirements in the same sense that theorems are derived from
axioms in published mathematical proofs
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.8
The Mathematical Analogy
How lay people think mathematicians work
definitions
axioms
new knowledge(theorems)
proof(deductions,reasoning)
At least this is an impression if to judge about this from the
documented accounts of their job — published articles, books etcwhich present the results of their work
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.8
The Mathematical Analogy
How mathematicians really work
definitions
axioms
strict newknowledge
intuitionsconjectures
trials and errorsdreams
?
?
?
essentials of new knowledge
theorems
lemmata
Proof(deduction, reasoning)
This is what really happens in their heads
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.9
The Software Development Process
The Ideal Software Process
Time (minutes, hours, days...)
15 6045 907530
testing
analysis
requirements
design
implementation
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.9
The Software Development Process
The Real Software Process
Time (minutes, hours, days...)
15 6045 907530
testing
analysis
requirements
design
implementation
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.10
Why the Process cannot be Ideal?
• In most cases the people who commission the building of a software system do not
know exactly what they want and are unable to tell us all that they know.
• Even if we knew the requirements, there are many other facts that we need to know to
design the software. Many of the details only become known to us as we progress in the
implementation. Some of the things that we learn invalidate our design and we must
backtrack. Because we try to minimize lost work, the resulting design may be one that
would not result from a rational design process.
• Even if we knew all of the relevant facts before we started, experience shows that
human beings are unable to comprehend fully the plethora of details that must be
taken into account in order to design and build a correct system. The process of
designing the software is one in which we attempt to separate concerns so that we are
working with a manageable amount of information. However, until we have separated
the concerns, we are bound to make errors.
• Even if we could master all of the detail needed, all but the most trivial projects are
subject to change for external reasons. Some of those changes may invalidate
previous design decisions. The resulting design is not one that would have been
produced by a rational design process.
• Human errors can only be avoided if one can avoid the use of humans. Even after
the concerns are separated, errors will be made (“I err therefore I am!”).• We are often burdened by preconceived design ideas, ideas that we invented,
acquired on related projects, or heard about in a class. Sometimes we undertake a
project in order to try out or use a favourite idea. Such ideas may not be derived from
our requirements by a rational process.
• Often we are encouraged, for economic reasons, to use software that was developed
for some other project. In other situations, we may be encouraged to share our
software with another ongoing project. The resulting software may not be the
ideal software for either project, ie, not the software that we would develop based on
its requirements alone, but it is good enough and will save effort.
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.11
Why Idealization is useful?
If the above is well known and accepted (it is!), why is all these activities — conferences,
workshops, commercial courses — purporting to describe and teach you logical ways to design
software?
The reasons:
• we can follow an idealized rational process as closely as possible, even if we cannot
follow it exactly in reality (this will help to achieve better results with all other conditions
equal)
• designers need guidance (overwhelmed and unsure where to start, with a good
understanding of the ideal process, we will be able to know how to proceed)
• an ideal model is better than an ad hoc process
• a rational process provides a basis for a standardized method — easier to have good
design reviews, to transfer people, ideas, and software from one project to another
• provides a model for control and review — it becomes easier to measure the progress
that a project is making (we can compare the project’s achievements with those that the
ideal process calls for, and identify areas in which we are behind or ahead)
• makes easier for the project’s progress review by outsiders (essential for good
management)
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.12
What does the Faking involves?
The most useful form of a process description will be in terms of work
products.
For each stage of the process, we need to know:
• what product we should work on next
• what criteria the product should satisfy
• who should do the work
• what information the workers should use
“Management of any process that is not described in terms of work
products can only be done by mind readers. Only if we know which work
products are due and what criteria they must satisfy can we review the
project and measure progress.”
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.13
A rational design process
This is what we want:
Input: The description of the system requirements is the input to the
ideal, rational design process
Output: An architecture and a detailed design
Process:
A Establish and Document the Requirements
B Design and Document the Module Structure
C Design and Document the Module Interfaces
D Design and Document the uses-relationships between modules
E Design and Document the Module Internal Structures
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.14
Establish and Document the Requirements
The ideal requirements document satisfies:
• necessary: every statement should be valid for all acceptable
software systems produced (no implementation details appear here)
• sufficient: the document should be complete (any system satisfying
the stated requirements must be acceptable)
• honest: where information is incomplete the documentation should
say so
• referenced: the document should be organized as a reference
document — not as an introductory narrative (harder but pays off in
long term)
A complete and sufficient set of specs would be essential to act as the
input if we did have a rational, automatic design process.
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.15
Design and Document the Module Structure
What is in the Module Guide:
• It defines the responsibilities of each of the modules by stating the design decisions that
will be encapsulated by that module.
• The module may consist of submodules, or it may be considered to be a single work
assignment.
• The document should reflect a tree structure, dividing the system into a small number of
modules.
• It should treat each module in the same way until all modules are “quite small”
A module guide is needed to avoid duplication, to avoid gaps, to achieve separation of
concerns, and most of all, to help an ignorant maintainer to find out which modules are affected
by a problem report or change request. If it is kept up-to-date, this document, which records
our initial design decisions, will be useful as long as the software is used.
A guide that was simply a list of those modules, with no other structure, would help only those
who are already familiar with the system. The module guide should have a tree structure,
dividing the system into a small number of modules and treating each such module in the same
way until all of the modules are quite small.
Note:
• Today, we usually call the module guide section the system architecture or high-leveldesign (this term now has stronger meaning: we expect more “structure” such as layers,
pipelines, MVC in our architectures).
• This process appears to echo a (old?fashioned) stepwise refinement process but it also
lays down some good qualities of the description resulting from any process.
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.16
Design and Document the Module Interfaces
Efficient and rapid production of software requires that the programmers
be able to work independently. The module guide defines responsibilities
but it does not provide enough information to permit independent
implementation. A module interface specification must be written for each
module. It must be formal and provide a black box picture of each module.
The module interface section must include:
• describe interfaces using parameters, signatures, possibly pre- and
post- conditions
• interface description must include a black box description of the
module — a statement of its purpose, what the module does not how
• just enough information to use the module and nothing more (which
is also a property of design by contract)
• timing constraints and accuracy constraints, where necessary (esp.
for real-time systems)
• definition of undesired events
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.17
Design and Document the module uses relationships
The Uses–Relationships section includes:
• The “uses” relationship is another view of a design: it may be an abstraction of the
module interfaces or more detail.
• Can be represented as a matrix — the entry in position (A,B) is true if and only if the
correctness of program A depends on the presence in the system of a correct program
B. For modern OO we would also use a class diagram.
• Captures an important notion of interaction.
• Important for building subsets: answers the question can we build a part of the system
using only a subset of modules? (staged delivery, fail soft systems, program families. . . )
Modules A B C D
A true false false
B false false false
C true true false
D false true false
Note: Other interactions between modules can also be documented, especially flows of control
(and incoming event handling), data flows. for modern OO we can use other UML
diagrams: sequence, collaboration, state. . .
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.18
Design and Document the Module Internal Structures
The Internal Structure section:
• explains the intent of the module to the programmer (implementer)
of this module
• documents the effect of each function on any data structures — any
side effects as well as pre and post- conditions of the contract
• exception (undesired events) handling
• use pseudocode or partial program code (the authors make no bone
about using real chunks of code — if their syntax can be verified by
a compiler — even better!)
• a “verification” argument that the module’s properties are sufficient
to satisfy the specification
• allows an efficient review of the design before coding
Note: in OO design many classes and methods are almost fully described
by the interface alone. Systems where there are more substantial
functions involved than just “handle” or “dispatch” events or
manipulate simple data need more design work and documentation
here.
Faking the Design
Process
Alexei Khorev
The Classic Paper
David Parnas
Ideal Process
Analogy
Real Process
Rational Process
Why No Ideal?
What is in Rational?
Rational Structure?
Requirements
Module Structure
Module Interfaces
Module Relationships
Module Internals
Design Notebook
29.19
Design document and design notebook
Besides the design document:
It is also useful to record all of the design alternatives and a reason why
they were rejected.
We can call this record a design notebook — which is not the final
design — but it is a very useful adjunct to the design for the initial design
team and for the later maintainer.
If the design is only recorded as comments within the program code, this
aspect is easily lost.
