Software Design and

Architecture

Dr. Nguyen Thanh Hung

1
What is software design ?
• Design as an activity: acts as a bridge between
requirements and the implementation of the
system
– Decompose system into modules
– Assign responsibilities to these modules
– Ensure that these modules fit together to achieve a
global goal
• Design as a result of an activity: gives a structure
that makes the system easy to understand and
evolve
– Produce a Software Design Document
– Often a software architecture is produced prior to a
software design

2
Covered topics

• Introduction
• Divide and conquer strategy
• Modularization techniques
• Architecture

3
Objectives

• After this lesson, students will be able to:

– Explain the divide and conquer strategy
– Sketch the decomposition tree for a given software
– Conduct modularization techniques with a given
software
– Distinguish the concepts of program structure and
software architecture

4
Recalled questions

1. Where is the structure of a program shown ?

A. Problem solving, program abstraction and program
elements
B. Control structures, data structures, functions and
procedure
C. Separation of concerns

Structured levels of
Software design
program
• Problem-solving • Architectural design
• Program • High-level design (API)
abstraction/organization
• Program elements • Detailed design (Impl.)
5
I. DIVIDE AND CONQUER
STRATEGY

1. Introduction
2. Decomposition
3. Composition
4. Step refinement

7
Introduction

• Divide: decompose • We decompose

– To simplify the problem
problems into sub- – To find solutions in terms
problems of the abstract machine
we can employ
• Conquer: solve – When completed, we can
compose
sub-problems • However, we may
(hopefully easier) choose where we begin:
• Assemble : – Stepwise Refinement
(top-down)
compose the – Assemblage and
Composition (bottom-up)
complete solution – Design from the middle
from the sub- (middle-out)
solutions
8
1. Decomposition

• The process by which a complex problem or

system is broken down into parts that are easier
to conceive, understand, program, and maintain

Problem

Sub - P …. Sub - P

Sub - P …. Sub - P Sub - P Sub - P

9
1.1. Functional decomposition

• Break a function down into its constituent parts

in such a way that the original function can be
reconstructed (i.e., recomposed) from those parts
by function composition.
– What are the functions of my software?
– What does the software do?
– Which sub-functions exist?
à functions are grouped to modules/components

10
Example: abstract machine

Produce tea

sequence

add boiling
Put tea in pot wait
water

repetition

pour spoon tea

into pot

selection

fetch green fetch black

tea tea

11
Working: Banking system

Transfer Deposit

Withdraw

12
1.2. Algorithmic decomposition

• Break a process down into well-defined steps

• Case 1: Each step corresponds to an action
– What are the actions of my software process?
– What are the states on which the action is performed?
– actions are grouped to modules/components
• Case 2: Each step corresponds to a couple event-
action
– Rule-based
– What are the events that may occur?
– How does my software react on them?

13
Example: abstract machine

produce tea

sequence
condition
add boiling
put tea in pot wait
water
repetition
condition
pour spoon tea
into pot

selection
condition
fetch green fetch black
tea tea

14
Working: Banking system

Transfer Deposit

Withdraw

15
1.3. Object-oriented decomposition

• Breaks a large system down into progressively

smaller objects (sub systems) that are
responsible for some part of the problem domain
• Data and actions are developed together
• What are the objects and their associated
actions/functions?
– Case 1: Data-oriented:
• The algorithm is isomorphic to the data
– Case 2: Structure-oriented:
• What are the components of the system and their relations

16
Example: abstract machine

action
add boiling
Put tea in pot wait
water

Pot

Data

Cup

17
Exercise: Banking system

Transfer Deposit

Withdraw

18
2. Composition: bottom-up

• Given an abstract machine implementing the

partial solution, stepwise construction includes:
– assemble more complex operations of a higher-level
abstract machine
– assemble the more complex data structures
• Good:
– always realistic
– a running partial solution
• Bad:
– Design might become clumsy since global picture was
not taken into account

19
3. Stepwise refinement: top-down

• Iterative process
• Operations and their associated data in every
step of an algorithm are the keys to solve a
problem
• Given an abstract machine implementing the
whole solution, refining the solution includes:
– Operation refinement: refine the operations in every
step of the corresponding algorithm
– Data refinement: refine the structures of data in every
step of the corresponding algorithm

20
2. Stepwise refinement: top-down

