UNIT II

Software Design

1
 Design Structure Chart
• Structure Chart represent hierarchical structure of modules.
• It breaks down the entire system into 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.
• Modules at top level called modules at low level.
• Components are read from top to bottom and left to right. When a module calls another, it views the called module as
black box, passing required parameters and receiving results.

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

3
• Conditional Call
It represents that control module can select any of the sub module on the basis of some condition

4
Loop (Repetitive call of module)
• It represents the repetitive execution of module by the sub module.
• A curved arrow represents loop in the module.

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

6
Types of Structure Chart:

Transform Centered Structured:

These type of structure chart are designed for the systems that receives an input which is transformed by a
sequence of operations being carried out by one module.
Transaction Centered Structure:
These structure describes a system that processes a number of different types of transaction.

7
 Pseudo Codes

• Pseudo-code is a tool that can be used to express algorithms more precisely

• Pseudo-code is a combination of programming code and ordinary English
• Pseudo-code allows algorithms to be specified precisely without having to worry about programming language syntax
• There is currently no firmly established standard for Pseudo Code
• Pseudo-code is not actually executed on a computer, it simply provides a means for programmers to "Think out" their programs before
they implement them
• A carefully prepared pseudo code program can be easily converted to a programming language such as C++ or Java.
• HOW TO WRITE PSEUDO CODE?
• Any algorithm will eventually need to have its instructions performed by a computer
• For this reason the keywords used in Pseudo code are based on the main functions to a computer.

8
 Flow Charts

• A pictorial representation of an algorithm is called a ‘Flowchart’. In flowchart, the steps in the algorithm are
represented in the form of different shapes of boxes and the logical flow is indicated by interconnecting arrows.
The boxes are used to represent different operations and the arrows are used to represent the sequence of these
operations. Since this is a visual way of algorithm representation, it helps the programmer/tester in understanding
the logic of the program.

9
10
 Coupling
• Coupling is the measure of the degree of interdependence between the modules. A good software will have
low coupling.
• Types of Coupling:
• Data Coupling: If the dependency between the modules is based on the fact that they communicate by
passing only data, then the modules are said to be data coupled. In data coupling, the components are
independent to each other and communicating through data. Module communications don’t contain tramp
data. Example-customer billing system.
• Stamp Coupling: In stamp coupling, the complete data structure is passed from one module to another
module.

11
 Coupling

• Control Coupling: If the modules communicate by passing control information, then they are said to be control
coupled. It can be bad if parameters indicate completely different behavior and good if parameters allow factoring
and reuse of functionality. Example- sort function that takes comparison function as an argument.

• External Coupling: In external coupling, the modules depend on other modules, external to the software being
developed or to a particular type of hardware. Ex- protocol, external file, device format, etc.

12
 Coupling

• Common Coupling: The modules have shared data such as global data structures. The changes in global data
mean tracing back to all modules which access that data to evaluate the effect of the change. So it has got
disadvantages like difficulty in reusing modules, reduced ability to control data accesses and reduced
maintainability.

• Content Coupling: In a content coupling, one module can modify the data of another module or control flow is
passed from one module to the other module. This is the worst form of coupling and should be avoided.

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

Types of Cohesion:
• Functional Cohesion: Every essential element for a single computation is contained in the component. A functional
cohesion performs the task and functions. It is an ideal situation.
• Sequential Cohesion: An element outputs some data that becomes the input for other element, i.e., data flow between
the parts. It occurs naturally in functional programming languages.

14
 Cohesion

• Communicational Cohesion: Two elements operate on the same input data or contribute towards the same
output data. Example- update record into the database and send it to the printer.

• Procedural Cohesion: Elements of procedural cohesion ensure the order of execution. Actions are still weakly
connected and unlikely to be reusable. Ex- calculate student GPA, print student record, calculate cumulative
GPA, print cumulative GPA.

15
 Cohesion

• Temporal Cohesion: The elements are related by their timing involved. A module connected with temporal
cohesion all the tasks must be executed in the same time-span. This cohesion contains the code for initializing all
the parts of the system.
• Logical Cohesion: The elements are logically related and not functionally. Ex- A component reads inputs from
tape, disk, and network. All the code for these functions is in the same component. Operations are related, but
the functions are significantly different.
• Coincidental Cohesion: The elements are not related(unrelated). The elements have no conceptual relationship
other than location in source code. It is accidental and the worst form of cohesion. Ex- print next line and
reverse the characters of a string in a single component.

16
 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:

17
 Object Oriented Design

• In the object-oriented design method, the system is viewed as a collection of objects (i.e., entities). The state is
distributed among the objects, and each object handles its state data. For example, in a Library Automation
Software, each library representative may be a separate object with its data and functions to operate on these
data. The tasks defined for one purpose cannot refer or change data of other objects. Objects have their internal
data which represent their state. Similar objects create a class. In other words, each object is a member of some
class. Classes may inherit features from the superclass.

