NALANDA INSTITUTE OF TECHNOLOGY
SEMINAR REPORT GUIDELINE
Each student is required to write a comprehensive report about the seminar. The report should
consist of 20 to 25 pages describing the topic selected. The report should be in the format as
described below.
ARRANGEMENT OF CONTENTS:
The sequence in which the seminar report material should be arranged and bound should be as
follows:
A.
B.
C.
D.
E.
F.
G.
H.
I.
J.
Cover Page & Title
2. Certificate
3. Acknowledgements
4. Abstract
5. Table of Contents
6. List of Tables – if any
7. List of Figures – if any
8. Chapters
9. Appendix- if any(programs, data sheets, derivations, etc)
10. References
The table and figures shall be introduced in the appropriate places.
PAGE DIMENSION AND BINDING SPECIFICATIONS:
The dimension of the seminar report should be in A4 size.
PREPARATION FORMAT:
Abstract – Abstract should be one page synopsis of the seminar report typed 1.5 line spacing, Font Style
Times New Roman and Font Size 12.
Table of Contents – A specimen copy of the Table of Contents of the seminar report is given in
Appendix
List of Tables & List of Figures – 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.
Chapters – The chapters may be broadly divided into 4/5 parts 1) Introduction with Open Research
Issues 2) Overviews of Selected issues with Literature Reviews 3) Proposed Work (for project work) 4)
Tools/Platform/Experimental Setup/Hardware Requirements with Results & Discussions 5)
Summary/Conclusions 6) References
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.
List of References –The listing of references should be typed 4 spaces below the heading
“REFERENCES” in alphabetical order in single spacing left – justified. The reference material should be
listed in the alphabetical order of the first author. The name of the author/authors should be immediately
followed by the year and other details. The orders of references in the List of References are either in the
order of the of year of publications OR in the order of references cited in the text. References for
journals, conferences and books are provided.
A typical illustrative list given below relates to the citation example quoted below. Which are different
for Journals, Conferences proceedings and Books
REFERENCES
[1] S. Zhang, C. Zhu, J. K. O. Sin, and P. K. T. Mok, “A Novel Ultrathin Elevated Channel Low-temperature poly-Si TFT,” IEEE Electron Device
Lett., vol. 20, pp. 569–571, Nov. 1999.
[2] S. P. Bingulac, “On the Compatibility of Adaptive Controllers”, Proc. 4th International National Conf. Circuits and Systems Theory, New York,
1994, pp. 8–16.
[3] Rajiv Ramaswami and Kumar N. Sivarajan, “Optical Networks: A Practical Perspective”, Morgan Kaufmann Publishers, 2 nd Edition, 2002.
TYPING INSTRUCTIONS:
One and a half spacing should be used for typing the general text. The general text shall be typed in the
Font style „Times New Roman‟ and Font size 12.
Suggested Font Sizes
Details
Font Type
Font size
Spacing
Times New Roman
16pt bold capitals
Centered
Chapter headings with
chapter number on top
Section headings
Times New Roman
14pt bold capitals
Left adjusted
Subsection headings
Times New Roman
12pt. sentence case
Left adjusted
Paragraph headings
Times New Roman
12pt.bold sentence case
Left adjusted
Body of seminar report
Times New Roman
12 pt
Adjusted on both left
and right(Justified) and
with 1.5 spacing for text
and double spacing for
equations
Margins
Left Margin
1.5 inch
To accommodate
binding area
Right Margin
1.25 inch
Top
2.0inch
On pages in which chapter
begins
1.0 inch
Other pages
Bottom
1.25 inch
CIG: AN APPROACH TO TEST COMPONENT
COMOSITION
A SEMINAR REPORT
Submitted by
RAKESH KUMAR SAHOO
REGD. NO: 0805297005
in partial fulfillment for the award of the degree
of
BACHELOR OF TECHNOLOGY
in
COMPUTER SCIENCE & ENGINEERING
LOGO
LOGO
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
NALANDA INSTITUTE OF TECHNOLOGY
BIJU PATNAIK UNIVERSITY OF TECHNOLOGY
MAY 2011
LOGO
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
NALANDA INSTITUTE OF TECHNOLOGY
CERTIFICATE
This is to certified that the project report “CIG: An approach to test Component
Composition” being submitted by “RAKESH KUMAR SAHOO” 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
HOD
Department of CSE & IT
Nalanda Institute of Technology
Chandaka, Bhubaneswar
Narottam Sahu
INTERNAL SUPERVISOR
Professor
Department of IT
LOGO
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
NALANDA INSTITUTE OF TECHNOLOGY
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
Rakesh Kumar Sahoo
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
1
Title
Introduction
1
1.1
Background
1
1.1.1
Research Objective
1
1.1.2
Structure of the Thesis
3
1.2
1.3
2
Page No
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
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
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 wellknown 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