CMSC 345 Fall 2000

Design Issues

Modularity and Abstraction Characteristic of all design methods Components have clearly defined inputs

and outputs, and clearly stated purpose Easy to examine each component

separately Organized in hierarchy so system can be

investigated one level at a time Components at one level refine those in the

level above More abstract top levels hide detail of lower

level functional or data components

Information Hiding Components hide internal details and

processing from one another Each hides a specific design decision Allows to isolate complex parts of problem,

where “decisions” need to be made Possible to use different design methods

within different components When a hidden design decision changes,

only that component must be changed The rest of the design remains intact

Collaborative Design Most designs created by teams Determine who is best suited to design

each aspect of system Document each subsystem design so

understandable by other team members Coordinate design components so work

well as unified whole The Problem: differences in experience,

understanding and prefrence

Trends Toward Collaborative Teams Cut costs and maximize productivity1. Project performed at single site with on-site

developers from multiple locations2. On-site analysts determine requirements, then

off-site groups of designers and programmers continue

3. Off-site developers build generic products and components used worldwide

4. Off-site developers build components that take advantage of their areas of expertise

Contrary to iterative feedback among phases Introduces difficult communication problems

Designing User Interface Metaphors: fundamental terms, images,

and concepts to be recognized and learned Mental model: organization/representation

of data, functions, tasks, roles Navigation rules: how to move among

data, functions, activities, roles Look: characteristics of appearance that

convey information to the user Feel: interaction techniques the provide

appealing experience for user

Characteristics of Good Design High-quality design lead to quality

products1. Ease of understanding2. Ease of implementation3. Ease of testing4. Ease of modification5. Correct translation from requirments6. Modifiability

Component Independence Abstraction and Information Hiding

allow us to examine ways that components are related

Strive to make components as independent as possible Easier to understand if not tied to

others Easier to modify if independent Easier to isolate and fix problems

Component Coupling Highly coupled = great deal of

dependence between components Loosely coupled = some

dependence but interconnections are weak

Uncoupled = no interconnections at all

Uncoupled -no dependencies

Highly coupled -many dependencies

Loosely coupled -some dependencies

How components are coupled References from one component to

another, such as invocation Amount of data passed from one

component to another Amount of control one component

has over another Degree of complexity of interface,

e.g., one entry point vs. mutual entry points

Goal is to Minimize Coupling Enables to change portion of system while

disrupting rest of system little as possible Very low coupling might allow pull-out,

plug-in replacement of only one component Loose coupling may require changing or

replacing a few components High coupling may require widespread

perturbations in system Low coupling reduces the number of

components needing revision

Types of Coupling Content: one component directly

modifies data or control flow of another

Common: Organizing data into a common store

Control: Control flags passed as parameters between components

Stamp: Data structures passed Data: Only primitive data passed

HIGH COUPLING

LOW

LOOSE

Data coupling

Stamp coupling

Uncoupled

Control coupling

Common coupling

Content coupling

A

B C

D EComponent B

Go to D1 Component D

Go to D1

D1:

Content Coupling

Global:A1A2A3

Variables:V1V2

Common data areaand variable names

Component X Component Y Component Z

Change V1 to zero Increment V1 V1 = V2 + A1

Common Coupling

Maximize Cohesion Cohesion: the degree of

interrelatedness of internal parts. All elements of the component are

directed towards and essential for the same task

Degrees of Cohesion Coincidental: component’s parts unrelated Logical: logically related functions and/or data placed

in same component Temporal: performs several functions in sequence,

related only by timing (not ordering) Procedural: functions grouped together to ensure

mandatory ordering Communicational: functions operate on or produce

same data set Sequential: output from one function is input to next Functional: every processing element essential to

single function, and all such essential elements contained in one component

HIGH COHESION

LOW

Logical

Temporal

Coincidental

Procedural

Communicational

Sequential

Functional

COINCIDENTALParts unrelated

FUNCTION A

FUNCTIONB

FUNCTION D

FUNCTION C

FUNCTION E

LOGICALSimilar functions

FUNCTION A

FUNCTION A’

FUNCTION A”

logic

TEMPORALRelated by

time

TIME T0

TIME T0 + X

TIME T0 + 2X

PROCEDURALRelated by

order offunctions

FUNCTION A

FUNCTION B

FUNCTION C

COMMUNICATIONAL

Access Same Data

FUNCTION A

FUNCTION B

FUNCTION C

SEQUENTIALOutput of one part is Input to the next

FUNCTION A

FUNCTION B

FUNCTION C

DATA

FUNCTIONALSequential with

complete, related functions

FUNCTION A Part 1

FUNCTION APart 2

FUNCTION APart 3

Control Issues Scope of control: set of

components supposed to be invoked by another

Scope of effect: set of components actually invoked by another

Scope of effect should be fully within scope of control

Fans Fan-in: number of components

controlling a particular component Fan-out: number of components

controlled by a given component Minimize components with high fan-out

Probably doing too much, performing more than one function

High fan-in should be limited to utility components

Goal – High fan-in; low fan-out

A

B C D

E F G

System 1

A

B C D E F

G System 2

Exceptions “Defensive design”: actively anticipate situations

that may lead to problems Make explicit what the system is not supposed to

do Not easy to define

Should do what it is required to do “but no more” Not easy to define or test

Exception: situation counter to what system should do. Typical exceptions: Failure to provide service or data Providing wrong service or data Corrupting data

Exception Handling Retry: restore system to previous

state and try again using a different strategy

Correct: restore to previous state, correct some aspect, and try again (same strategy)

Report: restore to previous state, report problem, and do not provide service

Faults and Failures Fault = error internal to software

product Failure = department of system

from required behavior Not every fault corresponds to

failure, since conditions under which fault leads to failure may never occur

Fault Detection Passive fault detection

wait until failure occurs, then do something Active fault detection

periodically check for symptoms of faults or try to anticipate failures

Mutual suspicion policy = each component assumes other components contain faults Check all inputs for correctness and consistency Fault handled when discovered rather than

propagated Limits damage

N-version programming Compare results of multiple

processes performing same function but designed separately May not help, since designers often

use similar patterns and techniques Diagnostic Transactions

Second system monitoring or running diagnostics on first

Fault Correction Compensate for fault’s presence Halt system and fix problem

Not acceptable for some applications Note problem and fix later

May allow additional damage System criticality determines

strategy

Fault Tolerance Correcting fault too expensive,

risky or inconvenient Minimize damage and carries on Relies on ability to predict location

of faults and timing of failures To build work-around into system

design we must be able to guess what may go wrong

Design Reviews Preliminary design review: examine

conceptual design with customers/users Critical design review: present

technical design to other developers Program design review: feedback to

programmers before implementation Egoless: comments and criticism

directed at process and product, not designers or other participants

Preliminary Design Review Validation: Make sure all requirements addressed

by design Moderator leads discussion but has no vested

interest Secretary records main points and outcome Developers not involved in project provide

objective outsider’s perspective Customer approves dialogs, menus, report formats,

fault handling, etc. Resolve minor issues as appear, major problems

lead to design revision and another review

Critical Design Review Addresses technical details Two major questions

Does design implement all requirements? Is design of high quality?

Program designers need to understand, to derive more detailed designs

Explain alternative design strategies and how/why of major design decisions

If major problems identified, then revise and re-review

Program Design Review Program designers treat technical

design as design descriptions for components to be coded and tested

Present coding plans before coding begins

Value of Design Reviews Detecting (not correcting) faults

when it is easy and inexpensive to fix

By investigating the integrity of the design (not the designers), we emphasize that we are all working together towards the same goal

Answers important questions (see text pg 244-245)