UNIT-3

Software Design:-
Software design is a mechanism to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation. It deals with representing the client's
requirement, as described in SRS (Software Requirement Specification) document, into a form, i.e.,
easily implementable using programming language.

The software design phase is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from the problem domain to the solution domain. In software design, we consider the
system to be a set of components or modules with clearly defined behaviours & boundaries.

Objectives of Software Design:-

Following are the purposes of Software design:

1. Correctness: Software design should be correct as per requirement.

2. Completeness: The design should have all components like data structures, modules, and
external interfaces, etc.

3. Efficiency: Resources should be used efficiently by the program.

4. Flexibility: Able to modify on changing needs.

5. Consistency: There should not be any inconsistency in the design.

6. Maintainability: The design should be so simple so that it can be easily maintainable by

other designers.
Software Design Principles:-

Software design principles are concerned with providing means to handle the complexity of the
design process effectively. Effectively managing the complexity will not only reduce the effort
needed for design but can also reduce the scope of introducing errors during design.

Following are the principles of Software Design

1. Problem Partitioning:-

For small problem, we can handle the entire problem at once but for the significant problem, divide
the problems and conquer the problem it means to divide the problem into smaller pieces so that
each piece can be captured separately.

For software design, the goal is to divide the problem into manageable pieces.

Benefits of Problem Partitioning

1. Software is easy to understand

2. Software becomes simple

3. Software is easy to test

4. Software is easy to modify

5. Software is easy to maintain

6. Software is easy to expand

These pieces cannot be entirely independent of each other as they together form the system. They
have to cooperate and communicate to solve the problem. This communication adds complexity.

Note: As the number of partition increases = Cost of partition and complexity increases

2. Abstraction:-
An abstraction is a tool that enables a designer to consider a component at an abstract level without
bothering about the internal details of the implementation. Abstraction can be used for existing
element as well as the component being designed.

Here, there are two common abstraction mechanisms

1. Functional Abstraction
 2. Data Abstraction

1. Functional Abstraction

i. A module is specified by the method it performs.

ii. The details of the algorithm to accomplish the functions are not visible to the user of the
function.

Functional abstraction forms the basis for Function oriented design approaches.

2. Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction forms the basis
for Object Oriented design approaches.

3. Modularity
Modularity specifies to the division of software into separate modules which are differently named
and addressed and are integrated later on in to obtain the completely functional software. It is the
only property that allows a program to be intellectually manageable. Single large programs are
difficult to understand and read due to a large number of reference variables, control paths, global
variables, etc.

The desirable properties of a modular system are:

o Each module is a well-defined system that can be used with other applications.

o Each module has single specified objectives.

o Modules can be separately compiled and saved in the library.

o Modules should be easier to use than to build.

o Modules are simpler from outside than inside.

Advantages and Disadvantages of Modularity

In this topic, we will discuss various advantage and disadvantage of Modularity.

Advantages of Modularity

There are several advantages of Modularity

o It allows large programs to be written by several or different people

o It encourages the creation of commonly used routines to be placed in the library and used
by other programs.

o It simplifies the overlay procedure of loading a large program into main storage.

o It provides more checkpoints to measure progress.

o It provides a framework for complete testing, more accessible to test

o It produced the well designed and more readable program.

Disadvantages of Modularity

There are several disadvantages of Modularity

o Execution time maybe, but not certainly, longer

o Storage size perhaps, but is not certainly, increased

o Compilation and loading time may be longer

o Inter-module communication problems may be increased

o More linkage required, run-time may be longer, more source lines must be written, and
more documentation has to be done

Modular Design:-

Modular design reduces the design complexity and results in easier and faster implementation by
allowing parallel development of various parts of a system. We discuss a different section of modular
design in detail in this section:

1. Functional Independence: Functional independence is achieved by developing functions that

perform only one kind of task and do not excessively interact with other modules. Independence is
important because it makes implementation more accessible and faster. The independent modules
are easier to maintain, test, and reduce error propagation and can be reused in other programs as
well. Thus, functional independence is a good design feature which ensures software quality.

It is measured using two criteria:

o Cohesion: It measures the relative function strength of a module.

o Coupling: It measures the relative interdependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that modules can be
characterized by the design decisions that protect from the others, i.e., In other words, modules
should be specified that data include within a module is inaccessible to other modules that do not
need for such information.

The use of information hiding as design criteria for modular system provides the most significant
benefits when modifications are required during testing's and later during software maintenance.
This is because as most data and procedures are hidden from other parts of the software,
inadvertent errors introduced during modifications are less likely to propagate to different locations
within the software.

Strategy of Design:-

A good system design strategy is to organize the program modules in such a method that are easy to
develop and latter too, change. Structured design methods help developers to deal with the size and
complexity of programs. Analysts generate instructions for the developers about how code should
be composed and how pieces of code should fit together to form a program.

To design a system, there are two possible approaches:

1. Top-down Approach
 2. Bottom-up Approach

