J. Software Engineering & Applications, 2010, 3, 536-540
doi:10.4236/jsea.2010.36061 Published Online June 2010 (http://www.SciRP.org/journal/jsea)
Testability Models for Object-Oriented
Frameworks
Divya Ranjan1, Anil Kumar Tripathi2
1Department of Computer Science, Faculty of Science, Banaras Hindu University, Varanasi, India; 2Department of Computer Engi-
neering, Institute of Technology, Banaras Hindu University, Varanasi, India.
Received April 10th, 2010; revised April 21st, 2010; accepted April 23rd, 2010.
ABSTRACT
Frameworks are time-tested highly reusable architectural skeleton structures. They are designed ‘abstract’ and ‘inco-
mplete’ and are designed with predefined points of variability, known as hot spots, to be customized later at the time of
framework reuse. Frameworks are reusable entities thus demand stricter and rigorous testing in comparison to one- time
use application. The overall cost of framework development may be reduced by designing frameworks with high
testability. This paper aims at discussing a few metric models for testability analysis of object-oriented frameworks in an
attempt to having quantitative data on testability to be used to plan and monitor framework testing activities so that the
framework testing effort and hence the overall framework development effort may be brought down.
Keywords: Object-Oriented Frameworks, Complexity, Framelet-Based Design and Testability
1. Introduction
Frameworks represent semi-codes for defining and im-
plementing time-tested highly reusable architectural ske-
leton design experiences and hence become very useful in
development of software applications and systems. The
object-oriented paradigm provides a promising set of so-
lutions to attain reusability with the help of objects, class-
es, templates, inheritance, overloading and genericity [1,2]
so object-oriented frameworks are much more com- mon
than non object-oriented frameworks and have become a
synonym for software frameworks. It should be noted that
a framework without object-orientation is also possible.
As per Gamma et al. [3], famous in reuse literature as
gang of four, an object-oriented framework is a set of
cooperating classes that make up a reusable design for a
specific class of software which provides architectural
guidance by partitioning the design into abstract classes
and defining their responsibilities and collaborations. The
five elements of an object-oriented framework, as identi-
fied by Gurp and Bosch [4], are design documents, inter-
faces, abstract classes, components and classes. An ab-
stract class usually has at least one unimplemented ope-
ration deferred to for its implementation during frame-
work reuse.
Applications are built from frameworks by extending or
customizing the framework, while retaining the original
design. The framework-centered development lifecycle
broadly consists of following three phases [5]: 1) the
framework development phase aims at producing re-
usable design in a domain, consisting of domain analysis,
architectural design, framework design, framework im-
plementation, framework testing activities; 2) the frame-
work usage phase is also referred to as the framework
instantiation phase or application development phase.
Once framework is developed, it is deployed for the de-
velopment of framework-based applications that include
the core framework designs or part of it and new classes
need to be developed to fulfill the actual applications
requirements and 3) the framework evolution and main-
tenance phase.
One has to be very careful about developing fault free
reusable frameworks because if the framework contains
defects, the defects will be passed on to the applications
developed from the framework during framework usage
phase [6]. The reusable framework thus demands stricter
and rigorous testing in comparison to a one-time use ap-
plication [7,8]. It would be advisable to guaranty the pro-
duction of high quality frameworks without incurring
heavy costs for rigorous testing. This calls for analyzing
testability of reusable artifacts so as to reduce the overall
cost of framework-based development [9].
Bache and Mullerburg [10] define testability as the
minimum number of test cases required to provide total

Testability Models for Object-Oriented Frameworks
537
test coverage, assuming that such coverage is possible.
Several definitions of software testability are available in
literature but intuitively, a software component that is test-
able has the following desirable properties [11]:
 test sets are small and easily generated,
 test sets are non-redundant,
 test outputs are easily interpreted and
 software faults are easily locatable.
