1. Design Engineering
1

2. Fundamental Concepts
 abstraction—data, procedure, control
 architecture—the overall structure of the software
 modularity—compartmentalization of data and function
 Functional independence—single-minded function and low coupling
 hiding—controlled interfaces
 refinement—elaboration of detail for all abstractions
 Refactoring—a reorganization technique that simplifies the design
2

3. Data Abstraction
Abstraction is the intellectual tool that allows us to deal
with concepts apart from particular instances of those
concepts. During requirements definition an design,
abstraction permits separation of the conceptual aspects
of a system from the implementation details
3

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

5. Three widely used abstraction mechanism in s/w design are
functional abstraction
data abstraction
control abstraction.
5

6. Functional Abstraction
Functional Abstraction

6
It involves the use of parameterized subprograms. The
ability to parameterize a subprogram and to bind different
parameter values on different invocations of the subprogram
is a powerful abstraction mechanism.
Data Abstraction
It involves specifying a data type or a data object by
specifying legal operations on objects. Representation and
manipulation details are suppressed.


7. Control Abstraction

It is the third commonly used abstraction mechanism in
software design. Control abstraction is used to state a
desired effect without stating the exact mechanism of
control. IF statements and WHILE statements in modern
programming languages are abstractions of machine code
implementations that involve conditional jump instructions.
A statement of the form
“for all I in S sort files I”
leaves unspecified the sorting techniques, the nature of S, the
nature of the files, and how “for all I in S” is to be handled
7

8. Architecture
“The overall structure of the software and the ways in
which that structure provides conceptual integrity for a
system.” [SHA95a]
Structural properties. This aspect of the architectural design representation
defines the components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact with one
another. For example, objects are packaged to encapsulate both data and the
processing that manipulates the data and interact via the invocation of methods
Extra-functional properties. achieves requirements for performance, capacity,
reliability, security, adaptability, and other system characteristics.
Families of related systems. The architectural design should draw upon
repeatable patterns that are commonly encountered in the design of families of
similar systems. In essence, the design should have the ability to reuse
architectural building blocks.
8

9. Modular Design
e se t b i d e se t c a g , e se t f x. .
ai r o u , ai r o h n e ai r o i
l
.
Modularity is the way of defining the system as a collection of well defined, manageable units with
well defined interfaces among the units. Desirable properties of a modular system include:
•Each module is a well defined subsystem that is potentially useful in other applications
•Each module has a single, well defined purpose.
•Modules can be separately compiled and stored in a library
•Modules can use other modules.
•Modules should be easier to use than to build
•Modules should be simpler from the outside than from the inside.
9

10. 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
of modules
10
number of modules

11. abstraction
architecture
modularity
functional independence
hiding
refinement
refactoring
Functional Independence
COHESION - the degree to w hich a
module performs one and only one
function.
COUPLING - the degree to w hich a
module is "connected" to other
modules in the system.
11

12. Coupling
Coupling is the measure of the degree of interdependenc
between modules. Two modules with high coupling are
strongly interconnected and thus, dependent on each oth
•Content/Pathological Coupling : (worst) When a module
uses/alters data in another
•Control Coupling : 2 modules communicating with a control flag
(first tells second what to do via flag)
•Common/Global-data Coupling : 2 modules communicating via
global data
•Stamp/Data-structure Coupling : Communicating via a data
structure passed as a parameter. The data structure holds more
information than the recipient needs.
•Data Coupling : (best) Communicating via parameter passing. The
parameters passed are only those that the recipient needs.
12

13. Cohesion
Coincidental Cohesion : (Worst) Module elements are
13
unrelated Logical Cohesion : Elements perform similar
activities as selected from outside module, i.e. by a flag that
selects operation to perform
Logical cohesion
Temporal Cohesion : operations related only by general time
performed (i.e. initialization() or FatalErrorShutdown?())
Procedural Cohesion : Elements involved in different but
sequential activities, each on different data


14. Cohesion
Sequential Cohesion : operations on same data in significant
14
order; output from one function is input to next (pipeline)
Informational Cohesion: a module performs a number of
actions, each with its own entry point, with independent
code for each action, all performed on the same data
structure. Essentially an implementation of an
Functional Cohesion : all elements contribute to a single,
well-defined task, i.e. a function that performs exactly one
operation

15. Communicational Cohesion : unrelated operations except
need same data or input
15

16. abstraction
architecture
modularity
functional independence
hiding
refinement
refactoring
Information Hiding
module
• algorithm
controlled
interface • data structure
• details of external interface
• resource allocation policy
clients
"secret"
a specific design decision
16

17. Why Information Hiding?
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
leads to encapsulation—an attribute of high
quality design
results in higher quality software
17

18. abstraction
architecture
modularity
functional independence
hiding
refinement
refactoring
Stepwise Refinement
open
walk to door;
reach for knob;
open door;
walk through;
close door.
18
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat

19. abstraction
architecture
modularity
functional independence
hiding
refinement
refactoring
Refactoring
 Fowler [FOW99] defines refactoring in the following manner:
 "Refactoring is the process of changing a software system in such a way that it
does not alter the external behavior of the code [design] yet improves its internal
structure.”
 When software is refactored, the existing design is examined for
 redundancy
 unused design elements
 inefficient or unnecessary algorithms
 poorly constructed or inappropriate data structures
 or any other design failure that can be corrected to yield a better design.
19