BPUT

FORMAT FOR PREPARATION OF PROJECT REPORT

FOR

MCA

Paper size and margins

Pages should be printed on one side only. The report should be hard bound with black cover and
printed in golden letters.

Paper size:
The paper size should strictly be A4 i.e 8.27 X 11.69 inches.

Margins:
Margins must be: left: 1.25”
Right: 1”
Top: 1”
Bottom: 1”

Texts/Fonts

Font: All text in Times New Roman, aligned in justify.

The paragraph line spacing should be1.5 lines

Style and Font sizes

place Style Size

Main section heading Bold 16pt

Sub section heading Bold 14pt
Figures and table titles normal 12pt
Chapter Title bold 18pt
All other text normal 12pt

Diagrams/Images/Tables

1. All Diagrams/Images/Tables should be clear, electronically drawn and should be having

good resolution.
2. Single Diagrams/Images/Tables should not be more than the available page size (within
margins).
3. Diagrams/Images/Tables should be aligned centrally to the page.
4. Diagrams/Images/Tables titles should be also aligned centrally to the page.
 5. Diagrams/ Images/ Tables should be properly numbered. Example: If chapter-5 contains
three images, then the numbering of the image should be 5.1, 5.2 and 5.3 respectively.

Submitted Copies
1. 2 hard copies of report (1 Exam Department, 1 Library, 1 Self) to be submitted in hard
binding form.
2. Soft copy of the project on CD ( to be submitted to the Universiy) on a cover mentioning the
name of the project, name of the student, Regd No. , name of the college, Year

Arrangement
The sequence in which the project report material should be arranged and bound should be as
follows:

a. Cover page
b. Certificate of the internal supervisor
c. Certificate of the external supervisor
d. Self certificate
e. Acknowledgement
f. List of Figures (page no)
g. List of Tables (page no)
h. List of abbreviations
i. Synopsis of the project (3-4 pages)
j. Table of Content (page no)
k. Chapters
 Chapter-1
 Chapter-2
 ……………..
l. Conclusion
m. Future scope
n. Bibliography

Cover Page & Title Page – A specimen copy of the Cover page & Title page of the project report
are given below as sample. The report should be hard bound

Certificate of the Internal Supervisor – The Certificate shall be in double line spacing using Font
Style Times New Roman and Font Size 14, as per the format given below.

The certificate shall carry the supervisor’s signature and shall be followed by the supervisor’s name,
academic designation (not any other responsibilities of administrative nature), department. The term
‘INTERNAL SUPERVISOR’ must be typed in capital letters between the supervisor’s name and
academic designation.

Certificate of the External Supervisor – The Certificate shall be in double line spacing using Font
Style Times New Roman and Font Size 14, as per the format given below.

The certificate shall carry the supervisor’s signature and shall be followed by the supervisor’s name,
academic designation (not any other responsibilities of administrative nature), department and full
address of the institution where the supervisor has guided the student. The term ‘EXTERNAL
SUPERVISOR’ must be typed in capital letters between the supervisor’s name and academic
designation.

Self Certificate- The Certificate shall be in double line spacing using Font Style Times New Roman
and Font Size 14, as per the format given below.

Acknowledgement- Acknowledgement should be one page typed with line spacing 1.5, Font Style
Times New Roman and Font Size 14.

List of Tables – The list should use exactly the same captions as they appear above the tables in the
text. One and a half spacing should be adopted for typing the matter under this head.

List of Figures – The list should use exactly the same captions as they appear below the figures in
the text. One and a half spacing should be adopted for typing the matter under this head.

List of Symbols, Abbreviations and Nomenclature – One and a half spacing should be adopted or
typing the matter under this head. Standard symbols, abbreviations etc. should be used.

Abstract format:

1. Not more than 300 words.

2. Precise, concise and duly approved by the guide.
3. Text and font guidelines to be followed.

Table of Contents – The table of contents should list all material following it. A specimen copy of
the Table of Contents of the project report is given below as sample.

Chapters – The chapters may be broadly divided into 3 parts (i) Introductory chapter, (ii)
Chapters developing the main theme of the project work (iii) and Conclusion.

The main text will be divided into several chapters and each chapter may be further divided into
several divisions and sub-divisions.

 Each chapter should be given an appropriate title.

 Tables and figures in a chapter should be placed in the immediate vicinity of the
