WOU Classification: Restricted

Faculty Name Dr. Naveed Jeelani Khan

Software System Design Email ID [email protected]

MODULE I

For lecture purposes only; please refrain from further distribution

 WOU Classification: Restricted

Introduction to Course Outline

For lecture purposes only; please refrain from further distribution

 WOU Classification: Restricted

• Meta Class:
• Syllabus
• Punctuality -> Attendance
• Assessments
• Discipline->Dressing Code->Hierarchy

• CONTEXT of the Course:

• Problem -> Solution
• Devices
• Program… Using Programming Languages
• Set of Programs -> Software -> Coding
• Coding = 30%. Analysis 70%.
• Software Engineering…Life Story of software… Software Design

For lecture purposes only; please refrain from further distribution

 WOU Classification: Restricted

Introduction to Software Design

• Definition: Transforming user requirements into a form suitable for coding and implementation.
• Role in SDLC: First step in Software Design Life Cycle (SDLC), moving focus from problem domain
to solution domain.

SRS Design
Document Design Documents
Activities

• An analysis technique helps elaborate the customer requirements through careful thinking:

• And at the same time consciously avoids making any decisions regarding implementation.

• The design model is obtained from the analysis model through transformations over a series of
steps
• Decisions regarding implementation are consciously made. 4
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Types
HIGH-LEVEL DESIGN DETAILED DESIGN (LOW LEVEL)

• The outcome of high-level design: • For each module, design:

• Program structure (or software architecture). • Data structure
• Several notations are available to represent high- • Algorithms
level design:
• Usually a tree-like diagram called structure chart is used. • Outcome of detailed design:
• Other notations: Jackson diagram or Warnier-Orr • Module specification.
diagram can also be used.

5
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Good and Bad Designs

• There is no unique way to design a system.
• Even using the same design methodology:
• Different designers can arrive at very different design
solutions.
• We need to distinguish between good and bad designs.

OBJECTIVES OF SOFTWARE DESIGN

 Correctness: Aligns with the requirements.

 Completeness: Includes all components like data structures, modules, and interfaces.

 Efficiency: Optimal resource usage.

 Flexibility: Adaptability to changes.

 Consistency: Uniformity across the design.

 Maintainability: Simplified for ease of maintenance.

6
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Software Design Principles

• Managing Complexity: Essential to
reduce effort and minimize errors.
• Problem Partitioning (Decomposition):
Breaking down large problems into
manageable pieces.
• Abstraction: Hiding details to focus on
the essence of the component.
• Modularity: Dividing software into
manageable, self-contained modules.

7
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Problem Partitioning (Decomposition)

• Definition: Breaking a large problem into
smaller, manageable pieces.  A popular way to demonstrate the
 The small parts are then taken up one by one and solved separately
decomposition principle: Try to break a
(Divide and Conquer).
bunch of sticks tied together versus
 The idea is that each small part would be easy to grasp and can be breaking them individually.
easily solved.
 Example use of decomposition principle:
 The full problem is solved when all the parts are solved.
You understand a book better when the
• Benefits: Easier understanding, testing, contents are organized into independent
modification, and expansion. chapters compared to when everything
is mixed up.
• Complexity: Increased partitions can
increase cost and complexity.

8
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Abstraction BASICS:
 Simplify a problem by omitting
unnecessary details: Focus attention on
• Functional Abstraction: Focus on the method without internal
details. only one aspect of the problem and
• Data Abstraction: Hides data details, forming the basis for Object- ignore irrelevant details.
Oriented Design.
 Suppose you are asked to develop an
overall understanding of some country.
 A module is unaware (how to invoke etc.) of the higher level modules.
 No one in his right mind would meet
 Lower-level modules: Do input/output and other low-level functions.
all the citizens of the country, visit
 Upper-level modules: Do more managerial functions. every house, and examine every tree
of the country, etc.
 The principle of abstraction requires:  You would possibly refer to various
 Lower-level modules do not invoke functions of higher level types of maps for that country.
modules.  A map, in fact, is an abstract
 Also known as layered design. representation of a country.

9
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

D1 ..
Abstraction and Decomposition Principles are Used in Design in
two principal ways:
D2 ..
D3 ..
Data

 Modular Design
F1 .. Functions
F2 ..
 Layered Design F3 ..
F4 ..
F5 ..
 A module consists of:
 Several functions
 Associated data structures.