1. Top-down Approach: This approach starts with the identification of the main components and
then decomposing them into their more detailed sub-components.

2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves towards up
the hierarchy, as shown in fig. This approach is suitable in case of an existing system.

 Coupling and Cohesion

The purpose of Design phase in the Software Development Life Cycle is to produce a solution to a
problem given in the SRS (Software Requirement Specification) document. The output of the design
phase is Software Design Document (SDD).

Basically, design is a two-part iterative process. First part is Conceptual Design that tells the
customer what the system will do. Second is Technical Design that allows the system builders to
understand the actual hardware and software needed to solve customer’s problem.

Conceptual design of system:

  Written in simple language i.e. customer understandable language.

 Detail explanation about system characteristics.

 Describes the functionality of the system.

 It is independent of implementation.

 Linked with requirement document.

Technical Design of system:

 Hardware component and design.

 Functionality and hierarchy of software component.

 Software architecture

 Network architecture

 Data structure and flow of data.

 I/O component of the system.

 Shows interface.

 Modularization:

Modularization is the process of dividing a software system into multiple independent modules
where each module works independently. There are many advantages of Modularization in
software engineering. Some of these are given below:

 Easy to understand the system.

 System maintenance is easy.
 A module can be used many times as their requirements. No need to write it again and
again.
Coupling: Coupling is the measure of the degree of interdependence between the modules.
A good software will have low coupling.
  Module Coupling

In software engineering, the coupling is the degree of interdependence between software modules.
Two modules that are tightly coupled are strongly dependent on each other. However, two modules
that are loosely coupled are not dependent on each other. Uncoupled modules have no
interdependence at all within them.

The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the number of relations
between the modules. That is, the coupling increases as the number of calls between modules
increase or the amount of shared data is large. Thus, it can be said that a design with high coupling
will have more errors.

Types of Module Coupling

1. No Direct Coupling: There is no direct coupling between M1 and M2.

In this case, modules are subordinates to different modules. Therefore, no direct coupling.

2. Data Coupling: When data of one module is passed to another module, this is called data
coupling.
3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite data
items such as structure, objects, etc. When the module passes non-global data structure or entire
structure to another module, they are said to be stamp coupled. For example, passing structure
variable in C or object in C++ language to a module.

4. Control Coupling: Control Coupling exists among two modules if data from one module is used to
direct the structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally imposed data
format, communication protocols, or device interface. This is related to communication to external
tools and devices.

6. Common Coupling: Two modules are common coupled if they share information through some
global data items.

7. Content Coupling: Content Coupling exists among two modules if they share code, e.g., a branch
from one module into another module.

 Cohesion:

Cohesion is a measure of the degree to which the elements of the module are functionally related. It
is the degree to which all elements directed towards performing a single task are contained in the
component. Basically, cohesion is the internal glue that keeps the module together. A good software
design will have high cohesion.
  Module Cohesion
In computer programming, cohesion defines to the degree to which the elements of a module
belong together. Thus, cohesion measures the strength of relationships between pieces of
functionality within a given module. For example, in highly cohesive systems, functionality is strongly
related.

Cohesion is an ordinal type of measurement and is generally described as "high cohesion" or "low
cohesion."

Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a

module, cooperate to achieve a single function.

2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of a

module form the components of the sequence, where the output from one component of
the sequence is input to the next.

3. Communicational Cohesion: A module is said to have communicational cohesion, if all tasks

of the module refer to or update the same data structure, e.g., the set of functions defined
on an array or a stack.

4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of the
module are all parts of a procedure in which particular sequence of steps has to be carried
out for achieving a goal, e.g., the algorithm for decoding a message.

5. Temporal Cohesion: When a module includes functions that are associated by the fact that
all the methods must be executed in the same time, the module is said to exhibit temporal
cohesion.
 6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the module
perform a similar operation. For example Error handling, data input and data output, etc.

7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a set of

tasks that are associated with each other very loosely, if at all.

Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter-Module Binding. Cohesion is also called Intra-Module Binding.

Coupling shows the relationships between modules. Cohesion shows the relationship within the module.

Coupling shows the relative independence between the Cohesion shows the module's relative functional strength.
modules.

While creating, you should aim for low coupling, i.e., While creating you should aim for high cohesion, i.e., a
dependency among modules should be less. cohesive component/ module focuses on a single function
(i.e., single-mindedness) with little interaction with other
modules of the system.

In coupling, modules are linked to the other modules. In cohesion, the module focuses on a single thing.

 Function Oriented Design

Function Oriented design is a method to software design where the model is decomposed into a set
of interacting units or modules where each unit or module has a clearly defined function. Thus, the
system is designed from a functional viewpoint.

Design Notations

Design Notations are primarily meant to be used during the process of design and are used to
represent design or design decisions. For a function-oriented design, the design can be represented
graphically or mathematically by the following:
Data Flow Diagram