reference where they are cited.

 Footnotes should be used sparingly. They should be typed single space and placed
directly underneath in the very same page, which refers to the material they annotate.
Chapter’s format:

1. Every chapter must have a title. Every sub section must be numbered.
2. Every numbering should be in numeric. For example chapter 2, section 1 should be
numbered as 2.1.
3. Text and font guidelines to be followed.

Appendix format:
Appendix should not be numbered as chapters. Appendix should be numbered only in Roman. The
title of appendix should be appropriate and the contents must be specific. The necessity of the
appendix must be explained to the respective guide. Every appendix must have proper explanations
of usage and should contain the source from where it’s derived. (Text and font guidelines to be
followed)

References:

1. References should be cited clearly in the text wherever required with square brackets
containing reference number. (For example[12] says that the preceding text has relevance
with support from the cite mentioned in reference number 12).
2. Not more than 12 and not less than 5 references are allowed. In case of any deference from
the stipulated range one must get the approval of concerned guide and HOD.
3. Website and web pages reference format:
Title, full url
Example: Grid security infrastructure, http://www.globus.org/security/overview.html
4. Books reference
Author(s), Title, Publication, Edition, Year
Example: Stallings W., Data and Computer Communications, Prentice-Hall of India, 5th Ed.,
2003.
5. Research paper reference.
Author(s), title, journal/ workshop etc, (volume( issue):pages), month year
Example: K. M. Chandy and L. Lamport. Distributed snapshots: Determining global states
of distributed systems. ACM Transactions on Computer Systems, (63–75), Feb. 1985.

All other references must be approved by the concerned guide.

*****
 A
PROJECT REPORT
ON
“ONLINE EXAMINATION SYSTEM”
Submitted to Biju Patnaik University of Technology in partial fulfillment of the
requirement for the award of degree in

Master Of Computer Application

SUBMITTED BY- SUBHADIPTA PRADHAN

REGISTRATION NO-1705274023

STREAM MCA (6TH SEM.)

INTERNAL GUIDE: External guide:

Mr. Samir Kumar Patro
(Asst Prof., Dept. of MCA) .

UNITED SCHOOL OF BUSINESS MANAGEMENT

(Ministry of HRD, Govt. Of India and is affiliated to Biju patanaik University of
Technology (BPUT), Govt. Of Odisha)
 CERTIFICATE

This is to certified that the project report “CIG: An approach to test Component

Composition” being submitted by “SISIR KUMAR JENA” bearing registration

number: 0805297005, in partial fulfillment of requirement for the award of degree of

Bachelor in Technology in CSE is a bonafide work carried out under my/our

supervision.

Sisir Kumar Jena Narottam Sahu

HOD INTERNAL SUPERVISOR
Department of CSE & IT Professor
College name Department of IT

External Examiner

CERTIFICATE
This is to certify that Mr. SISIR KUMAR JENA bearing registration number:

0805297005, has successfully developed a project on “CIG: An approach to test

Component Composition” under our guidance. His skill set, knowledge on software

and sincere effort has contributed towards successful completion of the project.

Sisir Kumar Jena Mr. X. X Xxxxxx

HOD EXTERNAL SUPERVISOR
Department of CSE & IT Project Leader
College name CMC Academy, Bhubaneswar

LOGO
 CERTIFICATE

I hereby declare that the matter embodied in this report is original and has not been

submitted for the award of any other degree

Sisir Kumar Jena

Regd. No. : 0805297005
Department of CSE
 Acknowledgement
I take this opportunity with much pleasure to thank all the people who have helped me through the
course of my journey towards producing this thesis. I sincerely thank my thesis guide, Prof. Arup
Abhinna Acharya, for his guidance, help and motivation. Apart from the subject of my research, I
learnt a lot from him, which I am sure will be useful in different stages of my life. I would like to
express my gratitude to M. Tech Coordinator Prof. Hati for his review and many helpful comments.

I am especially grateful to my colleagues for their assistance, criticisms and useful insights. I am
thankful to all the other M. Tech students of KIIT UNIVERSITY with whom I share tons of fun
memories. I would like to acknowledge the support and encouragement of my friends. My sincere
gratitude also goes to all those who instructed and taught me through the years.

Finally, this thesis would not have been possible without the confidence, endurance and support of
my family. My family has always been a source of inspiration and encouragement. I wish to thank
my parents, whose love, teachings and support have brought me this far.