Modularity
• Definition: Dividing software into modules.
• Modules are almost independent of each other
• Desirable Properties: Well-defined systems, single objectives, ease of use.
• Advantages: Facilitates team collaboration, code reuse, and systematic testing. 10
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Modular Design
Fan Fan LAYERED DESIGN
out=2 in=0
Fan Fan
out=1 in=1

Fan
in=2
 If modules are independent: They can be understood
separately => Reduces the complexity.  Neat arrangement of modules in a hierarchy
 To understand why this is so, Remember that it is very difficult (Layered Design) means:
to break a bunch of sticks but very easy to break the sticks  Low fan-out
individually.
 Control abstraction
• Functional Independence: Achieved through cohesion and
coupling.
• Information Hiding: Protecting data within a module from other
modules. 11
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

COHESION AND COUPLING

 Modules should display:

 High cohesion

 Low coupling.

 Cohesion is a measure of functional strength of a module.

 A cohesive module performs a single task or function.

 Intra-module relationship, aiming for high functional strength.

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

interdependence or interaction between the two modules.
 Inter-module relationship, aiming for low dependency.

 A module having high cohesion and low coupling is functionally

independent of other modules. A functionally independent
module has minimal interaction with other modules.

12
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Design Approaches
 Two fundamentally different software design approaches:

 Function-oriented design

 Object-oriented design

FUNCTION-ORIENTED DESIGN - OVERVIEW AND CHARACTERISTICS

Example
• Focuses on functions or procedures
• Emphasizes on the sequence of tasks and how they interact  The function create-new-library- member:

 Creates the record for a new member,

 Assigns a unique membership number

 Prints a bill towards the membership

13
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Function-Oriented Design - Design Process

Steps Involved in the Design Process:
1. Identify major functions
 A system is looked upon as something that performs a set of
2. Break down into sub-functions functions.
3. Design data flow between functions
 Starting at this high-level view of the system:
4. Create flowcharts and pseudocode
 Each function is successively refined into more detailed
functions.
 Functions are mapped to a module structure.

 Each subfunction is split into more detailed subfunctions

14
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Function-Oriented Design - Design Notations

• Common Notations Used in Function-Oriented Design:
• Flowcharts

• Data Flow Diagrams (DFDs)

• Structure Charts

15
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Object-Oriented Design - Overview and

Characteristics
• Focuses on objects rather than functions
• Emphasizes on data encapsulation,
inheritance, and polymorphism
 System is viewed as a collection of objects (i.e. entities).

 System state is decentralized among the objects

 Each object manages its own state information.

16
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Object-Oriented Design - Important Concepts

Key Concepts in Object-Oriented Design:
• Objects: Entities combining data and behavior Object-Oriented Design Example:
• Classes: Blueprints for objects
 Library Automation Software:
• Messages: Communication between objects
 Each library member is a separate object
• Inheritance, Polymorphism, Encapsulation
 With its own data and functions.

 Functions defined for one object:

 Cannot directly refer to or change data of

other objects.

17
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

 Objects have their own internal data that defines

their state.
Object-Oriented versus Function
 Similar objects constitute a class. Oriented Design

 Each object is a member of some class. Unlike function-oriented design,

 Classes may inherit features from a super class. • In OOD the basic abstraction is not
functions such as “sort”, “display”,
 In OOD: Software is not developed by designing “track”, etc.,
functions such as:
• But real-world entities such as
 update-employee-record, “employee”, “picture”, “machine”,
 get-employee-address, etc.
“radar system”, etc.

 But by designing objects such as:

 employees,

 departments, etc.
18
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Software Development Life Cycle

Definition of SDLC:
• A structured approach to software
development
• Ensures systematic progression through
stages
Importance in Software Development:
 Software life cycle (or software process) is
• Reduces risk of failure
a series of identifiable stages that a
• Improves quality and maintainability software product undergoes during its life-
 A software life cycle model (or process model) is time:
a descriptive and diagrammatic model of
 Feasibility study
software life cycle:
 Requirements analysis and specification,
 identifies all the activities required for product
development,  Design,

 establishes a precedence ordering among the  Coding,

different activities,
 Testing
19
 Divides life cycle into phases.
 Maintenance.
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

 The development team must identify a suitable life cycle model and then adhere to it.

 Primary advantage of adhering to a life cycle model is that it helps development of software in a systematic