Data-flow design is concerned with designing a series of functional transformations that convert
system inputs into the required outputs. The design is described as data-flow diagrams. These
diagrams show how data flows through a system and how the output is derived from the input
through a series of functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They are generally
understandable without specialized training, notably if control information is excluded. They show
end-to-end processing. That is the flow of processing from when data enters the system to where it
leaves the system can be traced.

Data-flow design is an integral part of several design methods, and most CASE tools support data-
flow diagram creation. Different ways may use different icons to represent data-flow diagram
entities, but their meanings are similar.

The notation which is used is based on the following symbols:

The report generator produces a report which describes all of the named entities in a data-flow
diagram. The user inputs the name of the design represented by the diagram. The report generator
then finds all the names used in the data-flow diagram. It looks up a data dictionary and retrieves
information about each name. This is then collated into a report which is output by the system.

 Data Dictionaries

A data dictionary lists all data elements appearing in the DFD model of a system. The data items
listed contain all data flows and the contents of all data stores looking on the DFDs in the DFD model
of a system.

A data dictionary lists the objective of all data items and the definition of all composite data
elements in terms of their component data items. For example, a data dictionary entry may contain
that the data grossPay consists of the parts regularPay and overtimePay.

grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their type.

A data dictionary plays a significant role in any software development process because of the
following reasons:

o A Data dictionary provides a standard language for all relevant information for use by
engineers working in a project. A consistent vocabulary for data items is essential since, in
large projects, different engineers of the project tend to use different terms to refer to the
same data, which unnecessarily causes confusion.

o The data dictionary provides the analyst with a means to determine the definition of various
data structures in terms of their component elements.

Structured Charts

It partitions a system into block boxes. A Black box system that functionality is known to the user
without the knowledge of internal design.
Structured Chart is a graphical representation which shows:

o System partitions into modules

o Hierarchy of component modules

o The relation between processing modules

o Interaction between modules

o Information passed between modules

The following notations are used in structured chart:

Pseudo-code

Pseudo-code notations can be used in both the preliminary and detailed design phases. Using
pseudo-code, the designer describes system characteristics using short, concise, English Language
phases that are structured by keywords such as If-Then-Else, While-Do, and End.
 Object-Oriented Design
Software design is the process by which an agent creates a specification of a software
devices, intended to accomplish goals, using a set of primitive components and subject to
constraints. Having a design process when the software is being developed allows
developers to be more efficient and transparent. Moreover, it keeps all the members of
different team on track and enables them to collaborate easily. With the assistance of
software design, developers can reduce the risks as they will be using a tried and tested
plan, wherein not retracing of steps as well as guesswork is required.
Furthermore, there are several types of software design, which are used to simplify the
designing process as well as to reduce the complexities in the software. Object Oriented
Design (OOD) is one approach of software design and is defined as the process of planning a
system of interacting objects for the purpose of solving a software problem.

 What is Object Oriented Design?

Object Oriented Design (OOD) serves as part of the object oriented programming (OOP)
process of lifestyle. It is mainly the process of using an object methodology to design a
computing system or application. This technique enables the implementation of a software
based on the concepts of objects. Additionally, it is a concept that forces programmers to
plan out their code in order to have a better flowing program.
The origins of Object Oriented Design (OOD) is debated, but the first languages that
supported it included Simula and SmallTalk. The term did not become popular until Grady
Booch wrote the first paper titled Object-Oriented Design, in 1982. The chief objective of
this type of software design is to define the classes and their relationships, which are
needed to build a system that meets the requirements contained in the Software
Requirement Specifications.
Moreover, it is the discipline of defining the objects and their interactions to solve a
problem that was identified and documented during the Object Oriented Analysis (OOA). In
short, Object Oriented Design (OOD) is a method of design encompassing the process of
object oriented decomposition and a notation for depicting both logical and physical models
of the system under design. The other characteristics of Object Oriented Design are as
follow:
 Objects are abstractions of the real-world or system entities and manage themselves.
 The objects are independent and in an encapsulated state and representation information.
 System functionality is expressed in terms of object services.
 Shared data areas are eliminated.
 Communication between objects is through message passing.
 The objects may be distributed and may execute sequentially or in parallel.

 Process of Object Oriented Design:

Understanding the process of any type of software related activity simplifies its
development for the software developer, programmer and tester. Whether you are
executing functional testing, or making a test report, each and every action has a process
that needs to be followed by the members of the team. Similarly, Object Oriented Design
(OOD) too has a defined process, which if not followed rigorously, can affect the
performance as well as the quality of the software. Therefore, to assist the team of software
 developers and programmers, here is the process of Object Oriented Design (OOD):
