Software Design Fundamentals

1
Software Design Fundamentals

• Introduction
• Design Principles

2
Agenda

• Deliverables
• Return Midterms
• SRSs still being graded
• Design Project assignments
• Design Review - Thursday, 11 November
• Software Design Fundamentals Lecture

3
Software Design

• General definition of design
• the process of applying various techniques and
  principles for the purpose of defining a device,
  a process, or a system in sufficient detail to
  permit its physical realization.
• Goal
• To produce a model or representation that will
  later be built
• Engineering or Art?

4
Software Design Model
Information model
Functional model
Behavioral model
Data design
Design
Architectural design
Code
Other requirements
Integrated validated software
Procedural design
Program modules
Test
5
General Design Guidelines

• Exhibit a hierarchical organization that make
  intelligent use of control among components
• Logically partitioned into components that
  perform specific tasks and subtasks
• Distinct representation of data and procedure
• Lead to interfaces that reduce complexity
• Derived using a repeatable method driven by
  information gathered during requirements

6
Data Design
The primary activity during data design is to
select logical representations of data objects
identified during the requirements definition and
specification phase. The selection process may
involve algorithmic analysis of alternative
structures in order to determine the most
efficient design or may simply involve the use of
a set of modules that provide the operations
upon some representation of an object. Wasserman

• Identify the program modules that operate upon
  the logical data structures
• Data design leads to better program structure,
  effective modularity, reduced complexity

7
Data Specification Principles

• Apply functional analysis principles to data
• Identify all data structures and associated
  operations
• Establish a data dictionary to define data
  program design
• Defer low-level data design decisions
• Representation of data structure should only be
  known to modules with direct use of data within
  the structure
• Develop a library of useful data structures
• Language should support abstract data types

8
Architectural Design

• Objective is to develop a modular program
  structure and represent the control relationships
  between modules
• Combines program and data structure by defining
  interfaces that allows data to flow throughout
  the program
• Holistic view of software

9
Procedural Design

• After data program structure have been
  established, becomes necessary to specify
  procedural detail without ambiguity
• Design Notations
• Structured programming
• Graphical design notation
• Tabular design notation
• Program design language (PDL)

10
Software Design Fundamentals

• Good design is not accomplished by chance

The beginning of wisdom for a computer
programmer is to recognize the difference between
getting a program to work, and getting it right.
Jackson

• Fundamental concepts provide the framework for
  getting it right

11
Design Fundamentals

• Abstraction
• Refinement
• Modularity
• Software Architecture
• Control Hierarchy
• Data Structure
• Software Procedure
• Information Hiding

12
Design Fundamentals

• Abstraction
• Levels of detail/language used to describe a
  problem

notion of abstraction permits one to
concentrate on a problem at some level of
generalization without regard to irrelevant low
level details use of abstraction also permits
one to work with concepts and terms that are
familiar in the problem environment
Wasserman

• Types of abstractions

13
Design Fundamentals (cont.)

• Refinement
• Top-down strategy

In each step, one or several instructions of the
given program are decomposed into more detailed
instructions. This successive decomposition or
refinement of specification terminates when all
instructions are expressed in terms of any
underlying computer or programming language.
Wirth

• Modularity
• Divide software into separate components that are
  integrated to solve problem requirements

14
Design Fundamentals (cont.)

• Software Architecture
• The hierarchical structure of procedural
  components the structure of data
• Transition between analysis and design
• Control Hierarchy/Program Structure
• Organization of modules that implies a hierarchy
  of control
• Metrics - depth, width, fan-out, fan-in
• Visibility connectivity

15
Control Hierarchy
16
Design Fundamentals (cont.)

• Data Structure
• Logical representation of the relationship among
  individual data elements
• Scalar, sequential vector, array, linked list,
  hierarchical data structure
• Software Procedure
• Processing details of each module
• Precise specification includes sequence of
  events, decision points, repetitive operations,
  data organization

17
Design Fundamentals (cont.)

• Information Hiding
• Modules should be characterized by design
  decisions that each hides from all others
• Modules are designed so that information within a
  module is inaccessible to other modules with no
  need for the information
• Defines and enforces access constraints

18
Modular Design

• Benefits
• Reduces complexity
• Facilitates change
• Easier implementation afforded by parallel
  development
• Activation Mechanisms
• Pattern of Control

19
Functional Independence
Design software so that each module addresses a
specific sub-function of requirements and has a
simple interface when viewed from other parts of
the program structure

• Benefits
• Easier to develop
• Easier to maintain test
• Measures of Independence
• Cohesion
• Coupling

20
Cohesion

• A cohesive module should do just one thing.
• Levels of Cohesion
• Coincidental
• Logical
• Temporal
• Procedural
• Communicational
• Sequential
• Functional

21
Coupling

• Measure of interconnection among modules
• Levels of Coupling
• No direct coupling
• Data coupling
• Stamp coupling
• Control coupling
• External coupling
• Common coupling
• Content coupling

22
Coming Up Next...

• Deliverables
• Design Review
• Homework 2 - Tuesday, 9 November 1999
• Due Thursday, 11 November 1999
• Homework 3 - Tuesday, 16 November 1999
• Design Document
• Due Thursday, 18 November 1999
• Lecture Software Architecture Structured
  Software Design