SOFTWARE SYSTEM DESIGN

INTRODUCTION TO SOFTWARE DESIGN

SRS Design
Document Design Documents
Activities

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

2
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-level
design:  Algorithms

 Usually a tree-like diagram called structure chart is  Outcome of detailed design:

used.
 Module specification.
 Other notations:

 Jackson diagram or Warnier-Orr diagram can

also be used.

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

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

5
PROBLEM PARTITIONING (DECOMPOSITION)

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

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

7
Abstraction and Decomposition Principles are Used in Design D1 ..
in two principal ways: D2 .. Data
D3 ..
 Modular Design F1 .. Functions
 Layered Design F2 ..
F3 ..
F4 ..
F5 ..

MODULARITY
 A module consists of:
 Several functions
 Associated data structures.

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

8
MODULAR DESIGN LAYERED DESIGN
Fan Fan
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.
 To understand why this is so, Remember that it is very difficult to  Neat arrangement of modules in a hierarchy
break a bunch of sticks but very easy to break the sticks means:
individually.  Low fan-out

 Functional Independence: Achieved through cohesion and coupling.  Control abstraction

 Information Hiding: Protecting data within a module from other

modules.

9
 Modules should display: COHESION AND COUPLING
 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.

10
DESIGN APPROACHES
 Two fundamentally different software design approaches:

 Function-oriented design

 Object-oriented design

FUNCTION-ORIENTED DESIGN - OVERVIEW AND CHARACTERISTICS

 Focuses on functions or procedures Example

 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

12
FUNCTION-ORIENTED DESIGN - DESIGN PROCESS

 A system is looked upon as something that performs a set of

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

13
FUNCTION-ORIENTED DESIGN - DESIGN NOTATIONS

 Common Notations Used in Function-Oriented Design:

 Flowcharts
 Data Flow Diagrams (DFDs)
 Structure Charts

14
OBJECT-ORIENTED DESIGN - OVERVIEW AND CHARACTERISTICS

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

 Focuses on objects rather than functions

 Emphasizes on data encapsulation,

inheritance, and polymorphism

15
OBJECT-ORIENTED DESIGN - IMPORTANT CONCEPTS

Object-Oriented Design Example

 Key Concepts in Object-Oriented Design:  Library Automation Software:

 • Objects: Entities combining data and behavior  Each library member is a separate object

 • Classes: Blueprints for objects  With its own data and functions.

 • Messages: Communication between objects  Functions defined for one object:

 • Inheritance, Polymorphism, Encapsulation  Cannot directly refer to or change data of other objects.

16
 Objects have their own internal data that defines their state.

 Similar objects constitute a class.

 Each object is a member of some class.

 Classes may inherit features from a super class.

 In OOD: Software is not developed by designing functions OBJECT-ORIENTED VERSUS FUNCTION ORIENTED DESIGN
such as:
 Unlike function-oriented design,
 update-employee-record,
 In OOD the basic abstraction is not functions
 get-employee-address, etc.
such as “sort”, “display”, “track”, etc.,
 But by designing objects such as:
 But real-world entities such as “employee”,
 employees, “picture”, “machine”, “radar system”, etc.

 departments, etc.

17
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
 Definition of SDLC:

 • A structured approach to software development

 • Ensures systematic progression through stages

 Importance in Software Development:

 • Reduces risk of failure

SOFTWARE LIFE CYCLE
 Software life cycle (or software process) is a
 • Improves quality and maintainability
series of identifiable stages that a software
product undergoes during its life-time:
 A software life cycle model (or process model) is a descriptive
and diagrammatic model of software life cycle:  Feasibility study

 identifies all the activities required for product  Requirements analysis and specification,
development,  Design,
 establishes a precedence ordering among the different  Coding,
activities,
 Testing
 Divides life cycle into phases.
 Maintenance. 18
 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.

19
 Many life cycle models have been proposed.

 Classical waterfall model

 Iterative waterfall,

 Evolutionary,

 Prototyping, and

 Spiral model

20
CLASSICAL WATERFALL MODEL

Feasibility Study

 Overview of Classical Waterfall Model:

Req. Analysis
 • Linear and sequential model

 • Each phase must be completed before the next begins Design

 Characteristics:
Coding
 • Easy to manage

 • Rigid and less flexible

Testing

Maintenance

21
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 design:
among the functions.
 architectural design (or high-level design)
 Decompose each function recursively into sub-
 detailed design (or low-level design).
functions.
 Identify data flow among the subfunctions as well.

 Carried out using Data flow diagrams (DFDs).

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

23
ITERATIVE WATERFALL MODEL
 Classical waterfall model is idealistic AS IT assumes that no
defect is introduced during any development activity. Feasibility Study
 in practice: defects do get introduced in almost every phase
of the life cycle. Req. Analysis

 Overview of Iterative Waterfall Model: Design

 Similar to Waterfall but allows revisiting previous phases
Coding
 Better handling of changes

 Characteristics: Testing
 More flexible than Classical Waterfall
Maintenance
 Suitable for projects with evolving requirements

24
PROTOTYPING MODEL

 A prototype is a toy implementation of a system:

 limited functional capabilities, Build Prototype

 low reliability, Requirements Customer Customer

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

 Overview of Prototyping Model: Refine Implement

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

25
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: C
 • Develops the system incrementally

 • Continual refinement of the product

A AB A
B
 Characteristics:

 • High flexibility and adaptability

 • Suitable for projects with unclear requirements

26
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 &
 There are no fixed phases in this model, the phases shown in the Objectives Resolve Risks
figure are just examples.

 Overview of Spiral Model:

 Combines iterative development with risk management Customer
Evaluation of Develop Next Level
 Focuses on early identification of risks and mitigation Prototype of Product

 Each loop in the spiral is split into four sectors (quadrants).

 Characteristics:
 Highly flexible and adaptable
 Suitable for large and complex projects 27
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.

28