1. To design classes and their attributes, methods, associations, structure, and even protocol,
design axiom is applied.
o The static UML class diagram is redefined and completed by adding details.
o Attributes are refined.
o Protocols and methods are designed by utilizing a UML activity diagram to represent
the methods algorithm.
o If required, redefine associations between classes, and refine class hierarchy and
design with inheritance.
o Iterate and refine again.
2. Design the access layer.
o Create mirror classes i.e., for every business class identified and created, create one
access class.
3. Identify access layer class relationship.
4. Simplify classes and their relationships. The main objective here is to eliminate redundant
classes and structures.
o Redundant Classes: Programmers should remember to not put two classes that
perform similar translate requests and translate results activities. They should
simply select one and eliminate the other.
o Method Classes: Revisit the classes that consist of only one or two methods, to see
if they can be eliminated or combined with the existing classes.
5. Iterate and refine again.
6. Design the view layer classes.
o Design the macro level user interface, while identifying the view layer objects.
o Design the micro level user interface.
o Test usability and user satisfaction.
o Iterate and refine.
7. At the end of the process, iterate the whole design. Re-apply the design axioms, and if
required repeat the preceding steps again.

 Concepts of Object Oriented Design:

In Object Oriented Design (OOD), the technology independent concepts in the analysis
model are mapped onto implementing classes, constraints are identified, and the interfaces
are designed, which results in a model for the solution domain. In short, a detailed
description is constructed to specify how the system is to be built on concrete technologies.
Moreover, Object Oriented Design (OOD) follows some concepts to achieve these goals,
each of which has a specific role and carries a lot of importance. These concepts are defined
in detail below:
1. Encapsulation: This is a tight coupling or association of data structure with the methods or
functions that act on the data. This is basically known as a class, or object (object is often the
implementation of a class).
2. Data Protection: The ability to protect some components of the object from external
entities. This is realized by language keywords to enable a variable to be declared as private
or protected to the owning class.
3. Inheritance: This is the ability of a class to extend or override the functionality of another
class. This so called child class has a whole section that is the parent class and then it has its
 own set of functions and data.
4. Interface: A definition of functions or methods, and their signature that are available for use
as well as to manipulate a given instance of an object.
5. Polymorphism: This is the ability to define different functions or classes as having the same
name, but taking different data type.

 Advantages of Object Oriented Design:

The discussion above has elaborated on several advantages of Object Oriented Design
(OOD). From enabling the implementation of a software based on the concepts of objects
and deleting the shared data areas to distributing and executing the object sequentially or in
parallel, the benefits of this approach of software design are numerous. Hence, provided
here some of the other advantages of using Object Oriented Design (OOD).
 Easier to maintain objects.
 Objects may be understood as stand-alone entities.
 Objects are appropriate reusable components.
 For some systems, there may be an obvious mapping from real entities to system objects.

 Conclusion:

With the transition and advancement of software industry, several aspects of software
engineering and software development are also improving and transforming into their
better forms. Similarly, the ways of designing the software are also advancing and changing
for better. Introduced by Grady Booch in the paper titled Object-Oriented Design, in 1982,
Object Oriented Design (OOD) is a newer paradigm that is replacing function oriented design
techniques day-by-day. Object Oriented Analysis and Design combines both data and
methods into cohesive units and classes. Unified modelling language (UML) is a notation
that is often used to model object oriented systems.
Moreover, it also provides various diagrams for modelling a system’s structure, dynamic
behaviour, states, architecture, etc. Creating an Objective Oriented Design (OOD) is an
iterative process based on applying the knowledge stored in a system’s use cases. Hence,
this approach of software design is basically used for planning a system of interacting
objects and for the purpose of solving a software problem, which further helps software
developers and programmers in creating a software that has exceptional features and
qualities.

 Software Measurement and Metrics

Software Measurement: A measurement is an manifestation of the size, quantity, amount
or dimension of a particular attributes of a product or process. Software measurement is a
titrate impute of a characteristic of a software product or the software process. It is an
authority within software engineering. Software measurement process is defined and
governed by ISO Standard.
 Need of Software Measurement:
Software is measured to:

1. Create the quality of the current product or process.

2. Anticipate future qualities of the product or process.

3. Enhance the quality of a product or process.

4. Regulate the state of the project in relation to budget and schedule.

Classification of Software Measurement:

There are 2 types of software measurement:

1. Direct Measurement:
In direct measurement the product, process or thing is measured directly using standard
scale.

2. Indirect Measurement:
In indirect measurement the quantity or quality to be measured is measured using related
parameter i.e.
by use of reference.

Metrics:
A metrics is a measurement of the level that any impute belongs to a system product or
process. There are
4 functions related to software metrics:
1. Planning

2. Organizing

3. Controlling

4. Improving

Characteristics of software Metrics:

1. Quantitative:
Metrics must possess quantitative nature. It means metrics can be expressed in values.

2. Understandable:
Metric computation should be easily understood ,the method of computing metric should
be clearly defined.

3. Applicability:
Metrics should be applicable in the initial phases of development of the software.

4. Repeatable:
The metric values should be same when measured repeatedly and consistent in nature.

5. Economical:
Computation of metric should be economical.

6. Language Independent:
Metrics should not depend on any programming language.
 Classification of Software Metrics:
