Software Design: History

1
Software DesignHistory
2
Overview

• To frame our discussion, consider
• What intellectual history of software
  development?
• How has the history of design practice influenced
  the development of methodologies and tools?
• How did the evolution of methodologies impact
  design problem solving?
• Where does design as an activity fit in the
  software process?

3
Outline

• Software Design
• Historical View
• Design Principles

4

• "The beginning of wisdom for a software
  engineer is to recognize the difference between
  getting a program to work, and getting it right."
  
• M. A. Jackson

5
Software Design

• What is the process? What are the activities?
• Goal
• Providing a model from which an implementation
  can be derived.
• Processes?
• Qualities?

6
(No Transcript)
7
Historical View (1)

• Pre 70s
• Ad Hoc - Programming any which way

8
Historical View (2)

• Early 70s Structured
• Top-down Programming
• Dijkstra, Levels of Abstraction
• Wirth, Stepwise Refinement
• Parnas, Information Hiding

9
Top-Down Design (1)

• An informal design strategy for breaking
  problems into smaller problems. It has the
  following objectives
• 1) To systematize the design process
• 2) To produce a modular program design
• 3) To provide a framework in which problem
  solving can more effectively proceed

10
Top-Down Design (2)

• Decomposition
• Break the original problem into a series of
  subproblems. We then derive a software
  architecture that provides components that solve
  one or more of the subproblems.
• Refinement
• Stepwise refinement - A top-down strategy
  (Wirth, 1971) where the architecture of the
  program is developed by successively refining
  levels of detail.

11
Top-Down Overview

• 1) A better approach that the ad hoc design
  methods in that it gave an organized way of
  attacking large problems.
• 2) Does not offer enough guidelines on how to
  subdivide a problem, when to stop subdividing, or
  how to measure the quality of a design.
• 3) It relies heavily on experience and judgment
  of the designer.
• 4) Appropriate for small, simple programs. It is
  too informal for large programs.

12
Historical View (3)

• Mid 70s Structured Design
• A composite of techniques, strategies, methods
  for designing software systems and programs. It
  provides a step-by-step procedure. It is a
  refinement of the top-down process.
• Yourdon/Constantine
• Jackson
• Warnier-Orr

13
Structured Design

• STEP 1 Draw Data Flow Diagram
• STEP 2 Draw Structure Chart
• STEP 3 Evaluate the Design
• STEP 4 Prepare for Implementation

14
Historical View (4)

• Late 70s Structured Analysis
• Gane and Sarson (SADT)
• Demarco

15
Note

• Tendency is to focus on issues of implementation
  early, then realize that front-end and back-end
  processes require attention.

16
Historical View (5)

• Early 80s
• Programming-in-the-large
• Formal Methods

17
Historical View (6)

• Late 80s
• Object-Oriented analysis and design

18
Historical View (7)

• Early 90s
• Design for Reuse

19
Historical View (8)

• Late 90s
• Component-based Systems
• Design Synthesis

20
Future?

• There is increasing pressure to view software
  design as an investment activity. Such a view
  forces the developers to deal with issues other
  than technical ones in choosing architecture,
  features, etc.
• See Barry W. Boehm and Keith J. Sullivan (2000)
  Software Economics A Roadmap. International
  Conference on Software Engineering.

21
Software Engineering Economics

• I have prepared a collection of papers related to
  software cost estimation, cost modeling, and
  economics. The url is http//www2.umassd.edu/SWPI
  /costmodeling/papers.html

22
Perspective

• Most of the methods developed assumed it was
  possible to conduct a problem decomposition
  beginning at a root node, and each level of the
  decomposition would be carried out systematically
  by elaborating only the next level.

23
Opportunistic Design

• Research with designers indicates a very
  different picture. The ability to conduct a
  decomposition in this manner seems to require
  prior experience in this particular application
  area.
• Compare domain experts/novice
• Compare experts/domain experts

24
Design Principles

• 1. Design process should not suffer from
  tunnel vision.
• 2. Design should provide traceability to the
  analysis model.
• 3. Design should not reinvent the wheel.
• 4. Design should be consistent with problem
  domain.
• 5. Design should exhibit uniformity
  integration.
• 6. Design should facilitate change.
• 7. Design should accommodate the unexpected.
• 8. Design is not coding!!!
• 9. Designs have qualities too!
• 10. Designs should be reviewed!