SEKE 2012 Proceedings - Knowledge Systems Institute

Table I shows the relationships between hello.c and
anymessage.c in terms of attribut es such as size,
complexity, etc. We ran the wc program in the Unix
environment [http://www.computerhope.com/unix/uwc.htm]
on hello.c and anymessage.c. As predicted, the reusable
program is large r and has more parameters. We also
hypothesize that anymessage.c will be more complex,
require more testing, require more design know ledge, have
higher execution speed, and require more time to develop. Thus
Table I summarizes our theoretical model of the relationship
between a one-use and a reusable component. In the remainder
of this paper, w e will empirically evaluate certain aspects of
this model.
TABLE I: hello.c (one-use component) VS. anymessage.c
(reusable component)
Attribute hello.c anymessage.c
Size (lines, chars,
executable)
(1, 8, 9878) (10, 25, 9931)
Parameters 0 2
Domain Knowledge Low Medium
Testing < >
Design < >
Execution Speed < >
Effort < >
B. Motivation
For practitioners and researchers, there are two motivations
in our stu dy. One is that even though the relation between
software quality and reuse has been established, no empirical
study has been foun d comparing one-use and equivalent
reusable components. The other motivation is that practitioners
and researchers need to address the problem of how to build
reusable components. This exploratory study used a
comprehensive list of reuse design principles presented in the
past two decades for software reuse and identified the most
used reuse design principles. This can be a guideline for
building reusable components. One major limitation of our
study is that the components studied are small in size.
However, this is an exploratory study and with 107 subjects,
nearly all of whom have some experience in software
engineering. The sample size is adequate for comparing oneuse
and reusable components. Also, this exploratory study is a
baseline for future study on designing, building, and measuring
reusable components.
One study that is similar to ours is presented by Seepold
and Kunzmann [14] for components written in VHDL .
However, the major limitation in that study was that it involved
only four com ponents - two one-use and two equivalent
reusable components. According to that study the complexity,
effort and productivity were all higher for reusable
components. The reasons identified were due to overhead in
domain analysis, component verification and documentation.
This paper is organized as follows: section II provides an
overview of the reuse design process and principles; section III
presents the hypotheses analyzed in this study; section IV
discusses the method employed, metrics used for evaluation,
and the s-stemmer component used in our study; section V
presents the results and discussion; and section VI presents the
conclusions and future work.
II. REUSE DESIGN PRINCIPLES
How to make a software component reusable has been one
of the key questions for software reuse research. Reusable
components may be built from scratch or re-engineered from
existing artifacts. As can be seen from Fig. 1., the quality of the
reusable components may be measured in terms of safety
(when implemented and/or merged with another component),
execution speed (generally the reusable components are slower
than the one-use components), cost, and size. Size may be
measured by source lines of code (SLOC). We assume that the
higher the SLOC, the higher will be the complexity resulting in
higher numbers of faults and parameters.
Many reuse design principles have been proposed. These
are summarized in the mindmap in Fig. 1 based on the work by
[1]. The principles are at var ious levels of abstraction. The 3
C's model of reuse design [15], for example, was developed to
explore the reuse design process in a general framework. It
specifies three levels of design abstraction: 1. Concept –
representation of the abstract semantics. 2. Content –
implementation details of the code or software. 3. Context –
environment required to use the component.
III. HYPOTHESES
This paper aims primarily to study and test four
hypotheses related to the reusable components. Due to the
higher complexity and functionality of the reusable
components, their size (in SLOC - source lines of code), effort
(in hours), the productivity (in source lines of code per hour)
and number of parameters should be significantly higher than
their equivalent one-use components. The choice of the
metrics is discussed in section 4.3. These hypotheses are
summarized in equations (1), (2), (3), and (4). SLOC Reuse is the
actual source lines of code in the reusable component while
SLOC ReuseDiff is the difference in the source lines of code
between the reusable and one-use components. The difference
is considered for the productivity of reusable components
because the reusable components studied in this paper were
not built from scratch; instead , they were reengineered by
modifying the one-use components based on the reuse design
principles given in Fig. 1.
SLOC Reuse > SLOC one-use (1)
Effort Reuse > Effort one-use (2)
SLOC ReuseDiff/hour > SLOC one-use/hour (3)
Parameters Reuse > Parameters one-use (4)
195