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 productivity 1. Project performed at single site with on-site developers from multiple locations 2. 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 products 1. Ease of understanding 2. Ease of implementation 3. Ease of testing 4. Ease of modification 5. Correct translation from requirments 6. 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 BC DE Component B Go to D1 Component D Go to D1 D1: Content Coupling

Global: A1 A2 A3 Variables: V1 V2 Common data area and variable names Component XComponent YComponent 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

COINCIDENTAL Parts unrelated FUNCTION A FUNCTION B FUNCTION D FUNCTION C FUNCTION E LOGICAL Similar functions FUNCTION A FUNCTION A’ FUNCTION A” logic

TEMPORAL Related by time TIME T0 TIME T0 + X TIME T0 + 2X PROCEDURAL Related by order of functions FUNCTION A FUNCTION B FUNCTION C

COMMUNICATIONAL Access Same Data FUNCTION A FUNCTION B FUNCTION C SEQUENTIAL Output of one part is Input to the next FUNCTION A FUNCTION B FUNCTION C DATA

FUNCTIONAL Sequential with complete, related functions FUNCTION A Part 1 FUNCTION A Part 2 FUNCTION A Part 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 BCD EFG System 1 A BCD EF 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 )