![](bg2.png)
components' reusability, and compare our own re-
sults in this area, to some of the most popular com-
ponent models and approaches to component reuse
that they provide.
2 SOFTWARE COMPONENT
MODELS
One of the pervasive needs of software development
is increase of speed and reliability of both software
development process, and the software created. Ben-
efits that component-based software development
(CBD) promises through reuse of well tested com-
ponents, with well documented and defined func-
tionality, it should be possible to create new soft-
ware, combining and connecting existing software
components instead of implementing the same func-
tionality over and over again. Unfortunately, current
component models fail to deliver on promises of
CBD (Lau and Wang, 2007; Bose, 2011). This is
evident in many very similar components that have
been implemented over and over again for most
popular frameworks in existence – a simple Google
query for a word “forum” in addition to the frame-
work name of choice will always yield results.
This is because software components are always
built for a specific framework or application that
uses a component model, which defines what a
software component is, how it can be constructed,
composed or assembled and finally deployed (Wal-
lace, 2010; Lau and Wang, 2007; Crnković et al.,
2011). Depending on the framework, components
can vary in possible complexity and functionality.
If a component is built for a specific application,
it can be thought of as an architectural unit, and such
a component can span through many layers of the
application, consisting of many classes and other
code or binary constructs. Components built for a
specific application are easy to reuse, but only inside
other instances of the same application.
Similarly, components built for a specific
framework are also architectural units, or even ap-
plications themselves. When reuse of such compo-
nents is intended inside another application, that
uses the same framework, required programming
effort can be significant. The more complex the
component, the harder reuse is. Although reuse can
be complex, it is significantly less complex than
reusing architectural unit type components built for a
specific application, inside another application.
Thirdly, in object oriented programming, the
most simple components are classes, or libraries of
classes. Reuse of such components is easiest to
achieve, but functionality that such components pro-
vide is minimal compared to an architectural unit
type of components.
To enable component reusability in other appli-
cations or frameworks, software adapters (Bishop,
2007) can be employed. Software adapters translate
required interfaces of one component to provided
interfaces of another component. This is obviously
inefficient and potentially very complex and has led
to implementation of very simmilar components for
various frameworks.
2.1 Nested Framework Component
Model
Our framework makes runtime and design-time as-
sembly of components possible, which is discussed
further in section 4. It makes assembly of nested
components possible, ie. a forum component that
extends the functionality of that same forum compo-
nent. This makes possible the creation of a forum to
debate a single forum post or topic, which is dubi-
ously useful in itself, but in some cases could be, ie.
using a commenting application nesting to enable
comment replies, while the component itself pro-
vides only the simple, basic functionality.
To achieve this, it provides both abstract classes
and objects as base building blocks for component
development. Use of these building blocks, for ex-
ample, provides simple access to host application's
execution context (Prstačić et al., 2011) with rele-
vant data commonly found in Web applications
(Prstačić et al., 2012) – user session, current user
data, current user permissions etc., are all translated
by the framework and provided to extensions in a
form that they can use. Integration of the framework
into the host application involves implementation of
abstract classes that are essential to providing this
translated execution context.
Once implemented, components can be used to
extend existing applications, that were built using a
different framework, with minimal effort. This is
possible because our framework is designed and
built as a component that is ready to be integrated
into arbitrary Web applications that we call host ap-
plications. When this integration is achieved, reusing
any component of the framework is possible using a
single line of code, as discussed further in section
4.2.
ENASE2013-8thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering
150