In spite of wide importance and promotion of frame-
works, over the last decades, a widely accepted set of
measures to quantify its characteristics has not been es-
tablished. Moreover, there is a complete lack of frame-
work testability metrics related studies in literature that
could produce quantitative data on testability to be used to
plan and monitor framework testing activities so that the
framework testing effort and hence the overall framework
development effort may be brought down. A recent work
[9] proposed models for testability analysis of framework
that particularly consider that the frameworks are inher-
ently abstract and variable in nature. This paper proposes
few more models for testability analysis of object-oriented
frameworks, considering few design related aspects of
frameworks.
Some obvious reasons for rigorous testability analysis
of a framework could be summarized as [9]:
1) A testable framework ensures low testing cost and
helps in reduction of overall development cost of a
framework which has been designed and implemented as
a semi-code.
2) Frameworks are reusable entities and hence high
testability is essential. As testable system is known to pro-
vide increased reliability.
3) High testability brings high reusability. Many a
times a framework reuser will want to test few features to
assess its quality. If testing a framework is tough then
framework reuser will hesitate in testing and using the
framework and will seek to choose another framework or
go for development without deploying a framework.
4) To calm obvious scientific curiosity that while writ-
ing test cases for frameworks why it is tougher in some
case than the other cases or, so to say, why for one
framework we had to think very hard before we were able
to write a meaningful test suite, whereas for other frame-
works we could generate test cases in a straightforward
way.
5) Testability holds a prominent place as part of the
maintainability characteristic in ISO 9126 quality model
ISO, 1991, so this study also increases our understanding
of software quality in general.
6) Framework testability analysis creates a base for
formulating the strategy for designing highly testable
frameworks, i.e., framework design for test (FDFT).
The paper is organized in three sections. Proposed
testability models for software frameworks appear in Sec-
tion 2 and Section 3 presents conclusions.
2. Models for Testability Analysis of
Object-Oriented Frameworks
This section aims at discussing various metric models for
testability analysis of object-oriented frameworks con-
sidering few design related aspects of frameworks. Fol-
lowing discussion takes into account the factors that affect
the testability of an object-oriented framework, as identi-
fied by Ranjan and Tripathi in [12]. They identified va-
rious factors and sub factors that affect the testability of
frameworks so as to take care of those factors to bring
high testability in frameworks. As per their observations,
the factors that affect the testability of a framework are
related to the characteristics of documentation of a frame-
work, domain of a framework, design of a framework and
the test support available for the framework testing like
test tools, environments, reusable test artifacts and built-in
tests etc.
2.1 A Testability Model Considering the
Structural Complexity of a Framework
It is empirically proved that complexity metrics are good
predictors of testing effort [13]. An interesting model of
OO system complexity, proposed by Tegarden and Sheetz
[14], consists of the system complexity, structural com-
plexity, and perceptual complexity constructs. System
complexity represents aspects of OO techniques and cha-
racteristics inherent to the problem. This construct influ-
ences the structural aspects of the system and the per-
ceptual complexity of the OO system. Structural com-
plexity deals with the measurable characteristics of the
resulting OO system such as the number of classes and the
interconnections between the classes whereas perceptual
complexity deals with the ability of the developer to un-
derstand the problem, the structural components of the
OO system, the use of OO techniques, and how to inte-
grate these ideas to create an OO system.
As per this model, structural complexity identifies four
levels of describing complexity of OO systems: variable,
method, object, and system. At each level, measures are
identified that account for the cohesion (Intra) and cou-
pling (Inter) aspects of the system. Thus, the structural
complexity of object-oriented framework may be ex-
pressed as:


 N
i
Inter
N
i
IntraFr ii COCOSC
11
(1)
where,
IntraIntraIntra CMCVCO 

(2)
and
InterInterInter CMCVCO 

(3)

