Unit-3(Software Design)

• Basic Concept of Software Design,

• Architectural Design,
• Low Level Design: Modularization, Design Structure Charts, Pseudo Codes, Flow Charts,
• Coupling and Cohesion Measures,
• Design Strategies
• Function Oriented Design,
• Object Oriented Design,
• Top-Down and Bottom-Up Design.
• Software Measurement and Metrics:
• Various Size Oriented Measures: Halestead's Software Science,
• Function Point (FP) Based Measures,
• Cyclomatic Complexity Measures: Control Flow Graphs.
 Design
• In software design phase input is SRS document and output is SDD.
• Software designing is most creative process, where we actually decide how a
problem will be solved.

SRS Design SDD

 Characteristics of a Good SDD
• The SDD must contain all the requirement which were given in SRS.

• The design document must be readable, easy to understand and maintainable.

• It must describe a complete picture of data, functional and behavioural domain.

Steps of design
• Software designing is a 3-step process

Interface Design Architectural Design Details Design

 Interface design
• In this, we treat system as a whole and understand the relationship between the
system & environment.
• Here we treat system as a black box and do not concentrate how a function will be
implemented but we decide what is input & what should be the output according to
user requirement or SRS

I/P O/P
System
 Architectural design
• In this we understand what are the major modules that must be
implemented in the system and what are their responsibility and how
they will communicate with each other.
• We do not give stress on individual modules but concentrate coupling
and cohesion between the modules. Here we treat modules as black
box.
 Detailed design/Low level design
• In this, specification of internal elements of all modules their functions, their
processing methods, data structure, algorithms, everything is defined properly.
 Modularity
• In modular architecture, we understand that a system is composed of well
defined conceptually simple and independent units interacting through a well-
defined interface.
• Advantage of having modular architecture
• Easy to understand and explain
• It is easy to design and document
• It is easy to code and test.
• It is easy to maintain.
 Design Structure Charts
• Structure Chart represent hierarchical structure of modules. It breaks down the entire
system into lowest functional modules, describe functions and sub-functions of each
module of a system to a greater detail.
• Structure Chart partitions the system into black boxes (functionality of the system is
known to the users but inner details are unknown). Inputs are given to the black boxes
and appropriate outputs are generated.
 Symbols used in construction of structured chart
• Module: It represents the process or task of the system. It is of three types.
• Control Module: A control module branches to more than one sub module.
• Sub Module: Sub Module is a module which is the part (Child) of another
module.
• Library Module: Library Module are reusable and invokable from any
module.
• Conditional Call: It represents that control module can select any of the sub
module on the basis of some condition.
• Loop (Repetitive call of module): It represents the repetitive execution of
module by the sub module. A curved arrow represents loop in the module. All
the sub modules cover by the loop repeat execution of module.
• Data Flow: It represents the flow of data between the modules. It is
represented by directed arrow with empty circle at the end.
• Control Flow: It represents the flow of control between the modules.
It is represented by directed arrow with filled circle at the end.
• Physical Storage: Physical Storage is that where all the
information are to be stored.
• Structure chart for an Email server
 Benefits of Design Structure Charts in Software Engineering

• Improved understanding of system architecture

• Simplified communication between team members
• Easier identification of potential issues and dependencies
• Support for modular and maintainable software design
 Pseudocode
• Pseudocode is a simplified, informal representation of an algorithm or a program that
uses a mix of natural language and programming constructs.
• It is used to illustrate the high-level structure and logic of an algorithm without the
syntactic details of a specific programming language.
• Pseudocode helps developers plan and discuss algorithms, making it easier to
understand and translate into actual code later in the software development process.
 Coupling and cohesion
• Coupling and cohesion are two parameters on which we can understand the
quality of modularity in the design of a software
• Coupling
• The measure of interdependence of one module over another module
• Types of coupling
• Data Coupling: Here two modules communicate with each other
only by-passing data. it is most desired type of coupling. e.g.
addition by using call by value is an example of data coupling.
• Stamp Coupling: When two modules communicate with each other by
passing of data structure is called stamp coupling. e.g. addition of two
value but by call by reference.
• Control Coupling: The module is set to be controlled coupled if they
communicate using control information with each other. e.g.
dependence of two modules on each other because of flag.
• External Coupling: in case of external coupling two modules on each
other external to the logic of software (mostly because of hardware
issue). e.g. data bus, CPU, main memory etc.
• Common Coupling: Two modules are set to be common coupled if
they share some global data. e.g. synchronization issue between the
processes.
• Content Coupling: when one module is a part or context of another
module then it is called content coupling it is worst type of coupling.
Cohesion
• We mean the measure of functions strength of the module.
• Types of cohesion
• Coincidental Cohesion: as the name suggest is the worst kind of
cohesion where the only relationship between the functions which
are present in a module is random or coincidental.
• Logical Cohesion: All the elements of a module perform similar or
slightly similar operations, for e.g. if mouse, printer, scanner functions
are written in the same module.
• Temporal Cohesion: In case of temporal cohesion functions are related by a fact
that all the task must be executed in the same time span. so, there is a flow
control between the functions. for e.g. two functions first which catch the
exception and second which flash an error message.
• Procedural Cohesion: Here functions of a module are related to each
other through a flow control i.e. they are part of an algorithm or
procedure. for e.g. two functional first which check the file access
permission and second which opens the file.
• Communicational Cohesion: in case of communicational cohesion
different functions are operating on the same data structure. for e.g.
push and pop.
• Sequential Cohesion: here sequence is very important and the
functions are the part of sequence along with data dependency for
e.g. function1 which provides the data and function2 which process
the data.
• Functional Cohesion: in functional cohesion, different functions of a
module cooperate with each other. perform a single function. for e.g. a
module which control mouse must have different functions like accessing
the location of the track ball, then decoding it on the screen and give an
appropriate cursor movement
 Design Approach
