Development and evaluation of a low-level plugin ... - OpenJEVis

HAMBURG UNIVERSITY OF TECHNOLOGY
INSTITUTE FOR SOFTWARE SYSTEMS
Development and Evaluation of a low-level
Plugin Framework for Data Analysis and
Visualisation Applications
Bachelor Thesis by Benjamin Schwanke
Hamburg, 2nd May 2010
Supervisor:
Advisor:
Company Supervisor:
Prof. Dr. Sibylle Schupp
Dipl.-Inform. Rainer Marrone
Dr. Stefan Kuck

Declaration
I hereby confirm that I have authored this thesis independently and without use of others
than the indicated resources. All passages taken out of publications or other sources are
marked as such.
Hamburg, 2nd May 2010
City, Date
Sign

Acknowledgements
I sincerely would like to thank Prof. Dr. Sybille Schupp for giving me the opportunity to
perform this interesting and challenging work in her department. Special thanks to Dipl.-
Inform. Rainer Marrone for his support, motivation and for many helpful discussions. My
other special appreciation goes to the management of the Envidatec GmbH, specifically to
Dipl.-Ing. Thomas Frank, Dr. Stefan Kuck and Prof. Dr. Peter Palensky for providing me
with the challenge to carry out my research work within the company. Last but not least,
I want to express my gratefulness to my family and friends for their support during the
making of this thesis and the whole study.

Abstract
The advantage of visualising data stems from its ability to make use of the human’s efficient
perceptual system. For that reason software with easy to use graphical user interfaces
and comfortable features to display a wide range of different data becomes more important.
This project deals with a design of a low-level framework providing extensibility for a
main software construct through addable plugins based on existent prerequisites. Different
approaches are evaluated and the reasons for chosen concepts are given.
Kurzfassung
Visualisierte Daten haben den großen Vorteil, dass diese vom Menschen weitaus besser
wahrgenommen und behalten werden, als Daten, welche in unformatierter Form vorliegen.
Aus diesem Grund kann der Entwicklung von Software mit leicht zu bedienenden
grafischen Benutzeroberflächen und intuitiven Funktionen zum Darstellen von verschiedensten
Daten eine große Bedeutung zugesprochen werden. In dieser Arbeit wird ein
einfaches Framework entwickelt, welches die Möglichkeit bieten soll, ein Kernprogramm
durch Plugins zu erweitern. Dabei sind gewisse Vorgaben einzuhalten. Die verschiedenen
Ansätze werden bewertet und Gründe für benutzte Konzepte aufgezeigt.

Contents
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Background 3
2.1 Current Visualisation Concepts . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Present GUIs and Applications . . . . . . . . . . . . . . . . . . . 3
2.1.2 Software Specification . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3 IBM ILOG JViews Charts . . . . . . . . . . . . . . . . . . . . . 4
2.2 Plugin Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Hard-coded Plugins . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Dynamic Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Discussion on existing Plugin Designs . . . . . . . . . . . . . . . 7
3 Design and Implementation 9
3.1 Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Overview of the Framework Design . . . . . . . . . . . . . . . . . . . . 10
3.3 Introducing the Plugin Architecture . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Interface vs. Abstract Classes in Project Context . . . . . . . . . 11
3.3.2 Presentation of the Plugin Hierarchy and Configuration . . . . . . 12
3.3.3 Extending the Framework with new Plugins . . . . . . . . . . . . 13
3.4 Register and add Plugins to the Application . . . . . . . . . . . . . . . . 14
3.5 Data Reception through a dedicated API . . . . . . . . . . . . . . . . . . 16
3.6 Data Management and Interchange within the Framework . . . . . . . . . 16
3.6.1 Configuration of the PluginData Class . . . . . . . . . . . . . . . 17
3.6.2 Notification and Reaction to Changes in the PluginData Object . . 17
3.7 Tools and Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.8 Suggestions how to increase Testability . . . . . . . . . . . . . . . . . . 19
4 Conclusion and Outlook 22
Bibliography 23
List of Figures 25

Chapter 1
Introduction
1.1 Motivation
The Envidatec GmbH provides energy services and energy management. Their major
business area is the regular collection and evaluation of energy consumption information
and other energy data in customer’s properties. Visualising this data is an important and
challenging task. Therefore, an application to display all data and to make different data
rows comparable, easy to analyse and benchmark is a fundamental need.
Existent tools in the company are able to do this in a simple way, but they are very specific
or rather inflexible, hard to change and to update. Furthermore, each tool needs an
individual web service to communicate with. That implies high-maintenance software and
consequently much effort for software engineers and programmers. A new system has
been designed by the company to simplify and improve these concepts. There is only one
application programming interface (API) to communicate with the database. Programs do
not need a special web service, they just use the existing API.
The main purpose of this project is the design of a framework that provides easy development
of plugins with all the features needed for best possible visualisation and analysis
conditions. Registered plugins can be arbitrarily added to and removed from a JPanel
component (hereinafter referred to as the main frame). The main frame serves as the
global graphical user interface (GUI) window with global features that are available and
applicable for every plugin. Database communication, data up- and download should be
managed by the API. Data exchange between the plugins has to be consistent and intuitive.
Technical requirements regarding the programming language and libraries are as following:
The programming language is Java. The Java Foundation Classes (JFC), including
the Swing libraries, are used for the GUI and the graphical visualisation tasks are handled
mostly by the IBM ILOG JViews Charts library.