Testability Models for Object-Oriented Frameworks
538
where,
N = Total number of objects in the framework
SCFr = Structural Complexity of the framework
COIntra = Intra Object Complexity in the framework
COInter = Inter Object Complexity in the framework
CVIntra = Intra Variable Complexity in an object
CVInter = Inter Variable Complexity in an object
CMIntra = Intra Method Complexity in an object
CMInter = Inter Method Complexity in an object
It is very clear that framework testability is inversely
proportional to its structural complexity. Therefore, using
Equation (1) we can write,



N
i
N
i
InteriIntrai
Fr
COCO
Tb
11
1 (4)
It for sure that and , in the above
model, will never be zero together. Because total number
of objects in the framework will always be >= 1. In case
when N = 1, the value of may become zero but
the value of will not be zero then also.


N
i
Intra iCO
1


N
i1
Intra i

N
i
InteriCO
1
InteriCO


N
i
CO
1
2.2 A Testability Model Considering Complexity
of Framework Interfaces
A framework may have its interfaces linked to external
entities like other frameworks, components, or library
functions etc. [15], known as external interfaces. More the
number of other entities to be integrated with the frame-
work, the more effort are required for their integration
testing. This effort increases with the number and com-
plexities of the constituent interfaces.
A framework testability model, considering complexity
of framework interfaces, may be expressed as











LInf
i
i LInf
CInf
i
CInf
FItf
i
FItf
Fr N
C
N
C
N
C1
Tb
ii
111
1 (5)
where,
F
Itfi
C = Complexity of framework’s ith interface with
other framework
CInfi
C = Complexity of framework’s ith interface with
component
L
Infi
C = Complexity of framework’s ith library interface
FItf
N = Total number of interfaces with other frameworks
CInf
N = Total number of interfaces with component
2.3 Aeaviness of
ing, i.e. consisting
of how much time and
ef
LInf
N = Total number of library interfaces
Testability Model Considering H
Framework in Terms of its Size
Size happens to be an obvious influencing factor for test-
effort [16]. A framework of huge size
of large number of classes, methods, attributes and depth
of inheritance etc., is considered heavy. We here make use
of (a subset of) object-oriented metrics proposed by
Chidamber and Kemerer [17].
The number and complexities of the methods involved
in the framework is a predictor
fort is required to test. We define WMFr (the consoli-
dated weighted method per framework in line with WMC
proposed in [17]) as follows:


CN
i
WWMFr
1
i
MC (6)
where


MiN
j
iji cWMC
1
(7)
and
= Sum of weighted methods of all classes in FUT
WMFr
i
WMC = Weighted method per class of th class in FUT
Total number of classes in FUT
i
=
=
Nc
ij
C Complexity of jth method in ith class of FUT
M
i
N
= Total number of methods in ith class
heaviness oFf
fram follows:
ramework testability model considering
ework in terms of its size may be defined as
11
1
Mi
Fr Nc N Tb 
() ij
ij
c



because,
(8)
WMFrTEFr

(9)
M appearing in Equation 8
panded as below in Equations 10 and
Nc and N may further be ex-
11
FrFrC NOACNOCCN 

(10)
where,
Nc = Total number of classes in FUT
= Number of concrete classes in the FUT
in the FUT
e con-
meth-
od
NOCCFr
NOACFr = Number of abstract classes
And, methods in a class shall comprise of all th
crete methods, abstract methods, and overridden
s. Thus,
OMAMCMM NNNN 

(11)
where
N = Total number of methods in FUT
otal number of concrete methods in FUT
in FUT
M
NCM = T
NAM = Total number of abstract methods
NOM = Total number of overridden methods in FUT