18
• Objects: All entities involved in the solution design are known as objects. For example, person, banks,
company, and users are considered as objects. Every entity has some attributes associated with it and has
some methods to perform on the attributes.
• Classes: A class is a generalized description of an object. An object is an instance of a class. A class defines
all the attributes, which an object can have and methods, which represents the functionality of the object.
• Messages: Objects communicate by message passing. Messages consist of the integrity of the target object,
the name of the requested operation, and any other action needed to perform the function. Messages are
often implemented as procedure or function calls.

19
• Abstraction In object-oriented design, complexity is handled using abstraction. Abstraction is the removal of the irrelevant and the
amplification of the essentials.
• Encapsulation: Encapsulation is also called an information hiding concept. The data and operations are linked to a single unit.
Encapsulation not only bundles essential information of an object together but also restricts access to the data and methods from the
outside world.
• Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the lower or sub-classes can import, implement,
and re-use allowed variables and functions from their immediate super classes. This property of OOD is called an inheritance. This
makes it easier to define a specific class and to create generalized classes from specific ones.
• Polymorphism: OOD languages provide a mechanism where methods performing similar tasks but vary in arguments, can be assigned
the same name. This is known as polymorphism, which allows a single interface is performing functions for different types. Depending
upon how the service is invoked, the respective portion of the code gets executed.

20
 Top Down Approach

Top Down Design

• We know that a system is composed of more than one sub-systems and it contains a number of
components. Further, these sub-systems and components may have their own set of sub-system
and components and creates hierarchical structure in the system.

• Top-down design takes the whole software system as one entity and then decomposes it to
achieve more than one sub-system or component based on some characteristics. Each sub-
system or component is then treated as a system and decomposed further. This process keeps
on running until the lowest level of system in the top-down hierarchy is achieved.

• Top-down design starts with a generalized model of system and keeps on defining the more
specific part of it. When all components are composed the whole system comes into existence.

• Top-down design is more suitable when the software solution needs to be designed from scratch

21
 Bottom Up approach

• The bottom up design model starts with most specific and basic components. It proceeds with composing higher level of
components by using basic or lower level components. It keeps creating higher level components until the desired system is
not evolved as one single component. With each higher level, the amount of abstraction is increased.

• Bottom-up strategy is more suitable when a system needs to be created from some existing system, where the basic
primitives can be used in the newer system.

• Both, top-down and bottom-up approaches are not practical individually. Instead, a good combination of both is used

22
 Software Measurement and Matrices

Software Measurement: A measurement is a 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:

• Create the quality of the current product or process.

• Anticipate future qualities of the product or process.
• Enhance the quality of a product or process.
• Regulate the state of the project in relation to budget and schedule.

23
• Classification of Software Measurement:
• There are 2 types of software measurement:
• Direct Measurement:
• In direct measurement the product, process or thing is measured directly using standard scale.
• Indirect Measurement:
• In indirect measurement the quantity or quality to be measured is measured using related parameter i.e. by use
of reference.

24
• 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:

• Planning
• Organizing
• Controlling
• Improving
• Classification of Software Metrics:
• There are 2 types of software metrics:

25
• 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.
• Process Metrics:
• Process metrics pay particular attention on enhancing the long term process of the team or organisation.
• 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

26
• Halstead’s metrics are included in a number of current commercial tools that count software lines of code. By counting the tokens and determining which are operators and which are operands, the
following base measures can be collected :

• n1 = Number of distinct operators.

• n2 = Number of distinct operands.
• N1 = Total number of occurrences of operators.
• N2 = Total number of occurrences of operands.

• In addition to the above, Halstead defines the following :

• n1* = Number of potential operators.

• n2* = Number of potential operands.

• Halstead refers to n1* and n2* as the minimum possible number of operators and operands for a module and a program respectively. This minimum number would be embodied in the programming
language itself, in which the required operation would already exist (for example, in C language, any program must contain at least the definition of the function main()), possibly as a function or as a
procedure: n1* = 2, since at least 2 operators must appear for any function or procedure : 1 for the name of the function and 1 to serve as an assignment or grouping symbol, and n2* represents the
number of parameters, without repetition, which would need to be passed on to the function or the procedure.

27
• n1* = Number of potential operators.
• n2* = Number of potential operands.

• Halstead refers to n1* and n2* as the minimum possible number of operators and operands for a module and a program
respectively. This minimum number would be embodied in the programming language itself, in which the required
operation would already exist (for example, in C language, any program must contain at least the definition of the function
main()), possibly as a function or as a procedure: n1* = 2, since at least 2 operators must appear for any function or
procedure : 1 for the name of the function and 1 to serve as an assignment or grouping symbol, and n2* represents the
number of parameters, without repetition, which would need to be passed on to the function or the procedure.