There are 2 types of software metrics:

1. Product Metrics:
Product metrics are used to evaluate the state of the product, tracing risks and
undercovering prospective problem areas. The ability of team to control quality is
evaluated.

2. Process Metrics:
Process metrics pay particular attention on enhancing the long term process of the team or
organisation.

3. Project Metrics:
Project matrix is describes the project characteristic and execution process.
 Number of software developer
 Staffing pattern over the life cycle of software
 Cost and schedule
 Productivity

Advantage of Software Metrics

1) Comparative study of various design methodology of software systems.
2) For analysis, comparison, and critical study of different programming language concerning their characteri
3) In comparing and evaluating the capabilities and productivity of people involved in software development
4) In the preparation of software quality specifications.
5) In the verification of compliance of software systems requirements and specifications.
6) In making inference about the effort to be put in the design and development of the software systems.
7) In getting an idea about the complexity of the code.
8) In taking decisions regarding further division of a complex module is to be done or not.
9) In guiding resource manager for their proper utilization.
10) In comparison and making design tradeoffs between software development and maintenance cost.
11) In providing feedback to software managers about the progress and quality during various phases of the s
12) In the allocation of testing resources for testing the code.

Disadvantage of Software Metrics:-

1) The application of software metrics is not always easy, and in some cases, it is difficult and costly.
2) The verification and justification of software metrics are based on historical/empirical data whose validity
Is difficult to verify.
3) These are useful for managing software products but not for evaluating the performance of the technical
staff.
4) The definition and derivation of Software metrics are usually based on assuming which are not standardized
and may depend upon tools available and working environment.
5) Most of the predictive models rely on estimates of certain variables which are often not known precisely.

 Halstead's Software Metrics

According to Halstead's "A computer program is an implementation of an algorithm considered to be
a collection of tokens which can be classified as either operators or operand."

Token Count
In these metrics, a computer program is considered to be a collection of tokens, which may be
classified as either operators or operands. All software science metrics can be defined in terms of
these basic symbols. These symbols are called as a token.

The basic measures are

n1 = count of unique operators.

n2 = count of unique operands.
N1 = count of total occurrences of operators.
N2 = count of total occurrence of operands.

In terms of the total tokens used, the size of the program can be expressed as N = N1 + N2.

Halstead metrics are:

Program Volume (V)

The unit of measurement of volume is the standard unit for size "bits." It is the actual size of a
program if a uniform binary encoding for the vocabulary is used.

V=N*log2n

Program Level (L)

The value of L ranges between zero and one, with L=1 representing a program written at the highest
possible level (i.e., with minimum size).

L=V*/V

Program Difficulty

The difficulty level or error-proneness (D) of the program is proportional to the number of the
unique operator in the program.

D= (n1/2) * (N2/n2)

Programming Effort (E)

The unit of measurement of E is elementary mental discriminations.

E=V/L=D*V

Estimated Program Length

According to Halstead, The first Hypothesis of software science is that the length of a well-structured
program is a function only of the number of unique operators and operands.

N=N1+N2

And estimated program length is denoted by N^

N^ = n1log2n1 + n2log2n2

The following alternate expressions have been published to estimate program length:

o NJ = log2 (n1!) + log2 (n2!)

o NB = n1 * log2n2 + n2 * log2n1
 o NC = n1 * sqrt(n1) + n2 * sqrt(n2)

o NS = (n * log2n) / 2

Potential Minimum Volume

The potential minimum volume V* is defined as the volume of the most short program in which a
problem can be coded.

V* = (2 + n2*) * log2 (2 + n2*)

Here, n2* is the count of unique input and output parameters

Size of Vocabulary (n)

The size of the vocabulary of a program, which consists of the number of unique tokens used to
build a program, is defined as:

n=n1+n2

where

n=vocabulary of a program
n1=number of unique operators
n2=number of unique operands

Language Level - Shows the algorithm implementation program language level. The same algorithm
demands additional effort if it is written in a low-level program language. For example, it is easier to
program in Pascal than in Assembler.

L' = V / D / D
lambda = L * V* = L2 * V

Language levels

Language Language level λ Variance σ

PL/1 1.53 0.92

ALGOL 1.21 0.74

FORTRAN 1.14 0.81

CDC Assembly 0.88 0.42

PASCAL 2.54 -

APL 2.42 -

C 0.857 0.445
Counting rules for C language

1. Comments are not considered.

2. The identifier and function declarations are not considered

3. All the variables and constants are considered operands.

4. Global variables used in different modules of the same program are counted as multiple
occurrences of the same variable.

5. Local variables with the same name in different functions are counted as unique operands.

6. Functions calls are considered as operators.

7. All looping statements e.g., do {...} while ( ), while ( ) {...}, for ( ) {...}, all control statements
e.g., if ( ) {...}, if ( ) {...} else {...}, etc. are considered as operators.

8. In control construct switch ( ) {case:...}, switch as well as all the case statements are
considered as operators.

