Software design: Lecture 6 - Sheraz Pervaiz

1

Software Design

Lecture : 6


2

Software Design Components
Ø

Principle 

Ø

Criteria

Ø

Techniques


3


4

Myth about Abstraction
Problem Statement

ü

Our  task  is  to  design  an  management 
information  system  for  a  hospital,  it  should 
include 

patient 

management 

, 

management, 

laboratory 

doctors 

management 

inventory of equipment and  medicines, 

, 


5

Traditional Approach
ü

Programmers Approach:

Ø

‘Which Technology to use for implementation ‘

ü

System Architect Approach

ü


6

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

7

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


8

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


9

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”


10

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


11

Decomposition continues....

ü

 Components should be specified by all 
information  needed to use the component – 
nothing less and  nothing more!


12

Subsystems
A Subsystem is a secondary or subordinate 
system within a  system.

IEEE Standard 610.12­1990


13

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


14

Subsystems

Ø

Decompose by  functional services i­e Database 
Subsystem,  User Interface Subsystem etc


15


16

Subsystem Example

Student 
Management

Hrm and Payroll

Accounts

Library 
Management


17

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


18


19


20

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


21

Layer Rule
High Level Architectural Diagram
Services Layers
Request

Operations Layers

Response
Student Data Management