Tải bản đầy đủ (.pdf) (46 trang)

Software design: Lecture 11 - Sheraz Pervaiz

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (681.14 KB, 46 trang )

1

Software Design

Lecture : 11


2

Software Design Components
Ø

Principle 

Ø

Criteria(this lecture)

Ø

Techniques (this lecture)


3


4

Range of Cohesion
High Cohesion
Functional


Sequential
Communicational
Procedural
Temporal
Logical

Coincidental
Low


5

Sequential Cohesion
Ø

The output of one component is the input to 
another.

Ø

Occurs naturally in functional programming 
languages

Ø


6

Example
i.


Retrieve customer Data

ii.

 Retrieve customer order 

iii.

Generate invoice

iv.

Get and edit input data.


7

Functional Cohesion – Highly 
cohesive
Ø

Definition: Every essential element to a single 
computation is contained in the component.

Ø

A functionally cohesive module performs one 
and only one problem related task.



8

Examples
Ø

Calculate Net Pay

Ø

A complex module with numerous sub modules 
may still be functionally cohesive if all of its 
subordinate modules are only performed to carry 
out the task of the parent module.


9

Scale of Cohesion Vs 
Maintainability


10

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.


11


12

Extensibility
ü

Extendibility is the ease of adapting software 
products to changes of specification.


13

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 


14

Extensibility
ü

We need extendibility because at the basis of all 
software lies some human phenomenon and 
hence indecisiveness


15

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.



16

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.


17

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” 


18



19


20

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


21

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.


22

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 


23

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


24

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.


25

public class test
{
int a ;
float b;
public class()
{}
void seta(int a)
{


×