Name of the Student

 List of Table

Sl. No. Table Name Table Caption Page No.

1 Table 1.1 Software modules versus Reusable components 5
2 Table 1.2 Software modules versus Reusable components 30
3 Table 1.3 Software modules versus Reusable components 48
4 Table 2.1 Software modules versus Reusable components 5
5 Table 2.2 Software modules versus Reusable components 30
6 Table 3.1 Software modules versus Reusable components 48
7 Table 3.2 Software modules versus Reusable components 5
8 Table 4.1 Software modules versus Reusable components 30
9 Table 5.1 Software modules versus Reusable components 48
 List of Figures

Sl. No. Figure Name Caption Page No.

1 Figure 1.1 Software modules versus Reusable components 5
2 Figure 1.2 Software modules 30
3 Figure 1.3 Software modules versus Reusable components 48
4 Figure 2.1 Software modules components 58
5 Figure 2.2 Software modules versus Reusable components 60
6 Figure 3.1 Software modules 68
7 Figure 3.2 Software modules versus Reusable components 75
8 Figure.1 Software modules 80
9 Figure 5.1 Software modules versus Reusable components 88

Contents
Chapter No Title Page No
1 Introduction 1
1.1 Background 1
1.1.1 Research Objective 1
1.1.2 Structure of the Thesis 3
1.2 Introduction to Software Component 3
1.2.1 What is software component? 3
1.2.2 Properties of software component 4
1.2.3 Software modules versus software components in CBSE 5
1.2.4 Component Testing 7
1.2.5 Component Composition 11
1.3 Introduction to Model Based Testing with UML 13
1.3.1 What is Model based Testing? 15
1.3.2 Model based testing process 17
1.3.3 Introduction to UML 20
2 Testing Component Based Software (A Survey) 23
2.1 Integration Testing for Component based software 23
2.1.1 Traditional integration testing methodology 23
2.1.2 UML based integration testing methodology 25
2.2 Regression Testing for Component based software 29
2.3 Built-in Contract Testing 29
2.3.1 BIT Architecture 30
2.3.1 Example of Contract Testing 34
2.4 Testing based Component Composition 36

Chapter – 1
 Introduction
Today, the concept of software reuse has been widely accepted by the software industry. The
reusability concept has been provided on the development of software components. Software
components are the parts for constructing software systems. With the increase of software
component products in today’s commercial market, many software vendors and workshops have
begun to use a new approach, known as component-based software engineering (CBSE), to develop
large, complicated software application systems based on available and reusable components. Its
major objective is to reduce software development cost and time by reusing available components,
including third-party and in-house grown components. This trend drives a strong demand for CBSE
methodology, standards, and guidelines to help engineers and managers in software analysis, design,
testing, and maintenance of component-based software and its components.

1.1 Background
In the component-based software-engineering paradigm, component-based software is developed
using a set of in-house and commercial-off-the-shelf components. These components are reused,
adapted, and tailored to meet the specifications of a specific project in a given context, including
system platform, technology, and running environment.

Since system quality depends on component quality, any defective component causes a ripple impact
on all systems built on it. Hence, component validation and quality control is critical to both
component vendors and users. To validate component quality, component vendors must perform a
cost-effective test process and implement a rigorous quality process for all generated software
components. Component users must go through well-defined processes to evaluate, validate, and
accept third party components before using them in a component-based software system.

Generally speaking, software component testing refers to testing activities that uncover software
errors and validate the quality of software components at the unit level. In traditional software
testing, component testing usually refers to unit testing activities that uncover the defects in software
modules.

1.1.1 Research Objective

My objective of the research is to provide the answer to the following questions:

Why has reuse of third-party software components become popular recently?

Building systems based on reusable components is not a new idea. It has been proven to be a very
effective cost-reduction approach in the computer hardware industry. Today, that industry is able to
build computer systems based on standardized high-quality hardware parts and devices reliably and
quickly. Software engineers learned the value of this idea many years ago. They developed reusable
software modules as internally shared building blocks for constructing different software systems,
and they established repositories of such modules, but in an ad hoc manner. Many years of trial and
error proved to many software developers that it was not easy to build software systems based on
reusable software components. The major reasons include the lack of a well-defined discipline for
component-based software engineering and the absence of a comprehensive collection of
standardized high-quality software components within the company or on the market.
Recently, the increasing complexity of information technology (IT)-based software application
systems and intensive competition in the marketplace forced software vendors and researchers to
look for a cost-effective approach to constructing software systems based on third-party components.
The major goal is to shorten the software development cycle and thereby reduce cost. Hence,
component-based software engineering becomes a popular subdiscipline within software engineering
because of its promising potential for cost and cycle-time reductions.

