Design Patterns

The topic of this weeks blogpost are Design Patterns.
The definition at the beginning of the wikipedia article states following:

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

We did research about different design patterns, like the factory and the observer pattern. But we could not really find a point in our source code where we could apply one of these more common design patterns in a meaningful way.
The reason for this is that we are taking big advantage of the functionalities that our frameworks are providing us. In the case of our frontend this would be Flutter and Angular Dart and in the backend things like Socket IO and Sequelize. This has the result that we are only writing little pieces of independent code. It was difficult to find a Design Pattern with which we could improve our code.

The mentioned frameworks are already providing us with different design patterns, which we didn’t have to implement on our own. The first example for this is the observer pattern, which is provided by Socket IO. The observer pattern is pretty simple and basically consists of two different parts, observers and subjects. The observer subscribes to different subjects of which he wants to gets updates, when changes happen. One observer can subscribe to several different subjects and every subject can have many observers. In our case do we only have one subject which is our webservice on the server. Every client who usese our service ans is logged in subscribes to this subject.

In the end we chose to implement the module pattern in our API-code, in a simplified way. We found that we were using the same function call for Sequelize at different points in our code. To increase the maintainability of our code we moved it into a separate function. Because of this we only had to change the call at this one point, when necessary. For now this seems to be only a minor problem because our project is still pretty easy managable at this size. But as our codebase grows, little things like these are getting more important.

In the following you can see the difference that this change caused in our class diagram. The difference is pretty small, because we only did a minor change to the code.

Old version on the left and new version on the right.

And here you can see the changes we did in our code:

Old code
New code

Best regards,


Hello everybody,

this week’s task was to refactor a deliberately badly written code. To improve the code, we added JUnit tests and restructured the code using the IDE tools of the IDE we prefer.

These are the links to our Git repositories:

Below you will find a little note from each of us, how their IDE helped us to do the Refactoring.

Tim and Marvin:
We have used IntelliJ to do the refactoring and could automate nearly every step of it which spared time and left less room for failure, which we didn’t expect to this extend beforehand.

I used eclipse to refactor since i was already working with it. It helped a lot with the refactoring and even though it sounds very subtle, auto-formatting helps a lot.

In my case I have tried refactoring in Visual Studio code, as I do a lot of projects using this IDE. VSC offers a very wide range of functions for refactoring and if that’s not enough for you, you can choose from countless plugins. For more information about refactoring in VSC just click here.

Greetings from your Maphynn Team !

Function Points

The topic of the Blogpost for this week is the calculation of Function Points for past and future use cases.
Function points are a measurement unit for software components. It is possible to evaluate the complexity of a chunk of software with them. If you want to learn more details about function points and how to calculate them then we can recommend the following YouTube channel:

Here you can see an example of our calculations:

You can find these calculations in every use case document of our project.
Here is a link to the example above:

All our calculations are also collected in the following Google sheet:

But what do you do after collecting all this data? We used the function points to improve our time estimations for future use cases. To accomplish this we created the following graph based on the table below:

Time spent per Function Point
Function Points table

Detailed view:

Based on the use cases from last semester we estimated a trendline that correlates the calculated function points with the spent time. Based on that we can now approximate the time needed for future use cases. As you can see some of the blue points are very far away from the trendline, like the use cases “Login” (Log), “Register” (Reg). We needed more time to complete these use cases because they were the ones we started to work on first. At this time we had zero to no experience in working with these technologies. Thats why we needed longer to complete them. “Add/Remove Friend” (ARF) on the other hand took less time, relative to the other use cases. This was the case because we were able to copy some things from past use cases and didn’t have to figure everything out from scratch. One of theses things was, how to send an http-request in Dart and how to work with the received answer, for example.

With the estimated time and the data from the last semester we are now able to estimate the time we have to invest in our project this semester, if we want to fulfill our goals we set.
You can see our spent time per workflow in the picture below. In an earlier blogpost we explained what these workflows are. The yellow area is our spent time on implementing our practical use cases. We marked the end of the first semester with the black arrow. There you can see that we spent around 40% of our time on implementing features. Because we also did much setup work, which is now already done, we expect to spend 50% of our time implementing in the future.

Here is also a link to our chart in YouTrack.

Thanks for reading this blogpost. We would really appreciate if we would get feedback from you.

Based on that we get an estimate of about 60 workhours needed for implementation and if we double this do we get an estimation of 120h that we will have to invest. This seems to be a managable amount and we will see if this is how the reality looks like.

With best regards,
the MAPHYNN team