9. The reserve words like return, default, continue, break, sizeof, etc., are considered as
operators.

10. All the brackets, commas, and terminators are considered as operators.

11. GOTO is counted as an operator, and the label is counted as an operand.

12. The unary and binary occurrence of "+" and "-" are dealt with separately. Similarly "*"
(multiplication operator) are dealt separately.

13. In the array variables such as "array-name [index]" "array-name" and "index" are considered
as operands and [ ] is considered an operator.

14. In the structure variables such as "struct-name, member-name" or "struct-name -> member-
name," struct-name, member-name are considered as operands and '.', '->' are taken as
operators. Some names of member elements in different structure variables are counted as
unique operands.

15. All the hash directive is ignored.

Example: Consider the sorting program as shown in fig: List out the operators and operands and also
calculate the value of software science measure like n, N, V, E, λ ,etc.

Solution: The list of operators and operands is given in the table

Operators Occurrences Operands Occurrences

int 4 SORT 1

() 5 x 7
 , 4 n 3

[] 7 i 8

if 2 j 7

< 2 save 3

; 11 im1 3

for 2 2 2

= 6 1 3

- 1 0 1

<= 2 - -

++ 2 - -

return 2 - -

{} 3 - -

n1=14 N1=53 n2=10 N2=38

Here N1=53 and N2=38. The program length N=N1+N2=53+38=91

Vocabulary of the program n=n1+n2=14+10=24

Volume V= N * log2N=91 x log2 24=417 bits.

The estimate program length N of the program

= 14 log214+10 log2)10
= 14 * 3.81+10 * 3.32
= 53.34+33.2=86.45

Conceptually unique input and output parameters are represented by n2*.

n2*=3 {x: array holding the integer to be sorted. This is used as both input and output}

{N: the size of the array to be sorted}

The Potential Volume V*=5log25=11.6

Since L=V*/V

We may use another formula

V^=V x L^= 417 x 0.038=15.67

E^=V/L^=D^ x V

Therefore, 10974 elementary mental discrimination is required to construct the program.

This is probably a reasonable time to produce the program, which is very simple.

 Metrics for the Design Model of the Product

Metrics simply measures quantitative assessment that focuses on countable values most commonly
used for comparing and tracking performance of system. Metrics are used in different scenarios like
analyzing model, design model, source code, testing, and maintenance. Metrics for design modeling
allows developers or software engineers to evaluate or estimate quality of design and include
various architecture and component-level designs.

Metrics by Glass and Card :

In designing a product, it is very important to have efficient management of complexity. Complexity
itself means very difficult to understand. We know that systems are generally complex as they have
many interconnected components that make it difficult to understand. Glass and Card are two
scientists who have suggested three design complexity measures. These are given below :

1. Structural Complexity –
Structural complexity depends upon fan-out for modules. It can be defined as :
S(k) = f2out(k)

Where fout represents fanout for module k (fan-out means number of modules that are
subordinating module k).

2. Data Complexity –
Data complexity is complexity within interface of internal module. It is size and intricacy of
data. For some module k, it can be defined as :

D(k) = tot_var(k) / [fout(k)+1]

Where tot_var is total number of input and output variables going to and coming out of module.

3. System Complexity –
System complexity is combination of structural and data complexity. It can be denoted as:

Sy(k) = S(k)+D(k)

When structural, data, and system complexity get increased, overall architectural complexity also
gets increased.

Complexity metrics –
Complexity metrics are used to measure complexity of overall software. The computation if
complexity metrics can be done with help of a flow graph. It is sometimes called cyclomatic
complexity. The cyclomatic complexity is a useful metric to indicate complexity of software system.
Without use of complexity metrics, it is very difficult and time-consuming to determine complexity in
designing products where risk cost emanates. Even continuous complexity analysis makes it difficult
for project team and management to solve problem. Measuring Software complexity leads to
improve code quality, increase productivity, meet architectural standards, reduce overall cost,
increases robustness, etc. To calculate cyclomatic complexity, following equation is used:

Cyclomatic complexity= E - N + 2

Where, E is total number of edges and N is total number of nodes.

Example –
In diagram given below, you can see number of edges and number of nodes.
So, the Cyclomatic complexity can be calculated as –

Given,

E = 10,

N=8

So,

Cyclomatic complexity

=E-N+2

= 10 – 8 + 2= 4
  Data Structure Metrics
Essentially the need for software development and other activities are to process data. Some data is input to a

system, program or module; some data may be used internally, and some data is the output from a system,

program, or module.

Example:

Program Data Input Internal Data Data Output

Payroll Name/Social Security No./Pay Withholding rates Gross Pay

rate/Number of hours worked Overtime Factors Insurance withholding Net Pay
Premium Rates Pay Ledgers

Spreadsheet Item Names/Item Cell computations Subtotal Spreadsheet of items

Amounts/Relationships among and totals
Items

Software Program Size/No of Software Model Parameter Est. project effort

