Software Design - History

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?

"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

Software Design

What is this activity?

Goal: Providing a model from which an implementation can be derived.

Processes? Qualities? Design in Context

1. External Design -- conceiving, planning out, and specifying the externally observable characteristics of a software product (displays, report formats, data sources and sinks, functional characteristics, performance requirements). This design process begins with analysis phase and continues into the design phase. External design is concerned with refining the requirements and establishing the high level structural view of the system.

2. Internal Design -- conceiving, planning out, and specifying the internal structure and processing details of the software product. The goals of internal design are to specify internal structure and processing details, to record design decisions and indicate why certain alternatives and tradeoffs were chosen, to elaborate the test plan, and to provide a blueprint for implementation, testing and maintenance activities.

2.1 Architectural Design -- is concerned with refining the conceptual view of the system, identifying internal processing functions, decomposing high-level functions into subfunctions, defining internal data streams and data stores, and establishing relationships and interconnections among functions, data streams, and data stores.

2.2 Detailed Design -- is concerned with the specification of algorithms that implement the functions, concrete data structures that implement the data stores, and the actual interconnection among functions and data structures.

Historical View

Pre 70s Ad Hoc

- programming any which way

Early 70s Structured Programming

Top-down Programming
Dijkstra, Levels of Abstraction
Wirth, Stepwise Refinement
Parnas, Information Hiding

Top-Down Design

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

Decomposition

Our approach to decomposition is to 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. Refinement is actually a process of elaboration. The process should proceed from a highly conceptual model (abstractions) to lower level details. Note that this involves a breadth-first view of a solution strategy.

Decision Making Principles:

1) Input, function, output should be specified for each module designed at each step.

2) Implementation details should not be addressed until late in the design process.

3) At each level, the function of a module should be explained by at most a single page of instructions or a single page diagram. At the top level, the overall design should be describable in approximately ten or fewer lines of instructions and/or calls to lower-level modules.

4) Data should receive as much design attention as processing procedure because interfaces between modules must be carefully specified..

Top-down Design 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.

Mid 70s Structured Design

Yourdon/Constantine

Jackson

Warnier-Orr

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.

STEP 1: Draw Data Flow Diagram
Represent the problem as the flow of data through a system.

STEP 2: Draw Structure Chart
Represent the program as a hierarchy of functional components. This is derived from the data flow diagram.

STEP 3: Evaluate the Design

STEP 4: Prepare the Design for Implementation
Divide logical design into physical implementation units (load Units).

Late 70s Structured Analysis

Demarco

Gane and Sarson (SADT)

Early 80s

Programming-in-the-large (Mary Shaw)
Formal Methods

Late 80s

Object-Oriented analysis and design

Early 90s

Design for Reuse

Late 90s

Component-based Systems

Design Principles

Pressman, p. 345

Design process should not suffer from tunnel vision.
Design should provide traceability to the analysis model.
Design should not reinvent the wheel.
Design should be consistent with problem domain.
Design should exhibit uniformity integration.
Design should facilitate change.
Design should accommodate the unexpected.
Design is not coding!!!
Designs have qualities too!
Designs should be reviewed!