Modularization

Modularization is the process of dividing a software system into multiple independent modules where each module works independently.
A module (software component) is defined as a piece of software with a programming interface.
Advantages of modularization are:
 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:
 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.
 Two modules that are loosely coupled are not dependent on each other. Uncoupled modules have no interdependence at all within them.
 A good design is the one that has low coupling. Coupling is measured by the number of relations between the modules.
 As 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.

Type of Coupling:
1. Data Coupling
2. Stamp Coupling
3. Control Coupling
4. External Coupling
5. Common Coupling
6. Content 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. Therefore, it involves tramp data. It may be
necessary due to efficiency factors- this choice made by the insightful designer, not a lazy programmer.
 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.
 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.

Cohesion
 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."
 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.
 Communicational Cohesion: Two elements operate on the same input data or contribute towards the same output data. Example- update record int 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.
 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. Lots of different activities occur, all at initial time.
 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.

Difference between Coupling & Cohesion

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 is a chart derived from Data Flow Diagram. It represents the system in more detail than
DFD.

Symbols used in construction of structured chart

Module: It represents the process or task of the system. It is of three types.
1. Control Module: A control module branches to more than one sub module.
2. Sub Module: Sub Module is a module which is the part (Child) of another module.
3. 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.
Example : Structure chart for an Email server
Pseudo-Code
Pseudo Code is system description in short English like phrases describing the function. It uses keyword and indentation. Pseudo codes are used as
replacement for flow charts. It decreases the amount of documentation required.
 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.
 Pseudo code contains more programming details than Structured English. It provides a method to perform the task, as if a computer is executing the
code.

Example of a Pseudocode:
 
Flowchart: Flowchart is a graphical representation of an algorithm. 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.
Basic Symbols used in Flowchart Designs:
Terminal: The oval symbol indicates Start, Stop and Halt in a program’s logic flow. A pause/halt is generally used in a program logic under some error
conditions. Terminal is the first and last symbols in the flowchart.

Input/Output: A parallelogram denotes any function of input/output type. Program instructions that take input from input devices and display output
on output devices are indicated with parallelogram in a flowchart.

Processing: A box represents arithmetic instructions. All arithmetic processes such as adding, subtracting, multiplication and division are indicated by
action or process symbol.

Decision: Diamond symbol represents a decision point. Decision based operations such as yes/no question or true/false are indicated by diamond in
flowchart.

Connectors: Whenever flowchart becomes complex or it spreads over more than one page, it is useful to use connectors to avoid any confusions. It is
represented by a circle.

Flow lines: Flow lines indicate the exact sequence in which instructions are executed. Arrows represent the direction of flow of control and
relationship among different symbols of flowchart.
Example: Draw a flowchart to input two numbers from user and display the largest of two numbers
Design Strategies
The design process for software systems often has two levels. At the first level the focus is on deciding which modules are needed for the system on the basis
of SRS (Software Requirement Specification) and how the modules should be interconnected.
Function Oriented Design is an approach to software design where the design is decomposed into a set of interacting units where each unit has a clearly
defined function.
Function Oriented Design Strategies: Function Oriented Design Strategies are as follows:
 Data Flow Diagram (DFD): A data flow diagram (DFD) maps out the flow of information for any process or system. It uses defined symbols like
rectangles, circles and arrows, plus short text labels, to show data inputs, outputs, storage points and the routes between each destination.
 Data Dictionaries: Data dictionaries are simply repositories to store information about all data items defined in DFDs. At the requirement stage, data
dictionaries contain data items. Data dictionaries include Name of the item, Aliases (Other names for items), Description / purpose, Related data items,
Range of values, Data structure definition / form.
 Structure Charts: It is the hierarchical representation of system which partitions the system into black boxes (functionality is known to users but inner
details are unknown). 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.
 Pseudo Code: Pseudo Code is system description in short English like phrases describing the function. It uses keyword and indentation. Pseudo codes are
used as replacement for flow charts. It decreases the amount of documentation required.
Top-Down Design
 In top-down model, an overview of the system is formulated, without going into detail for any part of it.
 Each part of the system is then refined in more details.
 Each new part may then be refined again, defining it in yet more details until the entire specification is detailed enough to validate the model.
Design Strategies
 In bottom-up design individual parts of the system are specified in details.
 The parts are then linked together to form larger components, which are in turn linked until a complete system is formed.
 Object-oriented languages such as C++ or JAVA use bottom-up approach where each object is identified first.
Difference between Top-Down and Bottom-Up Design Models:
Conclusion: The top-down approach is the conventional approach in which decomposition of higher level system into lower level system takes place
respectively. Talking about the bottom-up mechanism for algorithm designing, starting from designing lower abstraction modules and then integrating them
to higher level provides better efficiency.

Structured Approach Object Oriented Approach