Chapter 1 Introduction 2
1.2 Structure of the Thesis
The introduction describes the purpose of and the need for a software design proposed in
this thesis.
Chapter 2 introduces the prerequisites for the application to be created and presents two
approaches of plugin architecture.
Chapter 3 explains the design and implementation of the low-level framework developed
in this project. Section 3.2 gives a general overview of the framework’s functionality while
section 3.3 and 3.4 describe the plugin architecture in more detail. The problem of data
exchange, im- and export is discussed in section 3.5 and section 3.6. An evaluation of the
tools and libraries is carried out in section 3.7.
Chapter 4 presents the reasons for the concepts and design approaches chosen in chapter
3. Besides, an outlook on further development deals with future plugins and additional
features that can be added to the current application.

Chapter 2
Background
As this project has been carried out by a request of the Envidatec GmbH, it is necessary to
introduce the conditions regarding software development inside this company. This chapter
describes the prerequisites, e.g. specifications for new software products, the already
existent tools and different approaches to design plugin extensibility.
2.1 Current Visualisation Concepts
Most of the software currently used in the company is written in Java. Especially GUI
tools use this technology including the Swing libraries to provide the user, respectively
the customer, with an easy to use graphical user interface. The company’s customers are
used to a certain look and feel. Provided tools follow common GUI design guidelines.
For this reason further development has to pursue this standards to preserve a general
identity and recognition value. The visualisation part, e.g. show charts and analyse data
in arbitrary diagrams, has to be implemented by the use of the IBM ILOG JViews Charts
library introduced in section 2.1.3. This is no drawback, but has to be noted to understand
further proceedings.
2.1.1 Present GUIs and Applications
The Envidatec GmbH provides a range of tools to analyse and to display consumption and
energy related data. Most programs are designed to connect to a database while every
program needs its own client-server connection. Accordingly, every tool needs a dedicated
running servlet to connect to. On that account, there are existing visualisation tools
that implement basic features, but still suffer from certain inflexibility and the need for a
particular servlet. But these tools already implement some core features and methods, e.g.

Chapter 2 Background 4
zooming interactions, that can be transferred to the new application and avoid unnecessary
redevelopment.
2.1.2 Software Specification
The entire program should serve as an analysis tool for recorded energy data, e.g. energy
consumption of the heating system in a supermarket and related data, e.g. outdoor temperature.
These data are saved as data sets in a dedicated database. The task is to visualise
these data sets. For instance this can be done in all kinds of charts, e.g. Cartesian charts or
pie charts. Any other utilisation of the logged data has to be possible as well. Thus, data
sets are available through a database and can be used in arbitrary ways. The program has
no demands on how to use the data, but its main purpose is to visualise them.
To realise variable ways to use the recorded data, it is necessary to design a flexible solution
that is able to cope with many use cases. The approach for this project is a low level
framework supporting a main application that holds plugins to extend its functionality and
features.
These plugins are equipped with database access through a unique API. Any further connection
points to external sources apart from the one provided by the dedicated API are not
supported. Furthermore, data exchange within the main frame and especially between the
plugins is a main feature of the program. Loaded data sets in one plugin have to be transferable
to another and the other plugin must be notified or even updated automatically, if new
data is sent to its data storage object. Another important feature is the synchronisation of
available charts. Editing and zooming actions in a plugin’s chart can affect other plugin’s
charts. This feature requires an option to link plugins among each other. The X-axes of
these charts have be to synchronised if intended. This behaviour has to be controllable by
the user via easy an easily accessible interface.
2.1.3 IBM ILOG JViews Charts
IBM ILOG JViews Charts provides a powerful set of professional Java chart components
for use in graphical user interfaces. It delivers complete support for desktop and web-based
charting with a full set of chart components in a single package. Displays and interactions
are completely customisable, ensuring developers a wide range of programming possibilities
[8]. Figure 2.1 shows a stock chart designed with IBM ILOG JViews Charts.
JViews Charts is based on the Separable Model Architecture [9]. This architecture is a
variant of the Model-View-Controller (MVC), an architectural pattern that separates three
application areas: data (model), representation (view) and interaction (controller) [17].

