Introduction

Well-established academic disciplines emerged from practices without focusing on the underlying theory[1]. In time, however, general and advanced scientific theories have been developed as they are essential for the advancement of scientific fields [2]. Software engineering is notably a young discipline [3]. As such, it is not yet overly concerned with a core, general theory; thus, the risk is to be limited to trial-and-error practices[4]. A lack of theoretical foundation inhibits the growth of a research tradition. A research tradition is essential to secure scientific beliefs but also to cause paradigm shifts [2]. Software engineering is missing such tradition. Software engineering suffers from gaps in the knowledge for understanding software development processes and their impact on each other [5].

The SEMAT initiative was born in order to “support a process to refound software engineering based on a solid theory, proven principles and best practices. […][What will enable this is a] kernel of widely-agreed elements [...] supported by industry, academia, researchers and users” [6]. The outcome of the SEMAT initiative is the Essence Theory of Software Engineering [7][8]. Strictly speaking, Essence documents the “things to work with” in software engineering [8], the relationship they have with each other, and the actions that involve such “things”.

Essence is claimed to provide a common basis for defining software development practices, by using widely agreed elements that are present in every software engineering endeavor [8]. These elements are called Alphas. As of today, the core Alphas of Essence kernel are Opportunity, Stakeholders, Requirements, Software System, Work, Team, and Way-of-working. Alphas change in their States, thus enabling a representation of the progress and health of the endeavor. For example, the Requirements can be Conceived, Bounded, Coherent, Acceptable, Addressed, or Fulfilled. Finally, Essence Alphas are organized in three areas of Concern. Each Concern focuses on a single aspect of software engineering. They are called Customer, Solution, and Endeavor. As opposed to other attempts to create a general theory of software engineering – e.g. the Software Engineering Body of Knowledge [9] – Essence aims to generalize software engineering by identifying its universal elements and actions, and to develop a universal language to describe them. The theory was submitted to the Object Management Group (OMG) and is currently undergoing the necessary steps to become an OMG standard [8]. A simple introduction to Essence is available in the material of a special lecture held at the Free University of Bozen-Bolzano by one of the authors of this paper [10].

As of today, there is a lack of consensus of Essence as an accepted model. For example, notable practitioners and researchers of Agile methodologies expressed negative comments on the SEMAT initiative (e.g., [11][12][13]). Reasons include a difficulty to see Essence’s utilization potential and a lack of tools for implementation. It is challenging to understand Essence before even evaluating it. As software engineering heavily relies on empirical research [14], there is the need to produce the empirical data when applying Essence, in order to understand its theoretical and practical implications and to evaluate it scientifically.

This paper describes the SEMAT Accelerator (SematAcc), which is a Web-based modeling system for software engineering processes as depicted by the SEMAT’s Essence kernel. SematAcc has been developed as a way to produce such needed empirical data for evaluating Essence. It helps in using and understanding the Essence theory under a practical viewpoint. SematAcc lets users model a software development process with Essence elements. A software engineering endeavor (called project in SematAcc) has an associated Essence kernel. The kernel has been implemented using the OMG submission of Essence [8] as a reference. A software engineering endeavor is represented using graphs of the Concerns’ and Alphas’ completions.

SematAcc is developed in JavaScript both on the client side and on the server side, on top of the recently born Meteor [15]. Meteor is an open-source platform to build JavaScript-based Web applications. By providing a nearly identical API for the development of the server and the client, Meteor target is to deliver almost real-time data transfer through latency compensation techniques and reactive programming.

SematAcc can be employed in empirical experiments and case studies on Essence theory because it registers the events triggered by its usage. The events can be easily downloaded as a CSV string. Thus, they are directly employable in statistical software.

The rest of this paper is organized as follows. The next section - Implementation and Architecture - provides a brief introduction to Meteor, an illustrated guide on how to use SematAcc main functionality, and more technical details on the architecture of the system and the source-code organization. It is followed by a section regarding the Quality Control of the system, where the tests and the techniques in order to ensure a high quality of the delivered software are provided. In the Availability section, details on SematAcc system requirements and dependencies are given, as well as the information on how to obtain the software. The last section - Reuse Potential - provides an overview on how to configure and run SematAcc on a local computer and on a remote server and suggestions on how to employ the software for research purposes.

Implementation/architecture

SematAcc was implemented using the recent Meteor project [15]. Meteor is an open-source platform and framework to build JavaScript-based Web applications. It is built upon the server-side JavaScript enabling technology Node.js [16] and the NoSQL document-oriented MongoDB database [17]. As a programming framework, Meteor permits developers to write both client- and server-side applications using almost the same JavaScript APIs. Its aim is to achieve nearly real-time performance by providing latency compensation for data transfers between the server and clients (and vice versa). Data is the central point of Meteor. It is organized in data structure named collections. Meteor collections are convenient wrappers around MongoDB documents; they provide the basic create, read, update, and delete operations needed for the functionality of a Web application.

Meteor has been inspired by the reactive programming paradigm [18]: nearly all of its layers, from database access to graphical user interface (GUI), provide an event-driven interface whose operations run whenever the underlying data-dependencies change. For example, a hypothetical Meteor Web application is developed to manage a library. A template of the GUI of the application is responsible to render a list of books. A user observes a Web page with a list of books. Meanwhile, an editor inserts a new book in the database, from the application backend. The change in the data is detected by Meteor components, which automatically trigger a re-render of the GUI element interested by this operation. The user simply sees a new element added to the list, without a Web page refresh.

As an infrastructure, Meteor covers development, testing, and production phases to run the implemented source-code. For development, Meteor provides a local server, built on top of Node.js [16], to run the developed Website and perform tests. For testing and production, Meteor provides a freely available infrastructure of servers. More information on Meteor can be obtained on the official Website [15], in the introductory screencast [19], and on the documentation Website [20].

