2016-12, Gysel, Peter, Kröni, Daniel

Die Bereitstellung elektrischer Energie an die Haushalte ist eine komplexe Aufgabe der Energieversorgungsunternehmen. Die Energie wird über einen mehrjährigen Zeitraum in mehreren Tranchen von unterschiedlichen Anbietern und Marktplätzen und unter der ständigen Unsicherheit des Marktes beschafft. Eine gelungene Energiebeschaffung, also der Handel zum richtigen Zeitpunkt, bedeutet für ein Energieversorgungsunternehmen einen Wettbewerbsvorteil. In diesem Bericht wird die Energiebeschaffung erklärt und aufgezeigt, wie der Prozess mittels Software unterstützt werden kann.

2013-12, Kröni, Daniel, Schweizer, Raphael

Connected data such as social networks or business process interactions are frequently modeled as graphs, and increasingly often, stored in graph databases. In contrast to relational databases where SQL is the proven query language, there is no established counterpart for graph databases. One way to explore and extract data from a graph database is to specify the structure of paths (partial traversals) through the graph. We show how such traversals can be expressed by combining graph navigation primitives with familiar grammar constructions such as sequencing, choice and repetition – essentially applying the idea of parser combinators to graph traversals. The result is trails, a Scala combinator library that provides an implementation for the neo4j graph database and for the generic graph API blueprints.

2012-12, Denzler, Christoph, Kröni, Daniel, Moschko, Maxim

Mobile apps are often developed and then evolved on more than one mobile operating system. For the publisher of such apps, the problem is how to ensure equivalence of the product on the various platforms, in the sense of acting equivalently with respect to a test set. In this paper we present an approach that tackles this problem from two directions: architecture and testing. First we will explain the role and pitfalls of reference architectures. Then we will present our equivalence testing framework. It is based on mocking components of the target implementation. Instead of implementing mock components for all platforms, our approach is to implement these mocks only once and run them on a central server. On the tested target device, stub components are injected that forward to their server-based counterparts. Thus the exactly same test code is applied to all platform specific implementations.