Chapter 13 Design Concepts and Principles

Analysis to Design component- level design

Where Do We Begin? modeling Prototype Spec Design

A good design Implement all explicit and implicit requirements Be a readable and understandable guide for developers and customers Provide a complete picture of software

Design Principles (1) From Davis [DAV95] The design process should not suffer from ‘tunnel vision.’ The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world. The design should exhibit uniformity and integration.

Design Principles (2) From Davis [DAV95] The design should be structured to accommodate change. The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Design is not coding, coding is not design. The design should be assessed for quality as it is being created, not after the fact. The design should be reviewed to minimize conceptual (semantic) errors.

Fundamental Concepts Abstraction — data, procedure, control Refinement — elaboration of detail for bstractions Modularity — compartmentalize data and function Architecture — overall structure of the software Partitioning — partition the program structure Data structure — the logical relationship of data Procedure — the algorithms that achieve function Hiding — controlled interfaces Function independences — cohesion, coupling

Abstraction Data abstraction Procedure abstraction Control abstraction

Data Abstraction door manufacturer model number type swing direction inserts lights type number weight opening mechanism implemented as a data structure

Procedural Abstraction open details of enter algorithm implemented with a "knowledge" of the object that is associated with enter

Refinement Refinement — elaboration of detail for all abstractions open walk to door; reach for knob; open door; repeat until door opens turn knob clockwise; walk through; if knob doesn't turn, then close door. take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat

Modular Design modularity—compartmentalization of data & function

Sizing Modules: Two Views

Modularity: Trade-offs What is the "right" number of modules for a specific software design? module development cost cost of software module integration cost optimal number number of modules of modules

An Effective Modular System Modular decomposability Modular composability Modular understandability Modular continuity Modular protection

Architecture “The overall structure of the software and the ways in which that structure provides conceptual integrity for a system.” [SHA95a] superordinate subordinate

Partitioning the Architecture “horizontal” and “vertical” partitioning are required

Horizontal Partitioning define separate branches of the module hierarchy for each major function use control modules to coordinate communication between functions function 1 function 3 function 2

software that is easier to test software that is easier to maintain propagation of fewer side effects software that is easier to extend

Vertical Partitioning: Factoring design so that decision making and work are stratified decision making modules should reside at the top of the architecture decision-makers workers

Data Structure Data Structure — a representation of the logical relationship Item: integer, string… Vector: array Space: structure Linked list, node

Software Procedure Procedure — a precise specification of processing

Information Hiding Hiding — controlled interfaces module clients "secret" clients a specific design decision

Why Information Hiding? Leads to encapsulation — an attribute of high quality design Reduces the likelihood of “side effects” Limits the global impact of local design decisions Emphasizes communication through controlled interfaces Discourages the use of global data Results in higher quality software

Functional Independence COHESION - the degree to which a module performs one and only one function. COUPLING - the degree to which a module is "connected" to other modules in the system.

Cohesion The degree to which a module performs one and only one function

Coupling A measure of interconnection among modules

uncouple control stamp data content common

Content Coupling Common Coupling

Design Heuristics 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 depth increases. Keep the scope of effect of a module within the scope of control of that module. Evaluate module interfaces to reduce complexity and redundancy and improve consistency. Define modules whose function is predictable, but avoid modules that are overly restrictive. Strive for “controlled entry” modules by avoiding “pathological connections.”

Design Specification