• There are two popular approach using which design is done

Top down approach Bottom Up

approach
• In top down approach, the problem is divided into small no of
programs according to user requirements and we repeat the process
until the problem become so easy till we can solve it directly.
• Advantage
• More Systematic.
• Easy to understand and provide a modular architecture.
• In correspondence with user requirement cost and time prediction is
possible.
• Should be used with small and medium size products.
• Used mostly.

• Disadvantage
• When a problem is very complex and very large then we can not understand
the entire problem as a whole.
• Bottom Up: This approach is important as the s/w grows in complexity in a
systematic fashion. if the problem is very difficult to understand instead of
understanding the entire problem, we must solve some sub-problem and then
should keep repeating the process until the entire problem is solved.
• Advantage
• Should be used on large size projects.
• Easy to use by designers as we work in incremental fashion.

• Disadvantage
• it has complex architecture very difficult to understand and manage.
 Estimation model
• Here we try to estimate about two things time and cost of
development

• Majorly estimation can be divided into four types

• Post estimation
• Base estimation
• Decomposition
• Empirical model
 Post / Delayed estimation

• In case of a friendly partly and known technology, we do not estimate

either the time or the cost, because we know that cost will support as
in every situation.
 Base estimation

• In base estimation we predict the cost and time of the entire project
based on the experience which we have gained from the previous
projects.
 Decomposition based estimation
• It is used for large projects where decomposition of the problem into smaller
problems is done, usually it is done on two bases.

• Direct Estimation(White Box): Size oriented metrices (KLOC)

• Indirect Estimation(Black Box): Function oriented metrices (FP)

• Effort = Size / Productivity

• Productivity = Size / Effort

• Size = Effort X Productivity

• Cost = Effort X Pay

• Duration = Effort / Team Size

• Team Size = Effort / Duration

• Effort = Duration X Team Size

Q Consider a banking application which required 4 modules as follows:
User Interface = 5400 LOC
Database = 8500 LOC
Server = 7300 LOC
Client = 5500 LOC
Find the total
expenditure of
company if
productivity of
the person is 870
Loc per month.
Consider the
salary of each
developer is 1500
US dollar per
month.
Q Consider a application which contain 3 modules M1, M2, M3 having following size
M1 – 14.4 KLOC
M2 – 21.5
KLOC M3 – 8.4
KLOC
if the cost of writing 1KLOC is 50 dollars. Find the cost of the application. if the
productivity of the developer is 4 KLOC per month. Find the effort, if the project is
required to be completed in month then predict the team size.
Q Consider a application which if required to be developed by drdo contain 3 modules M1, M2,
M3 having following size
M1 – 4600 LOC optimistic developer
M2 – 6900 LOC most likely developer
M3 – 8600 LOC pessimistic developer
What is the expected size of
application
In general if the software development effort is 10 person-month, find the productivity.
if the development is required to be done in 2 months then find the team size?

Size = (Soptimistic + 4 X Slikely + Spessimistic)/6

 Indirect Estimation
• Here we use functional points to predict the cost of development, it is a better technique in
general compare to kloc because it considers the logical complexity of the product, as in
general it is not necessary that the larger the project the more complex it will be code.

• (size oriented, function oriented, extended functions point matrices) here we say that the
size of the software is directly dependent on the number and type of different functions it
performs.

FP

2D 3D
• 2D- in 2D FP we consider only information domain where we consider mainly five factors, as
follows:
• No of inputs: Each user data input is counted
• No of outputs: Output refers to reports, screen and error messages
• No of inquiries: The no of distinct interactive queries made by user which requires specific
actions by the system
• No of files: Each logical file. So either can be data structure or physical files
• No of external interfaces: Data files on tapes, disk etc. and other interfaces that are used
to transmit information to other systems are counted

FP

2D 3D

Unadjustable Adjustable
 Function point calculation

Measurement parameters Simple Average Complex

i/p 3 4 6
o/p 4 5 7
Inquires 3 4 6
Files 7 10 15
External interface 5 7 10
 In Unadjustable case
o FP= total_count

o In Adjustable case
o FP= total_count * EAF(error adjustable factor/Cost adjustment Factor)
o EAF = 0.65 + i"
𝑓i 14 factors are indirectly involved to estimate the size of the software.
1
o ∑i analysis
In FP
0.01* " 1$
• 3D- In 3D FP we consider only information domain where we consider
mainly five factors, and along with Function domain and behaviour
domain.

