software design l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Design PowerPoint Presentation
Download Presentation
Software Design

Loading in 2 Seconds...

play fullscreen
1 / 71

Software Design - PowerPoint PPT Presentation


  • 119 Views
  • Uploaded on

Software Design. Introduction. Material drawn from [Godfrey96,Parnas86,Parnas94]. Software 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!

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Design' - metta


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software design
Software Design

Introduction

Material drawn from [Godfrey96,Parnas86,Parnas94]

Software Design (Introduction)

software design2
Software 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.

Software Design (Introduction)

software design cont d
Software Design (Cont’d)
  • 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.”

Software Design (Introduction)

requirements engineering an overview
Requirements Engineering:An Overview
  • Basic goal: To understand the problem as perceived by the user.
  • Activities of RE are problem oriented.
    • Focus on what, not how
    • Don’t cloud the RD with unnecessary detail
    • Don’t pre-constrain design.
  • After RE is done, do software design:
    • solution oriented
    • how to implement the what

Software Design (Introduction)

requirements engineering an overview5
Requirements Engineering:An Overview
  • Key to RE is good communication between customer and developers.
  • Work from Requirements Document as guide.

Software Design (Introduction)

requirements engineering
Requirements Engineering
  • Basically, it’s the process of determining and establishing the precise expectations of the customer about the proposed software system.

Software Design (Introduction)

the two kinds of requirements
The 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, ...

Software Design (Introduction)

the purpose of re
The 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”.

Software Design (Introduction)

the re process

System

Models

Requirements

Definition

Requirements

Specification

Requirements

Document

Software

Specification

Requirements

Analysis

The RE Process

leads to

Requirements

Definition

produces

Requirements

Specification

Software

Specification

included in

Software Design (Introduction)

the requirements document
The 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.

Software Design (Introduction)

requirements document requirements
Requirements Document “Requirements”
  • Should be easy to change as requirements evolve.
  • Must be kept up-to-date as system changes.

Software Design (Introduction)

the requirements document should state
The Requirements Document Should State ...
  • Foreseen problems:
    • “won’t 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”

Software Design (Introduction)

requirements document structure
Requirements 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

Software Design (Introduction)

a story
A 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.

Software Design (Introduction)

a story cont d
A Story … (Cont’d)

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 don’t 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.

Software Design (Introduction)

a story cont d16
A Story … (Cont’d)

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.

Software Design (Introduction)

a story cont d17
A Story … (Cont’d)

Please don’t 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.

Software Design (Introduction)

a story cont d18
A Story … (Cont’d)

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 neighbor’s 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.

Software Design (Introduction)

a story cont d19
A Story … (Cont’d)

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 doesn’t happen very

often. Contact me as rapidly as possible with your design ideas.

I am enthusiastic about seeing what you can come up with.

Software Design (Introduction)

a story cont d20
A Story … (Cont’d)

P.S. My wife has just told me that she disagrees with many on the

instructions I’ve 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 can’t handle

this, I’ll 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.

Software Design (Introduction)

re summary
RE 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.

Software Design (Introduction)

re summary cont d
RE Summary (Cont’d)
  • The customer often doesn’t 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 won’t be the system the customer really wants.

Software Design (Introduction)

back to software design
Back to Software Design ...

Software Design (Introduction)

slide24

Software

architecture

Subsystem

decomposition

Subsystem

dependencies

Subsystem

interfaces

module or class

decomposition

module or class

dependencies

module or class

interfaces

Data structures

Algorithms

High-Level

(abstract)

design

Low-Level

(detailed)

design

Software Design (Introduction)

top down vs bottom up design
Top-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.

Software Design (Introduction)

top down vs bottom up design cont d
Top-Down vs Bottom-Up Design (Cont’d)
  • Top-down is the “ideal” of most design methods, but it’s rarely followed absolutely:
    • some branches of development are expanded before others are even started
    • doesn’t adequately account for reuse of existing components:
      • COTS products, libraries, previous versions of the same system.

Software Design (Introduction)

design quality
Design 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.

Software Design (Introduction)

discussion
Discussion
  • What does “quality” mean to:
    • IBM?
    • Microsoft?
    • Netscape?
    • FAA?
    • IRS?
    • Intel?
    • ...

Software Design (Introduction)

some desirable design attributes
Some 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.

Software Design (Introduction)

some desirable design attributes cont d
Some Desirable Design Attributes (Cont’d)
  • 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.

Software Design (Introduction)