Before illustrating some details regarding SematAcc architecture, a brief introduction on using SematAcc is provided. Upon login, the user manages the projects (Fig. 1). The Hint Box on the left side of the screen contains suggestions, which help the user to manage the projects. The central box lists the available projects. After the user creates a project, putting the mouse over it, it will activate the available commands. A click on the arrow icon will accelerate a project with SematAcc (that is, it will start the modeling activity with Essence kernel). The other two commands are for editing a project and for deleting it.

When the user decides to accelerate a project with SematAcc, the Essence kernel is loaded with the chosen project (Fig. 2). This is the main functionality of SematAcc. The user interface is divided in three parts. The first part, on the left, is the already mentioned Hint Box, which reports information on an Alpha or a State, depending on the position of the mouse. The second part, on the center, is Essence kernel. It shows the Alphas. If the user clicks on an Alpha, the Kernel expands and shows the corresponding States. The third part, on the right, is the project status. It displays a rose graph and a horizontal bar chart. The rose graph represents the project status in terms of Alphas’ completions, whereas the horizontal bar chart provides an overview of the Concerns’ completion.

When a user clicks on a State, thus expressing a change of State of an Alpha, the graphs are immediately updated. For example, in Fig. 3), the user chooses that Requirements Alpha is now in the Conceived State. The rose graphs and the horizontal bar chart on the right side of Fig. 3 represent the change in the State of an Alpha, and the completion of the project is shown.

The models of SematAcc derive from an analysis of the Essence theory. They are represented in the class diagram of Fig.4.

A user of the system possesses one-to-many projects. Each project has an associated Essence kernel. In SematAcc, the kernel is a graphical conceptualization and does not have a corresponding database collection. Although a kernel may have one-to-many Concerns, the current OMG standard proposal suggests three of them: “Customer”, “Solution”, and “Endeavor”. The three Concerns contain the corresponding Alphas. Alphas have several associated States but may be in zero or one-and-only-one State.

Each Concern, Alpha, and State has a corresponding name and description taken from Essence OMG submission. In order to speed-up the Essence learning process, the descriptions of kernel elements appear in SematAcc as soon as the user hovers with the mouse over them.

Concerns and Alphas also possess a completion, represented as a JavaScript Number. This number represents the percentage of completion of such kernel elements. For an Alphas completion, the order of the current Alpha State is employed. Then, the completion of the Alphas determines the progress of the project in terms of Concerns completion.

Finally, each project possesses events, which are employed by SematAcc to log and generate data for research purposes.

A high-level view of the most important functionality of SematAcc is represented in Fig. 5.

In the example provided in Fig. 3, the user decides that the “Requirements” are now “conceived”. A mouse click on the “conceived” State in the user interface triggers an update to the server’s Alpha collection. Upon a successful update in the database, the completion ratios for the Concerns and the Alphas are recalculated in order to keep the data consistent. Then, the client component of SematAcc is notified of the successful change of State operation. A relevant event is generated and stored. Finally, the graphs are updated to represent the new data. At this stage, SematAcc GUI shows what is represented in Fig. 3.

The project source-code is organized by separation of concerns. The project’s root directory contains three main parts, according to Meteor conventions. In the client folder, there is the code executed by the client (the Web browser). In the server folder lives the source-code, which is purely executed on the server side. The tests folder hosts the automated tests written with the Laika framework [21]. The public folder stores all the binary files publicly accessible – e.g., pictures. All the source-code files are commented. For more information regarding the project structure, we advise to read the README file in SematAcc source-code. The file also contains instructions on how to run SematAcc on a development machine and how to have an own private instance of SematAcc on Meteor’s free servers.

Quality Control

Different levels of testing have been performed. Eight volunteers were involved to perform user-acceptance tests of the software. Three of them are experts of Essence. The remaining five are experts in the field of software engineering but needed an introduction to Essence theory. Their involvement persisted up to the first public release of SematAcc. Their feedback influenced the development of Essence, especially of its GUI.

Before a public release, SematAcc is manually tested with the latest versions of the leading browsers (i.e., Mozilla Firefox, Google Chrome, Microsoft Internet Explorer, and Apple Safari).

An official automated testing method does not exist for Meteor yet [22]. However, community-based tools are under active development. SematAcc employs the recently born Laika [21], a feature rich testing framework for Meteor, which simulates the interaction between the server and clients. The tests are run before each commit to the version control system. In order to run the tests, the Laika framework has to be installed on the system. More information on how to run the test cases can be found in the TESTING.md file in SematAcc root directory.

Lastly, each SematAcc function has been carefully debugged. Formal inspections of the database content revealed consistent data values after the software trials. The JavaScript code adheres to standard coding conventions and passes all JS Hint tests [23].

Operating system

Server-side: SematAcc works wherever Meteor works. Official support [24] is offered for:

• Mac OS X 10.6 and above
• GNU/Linux x86 and x86_64

Client-side: any operating system, which runs a recent Web-browser.

Programming Language

HTML, CSS, and JavaScript over Meteor framework v0.6.4.

Additional system requirements

A minimum resource requirement is the ability to run the Meteor framework, i.e. Node.js [16] and MongoDB [17].

In a GNU/Linux development machine, the memory map of the processes, gathered with the pmapcommand, was of 295.02Mb.

SematAcc source code occupies about 1Mb of disk space.

Dependencies

Meteor v0.6.4 [15].

List of contributors

1. Daniel Graziotin (Project Development)
2. Pekka Abrahamsson (Project Manager)

Archive

Code repository

Language

English