Conversion of Object Oriented System into Software Product Line with Delta
Modeling Abstract Behavioral Specification
OPEN ACCESS JCC
LONTAR to fulfill those needs. Moreover, we also try to
show advantage of using ABS rather than object oriented.
This paper is divided into six sections: Introduction,
Literature Study, Conversion Steps, Experiment and Ob-
servation, Concluding Remarks, and finally Acknowledg-
ments. Conversion Steps section contains steps to convert
an object oriented system into SPL using ABS. Content of
each steps is elaborated more clearly in Experiment and
Observation section.
2. Literature Study
2.1. Abstract Behavioral Specification
There are many known modeling languages such as Uni-
fied Modeling Language (UML), Java Modeling Lan-
guage (JML), and Behavior Tree. Each of those lan-
guages has certain flaw or weakness. For example, UML
cannot be executed directly and cannot be verified. On
the other hand, implementation level languages such as
JML are lacking on verifiability aspect. Mathematical
approaches try to solve the problem but they are too
complicated, thus making the usability low.
ABS tries to cover those weaknesses mentioned above.
ABS is a software modeling language which located be-
tween realistic and abstract language. The definition of
realistic language is language in implementation level or
language closely similar to how people think to solve
problems. Meanwhile, abstract language is formal lan-
guage and very mathematical. ABS adds executability
for design-oriented modeling language such as UML and
verifiability for realistic language and tries to improve
usability for abstract language.
According to [3], ABS targets concurrent, distributed,
object oriented software. Moreover, software is devel-
oped with several components and with a high variable
level. To achieve the last one mentioned, ABS imple-
ments delta modeling as the main paradigm to develop
various systems. Further information about ABS can be
accessed in http://www.hats-project.eu /.
2.2. Software Product Lines
Software Product Lines (SPL) is a set of software which
have several similar features [4]. Each element of the set
however has unique features to comply with market de-
mand or special mission. Products in SPL pertain to the
same business goal or application domain, they share the
same architectures; they are also built from the same
components and services [5]. Core assets of SPL are the
architectures, components, and services aforementioned.
They are called core assets because they are the main
resources to create new products in SPL.
Eventually, new products will not be created from
scratch again because they can be built simply by reusing
and reprocessing the core assets which already are there.
Therefore, the process of creating new products will be
faster and more efficient. In addition to that, the new
products will be easier to maintain because they have
similar components.
One way to develop SPL is with Delta Oriented Pro-
gramming (DOP) which is a programming language spe-
cifically designed for implementing SPL approach [6].
The purpose of DOP is to provide expressive and flexible
programming language for SPL. An SPL in DOP is im-
ple me nted with a core module and a set of delta modules.
Core module is a starting point of other products which
will be created by application of delta module. Core
module has a number of classes as the base of other
products. The definition of base here is a product to be
modified by delta to make a new product.
Delta modules specify changes in core module to im-
plement other products. Those changes are in class level
such as adding, removing, and modifying class. They can
also be in class structure level such as adding and re-
moving field or method.
2.3. LONTAR
Library Automation and Digital Archive (LONTAR) is a
digital library system in Universitas Indonesia. This sys-
tem manages common activities in library such as look-
ing data about a collection, borrowing collection, return-
ing collection, etc. LONTAR also provides web service
to increase its interoperability for various libraries. The
architecture of LONTAR can be seen in Figure 1.
Currently LONTAR only provides SOAP web service
because LONTAR uses Apache Axis as shown in circle
in Figure 1, which is by default only implements SOAP
web service. In its development, there are needs for
digital libraries to implement REST or other web service.
This paper tries to explore possibility for using ABS to
make LONTAR has another web service such as REST.
The plan is to take one specific LONTAR's module
which is the web service module and convert it to SPL.
With it, hopefully it will become easier to implement
another web service. As illustrated , we tried to adj u st the
module in circle in Figure 1 according to Figure 2.
3. Conversion Step
Steps from Figure 3 can be generally used for every
object oriented system. Meanwhile, steps in Figure 4 are
specifically used for LONTAR conversion from an
object oriented system into an SPL one. In Figure 4, first
two steps are the same as two first steps in Figure 3.
Significant differences for steps in LONTAR are in third
and fourth step. In Figure 4, step “process and generate”
is elaborated more specifically. The triangular shapes