Testability Models for Object-Oriented Frameworks
539
2.4 A Testability Model Considering
Framelet-Based Design of Frameworks
Fra endent melets are the small, flexible, relatively indep
and reusable assets, which are designed based on the
concept of frameworks. They are mini-frameworks that
usually contain less than ten classes and have a simple,
clearly defined interface [18]. They evolved as a means
of modularizing the frameworks where a family of inter-
related framelets is an alternative to complex frameworks.
It is basically a design principle that instead of designing
one full fledged and complex framework, design it with a
family of related framelets with lean interfaces [19]. De-
signing a framework in framelet-based fashion promotes
reducing overall complexity of the framework and is like
using divide and conquers approach to facilitate both, the
design and testing of the framework.
Understanding a framelet-based framework is easier
than a full fledged and complex framework because a
framelet-based framework is made up of loosely coupled
small frameworks, known as framelets. Testability of a
framelet-based framework depends upon the testability
of constituent framelets and the coupling among them.
So, we may write,








Fr
N
Tb
Fmlt
i
Fmlt
Fmlt
Tb
COUP i
i
1
1 (12)
where
ility of the framework
amelets
ith framelet
t a small framework,
hat the quality of the software system
TbFr = Testab
NFmlt= Total number of constituent fr
COUPFmlti = Sum of measure of coupling of
her with otframelets
TbFmlti = Testability of ith framelet
inSce, a framelet is nothing bu
consisting of not more than ten classes and very lean
interfaces with other framelets [19], so any discussion or
metric model regarding framework’s testability will be
applicable for estimating testability of a framelet.
Each of the testability metric models, discussed above,
has different intention or applicability which is discussed
in the following Table 1, however, more than one model
may also be employed at the same time.
3. Conclusions
It is quite obvious t
which has been developed with reuse depends heavily
upon the quality of the underlying reusable artifacts.
Frameworks are an important reusable artifact and are
believed to be at the core of leading-edge software tech-
nology in the twenty first century [20]. Software frame-
works and design patterns make reuse of design experi-
ences possible but unlike design patterns (that may not
have any code) software frameworks are semi-codes and
hence call for thorough testing before they can be de-
ployed as reusable entities. Although the technology for
Table 1. Applicability of framework testability metric models
Framework
S.No.Category Testability Applicability of
the Model
Metric Model
1.
m
s
ering the Struc-
structural com-
Testability
odels con-
idering vari-
ous kinds of
complexities of
frameworks
Testability
Model Consid-
tural Complexity
of a framework
When framework
plexity is of con-
cern for testabil-
ity.
2. -- do--
Model Consid-
erity
integration with
3.
Testability
models con-
b
Model Consid-
ering Heaviness
Wheork
size is of concern
4. -- do-- er-
W
has framelet-
Testability
ng Complexi
of Framework
Interfaces
Testability
When framework
other frame-
works, compo-
nents and library
functions is of
concern for test-
ability.
n framew
sidering size
and framelet-
ased design of
the framework
of Framework in
terms of its Size
Testability
Model Consid-
for testability.
hen framework
ing Framelet
based design of
frameworks
based design and
the testability of
framelets are of
concern.
constructing frameworks ork-baware
relatively advanced, we comparatively lack a sufficient
[1] J. W. HoopeSoftware Reuse:
Guidelines andishing, Cambridge,
s, Prospects,” Journal of Computing and Infor-
ented
ed Frameworks: Concepts and
Problems and Experiences,”
and framewsed soft
is
theoretical basis for testing them. This paper attempted to
discuss a few metric models for testability analysis of
object-oriented frameworks in an attempt to having quan-
titative data on testability to be used to plan and monitor
framework testing activities so that the framework testing
effort and hence the overall framework development ef-
fort may be brought down. The framework testability
models presented here takes into account few design re-
lated aspects of object-oriented frameworks.
REFERENCES
r and R. O. Chester, “
Methods,” Perseus Publ
1991.
[2] M. Smolarova and P. Navrat, “Software Reuse: Principles,
Pattern
mation Technology, Vol. 5, No. 1, 1997, pp. 33-49.
[3] E. Gamma, R. Helm, R. Johnson and J. M. Vlissides,
“Design Patterns: Elements of Reusable Object-Ori
Software,” Addison-Wesley Professional Computing Se-
ries, Massachusetts, 1994.
[4] J. Gurp and J. Bosch, “Design, Implementation and
Evolution of Object-Orient
Guidelines,” Software - Practice and Experience, Vol. 31,
No. 3, 2001, pp. 277-300.
[5] J. Bosch, P. Molin, M. Mattsson and P. Bengtsson, “Ob-
ject-Oriented Framework-