• Iterative process:
– Start: overall description of the problem to be solved
(top function)
– Decompose (in a recursive manner) the problem into
sub-problems according to control structures
– Terminate: when each sub-problems is easy to express
in terms of a few lines of code in the chosen
programming language.
• Bad:
– we might never reach a realization
– often “warehouse solutions” are developed

21
Decomposition tree

• Stepwise refinement process may be depicted by

a decomposition tree
– root labeled by name of top problem
– sub-problem nodes labeled as children of parent node
corresponding to problem
– children from left to right represent sequential order of
execution
– if and while nodes denoted by suitable decoration

22
Example

Produce tea

add boiling
Put tea in pot wait
water

pour spoon tea

into pot

C1 not C1

fetch green fetch black

tea tea

23
Exercise: Banking system

Transfer Deposit

Withdraw

24
II. MODULARIZATION
TECHNIQUES

1. Module
2. Relations between modules
3. Specific techniques for design for change

25
1.1. What is a module ?
• Software system should, according to the divide-and-
conquer principle, also physically be divided into basic
parts, modules
– 1 module can be developed independently
• errors can be traced down to modules
• modules can be tested before assembling
But not normally be considered as neither a separate system nor an
independent system
– 1 module can be exchanged independently
– 1 module can provide a set of computational elements to other
modules
– modules can be reused
• The terms module and component are pretty much the
same: a module is a well-defined component of a software
system
– a programming-language supported component (often composite)
– a simple component

26
Questions

• How to define the

structure of a M1
modular system?
• What are the M2
desirable
properties of that …
structure? Mn-1
Mn

System

27
1.2. Principle of modularization
[Parnas72]
• Fix all design decisions that
are likely to change design design
• Attach each of those decision M
decision
1
decisions to a new module design design
• The design decision is now M2
decision decision

called module secret

… design
• Design module interface decision
which does not change if design
M
decisionn-1
module secret changes design
M
decision
n
à This principle (that modules design
hide design decisions) is also decision

called information hiding System

28
 1.2. Principle of modularization
[Parnas72]

Client Resources to be exported:

types; variables, attributes,
functions, events, exceptions,
etc.
interface Bicycle {
void changeCadence (int newValue);
void changeGear(int newValue);
void speedUp(int increment);
Module
void applyBrakes(int decrement);
Interface }

Secret
Implementation of
Module exported resources

class Bike implements Bicycle {

}
class Motor-Bike implements Bicycle {
} 29
 Interface
Client Act as a firewall preventing access
to hidden parts
Should never change
Should not reveal what we expect
may change later
Should not reveal unnecessary
Module details
Interface Should consist only of functions
access to data is efficient, but
cannot easily be exchanged
Secret e.g., set/get methods for fields of
objects
Module Should specify what is
provided (exported)
required (imported)
many languages support only the
former
30
 Information hiding
Client

Possible module secrets:

implementation
how the algorithm works
data formats
Module representation of data structures,
Interface
states
user interfaces (e.g., AWT)
texts (language e.g., get text
Secret library)
ordering of processing (Design
Module Pattern Strategy, Visitor)
location of computation in a
distributed system

31
II. MODULARIZATION
TECHNIQUES

1. Module
2. Relations between modules
3. Specific techniques for design for change

32
2.1. Definition

• Let S be a set of
modules M1
S = {M1, M2, . ., Mn}
• A binary relation r M2
on S is a subset of
… r
SxS
• If Mi and Mj Î S, Mn-1
Mn
a pair <Mi, Mj> Î r
can be written as
System
Mi r Mj

33
2.2. Classification
• delegates-to (delegation)
• is-a (inheritance)
M1
• has-a (aggregation)
• is-component-of,
comprises (composition) M2
• accesses-a (access … r
relation)
• is-privileged-to, owns-a Mn-1
(security) Mn
• calls
• is-called-by System
• relies-on (uses)

34
2.3. USES relation: A uses B
• Module A uses (relies-on) module B iff A
requires a correct implementation of B for its
own correct execution. A
– It is “statically” defined
– A is a client of B; B is a server
• Requires an implementation may mean:
– A delegates work to B (delegation relation)
– A accesses a variable of B through the B’s
uses
interface (access relation)
– A depends on B to provide its functions: A calls B
OR B calls A B
• The uses relation may be a partial order (a tree
or a dag) or a total order, then the system is
called hierarchical or layered
• USES should be a hierarchy to make the
software easier to understand, build and test

