J. Software Engineering & Applications, 2009, 2: 209-220
doi:10.4236/jsea.2009.23029 Published Online October 2009 (http://www.SciRP.org/journal/jsea)
1
An Exploratory Case Study in Designing and
Implementing Tight Versus Loose Frameworks
Manjari GUPTA1, Ratneshwer GUPTA2, A. K. TRIPATHI3
1Department of Computer Science, Faculty of Science, Banaras Hindu University, Varanasi, India; 2Department of Computer Science,
MMV, Banaras Hindu University, Varanasi, India;3Department of Computer Engineering, Institute of Technology, Banaras Hindu
University, Varanasi, India.
Received May 5th, 2009; revised June 20th, 2009; accepted June 24th, 2009.
ABSTRACT
Frameworks provide larg e scale reuse b y providing skeleton structure of similar applica tions. But the generality, that a
framework may ha ve, makes it fairly complex, hard to unde rstand and thus to reuse. Fram eworks have been classified
according to many criteria. This paper proposes two types of framework (based on the concept of ‘generality’) named
as: tight framework and loose framework. A case study is done by developing loose and tight frameworks for the appli-
cation sets of Environment for Unit testing (EUT) domain. Based on the experience that we got by during this case
study, we tried to find out the benefits of one (tight or loose) framework over the other. This work attempts to provide an
initial background for meaningful studies related to the concept of ‘Design and Development of Framework’.
Keywords: Framework Reuse, Environment for Unit Testing, Condition Coverage Criteria
1. Introduction
“Frameworks are reusable designs of all or part of a
software system described by a set of abstract classes and
the way instances of those classes collaborate”. It is al-
ways the result of domain analysis [1]. Frameworks may
be classified according to many criteria such as manner
of deployment in different applications, level of support
that provides to applications, type of services they have
(entity framework, control framework), level of abstrac-
tion they have (white box framework, black box frame-
works) etc. Frameworks are normally developed by
keeping in mind requirements of multiple similar appli-
cations. Frameworks should be developed and delivered
in such a manner so that problems in instantiation (like
determining the applicability of a framework, under-
standing and modifying if necessary, architectural mis-
match etc. [2]) do not arise and overheads (requirements
that are not required in a particular application), do not
get transported with the framework. In order to develop a
framework, its scope must not be an afterthought and it
should be considered at the beginning i. e. at the time of
designing frameworks. When one talks about frame-
works, its scope and generality are necessary to consider.
Here, we classify frameworks by considering the gen-
erality they have. In software engineering literature, we
could not find the formal categorization of frameworks
based on ‘generality’ concep t. We classify frameworks in
two categories by considering their generality as follows.
A loose framework is a framework that does not fix
the way of performing many activities (that may be per-
formed differently in similar applications in a domain) in
the framework itself. It only provides the control abstrac-
tion and thus may need to work together with other
frameworks for some activities that will extensively in-
teract with it. Such frameworks may be useful for those
applications that have many possible variations in their
requirements for example business application systems,
E-governance systems etc.
A tight framework fixes the way of performing most
of such activities in the framework itself. Thus, these
frameworks are highly useful for (only) those similar
applications that require performing those activities in a
particular way as defined and implemented in the
framework. Such frameworks may be useful for those
applications that have very few variations in their proper-
ties like embedded systems, pervasive systems etc.
During design of a framework certain roles and re-
sponsibilities amongst the classes along with their col-
laboration are fixed. Variability among applications is
represented as hot spots. Thus, by comparing the already
fixed roles and responsibilities as well as the variability
(hotspots) of different frameworks, for the same domain,
one can say “what is the scope of a framework?” and

An Exploratory Case Study in Designing and Implementing Tight Versus Loose Frameworks 210
thus “whether a tight or a loose framework development
would be beneficial for that domain?”
To the best of our knowledge, there is lack of such
study/work in which tight and loose frameworks, for a
same domain, are compared so that one can list the cases
in which one (tight or loose framework) would be better
than the other. In this paper, a tight and a loose framework
for ‘Environment of Unit Testing’ have been developed
and a comparative study has been made between the two
types of frameworks. Based on the observations of this
study, we tried to answer the following questions:
1) Which framework (tight or loose) is more reusable
in terms of “ease of reuse”?
2) Which one is more reusable in terms of “number of
reuses”?
3) Which one is easy to develop?
4) Which one is heavier in terms of size?
5) Which one is more complex?
Reminder of this paper is organized as follows. The
section 2 attempts to present, in a concise manner, the
research efforts related to the topic of discussion. In sec-
tion 3, we briefly describe the domain ‘EUT’ for which
frameworks have been developed. Designs of a loose and
a tight framework for “EUT” have been described in sec-
tion 4 and 5 respectively. A comparative study of loose
and tight frameworks has been discussed in section 6.
Finally, we conclude in section 7.
2. Related Work
Software engineering, over the last decades, has been
promoting the development of software systems with
software frameworks. Researchers and practitioners have
been considering various aspects of framework devel-
opment and related issues. Software frameworks are
classified according to several criteria.
There are two styles of frameworks that are commonly
used: called and calling frameworks. Sparks et al. [3]
showed the reuse with Called and calling frameworks.
Called frameworks are very much like traditional librar-
ies in that the application code calls the framework when
some framework service is needed. Calling frameworks
on the other hand, reverse the role of the framework and
the application, because the framework calls the applica-
tion code, rather than the other way around. Some au-
thors defined frameworks according to domain depend-
ency: vertical and horizontal frameworks [4]. A frame-
work dependent on specific domain is referred to as ver-
tical framework. A framework independent on specific
domain is referred to as horizontal framework. Accord-
ing to Taligent, Inc (now IBM) [5]) the problem domain
that a framework addresses can encompass application
functions, domain functions, or support functions. Ap-
plication frameworks encapsulate expertise applicable to
a wide variety of programs. These frameworks encom-
pass a horizontal slice of function ality that can b e app lied
across client domains. Current commercial graphical user
interface (GUI) application framework, which supports
the standard function req uired by all GUI applications, is
one type of application frameworks. Domain frameworks
encapsulate expertise in a particular problem domain.
These frameworks encompass a vertical slice of func-
tionality for a particular client domain. Examples of do-
main frameworks include: a control systems framework
for developing control applications for manufacturing,
securities trading framework, multimedia framework, or
data access framework. Support frameworks provide
system-level services, such as file access, distributed
computing support, or device drivers. Several authors
defined Frameworks based on the techniques used to
extend them: White-box, Black-box and gray-box
frameworks [4]. In a white box framework, the frame-
work user is supposed to customize the framework be-
haviour through sub-classing of framework classes. On
the other hand, a black box framework user does not
have access to framework code. Gray-box frameworks
lie between white and black box framework. Frameworks
are also classified by their scopes: System infrastructure
frameworks, Middleware integration frameworks and
Enterprise application framewor ks. System infrastructure
frameworks simplify the development of portable and
efficient system infrastructure. Communication frame-
works, proposed by Schmidt [6], also belong to System
infrastructure frameworks. Middleware integration
frameworks are commonly used to integrate distributed
applications and components. Common examples include
ORB frameworks, message-oriented middleware, and
transactional databases. Enterprise application frame-
works, proposed by Fayad et al. [7], address broad appli-
cation domains such as telecommunications, avionics,
manufacturing, and financial engineering.
However, no such study has been done till now to de-
velop different types of frameworks for a domain and
compare them to show in which situation which one is
more applicable for reuse. We had earlier done risk
analysis in framework development and its reuse [8].
This paper attempts to extend the above contributions
further by considering the comparative differences of
loose and tight frameworks.
3. Environment for Unit Testing
We briefly explain the domain “EUT” for which frame-
works are developed in the next sections. To develop a
framework, it is necessary to understand the domain for
which it is to be developed. Thus, first we briefly de-
scribe the unit test i ng pr ocess.
Unit testing is a dynamic method for verification,
where the smallest unit of software design- the software
component or module (unit code) is actually compiled
and executed. The unit testing focuses on the internal
processing logic and data structures within the boundary