some desirable design attributes cont d31
Some Desirable Design Attributes (Cont’d)
  • 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.

Software Design (Introduction)

a rational design process how and why to fake it
A Rational Design Process:How 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

Software Design (Introduction)

rdp faking it
RDP - “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:
    • It’s 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.

Software Design (Introduction)

rpd payoff
RPD Payoff

The real payoff comes during maintenance

and “the next time around”.

Software Design (Introduction)

the role of documentation
The 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!

Software Design (Introduction)

the role of documentation cont d
The Role of Documentation (Cont’d)
  • 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”, can’t see the forest through the trees.
      • Focus is on documenting small details rather than on important design decisions.

Software Design (Introduction)

so what s to be done
So What’s 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 don’t follow the steps in that order, go back and fill in the blanks! Pretend that you did follow the process precisely.
  • It isn’t just a paper trail you’re creating.

Software Design (Introduction)

programs vs proofs
Programs 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 you’ve figured out how to get there, you clean up the proof and present it as if no mistakes had ever been made.

Software Design (Introduction)

programs vs proofs39
Programs 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.

Software Design (Introduction)

software aging
Software Aging

“Programs, like people, get old. We can’t 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

Software Design (Introduction)

software aging41
Software “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.

Software Design (Introduction)

software does age
Software 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.

Software Design (Introduction)

software does age43
Software 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 today’s 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!

Software Design (Introduction)

the causes of software aging
The Causes of Software Aging
  • There are two types of software aging:
    • Lack of Movement: Aging caused by the failure of the product’s 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.

Software Design (Introduction)

lack of movement
Lack of Movement
  • Unless software is frequently updated, its user’s will become dissatisfied and change to a new product.
  • Excellent software developed in the 60’s 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.

Software Design (Introduction)

ignorant surgery
Ignorant 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.

Software Design (Introduction)

ignorant surgery cont d
Ignorant Surgery (Cont’d)
  • 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.

Software Design (Introduction)

the cost of software failure
The Cost of Software Failure
  • Inability to keep up,
  • reduced performance,
  • decreasing reliability.

Software Design (Introduction)

inability to keep up
Inability 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.

Software Design (Introduction)

reduced performance
Reduced 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.

Software Design (Introduction)

decreasing reliability
Decreasing 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.

Software Design (Introduction)

decreasing reliability cont d
Decreasing Reliability (Cont’d)
  • 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.

Software Design (Introduction)

reducing the cost of sw aging
Reducing 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 ...

Software Design (Introduction)

reducing the cost of sw aging cont d
Reducing the Cost of SW Aging (Cont’d)
  • 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.

Software Design (Introduction)

preventive medicine
Preventive Medicine
  • Design for success
  • Keep records (documentation)
  • Seek second opinions (reviews)

Software Design (Introduction)

design for success
Design for Success
  • Design for change.
  • This principle is known by various names:
    • information hiding
    • abstraction
    • separation of concerns
    • data hiding
    • object-orientation

Software Design (Introduction)

design for change
Design 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 ...

Software Design (Introduction)

design for change cont d
Design for Change (Cont’d)
  • 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

Software Design (Introduction)

why is design for change ignored
Why 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 programmer’s intuition.

Software Design (Introduction)

why is design for change ignored cont d
Why is Design for Change Ignored? (Cont’d)
  • 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.

Software Design (Introduction)

keeping records documentation
Keeping 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

Software Design (Introduction)

documentation
Documentation
  • Hence, documentation is ignored by maintainers.
  • Worse, documentation is ignored by managers because it does not speed up the initial release.

Software Design (Introduction)

second opinions reviews
Second 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.

Software Design (Introduction)

reviews
Reviews
  • 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.

Software Design (Introduction)

reviews65
Reviews
  • Every design should be reviewed and approved by someone whose responsibilities are for the long-term future of the product.

Software Design (Introduction)

why is software aging inevitable
Why 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 ...

Software Design (Introduction)

why is software aging inevitable cont d
Why is Software Aging Inevitable? (Cont’d)
  • Preventive measures are worthwhile but anyone who thinks that this will eliminate aging is living in a dream world.

Software Design (Introduction)

software geriatrics
Software 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.

Software Design (Introduction)

software geriatrics cont d
Software Geriatrics (Cont’d)
  • 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.

Software Design (Introduction)

planning ahead
Planning Ahead
  • It’s 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 it’s not documented, it’s 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.

Software Design (Introduction)

references
References
  • [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.

Software Design (Introduction)