Definition: (verb) Design is a problem solving process whose goal is to find and describe a way to implement a system's functional requirements subject to the contraints of the non-functional and other requirements.
Definition: (noun) "Design is a meaningful engineering representation of something that is to be built."

Example: A blueprint for a house is the classic example of an architectural design.

Why do we need design? Imagine trying to build a house without a blueprint. We need design to create a quality product. Design avoids confusion and errors.

Unfortunately, often software development proceeds without adequate design, using a "house of cards" approach. The result is fragile, unstable, inflexible, error prone software.

What you need to know about design:

• General design approaches and history
• The four components of a design
• Three design principles: Decomposition, Abstraction, Information Hiding
  
• Design Methods (in a nutshell): Functional and Object Oriented
• Know how to choose between OO approach and Functional approach
• Design Quality: How to know if you have a good design
Quality Factors and Tradeoffs
Assessing Decomposition
Quality Metrics and an OO Quality Metrics Tool
Example QA Checklists: High Level Design and Detailed Design
• Examples and Case Studies: Traffic Jam andATM Simulator
• Practice Problems

• How to apply a specific design method: Functional Design
• How to apply a specific design method: Object Oriented Design
• How to express your Functional design: Structure Charts
• How to express your OO design: UML notation for class diagrams
• Hybrid design method

Design Rationale Documentation

• Template for writing a Design Rationale

General software design approaches and history

Each has many specific methodologies, but the most prominent are:

• Structured Design (functional)
• Unified Modeling Language - UML (object oriented)

• A functional approach answers "Do algorithms first"
  
• An object oriented approach answers "Do data first"

Historically, functional approaches came first.  The reasons are:

• Requirements are stated as functions, so functional design is an obvious transition from requirements.
• Computer Architectures are functional, so early languages were functional, and lend themselves to functional designs.

OOD is the "new kid" on the block, and it gets a lot of hype.  It solves some of the limitations of the functional approach, but introduces others limitations of its own. 

Design approaches in a nutshell

If you ever wrote a C program as one big main program with all global data, you were doing functional design (but poorly).
 

Know how to choose between OO approach and Functional approach.

Four components of a design

Architectural design defines the structure and relationships among major elements of the software. The architecture is the framework of the solution, often comprised of "design patterns." Examples: Class Diagram, Module hierarchy chart (structure chart). "Architecture" when used to describe large systems describes the major subsystems and their relationships like client-server or peer-to-peer. When used within a subsystem "architecture" is a class diagram.

Interface design describes how the elements of the design will communicate with each other. It describes the "protocols" or "contracts" that allow elements of the design to request services of each other. Examples: C++ header file, Ada spec file, Java interface. In OO design, this component is called Class Skeletons. In a large system design, it means a communication protocol.

Procedural design describes how the functional aspects of the software will work. It describes the logic and control structures for the operations in the design. It's the algorithms for each element in the solution. Examples: pseudocode, flowcharts,  sequence diagrams, n-s charts.

Data design describes the data structures which will store the information used in the solution.

Usually each component has its own representation or notation, but sometimes they are combined.
In a large system, this would include database design.  
 

Design Principles

Decomposition

Decomposition is the primary tool for attacking large problems, by using a "Divide and conquer" strategy.

It helps us several ways:

• Allows for distribution of effort via parallel development.
• Makes testing easier by isolating errors
• Promotes reuse.
• Localizes changes for easier maintenance.
• Makes the solution simpler to comprehend

Abstraction

Abstraction is a tool for coping with complexity. If you find yourself feeling like there's too many things to keep in your head at once, then invent an abstraction.

It helps us several ways:

• It simplifies a design by hiding low level details and keeping the emphasis on the main features of the solution.
• It promotes implementation independence, meaning we can change the implementation (low level) without affecting the entire system (at a high level).
• It simplifies our thinking by allowing us to focus on the problem domain and defer the details of the implementation until later.
• It reduces errors by reducing the number of details we need to hold in short-term memory.

Information Hiding