An Exploratory Case Study in Designing and Implementing Tight Versus Loose Frameworks 211
Figure 1. Use case diagram for tight framework
of a component [9]. As the focus of this testing level is
on testing the code, structure testing is best suited for it.
Unit testing commences with generating test drivers and
stubs for the unit. Next, test cases are generated. A test
case is a set of test inputs, on which the unit code, to be
tested, is executed. The output of the program for each
test case is evaluated to verify compliance with the cor-
responding requirement using test oracles. During unit
testing several test deliverables (test case specification,
error report and test log etc.) are generated. At last, test
summary report is generated that specify the result of
testing p rocess.
To test the structure of a program, structure testing
aims to achieve test cases that will force the desired cov-
erage of different structures. Various criteria have been
proposed for this. Most common structure based criteria
are based on the control flow of the program for example
statement coverage, branch coverage, decision/condition
coverage and path coverage.
We developed both of these (tight and loose frame-
works) for the domain of ‘EUT’. Both of these frame-
works test a unit written in C language. In the tight
framework we fixed the test case generation activity
(based on condition coverage criteria). Because of that,
this framework can only be used if the unit testing crite-
ria is ‘condition coverage’. For rest of the unit testing
criteria, this reusable framework is useless. However, the
test case generation activity was not fixed in the loose
one and thus any test case generator (developed by con-
sidering any unit testing criteria) that can generate test
cases to test a C unit can be integrated with the loose
framework. Both the frameworks (tight and loose) have
been developed in C++ language.
4. The Proposed Tight Framework for ‘EUT’
We first describe the design and implementation of tight
framework for ‘EUT ’ .
The tight framework is developed by considering the
test cases generation based on the condition coverage
criterion. Thus, this framework supports the development
of a family of applications that would test a unit based on
the condition coverage criteria but differ in the way of
getting unit, driver, stubs. For example, a system devel-
oped by using this framework may accept these from a
human being while others may get these from software
systems (that will be generating these automatically).
As we know, any object oriented software and in par-
ticular any object oriented framework is a collaboration
of domain, control logic, utility and interface classes. In
this remaining section and in the next section, we iden-
tify these classes for both tight and loose framework for
‘EUT’ and show how they collaborate with each other.
4.1 Analyzing the Requirements of Tight
Framework for ‘EUT’
By studying the above problem statement, we specify
how a user will interact with this tight framework in the
use case diagram shown in Figure 1. Gray ovals show
the functionalities that are needed to be customized and
black ovals show functionalities that are prefixed in the
framework . Way to provide unit to be tested, dr ivers and
stubs (if any) to the framework (manually by the tester or
automatically using a software system) may be different
for different applications th at will be developed by using
this framework. Thus, in the use case shown on the left
hand side of Figure 1, actor may either be a human being
or a software system and that’s why has shown as gray
(as per the convention usually used to describe a frame-
work). As shown in the use case on the right h and side of
Figure 1, each condition, to be tested, is displayed to the
tester and then a tester provides test cases corresponding
to each condition. These test cases are run and test sum-
mary report is delivered to the tester after the completion
of the testing process.
From the problem specification, described above, we
can identify the following classes:
Unit – is an important class that would be tested using
this framework,
Driver – would invoke and provide environment for
he execution of the unit (if required), t