FP

2D 3D

Unadjustable Adjustable
 Empirical models
• Empirical models are estimation models which uses empirically
derived formulas for predicting based on LOC or FP.

• Different authors provides different mathematically derived formula

based on either LOC or FP.

• Out of all COCOMO models in most versatile and universally

accepted
 COCOMO(1981)
• COCOMO model (construction cost model) is the most widely used
estimating technique. It is a regression-based model developed by
barry boehm, he postulated that there are essentially three important
classes of the software.

• Organic(application)

• Semidetached(utility)

• Embedded(system)
• In order to classify a product into any of the three proposed classes, we take
into consideration the characteristics of the product as well as those of the
development team.

• Data processing and scientific program are considered to be application

programs. Complier, linkers etc are utility programs. Operating system and real
time system programs are system programs.

• According to the brooks the relative level of the product complexity for the
three categories of product are in the ratio 1:3:9 for application, utility and
system programs relatively
• Organic: Relatively small group work in a familiar environment to
develop well understood application program, here little innovation is
required, constraints and deadlines are few and the development
environment is stable.
• Semidetached: Project teams consist of a mixture of experienced and
inexperienced staff. It is of medium size, some innovation is required,
constraints and deadlines are moderate and the development
environment is somewhat fluid.
• Embedded: the s/w is strongly coupled to complex h/w, such as air traffic
control, ATM’s or weapon systems. The project team is large, a great deal of
innovation is required, constraints and deadlines are tight and the development
environment consist of many complex interfaces, including those with h/w and
with customer.
 Basic COCOMO

• A simple and static cost estimation model that calculates project effort and duration based
on the size of the software, measured in thousands of lines of code (KLOC)

• Provides a rough order-of-magnitude estimate of project effort and duration

• Uses three modes: Organic, Semi-Detached, and Embedded

 Basic COCOMO

• DE = ab (KLOC) bb

• DD = cb (DE) db

• Team Size = DE / DD
 20KLOC Organic Semidetached Embedded

Effort 55.75 PM 85.95 PM 131 PM

Duration 11.52 M 11.8 M 11.89 M

Team Size 5 7 11

• DE = ab (KLOC) bb

• DD = cb (DE) db

• Team Size = /
 Intermediate COCOMO
• Definition: An extension of the Basic COCOMO model that refines effort and duration
estimates by considering additional project factors, such as product attributes, hardware
constraints, and personnel/team attributes.

• Introduces 15 cost drivers to adjust the estimation, these drivers plays a major role in
computation of effort estimation.

• Effort Adjustment Factor (EAF) accounts for the influence of cost drivers.
 20 KLOC / Organic Semidetached Embedded
EAF=1.25

Effort 92.9 PM 107.4 PM 127.4 PM

•DE = a (KLOC)b X EAF(Error Adjustment

Factor)
• DE = a (KLOC)b X EAF(Error Adjustment Factor)

20 KLOC /
Embedded
Organic Semidetached
EAF=1.25

Effort
• DE = a (KLOC)b X EAF(Error Adjustment Factor)

20 KLOC /
EAF=1..675
Organic Semidetached Embedded

Effort
 Detailed COCOMO
• Definition: The most comprehensive and accurate COCOMO model that divides
a software project into multiple components or modules, and accounts for
interactions between cost drivers and project phases.

• Estimates effort and duration for each component using the Intermediate
COCOMO model, then sums them up.

• Considers software reuse, hardware constraints, and personnel/team attributes

in estimation.
 Other Empirical models

• E = 5.2 X (KLOC)0.91 Waltson & Felix

Model

• E = 5.2 + 0.73X(KLOC)1.16 Bailey-Basili

Model

• E = 3.2 X (KLOC)1.05 Simple Bohem Model

• E = 5.288 X (KLOC)1.047 Doty Model

 Cyclomatic Complexity
• Cyclomatic complexity is a software metric that measures the
complexity of a program's control flow by counting the number of
linearly independent paths through the source code.
Need:
• Assess code maintainability and readability
• Identify potential errors and areas of high risk
• Determine testing effort required
• Aid in refactoring efforts to simplify code
Objective:
• Quantify the complexity of a program or function
• Facilitate better decision-making in software development
• Improve overall code quality and understandability
Process:
• Identify the program's decision points (such as if, while, and for
statements)
• Calculate the number of linearly independent paths by
counting the
decision points and adding one
• Interpret the resulting value:
• Low value: lower complexity, easier to maintain and test
• High value: higher complexity, harder to maintain and test, may
require refactoring
• Given a control flow graph G of a program, the cyclomatic complexity V(G) can
be computed as:

• V(G) = E – N + 2, where E is the number of edges and N is the total number of

nodes

• V(G) = V(G) = Total number of bounded areas + 1

• Any region enclosed by nodes and edges can be called as a bounded area.

• The cyclomatic complexity of a program can also be easily computed by

computing the number of decision statements of the program.