Professional Documents
Culture Documents
http://classes.cec.wustl.edu/cs342/ Motivation
Common Design Mistakes
Design Rules
Copyright c 1997-2000 Dept. of Computer Science, Washington University 1
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Motivation: Goals of the Design Phase Motivation: Goals of the Design Phase (contd)
Decompose System into Modules
Specify Module Interfaces
i.e., identify the software architecture
Modules are abstractions that should: Interfaces should be well-defined
be independent, facilitate independent module testing
have well-specified interfaces, and improve group communication
have high cohesion and low coupling.
Describe Module Functionality
Determine Relations Between Modules
Informally
Identify module dependencies e.g., comments or documentation
Determine the form of intermodule communication, e.g., Formally
global variables e.g., via module interface specification languages
parameterized function calls
shared memory
RPC or message passing
Copyright c 1997-2000 Dept. of Computer Science, Washington University 2
Copyright c 1997-2000 Dept. of Computer Science, Washington University 3
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 4
Copyright c 1997-2000 Dept. of Computer Science, Washington University 5
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Decomposition is a concept common to all life-cycle and design Some guiding decomposition principles
techniques.
Because design decisions transcend execution time, modules
Basic concept is very simple: might not correspond to execution steps . . .
Decompose so as to limit the effect of any one design decision on
1. Select a piece of the problem (initially, the whole problem)
the rest of the system
2. Determine its components using the mechanism of choice, e.g.,
Remember, anything that permeates the system will be expensive
functional vs data structured vs object-oriented
to change
3. Show how the components interact
Modules should be specified by all information needed to use the
4. Repeat steps 1 through 3 until some termination criteria is met
module and nothing more
(e.g., customer is satisfied, run out of money, etc.;-))
Copyright c 1997-2000 Dept. of Computer Science, Washington University 6
Copyright c 1997-2000 Dept. of Computer Science, Washington University 7
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Abstraction provides a way to manage complexity by emphasizing Three basic abstraction mechanisms
essential characteristics and suppressing implementation details.
Procedural abstraction
Allows postponement of certain design decisions that occur at e.g., closed subroutines
various levels of analysis, e.g., Data abstraction
e.g., ADTs
Representational/Algorithmic considerations
Control abstraction
Architectural/Structural considerations
iterators, loops, multitasking, etc.
External/Functional considerations
Copyright c 1997-2000 Dept. of Computer Science, Washington University 8
Copyright c 1997-2000 Dept. of Computer Science, Washington University 9
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Motivation: details of design decisions that are subject to change Information to be hidden includes:
should be hidden behind abstract interfaces, i.e., modules.
Data representations
Information hiding is one means to enhance abstraction. i.e., using abstract data types
Algorithms e.g., sorting or searching techniques
Modules should communicate only through well-defined interfaces.
Input and Output Formats
Each module is specified by as little information as possible. Machine dependencies, e.g., byte-ordering, character codes
Policy/mechanism distinctions
If internal details change, client modules should be minimally affected i.e., when vs how
(may require recompilation and relinking, however . . .) e.g., OS scheduling, garbage collection, process migration
Lower-level module interfaces
e.g., Ordering of low-level operations, i.e., process sequence
Copyright c 1997-2000 Dept. of Computer Science, Washington University 10
Copyright c 1997-2000 Dept. of Computer Science, Washington University 11
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
A Modular System is a system structured into highly independent Modularity facilitates certain software quality factors, e.g.:
abstractions called modules.
Extensibility - well-defined, abstract interfaces
Modularity is important for both design and implementation phases. Reusability - low-coupling, high-cohesion
Compatibility - design bridging interfaces
Module prescriptions:
Portability - hide machine dependencies
Modules should possess well-specified abstract interfaces.
Modularity is an important characteristic of good designs because it:
Modules should have high cohesion and low coupling.
allows for separation of concerns
enables developers to reduce overall system complexity via
decentralized software architectures
enhances scalability by supporting independent and concurrent
development by multiple personnel
Copyright c 1997-2000 Dept. of Computer Science, Washington University 12
Copyright c 1997-2000 Dept. of Computer Science, Washington University 13
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 14
Copyright c 1997-2000 Dept. of Computer Science, Washington University 15
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 16
Copyright c 1997-2000 Dept. of Computer Science, Washington University 17
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Criteria for Evaluating Modular Designs Criteria for Evaluating Modular Designs (contd)
Copyright c 1997-2000 Dept. of Computer Science, Washington University 18
Copyright c 1997-2000 Dept. of Computer Science, Washington University 19
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Principles for Ensuring Modular Designs Principles for Ensuring Modular Designs (contd)
Copyright c 1997-2000 Dept. of Computer Science, Washington University 20
Copyright c 1997-2000 Dept. of Computer Science, Washington University 21
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
A satisfactory module decomposition technique should yield modules Traditional design techniques and programming languages do not
that are both open and closed: offer an elegant solution to the problem of producing modules that
are both open and closed.
Open Module: is one still available for extension. This is necessary
because the requirements and specifications are rarely completely Object-oriented methods utilize inheritance and dynamic binding to
understood from the systems inception. solve this problem.
Closed Module: is available for use use by other modules, usually
given a well-defined, stable description and packaged in a library.
This is necessary because otherwise code sharing becomes
unmanageable because reopening a module may trigger changes
in many clients.
Copyright c 1997-2000 Dept. of Computer Science, Washington University 22
Copyright c 1997-2000 Dept. of Computer Science, Washington University 23
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Case Study: Arithmetic Expression Evaluation Case Study: Arithmetic Expression Evaluation (contd)
Initial specification: write a four-function calculator utility that
evaluates arithmetic expressions of the form: However, problems arise when the calculators functionality is
(10 + 20) * 30.0 / 49 - 37 enhanced by adding new operations, e.g., extending it to handle
Typical solution in Ada, Pascal, or C makes use of enumerated types complete C or C++ expression syntax.
and a case or switch statement, e.g., Programs that utilize case analysis and enumerated types are often
enum op_type { ADD, SUB, MUL, DIV }; difficult to update, enhance, and maintain.
// . . .
void apply (op_type op_code, double v1, double v2) { OOD/OOP provide a more flexible and extensible solution using
switch (op_code) { inheritance and dynamic binding.
case ADD: // . . .
case SUB: // . . .
case MUL: // . . .
case DIV: // . . .
}
}
Copyright c 1997-2000 Dept. of Computer Science, Washington University 24
Copyright c 1997-2000 Dept. of Computer Science, Washington University 25
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
A virtual machine architecture is used to decompose system into A virtual machine component provides a set of operations that are
smaller, more manageable units. useful in developing a family of similar systems
A virtual machine provides an extended software instruction set Reusability is limited if virtual machine operations merely correspond
to steps in processing from input to output, i.e., use the shopping
Extensions provide additional data types and associated software
list approach.
instructions
Modeled after hardware instruction set primitives that work on a It is difficult to obtain good performance at level N, if levels below N
limited set of data types are not implemented efficiently.
Virtual machines allow incremental extensions
But beware of overly narrow interfaces in lower layer virtual
machines . . .
Copyright c 1997-2000 Dept. of Computer Science, Washington University 26
Copyright c 1997-2000 Dept. of Computer Science, Washington University 27
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 28
Copyright c 1997-2000 Dept. of Computer Science, Washington University 29
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Relations that define hierarchies: X Uses Y if the correct functioning of X depends on the availability of
a correct implementation of Y
Uses
Is-Composed-Of Note, uses is not necessarily the same as invokes:
Is-A
Some invocations are not uses
Has-A
e.g., error logging
The first two are general to all design methods, the latter two are Some uses dont involve invocations
more particular to object-oriented design and programming. e.g., message passing, interrupts, shared memory access
A uses relation does not necessarily yield a hierarchy (avoid cycles .
. .)
Copyright c 1997-2000 Dept. of Computer Science, Washington University 30
Copyright c 1997-2000 Dept. of Computer Science, Washington University 31
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 32
Copyright c 1997-2000 Dept. of Computer Science, Washington University 33
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
The is-composed-of relationship shows how the system is broken Many programming languages support the is-composed-of relation
down in components. via some higher-level module or record structuring technique.
X is-composed-of fxig if X is a group of units x i that share some Note: the following are not equivalent:
common purpose
1. level (virtual machine)
The system structure graph description can be specified by the is- 2. module (an entity that hides a secret)
composed-of relation such that: 3. a subprogram (a code unit)
non-terminals are virtual code Modules and levels need not be identical, as a module may have
terminals are the only units represented by actual (concrete) several components on several levels of a uses hierarchy.
code
Copyright c 1997-2000 Dept. of Computer Science, Washington University 34
Copyright c 1997-2000 Dept. of Computer Science, Washington University 35
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
These two relationships are associated with object-oriented design Very important design principle, used to separate concerns at both
and programming languages that possess inheritance and classes. the design and implementation phases.
Is-A or Descendant relationship Multiple policies can be implemented by shared mechanisms.
class X possesses Is-A relationship with class Y if instances of e.g., OS scheduling and virtual memory paging
class X are specialization of class Y.
Same policy can be implemented by multiple mechanisms.
e.g., a square is a specialization of a rectangle, which is a
specialization of a shape . . . e.g., FIFO containment can be implemented using a stack based
on an array, or a linked list, or . . .
Has-A or Containment relationship
e.g., reliable, non-duplicated, bytestream service can be provided
class X possesses a Has-B relationship with class Y if instances by multiple communication protocols.
of class X contain one or more instance(s) of class Y.
e.g., a car has an engine and four tires . . .
Copyright c 1997-2000 Dept. of Computer Science, Washington University 36
Copyright c 1997-2000 Dept. of Computer Science, Washington University 37
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 38
Copyright c 1997-2000 Dept. of Computer Science, Washington University 39
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 40
Copyright c 1997-2000 Dept. of Computer Science, Washington University 41
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 42
Copyright c 1997-2000 Dept. of Computer Science, Washington University 43
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 44
Copyright c 1997-2000 Dept. of Computer Science, Washington University 45
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 46
Copyright c 1997-2000 Dept. of Computer Science, Washington University 47
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 48
Copyright c 1997-2000 Dept. of Computer Science, Washington University 49
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Design is the process of organizing structured solutions to tasks from Depth-first design
a problem domain.
only partially satisfy the requirements
This process is carried out in many disciplines, in many ways. experience is best cure for this problem . . .
There are many similarities and commonalities among design Directly refining requirements specification
processes.
leads to overly constrained, inefficient designs
There are also many common design mistakes . . .
Failure to consider potential changes
The following pages provide a number of design rules.
always design for extension and contraction
Remember, these rules are simply suggestions on how to better
organize your design process, not a recipe for success! Making the design too detailed
this overconstrains the implementation
Copyright c 1997-2000 Dept. of Computer Science, Washington University 50
Copyright c 1997-2000 Dept. of Computer Science, Washington University 51
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 52
Copyright c 1997-2000 Dept. of Computer Science, Washington University 53
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 54
Copyright c 1997-2000 Dept. of Computer Science, Washington University 55
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 56
Copyright c 1997-2000 Dept. of Computer Science, Washington University 57
CS 342: OO Software Development Lab OO Programming with C++ CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 58
Copyright c 1997-2000 Dept. of Computer Science, Washington University 59
CS 342: OO Software Development Lab OO Programming with C++
Copyright c 1997-2000 Dept. of Computer Science, Washington University 60