DESOSA 2021: About these Essays

Arie van Deursen, Casper Boone and Shipra Sharma

Delft Students on Software Architecture (DESOSA) is a collection of technical essays in which students explore the software architecture of 26 different open source systems, available as a series of blog posts for easy browsing.

These essays were written as part of a master level course on Software Architecture that took place in the spring of 2021. The essays emerged as they were written, with most of them posted in March / April 2021. While the course has existed for several years, this is the first time the entire course was online only, as the TU Delft was closed for in person education while The Netherlands went through the second and third waves of COVID-19.

In total over 110 students worked in teams of four, studying 28 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 (26 out of 28) 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, Internet of Things (ThingsBoard), deep learning (HuggingFaceTransformers, FastAI), web technology (FireFox), crypto currencies (Stellar), and distributed systems (Kafka, Spark).

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.

The textbook used during the lectures was Software Architecture: Visual Lecture Notes, by Cesare Pautasso². This book was published in 2020, based on a series of lectures Cesare has taught over the years in Lugano, Switzerland. It covers architectural views, connectors, service-oriented architectures, run time perspectives, among others. It was the task of the students to internalize as much of this book as possible, by trying to apply it to the open source systems they were studying.

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. In line with Grady Booch’s maxim that every line of code has a moral and ethical implication, students were also encouraged to discuss ethical aspects of the system under study.

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 key role. Many students here relied on the C4³ model, to describe the Context, Containers, Components and Code of a system. Furthermore, as proposed by Pautasso², students added a 5th “C” to this model, by also taking connectors between components into account as first class architectural citizens, making it possible to reason about properties of connections such as privacy, throughput, and their interfaces. Where relevant, students assessed APIs provided by the systems under study, by comparing them against API design principles from, e.g., Meyer or Bloch, as discussed by Pautasso².

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

Style	Example Systems
Client Server	HuggingFaceTransformers
Model View Controller	Inkscape, NetworkX, Odoo
Bridge	Jitsi
Layering	Matplotlib, Odoo
Plugins	IntelliJ
Factory	HuggingFaceTransformers, IntelliJ

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. Particularly popular were SonarQube, which can identify a series of smells, security issues, and maintainability problems in code (see, e.g., theia, stellar), as well as CodeScene, which can also identify hotspots of coding activity for which addressing technical debt would be most relevant (see, e.g., NetworkX, inkscape, or bitwarden)

Deepening the Analysis

For the final essay, students could pick a topic of choice. One suggestion was to conduct as an assessment of the system’s distributed nature (focusing on consistency, availability, and partition tolerance). Another possibility was to study the energy consumption of the system under study (see, e.g., Kubernetes)

Many students opted to conduct a 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 Theia, LibGDX, or XWiki.

Other teams (e.g., Jitsi) ‘gave back’ to the system they studied, by offering an ARCHITECUTRE.MD file summarizing the system’s architecture, following the guidelines laid out by Aleksey Kladov.

Code Contributions

In order to get exposure to the source code, students made a total of 106 pull requests to the 28 open source systems, of which 56 were merged, 46 are still open at the time of writing, and the remaining 4 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 and essays:

Essay 1 – Product Vision:

The Firefox team explains how the architecture of Firefox is driven by the vision of providing people with the best browsing experience while putting them in control of their experience.
The 🤗 Transformers project combines pre-trained Natural Language Processing Models, tokenizers, pipelines, and PyTorch and Tensorflow support, with a focus on accessibility, usabiliity, extensability, matintainability, and security.

Essay 2 – Architectural Decisions:

The ThingsBoard IoT platform uses layered, Model-View-Controller (MVC) and REST architectural styles and a Transport container to abstract communication between devices and servers
The Odoo Human Resources module also combined a layered (three tier) and an MVC architecture, with a focus on extensibility. Its deployment architecture supports on premise as well as cloud deployment.

Essay 3 – Quality and Technical Debt:

The quality analysis of Rustpython indicates a project with a focus on short functions (with low cyclomatic complexity) in files of fewer than 1000 lines oof code, extensive testing, and a fully automated continuous integration pipeline.
For FastAI, the team looked at both functional and non-functional requirements, identified hotspots using CodeScene, and looked at how Jupyter Notebooks are used for testing purposes.

Essay 4 – Project-Specific Posts:

For Jisti Meet the students created an Architecture.md file, describing the key components, an architecture diagram, and a code map. It was included in the official Jitsi documentation.
For OpenHab, the students chose to analyze the way OpenHab implements and builds upon the OSGi dynamic component system.
The KiCad kicad team studied socio-technical congruence, assessing to what extent the system’s modularization was in line with Conway’s Law.
The Stellar team focused on the distributed nature of the Stellar blockchain, analyzing how the Stellar Conensus Protocol implements Fedearted Byzantine Agreement.
The libGDX team studied how variability in target platforms is realized using backend packages that implement or can interface with the common interfaces of the platform-independent code and the application.

Acknowledgments

We are grateful to the team coaches, who each helped 4-5 teams: Leonhard Applis, Luís Cruz, Xavier Devroey, Burcu Kulahcioglu Ozkan, and Diomidis Spinellis.

A huge thanks to the various guest lectures, which informed the students in their essay writing: Luís Cruz (sustainability), Xavier Devroey (variability), Burcu Kulahcioglu Ozkan (distributed systems), Diomidis Spinellis (Unix history), Bert Wolters (Adyen, payment systems at scale), Steffan Norberhuis (operations), and Daniel Gebler (Picnic, managing the unexpected).

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.

Amy Brown and Greg Wilson (editors). The Architecture of Open Source Applications. Volumes 1-2, 2012. aosabook.org. ↩︎
Cesare Pautasso. Software Architecture: Visual Lecture Notes. Leanpub, 2020. leanpub.com. ↩︎
Simon Brown. The C4 model for visualising software architecture. https://c4model.com/. ↩︎
Sven Apel, Don Batory, Christian Kästner, Gunter Saake. Feature-oriented software product lines. Springer-Verlag, 2013. (url) ↩︎
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 (preprint). ↩︎
Arie van Deursen, Alex Nederlof, and Eric Bouwers. Teaching Software Architecture: with GitHub! avandeursen.com, December 2013. ↩︎

About