It works with Top-down approach. It works with Bottom-up approach.
Program is divided into number of submodules Program is organized by having number of
or functions. classes and objects.
Function call is used. Message passing is used.
Software reuse is not possible. Reusability is possible.
Structured design programming usually left until Object oriented design programming done
end phases. concurrently with other phases.
Structured Design is more suitable for It is suitable for in-house development.
offshoring.
It shows clear transition from design to Not so clear transition from design to
implementation. implementation.
It is suitable for real time system, embedded It is suitable for most business applications,
system and projects where objects are not the game development projects, which are expected
most useful level of abstraction. to customize or extended.
DFD & E-R diagram model the data. Class diagram, sequence diagram, state chart
diagram, and use cases all contribute.
In this, projects can be managed easily due to In this approach, projects can be difficult to
clearly identifiable phases. manage due to uncertain transitions between
phase.
Measures, Metrics and Measurement
A measure provides a quantitative indication of the extent, dimension, size, capacity, efficiency, productivity or reliability of some attributes of a
product or process.
Measurement is the act of evaluating a measure.
A metric is a quantitative measure of the degree to which a system, component or process possesses a given attribute.
 
Software Measurement and Metrics
Software Measurement: A measurement is a manifestation of the size, quantity, amount or dimension of a particular attributes of a product or process.
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.
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.
Software metrics is a standard of measure that contains many activities which involve some degree of measurement. It can be classified into three
categories: product metrics, process metrics, and project metrics.
 Product metrics describe the characteristics of the product such as size, complexity, design features, performance, and quality level. (product
metrics are measures for the software product.)
 Process metrics can be used to improve software development and maintenance. Examples include the effectiveness of defect removal during
development, the pattern of testing defect arrival, and the response time of the fix process. Process metrics are: Productivity, Quality, Efficiency
etc. (Process metrics quantify the attributes of software development process and environment)
 Project metrics describe the project characteristics and execution. Examples include the number of software developers, the staffing pattern
over the life cycle of the software, cost, schedule, and productivity.

Productivity and Effort

 
Productivity is defined as the rate of output, or production per unit of effort, i.e. the output achieved with regard to the time taken but irrespective
of the cost incurred.
 
Hence most appropriate unit of effort is Person Months (PMs), meaning thereby number of persons involved for specified months. So,
productivity may be measured as LOC/PM (lines of code produced/person month)
 
Various Size Oriented Software Measures:
LOC Metrics
Lines of Code (LOC) is a software metric used to measure the size of a software program by counting the number of lines in the text of the program's
source code. SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming
productivity or effort once the software is produced.
For example: Consider this snippet of C code as an example of the ambiguity encountered when determining SLOC:
for (i = 0; i < 100; i += 1) printf("hello"); /* How many lines of code is this? */
In this example we have:
 1 Physical Lines of Code (LOC)
 2 Logical Line of Code (LLOC) (for statement and printf statement)
 1 comment line
Depending on the programmer and/or coding standards, the above "line of code" could be written on many separate lines:
for (i = 0; i < 100; i += 1)
{
printf("hello");
} /* Now how many lines of code is this? */
In this example we have:
 4 Physical Lines of Code (LOC): is placing braces work to be estimated?
 2 Logical Line of Code (LLOC): what about all the work writing non-statement lines?
 1 comment line: tools must account for all code and comments regardless of comment placement.
Advantages of using LOC:
 It is simple to measure
Disadvantages of using line of code as a unit of sizing of software.
 Difficult to measure LOC in the early stages of a new product.
 It characterise only one specific view of size, namely length, it takes no account of functionality or complexity
 Bad software design may cause excessive line of code
 It is language dependent
 No proper industry standard exist for this technique.
Functional Point (FP) Analysis
 Function point metrics, developed by Alan Albercht of IBM, were first published in 1979.
 In 1984, the International Function Point Users Group (IFPUG) was set up to clarify the rules, set standards, and promote their use and evolution
 The principle of Albrecht’s function point analysis (FPA) is that a system is decomposed into functional units.
 Inputs: information entering the system
 Outputs: information leaving the system
 Enquiries: requests for instant access to information
 Internal logical files: information held within the system
 External interface files: information held by other system that is used by the system being analysed.
External Inputs (EI): A process where inputs are imported from outside the boundary of the system through external sources such as external system or from
the user's input screen to form internal logic database file, where input data consists of control information and business information, but internal logic file
gets updated only for the business information

External Output (EO): A process where data is passed to the outside system or application from inside in the form of reports or files. Generally, these
reports or files are get derived from the data present in the internal logic file.
Internal Logic Files (ILF): A group of logically related data residing entirely within the application boundary. It is maintained by External Inputs (EI). Every
ILF has to have atleast one External Input. It maintains adds, changes and deletes.

External Interface Files (EIF): A group of logically related data that resides entirely outside the application boundary. It is maintained by other applications.
An EIF is an ILF for another application.

Every application that retrieves from the file counts the EIF. It must have transactions with EIF usually with EO OR EQ
External InQuiries (EQ): an elementary process with both input and output components that result in data retrieval from one or more internal logical files
and external interface files.

The five functional units are divided in two categories:

1. Data function types – ILF, EIF
2. Transactional function types – EI, EO, EQ
Counting Function Points:
Step 1: 5 Function types are ranked according to their complexity: Low, Average or High, using a set of prescriptive standards. (determination of complexity
is subjective based on organization FP methods.
Step 2: After classifying each of the five function types, the UFP is computed using predefined weights for each function type. UFP Calculation Table:
UFP = ∑(product of all FP components with its weighing factors)
Step 3: In this step, 14 general system characteristics is rated on a scale from 0 to 5 in terms of their likely effect on the project or application
Total Degree of Influence = Sum of all GSCs i.e.,
TDI = ∑14 Degrees of Influence
VAF = (TDI*0.01) + 0.65

Step 4: Function Points Count:

FP = UAF X VAF

Functions points may compute the following important metrics:

• Productivity=FP / persons-months
• Quality=Defects / FP
• Cost=Rupees / FP
• Documentation=Pages of documentation per FP
Example:

Given the following values, compute function point when all complexity adjustment factor (CAF) and weighting factors are average.
User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4

Explanation:
Step-1: As complexity adjustment factor is average (given in question), hence,
scale = 3.
F = 14 * 3 = 42
Step-2:
VAF = 0.65 + (0.01 * 42) = 1.07
Step-3: As weighting factors are also average (given in question) hence we will
multiply each individual function point to corresponding values in TABLE.
UFP = (50*4) + (40*5) + (35*4) + (6*10) + (4*7) = 628
Step-4:
Function Point = 628 * 1.07 = 671.96
 
This is the required answer.

Note: FPs consider the number of functions being developed based on the requirements specification. FPs are used to estimate functional size of any
software program.
Complexity Measures
 
1. Halstead Software Science
2. Cyclomatic Complexity
 
Halstead's Complexity Measures
 
 In 1977, Mr. Maurice Howard Halstead introduced metrics to measure software complexity.
 Halstead’s metrics depends upon the actual implementation of program and its measures, which are computed directly from the operators and operands
from source code, in static manner.
 It allows to evaluate testing time, vocabulary, size, difficulty, errors, and efforts for C/C++/Java source code.
 According to Halstead, “A computer program is an implementation of an algorithm considered to be a collection of tokens which can be classified as
either operators or operands”. Halstead metrics think a program as sequence of operators and their associated operands.
 
He defines various indicators to check complexity of module.
 

When we select source file to view its complexity details in Metric Viewer, the following result is seen in Metric Report:
Example:
 
Cyclomatic Complexity
 
 Cyclomatic complexity is a software metric used to measure the complexity of a program. These metric, measures independent paths through program
source code.
 Independent path is defined as a path that has at least one edge which has not been traversed
before in any other paths.
 Cyclomatic complexity can be calculated with respect to functions, modules, methods or classes within a program.
 This metric was developed by Thomas J. McCabe in 1976 and it is based on a control flow representation of the program. Control flow depicts a program as
a graph which consists of Nodes and Edges.
 In the graph, Nodes represent processing tasks while edges represent control flow between the nodes.

Flow graph notation for a program:

Flow Graph notation for a program is defines. Several nodes connected through the edges. Below are Flow diagrams for statements like if-else, While, until and
normal sequence of flow.
Mathematical representation: Flow graph for this program will be:
Mathematically, it is set of independent paths through the graph diagram. The
complexity of the program can be defined as -
 V(G) = E - N + 2
Where,
 E - Number of edges
 N - Number of Nodes
 V (G) = P + 1
Where P = Number of predicate nodes (node that contains condition)
Example -
i = 0;
n=4; //N-Number of nodes present in the graph
while (i<n-1) do
j = i + 1;
while (j<n) do
if A[i]<A[j] then Computing mathematically,
swap(A[i], A[j]);  V(G) = 9 - 7 + 2 = 4
end do;  V(G) = 3 + 1 = 4 (Condition nodes are 1,2 and 3 nodes)
i=i+1;  Basis Set - A set of possible execution path of a program
end do; 1, 7
1, 2, 6, 1, 7
1, 2, 3, 4, 5, 2, 6, 1, 7
1, 2, 3, 5, 2, 6, 1, 7
Properties of Cyclomatic complexity:
Following are the properties of Cyclomatic complexity:
 V (G) is the maximum number of independent paths in the graph
 V (G) >=1
 G will have one path if V (G) = 1
 Minimize complexity to 10
 
Steps to be followed:

The following steps should be followed for computing Cyclomatic complexity and test cases design.
Step 1 - Construction of graph with nodes and edges from the code
Step 2 - Identification of independent paths
Step 3 - Cyclomatic Complexity Calculation
Step 4 - Design of Test Cases
 
Once the basic set is formed, TEST CASES should be written to execute all the paths.
Compute function point value for a project with the following domain characteristics: (Function Point Analysis)
 No. of I/P = 30
 No. of O/P = 62
 No. of user Inquiries = 24
 No. of files = 8
 No. of external interfaces = 2
Assume that all the complexity adjustment values are average. Assume that 14 algorithms have been counted.