- Forward


Engineering Design Principles
Evaluating Software Engineering Designs


Prof. David Bernstein
James Madison University

Computer Science Department
bernstdh@jmu.edu

Print

Overview
Back SMYC Forward
  • Rationale
  • Qualitative Goals
  • The Fundamental Principle
  • Other Engineering Design Principles
Rationale
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • Standardization
  • Simplicity
  • Elegance/Beauty
Standardization
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • Information Hiding
  • Coupling
  • Cohesion
Information Hiding
Back SMYC Forward
  • The Practice:
    • Hide the internal details of a component from all other components
  • The Rationale:
    • Prevents damage from errant external code
      • You can't hurt what you can't see
      Expand
    • Makes components easier to understand/use
      • It enhances abstraction (i.e., shields users from the details)
      Expand
    • Simplifies modification and repair
      • Changing internal details should not have any impact other components
      Expand
    • Facilitates re-use
Information Hiding (cont.)
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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.)
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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.)
Back SMYC Forward
  • 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
Back SMYC Forward
  • 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
Back SMYC Forward
  • Design:
    • cohesion-coupling2
  • Discussion:
    • Is it a good design? If not, how can it be improved?
    • The class is not cohesive.
    • Expand
Examples (cont.)
Back SMYC Forward
  • Design:
    • cohesion-coupling4
  • Discussion:
    • Is it a good design? If not, how can it be improved?
    • The classes are strongly coupled. The Calculator should not have know details about messages.
    • Expand
Examples (cont.)
Back SMYC Forward
  • Design:
    • cohesion-coupling5
  • Discussion:
    • Is it a good design? If not, how can it be improved?
    • It is not cohesive. A better design would be to have a ZipCodeReader class and a PostageFinder class.
    • Expand
Examples (cont.)
Back SMYC Forward
  • Design:
    • cohesion-coupling6
  • Discussion:
    • Is it a good design? If not, how can it be improved?
    • It isn't cohesive. Though the buttons seem similar, they aren't. Some are in the elevator and some are outside of the elevator. So, it would be better to have an Elevator class and a CallStation class.
    • Expand
Examples (cont.)
Back SMYC Forward
  • Design:
    • cohesion-coupling7
  • Discussion:
    • Is it a good design?
    • It isn't a good design because it violates standards. That is, in the real world, Bold, Italic and Plain do not have a part-whole relationship to Paragraph.
    • Expand
Examples (cont.)
Back SMYC Forward
  • Design:
    • cohesion-coupling8
  • Discussion:
    • Is it a good design? If not, how can it be improved?
    • It is tightly coupled. It could be improved by adding a Content interface.
    • Expand
There's Always More to Learn
Back -