An Exploratory Case Study in Designing and Implementing Tight Versus Loose Frameworks 212
Unit
name
noofInputParameters
noofOutputPa ram eters
IsDriverRequired
PointertoDriver
Pointert oSub
display()
execute()
Testcase
testcaseId
noofInputParameters
inputParameters
inputParameterValues
noofOu tputPa ra meters
outputParameters
expectedOutputParameterValues
display()
TestSummaryReport
File
cre ate()
open()
append TestcaseId()
appendInputParameterValues()
append ExpectedParameterValues()
appendActualOutp utValues()
append TestcaseEvalu atio n()
Driver
name
noofInputParameters
noofOutp utParameters
Pointert oUnit
display()
execute()
Stub
name
noofInputParameters
noofOutp ut P aramete rs
Pointert ounit
display()
execute()
Condition
conditionId
conditionValue
isTes ted
display()
Figure 2. Domain classes for tight framework
Stub – would be called by the unit during its execution
(if required),
Test case – is a class that would represent a test case,
Condition – is a class that represents a condition to be
tested and
Test summary report – represents the test summary
report delivered to the tester after testing. These domain
classes along with their attributes and methods are shown
in Figure 2.
4.2 Designing the Tight Framework for ‘EUT’
To represent the abstract dynamic behavior of the system
developed as a tight framework, we first describe sce-
narios.
The success scenario is as follows:
1) Unit is provided (way would be specific to the ap-
plication) to the system.
2) If driver is needed, it is provided (way would be
specific to the application) to the system.
3) If stubs are needed, these are provided (way would
be specific to the application) to system.
4) Until all the conditions, in the unit, are tested
a) Next condition is identified.
b) System displays this condition to the tester and
asks the number of test cases (N) that need to be gener-
ated to test this condition.
c) For this number (N) of times
i) System asks the next test case.
ii) Tester inputs the test cases.
iii) System executes this test case and redirects
the output value of the ex ecution to a file.
iv) The actual output value is compared with the
expected output value and is shown to the tester.
v) System appends the testing result of this test
case (condition, corresponding test case, actual output
value, execution status of the test case (success-
ful/unsuccessful, executed or not) etc.) in the test sum-
mary report.
vi) System asks whether to proceed further or quit.
vi) If tester wants to quit (in case of getting
wrong result to corr ect the un it), the path an d n ame of the
Test Summary Report is displayed to the tester and sys-
tem stops.
d) System asks whether to proceed further or quit.
e) If tester wants to quit, the path and name of the
Test Summary Report is displayed to the tester and sys-
tem stops.
5) A message “all the conditions have been tested” and
the path and name of the Test summary report is dis-
played to the tester.
An exception scenario could be: if the format of any of
the information related to the program (unit, driver or
stub) is unacceptable by the system, for example if the
values of the input parameters, needed as a string con-
taining all these values separated by a space, is not pro-
vided in the required format. In all these types of situa-
tions, system would display different error messages ac-
cording to the situation.
Another abnormal scenario could be: if a test case
cannot be run successfully and thus the execution fails.
System will display an error message to show this situa-
tion.
The activity diagrams (Figure 3 (a) and Figure 3 (b))
show the sequence of activities performed during test
case generation and execution and comparison of actual
and expected output activities in the framework. All the
activities in this tight framework for ‘EUT’ are shown in
Figure 3 (c).