Chapter 2 Background 5
Figure 2.1: Example of a stock chart designed with IBM ILOG JViews Charts
This pattern provides an isolation between data and its screen representations. The data
model is completely open and extensible, allowing it to connect with any other application
component. Notifications are automatic and transparent. When the data model changes,
views are updated; when the user interacts with views, the model changes. By means of
the Separable Model Architecture, the model manages the data or the values represented
by the component, while the view manages the graphical representation of the model, and
handles interaction on it [9].
2.2 Plugin Approaches
To start developing software with plugin extensibility it is important to understand the
concept of plugins. A plugin in terms of computing is a software module that adds new
features to a host application. Figure 2.2 illustrates the host application providing the software
main functions, services and interfaces. Plugins usually do not work by themselves,
they depend on these services. The plugin characteristics combined with the services provided
result in new features accessible via the main software program. Several designs
allow plugins to be extended by plugins. This approach requires further extension points
for each plugin. There are different ways to develop a program with plugin extensibility.
The decision for one of these ways depends on its requirements.

Chapter 2 Background 6
Host Applicaon
Plugin
Services
Interface
Features
Plugin Handler
Interface
Figure 2.2: General plugin structure
2.2.1 Hard-coded Plugins
Hard-coding in terms of software development describes a programming practise that embeds
configuration or input data directly into the source code of a program. It is an analogy
to hard wiring circuits to convey the inflexibility when used within software implementation
and design.
Host Applicaon
Services
Hardcoded Plugin
load and
communicate
Features
Plugin Handler
Figure 2.3: Hard-coded plugin structure in this project
A hard-coded plugin in this project is referred to be a part of a program, that is implemented
in the source code of the main application. This design is shown in figure 2.3. Every
change in the plugin’s source code requires another compilation of the entire program. In
return a hard-coded plugin structure provides a simple way to develop. Dynamic class

Chapter 2 Background 7
loading and file access is not necessary. This feature is particularly beneficial for applet
development, because according to the Java security manager, applets are subject to high
restrictions on server and client file access.
2.2.2 Dynamic Plugins
A dynamic plugin structure is mainly characterised by a plugin development that is independent
of the main application’s program code. Programmers are able to add and update
plugins to a host application dynamically without changing its source code. Many applications
using this approach even provide plugin loading at runtime. Therefore, the plugin’s
compiled files must be stored in a separate location, e.g. in Java they cannot be part of the
main application’s Java Archive file (JAR).
This approach raises the following requirements:
• A more generic framework
• A plugin discovery and loading component
• Server-side read and write access when used in applets
The design of a dynamic plugin architecture is similar to the design in figure 2.2.
2.2.3 Discussion on existing Plugin Designs
There are existing plugin-based application developments and framework designs. A lightweight
approach is described in [13]. It discusses the plugin concept formally as a design
pattern and makes use of dynamic loading of classes and modules. It includes a plugin
manager to identify and load classes that implement interfaces known to the main application.
One application can be extended with multiple plugins, but their work does not cope
with adding plugins to other plugins.
In [16], a PluggableComponent architecture involves a management component (registry)
that handles different types of plugins. All PluggableComponents are derived from
the PluggableComponent base class. The registry is configured via a tool and therefore,
the administrator or developer decides which components are used. This way, the application’s
configuration is human driven. Hence, the system cannot work without human
interaction.

Chapter 2 Background 8
Plugin application development on another level is provided by Rich Client Platforms
(RCP). One famous open source framework is the Eclipse RCP that is an implementation
of the pure-plugin architecture as described by Birsan in [1]. The hosting application is
reduced to a no-functionality runtime engine for plugins. Any plugin is free to define
new extension points. Other plugin’s functionality and even the kernel can be extended
by new plugins. A manifest file (XML) describing its interconnections in detail has to be
included by every plugin [3]. Finally, a program obtains functionality and becomes useful
for end-users only through a federation of plugins.
The designs mentioned above do all follow the dynamic plugin loading principle. However,
this is a nice feature, but not really necessary for the design of the framework in this thesis.
The project asks for easy development and a compact application topology. Furthermore,
a high number of modules as described in [1] might lead to confusing file structures and
difficult development.

Chapter 3
Design and Implementation
In this chapter a low level framework is designed and modelled, that will be able to comply
with most of the requirements outlined in the previous chapter. In an initial step a
different design approaches are validated and following a conceptual framework model
and its general functionality behind the visualisation is presented. Next, the framework
is broken down into the different components and finally an analysis describes how these
components will be able to satisfy the desired requirements.
3.1 Design Considerations
The required specifications are described in section 2.1.2, section 2.2 and especially 2.2.3
present a set of different approaches to develop plugin frameworks. While comparing
requirements and existing approaches listed in section 2.2.3, only a small number of intersections
can be found. In this project, a plugin is referred to be a GUI component providing
visualisation features and containing predetermined components like buttons and menus.
Accordingly, plugins are supposed to have a common appearance, share a mutual design
and therefore have to be limited within their fundamental characteristics. Since GUI
components must be implemented by the use of the Swing libraries following the requirements
in section 1.1, plugin classes must extend at least javax.swing.JComponent or even
javax.swing.JPanel to ensure a consistent GUI appearance and development guidelines.
These limitations can be enforced by inheritance. A superclass predefines the common
look and feel and rudimental features in such a way as to provide these characteristics to
each subclass, respectively each extending plugin class. Since [13] deals with an interface
structure that does not cope with the requirements, it won’t be applied to this project. The
concept discussed by Völter in [16] implies, that every plugin is derived from Pluggable-
Component (see section 2.2.3). This lacks flexibility, because in Java every class cannot
extend more than one superclass. Hence, plugins that extend PluggableComponent are
unable to extend a necessary Swing (e.g. JPanel) class to be displayed in the application’s
main frame (see section 1.1).

