Design & Architecture

1
"You can use an eraser
on the drafting table or
a sledgehammer on the
construction site.“
--Frank Lloyd Wright
What is Design?
• Design bridges that
gap between knowing
what is needed
(software requirements
specification) to
entering the code that
makes it work (the
construction phase).
• Design is both a verb
and a noun.
• Design is both a
process and a product.

3
What is Design?
Design (process) is the creative process of transforming the
problem into a solution. (software engineer’s definition)
Design is the creative process of figuring out how to implement
all of the customer’s requirements; the resulting plan is also
called the design.
Design (product) is the description of a solution.
Early design decisions address the system’s architecture.
Later design decisions address how to implement the individual
units.
Design is an especially creative activity and therefore hard to
schedule (hence iteration).
What is a solution?
 We declare something to be a solution to a problem if it
satisfies all the requirements in the specification. 4
Conceptual and Technical Designs
We produce conceptual design that tells the customer
exactly what the system will do. (The What of the solution)

We produce technical design that allows system builders

(developers) to understand the actual hardware and
software needed to solve the customer’s problem. (The
How of the solution)

Merged the two into one document.

5
 WHAT HOW

CONCEPTUAL TECHNICAL
DESIGN DESIGN

function System form

designers

Customers System
builders
6
Qualities of Good Conceptual Design
It should be written in customer’s language.
It explaining the observable external characteristics of the
system.
It contains no technical jargon (If it does, define it.).
It describes the functions of the system.
It is independent of implementation.
It is linked to the requirements documents.

7
Qualities of Good Technical Design
It describes of major hardware components and their
functions.
It shows hierarchy (organization) and functions of the
software components.
It shows data structures and data flow.
It shows interfaces.

8
Design Principles
Design principles are guidelines for decomposing a system’s
required functionality and behavior into modules.
The principles identify the criteria
 for decomposing a system.
 deciding what information to provide (and what to conceal) in the resulting
modules.
Important design concepts and design principles include:
 Decomposition
 Abstraction
 Information hiding
 Modularity - coupling and cohesion
 Hierarchical structure
 Separating Policy and Mechanism
Main purpose of these concepts and principles is to manage
software system complexity and improve software quality factors.
9
Decomposition
Decomposition is a concept common to all life-cycle and
design techniques.
Basic concept is very simple:
1. Select a piece of the problem (initially, the whole
problem).
2. Determine its components using the mechanism of
choice, e.g., functional vs data structured vs object-
oriented.
3. Show how the components interact.
4. Repeat steps 1 through 3 until some termination criteria is
met (e.g., customer is satisfied, run out of money, etc.).

10
Decomposition
Some guiding decomposition principles:
Because design decisions transcend execution time,
modules might not correspond to execution steps .
Decompose so as to limit the effect of any one design
decision on the rest of the system.
Remember, anything that permeates the system will be
expensive to change.
Modules should be specified by all information needed to
use the module and nothing more.

11
Abstraction
An abstraction is a model or representation that omits
some details so that it can focus on other details.
The definition is vague about which details are left out of a
model, because different abstractions, built for different
purposes, omit different kinds of details.
An abstraction is a generalization of something too complex
to be dealt with in its entirety.
Models can also be considered types of abstractions as per
their generalization of aspects of reality.
Basic abstraction mechanisms
Procedural abstraction
Data abstraction
12
Types of Abstraction
Procedural abstraction
 Distinguish what is to be achieved by a procedure from its
implementation.
 Natural consequence of stepwise refinement: name of procedure
denotes sequence of actions.

Data abstraction
 Specify the data objects for a problem and the operations to be
performed on them without concern for their representation in
memory.
 Aimed at finding a hierarchy in the data.

13
Information Hiding
A more accurate term would be “details hiding”.
Motivation: details of design decisions that are subject to change
should be hidden behind abstract interfaces, i.e., modules.
Information hiding is one means to enhance abstraction.
The information hidden can be data, data formats, behavior, and
more generally, design decisions.
Modules should communicate only through well-defined interfaces.
Each module is specified by as little information as possible.
If internal details change, client modules should be minimally
affected (may require recompilation and relinking, however . . .)
Design involves a series of decision: for each such decision, wonder
who needs to know and who can be kept in the dark.
A big advantage of information hiding is that the resulting software
units are loosely coupled. 14
Information Hiding
Information to be hidden includes:
Data representations
 i.e., using abstract data types
Algorithms e.g., sorting or searching techniques
Input and Output Formats
 Machine dependencies, e.g., byte-ordering, character codes
Policy/mechanism distinctions
 i.e., when vs how
 e.g., OS scheduling, garbage collection, process migration

Lower-level module interfaces

 e.g., Ordering of low-level operations, i.e., process sequence
15
Module
What is a module?
 lexically contiguous sequence of program statements, bounded by
boundary elements, with aggregate identifier
A module is a unit of code that:
 has one or more names
 has identifiable boundaries
 can be (re-)used by other modules
 encapsulates data
 hides unnecessary details
 can be separately compiled (if supported)
