Advanced Software

Engineering

Lecture #3
Software Architecture & Design
Software Design
• Software design deals with transforming the customer
requirements, as described in the SRS document, into a form (a set
of documents) that is suitable for implementation in a
programming language.
• A good software design is seldom arrived by using a single step
procedure but rather through several iterations through a series of
steps.
• Design activities can be broadly classified into two important parts:
• Preliminary (or high-level) design and
• Detailed design.
Preliminary and Detailed design activities
• High-level design means identification of different modules and
the control relationships among them and the definition of the
interfaces among these modules.
• The outcome of high-level design is called the program structure
or software architecture.
 Preliminary and detailed design activities
• During detailed design, the data structure and the algorithms of
the different modules are designed.
• The outcome of the detailed design stage is usually known as the
module-specification document.
Cohesion
• Most researchers and engineers agree that a good software design
implies clean decomposition of the problem into modules, and the
neat arrangement of these modules in a hierarchy.
• Cohesion is a measure of functional strength of a module.
• The primary characteristics of neat module decomposition are high
cohesion and low coupling.
• A module having high cohesion and low coupling is said to be
functionally independent of other modules.
Classification of cohesion
 Classification of cohesion
• Coincidental ( Random) cohesion: A module is said to have
coincidental cohesion, if it performs a set of tasks that relate to each
other very loosely, if at all. It is likely that the functions have been
put in the module out of pure coincidence without any thought or
design. For example, in a transaction processing system (TPS), the
get-input, print-error, and summarize members functions are
grouped into one module. The grouping does not have any relevance
to the structure of the problem
• Logical cohesion: A module is said to be logically cohesive, if all
elements of the module perform similar operations, e.g. error
handling, data input, data output, etc. An example of logical
cohesion is the case where a set of print functions generating
different output reports are arranged into a single module.
 Classification of cohesion
• Temporal cohesion: When a module contains functions that are
related by the fact that all the functions must be executed in the same
time span, the module is said to exhibit temporal cohesion. The set of
functions responsible for initialization, start-up, shutdown of some
process, etc. exhibit temporal cohesion.
• Procedural cohesion: A module is said to possess procedural
cohesion, if the set of functions of the module are all part of a
procedure (algorithm) in which certain sequence of steps have to be
carried out for achieving an objective, e.g. the algorithm for decoding a
message.
• Communicational cohesion: A module is said to have
communicational cohesion, if all functions of the module refer to or
update the same data structure. e.g. the set of functions defined on an
array or a stack.
 9

Classification of cohesion
• Sequential cohesion: A module is said to possess sequential
cohesion, if the elements of a module form the parts of sequence,
where the output from one element of the sequence is input to the
next. For example, in a TPS, the get-input, validate-input, sort-
input functions are grouped into one module.
• Functional cohesion: Functional cohesion is said to exist, if
different elements of a module cooperate to achieve a single
function. For example, a module containing all the functions
required to manage employees’ pay-roll exhibits functional
cohesion.
Coupling

• Coupling between two modules is a measure of the degree of

interdependence or interaction between the two modules.
• A module having high cohesion and low coupling is said to be
functionally independent of other modules.
• If two modules interchange large amounts of data, then they are
highly interdependent. The degree of coupling between two modules
depends on their interface complexity.
Classification of Coupling
 Classification of Coupling
• Data coupling: Two modules are data coupled, if they
communicate through a parameter. An example is an elementary
data item passed as a parameter between two modules, e.g. an
integer, a float, a character, etc. This data item should be problem
related and not used for the control purpose.
• Stamp coupling: Two modules are stamp coupled, if they
communicate using a data item such as a record in PASCAL or a
structure in C.
 Classification of Coupling
• Control coupling: Control coupling exists between two modules,
if data from one module is used to direct the order of instructions
execution in another. An example of control coupling is a flag set in
one module and tested in another module
• Common coupling: Two modules are common coupled, if they
share data through some global data items.
• Content coupling: Content coupling exists between two
modules, if they share code, e.g. a branch from one module into
another module.
Classification of Design
• Functional Oriented Design
• Class Oriented Design
Function-oriented design
• A system is viewed as something that performs a set of functions.