Why is testing software components and component-based software important?

As mentioned earlier, widespread reuse of a software component with poor quality may wreak
havoc. Improper reuse of software components of good quality may also be disastrous. Testing and
quality assurance is therefore critical for both software components and component-based software
systems. A number of recent books address the overall process of component-based software
engineering or specific methods for requirements engineering, design, and evaluation of software
components or component-based software. We are not aware of any books focusing on testing,
validation, certification, or quality assurance in general for reusable software components and
component-based software systems.

Now after answering the above questions, we would like to introduce the issues and challenges in
component testing approach:

 Difficult to perform component analysis and testing due to the lack of the access to
component source code and internal artifacts.
 Testing reused components in a new reuse context and environment.
 Expensive cost of constructing component test bed, including test drivers and stubs.

In our work we proposed a model and an algorithm generate testcases for component composition.
We take the help of UML statechart diagram and CIG for generating the testcases. CIG stands for
Component Interaction graph whose detail will be discussed later.

1.1.2 Structure of the Thesis

The structure of the thesis consists of 5 chapters. We briefly describe their contents here.

Chapter I: Introduction provides background on software components, component-based software,

UML diagrams, model based testing as well as component-based software engineering. Moreover, it
explains the importance of testing software components and component-based software. It consists
of three sections. Section 1.1 explains the background, research objective and structure of the thesis.
Section 1.2 describes about components, CBSE, component testing and component composition.
Section 1.3 review the process of model based testing and describe briefly about the UML diagrams.

Chapter 2: A survey on testing component based software is presented. In this survey we present
some of the literature like integration testing, regression testing and built-in contract testing. This
chapter is again sub divided into four subsections and each subsections is explaining about different
type of testing technique that can be applied upon component based software.
 Table 1.1 : Sample database table

1.2 Introduction to Software Component

In the early days of programming, programs were constructed by creating a main program to control
(or invoke) a number of subroutines. Each subroutine was programmed as a specific part of the
program based on the given requirements and function partitions. To reduce programming efforts,
programmers in a project team reused subroutines during a project’s implementation. Hence,
subroutine reuse is one of the earliest formats in software reuse. Recently, several well-defined
component-based development methods have been published to support the development of
component-based software systems.

1.2.1 What is Software Components?

Let us review some of the important definitions of software components given by the experts. One of
the earliest definitions is given by Gready Booch [7]:

A reusable software component is a logically cohesive, loosely coupled module that denotes a single
abstraction.

This definition captures the idea that a reusable component is an encapsulated software module
consisting of closely related component elements. Later, Clement Szyperski presented his well-
known definition of a software component at the 1996 European Conference on Object-Oriented
Programming [7]:

Figure 1.1 : Component based software development

1.2.2 Properties of Software Component

Component properties refer to the essential characteristics of software components. A software

component in CBSE must have the following basic properties [7].
 Identity: Each component must be uniquely identifiable in its development environment and
targeted deployment environment. Without this feature, a large scale of component reuse is
impossible.
 References

[1] Y. Wu, D. Pan, and M. Chen, “Techniques for testing component-based software,” in Proceedings of
the 7th IEEE International Conference on Engineering of Complex Computer Systems, 2001, pp.
222–232.

[2] Ye Wu, Mei-Hwa Chen, Jeff Offcutt : UML-Based Integration Testing for Component-Based
Software.

[3] Jerry Zeyu Gao, H.-S. Jacob Tsao, Ye Wu : Testing and Quality Assurance for Component-Based
Software, Artech House, Boston, London

[4] Hans-Gerhard Gross : Component-Based Software Testing with UML, Springer Berlin Heidelberg,
New York, 2005

[5] C. Atkinson and H.-G. Gross, “Built-in contract testing in modeldriven, component-based
development,” in ICSR Work. on Component- Based Develop. Processes, 2002.

[6] Colin Atkinson, Joachim Bayer, and Dirk Muthig, “Component-Based Product Line Development:
The KobrA Approach”, Software Product Line Conference, 2000