Date post: | 18-Jan-2016 |
Category: |
Documents |
Upload: | byron-mason |
View: | 215 times |
Download: | 0 times |
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)