Engineering Design Principles

Engineering Design Principles
Evaluating Software Engineering Designs

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Overview

Rationale
Qualitative Goals
The Fundamental Principle
Other Engineering Design Principles

Rationale

Problem Solving:
- Several alternative designs should/will be developed
- The different alternative designs must be evaluated
Evaluation of Alternative Designs:
- The evaluation involves quantitative and/or qualitative "measures" of quality
The Purpose of Design Principles:
- Produce higher-quality designs

The Fundamental Principle of Software Engineering Design

The Principle:
- Designs should be modular
The Rationale:
- Understanding is inversely proportional to scope/scale (due, in part, to human memory limitations of 7 $\pm$ 2 "chunks")
- Small (and simple) components are easier to debug and fix than large (and complex) components
- Reusability is inversely proportional to scope/scale
- Systems constructed from small (and simple) components are more portable

Modular Designs: Things to Think About

Decomposability:
- Do the modules aid in decomposition (i.e., top-down development)?
Composability:
- Do the modules aid the constructions of new systems (i.e., bottom-up development)?
Continuity:
- Do the modules "localize" small changes?
Protection:
- Do the modules confine problems?

Some Other Software Engineering Design Principles

Standardization
Simplicity
Elegance/Beauty

Standardization

The Principle:
- Use standard designs, algorithms, data structures, and documentation practices if possible
The Rationale:
- Easier to understand and use
- More likely to be re-used
- More likely to be portable

Simplicity

The Principle:
- Occam's Razor (i.e., simpler designs are better)
The Rationale:
- Easier to understand and use
- More likely to be re-used
To Think About:
- Have I developed a complex solution to a simple problem?

Elegance/Beauty

The Principle:
- Elegance matters
The Rationale:
- Elegant modules are more likely to be re-used
- Elegance is usually directly proportional to clarity

Engineering Design Practices

Information Hiding
Coupling
Cohesion

Information Hiding

The Practice:
- Hide the internal details of a component from all other components
The Rationale:
- Prevents damage from errant external code
- Makes components easier to understand/use
- Simplifies modification and repair
- Facilitates re-use

Information Hiding (cont.)

Examples of Private Information:
- Local variables, data types, and data structures
- Internal flow of control
- Algorithms
Examples of Public Information:
- Interface information (inputs and outputs)
- Behavior/Functionality
- Errors and exceptions

Coupling

The Practice:
- Minimize the coupling (i.e., the amount of communication/interaction) between modules
The Rationale:
- Strongly coupled modules are difficult to change
- Strongly coupled modules are difficult to debug
- Weakly coupled/decoupled modules are easier to understand
- Weakly coupled/decoupled modules are more likely to be re-used

Coupling (cont.)

Techniques:
- Information hiding decreases coupling
- The use of global entities increases coupling
- Modules that communicate complex data structures are more tightly coupled
To Think About:
- Could I use module A elsewhere without module B?

Some Kinds of Coupling

Direct Coupling:
- Modules share variables
Common Coupling:
- Modules share "global"/"common" variables
Import/Export Coupling:
- Modules only share variables/operations that are explicitly "exported"

Cohesion

The Practice:
- Make the parts of a module closely related to each other.
The Rationale:
- Highly cohesive modules are easier to understand (like a well-written paragraph) and document
- Separation of (Orthogonal) Concerns

Cohesion (cont.)

Techniques:
- Separate input, input validation, calculations, and output
- Modules should not cross levels of abstraction
- Design modules that relate to real-world entities
To Think About:
- Does this module have a single, clear responsibility?

Kinds of Cohesion

Coincidental Cohesion:
- No meaningful connection
Logical Cohesion:
- Collection of functionally related components (e.g., I/O)
Temporal Cohesion:
- Functions are executed together (e.g., initialization)
Abstract Cohesion:
- Module provides services associated with a single data type

Examples

Design:
Discussion:
- Is it a good design? If not, how can it be improved?

Examples (cont.)

Design:
Discussion:
- Is it a good design? If not, how can it be improved?

Examples (cont.)

Design:
Discussion:
- Is it a good design? If not, how can it be improved?

Examples (cont.)

Design:
Discussion:
- Is it a good design? If not, how can it be improved?

Examples (cont.)

Design:
Discussion:
- Is it a good design?

Examples (cont.)

Design:
Discussion:
- Is it a good design? If not, how can it be improved?

There's Always More to Learn