About

Arie van Deursen and Casper Boone

Delft Students on Software Architecture (DESOSA) is a collection of technical essays in which students explore the software architecture of 28 different open source systems. These essays are available as a series of blog posts for easy browsing, besides being available in ebook form as pdf and epub.

These essays were written as part of a master level course on Software Architecture that took place in the spring of 2020. The essays emerged as they were written, with most of them posted in March / April 2020.

In total over 120 students worked in teams of four, studying over 30 different systems. The course is open by design, with students not just learning from the teacher, but primarily from each other and from the wisdom of the open source communities. The course builds on ideas in open learning from (the late) Erik Duval, and on Amy Brown and Greg Wilson’s book series addressing the Architecture of Open Source Applications¹.

Students could decide for themselves whether to publish their essays, or whether to keep them visible to other students only. The large majority (28 out of 30) of teams decided to make their work public, with the result visible here.

Recurring Themes

Students were free to pick any open source system they liked, provided the system was sufficiently complex and active (a few pull requests per day, and actually used). Driven by their interest, they selected systems from a wide variety of domains, such as data science (Ludwig, NumPy, Bokeh), web frameworks (Gatsby, Material-UI), autonomous driving and flying (Ardupilot, openpilot), games (OpenRCT2), media (Musescore, Blender), the Internet-of-Things (RIOT, Micronaut), and many others.

Students were asked to write four different essays, which ended up as four separately readable blog posts, as well as four sections in the ebook chapter devoted to their system.

Product Vision

The starting point for all essays was a look at the future: What is the vision underlying the system, what is the system’s roadmap, who are the people that have a stake in the system, and in what context does the system operate.

To do this, many teams made use of Coplien and Bjørnvig’s Lean Architecture². This book emphasizes the need to discern an end user mental model, reflecting the expectations people have when using the system. These expectations are often domain-specific, corresponding to the way a user understands the application domain. As an example, team scikit-learn explains how estimators, predictors and transformers are core to any machine learning approach that is to be supported by scikit-learn. Likewise, team RIOT explains how the embedded nature of IoT devices shapes the expectations of RIOT users.

Coplien and Bjørnvig also argue for the need to conduct a stakeholder analysis, distinguishing end users, the business, customers, domain experts and developers (see, e.g., Ardupilot). The student teams identified these stakeholders, sometimes also falling back to the stakeholder categories provided by Rozanski and Woods in their book Software Systems Architecture³.

From Vision to Architecture

With the vision in place, the next essay takes a look under the hood, looking at the underlying architecture.

To that end, architectural views played a keyrole. Many students relied on Philippe Kruchten’s “4+1” model, distinguishing a logical, development, process, and physical view, as well as scenarios connecting them together⁴. Other teams relied on the seven viewpoints proposed by Rozanski and Woods ³, or benefited from the Arc42 templates for documentation and communication of software and system architectures.

Here, the students also looked at the various architectural styles used. The descriptions of the 28 systems serve to illustrate a wide variety of architectural styles, as well as common combinations of styles. Some examples include:

Style	Example Systems
Micro-kernel	RIOT
Micro-services	Micronaut
Inversion-of-Control	Micronaut
Layering	Material-UI, Ardupilot, Signal-Android
Event-based, Pub-Sub	Ardupilot, Bokeh, Sentry, openpilot
Model-View-Controller	Blender, GitLab, MuseScore, OpenRCT2, Signal-Android
Model-Template-View	Sentry
Flux Dataflow	Sentry
Client-server	Bokeh, Signal-Android
Type-based abstraction	Ludwig
Pipe-and-Filter	MyPy
Plugins	RIOT, Spyder

Quality and Technical Debt

Software architecture is not just about design in a greenfield setting: Architecture becomes especially challenging under the pressure of continuous change and evolution.

In their third essay, students investigate the processes in place to safeguard high quality evolution. For example, students look at the continuous integration processes, reviewing practices, and the test adequacy criteria used (such as code coverage).

Another aspect taken into account is what the quality of the system is in relation to the earlier established roadmap: Which components will be affected by this roadmap, and to what extent are these affected components ready for this change? If not, what refactoring would be needed to address the technical debt currently present in the system?

For this essay, students made use of various tools. Many students relied on Sigrid, a code analysis tool offered by the Amsterdam-based Software Improvement Group. This tool offers insight in component dependencies, and offers rating of the a system’s maintainability using seven factors ⁵. Another tool many students used to assess quality is SonarQube.

Deepening the Analysis

For the final essay, students could pick a topic of choice, from one of these categories:

• Variability analysis: Most systems can be configured in many different ways, at compile time, installation time, or dynamically at run time. A substantial body of research in managing such variability exists, giving rise to so-called “product lines”: Software systems that can be configured to a series of different software products⁶. Many students looked at their system from a variability perspective, for example when studying Ardupilot, openpilot, or NumPy.

• Socio-Technical Congruence: Conway’s law suggests that organizational structure is reflected in system design. This gives rise to the notion of socio-technical congruence⁷: An assessment of how social interactions and software component interactions are “congruent”. Several teams studied this congruence based on module dependencies, developers working on certain modules, and developer interactions (in, e.g., issues or reviewer comments). For example, team Bokeh used the SIG component analysis and contrasted this with developer communications obtained via the GitHub API, and team NumPy contrasted developer communication between maintainers of tightly and loosely coupled components.