• Starting at this high-level view of the system, each function is

successively refined into more detailed functions.

• For example, consider a function create-new-library-member which

essentially creates the record for a new member, assigns a unique
membership number to him, and prints a bill towards his
membership charge. This function may consist of the following sub-
functions:
• assign-membership-number
• create-member-record
• print-bill
Function-oriented design

• Each of these sub-functions may be split into more detailed sub

functions and so on.

• The system state is centralized and shared among different functions,

e.g. data such as member-records is available for reference and
updating to several functions such as

 create-new-member
 delete-member
 update-member-record
 Object-oriented design

• In the object-oriented design approach, the system is viewed as

collection of objects (i.e. entities).
• The state is decentralized among the objects and each object
manages its own state information.
• For example, in a Library Automation Software, each library
member may be a separate object with its own data and functions to
operate on these data.
 Object-oriented design

• In fact, the functions defined for one object cannot refer or change
data of other objects.
• Objects have their own internal data which define their state.
• Similar objects constitute a class. In other words, each object is a
member of some class. Classes may inherit features from super class.
• Conceptually, objects communicate by message passing.
 Object-oriented design approach

• Unlike function-oriented design methods, in OOD, the basic

abstraction are not real-world functions such as sort, display, track,
etc, but real-world entities such as employee, picture, machine, radar
system, etc.
• For example in OOD, an employee pay-roll software is not developed
by designing functions such as update-employee-record, get-
employee-address, etc. but by designing objects such as employees,
departments, etc.
 20

Software Design Components

Principle

Criteria

Techniques
21
 22

Myth about Abstraction

Problem Statement

Our task is to design an management

information system for a hospital, it should
include patient management, doctors
management , laboratory management ,
inventory of equipment and medicines,
 23

Traditional Approach

Programmers Approach:

‘Which Technology to use for implementation ‘

System Architect Approach

Forget the technology, first understand what to do in detail ,

generate Requirement Specification (RS)– This is Abstraction
 24

Abstraction

What to Do not How to do !!

 A view of an object that focuses on the

information relevant to a particular purpose and
ignores the remainder of the information.
IEEE Standard 610.12-1990

 Abstraction is generally used for handling and

reducing complexity
 25

Abstraction continue...

Abstraction is simply removal of unnecessary

details.
To design a complex system, you must identify
what about that part other parts should know in
order to design their part
 26

Benefits of Abstraction
Gives the designer freedom to ignore certain
details, for the time being, and to determine or
design the "big picture" aspects of his design
 27

Decomposition

Splitting one system into smaller components

 Designing the components independently.

 For the outside world the components are

reduced to their interfaces

 “Divide and Conquer”

 28

Decomposition Rules

Don't design components to correspond to execution

steps – look for similar tasks – No Run-time binding

Decompose so that all design decision have a

minimum effect to the rest of the system – anything

that soaks the system will be expensive to change

 29

Decomposition continues....

 Components should be specified by all information needed to use

the component – nothing less and nothing more!
 30

Subsystems

A Subsystem is a secondary or subordinate

system within a system.

IEEE Standard 610.12-1990

 31

Subsystems
 A subsystem is a functionally cohesive grouping of
classes that is a major part of a larger aggregate system

 Can be independently ordered, configured or delivered

 Subsystems are related to each other via dependency

relations, and communicate with each other via well-
defined interfaces
 32

Subsystems

Decompose by functional services i-e Database

Subsystem, User Interface Subsystem etc
33
 34

Subsystem Example

Student Accounts
Management

Hrm and Payroll Library

Management
 35

Layers
Decomposition of the system into smaller, more
manageable units, that are layered hierarchically.

Each layer supplies one level of abstraction

 A layer only uses services of the next
underlying layer
 Layers can be tested independently
36
37
 38

Layers Rule
Layer can request for services from exactly one
layer below it.

Layer can respond to a request of a layer exactly

one layer above it.

Total Layers = N = 3
Request = N-1
Response = N+ 1
Example on next slide
 39