and disciplined manner.

 When a program is developed by a single programmer : He/she has the freedom to decide the exact steps.

 BUT When a software product is being developed by a team:

 there must be a precise understanding among team members as to when to do what,

 Otherwise, it would lead to chaos and project failure.

 A life cycle model defines entry and exit criteria for every phase.

 A phase is considered to be complete only when all its exit criteria are satisfied.

 E.g. The phase exit criteria for the software requirements specification phase:

 Software Requirements Specification (SRS) document is complete, reviewed, and approved by the customer.

 A phase can start: only if its phase-entry criteria have been satisfied.
20
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Many Software life cycle models have been proposed:

• Classical waterfall model

• Iterative waterfall,

• Evolutionary,

• Prototyping, and

• Spiral model

21
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Classical Waterfall Model

Overview : Feasibility Study
• Linear and sequential model
Req. Analysis
• Each phase must be completed before
the next begins Design
Characteristics:
Coding
• Easy to manage
• Rigid and less flexible Testing

Maintenance

22
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Design Phase
• Design phase transforms requirements specification into a form suitable for
implementation in some programming language.

 In technical terms: during design phase, software architecture is derived from the SRS document.

 Two design approaches: traditional approach & object-oriented approach.

 Traditional approach consists of two activities:

 Structured analysis
 Structured design
 Identify all the functions to be performed, data flow
 After structured analysis, carry out structured
among the functions.
design:
 Decompose each function recursively into sub-
functions.  architectural design (or high-level design)

 Identify data flow among the subfunctions as well.  detailed design (or low-level design).
 Carried out using Data flow diagrams (DFDs).
23
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Object Oriented Design

• Identify various objects (real world entities) occurring in the
problem:
• identify the relationships among the objects.
• For example, the objects in a pay-roll software may be:
employees, managers, pay-roll register, Departments, etc.
 Object structure: further refined to obtain the
detailed design.
 OOD has several advantages:

 lower development effort,

 lower development time,

 better maintainability.

24
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Iterative Waterfall Model

 Classical waterfall model is idealistic AS IT assumes
that no defect is introduced during any Feasibility Study
development activity.
Req. Analysis
 in practice: defects do get introduced in almost
every phase of the life cycle. Design
• Overview of Iterative Waterfall Model:
Coding
• Similar to Waterfall but allows revisiting previous phases
• Better handling of changes Testing
• Characteristics:
Maintenance
• More flexible than Classical Waterfall
• Suitable for projects with evolving requirements

25
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Prototyping Model
 A prototype is a toy implementation of a system:

 limited functional capabilities, Build Prototype

 low reliability, Requirements Customer Customer

Gathering Quick Design Evaluation of satisfied Design
 inefficient performance. Prototype

Refine Implement
• Overview of Prototyping Model: Requirements
• Involves creating prototypes to refine requirements
Test
• Focuses on user feedback and iterative refinement
• Characteristics: Maintain
• Allows users to visualize the product early
• Can lead to better requirement gathering

26
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Evolutionary Model
 Evolutionary model (aka successive versions or incremental model): The system is broken
down into several modules which can be incrementally implemented and delivered.
 First develop the core modules of the system.

 The initial product skeleton is refined into increasing levels of capability by adding new
functionalities in successive versions.

Overview of Evolutionary Model:

• Develops the system incrementally C
• Continual refinement of the product
A AB A
Characteristics: B
• High flexibility and adaptability
• Suitable for projects with unclear requirements

27
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Spiral Model
 Proposed by Boehm in 1988.

 Each loop of the spiral represents a phase of the software process:

 the innermost loop might be concerned with system feasibility,

 the next loop with system requirements definition,

 the next one with system design, and so on. Determine Identify &
Objectives Resolve Risks
 There are no fixed phases in this model, the phases shown in the
figure are just examples.

• Overview of Spiral Model: Customer

Evaluation of Develop Next Level
• Combines iterative development with risk management Prototype of Product
• Focuses on early identification of risks and mitigation
• Each loop in the spiral is split into four sectors (quadrants).

• Characteristics:
• Highly flexible and adaptable
• Suitable for large and complex projects

28
For lecture purposes only; please refrain from further distribution
 WOU Classification: Restricted

Items Designed During Design Phase

• High Level:
• Module structure,
• Control relationship among the modules
• call relationship or invocation relationship
• Interface among different modules,
• Data items exchanged among different modules,
• Low Level:
• Data structures of individual modules,
• Algorithms for individual modules.

29
For lecture purposes only; please refrain from further distribution