An Exploratory Case Study in Designing and Implementing Tight Versus Loose Frameworks213
(a) (b)
(c)
Figure 3. (a): Activity diagram for generating test case for tight framework, (b): Activity diagram for executing and
comparing output for tight framework, (c): Activity diagram for tight framework

An Exploratory Case Study in Designing and Implementing Tight Versus Loose Frameworks 214
DriverLoad er
Pointe rt oCurrentDriver
askDriverName()
setDriverName()
askNoofInputparameters()
setNoofInputParameters()
askNoofOutputParameters()
setNoofOutputParameters()
loadDriver()
getDriver()
TestSummaryReportGenerator
PointertoTestcase
PointertoComprator
gene rate Report ( )
TestcaseGenerator
PointertoTestSummaryReportGen
Pointert oExec ut or
Pointe rt oCurrentTestCase
PointertoComparator
NoofTestCasesPerCondition
Pointerto G UIf orGettingTestcase
generateTestcase()
Comprator
PointertoTestcase
actualOutpu t
compare()
UnitLoader
PointertoCurre nt Unit
askUnitName()
setUnitName()
askN oofInputP arameters()
setNoofInputParameters()
askN oof Outpu tParameters()
setNoofOutputParameters()
loadUnit()
getUnit()
ConditionFileGenerator
PointerTo Unit
scanNextCondition()
generateConditionFile()
Executor
pointert oProgram
pointert oCurrentTest c ase
executeProgram()
StubLoader
Pointe rt oCurre ntSt ub
askStubName()
setStub Name()
loadStub()
getStub()
Figure 4. Control logic classes for tight framework
TestcaseInputGetter
PointerT o Testc ase
getTestcaseInput()
setTestcase()
UnitGetter
isDriverRequired
isStubRequired
pointerto CurrentDriver
pointe rt oCurrent Stub
askIsDrive rRe quire d( )
askIsSt ubRequired()
askPointertoCurrentDriver()
askPointertoCurrentStub()
DriverGet t er
Pointe rt o Current Unit
askPointe rt o Current Unit()
StubGette r
pointerto CurrentUnit
askPointe rt o Current Unit()
Figure 5. Graphical user interface class for tight framework
Scenarios and activity diagram, described above, hint
for the following control logic classes:
UnitLoader – responsible for loading the unit to be
tested,
DriverLoader – responsible for loading a driver (if
any),
StubLoader – responsible for loading a stub (if any),
TestcaseGenerator – responsible for generating test
cases with the help of tester,
ConditionFileGenerator – responsible for identifying
all the conditions, in the unit, to be tested,
Executor – responsible for executing the unit (if there
is no driver) or driver,
Comparator – responsible for comparing the actual
output from the expected output parameter values for a
given test case and
TestSummaryReportGenerator – responsible for
generating test summary report.
These control logic classes along with their attributes
and methods are shown in the Figure 4.
Following are the interface classes that are designed
for this tight framework. These classes with their attrib-
utes and methods are shown in Figure 5.
UnitGetter – responsible for providing unit, to be
tested, to the rest of the system.
DriverGetter – responsible for providing driver, if any,
to the rest of the system.
StubGetter – responsible for providing stubs, if any, to
the rest of the system.
TestcaseInputGetter – responsible for displaying a
condition to the tester and getting inpu t parameter values
to test that conditio n.