35
Example:
modular representation with OOP
USES HAS IS
class B class B class B
{ { {
… … …
… … …
} } }

class A class A class A extends B

{ { {
… … …
… … …
void test() {
B obj = new B (); B obj = new B (); }
…. ….
} }
}

36
Hierarchy
• Organizes the modular
structure through levels of
abstraction
• Each level defines an M M level 0
abstract (virtual) machine 5 6
for the next level level 1
• Level can be defined M2 M3 M4
precisely
– Mi has level 0 if no Mj exists
s.t. Mi r Mj
– let k be the maximum level of M1 level 2
all nodes Mj s.t. Mi r Mj. Then
Mi has level k+1

37
Discussion: USE relation

Delegation With hierarchy

class Employee {
float salary = 30000;
class B }
{
methodB(){…} class Developer extends Employee {
… float bonus = 2000;
}
public static void main(String args[])
class A
{ {
B obj = new B ();
methodA() {
Employee obj = new
obj.methodB(); Employee();
} ….
} System.out.println
("Salary is:"+obj.salary);
}
} 38
 2.4. IS-COMPONENT-OF relation

• Used to describe a higher level module as

constituted by a number of lower level modules

A IS-COMPONENT-OF B B COMPRISES A
B consists of several modules,
of which one is A
M M M M M M1
7 8 9 5 6

M2 M3 M4
M2 M3 M4

M M M M M
M1 They are a hierarchy 7 8 9 5 39
6
 IS-COMPONENT-OF relation

• Used to describe a higher level module as

constituted by a number of lower level modules
• If MS,i={Mk|MkÎS Ù Mk IS-COMPONENT-OF Mi}
we say that MS,i IMPLEMENTS Mi

M M M M M
7 8 9 5 6

M3 M4 MS,2={M7, M8 ,M9} IMPLEMENTS M2

M2

M1 40
 Example: OO relations
• Aggregation:
– Defines objects or object classes as composed of simpler
components that constitute the parts of other objects.
– This is a PART-OF relation (differs from IS-COMPOSED-OF)

Cardinality of the constituents Behaviors of the constituents

Triangle Person
1
3
Point Heart Brain Hand
Triangle USES Point Person HAS Heart, Brain, Hand
Point IS-A-PART-OF Triangle Person IS-COMPOSED-OF Heart, Brain, Hand
Not Triangle IS-COMPOSED-OF Point 41
 2.5. CALLS relation

• A allocates an instance of B
• A calls B by exception or event (not A
by other resources such as types,
functions, procedures, variables,
etc.) calls
public class className {
public void deposit(double amount)
throws RemoteException { B
// Method implementation
throw new RemoteException();
}
//Remainder of class definition
}

42
II. MODULARIZATION
TECHNIQUES

1. Module
2. Relations between modules
3. Specific techniques for design for change

43
3.1. Constant configuration

• Factoring constant values into symbolic constants

is a common implementation practice
• Example:
In C:
#define MaxSpeed 5600;
class _const:
class ConstError(TypeError): pass
In Python: def _ _setattr_ _(self, name, value):
if self._ _dict_ _.has_key(name):
raise self.ConstError, "Can't rebind const(%s)"%name
self._ _dict_ _[name] = value
def _ _delattr_ _(self, name):
if self._ _dict_ _.has_key(name):
raise self.ConstError, "Can't unbind const(%s)"%name
raise NameError, name

import sys
44
sys.modules[_ _name_ _] = _const( )
3.2. Conditional compilation
• Have several versions of a (part of) program in the same
source file.
• Compile the program accordingly to
– Its state at runtime
– Target platform
– Ambitious testing
– ..
• Example: C pre-processor
//...source fragment common to all versions...
#ifdef hardware-1
//...source fragment for hardware 1 ...
#endif
#ifdef hardware-2
//...source fragment for hardware 2 ...
#endif

45
3.3. Software generation

• Example: interface prototyping tools

– Once an interface is defined, implementation can be
done
• first quickly but inefficiently
• then progressively turned into the final version
– Initial version acts as a prototype that evolves into the
final product

46
III. SOFTWARE
ARCHITECTURES

