Building a Reactive UMLet API for Eclipse

Building a Reactive UMLet API for Eclipse
registration: 4784227
(Supervisor: Dr Joost Noppen)
Abstract
This project involved the building of a reactive Application Programming Interface
(API) for UMLet, a Unified Modelling Language diagramming application. It required
the use of and integration with a predefined Integrated Development Environment, namely
Eclipse, for which it is available as a plugin. A reference implementation of the API incorporated into another Eclipse plugin, was also to be achieved.
The development of this API consisted of a number of stages:
1. Undertaking a literature review: being based on a specified set of criteria, the
literature review for this project had to take into account both specific directly
related material, as well as more generic matters. This provided a firm foundation
for commencing the design of the system.
2. Researching and selecting tools and methodologies having regard to the criteria
set out in the initial project specification
3. Conceiving the best potential designs: This was achieve through successive iterations of thorough experimentation as well as detailed inspection of the UMLet
source code.
4. Designing, developing, testing and perfecting the various components of the system.
5. Consolidation and deployment for the purpose of the project.
An unanticipated new release of the UMLet plugin resulted in an unexpected additional phase.
Execution of the project resulted in a working version of the API. It also demonstrated
the value of certain software engineering techniques such as the use of software design
patterns and an iterative development model.
CMPC3P2Y
Acknowledgements
The project relied upon:
• UMLet, originally developed in 2002 and now in it’s 12th release.
• Eclipse, originally released in November 2001 by IBM and now at release 4.2.
And the particular contributions of the following persons:
• Dr. Joost Noppen the project supervisor whose constant availability, attentiveness,
support and encouragement proved invaluable.
• Dr. Pierre Chardaire, the module organiser, who also provided helpful advise and
encouragement.
• Dr. Richard Harvey, whose project lectures brought added value.
Reg: 4784227
3
CMPC3P2Y
Contents
Contents
1
Introduction
7
2
Literature Review
7
2.1
Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.1
The Integrated Development Environment . . . . . . . . . . . .
7
2.1.2
The Plugin Architecture . . . . . . . . . . . . . . . . . . . . .
8
2.1.3
Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2
The Java Programming Language . . . . . . . . . . . . . . . . . . . .
10
2.3
UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.4
UML Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.5
Software Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.5.1
Singleton design pattern . . . . . . . . . . . . . . . . . . . . .
13
2.5.2
Facade Design Pattern . . . . . . . . . . . . . . . . . . . . . .
14
2.6
Software Methodology . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.7
Event driven programming . . . . . . . . . . . . . . . . . . . . . . . .
16
3
4
5
6
Design of the Software System
16
3.1
17
The Application Programming Interface . . . . . . . . . . . . . . . . .
The Eclipse Environment
19
4.1
Exploration of Eclipse Plugin Extensibility . . . . . . . . . . . . . . .
19
4.2
The D-UEA-ST Eclipse Plugin . . . . . . . . . . . . . . . . . . . . . .
20
4.3
Initial API Implementation . . . . . . . . . . . . . . . . . . . . . . . .
20
The UML Model
22
5.1
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
5.2
Population . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.3
Persisting Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
The Reactive API
6.0.1
Reg: 4784227
The Notification Centres . . . . . . . . . . . . . . . . . . . . .
25
25
5
CMPC3P2Y
7
Contents
Proof of Concept D-UEA-ST Plugins
29
7.1
The Name Checker Plugin . . . . . . . . . . . . . . . . . . . . . . . .
29
7.1.1
The First Implementation . . . . . . . . . . . . . . . . . . . . .
29
7.1.2
Further Revisions . . . . . . . . . . . . . . . . . . . . . . . . .
29
The OMT Analyser Plugin . . . . . . . . . . . . . . . . . . . . . . . .
29
7.2
8
New UMLet Release and Multiple Document Support
30
9
Deliverables
31
9.1
Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
9.2
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
10 Future Development
31
11 Conclusion
32
Reg: 4784227
6
CMPC3P2Y
1 Introduction
1 Introduction
This project sought to design and implement a reactive Application Programming Interface (API) that would allow new software tools to both easily and effectively integrate
with a Unified Modelling Language (UML) based diagramming application and to assist users in designing UML diagrams. For the user facing, diagramming, application
(client side), "UMLet" (UMLet Project, nd) was selected as worthy of investigation.
UMLet is available as an Eclipse(The Eclipse Foundation, nd) plugin. Eclipse, an opensource integrated development environment (IDE) that is built around a flexible plugin
system while supporting different programming languages. It was thus also selected for
investigation.
This report documents the research of existing material, the research performed to
identify the best possible solution for the implementation of the API and seeks to fully
document the resulting system.
2 Literature Review
2.1 Eclipse
2.1.1 The Integrated Development Environment
With the increasing complexity of modern day operating systems, developers have significantly increased their expectations of tools used to support software development.
Developers use many different tools and technologies in their work and these become
increasingly difficult to manage as more tools are used. An Integrated Development
Environment (IDE) aims to solve this problem by giving developers the ability to access
the functionality of each of such tools from within one program. Rivieres and Wiegand
(2004) explained this in their paper on Eclipse:
"The use of IDEs is prevalent for one simple reason: they make software
developers more productive [...] Another way to improve productivity is for
the IDE to cover more of the software development life cycle."
Reg: 4784227
7
CMPC3P2Y
2 Literature Review
Storkel (2002) explained that Eclipse (The Eclipse Foundation, nd) aimed to be a
language-neutral IDE that is platform independent, even though it is built on a Java
foundation. The Eclipse environment provides a number of open application programming interfaces (APIs) that can be used to create new tools and integrate existing tools
into a developers workflow. By doing this, the Eclipse environment can control the interaction between these tools. The resulting product is a very streamlined development
experience, where all the tools work well with each other, even though they may be developed by completely different entities. This contrasts width some language-focused
IDEs, which may contain some of the functionalities that developers seek but may lack
some important functionality, thus impacting negatively on the developers productivity
(Rivieres and Wiegand, 2004).
Rivieres and Wiegand (2004) summarise this well:
"The Eclipse Platform’s principal role is to provide tool providers with
mechanisms to use and rules to follow that lead to seamlessly integrated
tools. These mechanisms are exposed through well-defined API interfaces,
classes, and methods. The platform also provides useful building blocks
and frameworks that facilitate developing new tools."
2.1.2 The Plugin Architecture
The Eclipse plugin architecture allows new functionalities to be easily integrated into the
IDE. Rivieres and Wiegand (2004) note that the core of the Eclipse IDE is known as the
“Platform Runtime” and consists of a small codebase that is responsible for the loading
of plugins. The graphical user interface (GUI) and tools, that to the user appears as a
single program, are then built up using a lot of small plugins, each of which implement
a small piece of the overall functionality.
A plugin is usually distributed as a Java Archive (JAR) file, a compressed container,
which contains the plugin’s Java byte code, as well as any other resources needed for
the plugin to function. Eclipse also offers plugin developers the possibility to split the
functionality of a given plugin into separate JAR files that are then bought together at
runtime. An example of where this segregation of plugin code can be used is discussed
by Rivieres and Wiegand (2004) when it is explained that multiple plugin files are:
Reg: 4784227
8
CMPC3P2Y
2 Literature Review
"[...] the mechanism used to deliver separate language packs for an internationalized plug-in"
When an Eclipse plugin is created, an associated Extensible Markup Language (XML)
file containing relations with other plugins also has to be created. This file allows the
plugin to detail build-time and run-time dependancies on other plugins while also detailing extension points. These extension points are Eclipse’s mechanism for dynamically
extending plugin’s functionality using a further plugin. This mechanism allows different plugins to interact with each other, as well as allowing the modularisation of code
explained above.
When Eclipse is first started a “registry” of the plugins is established and the relationships between them is read from each plugin’s XML file. Because this operation is only
performed on startup, no new plugins can be installed and loaded into the environment
without also first closing and restarting Eclipse.
When dormant plugins are activated, a request is sent to the plugin registry querying
which other plugins provide additional functionality. This can be done without actually
loading any plugins and means that such additional plugins are only activated by a parent
plugin, when the functionality that they implement needs to be used. By working in the
manner, Eclipse minimises the resources (CPU, Memory, etc.) needed and reduces the
start up time of the IDE. Eclipse also allows plugins to store information relating to
them, so that they can maintain any preferences that a user may have indicated.
2.1.3 Tools
UMLet (UMLet Project, nd) is a software tool in which user’s can design UML diagrams
and is available as an Eclipse plugin as well as a standalone version. UMLet forms part
of the user facing portion of this project. A second plugin, that runs in the background,
would then be able to use an API to receive notifications of changes to a diagram and
make any changes. Csertan et al. (2002) use a similar concept in their project:
"A back-annotation engine (based directly upon the automatically generated transformer) provides the user with the analysis results integrated into
Reg: 4784227
9
CMPC3P2Y
2 Literature Review
the original UML model. The entire transformation framework is hidden
from the end user."
This project did however intend to explore how the user facing functionality and the
back-end functionality can be separated by using two separate plugins that are able to
communicate with each other. This offers the advantage of multiple back-end processes
being able to communicate with a single user facing process.
2.2 The Java Programming Language
It merits being mentioned that, in considering the choice of programming languages,
the existence of the Java Hotspot Performance Engine was amongst the reasons that
militated in favour of its use in this project. Oracle (nd) explains that,
"virtually all programs spend the vast majority of their time executing a
minority of their code."
The Hotspot architecture makes use of this fact and implements a variant of a "just in
time" compiler. This allows the Java byte code to be run, first off, by the interpreter and
performance analysis performed, recording which methods are used the most. These
highly used methods are then replaced, on the fly, by the virtual machine with native
optimised code. This architecture avoids the need to optimise rarely used methods that
may never benefit from it.
By using extremely optimised garbage collection algorithms, Java is able to treat
all non primitive variables (all variables instantiated from a class inheriting from the
Object class) as references to a location in memory, avoiding the need for developers
to perform manual memory management. Oracle (nd) discusses how this optimisation
considers how many processors and how much RAM, the computer running the JVM
has, and in doing so,
the garbage collectors will self-tune to improve the throughput of the application and reduce pause times.
Reg: 4784227
10
CMPC3P2Y
2 Literature Review
2.3 UML
Unified Modelling Language (UML) is a modelling language, standardised by the Object Management Group (OMG), that helps people model and plan ideas and projects
using charts and diagrams that show the relationships between different aspects of design in a project. Given that UML is standardised, these diagrams can be shared by
different persons and, potentially, different applications to communicate ideas and implementations in a common format. According to the UML specification published by
OMG:
"The objective of UML is to provide system architects, software engineers,
and software developers with tools for analysis, design, and implementation
of software- based systems as well as for modelling business and similar
processes (Group, 2010)"
As UML has grown in popularity, and newer versions of the specification have been
released, additional types of diagram that can be used have been added to the specification. Csertan et al. (2002) note that this was a concern to them and that there was
a:
"need for a high-degree of flexibility due to the changing and extensible
UML standard, the problems revealed in UML and the implementationrelated aspects of the target application to be included into the transformation"
A need was therefore envisaged, that the API would need to be easily extensible, so
to allow additional diagram types to be supported.
2.4 UML Analysis
Csertan et al. (2002) proposed that a UML dialect be used for interacting with their
application. The use of a front-end application, such as UMLet, for user input and
display of notifications, should avoid introducing another dialect to a user and permit
Reg: 4784227
11
CMPC3P2Y
2 Literature Review
them to use a visual format that they may be more familiar with. This could, in turn,
result in less errors, by the end user, when designing diagrams.
This has been identified as a problem in the past by Ramollari and Dranidis (2007),
who commented that:
"[...] Both professional and educational tools lack consistency and validation capabilities, which we consider as important educational features. As a
result, such tools discommode, instead of supporting the learning process,
since students are left with the wrong impression that what they model is
correct." Ramollari and Dranidis (2007)
This was their motivation for building a new UML design tool called StudentUML
that would allow students to easily design UML diagrams and receive feedback on the
diagrams that were designed. While this project has not focused on building a backend
application to perform this analysis, validation and completion, it will still be important
to consider these topics when implementing the API so as to ensure that such tools can
be able to be easily integrated.
As this project looked at building an API between a UML display tool (UMLet) and
a backend tool, it was important to understand what would be required by the backend
tool. UML analysis is one of the applications in which the API that this project aimed to
develop would be extremely useful and this project thus aimed to facilitate such future
developments.
Much research has already been performed in the area of code completion, correction
and validation, but little research has been performed in the area of UML verification
and completion. On the rare occasion that these tools are implemented, they are usually
included as part of a specific software package.
2.5 Software Design Patterns
A common technique in software engineering is to use design patterns to solve common
problems that need to be repeatedly in projects. Source Making (nd) explains that:
"A design pattern is a general repeatable solution to a commonly occurring
problem in software design. A design pattern isn’t a finished design that can
Reg: 4784227
12
CMPC3P2Y
2 Literature Review
be transformed directly into code. It is a description or template for how to
solve a problem that can be used in many different situations."
Various design patterns exist that can prove useful when developing an API. The
following have selected for this project from amongst those explored:
2.5.1 Singleton design pattern
A singleton design pattern allows for a class which defines that only one instance of that
class can exist at a time.
In Java this implemented by first creating a static class variable inside of the class
implementing the singleton pattern. This field is used to store the single instance of
the class. The constructor of the singleton needs to assigned private visibility, meaning
that it is only executable from within itself. Finally a method with public visibility is
created to fetch the instance from the static field or create it if one does not yet exist. An
example of this can be seen in figure 2.1.
API
- apiInstance : API
- API()
+ getInstance() : API
Figure 2.1: The Singleton Design Pattern
The singleton pattern is thus well suited for use in an API.
Reg: 4784227
13
CMPC3P2Y
2 Literature Review
2.5.2 Facade Design Pattern
A class that implements a facade design pattern, defines a set of methods that can be
called to execute further functionality, of which the developer using the facade need
not know how the underlying functionality is implemented (See Figure 2.2). Tarr (nd)
further expands on this when he explains that a facade design pattern is used to:
• "To provide a simple interface to a complex subsystem. This interface is good
enough for most clients; more sophisticated clients can look beyond the facade".
• "To decouple the classes of the subsystem from its clients and other subsystems,
thereby promoting subsystem independence and portability".
Class
Class
Class
Facade
Class
Class
Class
Figure 2.2: The Facade Design Pattern
This is an ideal candidate pattern for creating an API, as changes in methods behind
the facade will rarely have any effect on code already using the facade.
Reg: 4784227
14
CMPC3P2Y
2 Literature Review
2.6 Software Methodology
The Waterfall software development methodology is one of the oldest and best known.
It is comprised of four main stages, Analysis, Design, Implementation and Testing. In
an ideal situation, each of these stages was designed to be performed only once for
each software development project and although stages can be returned to, this can be
costly. This means that the client for which the software was being developed would
be consulted at the beginning of the project, during the analysis stage, and asked for
all the requirements. This is the only stage at which the client has input and returning
to this stage becomes increasingly expensive as the project progresses through the next
stages. The clients requirements are then evaluated by the software development teams
and design decisions are made. After Implementation has been completed, the software
is thoroughly tested. This product is then delivered to the client. If a change does take
place then it could result in large delays, which in turn result in large costs to the client.
Given this it is important to note that the waterfall methodology is only really suited to
large mission critical applications. (Munassar and Govardhan, 2010)
Software methodologies that comprise of an iterative development model are designed to solve the inherent problems exhibited by the waterfall methodology. An
iterative development model keeps the same four steps as the waterfall model, while
repeating them many times throughout a project’s lifetime. Beck (1999)
Extreme programming (XP) is a methodology that follows the iterative software development model. When using XP, the customers and developers schedule a regular
release cycle and the developers only implement a small amount of functionality in the
current cycle, which they agree with the client at the beginning of the cycle. Beck (1999)
Agile methods, of which XP is one, also require a metaphor to be defined. A metaphor
is a communication tool that helps to easily explain the overall project, including it’s
goal and how the development should be structured (Tomayko and Herbsleb, 2003).
Tomayko and Herbsleb (2003) also explain that:
"Almost all agile methods explicitly cite “communication” as a key value.
This is meant to be communication about the software among the development team, as well as among and with the clients. The use of a metaphor is
a powerful tool to achieve this."
Reg: 4784227
15
CMPC3P2Y
3 Design of the Software System
Given that this is a relatively small project that was not being undertaken with a large
development team and did not require mission critical stability, an iterative development
model was followed. This was to also allow the project to adapt to requirements that
may become obvious during the implementation stages.
2.7 Event driven programming
Myers (1993) notes that reactive programming involves a new approach to software
design due to the software application not be in complete control. Instead a user will
perform a certain action that will trigger a certain action in the program to be run.
In this software system, the API was to be able to pass information about the UML
diagram being displayed in the user facing application, UMLet, straight to the backend applications, based on which actions the back-end applications have registered to
receive. This is therefore an event driven structure.
3 Design of the Software System
• UML is a constantly evolving language, with new functionality being frequently
added. It is thus important that the API be designed in an object oriented fashion
to ensure that future functionality can be quickly and easily integrated.
• The waterfall model was not suited to this kind of project. It was therefore important to use an iterative development model.
• A thorough inspection of the UMLet source code was an essential prerequisite to
be able to understand how to approach building an appropriate solution.
• The API was built as an Eclipse plugin. This was to allow the extension of UMLet
while also allowing backend tools to access the API’s functionality.
• The API was implemented in Java due to it’s object orientated approach. This
approach allows a UML diagram’s structure to be modelled and it’s contents to
be passed between the API and a backend application easily. Java also offered
cross-platform compatibility.
Reg: 4784227
16
CMPC3P2Y
3 Design of the Software System
• It was important to understand what functionality the backend tools would require
from the API. A detailed specification had to be produced to ensure a complete
implementation. This was provided as MoSCoW requirements table which can
be seen in Table 3.1.
• A key requirement of the project was to use Eclipse as a foundation. A major
element therefore, was to test at the outset to what extent UMLet would indeed
be a suitable application, having regard to the feasibility of developing an API, so
that it would work with other Eclipse plugins.
3.1 The Application Programming Interface
An API is a collection of functions that a program or service implements to allow other
applications to interact with the software system in a controlled and organised manner.
By having a defined set of functions that remain constant, developers can use them
without ever having to concern themselves about changes internal to the application,
even in cases where new functionality may eventually become available.
By implementing an API for UMLet, other applications will be able to interact with
it in a simple manner, notably to, for example:
• Fetch information about the diagrams available to them
• Read the content of any files that are open
• Perform actions, such as adding or removing objects to/from a diagram, etc.
An application’s developers will ensure that an API evolves in parallel with changes to
the application itself, but ensuring that earlier iterations continue to function as before.
Reg: 4784227
17
CMPC3P2Y
3 Design of the Software System
Table 3.1: MoSCOW analysis of project requirements
Priority
Requirement
must
Support exchange of data between UMLet and a backend client
must
Support UML Relation elements and the associated properties
must
Support UML Class elements and the associated properties
should
Use UMLet as a user facing application
should
Use the D-UEA-ST framework by Dr. Joost Noppen
should
Allow the API to reactively respond to user’s action
should
Allow for easy extensibility of element types
should
Implement an example plugin demonstrating the functionality of the noninteractive plugins in D-UEA-ST
could
Implement an example plugin demonstrating the functionality of interactive plugins in D-UEA-ST
could
Offer multi document support
could
Offer the possibility to prompt UMLet to create a new document
won’t
Implement a layout engine for deciding where to place new elements on a
canvas
won’t
Reg: 4784227
Implement detailed UML analysis
18
CMPC3P2Y
4 The Eclipse Environment
4 The Eclipse Environment
4.1 Exploration of Eclipse Plugin Extensibility
Having identified the Eclipse plugin architecture as a suitable candidate for the API to be
based upon during the initial research phase, further exploration needed to be performed
into how Eclipse allows plugins to communicate. The approach that was taken involved
creating a parent and a child plugin.
After having considered different possible techniques, it was decided that the parent
plugin should implement a method that returned a String object and that was contained
inside a Java package. Inside the build properties for the parent plugin, the Java package
was "exported", resulting in all other plugins in the eclipse environment having access
to the classes contained within it.
A child plugin was then created and it’s build properties set to declare a dependancy
on the parent plugin, so as to ensured that the parent plugin had already been loaded by
Eclipse as expected. A method was implemented inside the child plugin, to call upon
the method inside the parent plugin, fetching the String, and printing it to the debug
console. Finally this child plugin method was executed by the child plugin initialisation
code. The final resulting structure can be seen in Figure 4.1.
Parent Plugin
Exported
Package
Dependancy
Method Call
Child Plugin
Class
Figure 4.1: The Prototype Communication Structure
Reg: 4784227
19
CMPC3P2Y
4 The Eclipse Environment
4.2 The D-UEA-ST Eclipse Plugin
The D-UEA-ST framework is an Eclipse plugin written by Dr. Joost Noppen. It that
aims to allow plugins wishing to perform an analysis of data within a programming
environment, such as code analysis and diagram analysis, to use a common framework
to communicate with each other and share data.
It was decided that a reference implementation of this project would be implemented
within the D-UEA-ST plugin and some example plugins would be created inside of
D-UEA-ST to show the opportunities created by this projects API.
4.3 Initial API Implementation
Figure 4.2 shows how the result from the tests mentioned in figure 4.1 above, were
applied to the base implementation of the API. Within the UMLet source code, a new
Java package was created to house the API. A class called "API", that was to act as
a facade, was also created. A singleton design pattern was implemented inside the
API class, to ensure that only one instance of the API was ever created, regardless of
how many different back-end application access it. The UMLet build file was then
modified to export the API package and make it visible to other plugins in the Eclipse
environment.
Within the XML file in the D-UEA-ST plugin, a build and runtime dependancy was
declared on UMLet. This meant that Eclipse would ensure UMLet was always present
and loaded before then loading D-UEA-ST. A new package was created, inside of DUEA-ST, to contain all UML functionality. Inside this package a class called "UMLManager" was then created to act as a facade. This class was implemented as a singleton,
meaning that every plugin in D-UEA-ST would receive the same instance of the manager. By ensuring there is only one instance of the UMLManager, resource usage on the
user’s machine can be minimised by only holding one copy of the UML diagrams from
UMLet in memory.
Reg: 4784227
20
CMPC3P2Y
5 The UML Model
UMLet
com.umlet.api
API
- apiInstance : API
- API()
+ getInstance() : API
Dependency
getInstance()
D-UEA-ST
uk.uea.dueast.uml
UMLManager
- umletAPI : API
- fetcherInstance : UMLManager
- API()
+ getInstance() : API
Figure 4.2: The Base API Implementation
Reg: 4784227
21
CMPC3P2Y
5 The UML Model
5 The UML Model
5.1 Design
As a part of the reference implementation of the API within D-UEA-ST, a structure
of Java classes to model a UML diagram was created. A class was created for each
type of element that would appear, which in turn extended a class called UMLElement.
Functionality that was common to all elements, such as colour, was implemented in the
super-class, UMLElement, so that the implementation could then be shared with the
subclasses.
The UMLElement needed to be stored inside of a container that represented a document and so a class UMLDocument was created for this purpose. To ensure that a
UML document could always be uniquely identified, a String data member was added
to UMLDocument and was populated with the file path of the associated document in
UMLet. If in the future, a different client needed to be used with D-UEA-ST, this ID
could be set to any other String value that might be better suited in that particular situation.
A UML diagram showing the implementation of the model can be found in Figure
5.2.
Figure 5.1: D-UEA-ST UML Implementation
While relations in a UMLet diagram were already present in the form of UMLRela-
Reg: 4784227
22
CMPC3P2Y
5 The UML Model
Figure 5.2: The UMLModel Implementation
tion elements, they were not yet linked to any of the elements. To solve this issue, a
collection of references to UMLElementRelation objects that were attached to the element, were placed inside of each UMLElement. Two references, one to either end of a
relation were also placed in the UMLRelationElement class. These established the ability to traverse a whole UMLDocument, while only having the requirement of knowing
about one element.
Finally each element was assigned a reference to the UMLDocument in which it was
contained. This meant that the complete document could be retrieved from any element,
including the elements that might not have a reference attached to them.
Reg: 4784227
23
CMPC3P2Y
5 The UML Model
5.2 Population
Having constructed the structure for the UML model, functionality was then implemented into the UMLManager to populate it.
The UMLManager will populate documents in two circumstances:
• When the UMLManager is first initialised, it will request from UMLet, a list of
documents that are open in the current Eclipse workspace from UMLet.
• When the UMLManager receives a notification that a new document has been
opened inside of UMLet.
In both of the above cases, D-UEA-ST will proceed to create a new UMLDocument
before querying UMLet for a list of all the elements that currently exist in the document. The elements returned by UMLet are in the form of a Collection of GridElements
(UMLet’s internal storage for elements) that need to be looped through and converted
to UMLElements. These are then added to the previously created UMLDocument. The
resulting method was named "convertToUMLElement". As well as being responsible
for assigning all of the data to a UMLElement, the method first checked whether the
GridElement to be converted was of a type that had a specifically implemented UMLElement extension such as UMLClassElement or UMLRelationElement.
In it’s current form, UMLet does not in store it’s data model, a connection between
elements on the canvas and the relations between them, but instead relies on checking
wether the relations overlap the edge of elements. This was a particular consideration
when populating the UML model and different solutions had to be tried. In the end the
choice fell on harnessing the code used within UMLet when user’s move elements on
the canvas ("The Sticking Polygons").
5.3 Persisting Elements
The last feature implemented inside of the UML model was to allow any element that
has a document associated with it to be saved, simply by calling a save method. This
then allows an element to be distributed to any plugin in D-UEA-ST and for changes to
Reg: 4784227
24
CMPC3P2Y
6 The Reactive API
be made to it, without the plugin ever needing to require direct access to the UMLDocument class.
6 The Reactive API
6.0.1 The Notification Centres
To enable the API to be truly reactive, every time a element has changed inside of
UMLet, D-UEA-ST needed to be notified. A publish/subscribe design pattern, to be
referred to as the notification centre, was chosen to implement this functionality. The
reactive approach has the benefit that it allows actions performed by the user to be
relayed to D-UEA-ST in realtime and avoids the necessity to constantly poll the UMLet
layer of the API to check for changes, thus again reducing the burden on the system’s
resources.
This implementation resulted in there being one thread of control between UMLet
and D-UEA-ST and allowed some certainty that the UMLDocument would stay in synchronisation with the diagram on the UMLet canvas. A sequence diagram showing this
thread of execution is shown in Figure 6.1.
A second notification centre was implemented inside of D-UEA-ST allowing plugins
to subscribe to particular types of notification (element added, element remove, etc).
Support was also added for plugins to subscribe to notifications of a particular type
of a specific document. A sequence diagram showing the thread of execution for this
notification centre is shown in Figure 6.2.
Having implemented the notification centres, extensive testing needed to be performed. It was found during the first phase of testing that when actions inside UMLet
that should have caused new advice to be issued from D-UEA-ST occurred, no advice
was however displayed. This issue was later resolved by calling the method for updating
the table view inside D-UEA-ST, containing the advice, from the swing display thread.
A full class diagram should the structure of the implemented system can be seen
found in figure 6.3.
Reg: 4784227
25
Reg: 4784227
ELSE
IF n Begins with 'internal-'
recieveNotification(n,obj)
d-uea-st
UMLManager
recieveNotification(n2,obj2)
UMLet Notification
Center
fireNotification(n2, obj2)
UMLet API
recieveNotification(n,obj)
UMLet Notification
Center
fireNotification(n, obj)
UMLet Diagram
Command
CMPC3P2Y
6 The Reactive API
Figure 6.1: The Reactive Thread of Execution
26
Reg: 4784227
recieveNotification(n,obj)
recieveNotification(n,obj)
recieveNotification(n,obj)
d-uea-st Notification
Center
fireNotification(n,obj)
d-uea-st
UMLManager
recieveNotification(n,obj)
UMLet Notification
Center
d-uea-st Plugins
CMPC3P2Y
6 The Reactive API
Figure 6.2: The thread of execution for the D-UEA-ST notification center
27
CMPC3P2Y
6 The Reactive API
Figure 6.3: Class diagram showing the implementation of D-UEA-ST - For enlarged
copy see Annex 1.
Reg: 4784227
28
CMPC3P2Y
7 Proof of Concept D-UEA-ST Plugins
7 Proof of Concept D-UEA-ST Plugins
As D-UEA-ST is a framework on which many plugins can reside, two proof of concept
plugins were developed to test the functionality of both the API and the D-UEA-ST
implementation of the client. This was also to demonstrate the possibilities that the
platform offers.
7.1 The Name Checker Plugin
7.1.1 The First Implementation
The Name Checker Plugin was the first plugin that was written and it was designed to
scan through all elements in a document looking for a UMLRelationElement. Whenever
the plugin found a relation, it would check whether there was a name associated with
it and if not assign one. After having also changed the colour of any element without a
name, the plugin would then ask the UMLManager to update the element, in turn causing it be updated inside of UMLet. This plugin allowed the functionality to fetch and
modify elements, to be tested, as well as showing that using Java Object Introspection
inside of the UMLManager worked as expected.
7.1.2 Further Revisions
After having implemented the notification centre inside of D-UEA-ST, as documented
above and implemented after the plugin had initially written, some changes needed
to be made to the Name Checker Plugin to allow it to continue to function. These
changes included implementing a NotificationClient interface inside of the plugin and
subscribing to all "element-added" notifications. This resulted in the plugin being able to
inspect each element in a UMLDocument as it was added (element-added notifications
are sent for each element when D-UEA-ST is started).
7.2 The OMT Analyser Plugin
The OMT (object modelling technique) Analyser Plugin was developed to demonstrate
the ability of the API to handle plugins operating in an interactive mode within D-UEA-
Reg: 4784227
29
CMPC3P2Y
8 New UMLet Release and Multiple Document Support
ST. These plugins mainly allow the user to perform specific tasks that do not require
offering reactive feedback.
An initial implementation of the plugin, provided by Dr. Joost Noppen, that supported
using the Stanford Part of Speech (POS) Tagger (The Stanford Natural Language Processing Group, nd), allowed the software to find all the nouns in a text file corresponding
to a given specification. These where then displayed to the user and the user was given
the opportunity to remove any that he did not want appearing on the canvas.
This project took this implementation and added an ability to take the resulting nouns
and display them in a document of the user’s choice. The new elements would be placed
next to the shortest edge of the bounding box of the elements already present in the given
diagram.
8 New UMLet Release and Multiple Document Support
During this phase, a new release of UMLet was issued. As a result all previous phases
had to be revisited. This entailed verification of each phase, some major restructuring
and adaptation and renewed testing to ensure the compatibility with the changes resulting from the new release. This also generated the opportunity for a further enhancement
to be included, namely the incorporation of multi-document support. These change
mainly affected the API class and the UMLManager and demonstrated the clear value
of having used a facade design pattern as, in the end, a minimal amount code depending
on the UMLManager actually needed to be rewritten.
The value of the agile development methodology that was being used, also became
apparent, given the possibilities it offers to integrate changes, such as these, at a late
stage.
Reg: 4784227
30
CMPC3P2Y
9 Deliverables
9 Deliverables
9.1 Distribution
As certain elements of UMLet had been modified to allow the API to operate, a decision on how to make these changes available to users needed to be made. The follow
solutions were proposed:
1. A JAR file containing the plugin could be distributed. This would also be available
alongside D-UEA-ST for which a user should be instructed to install this version
of UMLet.
2. The source code of both UMLet and a patch file could be distributed to allow
users to compile their own version and to allow further use of the API in other
applications.
3. The UMLet developers could be contacted with a request to consider merging the
changes with the UMLet codebase.
The first and second solutions were chosen as an immediate solution. The JAR files
for the modified UMLet and D-UEA-ST, along with a patch file containing the change to
UMLet, can be found on the accompanying CD-ROM. It was also decided that perhaps
in the future the UMLet developers should contacted.
9.2 Documentation
A detailed documentation has been provided to accompany the codebase. This consists
of comments in the source code as well as the documented design and implementation
in this report.
10 Future Development
The project identified many possible avenues for further future development. These
include:
Reg: 4784227
31
CMPC3P2Y
11 Conclusion
• Extending the element support of the UMLManager to include the elements associated with sequence diagrams.
• Developing a transaction mechanism that would apply to all elements inside a
UMLDocument. This would allow multiple plugins to stage changes to document
and then later commit them to the document when they are complete. This could
also integrate a locking mechanism where only one plugin could commit to a
document at a time.
• Support for creating and opening a new document could exist as part of the API.
This would allow an interactive plug to request that a new document be created
and for the user to be prompted where to save it before moving on.
• Limit the number of notifications sent when, for example, a user is moving an
element across the UMLet canvas.
11 Conclusion
– The project demonstrated that it was feasible to build a reactive API based on
both Eclipse and UMLet. Furthermore the project explored the optimal manner
in which, amongst other things, to communicate between Eclipse plugins.
– Various ways of modelling UML diagrams in an object orient programming language, such as Java, were considered. Diverse challenges were identified and
overcome in developing this API, such as fetching the relations from UMLet.
– The project demonstrated how unexpected changes to the base application could
be successfully incorporated, without deviating from time schedule. This also
demonstrated the value of using certain software engineering design patterns.
– Overall the project resulted in the development, testing, deployment of a working
model API.
Reg: 4784227
32
CMPC3P2Y
11 Conclusion
Personal Project Evaluation and Reflections
This project was chosen because of the multiple opportunities that it offered to explore
new concepts, work on a real practical software project that had an actual envisaged
outcome and use, deal with real challenges and seek to find sound working responses to
them.
The value of regular meetings and meaningful communication with the software
client (project supervisor) became increasingly evident as the project progressed, particularly when the nature of one of the given parameters (UMLet), changed unexpectedly
and significantly.
Deep insights were provided into the value of sound software engineering principles
such as the use of reusable techniques such as design patterns as well as the use of an
agile development cycle.
The concepts explored and employed, allowed the acquisition of sound working
methods and valuable transferable skills.
Given the evolutionary nature of software, the project underlined how things have to
continuously adapt and progress. It proved a most enjoyable and satisfying piece of
work and is considered to offer a sound foundation to build upon in the future.
Reg: 4784227
33
CMPC3P2Y
References
References
Beck, K. (1999). Embracing change with extreme programming. Computer, 32(10):70
–77.
Csertan, G., Huszerl, G., Majzik, I., Pap, Z., Pataricza, A., and Varro, D. (2002). Viatra
- visual automated transformations for formal verification and validation of uml models. In Automated Software Engineering, 2002. Proceedings. ASE 2002. 17th IEEE
International Conference on, pages 267 – 270.
Group, O. M. (2010). Omg unified modeling languagetm (omg uml), infrastructure,
version 2.3. Technical report.
Munassar, N. and Govardhan, A. (2010). A comparison between five models of software
engineering. IJCSI International Journal of Computer Science Issues, 7(5):94–101.
Myers, B. (1993). Why are human-computer interfaces difficult to design and implement. Technical report, DTIC Document.
Oracle (n.d.). The java hotspot performance engine architecture. http://www.
oracle.com/technetwork/java/whitepaper-135217.html.
Ac-
cessed: April 2013.
Ramollari, E. and Dranidis, D. (2007). Studentuml: An educational tool supporting
object-oriented analysis and design. In Proceedings of the 11th Panhellenic Conference on Informatics (PCI 2007), pages 363–373.
Rivieres, J. and Wiegand, J. (2004). Eclipse: A platform for integrating development
tools. IBM Systems Journal, 43(2):371 –383.
Source Making (n.d.). Design patterns - simply. http://sourcemaking.com/
design_patterns. Accessed: April 2013.
Storkel, S. (2002). An introduction to the eclipse ide. http://www.onjava.com/
pub/a/onjava/2002/12/11/eclipse.html. Accessed: April 2013.
Reg: 4784227
34
CMPC3P2Y
References
Tarr, B. (n.d.). The facade pattern. http://userpages.umbc.edu/~tarr/dp/
lectures/Facade.pdf. Accessed: April 2013.
The Eclipse Foundation (n.d.). Eclipse - the eclipse foundation open source community
website. http://eclipse.org/. Accessed: October 2012.
The Stanford Natural Language Processing Group (n.d.). Stanford log-linear part-ofspeech tagger. http://nlp.stanford.edu/software/tagger.shtml.
Accessed: April 2013.
Tomayko, J. and Herbsleb, J. (2003). How useful is the metaphor component of agile
methods?: a preliminary study.
UMLet Project (n.d.). Uml tool for fast uml diagrams. http://www.umlet.com/.
Accessed: October 2012.
Reg: 4784227
35
CMPC3P2Y
References
Annex 1
Figure 11.1: Enlarged version of Class diagram (Figure 6.3) - Part 1
Reg: 4784227
36
CMPC3P2Y
References
Figure 11.2: Enlarged version of Class diagram (Figure 6.3) - Part 2
Reg: 4784227
37
CMPC3P2Y
References
Notes
Reg: 4784227
38