Planner developer on team Constants Coefficients Est. project duration

That's why an important set of metrics which capture in the amount of data input, processed in an output form
software. A count of this data structure is called Data Structured Metrics. In these concentrations is on variables
(and given constant) within each module & ignores the input-output dependencies.
There are some Data Structure metrics to compute the effort and time required to complete the project. There
metrics are:
1. The Amount of Data.

2. The Usage of data within a Module.

3. Program weakness.

4. The sharing of Data among Modules.

1. The Amount of Data: To measure the amount of Data, there are further many different metrics, and these are:

o Number of variable (VARS): In this metric, the Number of variables used in the program is counted.

o Number of Operands (η2): In this metric, the Number of operands used in the program is counted.
η2 = VARS + Constants + Labels

o Total number of occurrence of the variable (N2): In this metric, the total number of occurrence of the

variables are computed

1. The Usage of data within a Module: The measure this metric, the average numbers of live variables are
computed. A variable is live from its first to its last references within the procedure.
 2. Program weakness: Program weakness depends on its Modules weakness. If Modules are weak(less
Cohesive), then it increases the effort and time metrics required to complete the project.

Module Weakness (WM) = LV* γ

A program is normally a combination of various modules; hence, program weakness can be a useful measure and is

defined as:

Where

WMi: Weakness of the ith module

WP: Weakness of the program

m: No of modules in the program

4.There Sharing of Data among Module: As the data sharing between the Modules increases (higher Coupling),

no parameter passing between Modules also increased, As a result, more effort and time are required to complete

the project. So Sharing Data among Module is an important metrics to calculate effort and time.

Software Implementation
  Structured Programming
In the process of coding, the lines of code keep multiplying, thus, size of the
software increases. Gradually, it becomes next to impossible to remember the flow
of program. If one forgets how software and its underlying programs, files,
procedures are constructed it then becomes very difficult to share, debug and
modify the program. The solution to this is structured programming. It encourages
the developer to use subroutines and loops instead of using simple jumps in the
code, thereby bringing clarity in the code and improving its efficiency Structured
programming also helps programmer to reduce coding time and organize code
properly.
Structured programming states how the program shall be coded. Structured
programming uses three main concepts:
 Top-down analysis - A software is always made to perform some rational
work. This rational work is known as problem in the software parlance. Thus
it is very important that we understand how to solve the problem. Under top-
down analysis, the problem is broken down into small pieces where each one
has some significance. Each problem is individually solved and steps are
clearly stated about how to solve the problem.
 Modular Programming - While programming, the code is broken down into
smaller group of instructions. These groups are known as modules,
subprograms or subroutines. Modular programming based on the
understanding of top-down analysis. It discourages jumps using ‘goto’
statements in the program, which often makes the program flow non-
traceable. Jumps are prohibited and modular format is encouraged in
structured programming.
 Structured Coding - In reference with top-down analysis, structured coding
sub-divides the modules into further smaller units of code in the order of their
execution. Structured programming uses control structure, which controls the
flow of the program, whereas structured coding uses control structure to
organize its instructions in definable patterns.
 Functional Programming
Functional programming is style of programming language, which uses the
concepts of mathematical functions. A function in mathematics should always
produce the same result on receiving the same argument. In procedural languages,
the flow of the program runs through procedures, i.e. the control of program is
transferred to the called procedure. While control flow is transferring from one
procedure to another, the program changes its state.
In procedural programming, it is possible for a procedure to produce different results
when it is called with the same argument, as the program itself can be in different
state while calling it. This is a property as well as a drawback of procedural
programming, in which the sequence or timing of the procedure execution becomes
important.
Functional programming provides means of computation as mathematical functions,
which produces results irrespective of program state. This makes it possible to
predict the behavior of the program.
Functional programming uses the following concepts:
  First class and High-order functions - These functions have capability to
accept another function as argument or they return other functions as results.
 Pure functions - These functions do not include destructive updates, that is,
they do not affect any I/O or memory and if they are not in use, they can
easily be removed without hampering the rest of the program.
 Recursion - Recursion is a programming technique where a function calls
itself and repeats the program code in it unless some pre-defined condition
matches. Recursion is the way of creating loops in functional programming.
 Strict evaluation - It is a method of evaluating the expression passed to a
function as an argument. Functional programming has two types of
evaluation methods, strict (eager) or non-strict (lazy). Strict evaluation always
evaluates the expression before invoking the function. Non-strict evaluation
does not evaluate the expression unless it is needed.
 λ-calculus - Most functional programming languages use λ-calculus as their
type systems. λ-expressions are executed by evaluating them as they occur.
Common Lisp, Scala, Haskell, Erlang and F# are some examples of functional
programming languages.
 Programming style