An Exploratory Case Study in Designing and Implementing Tight Versus Loose Frameworks215
In this framework Unit, Driver and Stub classes share
several attributes and methods thus we take a class Pro-
gram from which all these three classes will inherit
properties and operations. Similarly, UnitLoader, Driver
Loader and StubLoader also share several properties and
operations and we have taken a class ProgramLoader
that have all the common properties and operations of
these classes and these classes are taken as sub class of
ProgramLoader class. Further, UnitLoader, DriverLoader,
StubLoader are kept as abstract classes because we don’t
fix in this framework how the unit, drivers or stubs are
generated. Thus, these classes are hot spots of the frame-
work. At the time of instantiation of this framework one
needs to refine these subclasses according to the applica-
tion using the framework. The object diagram, that sho-
ws the relationships among all the types of classes id enti-
fied during analysis and design, is shown in Figure 6.
4.3 Instantiation
We have instantiated this framework by adding three
classes UnitLoader_Sub of UnitLoader, Driver-
Loader_Sub of DriverLoader and StubLoader_Su b of
StubLoad er. These sub classes allow us to provide unit,
drivers and stubs (if required) manually using graphical
user interface. Thus in this instantiation, we assume the
application need is to provide these manually. In any
other instantiation, some other method of providing a
unit, drivers and stubs can be used for example as a result
of some automation process that will generate them etc.
Further one more class GUI is added that helps in im-
plementation of these other classes added during instan-
tiating. GUI class has a method that displays a string,
passed it as a parameter, to the user. Thus, at the time of
instantiation of this tight framework for ‘EUT’ only four
additional classes were needed to be added.
loads
generates
uses
executes
TestSummaryReport
Stub Driver
Program
ProgramLoader
TestSummaryReportGenerator
Unit
executes
uses
Condition
gene rate s
ConditionFile
ConditionFileGenerator
uses
invokes
TestcaseGenerator Comprator
Execu to r
Testcase testCaseInputGetter
StubGetter
StubLoade r
DriverGetter
Driver Loader
UnitGetter
UnitLoader
provides stub's
information provides driver's
information pr ovides unit's informati on
Figure 6. Object diagram of tight framework

An Exploratory Case Study in Designing and Implementing Tight Versus Loose Frameworks 216
Figure 7. Use case diagram for loose framework
Figure 8. Activity diagram for loose framework
5. Loose Framework for ‘EUT’
In the loose framework, for the same ‘EUT’ domain, we
do not restrict the method of drivers, stubs or test case
generation as we did in the above tight framework.
However, in this loose framework the test oracle is also
not fixed. That is, this framework would accept the driv-
ers, stubs (if required for a unit) and test cases from
somewhere else as the tight one did. These would be
given to the framework either manually or generated
automatically. This framework will accept and load these
into the respective classes defined in the framework. This
loose framework for ‘EUT’ does not fix the way of gen-
erating test cases, which is a big part of the framework.
Thus, using this loose framework one can perform any
type of structural testin g. That is, the test case gen eration
would also be application specific.