1. Definition
2. Common architectures
3. Domain specific architectures
47
1.1. What is software architecture ?

• Shows
– gross structure of the system to be defined
– organization of the system to be defined
• Describes
– main components of a system
– external visible properties of those components
– relationships among those components
– rationale for decomposition into its components
– constraints that must be respected by any design of the
components
• Guides
– the development of the design

48
1.2. What are software components?

• Goal
– build systems out of pre-existing libraries of components
– as most mature engineering areas do
• Examples
– STL for C++
– JavaBeans and Swing for Java

49
2. Common architectures
• Pipes (data flow) and filters
(operations): A component reads
streams of data on its inputs and
produces streams of data on its Pipes and filters
outputs, delivering a complete
instance of the result in a
standard order.
• Blackboard (shared data
structure): Data store can
contact and trigger actions in
components when data becomes Blackboard
available.
• Event-based control (implicit
invocation): Each component can
respond to externally generated
events from other components or
the system’s environment.
Event based control

50
3. Domain-specific architectures

• MVC architecture:
– Significant amount of user interaction

change notification Display model

for users
request
Model View
store data
change user’s
actions view’s
selection
Controller
Interact with users,
perform command
51
Domain-specific architectures

• Distributed system architectures:

– From two tiered
• Client-server
– to three tiered
Web browser Web server
(client) Requests (server)
for service
(pages)

User interface Decode

Requests Application
(client) service
for service server
request (database)
(database) nd
(2 tier)

52
4. Component integration
• The CORBA (Common Object Request Broker Architecture)
Middleware
• Clients and servers connected via an Object Request Broker
(ORB)
• Interfaces provided by servers defined by an Interface
Definition Language (IDL)
• In the Microsoft world: DCOM (Distributed Component Object
Model)

Application Domain CORBA

Objects Interfaces Facilities

Object Request Broker

CORBA Services
53
 Quiz and Exercises

• Now let’s go over what you have learned through

this lesson by taking a quiz.
• When you’re ready, press Start button to take the
quiz

54
1. Which of the following statements
are true ? Why ?
A. Designing module interfaces of a software
means designing a software architecture at high
level.
B. The program structure is used as a framework
for component integration.
C. A module represents a concern where its
solution could be changed later.
D. Module interface should present the solutions
that client modules needs.
E. When a module X requires a correct
implementation of a module Y for performing its
task, it’s an USE relation.

55
2. What are the desirable properties of
a modular structure?
A. Reused, independently developed,
independently exchanged, used
B. Reused, independently developed,
independently tested, used
C. Abstraction, anticipation of change
D. Anticipation of change

56
3. Exercises
• The XYZ Wear Corporation plans to develop (from system
analysis to operation testing) the web site for selling wears
through Internet and to form the new whole system as
follow:

Selling Web Site

Main System

Member
Internet

Administration
Administration
Search
Product

Of
Selling
DB Selling, Products,
Logistics, Dealing
Order
Customer

Transportation

Operation
Customer

57
3. Exercises

1. Decompose the selling website (i.e. online selling

software) using three approaches: functional,
algorithmic and object-oriented.
2. Apply the modularization techniques for
designing the online selling software. Point out the
modularization techniques that are suitable to cope
with the changes identified in the 1st in-class
assignment. Explain.
3. Point out a software architecture that is
convenient to build the online selling software.
Explain.

58
Expected result

1. Decompose the selling website (i.e. online selling

software) using three approaches: functional,
algorithmic and object-oriented.
- Decomposition tree: naming nodes, naming edges
(control flow)
- Describe the total workflow of program (how to use all
provided functions once at time)
- Analyze the advantage, disadvantages of each approach

59
• 2. Apply the modularization techniques for
designing the online selling software. Point out
the modularization techniques that are suitable to
cope with the changes identified in the 1st in-
class assignment. Explain.
– Identify design decisions
– Identify modules
– Identify relationships between modules.
– Illustrate the interactions among modules (as figured in
the slides)
à Explain your idea by answering these questions:
• How to define the structure of this modular system?
• What are the desirable properties of that structure?

60
• 3. Point out a software architecture that is
convenient to build the online selling software.
Explain.
– Identify the architecture
– Identify the components of this architecture
– Explain the relationship between components of this
architecture
– Check the components of program structure, comparing
to that of software architecture.

61