Software Design & Architecture

Cohesion

A measure of the closeness of the relationships

between elements of a component or "module"
of a system.
3
 4

Scale of Cohesion Vs
Maintainability
 5

General Rule of Cohesion

 A module will be cohesive if most of the methods defined
in a class use most of the data members most of the time.
If we find different subsets of data within the same
module being manipulated by separate groups of
functions then the module is not cohesive and should be
broken down as shown below.
6
 7

Extensibility

Extendibility is the ease of adapting software

products to changes of specification.
 8

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
 9

Extensibility

We need extendibility because at the basis of all

software lies some human phenomenon and
hence indecisiveness
 10

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.
 11

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

 12

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”

13
 14

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
 15

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.
 16

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
 17

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
 18

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.
 19

public class test

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

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
 21

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.
 22

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.
23
 24

abstract class GraphicObject

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

class Circle extends GraphicObject

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

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.
 27

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
 28

Example of Compile Time Polymorphism

 29

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
 30

Example of Run-time Polymorphism

31
32
 33

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.
 34

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
35
 36

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.
 37

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...");
}}
 38

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

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