An Exploratory Case Study in Designing and Implementing Tight Versus Loose Frameworks217
5.1 Analyzing the Loose Framework
Requirements
By studying the problem statement, we specify the func-
tionalities that the framework will support in the use case
diagram in Figure 7. Gray ovals show functionalities that
are needed to be customized and black ovals show func-
tionalities that are prefixed in the framework. Unit, to be
tested, drivers and stubs (if any) and test cases can be
provided to the system either manually or can be loaded
automatically using any software.
After analysis, here also, we get the same domain
classes as we obtained in tight framework described
above: Unit, Driver, Stub, Test case, and test summary
report. Only the domain class ‘condition’ that was iden-
tified during development of the tight framework, de-
scribed above, is not a domain class for this framework.
Rests of the classes are all same.
5.2 Designing the Loose Framework
To represent the dynamic behavior of a system that
would be developed using this loose framework, we de-
scribe the following scenarios that explain how the sys-
tem behaves when it performs some of its functions. The
success scenario is as follows:
1) Unit is provided to the system.
2) If driver is needed, driver is provided to the system.
3) If stubs are needed, these are provided to the sys-
tem.
4) Test data is given to the system.
5) Test oracle provides the correct output for a given
test data.
6) System executes the test case and compares the ac-
tual output with the expected output parameter values.
7) System generates a test summary report.
Abnormal scenarios are as follows:
1) Unit is given to the system.
2) If driver is needed, driver is given to the system.
3) Test data is given to the system.
4) Test oracle provides the correct output for the test
case.
5) System could not execute the test case and gener-
ates an error message “execution failed”.
Similarly other abnormal scenarios would be if the
unit and driver cannot be provided in the form used by
the system. At that time system again generates error
messages corresponding to the error occurred.
As we mentioned above, in this loose framework, we
do not restrict the method of generating drivers, stubs or
test case generation. Similarly the test oracle is also not
fixed. That is, drivers and stubs (if required for a unit to
be tested) and test cases can be provided manually or
generated automatically and are supplied to this frame-
work. This loose framework will accept and load these
drivers, stubs and test cases into their respective classes
defined in the framework. As the actual output would
need to be compared with the expected output, these
output variables would need to be stored in a file and
then compared with the expected output. To redirect
execution output of the unit it is required to add code in
the unit for the purpose. Activity diagram (Figure 8)
shows all the activities in this ‘EUT’ framework in brief.
Activity diagram hin ts some application logic classes:
UnitLoader, DriverLoader, StubLoader, TestcaseLoader,
Executor, Comparator, TestSummaryReportGenerator.
These classes are shown in Figure 9.
DriverLoad er
PointertoCurrentDriver
askDriverName ()
setDriverName()
askNoofInputparamete rs()
set NoofInputParameters()
askNoofOutpu tParameters()
setNoofOutputParameters()
loadDriver()
get Driver()
TestS ummar yReportGenerator
PointertoTestcase
PointertoComprator
g en erateReport()
TestcaseLoader
Pointert oUnit
PointertoCurrentT e st c ase
askTestcaseId()
setT estcaseId()
set NoofInputParameters()
askInput Paramet erValue s()
set InputParamet erValue s()
setNoofOutputParameters()
askExpect edOut put P arameterValue s()
setExpect e dOutputParame t e rValues()
loadTestcase()
getTest case()
Co mprator
PointertoTestcase
actualOutp ut
compare()
StubLoader
PointertoCurrentUnit
askS tu btName()
setStubName()
askNoofInputParame ters()
setNoo fInputP aramete rs()
askNoofOutputParameters()
setNoofOutputParameters()
loadStub()
get St ub()
UnitLoader
PointertoCurrentUnit
askUnitName()
setUnitName( )
askNoofInputParame ters()
setNoo fInputP aramete rs()
askNoofOutputParameters()
setNoofOutputParameters()
loadUnit()
getUnit()
Exe cutor
Pointe rtoPro gram
PointertoCurrentTe stCase
executeProgram()
Figure 9. Control logic classes for loose framework