Programming style is set of coding rules followed by all the programmers to write
the code. When multiple programmers work on the same software project, they
frequently need to work with the program code written by some other developer.
This becomes tedious or at times impossible, if all developers do not follow some
standard programming style to code the program.
An appropriate programming style includes using function and variable names
relevant to the intended task, using well-placed indentation, commenting code for
the convenience of reader and overall presentation of code. This makes the
program code readable and understandable by all, which in turn makes debugging
and error solving easier. Also, proper coding style helps ease the documentation
and updation.
 Coding Guidelines
Practice of coding style varies with organizations, operating systems and language
of coding itself.
The following coding elements may be defined under coding guidelines of an
organization:
 Naming conventions - This section defines how to name functions,
variables, constants and global variables.
 Indenting - This is the space left at the beginning of line, usually 2-8
whitespace or single tab.
 Whitespace - It is generally omitted at the end of line.
 Operators - Defines the rules of writing mathematical, assignment and
logical operators. For example, assignment operator ‘=’ should have space
before and after it, as in “x = 2”.
 Control Structures - The rules of writing if-then-else, case-switch, while-until
and for control flow statements solely and in nested fashion.
  Line length and wrapping - Defines how many characters should be there in
one line, mostly a line is 80 characters long. Wrapping defines how a line
should be wrapped, if is too long.
 Functions - This defines how functions should be declared and invoked, with
and without parameters.
 Variables - This mentions how variables of different data types are declared
and defined.
 Comments - This is one of the important coding components, as the
comments included in the code describe what the code actually does and all
other associated descriptions. This section also helps creating help
documentations for other developers.
 Software Implementation Challenges
There are some challenges faced by the development team while implementing the
software. Some of them are mentioned below:
 Code-reuse - Programming interfaces of present-day languages are very
sophisticated and are equipped huge library functions. Still, to bring the cost
down of end product, the organization management prefers to re-use the
code, which was created earlier for some other software. There are huge
issues faced by programmers for compatibility checks and deciding how
much code to re-use.
 Version Management - Every time a new software is issued to the customer,
developers have to maintain version and configuration related
documentation. This documentation needs to be highly accurate and
available on time.
 Target-Host - The software program, which is being developed in the
organization, needs to be designed for host machines at the customers end.
But at times, it is impossible to design a software that works on the target
machines.

 PROGRAMMING SUPPORT ENVIRONMENT OR SDE

A software development environment (SDE) is an environment that
automates or augments the routines involved in a software development
cycle. This includes programming-in-the-many tasks like team and project
management as well as programming-in-the-large tasks like configuration
management. An SDE supports the large-scale and long-term
maintenance of software as well.
With the advancement in technology and increased user expectations, the
functionality of an environment most likely changes. The collection of software
tools for developers has been enhanced significantly since the 1990s.

The following are four categories represents trends that have a considerable
influence over environments, i.e., on their user interfaces, tools and
architectures:
 Language-oriented environments: These environment types are
developed around one language, thereby offering a tool set suitable for
that particular language. They are very interactive and provide restricted
 support for programming-in-the-large. Cedar for Mesa/Cedar, Rational
Environment for Ada, Smalltalk for Smalltalk are some common examples
of language-centered environments.
 Structure-oriented environments: These environment types include
techniques that let users directly manipulate the structures. These
techniques are language independent, which triggered the concept of
generators for environments.
 Toolkit environments: These environment types offer a set of tools that
incorporate language-independent support for programming-in-the-large
tasks, which include version control and configuration management.
 Method-based environments: These environment types include support
for a wide variety of routines involved in the software development
process. This includes tasks like team and project management. They also
feature tools for certain specification and design techniques.

 Coding the procedural design

This methodology refers to a set of well-documented procedures and guidelines
used in the analysis, design, and implementation of programs. Coding methodology
includes a diagrammatic notation for documenting the results of the procedure. It
also includes an objective set (ideally quantified) of criteria for determining whether
the results of the procedure are of the desired quality. The steps to use coding’
methodology are listed below.
1. The software development team begins its work by reviewing and understanding the
design and requirements specification documents. These documents are essential
for understanding user requirements and creating a framework for the software code.
2. In case the software development team is unable to understand user
requirements correctly and further clarification is required, the queries are sent
back to the user. In addition, the software development team also returns the
requirements that are understood by them.
3. After the requirements are clearly understood by the software development
team, the design and specifications are implemented in source code,
supporting files, and the header files. Note that while writing the software code,
the coding style guidelines should be followed. In some cases, there may be a
proposal of change in hardware or software specifications. However, the
requests for change are implemented only after the approval of the user.
4. When the software code is completely written, it is compiled along with other
required files.
5. Code inspection and reviews are conducted after the compilation. These
methods are used to correct and verify errors in the software code.
6. Software testing is carried out to detect and correct errors in each module of
the software code.
7. After the software code is tested, the software is delivered to the user along
with the relevant code files, header files, and documentation files.
In Software Coding Process further change and clarifications are required in the
design or SRS, the software development team raises a query, which is sent to the
user with the document containing what the software development team understood
from the documents sent by the user. Changes are made only when the user has a
positive response to the queries raised by the software development team.