So finally the midterms arrived!

In this post, we want to summarize all the things we did so far and present you a nice overview about our project.

You can find any useful information in this blogpost, links to all ressources and all posts.

Happy holidays!

Clairvoyance team

Gitlab: https://gitlab.com/sasep-clairvoyance


Live Environment:

Use Cases:

Software specifications:

All the blog posts:

All our peer reviews: https://mfj-testing.com/2019/10/10/peer-reviews/

Our midterm presentation as .pdf: https://gitlab.com/sasep-clairvoyance/sasep-documents/raw/master/Presentation_Software_Engineering_Midterms.pdf


There is still a lot of work to do, so we try our best to get everything done in time. This week we should fill in the SAD-document with some diagrams. You can find this document here. Most likely we will change some parts of it in near future because we try to generate as much of those diagrams automatically based on our code. But our code is in an very early stage so there will be lots of changes.

Spring as MVC Framework

For our project we decided to use Spring Boot which includes the Spring MVC framework. Therefore, our project should match the MVC structure by default. The following image shows the structure of a normal Spring MVC application. The only difference in our case is that we return an object as “view” and not a html page.

Spring MVC overview (source: https://terasolunaorg.github.io/guideline/1.0.1.RELEASE/en/Overview/SpringMVCOverview.html)

As Spring is a very popular framework there are some tools out there to generate a CRUD application with only a few clicks. One of those tools is JHipster just to mention one example. But our application doesn’t fit the CRUD schema very well, so we took another approach.

Code generation with Swagger

The Spring application is only one half of our project. The second part is a single-page Vue.js application to visualize our data, as described in a previous blog post.

Therefore we had to design a REST-API for communication. To achieve this we used Swagger which allows us to define endpoints, parameter and transmitted objects in a YAML-format. Then Swagger uses this configuration to generate a lot of our needed Java-classes which will be the base for future development. Beside this generated code you will also get a well-organized documentation for your API which even allows interactive testing by sending some dummy requests to the server. So if you need to design an RESTful API you should definitely check it out.

Looking forward to some feedback.

Class Diagrams

This week was quite busy. We had to complete our use case diagrams with 3 use cases we hadn’t implemented so far, but which are required until December.

You can find all of our use cases in our documents git here: https://gitlab.com/sasep-clairvoyance/sasep-documents/tree/master/use-case-diagrams

One of our new Use Case diagrams

After that, we designed our first database scheme. We wanted to create basic table schemes for relevant data for our use cases. Our first basic database schemes can be found here: https://gitlab.com/sasep-clairvoyance/sasep-documents/tree/master/ERM

User Entity Relationship Model
Sport Entity Relationship Model

We also created our Software Architecture Document from the .html template, which you can find here: https://gitlab.com/sasep-clairvoyance/sasep-documents/wikis/SAD
But for now it is just the template in Markdown because it is the topic of next weeks lecture.

Last but not least we coded our first data object classes for our backend, based on the database scheme. With Spring JPA it’s really easy to work with POJOs (Plain Old Java Objects) and save and access them in a database. You define them as Entities. With the help of repositories you can access their data from the database. Whit that, you don’t have to write a single line of SQL.

After we created the 5 data object classes, it was easy to generate the class diagram from within IntelliJ. You can find the generated class diagram in our git repo here.

Our first UML class diagram for the data object classes


Our retrospective got our team talking about the good, the bad and steps to a better future (for Clairvoyance). Our flip charts are in German, but I will explain the content in English.

The Good

We do our homework on time. We reliably write blog posts and peer reviews in accordance with each weeks grading criteria. The spring boot hello world instance is up and running (sometimes). SCRUM tools are deployed and are utilized (more on this later). Some Use Cases regarding the frontend are nicely specified and come with pretty mockups.

The Bad

Some weaknesses in our inception phase have become apparent: there is currently one UC with one UCD that covers both user navigation to and view of the data. The UCD and its mockups specify the navigation well.

While we have all the tools to SCRUM, we so far have not used them effectively. This spirals adds to our time management issues and a lack of ownership by team members.

Steps to a better future

We will add a new UC to deal with the data view. Over UCs and our SRS will be adapted accordingly. More realistic specs and informative UCDs will aid implementation.

The biggest step towards more productive (team)work is build on the making SCRUM work. We have all the tools, now we will use them. Specifically, team members put things, they want to have done into tickets. Appropriate parts of the product backlog are pulled into the sprint backlog each thursday. YouTracks timekeeping feature will be used at a short retro to compare the input of each team member to address impediments.

I believe we have identified some of the biggest impediments in SaSEps workflow. The tools change things are already deployed. Now we have to change our work culture to level up.


This week the topic we’ll be talking about is Scrum.
Scrum is the currently most popular form of agile workflow and is primarily used for software development.
We won’t talk about how Scrum works, but about how we implement it. You can read about how Scrum works here.

Our sprints will be one week long. The reason behind this is to synchronize our worklow with the Software-Engeneering-classes and the homeworks. We will use YouTrack as agile board since it fullfills the given criteria. You can find an live overview with the Burn Down Chart here.

Time Tracking
Git integration
IDE integration
Agile Board
GANTT chart


Last week we specified our three first use cases including activity diagrams and mockups. This week we add narratives using the Gherkin-syntax. Screenshots of the feature files from the IDE are depicted on the blog. The whole feature files are linked and have been added to the use cases under narrative.

Our first feature file for our UC Collect public data for these scenarios:

The start of the feature file for our UC Registration and Login:

Parts of our feature file for the UC View our data:

We are still at the absolute beginning of using cucumber. We look forward to any tips and tricks you might offer and we promise to keep you up to date about our own testing regime.

Use Cases

Based on our UCD from last week we decided on which parts we want to concentrate on this semester. Luckily this decision wasn’t very difficult as we will need a base system before we can implement additional features. This means that we will need a frontend to display our calculated statistics, some scripts to collect the raw data and of course the part which processes all data in order to allow us to predict something. Therefore we selected the following use cases from our diagram:

Our first activity diagrams

Cause this were our first activity diagrams we started with creating one for the registration and login, although it was not necessary for the homework. But it was quite straightforward to draw these diagrams for such a common case that it helped us to get an idea of what we had to do. Also for the purpose of having a complete documentation we needed to create this document.

The next use case we examined in more detail was the collection of publicly available data which should be the basis for our first predictions. This case differs a bit from others because you can not separate the activities into user, UI and system or something similar as the whole process is part of the backend. For this reason it was also not possible to develop a mock up.

Activity diagram for data collection

We also had a closer look on the use case “View our data” which was a bit challenging because therefor we had to plan the overall design of our website, but we did not have any ideas how to design it. For that reason this task tooks longer than expected. We still didn’t finished the UC-document for this use case so we could not put a link in the blog post. But we will update this post as soon as we have finished the document.

Looking forward to get some feedback


This week we created our base software requirement specifications (SRS). It was quite a challenge to accomplish.

First, we had to think about specific components and detailed features. Second, it was our first SRS. With the help of the explanations provided in the Word document, we managed to fill in all the different parts.

It is much more clear now how we have to build our project and moreover which parts are important. For example, accessibility is not a point most software engineers think about in the first place. But it is really important for our users. Another important point is security. Since we will use external APIs and services to get our data, we have to think about vulnerabilities in our data processing. Especially things like SQL injections might be a problem.

You can find the newest version of our SRS in our documents git wiki: https://gitlab.com/sasep-clairvoyance/sasep-documents/wikis/SRS
It is still kind of WIP so please remember that when commenting 🙂

We also did our first use-case diagram. For that we had to think about specific user interactions with our application. You can find that on our documents git and in this blog post as an image.

This use case diagram specifies two actors: Contributors and consumers.
The system is divided in a frontend and a backend.

The backend part of the system stores collected data from public leagues und processes data to calculate ELOs and predict results. In the feature, it should be possible to get advice on optimizing a teams composition based on the processed data.

The frontend initially will be focused on consumers (casual users). They can view our calculations, get an account and customize their interests.

We plan to add contributor accounts at some point in the future. Contributors would be able to provide their own data, say from their private tournament. The backend would calculate the stats. Contributors would maintain control over the access to their data.

Team, Roles and Technologies

Team and Roles

Jan HanselImplementer, Deployment ManagerBackend, Database, Deployment
Marlon MüllerImplementer, DesignerFrontend, Design
Eric DehmelImplementer, Test Manager Backend, Database, Testing
Robin KingBusiness Designer, Analysis, ImplementerBusiness Modeling, Requirements,

The roles have been assigned considering the strengths of each team member. While the roles define the primary task of each member, the overall development will be agile, so everyone is able to assist in other areas if required. Not defined but needed roles and areas, like Project Management, will be worked on by the whole team in the same way. Therefor, as already mentioned, an agile form of development process, for example Scrum, will be used. The exact form of agile development has yet to be decided.

Technologies and Tools

BackendJava, Spring MVC
FrontendHTML, CSS, JavaScript, Vue.js
Project ManagementGitlab, YouTrack

We decided to use YouTrack as our issue tracker/project management tool. First we wanted to use Gitlabs built-in issue board, but we need time-tracking, sprint planning and more detailed reports. As a platform for using git, Gitlab is always our first choice. Features like merge-requests and especially the built-in CI/CD pipelines are great.

Peer Reviews

An overview of all peer reviews by SaSEp:Clairvoyance members.

Semester 2

WeekReviewed ProjectReviewing SaSEp:Clairvoyance
2ArreracEric Dehmel
2MAPHYNNRobin King
3MAPHYNNJan Hansel
3unitasksEric Dehmel
4towerdefenseMarlon Müller
4itemizeRobin King
5GreenClothaWayRobin King
5towerdefenseMarlon Müller
6ArreracJan Hansel
6MAPHYNNMarlon Müller

Semester 1

Week Reviewed project Reviewing SaSEp:Clairvoyance
1HopperJan Hansel
1Stats-ScreeningMarlon Müller
2MAPHYNNRobin King
2hypercasualMarlon Müller
3Stats-ScreeningEric Dehmel
3PiPossibleRobin King
3MAPHYNNJan Hansel
4GreenClothaWayRobin King
4GameBaseEric Dehmel
5easyFinanceJan Hansel
5Tower DefenseMarlon Müller
6KeyCloudRobin King
6Tower DefenseMarlon Müller
7OneTouchJan Hansel
7cozyMarlon Müller
8MAPHYNNEric Dehmel
8LogicGameRobin King
9TrackYourFitRobin King
9FoodyJan Hansel