During 14 years of developing an open source model driven engineering tool at a university we collected some dos and don'ts for such projects, which we are going to describe in this paper. For example, the mentoring of students and afterwards the integration of their results need special treatments, to be able to keep a product of high quality. Beside such quality related issues, we also report on our experience with industrial cooperations. To get an idea about the amount of work that has been put into our tool, we review and visualize its history.
In this paper, we report about the history of an open source software (OSS) tool
used in the context of model driven engineering (MDE). Started as an
implementation to validate formal semantics of the Object Constraint Language (OCL)
that was de ned in a doctoral thesis [
In this paper, we highlight some of the key extension that were made to USE during its 14 years of development. Due to the origin of USE as a research project, we further highlight some of the speci c characteristics that apply to open source projects at universities, e. g., experience with work of students.
The rest of the paper is structured as follows: In Sect. 2 we show the di erent areas in which USE can be applied. In Section 3 we rst describe the historical development of USE, followed by pointing out some key extensions. The section ends with di erent thoughts on key success factors. After taking a look to similar OSS tools published by working groups at universities in Sect. 4 we conclude.
The main application of USE is to validate and verify UML models. These models
are typically used during early stages of the software development process and
focus on key parts of the designed system. This allows to exclude errors in the
design at the very beginning. As it is commonly reported, e. g. in [
The most basic validation feature of USE is the static instantiation of a model. By this, we mean the creation of a system state without any dynamic behavior. In USE a system state consists of objects with their attribute values and links between them. Using such a state, a user can verify assumptions about the static speci cation, e. g., multiplicity, subsets, union, and rede nes constraints. Further, it can be veri ed whether invariants are excluding the right states. The creation of system states can be done in various ways. For exploration of a model, the user can create objects and links in an ad hoc manner by using the graphical user interface (GUI). This is especially useful for bigger models, as the GUI can guide the user. For example, USE only shows commands for creating links between selected objects for which valid associations exists. To create and reproduce system states and to simulate dynamic behavior USE supports the execution of a command language. During simulation, speci ed pre- and postconditions of operations as well as transitions of state machines are validated. 2.2
During our lectures about the design of information systems, we have successfully employed USE for more than 10 years now. One advantage of USE for education is the possibility to learn UML and OCL in an interactive way. Students can easily try di erent designs and get a rapid response about its correctness. For example, its fairly easy to create system states by dragging object instances and linking them to check de ned constraints on the y. Since USE can directly provide feedback about the current state of each constraint, one can immediately see, if the constraints are correct. This can be done by creating valid and invalid instantiations and by comparing the result of the evaluation of USE to the developer's expectations. To a given extent, the possibility to completely de ne models in a declarative way together with the option to simulate scenarios fosters the ability to prescind. 2.3
The integration of USE as a component into other products is supported by
its two-level architecture. The user interface is decoupled from the system core,
which allows other applications to easily integrate the UML and OCL validation
capabilities of USE. This integration can be done in two di erent ways.
Products can either implement interfaces required by the USE system or they can
map their own implementations to USE instances. While the former approach
reduces the memory consumption at runtime, because no additional instances
need to be created, the implementation is more time consuming. Whereas,
using the mapping approach reverts those pros and cons. Mapping application
speci c instances to USE concepts is supported by a recently added simpli ed
application programming interface (API). In fact, it is an implementation of
the facade pattern, which reduces the learning time for integrating USE as a
library since internal details are hidden behind the facade. An example of an
application, which integrates USE as a component is the so-called XGenerator.
This model-to-text transformer is used in the context of de ning data exchange
standards for the German public authority [
In this section we are going to take a brief tour through the history of USE. We highlight milestones and relate them to some metrics.
To get an overall impression on how the structure of USE has changed over
the past 14 years of development Fig. 1 and 2 visualize the internal structure of
USE as a city map [
Figure 1 shows the city map of version 0.9.0 which was released in May 2000. This rst version was build out of 489 classes spread over 27 packages with a total number of roughly 15,000 lines of code (LOC). The city map of the current development version of USE 3.1.0 is depicted in Fig. 2. As one can see, the city shape changed heavily over the last 14 years1. One example is the downtown district representing the GUI related classes that can be seen at the south of the city (see also Fig. 3). While the rst versions of USE focused on the implementation of OCL (the eastern part of the city), little work was done on the graphical user interface. This changed over the versions, until the previously empty district was lled with GUI related classes. The currently not yet released version of USE (3.1.0) now contains some 86,000 LOC and nearly 1,600 classes distributed over 92 packages. 1 An animation of the city maps of all released versions of USE can be found online: http://www.db.informatik.uni-bremen.de/projects/use/CodeCity.gif
Plug in support
State Machines Communication Diagram
SOIL
Generator
LOC (1000)
NOC (10)
NOP
0.9.0 1.0.0 1.1.0 1.2.0 1.3.0 1.4.0 1.5.0 2.0.1 2.1.0 2.2.0 2.3.0 2.3.1 2.4.0 2.5.0 2.6.1 2.6.2 3.0.0 3.0.1 3.0.3 3.1.0
Ver. 0.9.0 - 2.0.1: OCL Core Through the years 2000 and 20012 the
development of USE concentrated on the OCL core language up to version 1.4
of OCL. In parallel, a formal basis of OCL was developed and published as
a doctoral thesis [
Ver. 2.2.0: Generator A rst veri cation feature was added in 2005. This
generator allows to search for model instances using a language called ASSL
(A Snapshot Sequence Language) [
are described. Note that the plugins do not count to either the city map or the statistics in Fig. 4.
Ver. 3.0.0: SOIL The foundation of another milestone of USE was de ned
formally by a doctoral thesis [
ity improvements, the current version of USE (2014), which is available as a
preview, added support for de ning and validating UML protocol state
machines with full OCL support [
Plug-in: Monitor To apply USE for runtime veri cation, that is to verify
a concrete implementation relative to its speci cation, the so-called
USEMonitor can be applied [
In this section we are going to describe what factors of success are, from our experience, required to build and maintain a successful open source MDE tool. We have split these factors into three groups, each covering di erent aspects of a long-term OSS development.
Technical One of the most crucial factors is, in our opinion, to provide a sound system. This means, it should be easy to set up, to execute, and to use. Not to forget, it should be as stable as possible. To get and to keep a stable system, a leading architect who keeps an eye on the overall structure is essential. In the best case, this architect is something like a geek 3. For our project, we can state that during the time there was someone in our working group who could be seen as a geek, the project made quantitative and qualitative progress, whereas if no such person was present, the development was nearly stuck.
On a technical level, tests are even more essential to get and keep a product of high quality. For USE, we run about 700 unit tests and over 120 di erent regression tests each time someone is committing changes into the source control system. Overall they compare nearly 1,200 expressions against expected results and execute more than 28,000 statements. Running all tests after each commit and notifying the development team about failed tests, like we do using a continuous integration server, further motivates the developers to x errors as soon as they are encountered, which bene ts the overall stability.
To improve the productivity of the development process and to reduce the
likelihood of errors, it is a best practice to look for popular and active open
source libraries as to built-up your system with. However, each new library
introduces the burden of keeping an eye on new versions and even more
important, it needs to be checked if the license of the component is compatible
to the one under the own product is published. Because many open source
licenses exist, each forcing di erent requirements and granting di erent rights,
this is not a trivial task [
Organizational Although, USE is developed and maintained at a non commercial organization, economics play a role. To be able to increase the e ort put into the project, it is quite a good idea to get an industrial partner who is in the need for the current or future product and supports the work nancially. We made good experience even with long term cooperations. However, for research tools, one must be careful not to get into the role of a service provider. In other words, ongoing research and not only the maintenance of a product for the cooperation partner should be the goal.
Community and Feedback Even if software is open source, this does not mean you got a community of developers4. Therefore, by community we mean active users of our software. These can be modelers, who apply USE to gain information about their models, educators and students, who utilize it during lectures or researchers integrating USE as a component into their own tool.
For USE, we see two facts why it has reached such a high acceptance for research and industrial projects. First, publishing ongoing work at relevant conferences. Second, cooperations between our working group and commer3 For an exiting view on geeks we kindly refer to question six from Twenty Questions for Donald Knuth (http://www.informit.com/articles/article.aspx?p= 2213858, May 20, 2014) 4 c. f. http://readwrite.com/2014/07/07/open-source-software-pros-cons cial companies, like the integration of USE into the XGenerator as described earlier.
Regardless of the audience and as with commercial software, a profound support must be available. For our project, we run a discussion forum and a bugtracker at our project side on SourceForge5. Further, we provide information how to contact the developers in case of problems. For all of them, we try to keep response times low.
Nevertheless, publishing a tool as open source, even if no active developer community can be created, one can gain the bene t of receiving patches for issues found by users. While this is not the most common case, sometimes interested users already debug issues and propose xes for them. Another successful way how we collected feedback about new features and their value and usability was the usage of USE during lectures at university. The view of students as (usually) unexperienced users can help to identify possible usability issues, but can also guide the direction of development, i. e., whether it is worth to continue the work on a feature. 3.3
As we showed previously, some extensions to USE were made by students. Either for their diploma thesis, while participating in a collegiate project, which is mandatory at University of Bremen, or while working as a student assistant. As in the economy, the productivity and more importantly the quality of their work extremely di ers. For many students, their thesis project is the rst time they need to implement a bigger software component. These students need a well-delimited topic to work on and usually a more time consuming mentoring to achieve a good result. A kick-o meeting, introducing the topic and to give a rst insight of the relevant part of the system should be obligatory. When accompanying them during their time of writing their thesis, one often gets usable results. However, the lack of experience often leads to working but poorly maintainable code. The usage of a best practice guide can help to improve the code quality, but commonly one has to refactor certain parts of the produced results. For USE, we started to create such a best practice guide, since we noticed recurring bad smells.
One example of such bad smell is the tendency of students to extract information out of strings (if you are lucky they won't use the identity comparator (==) to check equality of strings). This leads to issues hard to identify if later on string representations change. While the wrong usage of the identity comparator on strings in Java can automatically be discovered by tools such as FindBugs6, the extraction of information out of strings cannot. For this, we tell students: \if you start to write something like aString.indexOf(something): rethink!".
Another point, that is worth noticing, is that unexperienced students have fun reinventing the wheel. It seems to be a pleasure implementing all the cool 5 http://www.sourceforge.net/projects/useocl 6 http://findbugs.sourceforge.net algorithms for sorting and searching learned during their study. Unfortunately, most of the times these algorithms either contain bugs or do not perform well. For this, at the beginning of their work a hint at already used libraries reduces the likelihood of the tenth sorting algorithm in the source code.
Last but not least, students should be encouraged { if not forced { to write tests containing more than tiny amounts of data. Otherwise the main developers of the extended system are going to spend a lot of time resolving bottlenecks. 4
Several long running open source MDE tools exist. Unfortunately, we can
highlight only two of them, because of space restrictions. Dresden OCL [
The Alloy Analyzer8 uses the Alloy language [
In this work we have shown, how an open source MDE tool that was the outcome of a single doctoral thesis emerged over more than 14 years of development. We described key extensions that were made by university members and discussed factors for the development that are in our view important for a successful longterm evolution of an open source tool. An anecdotal list of issues we encountered while integrating extensions made by students and the proposed best-practice guide, can help projects to receive better results when unexperienced developers are possibly temporarily working on a project.
Acknowledgments We would like to thank all the people who have contributed to USE over the years. In particular: Fabian Buttner, Mirco Kuhlmann, Mark Richters; Roman Asendorf, Jorn Bohling, Jens Bruning, Torsten Humann, and Hendrik Reitmann 7 http://www.dresden-ocl.org 8 http://alloy.mit.edu/alloy/index.html