Testability Models for Object-Oriented Frameworks
540
orks Using Hook Technology,” Procee-
se Program,” IEEE Computer Society Inter-
IEEE Software, Vol. 15, No. 5, 1998, pp.
ability Analysis of Frameworks,” Journal of Soft-
lity Assurance,” Software Engineering Jour-
eering, Vol. 17, No.
eworks,” The Journal of Defense
n and S. D. Sheetz, “Object-Oriented System
Approach to Software Engi-
or
Software
oskimies, “Framelets—Small and
. C. Schmidt, “Object-Oriented
Research Report, University of Karlskrona/Ronneby,
Sweden, 1997.
[6] J. Al-Dallal and P. Sorenson, “System Testing for Object-
Oriented Framew
dings of the 17th IEEE International Conference on Auto-
mated Software Engineering, Edinburgh, September 2002,
pp. 231-236.
[7] J. S. Poulin and J. M. Caruso, “Determining the Value of a
Corporate Reu
Comp
national Software Metrics Symposium, Baltimore, May
1993, pp. 16-27.
[8] E. J. Weyuker, “Testing Component-Based Software: A
Cautionary Tale,”
54-59.
[9] D. Ranjan and A. K. Tripathi, “Variability-Based Models
for Test neer
ware Engineering and Applications, Vol. 3, No. 6, 2010,
pp. 455-459.
[10] R. Bache and M. Mullerburg, “Measures of Testability as a
Basis for Qua
nal, Vol. 5, No. 2, 1990, pp. 86-92.
[11] R. S. Freedman, “Testability of Software Components,”
IEEE Transactions on Software Engin
6, 1991, pp. 553-564.
[12] D. Ranjan and A. K. Tripathi, “Testability Analysis of
Object-Oriented Fram
Loos
Software Engineering, accepted for publication.
[13] H. M. Olague, L. H. Etzkorn, S. L. Messimer and H. S.
Delugach, “An Empirical Validation of Object-Oriented
Class Complexity Metrics and their Ability to Predict
Error-Prone Classes in Highly Iterative, or Agile Software:
A Case Study,” Journal of Software Maintenance and
Evolution: Research and Practice, Vol. 20, No. 3, 2008,
pp.171-197.
[14] D. P. Tegarde
lexity: An Integrated Model of Structure and Per-
ceptions,” Presented at OOPSLA 1992. http://www.acis.
pamplin.vt.edu/faculty/tegarden/wrk-pap/OOPSLA92.pdf
[15] M. Mattsson and J. Bosch, “Framework Composition:
Problems, Causes and Solutions,” Proceedings of Techno-
logy of Object-Oriented Languages and Systems, Nether-
lands, 1997, pp. 203-214.
[16] P. Jalote, “An Integrated
ing,” Narosa Publishing House, Darya Ganj, 2009.
[17] S. R. Chidamber and C. F. Kemerer, “A Metrics Suite f
Object-Oriented Design,” IEEE Transactions on Software
Engineering, Vol. 20, No. 6, 1994, pp. 476-493.
[18] W. Pree, “Design Patterns for Object-Oriented
Development,” Addison-Wesley Publishing Company,
Massachusetts, 1995.
[19] W. Pree and K. K
ely Coupled Frameworks,” ACM Computing Surveys,
Vol. 32, No. 6, 2000.
[20] M. E. Fayad and D
Application Frameworks,” Communications of the ACM,
Vol. 40, No. 10, 1997, pp. 32-38.