Layer Rule

High Level Architectural Diagram

Services Layers

Request

Operations Layers

Response

Student Data Management

 40

Tree-Structures

It’s a combination of subsystem and layers

 When you start at the root each node can be

reached in exactly one way

 Usually the nodes can be placed in different layers

a node can be considered as the representative of his
subtree
41
 42

Problem
 An automated ticket issuing system used by passengers at a
railway station. The System should also allow reservation
of seats and give some route information. The passenger
should be able to pay for the ticket at the counter also.

To Do : We have to design the architecture of the above

system after selecting a specific principle and proper
assumptions.
 43

Possible Solution - Subsystem Based

Automated Ticketing
System

Seat Reservation Route Information Transaction

Train Data Bank Data

 44

Possible Solution - Layer Based

 45

Internal Abstraction : Modularization

“The process of breaking a system into

components to facilitate design and
development; an element of modular
programming “
 46

Encapsulation

A view of a problem that extracts the essential

information relevant to a particular purpose and
ignores the remainder of the information.
[IEEE, 1983]

Encapsulation is the grouping of related ideas into

one unit, which can thereafter be referred to by a
single name.
 47

Encapsulation

Isolating a system function or a set of data and

operations on those data within a module.

Providing precise specifications for the module

Common elements of an abstraction are grouped

together and separated from other components;
e.g.an Abstract Data Type
 48

Encapsulation Example

 Simple digital alarm clock is a real-world object that

a layman can use and understand. They can understand
what the alarm clock does, and how to use it through
the provided interface (buttons and screen), without
having to understand every part inside of the clock.
Similarly, if you replaced the clock with non-digital
model, the layman could continue to use it in the same
way, provided that the interface works the same.
 49

Another Encapsulation Example

A relational database is encapsulated in the sense that its only

public interface is a Query language (SQL for example), which
hides all the internal machinery and data structures of the
database management system.
 50

Information hiding

Information Hiding is software design technique

in which each module's interfaces reveal as little
as possible about the module's inner workings
and other modules are prevented from using
information about the module that is not in the
module's interface specification.
 51

Another Definition of Information Hiding

Every module is characterized by its knowledge of a design

decision which it hides from all others. Its interface or definition
was chosen to reveal as little as possible about its inner workings.
 52

Information Hiding

Information hiding gives the designer the freedom to modify how

the responsibility is fulfilled by a module/object.
Components should communicate only through well-defined
interfaces.
53
 54

Software Design Components

Principle

Criteria

Techniques
55
 56

Extensibility

Extendibility is the ease of adapting software

products to changes of specification.
 57

Extensibility

For small programs change is usually not a

difficult issue; but as software grows bigger, it
becomes harder and harder to adapt.

A large software system often looks to its

maintainers as a giant house of cards in which
pulling out any one element might cause the
whole structure to collapse
 58

Extensibility

We need extendibility because at the basis of all software lies

some human phenomenon and hence indecisiveness
 59

Principles for achieving Extensibility

Design simplicity: a simple architecture will

always be easier to adapt to changes than a complex one

Decentralization: the more autonomous the

modules, the higher the likelihood that a simple change
will affect just one module, or a small number of
modules, rather than triggering off a chain reaction of
changes over the whole system.
 60

Problem Statement

 In the electric subsystem of the house where there are

electric wires and appliances running. Each appliance is

having it’s own functionality and working. Each appliance is

having it’s own clear boundary into which it works.

i. Task is to identify level of coupling and cohesion in the

scenario.

ii. Write a scenario which should reverse the solution

 61

Solution to example

The given scenario is having no interdependency

and each appliance is encapsulated within its
own boundary so the system is having low or no
coupling but high level of cohesion.

Hint for Task ii: “Central”

62
63
 64

Open / Close Principle

Bertrand Meyer: “Software entities like
classes, modules and functions should be closed
but open for extension.
Closed
 The source code of the module inviolate; no one
is allowed to make changes to the code the
module can be used without risk
 65

Open / Close Principle

Open

 The module is open for extension according to new requirements

the module can be extended to behave in new and different ways.
 66