• Green computing: An often overlooked quality attribute of software system is its energy consumption. Several students analyzed this for their system, including GitLab exlporing how to make the DevOps life cycle greener, and cryptocurrency Ripple.

• Other: Lastly, teams could come up with proposals of their own to study aspects specific to their system. For example, for OpenRCT2, the open version of the well-known game Rollercoaster Tycoon, the students investigate what it means to optimize “fun” in a game. Likewise, the Micronaut team specifically studied how Micronaut supports the creation of micro-service applications, the Signal-Android team looked at the specific way in which privacy and security is ensured, and the MuseScore team explored the usability and accessability aspects of its music scoring application.

Code Contributions

In order to get exposure to the source code, students made a total of 121 pull requests to the 30 open source systems, of which 72 were merged, 33 are still open at the time of writing, and the remaining 16 were closed (rejected). In this way, students interacted with senior developers, fixed issues, improved documentation, provided localizations, and learned about project policies concerning code quality, refactoring, testing, feature prioritiziation, git usage, and about the importance of keeping changes small and focused.

For each team, the overview page of their system contains a short status update of all pull requests made, with links to the actual pull requests.

We are grateful to all open source developers who patiently interacted with all students.

Highlights

As part of the course, students studied and learned from each other’s material and gave lots of feedback to each other (in fact, measured in words the feedback exceeded the actual essays). The feedback also included various Likert-scale answers. Based on all this, we feature some popular projects:

• Sentry, a system for triaging, analyzing and resolving errors and bugs.
• Next.js, a framework to help programmers build fast and modern web applications on top of React and Node
• NumPy, the de facto standard library for efficient numerical data structures such as matrices and arrays in Python
• Micronaut, a modern, JVM-based, full stack microservices framework designed for building modular, easily testable microservice applications.
• Gatsby, the free and open source framework based on React 1 that helps developers build blazing fast websites and apps
• Bokeh, an interactive visualization library for the creation of rich interactive plots, dashboards and data applications in the browser
• openpilot, a driving system aimed at achieving partial automation (level 2), letting the software control both steering and acceleration, while the human is still responsible for environment monitoring and fallback performance.

Studying in Times of Corona

The course started mid February 2020, before any case of Corona (COVID-19) had hit The Netherlands. With 120 participants we enjoyed lectures in a hall with a capacity of 140.

Right from the start, the course had, by design, an international setup, embracing online opportunities where relevant. For example, in our second lecture, we had Grady Booch in an online connection from Hawaii, in an Ask-me-Anything session. Students had watched some of Booch’s keynotes on software architecture as preparation. In the course of 30 minutes they fired a battery of questions to Grady Booch, who used his decades of experience architecting dozens of widely used systems to explain many principles of software architecture.

Half-way the course, mid March, because of Corona, The Netherlands went into lockdown, all students and staff had to study and work from home, and all education had to be fully online. Two (invited, industry) lectures had to be cancelled, but luckily we were able to organize one via Twitch. Steffan Norberhuis, TU Delft alumnus, cloud architect, and DevOps consultant, took up the challenge and managed to switch his lecture to a completely virtual setting with just 24 hour notice.

We originally had planned to conclude the course with a full day of posters, presentations, and interaction. Given Corona, instead of presentations, the students created videos of 5-10 minutes summarizing what they did, with some great creative results. Many of the teams made these videos publicly available as well (see, e.g., Signal-Android, Material-UI, or openpilot), which serve as a great introduction to the work the students did.

Instead of in-person presentations, we watched the videos together in chat rooms setup using Discord. The 30 teams were split into six separate sessions of five teams each. For each team, 20 minutes were allocated: 10 minutes to watch the actual video on YouTube, and 10 minutes for Q&A. Students asked questions asynchronously over the chat, and the presenting team answered using voice. This setting worked very well, also because the students were extremely participatory, and very much interested in each other’s work.

For all students participating in the course, the impact of Corona was substantial. They had to stay home, and could not meet other students. Some international students had to travel back last minute to their home country. Some students got sick, some developed COVID-19, yet fortunately all got better again. Many students had family or friends affected by the disease; some lost their loved ones. All students had to rethink their immediate and long term future.

It was under these circumstances, that the students wrote most of the essays presented in this collection.

Further Reading

Earlier editions of DESOSA appeared as online books, in the years 2015, 2016, 2017, 2018, and 2019.

More information about the course can be found on:

1. Arie van Deursen, Maurício Aniche, Joop Aué, Rogier Slag, Michael de Jong, Alex Nederlof, Eric Bouwers. A Collaborative Approach to Teach Software Architecture. 48th ACM Technical Symposium on Computer Science Education (SIGCSE), 2017.⁸
2. Arie van Deursen, Alex Nederlof, and Eric Bouwers. Teaching Software Architecture: with GitHub! avandeursen.com, December 2013.⁹

The schedule, slides, and assignment of the 2020 edition are available online.

Copyright, License and Availability

The copyright of the chapters is with the authors of the posts. All posts are licensed under the Creative Commons Attribution Share Alike 4.0 International License:

Reuse of the material is permitted, provided adequate attribution (such as a link to the essay on the DESOSA site) is included. If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.

Cover photo by Alex Wong, Unsplash.