DTU 
 
 

Advanced Topics in Software Engineering (f15): Project proposals

A major part of the course Advanced Topics of Software Engineering (02265) is a project, and the evaluation of the project will be based on this project. The students will work on this project in groups of 2 to 4 students.

 

On this page, there are different project proposals that will use the concepts and technologies taught in this course. Each group of students can select one of these projects. More details on these projects will be presented in the first week of the course.

 

On this page you find the proposals for project for the spring semester 2015. Most of the proposed projects are in the context of existing tools, which are implemented in a a model-based way using some of the technolgies presented in this course: the ePNK, a generic tool for Petri nets (see ePNK Home Page) and the ECNO Tool (see ECNO Home Page).

 

Note that these projects and the ePNK and the ECNO Tool will be explained in much more detail and discussed during the first weeks of this course. Anyway, you will find a brief introduction to the ePNK and ECNO below, before the 4 possible projects are presented.

 
The ePNK
The Petri Net Markup Language (PNML) is an XML based interchange format for all kinds of Petri nets, which is standardized as ISO/IEC 15909-2 (and some extensions in ISO/IEC 15909-3). Different kinds of Petri net types can, basically, be defined by providing a UML model with the type's specific features.

 

The ePNK (eclipse-based Petri Net Kernel) is a tool based on Eclipse that is fully compliant with ISO/IEC-15909-2 and serves as a test-bed for the definition of ISO/IEC-15909-3. It provides a generic graphical editor to which new Petri net types can be plugged-in — basically, by providing a UML model of its concepts. The ePNK was developped in a model-based way, using the Eclipse Modeling Framework (EMF), the Graphical Modeling Framework (GMF), and XText and some related technologies.

 

For installing Eclipse in the correct configuration, and the correct version of the ePNK and some of the other prerequisites see http://www2.compute.dtu.dk/courses/02265/f15/project/eclipse-installation.shtml.

 
The ECNO
The Event Coordination Notation (ECNO) is a notation to coordinate the behaviour among related model elements that are defined in structural diagrams such as class diagrams. The ECNO allows the definition of events and provides means for defining how different related model events need to join or participate in the execution of these events: an interaction.

 

The local behaviour of each element defines, in which events an element could participate, which parameters are contributed, and which action is executed once an interaction is established and executed. In this project, the behaviour of each element is defined by ECNO nets (which are implemented based on the ePNK).

 