Examples
 procedures & functions in classical PLs
 objects & methods within objects in OO PLs

16
Modularity
A Modular System is a system structured into highly
independent abstractions called modules.
Modularity is important for both design and implementation
phases.
Structural criteria which tell us something about individual
modules and their interconnections.
If the principle is applied well, each resulting module will have a
single purpose and will be relatively independent of the others.
 each module will be easy to understand and develop.
 easier to locate faults (because there are fewer suspect
modules per fault).
 Easier to change the system (because a change to one module
affects relatively few other modules.
17
Modularity
Software should be split into separately named and addressable
components.
To determine how well a design separates concerns, we use two
concepts that measure module independence: coupling and
cohesion
Modularity facilitates certain software quality factors, e.g.:
 Extensibility - well-defined, abstract interfaces
 Reusability - low-coupling, high-cohesion
 Compatibility - design “bridging” interfaces
 Portability - hide machine dependencies
Module prescriptions:
 Modules should possess well-specified abstract interfaces.
 Modules should have high cohesion and low coupling.

18
Coupling
Degree of interaction between modules.
Five categories or levels of coupling (non-linear scale).

19
Coupling
 Two modules are tightly coupled when they depend a great deal on
each other
 Loosely coupled modules have some dependence, but their
interconnections are weak
 Uncoupled modules have no interconnections at all; they are
completely unrelated

Uncoupled - Loosely coupled - Tightly coupled -

no dependencies some dependencies many dependencies
 There are many ways that modules can be dependent on each other:
 The references made from one module to another
 The amount of data passed from one module to another
 The amount of control that one module has over the other 20
1. Content Coupling
Def.
 one module directly references contents of the other
Example
 module a modifies statements of module b
 module a refers to local data of module b in terms of some
numerical displacement within b
 module a branches into local label of module b
Why is this bad?
 almost any change to b requires changes to a
Warning
 Content coupling can be implemented in Ada through use of
overlays implemented via address clauses

21
 ccb

cca

2. Common Coupling
Def. global variable

 two modules have write access to the same global data

Example
 two modules have access to same database, and can both read and
write same record
 use of Java public statement while (global variable == 0)
Why is this bad? if (argument xyz > 25)
module 3 ();
 resulting code is unreadable
else
 modules can have side-effects
module 4 ();
 must read entire module to understand

 difficult to reuse
 module exposed to more data than necessary

22
3. Control Coupling
Def.
 one module passes an element of control to the other
Example
 control-switch passed as an argument
 Operation code passed to module with logical cohesion
Why is this bad?
 modules are not independent
 module b must know the internal structure of module a
 affects reusability
 Associated with modules of logical cohesion

23
4. Stamp Coupling
 Def. - Two modules are stamp coupled if a data structure is passed as a
parameter, but the called module operates on some but not all of the
individual components of the data structure
Some languages allow only simple variables as parameters
 part number, satellite altitude, degree of multiprogramming
Many languages also support passing of data structures
 part record, satellite coordinates, segment table
Example - calculate withholding (employee record)
Why is this bad?
 affects (difficult to) understanding
 not clear, without reading entire module, which fields of record are
accessed or changed
 unlikely to be reusable
 other products have to use the same higher level data structures
 passes more data than necessary
 e.g., uncontrolled data access can lead to computer crime
24
5. Data Coupling
Def.
 every argument is either a simple argument or a data structure in
which all elements are used by the called module
Example
 display time of arrival (flight number)
 compute product (first number, second number);
 get job with highest priority (job queue)
Slippery slope between stamp & data (see queue)
Why is this good?
 maintenance is easier
 good design has high cohesion & weak coupling

25
Cohesion
Degree of interaction within a module.
A measure of how well a component “fits together”.
Seven categories or level of Cohesion:

26
1. Coincidental Cohesion
Def. ?
 module performs multiple, completely unrelated actions
Example
 module prints next line, reverses the characters of the 2nd argument,
adds 7 to 3rd argument
How could this happen?
 hard organizational rules about module size
Why is this bad?
 degrades maintainability & modules are not reusable
Easy to fix. How?
 break into separate modules each performing one task
Arise from rules like
 “Every module will consist of between 35 and 50 statements”

27
2. Logical Cohesion
Def. ?
 module performs series of related actions, one of which is selected
by calling module
Example 1
 Module performing all input and output
Example 2
 One version of OS/VS2 (Operating System/Virtual Storage 2)
contained logical cohesion module performing 13 different actions.
Interface contained 21 pieces of data
Why is this bad?
 interface difficult to understand
 code for more than one action may be intertwined
 difficult to reuse

28
3. Temporal Cohesion
Def. ?
 module performs series of actions related in time
Initialization example
open old db, new db, transaction db, print db, initialize
sales district table, read first transaction record, read
first old db record
Why is this bad?
 actions weakly related to one another, but strongly related to
actions in other modules
 code spread out -> not maintainable or reusable
Initialization example fix
 define these intializers in the proper modules & then have an
initialization module call each

29
4. Procedural Cohesion
Def. ?
 module performs series of actions related by procedure to be
followed by product
Example
 update part number and update repair record in master db
Why is this bad?
 actions are still weakly related to one another
 not reusable
Solution
 break up!

30
5. Communicational Cohesion
Def. ?
 module performs series of actions related by procedure to be
followed by product, but in addition all the actions operate on same
data
Example 1
update record in db and write it to audit trail
Example 2
calculate new coordinates and send them to window
Why is this bad?
 still leads to less reusability -> break it up

31
7. Informational Cohesion
Def. ?
 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
 It is good.

32
Examples of Cohesion-1

Function A Function A Time t0

Function Function
B C logic Function A’ Time t0 + X
Function Function
D E Function A’’
Time t0 + 2X
Coincidental Logical Temporal
Parts unrelated Similar functions Related by time
Function A

Function B

Function C

Procedural
Related by order of functions
Examples of Cohesion-2
Function A Function A

Function B Function B

Function C Function C

Communicational Sequential
Access same data Output of one is input to another
Function A part 1

Function A part 2

Function A part 3

Functional
Sequential with complete, related functions
7. Functional Cohesion
Def. ?
 module performs exactly one action
Examples
 get temperature of furnace
 compute orbital of electron
 calculate sales commission

Why is this good?

 more reusable
 corrective maintenance easier
 fault isolation
 reduced regression faults
 easier to extend product

35
Modularity Dimensions
 Modularity has several dimensions and encompasses specification,
design, and implementation levels:
Criteria for evaluating design methods with respect to modularity
 Modular Decomposability
 Modular Composability
 Modular Understandability
 Modular Continuity
 Modular Protection
Principles for ensuring modular designs:
 Language Support for Modular Units
 Few Interfaces
 Small Interfaces (Weak Coupling)
 Explicit Interfaces
 Information Hiding
36
The Open/Closed Principle
 Satisfactory module decomposition technique should yield 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
understood from the system’s inception.
 Closed Module: is available for 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.
 Traditional design techniques and programming languages do not offer
an elegant solution to the problem of producing modules that are both
open and closed.
 Object-oriented methods utilize inheritance and dynamic binding to
solve this problem.

37
Hierarchical structure
Motivation: reduces module interactions by restricting the
topology of relationships.
A relation defines a hierarchy if it partitions units into levels
(note connection to virtual machines)
 Level 0 is the set of all units that use no other units
 Level i is the set of all units that use at least one unit at level < i and
no unit at level >= i.
Hierarchical structure forms basis of design:
 Facilitates independent development
 Isolates ramifications of change
 Allows rapid prototyping
 Relations that define hierarchies: Uses, Is-Composed-Of, Is-A, Has-A.
 The first two are general to all design methods, the latter two are more
particular to object-oriented design and programming.
38
The Uses Relation
X Uses Y if the correct functioning of X depends on
the availability of a correct implementation of Y
Note, uses is not necessarily the same as invokes:
Some invocations are not uses
e.g., error logging
Some uses don’t involve invocations
e.g., message passing, interrupts, shared memory access
A uses relation does not necessarily yield a hierarchy
(avoid cycles ...)

39
The Is-Composed-Of Relation
 The is-composed-of relationship shows how the system is broken down
in components.
 X is-composed-of {xi} if X is a group of units xi that share some common
purpose
 The system structure graph description can be specified by the is-
composed-of relation such that:
 non-terminals are “virtual” code
 terminals are the only units represented by “actual” (concrete) code
 Many programming languages support the is-composed-of relation via
some higher-level module or record structuring technique.
 Note: the following are not equivalent:
1. level (virtual machine)
2. module (an entity that hides a secret)
3. a subprogram (a code unit)
 Modules and levels need not be identical, as a module may have several
components on several levels of a uses hierarchy. 40
The Is-A and Has-A Relations
These two relationships are associated with object-oriented
design and programming languages that possess
inheritance and classes.
Is-A or Descendant relationship
 class X possesses Is-A relationship with class Y if instances of class X
are specialization of class Y.
e.g., a square is a specialization of a rectangle, which is a
specialization of a shape . . .
Has-A or Containment relationship
 class X possesses a Has-B relationship with class Y if instances of
class X contain one or more instance(s) of class Y.
 e.g., a car has an engine and four tires . . .

41
Separating Policy and Mechanism
Very important design principle, used to separate concerns
at both the design and implementation phases.
Multiple policies can be implemented by shared
mechanisms.
 e.g., OS scheduling and virtual memory paging
Same policy can be implemented by multiple mechanisms.
 e.g., FIFO containment can be implemented using a stack based on
an array, or a linked list, or . . .
 e.g., reliable, non-duplicated, bytestream service can be provided
by multiple communication protocols.

42
Thank You

43