An Exploratory Case Study in Designing and Implementing Tight Versus Loose Frameworks 218
loads
gene rates
uses
executes
uses
TestSummaryReport
Stub Driver
Program
ProgramLoader
TestSummaryReportGenerator
TestcaseLoader
Co mprator
Executor
Testcase
Unit
TestOracle
executes
uses
uses
StubGetter
St ubLoader
provides stub
information
DriverGetter
DriverLoader
provides driver
information
UnitProvider
UnitLoader
provides unit
information
Figure 10. Object diagram of a loose framework
The user interface classes for this loose framework are
same as they were in the above tight framework. Only
the TestCaseInputGetter class is not included in this
framework.
In this framework also, we take Program as an ab-
stract class from which Unit, Driver and Stub classes
would inherit properties and operations for the same rea-
son as described in tight framework. Similarly, Pro-
gramLoader is taken as an abstract class of which Unit-
Loader, DriverLoader and StubLoader are be imple-
mented as sub classes for the same reason. Further,
UnitLoader, DriverLoader, StubLoader and Test-
caseLoader are also kept as abstract classes because we
don’t fix in this framework how the unit, drivers, stubs or
test cases are generated. Thus, these classes are hot spots
of the framework. At the time of instantiation of this
framework one needs to refine these in subclass accord-
ing to the application using the framework. After identi-
fying the attributes and methods of these applica-
tion-logic classes along with relationship among these
and problem domain classes we get the object diagram
(Figure 10).
5.3 Instantiation
We have instantiated this framework by adding five
classes UnitLoader_Sub a sub class of UnitLoader,
DriverLoader_S ub a sub class of DriverLoader and
StubLoad er_Sub a sub class of StubLoader Test-
CaseLoader_Sub a sub class of the class TestCaseLoader
and a class GUI. Except the TestCaseLoader_Sub rest of
the classes have the same role and responsibilities that
they have in the earlier described tight framework for
‘EUT’. Since activities concerning with these classes
were not fixed in the above tight framework also. Using
this loose framework since the generation of test cases is
not fixed in the framework there is a need to customize
this activity also and thus the TestCaseLoader_Sub sub
class is also added in the instantiation of this loose
framework.
6. Observations
The objectives of the above case study are to obtain
quantitative characteristics of frameworks for the pur-
pose of comparing and understanding which framework
(tight or loose) can better be reused in which scenario.
The one main problem that we have encountered during
this work is the lack of some good experimental data
from real time environment that may help us to verify the
proposed idea in an efficient manner.

An Exploratory Case Study in Designing and Implementing Tight Versus Loose Frameworks219
Table 1. Comparison of tight and loose frameworks at code level
S.N. Code Characteristics of frameworks Tight framework Loose framework
1. Total number o f methods 74 68
2. Number of virtual functions 4 8
3. Total Number of classes 18 13
4. Number of abstract classes 4 5
5. Size (Total number of non-commented lines
of code ) 624 485
A comparative table 1 shows different characteristics
for loose and tight frameworks are drawn below.
By comparing frameworks at code level, we can an-
swer the questions discussed above at some extent.
1) If a software framework has more number of ab-
stract classes and virtual functions, the possibility of its
reuse will be higher. As we know, the abstract classes
and virtual functions give freedom (flexibility) to de-
signers to instantiate a framework according to the re-
quirements of a specific application. So such a frame-
work can be reused in more number of applications. It
can be shown from the table that loose framework for
‘EUT’ have 8 virtual functions and 5 abstract classes
while tight framework has 4 virtual functions and 4 ab-
stract classes. It shows the loose framework would be
more reusable in terms of “number of reuses” because it
can be used in more number of application developments
than the tight one.
In a software framework, the abstract classes and vir-
tual functions have to be customized at the time of in-
stantiation of that framework. A designer/implementer
would have to extend abstract classes and virtual func-
tions according to the requirements of any specific ap-
plication. If a software framework has more number of
abstract classes and virtual functions then more effort
would be needed to customize them at the time of instan-
tiation. However, as autonomous, in terms of its service
providing responsibilities, a framework would be that
better contribution it can make in functioning of the sys-
tem. It is shown in the table that loose framework for
‘EUT’ have 8 virtual functions and 5 abstract classes
while tight framework has 4 virtual functions and 4
abstract classes. As identified in the definition of tight
framework that it fixes the way of performing most of
such activities in the framework itself, it is our conj ecture
that tight framework would be more reusable in terms of
“ease of reuse”. As shown in Figure 9 ‘TestcaseLoader’
is an abstract class in the loose framework that is to be
implemented according to the application specific re-
quirements and hence requires extra effort. Whereas the
tight framework has a concrete ‘TestcaseGenerator’ class
that has all the implementation and hence it can be di-
rectly used in the application.
2) As given in the definition of loose framework that it
is a framework that does not fix the way of performing
most of the activities in the framework itself. During
design of loose framework one need not to write
semi-code for the portion that is not concretely defined in
the framework. As shown in section 4, we did not fix
the unit testing criteria in loose framework so we need
not to develop code for generating test cases (based on
any criteria) in this framework; only the interface that
would connect the test case generator is needed to be
developed. However, in the case of tight framework, one
has to collect all the requirements for a specific applica-
tion. Since, in tight framework, we fix the way of per-
forming most of the activities so we have to write
semi-code for all the activities. As shown in section 5,
for the tight framework, where we fixed the testing crite-
ria as condition testing, we required to develop whole
code for generating test cases, satisfying this condition
coverage criterion, as part of the framework itself. Based
on our design and development experience regarding
both type of frameworks, it is our conjecture that a loose
framework would always be easier to develop than a
tight one.
3) Unlike a loose framework, in a tight framework we
fix most of the activities, so we have to write semi-code
for them. It can be shown from the table that size of tight
framework (total number of non-commented line of code)
is 624 while size of loose framework is 485. And thus,
the tight framework will be heavier, in terms of size, as
compare to loose framework.
In case of tight framework, the interdependence
among the different component of the framework would
be more because the way of performing most of the ac-
tivities are fixed. In order to understand/modify one
component, one has to understand all the related compo-
nents that make the tight framework more complex. In
case of loose framework, different components are
loosely coupled to each other. It is easy to understand/
modify one component, without understanding/modi-
fying other components, in a loose framework because
for each activity there would be perhaps different loose
frameworks that fulfill the application need by interact-

