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.
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.
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 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.
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.
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.
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.
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:
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.
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.
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.
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
Java, Spring MVC
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.