You will find more information on the ECNO on the ECNO Home Page. The ECNO Tool can be installed together with the ePNK and requires the same confguration of Eclipse (see http://www2.compute.dtu.dk/courses/02265/f15/project/eclipse-installation.shtml).

 
The projects
 
1. An editor for a network of hierarchical module definitions

Context

Often, software models are defined in a hierarchical way: first, defining some basic modules which then are used to define more and more complex modules. The modules have typically some interfaces consisting of ports, which can be used to connect different instances of modules for defining new ones.

 

Task

The task of this project is to implement a basic mechanism for definining such modules and use them for defining more complex ones, which can be located in several different files. A prototype of a graphical editor should be implemented (e.g. based on EMF and GFM), in which a complex module can be shown and where one can "zoom" interactively deeper into the definition in order to see the complete hierarchy of the model (navigating between different files without being aware of that).

 

Scope

The focus of this project to study technologies for building such a hierarchical editor for models. It is important that the modules can be built up hierarchically over several levels and the editor can unfold and show several levels at a time in a single graphical model. The module concepts as such and how modules can be connected and combined via connecting the ports can be very simple — basically some graphs connecting some ports.

 

Additional information:

This project is inspired by a project proposed by Oticon, and it could lead up to a masters project in cooperation with Oticon (after the summer holidays). See Oticon's project descriptions and zip file with additional material.

 
2. A component model for defining formal models

Context

Formal models such as Petri nets can be used for formally verifying that a system fulfills some requirements (for example described in a temporal logic). The problem, however, is that modelling a large system as a Petri net is tedious and not always easy for people without Petri net experience. One solution for this problem is to define typical components of some application domain as a Petri net, and then to build the system in this domain just bycombining these components.

 

Task

The task of this project is to provide a means to define some basic Petri net components and an editor for combining these components. From the definition of these Petri net components, and model that connects such components, the tool should automatically generate the Petri net of the system and then do some simple form of analyis or verification on the generated Petri net.

 

Scope

The Petri net modules can be defined using the ePNK (with a Petri net type defined for that purpose), and a simple graphical editor for combining the components should be defined. In this project, hierarchical component definitions are not required; the important functionality is that the complete Petri net can be generated from the components definitions and the model combining them; on the generated Petri net some simple analyis or verification should be possible.

 

Additional information:

This is a very much simplified version of Component Tools [see Component Tools: A vision of a tool].

 
3. A GUI modelling language for ECNO Applications

Context

The Event Coordination Notation (ECNO) is a notation for modelling a system including the structure as well as the behaviour of the system. From such ECNO models, the software can be generated fully automatically. The generated software will be equipped with a simple GUI, that allows the end-user to see which elements can execute an event, and allows the end-user to trigger the respective events and interactions. This GUI, however, is very simple and, in particular, does not allow the end-user to define input (parameters) to the event. For more sophisticated GUIs of ECNO models, the GUI needs to be programmed manually using an API and programming framework that is part of the ECNO. Since the goal of ECNO is to model software instead of programming it, if also the GUI of an ECNO GUI could be modelled.

 

Task

The task of this project is to design a simple language that defines the GUI for a system modelled in ECNO. This GUI modelling language should defined which elements and events should be shown to the end-user, and in which way the end-user can interact with it. In particular, it should be possible to define which parameters (of which type) the end-user should be able to see, and to change himself. There should be a (generic) GUI that can be registered with the ECNO engine and will then interact with the end-user in the way described by the GUI configuration language.

 

Scope

The GUI language should be flexible enough so that it can be used for different kinds of applications. It, should at least support the features needed for modelling the GUI of the case-handling, which will be discussed during the tutorials. The implementation of the GUI itself, does not need to be fancy, but should implement all features of the GUI modelling language. The GUI configuration mechanism should be demonstrated with at least one example (which could be the case handling-system discussed in the tutorials).

 

Additional information:

It might help to read Chapter 1 and Section 5.5.2 of the ECNO: Documentation as background information. For the workers example (discussed in Section 1.1) the notations developed in this project should be able to define a GUI similar to the one discussed in Section 5.5.2 (but this was programmed using the ECNO API).

 

 
4. Flexible data collection with smart phones

Context

In many scientifc projects today, data need to be collected automatically, semi-automatically or fully automatically via smart phones. For example, there can be recurrent questionnaires on the dietary behaviour of citizens and their wellbeing, follow-up queries in health care, or studies of transportation habits. Part of the collected data could be provided by direct user input, others data could come from the smart phone’s sensors (location, body temperature, heart rate). Even though, implementing such data collection applications (apps) for modern smart phones has become quite simple with today's technologies, maintaining them in the long run, updating the apps, and making them available on different platforms is time consuming and costly.

 

Task

In this task, a simple language for defining surveys in a general and flexible way should be designed. Then, an app should be implemented, which equipped with such a definition of a survey conducts the survey. The definition of the survey should allow defining the questions asked, and the type of the data to be entered; it should be possible that the questions asked depend on the answer to earlier questions. Also it should be possible to define the frequency of how often certain parts of the survey are run (monthly, weekly, daily or only once). The app should collect the data of the survey and store it locally on the smart phone.

 

Scope

In the long run such an app should be able to obtain the survey definitions from a web server and transfer the results of the survey back to the web server. But this is out of the scope of this project. It is enough if the survey definition and the survey results can be stored locally on the smart phone, along with a very simple way to show all the survey results on the phone. The focus of this project is a clear design of the language for defining surveys, and a prototype app that is able to run all its features. One additional feature could be measuring some input data of the survey by some of the built-in sensors (but this is not required).

 

Additional information:

This project might be interesting for students who participated in the course Software Engineering 2 course in autumn 2014 and know a bit of Android programming. The project should use the Eclipse ADT (but this is not thaught here) for developement.

 

There is a project on the way at DTU Compute, which is doing this on a larger scale. Therefore, there could be follow-up master projects continuing this task.

 
Links and resources
Below you will find some links to relevant information on some eclipse technology, the ePNK, and the ECNO Tool.

 

Technology

Eclipse Installation (for this course)

ePNK

ECNO

 

Ekkart Kindler (), Jan 29, 2015 (last updated Feb 2, 2015)