An Exploratory Case Study in Designing and Implementing Tight Versus Loose Frameworks 220
ing with each other. As in our case, loose framework for
‘EUT’ interact with any of the test case generator
framework and perform the unit testing. Thus whenever
we need to modify in test case generator framework there
is no need to understand the ‘EUT’ framework and
vice-versa. Thus we can say a loose framework would
always be less complex than a tight framework for the
same domain. In short, we can say that the complexity of
the tight framework would be high because several ac-
tivities considered in that framework may result in tightly
coupled implementation of them. However, the loose
framework that contains only the abstract code would be
less complex since no detailed implementatio n is there in
its code.
One can consider the basic guiding principles for de-
signing a software framework based on the above obser-
vations.
7. Conclusions
For some situations a tight framework would be better
than a loose framework for same domain if the ways of
performing the activities, fixed in the tight framework,
are exactly those that are required in the needed applica-
tion. In this paper, we suggested some scenarios, which
type of framework would be more appropriate as com-
pared to other one. These observations will be useful at
the time of selection of frameworks. We have focused on
limited parameters. Results would be more visible for
industrial applications. One can extend this study by
considering other quality criteria.
REFERENCES
[1] D. Roberts and R. Johnson, “Evolving frameworks: A
pattern language for developing object-oriented frame-
works,” in Pattern Languages of Program Design 3. Ad-
dison-Wesley, Illinois, USA, 1997.
[2] J. Bosch, P. Molin, M. Mattsson, and P. Bengtsson, Ob-
ject-Oriented Frameworks – Problems & Experiences,
1997.
[3] S. Sparks, K. Benner, C. Faris, and S. Consulting, “Man-
aging object-oriented framework reuse,” IEEE 1996, pp.
52–61, 1996.
[4] Y. J. Yang, S. Y. Kim, G. J. Choi, E. S. Cho, C. J. Kim,
and S. D. Kim, “A UML-based object-oriented frame-
work development methodology,” Software Engineering
Conference, Proceedings. 1998 Asia Pacific, pp. 211–218,
1998.
[5] IBM, “Building Object-Oriented Frameworks”, http:
//www.ibm.com/java/education/oobuilding/index.html.
[6] D. C. Schmidt, “Applying design patterns and frame-
works to develop object-oriented communication soft-
ware,” Handbook of Programming Languages, Volume I,
edited by Peter Salus, MacMillan Computer Publishing,
1997.
[7] M. E. Fayad and D. S. Hamu “Object-oriented enterprise
frameworks: Make vs. buy decisions and guidelines for
selection,” The Communications of ACM, 1997.
[8] A. K. Tripathi and M. Gupta, “Risk analysis in re-
use-oriented software development,” International Journal
of Information Technology and Management, Vol. 5, No.
1, pp. 52–65, 2006.
[9] P. Jalote, “An integrated approach to software engineer-
ing,” ISBN 81-7319-702-4, Narosa. 2005.