Title: Software Design
1Software Design
Introduction
Material drawn from Godfrey96,Parnas86,Parnas94
2Software Design
- How to implement the what.
- Requirements Document (RD) is starting point.
- Software design is a highly-creative activity.
- Good designers are worth their weight in gold!
- Highly sought after, head-hunted, well-paid.
- Experience alone is not enough
- creativity, vision, all-around brilliance
required.
3Software Design (Contd)
- Some consider software design to be a black
art - difficult to prescribe how to do it
- hard to measure a good design objectively
- I know a good design when I see it.
4Requirements EngineeringAn Overview
- Basic goal To understand the problem as
perceived by the user. - Activities of RE are problem oriented.
- Focus on what, not how
- Dont cloud the RD with unnecessary detail
- Dont pre-constrain design.
- After RE is done, do software design
- solution oriented
- how to implement the what
5Requirements EngineeringAn Overview
- Key to RE is good communication between customer
and developers. - Work from Requirements Document as guide.
6Requirements Engineering
- Basically, its the process of determining and
establishing the precise expectations of the
customer about the proposed software system.
7The Two Kinds of Requirements
- Functional The precise tasks or functions the
system is to perform. - e.g., details of a flight reservation system
- Non-functional Usually, a constraint of some
kind on the system or its construction - e.g., expected performance and memory
requirements, process model used, implementation
language and platform, compatibility with other
tools, deadlines, ...
8The Purpose of RE
- Raw user requirements are often
- vague
- contradictory
- impractical or impossible to implement
- overly concrete
- just plain wrong
- The purpose of RE is to get a usable set of
requirements from which the system may be
designed and implemented, with minimal
surprises.
9The RE Process
Requirements Analysis
leads to
Requirements Definition
produces
Requirements Specification
Software Specification
included in
10The Requirements Document
- The official statement of what is required of the
system developers. - Includes system models, requirements definition,
and requirements specification. - Not a design document.
- States functional and non-functional
requirements. - Serves as a reference document for maintenance.
11Requirements Document Requirements
- Should be easy to change as requirements evolve.
- Must be kept up-to-date as system changes.
12The Requirements Document Should State ...
- Foreseen problems
- wont support Win-3.x apps
- Expected evolution
- will port to MacOS in next version
- Response to unexpected events/usage
- if input data in old format, will auto-convert
13Requirements Document Structure
- Introduction (describe need for system)
- Functional Requirements
- Non-Functional Requirements
- System Evolution (describe anticipated changes)
- Glossary (technical and/or new jargon)
- Appendices
- Index
14A Story ...
Dear Mr. Architect, Please design and build me a
house. I am not quite sure of what I need, so
you should use your discretion. My house should
have between two and forty-five bedrooms. Just
make sure the plans are such that bedrooms can be
easily added or deleted. When you bring the
blueprints to me, I will make the final decision
of what I want. Also bring me the cost breakdown
for each configuration so that I can arbitrarily
pick one.
15A Story (Contd)
Keep in mind that the house I ultimately chose
must cost less than the one I am currently living
in. Make sure, however, that you correct all the
deficiencies that currently exist in my house
(the floor of my kitchen vibrates when I walk
across it, and the walls dont have nearly enough
insulation in them). Also keep in mind as you
design this house that I wish to keep
yearly maintenance cost as low as possible. This
should mean the incorporation of extra-cost
features like aluminum or vinyl siding. If you
chose not to specify aluminum, be prepared to
explain in detail.
16A Story (Contd)
Please take care that modern design practices and
the latest materials are used in construction of
the house. The house should be really
nice. However, be alerted that the kitchen should
be designed to accommodate among other things, my
1952 Gibson refrigerator. To assure that you are
building the correct house for our family,
make sure that you contact each of the children
and also the in-laws. My mother-in-law will have
very strong feelings about how the house ought to
be designed since she visits with us at least
once a year. Make sure that you weigh all these
options carefully and make the right decision. I,
however, retain the right to override any
decision you come up with.
17A Story (Contd)
Please dont bother me with small details right
now. Your job is to develop the overall plans
for this house. Get the big picture. It is not
appropriate at this time to be choosing the color
of the carpet. However, keep in mind that my wife
likes green. Also do not worry at this time
about acquiring resources to build this house.
Your first priority is to develop detailed plans
and specifications. However, once I accept these
plans, I will expect to have the house under roof
within 48 hours.
18A Story (Contd)
While you are designing this house specifically
for me, keep in mind that sooner or later I will
have to sell this house. It should have appeal
to potential buyers. Please make sure that
before you finalize the plans, there is a
consensus of the population in my area that
they like the features this house has. You are
advised to run up and look at my neighbors house
he had constructed last year. We like it a great
deal. It has many features that we would like to
have in our new home, particularly the
75-foot swimming pool. With careful engineering
I believe that you can design this into our new
house without impacting the construction cost.
19A Story (Contd)
Please prepare a complete set of blueprints. It
is not necessary at this time to do the real
design since these blueprints will be used
only for construction bids. Please be advised
however, that any increase of cost in the future
as a result of design changes will result in
you getting your hands slapped. You must be
thrilled to be working on such an interesting
project such as this. To be able to use new
kinds of construction and to be given such
freedom in your designs is something that doesnt
happen very often. Contact me as rapidly as
possible with your design ideas. I am
enthusiastic about seeing what you can come up
with.
20A Story (Contd)
P.S. My wife has just told me that she disagrees
with many on the instructions Ive given
you in this letter. As architect it is
your responsibility to resolve these issues. I
have tried in the past and have been
unable to accomplish this. If you cant handle
this, Ill have to look for a new
architect. P.P.S. Perhaps what I need is not a
house at all, but a travel trailer.
Please advise me as early as possible if that is
the case.
21RE Summary
- RE focuses on determining what the customer
wants, and not how it will be implemented. - RE is hard to get correct it requires good
communication skills. - Requirements may change over time.
- RE requires iteration.
22RE Summary (Contd)
- The customer often doesnt have good grasp of
what he wants. - Errors made at the requirements stage are very
expensive to fix later. - You might well implement the stated requirements
correctly, but it wont be the system the
customer really wants.
23Back to Software Design ...
24High-Level (abstract) design
Low-Level (detailed) design
25Top-Down vs Bottom-Up Design
- Top-down Design
- Start with a coarsely-grained view of system, and
repeatedly refine components until you have
concrete sub-components. - Bottom-up Design
- Start with existing components and glue them
together to get what you want.
26Top-Down vs Bottom-Up Design (Contd)
- Top-down is the ideal of most design methods,
but its rarely followed absolutely - some branches of development are expanded before
others are even started - doesnt adequately account for reuse of existing
components - COTS products, libraries, previous versions of
the same system.
27Design Quality
- Software design quality, as with other ideas on
quality, is an elusive concept - It depends on priorities of your company and the
customers - fastest to implement
- easiest to implement
- easiest to maintain, evolve, port
- most efficient/reliable/robust end-product.
28Discussion
- What does quality mean to
- IBM?
- Microsoft?
- Netscape?
- FAA?
- IRS?
- Intel?
- ...
29Some Desirable Design Attributes
- Hierarchical A good design should be organized
into a well-designed hierarchy of components. - Modular Separate distinct concerns (data and
processing) into distinct containers (i.e.,
subsystems, modules, and/or classes). Hide
implementation details and provide clean, simple
interfaces for each container.
30Some Desirable Design Attributes (Contd)
- Independent Group similar things together limit
the amount of special knowledge that unrelated
components may share. If you change your mind
about something, the impact will be localized.
31Some Desirable Design Attributes (Contd)
- Simple Interfaces Endless flexibility adds
complexity. Complex interfaces mean - hard to understand by users and developers (e.g.,
Unix man page syndrome) - many possible variations of use
- inconvenient to change interface in order to
eliminate bad options. - You can get away with flexible interfaces in a
low-level localized setting, but the larger the
scale, the simpler the interface should be.
32A Rational Design ProcessHow and Why to Fake it
Many have sought a software design process that
allows a program to be derived systematically
from a precise statement of requirements.
although we will not succeed in designing a
real product that way, we can produce
documentation that makes it appear that the
software was designed by such a process
D. L. Parnas
33RDP - Faking It
- The rational design process is an irrational
ideal. - Question If we rarely act in a purely top-down
way when we develop software, why do most design
methods assume we do? - Possible answers
- Its simpler than trying to model real-life.
- Wide variation in problems, possible solutions.
- There is utility in the structure of the process,
and its ongoing documentation.
34RPD Payoff
The real payoff comes during maintenance and
the next time around.
35The Role of Documentation
- Documentation plays a major role in the
development of any large, long-lived software
system BUT poor documentation is a monumental,
ubiquitous problem. - Most programmers regard documentation as a
necessary evil, written as an afterthought only
because some bureaucrat requires it. They do not
expect it to be useful. - This attitude is a self-fulfilling prophecy!
36The Role of Documentation (Contd)
- While most documents are incomplete and
inaccurate, these problems can be fixed easily.
More serious problems are - Poor organization.
- Boring, redundant, verbose prose
- Boredom leads to inattentive reading and
undiscovered errors. - Confusing and inconsistent terminology.
- Myopia, cant see the forest through the trees.
- Focus is on documenting small details rather than
on important design decisions.
37So Whats to be Done?
- Look at the various stages of the Rational
Design Process, and consider the documents that
are to be produced at each step. - Even if you dont follow the steps in that order,
go back and fill in the blanks! Pretend that you
did follow the process precisely. - It isnt just a paper trail youre creating.
38Programs vs Proofs
- Designing a software system is a lot like proving
a mathematical theorem. - The construction of an original proof is a
painful process you make lots of mistakes,
pursue bad paths, ... - However, once youve figured out how to get
there, you clean up the proof and present it as
if no mistakes had ever been made.
39Programs vs Proofs
- If you want to prove a similar but different
theorem, you can re-use ideas from the first
proof! - The main difference is that during software
development, you also record why you chose each
path, what alternatives were considered, and why
other paths were not chosen.
40Software Aging
Programs, like people, get old. We cant
prevent aging, but we can understand its
causes, take steps to limit its effects,
temporarily reverse some of the damage it has
caused, and prepare for the day when the
software is no longer viable. ... (We must) lose
our preoccupation with the first release and
focus on the long term health of our
products. D.L. Parnas
41Software Aging?
- It does not make sense to talk about software
aging! - Software is a mathematical product, mathematics
does not decay with time. - If a theorem was correct 200 years ago, it will
be correct tomorrow. - If a program is correct today, it will be correct
100 years from now. - If a program is wrong 100 years from now, it must
have been wrong when it was written. - All of the above statements are true, but not
really relevant.
42Software Does Age
- Software aging is gaining in significance
because - of the growing economic importance of software,
- software is the capital of many high-tech firms.
43Software Does Age
- The authors and owners of new software products
often look at aging software with disdain. - If only the software had been designed using
todays languages and techniques - Like a young jogger scoffing at an 86 year old
man (ex-champion swimmer) and saying that he
should have exercised more in his youth!
44The Causes of Software Aging
- There are two types of software aging
- Lack of Movement Aging caused by the failure of
the products owners to modify it to meet
changing needs. - Ignorant Surgery Aging caused as a result of
changes that are made. - This one-two punch can lead to rapid decline in
the value of a software product.
45Lack of Movement
- Unless software is frequently updated, its users
will become dissatisfied and change to a new
product. - Excellent software developed in the 60s would
work perfectly well today, but nobody would use
it. - That software has aged even though nobody has
touched it. - Actually, it has aged because nobody bothered to
touch it.
46Ignorant Surgery
- One must upgrade software to prevent aging.
- Changing software can cause aging too.
- Changes are made by people who do not understand
the software. - Hence, software structure degrades.
47Ignorant Surgery (Contd)
- After many such changes nobody understands the
software - the original designers no longer understand the
modified software, - those who made the modification still do not
understand the software. - Changes take longer and introduce new bugs.
- Inconsistent and inaccurate documentation makes
changing the software harder to do.
48The Cost of Software Failure
- Inability to keep up,
- reduced performance,
- decreasing reliability.
49Inability To Keep Up
- As software ages, it grows bigger.
- Weight gain is a result of the fact that the
easiest way to add a feature is to add new code. - Changes become more difficult as the size of the
software increases because - There is more code to change,
- it is more difficult to find the routines that
must be changed. - Result Customers switch to a younger product
to get the new features.
50Reduced Performance
- As the size of the program grows, it places more
demands on the computer memory. - Customers must upgrade their computers to get
acceptable response. - Performance decreases because of poor design that
has resulted from long-term ad hoc maintenance. - A younger product will run faster and use less
memory because it was designed to support the new
features.
51Decreasing Reliability
- As the software is maintained, errors are
introduced. - Many studies have shown that each time an attempt
is made to decrease the failure rate of a system,
the failure rate got worse! - That means that, on average, more than one error
is introduced for every repaired error.
52Decreasing Reliability (Contd)
- Often the choice is to either
- abandon the project
- stop fixing bugs
- For a commercial product, Parnas was once told
that the list of known unrepaired bugs exceeded
2,000.
53Reducing the Cost of SW Aging
- We should be looking far beyond the first release
to the time when the product is old. - Inexperienced programmers get a rush after the
first successful compile or demonstration. - Experienced programmers realize that this is only
the beginning ...
54Reducing the Cost of SW Aging (Contd)
- Responsible, professional, organizations realize
that more work is invested between the time after
the first successful run and the first release
than is required to get the first successful run. - Extensive testing and rigorous reviews are
necessary.
55Preventive Medicine
- Design for success
- Keep records (documentation)
- Seek second opinions (reviews)
56Design for Success
- Design for change.
- This principle is known by various names
- information hiding
- abstraction
- separation of concerns
- data hiding
- object-orientation
57Design for Change
- To apply this principle one begins by trying to
characterize the changes that are likely to occur
over the lifetime of a product. - Since actual changes cannot be predicted,
predictions will be about classes of changes - changes in the UI
- change to a new windowing system
- changes to data representation
- porting to a new operating system ...
58Design for Change (Contd)
- Since it is impossible to make everything equally
easy to change, it is important to - estimate the probabilities of each type of change
- organize the software so that the items that are
most likely to change are confined to a small
amount of code
59Why is Design for Change Ignored?
- Textbooks fail to discuss the process of
estimating the probability of change for various
classes of changes. - Programmers are impatient because they are too
eager to get the first version working. - Designs that result from this principle are
different from the natural designs of the
programmers intuition.
60Why is Design for Change Ignored? (Contd)
- Few good examples of the application of the
principle. Designers tend to mimic other designs
they have seen. - Programmers tend to confuse design principles
with languages. - Many practitioners lack training in software
development.
61Keeping Records (Documentation)
- Even when software is well designed, it is often
not documented. - When documentation is present it is often
- poorly organized
- inconsistent
- incomplete
- written by people who do not understand the system
62Documentation
- Hence, documentation is ignored by maintainers.
- Worse, documentation is ignored by managers
because it does not speed up the initial release.
63Second Opinions (Reviews)
- In engineering, as in medicine, the need for
reviews by other professionals is never
questioned. - In designing a building, ship, aircraft, there is
always a series of design documents that are
carefully reviewed by others.
64Reviews
- This is not true in the software industry
- Many programmers have no professional training in
software at all. - Emphasis of CS degrees on mathematics and
science professional discipline is not a topic
for a liberal education. - Difficult to find people who can serve as quality
reviewers no money to hire outsiders. - Time pressure misleads designers into thinking
that they have no time for proper reviews. - Many programmers resent the idea of being
reviewed.
65Reviews
- Every design should be reviewed and approved by
someone whose responsibilities are for the
long-term future of the product.
66Why is Software Aging Inevitable?
- Our ability to design for change depends on our
ability to predict the future. - We can do so only approximately and imperfectly.
- Over a period of years
- changes that violate original assumptions will be
made - documentation will never be perfect
- reviewers are bound to miss flaws ...
67Why is Software Aging Inevitable? (Contd)
- Preventive measures are worthwhile but anyone who
thinks that this will eliminate aging is living
in a dream world.
68Software Geriatrics
- Retroactive Documentation
- A major step in slowing the age of older
software, and often rejuvenating it, is to
upgrade the quality of the documentation. - Retroactive Modularization
- Change structure so that each module hides a
design decision that is likely to change.
69Software Geriatrics (Contd)
- Amputation
- A section of code has been modified so often, and
so thoughtlessly, that it is not worth saving. - Major Surgery (Restructuring)
- Identify and eliminate redundant components and
gratuitous dependencies.
70Planning Ahead
- Its time to stop acting as if getting it to
run was the only thing that matters. - Designs and changes have to be documented and
carefully reviewed. - If its not documented, its not done.
- In other areas of engineering, product
obsolescence is recognized and included in design
and marketing plans. - The same should be done for software engineering.
71References
- Godfrey96 M. W. Godfrey class lecture notes in
Software Engineering. - Parnas86 D. L. Parnas, P. C. Clements, A
Rational Design Process, How and Why to Fake It,
IEEE TSE, Vol 12, No 2, 1986. - Parnas94 D. L. Parnas, Software Aging (plenary
talk), ICSE, May, 1994.