Overview

A software design is a meaningful engineering representation of some software product that is to be built. A design can be traced to the customer's requirements and can be assessed for quality against predefined criteria. During the design process the software requirements model is transformed into design models that describe the details of the data structures, system architecture, interface, and components. Each design product is reviewed for quality before moving to the next phase of software development.

Design Specification Models

• Data design - created by transforming the analysis information model (data dictionary and ERD) into data structures required to implement the software
• Architectural design - defines the relationships among the major structural elements of the software, it is derived from the system specification, the analysis model, and the subsystem interactions defined in the analysis model (DFD)
• Interface design - describes how the software elements communicate with each other, with other systems, and with human users; the data flow and control flow diagrams provide much the necessary information
• Component-level design - created by transforming the structural elements defined by the software architecture into procedural descriptions of software components using information obtained from the PSPEC, CSPEC, and STD

Design Guidelines

A design should

• exhibit good architectural structure
• be modular
• contain distinct representations of data, architecture, interfaces, and components (modules)
• lead to data structures that are appropriate for the objects to be implemented and be drawn from recognizable design patterns
• lead to components that exhibit independent functional characteristics
• lead to interfaces that reduce the complexity of connections between modules and with the external environment
• be derived using a reputable method that is driven by information obtained during software requirements analysis

Design Principles

The design

• process should not suffer from tunnel vision
• should be traceable to the analysis model
• should not reinvent the wheel
• should minimize intellectual distance between the software and the problem as it exists in the real world
• should exhibit uniformity and integration
• should be structured to accommodate change
• should be structured to degrade gently, even with bad data, events, or operating conditions are encountered
• should be assessed for quality as it is being created
• should be reviewed to minimize conceptual (semantic) errors

Fundamental Software Design Concepts

• Abstraction - allows designers to focus on solving a problem without being concerned about irrelevant lower level details (procedural abstraction - named sequence of events, data abstraction - named collection of data objects)
• Refinement - process of elaboration where the designer provides successively more detail for each design component
• Modularity - the degree to which software can be understood by examining its components independently of one another
• Software architecture - overall structure of the software components and the ways in which that structure provides conceptual integrity for a system
• Control hierarchy or program structure - represents the module organization and implies a control hierarchy, but does not represent the procedural aspects of the software (e.g. event sequences)
• Structural partitioning - horizontal partitioning defines three partitions (input, data transformations, and output); vertical partitioning (factoring) distributes control in a top-down manner (control decisions in top level modules and processing work in the lower level modules)
• Data structure - representation of the logical relationship among individual data elements (requires at least as much attention as algorithm design)
• Software procedure - precise specification of processing (event sequences, decision points, repetitive operations, data organization/structure)
• Information hiding - information (data and procedure) contained within a module is inaccessible to modules that have no need for such information

Modular Design Method Evaluation Criteria

• Modular decomposability - provides systematic means for breaking problem into subproblems
• Modular composability - supports reuse of existing modules in new systems
• Modular understandability - module can be understood as a stand-alone unit
• Modular continuity - side-effects due to module changes minimized
• Modular protection - side-effects due to processing errors minimized

Control Terminology

• Span of control (number of levels of control within a software product)
• Depth (distance between the top and bottom modules in program control structure)
• Fan-out or width (number of modules directly controlled by a particular module)
• Fan-in (number of modules that control a particular module)
• Visibility (set of program components that may be called or used as data by a given component)
• Connectivity (set of components that are called directly or are used as data by a given component)

Effective Modular Design

• Functional independence - modules have high cohesion and low coupling
• Cohesion - qualitative indication of the degree to which a module focuses on just one thing
• Coupling - qualitative indication of the degree to which a module is connected to other modules and to the outside world

Design Heuristics for Effective Modularity

• Evaluate the first iteration of the program structure to reduce coupling and improve cohesion.
• Attempt to minimize structures with high fan-out; strive for fan-in as structure depth increases.
• Keep the scope of effect of a module within the scope of control for that module.
• Evaluate module interfaces to reduce complexity, reduce redundancy, and improve consistency.
• Define modules whose function is predictable and not overly restrictive (e.g. a module that only implements a single subfunction).
• Strive for controlled entry modules, avoid pathological connection (e.g. branches into the middle of another module)