Chapter 3 Design and Implementation 10
Furthermore, the data exchange and synchronisation of interactions between plugins asks
for a tight binding of the plugins. This is another point, why plugin classes must be strongly
limited within their basic development or at least need to fulfil the requirements given by
a superclass to ensure proper behaviour.
The next sections introduce an implementation of a design, able to cope with the requirements
of this work.
3.2 Overview of the Framework Design
Figure 3.1 shows the general concept of the framework and how it is embedded in the
software program. The principle of subclassing is used to realise good extension capabilities.
Upcoming threads when using inheritance are discussed in 3.3.1. An abstract root
class with rudimental features provides basic operations and ensures the communication
constraints mentioned in section 2.1.2. Plugin classes extend the root class one of its subclasses,
providing more features than the root class. This approach is discussed in section
3.3. Moreover, the root class contains a data object and likewise each inherited plugin.
This PluginData class holds the JavaBeans specifications and fires change events every
time a property, e.g. data set, changes. Section 3.5 describes the data exchange.
The PluginHandler class is responsible for many different tasks. Primarily, it registers and
adds plugins to the main frame and takes care of the right display position in the main
panel. Details will be explained in section 3.4.
exte nds
Plu gin N o 1
Pan el
listen
and change
Plugin No 2
Panel
A bstractPlu gin
set / get selected data
P lu ginD ata (JavaBean)
- contains arbitrary data types as
properes
- fires change events
M ain Fram e
M ain Pan el
select and get data from database via API
Tree Dialo g
register / add Plugin
PluginH and ler
registerPlugin(JApplet applet, String pluginClassName)
{// register plugin without instantiation}
addPlugin(String pluginClassName)
{// create instance and add to main panel }
Figure 3.1: Overview of framework design

Chapter 3 Design and Implementation 11
3.3 Introducing the Plugin Architecture
3.3.1 Interface vs. Abstract Classes in Project Context
Inheritance is a powerful mechanism regarding software development, but is appropriate
only when a genuine subtype relationship exists between the subclass and the superclass
[2]. Subclassing involves some problems, the developer must be aware of. Classes, especially
designed and documented for extension, reduce the threat of erroneous behaviour
when they are extended by subclasses. In the first place, self-used overridable methods
must be accurately documented to avoid unconscious overriding and therefore unpredictable
behaviour in subclasses. Another danger is the updating of superclasses. Assuming
that a subclass overrides a method with certain functionality to prohibit decisive operations
within this method. Then, if its superclass acquires new methods with similar functionality
in subsequential releases, these methods can easily by-pass the prohibitions made in
the subclass unless they are not analogically overridden. Most objections to inheritance
stem from overriding, but through merely adding new methods to superclasses, avoidance
of overriding methods in subclasses and precise documentation, many problematic issues
can be minimised.
On the one hand many designs prefer interfaces over abstract classes or inheritance in
general. They allow a construction of nonhierarchical frameworks [2] and provide high
flexibility. Additionally, the previously mentioned difficulties with overridable methods
do not appear. On the other hand there are two drawbacks on interfaces that play an important
role in this work.
Evolving abstract classes is much easier than evolving interfaces [2]. Supposed a new
version of an abstract class contains new concrete methods. This modification is automatically
passed to all subclasses, so that they do all provide these new methods. In particular,
the GUI design progress benefits from the ease of abstract class development, because
GUI alteration or new features (e.g. buttons or menus) can be made in the superclass and
thenceforward, are present in each subclass. For interfaces, this does not work.
By the time an interface is released and implemented to a certain extent, it is almost impossible
to change. Changes must be considered in every class that implements the interface.
This is hardly manageable if you deal with many classes and due to the fact, that the interface
developer does not know which classes use the interface. For abstract classes this
issue exists to a certain degree. Changing existing methods, variables or return types raises
similar problems. But, adding new features, methods, variables does not affect existent implementations
in subclasses. In contrast, subclasses get updated and equipped with those
additional features without any further changing. To summarise, interfaces are generally
the best way to define types that allow heterogeneous implementations. Though, when
ease of use is deemed more important than flexibility and power, abstract classes are the
right way to define a type with the awareness of implicated limitations [2].

Chapter 3 Design and Implementation 12
3.3.2 Presentation of the Plugin Hierarchy and Configuration
According to the discussion in section 3.3.1, the principle of subclassing is considered as
good practise for this project. Classes inherit (extend in Java) from their superclasses thus
once implemented methods and fields in a superclass can be used in every subclass. Redundant
code and additional, unnecessary programming can be avoided. A contributing
aspect is the keyword abstract. Classes that are declared abstract in Java can contain fields
that are not static and final and they can contain implemented methods. Abstract classes
cannot be instantiated. They just serve as a base class that provides certain fields and methods.
They have a certain similarity to interfaces in Java, except a partial implementation
is provided, leaving it to subclasses to complete and extend it. Interfaces in Java do not
provide the features mentioned above and on that account subclassing is favoured over
interfaces here.
Abstract classes facilitate the plugin development. Figure 3.2 illustrates the chosen concept
and its application to this project. There is a base class called AbstractPlugin. The precondition
for every new abstract or concrete class with further functionality is to extend this
class. Assuming that this precondition maintains, every inherited class is equipped with
essential components. The following itemisation specifies some of them.
• A manager object to access the database,
• a toolbar including buttons to access the most important features,
• the PluginData object to store received data and
• predetermined panels preserve graphical layout.
Figure 3.2 depicts the present build of existing abstract classes and shows two concrete
classes MyArbitraryPlugin and DigitalChart, that can be seen as examples for discrete,
usable plugins developed for this application.
Moreover, plugins that do not comply with the predetermined subclassing requirements
cannot be added to the application. This behaviour is ensured through the restrictions
in the PluginHandler implementation. The PluginHandler (see section 3.4) exclusively
accepts subclasses of AbstractPlugin. Any other classes won’t be handled, registered or
added to the main panel and are consequently useless.

Chapter 3 Design and Implementation 13
AbstractPlugin
AbstractChartPlugin
MyArbitraryPlugin
AbstractCartesianChartPlugin
AbstractFullCartesianChartPlugin
DigitalChart
Figure 3.2: Diagram of plugin inheritance
3.3.3 Extending the Framework with new Plugins
The ability to extend the application with new plugins or new abstract classes that provide
additional features to further plugins is limited, but possible and desirable to a certain
degree. The project’s requirements ask for extension capability regarding new plugin development.
Extending plugins with other plugins is not required and therefore not considered
to provide a lightweight design that is easy to handle. The approach to extension relies on
the concept of subclassing explained in section 3.3.1 and 3.3.2. New plugins extend one
of the given abstract superclasses or, if no superclass fits its needs, it will extend the base
class AbstractPlugin and define all of its desired features itself. Assumed that these features
are useful for subsequent plugins, a new abstract plugin class that extends one of the
existing abstract classes might be created. The desired plugin extends this abstract plugin
class and adds its appropriate implementation.
This way, plugin development, respectively plugin extension, is based on a simple convention.
Similarly structured plugins with a standardised appearance result from the consistent
and limited principle of inheritance.
The hard-coded plugin structure combined with subclassing chosen for the design and
extension concept of this project implies that modifications in any plugin’s source code
involves changes in the application’s source code. Consequently, adjusting existent or
adding new plugins entails a recompilation of the whole program. Hence, extensive third
party programming is not supported. Development, implementation and extension are
subject to the application’s programmer.

Chapter 3 Design and Implementation 14
3.4 Register and add Plugins to the Application
Dynamic plugin loading as defined in section 2.2.2 is not requested in this project. For
this reason, scanning external sources, e.g. file archives and directories, for plugins is not
necessary. Nevertheless, the project still demands flexibility, e.g. load an arbitrary number
of plugins of the same type, and as little overhead of not used plugin instances as possible.
As seen in figure 3.1 there is a class called PluginHandler that meets these conditions.
But every available plugin has to be introduced to the plugin handler. Otherwise it cannot
be loaded or added to the main frame. Therefore, the PluginHandler implements two
important methods:
1 public void registerPlugin(JApplet applet, String pluginClassName)
2 {...}
and
1 public void addPlugin(String pluginClassName)
2 {...}
During the main frame initialisation registerPlugin() is invoked to publish every available
plugin via its unique pluginClassName. Within this method, the according resource bundle
location is set and a new menu item is added to the plugin menu in the main frame’s menu
bar. Until this point, neither a plugin has been loaded nor any plugin related objects have
been instantiated. What happened is just a publication of the available plugins that enables
the user to chose one or more of them to start.
Any further steps are taken by the addPlugin() method. As far as a plugin menu item is selected
and clicked by the user this method is called. Only now the object instantiation takes
place. The concept of dynamic class loading is realised through two Java core methods.
These methods are
1 public static Class forName(String pluginClassName)
2 {...}
and
1 public Constructor getConstructor(Class[] parameterTypes)
2 {...}
Both methods are used in addPlugin(). In Listing 3.1, line 6, a Class object associated
with the class with the given fully qualified pluginClassName is returned. In line 8, a
public constructor of that class with the specified parameterTypes is searched and invoked
to create a new instance of an AbstractPlugin object containing a unique plugin ID. After
both method invocations, a newly-created plugin object is available to be added to the main
frame (line 12) and ready to use. Whenever a plugin specific method is called, a downcast

Chapter 3 Design and Implementation 15
from AbstractPlugin to the desired plugin class is necessary. For this purpose, the Java
programming language provides run-time type identification (RTTI). It is able to find the
exact type of an object when a handle to only the base type is available [4].
1 public Integer addPlugin(String pluginClassName)
2 {
3 AbstractPlugin newPlugin = null;
4 pluginID++;
5 // [...]
6 Class

Chapter 3 Design and Implementation 16
this downside does not affect the frameworks security concerning unintentional loading of
malicious classes, because the application quits immediately when a ClassNotFoundException
is caught.
3.5 Data Reception through a dedicated API
There are many ways for the transfer of data between client and server. Here, there is
a predetermined way to do this. Data connection, e.g. request new data rows from a
dedicated database and add new values to the database, has been made easy. The existence
and desired use of a client API called JEVis Client API (JECAPI) simplifies this issue.
It provides a configurable handler object, that establishes a connection with the desired
database. The AbstractPlugin class creates a given, default tree table manager object. This
is passed to a new dialog object that presents the connected database structure in a tree
view. Hence, data rows can be browsed, selected and loaded into the plugin’s data storage
object PluginData. The PluginData class and its tasks are described in section 3.6.
Different ways to receive data from external sources are possible, but not natively implemented.
Further development or special needs might result in additional ways of communication.
Although, utilising the JECAPI is desired and this application is especially
prepared for its use, there is no directive to use it. The framework is open for any communication
channel, but provides no built-in support for web services other than the included
JECAPI. If ongoing development requires more communication channels, the framework
has to be extended in a way that supports these new requirements and still comply with the
specifications outlined in this work.
3.6 Data Management and Interchange within the
Framework
The data management is centralised in an object called PluginData. Its design is related
to the JavaBeans concept (see section 3.6.1 and serves as the main data storage and
exchange component for every single plugin. It guarantees consistency through the use
of the observer design pattern introduced in [6]. Section 3.6.2 covers this issue in more
detail.

Chapter 3 Design and Implementation 17
3.6.1 Configuration of the PluginData Class
In fact, the JavaBeans architecture is a component model which enables developers to
create reusable software component that can be visually manipulated in builder tools. But
this project only calls upon the core features of the JavaBeans concept. The following list
briefly describes key bean conventions.
• The default constructor must be public for easy instantiation.
• All properties must comply with the principle of information hiding via private access
modifiers.
• The class properties must be accessible using get, set or other accessor/mutator methods
that follow a standardised naming convention
• The class should implement the Serializable interface.
The PluginData class follows the conventions listed above. If a class is defined according
to given specifications, it is easier to understand and maintained. Subsequent extensions or
modifications are limited within these guidelines. If further development holds on to these
guidelines, the PluginData class is extensible with arbitrary properties and data types and
thereby usable in every upcoming plugin. There is one property for every desired data
type that should be stored in the PluginData object. New properties can be added at any
time during development. Data that is received from an external source gets stored in
the associated property. Once stored, it can be used and shared among other plugins. If
one plugin wants to set or get another plugin’s property value it calls the getPluginData()
method via the global PluginHandler object. This way, plugins can interchange their data
and their property values respectively.
3.6.2 Notification and Reaction to Changes in the PluginData Object
The Observer pattern "defines a one-to-many dependency between objects so that when
one object changes state, all its dependents are notified and updated automatically."[6].
There are two key objects called subject and observer. Any number of observers can be
added to the subject and if the subject’s state changes, all observers will be notified. Hence,
consistency is ensured between the state of the subject and behaviour of the observer objects.
The Java programming language provides a comfortable implementation of the Observer
pattern called PropertyChangeListener that is especially developed for changes of properties
in JavaBeans components. This design meets the demands of consistency between

Chapter 3 Design and Implementation 18
data and view according to the model view controller concept.
The class that should be notified of changes in particular properties needs to implement
the PropertyChangeListener interface. Furthermore, it implements the according property-
Change(PropertyChangeEvent evt) method and defines custom code that is executed every
time a PropertyChangeEvent is received by that class. Those events are fired by the subject
(see 3.6.2), in this case the PluginData object. The PluginData class contains an instance
of PropertyChangeSupport and delegates various work to it, especially firing appropriate
PropertyChangeEvents.
M yConcre tePlugin
public void propertyChange(P ropertyChangeEvent evt)
{ // insert code to execute on property change }
invoke propertyChange()
fire change event
PluginD ata
p ub lic Strin g PRO P_ N U M B ERS = “num be rs“;
p riv ate Vecto r n um be rs;
p riv ate Pro p ertyC h ang eSu p po rt pcs;
Figure 3.3: Outline of property change event handling
Here, the PluginData class contains properties and an instance of PropertyChangeSupport
that fires PropertyChangeEvents as soon as a property gets changed. Every plugin inherits
the PropertyChangeListener interface by extending an abstract plugin class (see 3.3), but
implements its own propertyChange() method. Thereby, the plugin’s behaviour towards
incoming change events is completely customisable. Figure 3.3 sketches the general structure.
3.7 Tools and Libraries
The basic tools used are the IBM ILOG JViews Charts (see section 2.1.3) and Swing libraries.
Additionally, the present web service JECPAI is used for electronic data interchange.
Assuming that the IBM ILOG JViews Charts libraries adhere to the model-view-controller
architecture, they suit this project’s design very well. The Swing architecture is rooted
in the MVC design, too, although it can be seen as a modified MVC [5]. Both libraries

Chapter 3 Design and Implementation 19
follow the same guidelines and cooperate in a very valuable manner. The data storage and
exchange (see section 3.5) in this project cover elements of the MVC idea as well. Hence,
these three parts work in collaboration.
The JECAPI and its trailed web service contribute to the data type specifications. It implements
a data request method that returns a predetermined data object containing all
necessary information and values. Due to the fact that the returned object holds certain
constraints the framework does not need to care for possible faulty data or prohibited data
types. If the database contains entries that cannot be processed within the framework,
this data is not even exported by the JECAPI, because the JECAPI handles such incidents
independently.
3.8 Suggestions how to increase Testability
This project’s original appointment is the initialisation of an easy to use and clearly structured
low-level framework to support plugin extension for dedicated application. Primarily,
it is designed to maintain a comfortable and consistent graphical user interfaces for applications
and its plugins. Design issues regarding testability and testing in general therefore
were not explicitly focused during development. Nevertheless, these questions are not
ignored and will be covered theoretically in this section. Hence, future development might
take advantage of these proposals and tend to result in source code refactoring.
In [10], Jungmayr outlines different approaches to contribute to low test costs and increased
quality of the product under test:
• improve the software specification and documentation,
• reduce or change functional requirements to ease testing,
• use better test techniques,
• use better test tools,
• improve the test process,
• train people, and
• improve the software design and implementation.
Software specifications and the application’s requirements won’t change in the near future.
Well documented source code administers to a better understanding and a more efficient
test case creation. If the application lacks this feature, comprehensive documentation can
be amended with little effort. Test tools, techniques and processes to some extent rely on
the developer’s preferences and choice.
Improvements in design and implementation are considered to create the most enduring
benefits in terms of testability. Object-oriented (OO) software design in contrast to sequential
implementations is regarded to be correlated with low testability due to the prin-

Chapter 3 Design and Implementation 20
ciples of inheritance and information hiding [15]. However, there are design approaches
to counteract this drawback of OO programming or at least to weaken its influence on
testability.
J.E. Payne et al. [15] discuss software contracts and their impact on testability. The
following three essential elements describe a formal or systematic class specification and
its associated methods:
• Invariant: A condition that applies to any instance of a class at any time or a condition
that should always be true for a specified segment of a program.
• Precondition: A condition that must be true prior to calling a method.
• Postcondition: A condition that the method itself promises to achieve.
These three roles collectively support what is called the design-by-contract model of programming.
They characterise the behaviour of a class and the requirements of its proper
use. In [15], the attention is turned to assertions to implement preconditions, postconditions
and class invariants. The Java programming language has built-in support for this
model since J2SE 1.4 1 . In fact, it supports assertions and introduces the keyword assert
to provide a source code implementation of the elements listed above. Listing 3.3 is based
on code snippets of an integer stack taken from [12] and shows how assertions are used in
Java. Pop and push methods are equipped with assert statements to verify correct values
and operation results. The assert command checks wether a boolean expression is true or
false. If true, nothing happens, but if the expression evaluates to false, the system throws
an AssertionError containing the given string after the colon. The system’s stack trace is
printed including the AssertionError message and the program aborts.
1 public int pop() {
2 // precondition
3 assert !isEmpty() : "Stack is empty";
4 return stack[--num];
5 }
6 public void push(int element) {
7 // precondition
8 assert num < capacity : "stack is full";
9 int oldNum = num;
10 stack[num] = element;
11 // postcondition
12 assert num == oldNum + 1 && stack[num-1] == element : "
problem with counter";
13 // class invariant
14 assert inv();
15 return;
16 }
1 Java 2 Platform, Standard Edition v 1.4

Chapter 3 Design and Implementation 21
17 private boolean inv() {
18 return (num >= 0 && num < capacity);
19 }
Listing 3.3: Class showing use of precondition, postcondition and class invariant
Assertions in Java are further used in classes designed for multithreading. A common
manner is to implement a precondition through an assert statement in nonpublic methods
to check whether or not some lock is held. This issue will not be covered in this work,
because the framework and the sample application are both not made for multithreading,
respectively do not contain multithreaded classes.
Software design-for-testability and consequently the use of software contracts is advocated
in [15]. Implementing assertions is regarded as good practise to achieve a high level
of object observability and to correct internal states within a program. Therefore, they
can significantly affect the overall testability of object-oriented software. Numerous design
approaches exist to increase testability. A useful overview of interesting concepts is
presented by Jungmayr in [10].

Chapter 4
Conclusion and Outlook
To understand the chosen approaches in the previous chapters it is important to know
in what domain the application is working and developed. The team of programmers
is separated into different fields and only a very small part is responsible for the GUI
and visualisation tasks. Anyway, all of them cooperate and should benefit from the new
software and plugin design.
Because subclassing is chosen for the design and extension concept of this project, it lacks
dynamic extensibility to a certain extent. The source code has to be recompiled every
time changes want to be made to plugins or other plugins are ready to be added to the
application. In fact, this is a disadvantage in terms of flexibility and changeability. But,
granted that the software that is supposed to use these concepts is more likely to be used
within one company, maintained and edited by a small group of programmers, than to be
spread out to arbitrary developers, an easy and straightforward way of development and
understanding is more important than a very complex and flexible structure. The software
and especially its plugins will be a selling product of the Envidatec GmbH. Most likely,
the software will run on a server, accessible trough a web portal. The software runs in a
central place, easy to manage and maintained. Updates and changes need to be applied to
one program in one place only. Consequently, the effort to publish new versions is kept
within reasonable limits.
In the future, many more plugins will be developed and implemented. All of them will use
the framework provided by this project. The framework itself is extensible as well. Further
projects might extend it with more flexibility or more abstract classes to provide new drafts
for a new range of concrete plugins. This way, unforeseen task might be performed with
the help of this framework.
Furthermore, applying design concepts to increase testability might be an interesting task
for subsequent development. Some ideas are outlined in this work, but there will be many
more ways to make the software more robust and to improve its testability.

Bibliography
[1] D. Birsan. On Plug-Ins and Extensible Architectures. Queue, 3(2):40–46, 2005.
[2] J. Bloch. Effective Java (2nd Edition) (The Java Series). Prentice Hall, 2008.
[3] R. Chatley, S. Eisenbach, and J. Magee. Painless plugins. Technical report, Department
of Computing, Imperial College London, 2003.
[4] B. Eckel. Thinking in Java. Prentice Hall, 2003.
[5] A. Fowler. A Swing Architecture Overview - The Inside Story on
JFC Component Design. http://java.sun.com/products/jfc/tsc/
articles/architecture/. [Online; accessed 25-February-2010].
[6] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. Elements of
Reusable Object-Oriented Software. Addison-Wesley, 1995.
[7] D. Govoni. Java Application Frameworks. John Wiley & Sons, 1999.
[8] I. S. Group. IBM ILOG JViews Charts - Features and Benefits. http:
//www-01.ibm.com/software/integration/visualization/
jviews/charts/about/?S_CMP=wspace. [Online; accessed 4-February-
2010].
[9] I. S. Group. IBM ILOG JViews Charts v8.6 - Introducing JViews Charts.
ftp://public.dhe.ibm.com/software/websphere/ilog/docs/
visualization/jviews86/jviews-charts86/ps_usrintcharts.
pdf. [Online; accessed 8-February-2010].
[10] S. Jungmayr. Design for testability. In Proceedings of CONQUEST 2002, pages
57–64, Nuremberg, Germany, September 18-20 2002.
[11] P. Kuchana. Software architecture design patterns in Java. Auerbach Publications,
Boston, MA, USA, 2004.
[12] Q. H. Mahmoudp. Using assertions in java technology. http://java.sun.

Bibliography 24
[On-
com/developer/technicalArticles/JavaLP/assertions/.
line; accessed 9-April-2010].
[13] J. Mayer, I. Melzer, and F. Schweiggert. Lightweight plug-in-based application development.
NODe ’02: Revised Papers from the International Conference NetObjectDays
on Objects, Components, Architectures, Services, and Applications for a
Networked World, pages 87–102, 2003.
[14] M. Naftalin and P. Wadler. Java generics and collections. O’Reilly Media, Inc.,
2006.
[15] J. E. Payne, R. T. Alexander, and C. D. Hutchinson. Design-for-Testability for
Object-Oriented Software. Object Magazine, 7(5):34–43, 1997.
[16] M. Völter. Pluggablecomponent - a pattern for interactive system configuration. In
Proceedings of the Fourth European Conference on Pattern Languages of Programming
and Computing, EuroPLoP 99, Irsee, Germany, July 7-10 1999.
[17] Wikipedia. Model view controller - Wikipedia the free Encyclopedia. http://de.
wikipedia.org/w/index.php?title=Plagiat&oldid=43117308.
[Online; accessed 4-February-2010].

List of Figures
2.1 Example of a stock chart designed with IBM ILOG JViews Charts . . . . 5
2.2 General plugin structure . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Hard-coded plugin structure in this project . . . . . . . . . . . . . . . . 6
3.1 Overview of framework design . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Diagram of plugin inheritance . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Outline of property change event handling . . . . . . . . . . . . . . . . . 18