28
• Halstead metrics are :

• Halstead Program Length – The total number of operator occurrences and the total number of operand
occurrences.
• N = N1 + N2
• And estimated program length is, N^ = n1log2n1 + n2log2n2

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

29
• NJ = log2(n1!) + log2(n2!)
• NB = n1 * log2n2 + n2 * log2n1
• NC = n1 * sqrt(n1) + n2 * sqrt(n2)
• NS = (n * log2n) / 2
• Halstead Vocabulary – The total number of unique operator and unique operand occurrences.
• n = n1 + n2
• Program Volume – Proportional to program size, represents the size, in bits, of space necessary for storing the program. This parameter is dependent on specific algorithm
implementation. The properties V, N, and the number of lines in the code are shown to be linearly connected and equally valid for measuring relative program size.
• V = Size * (log2 vocabulary) = N * log2(n)

• The unit of measurement of volume is the common unit for size “bits”. It is the actual size of a program if a uniform binary encoding for the vocabulary is used. And error =
Volume / 3000

• Potential Minimum Volume – The potential minimum volume V* is defined as the volume of the most succinct 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

30
 Function Point Analysis

• Function point is appended to be a solution to the size measurement problem.

• FPA is a method or set of rules of Functional Size Measurement. It assesses the functionality delivered for its users, based on the user’s
external view of the functional requirements. It measures the logical view of an application not the physically implemented view or the
internal technical view.

• The Function Point Analysis technique is used to analyze the functionality delivered by software.

Objectives of FPA:
• The objective of FPA is to measure functionality that the user requests and receives.
• The objective of FPA is to measure software development and maintenance independently of technology used for implementation.
• It should be simple enough to minimize the overhead of the measurement process.
• It should be a consistent measure among various projects and organizations.

31
 Special Features of FPA

• Independent to programming language

• Estimate development efforts on early phases
• Directly linked with requirement analysis
• Completely based on user’s external view of systems

Principles of FPA
A system is decomposed into five functional units
• Inputs
• Outputs
• Enquiries: Request/Response
• Internal logical files
• External Logical files

32
Types of FPA:

Transactional Functional Type

• (i) External Input (EI): EI processes data or control information that comes from outside the application’s boundary. The
EI is an elementary process.
• (ii) External Output (EO): EO is an elementary process that generates data or control information sent outside the
application’s boundary.
• (iii) External Inquiries (EQ): EQ is an elementary process made up of an input-output combination that results in data
retrieval.
Data Functional Type
• (i) Internal Logical File (ILF): A user identifiable group of logically related data or control information maintained within
the boundary of the application.
• (ii) External Interface File (EIF): A group of user recognizable logically related data illusion to the software but maintained
within the boundary of another software.

33
Benefits of FPA
• FPA is a tool to determine the size of a purchased application package by counting all the functions included in
the package.
• It is a tool to help users discover the benefit of an application package to their organization by counting
functions that specifically match their requirements.
• It is a tool to measure the units of a software product to support quality and productivity analysis.
• It s a vehicle to estimate cost and resources required for software development and maintenance.
• It is a normalization factor for software comparison.

34
 Cyclometric Complexity

• Cyclomatic complexity of a code section is the quantitative measure of the number of linearly independent paths in it. It is
a software metric used to indicate the complexity of a program. It is computed using the Control Flow Graph of the
program. The nodes in the graph indicate the smallest group of commands of a program, and a directed edge in it
connects the two nodes i.e. if second command might immediately follow the first command.
• M = E – N + 2P

• where,
• E = the number of edges in the control flow graph
• N = the number of nodes in the control flow graph
• P = the number of connected components

35
 Control Flow graphs

• A Control Flow Graph (CFG) is the graphical representation of control flow or computation during the execution of programs or
applications. Control flow graphs are mostly used in static analysis as well as compiler applications, as they can accurately represent
the flow inside of a program unit. The control flow graph was originally developed by Frances E. Allen.

• Characteristics of Control Flow Graph:

• Control flow graph is process oriented.

• Control flow graph shows all the paths that can be traversed during a program execution.
• Control flow graph is a directed graph.
• Edges in CFG portray control flow paths and the nodes in CFG portray basic blocks.
• There exist 2 designated blocks in Control Flow Graph:

36
Entry Block:
• Entry block allows the control to enter into the control flow graph.
Exit Block:
• Control flow leaves through the exit block.
• Hence, the control flow graph is comprised of all the building blocks
node, end node and flows between the nodes.

• General Control Flow Graphs:

• Control Flow Graph is represented differently for all statements and loops.

37