Open / Closed Principle

A module that is open for extension is a module whose behavior

can be altered to suit new requirements.

A module that is closed for modification is a module whose source

code is frozen and cannot be changed
 67

The “Open/Closed principle” – Usage in

an object oriented paradigm

The Open/Closed principle can be applied in

object oriented paradigms with the help of
inheritance and polymorphism:

The interface of the module becomes an abstract

class A

 If needed new Subclasses of A can be derived;

these subclasses may extend A
 68

What is Class
Basic implementation unit in OOP.

It encapsulate data members and methods.

Classes have objects or classes are assessed via

their objects.

Data members are accessed through getters and

setters methods.
 69

public class test

{
int a ;
float b;
public class()
{}
void seta(int a)
{
this.a=a;
}
int geta ()
{
return this.a;
}
 70

Abstract Classes

Abstract class is a class that can not be

instantiated, it exists extensively for inheritance
and it must be inherited. There are scenarios in
which it is useful to define classes that is not
intended to instantiate; because such classes
normally are used as base-classes in inheritance
hierarchies
 71

Inheritance

 It implies the functionality of data sharing between

super and sub class.

 All the data members and methods of super class are

available for use in sub class but not vice-versa.

 Subclass extends the functionality of super class to use

the base class methods.
 72

Example of Abstract class and Inheritance

In an object-oriented drawing application, you

can draw circles, rectangles, lines, Bezier curves,
and many other graphic objects. These objects
all have certain states (for example: position,
orientation, line color, fill color) and behaviors
(for example: moveTo, rotate, resize, draw) in
common.
73
 74

abstract class GraphicObject

{
int x, y;
void moveTo(int newX, int newY)
{ ... }
abstract void draw();
abstract void resize();
}
 75

class Circle extends GraphicObject

{ void draw()
{ ... }
void resize()
{ ... }
}
 76

Polymorphism
 In the context of object-oriented programming, is the ability
to create a variable, a function, or an object that has more
than one form.

 Polymorphism is the ability to process objects differently

depending on their data types.

 Polymorphism is the ability to redefine methods for derived

classes.
 77

Types of Polymorphism

Compile time Polymorphism

Compile time Polymorphism also known as

method overloading

Method overloading means having two or more

methods with the same name but with different
signatures
 78

Example of Compile Time Polymorphism

 79

Runtime Polymorphism

Run time Polymorphism also known as method overriding

Method overriding means having two or more methods with the

same name , same signature but with different implementation
 80

Example of Run-time Polymorphism

81
82
 83

Example
We have to design a banking system in which
there are several clients who are availing the
facility of maintaining the account in the bank. As
an international norm bank is offering multiple
type of accounts to it’s customers like savings,
current etc. Each account is having a facility of
deposit and withdrawal attached with it for it’s
client.
 84

Example

Task to do:

We have to design the system in such a way that

should accommodate the addition of new
account types i-e profit and loss account etc
without change in the design of the system
85
 86

Another Example
 You are going to design a library application where a particular request for

issuance of book is passed through a issueValidator to approve the issue request.

The issuanceValidator looks to see if the balance of book is above certain values

and then approves the request.

 Given this problem, one of the developer comes up with the following classes. The

libraryrequestHandler can assess a issue request. This class holds the balance of

remaining books and period of hold of books for a particular student account.
 87

Code in Java
 88

public class libraryRequestHandler {

private int balance;
private int period;
public libraryRequestHandler(int balance, int period) {
this.balance = balance;
this.period = period;
}
public void approverequest(issuanceValidator validator) {
if(validator.isValid(balance))
System.out.println(“Request approved...");
else
System.out.println("Sorry more books are in balance...");
}}
 89

PersonalLoanValidator Class
public class issuanceValidator {
public issueanceValidator() {
}
public boolean isValid(int balance) {
if(balance>5)
return true;
else
return false;
}
}
 90

Task To Do

• In future the bank should be able to handle business type of

accounts also.

• Identify the violation of open/close principle in classes defined.

• Reverse Engineered it and generate the class design of the code

and create a solution with no violation of open/close principle