JACOB DUIJZER

Dit artikel werd eerder gepubliceerd in het SDN Magazine.

Samenwerken. Dialoog. Conversatie. Elk boek over softwareontwikkeling besteed er aandacht aan. Het is misschien wel het belangrijkste middel om succesvol software te ontwikkelen. Of het nu gaat over domeinen, specificaties of architectuur, uiteindelijk moet er een ondubbelzinnig beeld ontstaan van het te ontwikkelen software systeem. Ook bij het ontwerpen van de architectuur is de dialoog belangrijk. Het is daarbij van belang dat alle betrokkenen begrijpen hoe de architectuur van het softwaresysteem er uit ziet.

Verschillend publiek

Bij het ontwikkelen van software zijn veel verschillende partijen betrokken. Stakeholders, Product Owners, System Engineers, Testers, Software Engineers, elke discipline heeft een ander belang bij de architectuur. Een stakeholder wil dat er waarde gecreëerd wordt, dat er een probleem wordt opgelost, een system engineer zal willen weten hoe het beheer moet gebeuren. Bij het ontwerpen van een software systeem moeten we het gesprek dus aanpassen aan het publiek. Elke weergave moet echter wel een waarheid weergeven om te voorkomen dat er designs ontstaan die in de praktijk niet gebruikt worden.

Het C4-model¹ kan helpen om de architectuur van een software systeem te visualiseren door het systeem in verschillende lagen te ontleden, elk niveau met zijn eigen detaillering.

Het C4-model

Context, Containers, Componenten en Code. Dat zijn de 4 C’s van het C4-model. Het heeft niets met het explosief C4 te maken, al kan het toepassen van C4 wel een explosieve impact hebben. Het is ontwikkeld door Simon Brown², die bij workshops tot de conclusie kwam dat visualiseren van architectuur een vaardigheid is die bij veel developers en architecten ontbreekt.

Het C4-model beschrijft de architectuur van software systemen door het te ontleden in verschillende niveaus, van de context tot de code. Het model beschrijft diverse elementen die kunnen helpen om gezamenlijk een ontwerp te maken en te visualiseren. Door de niveaus gescheiden te houden blijft de complexiteit van een design lager en is het uitermate geschikt om in een snel veranderende wereld gebruikt te worden.

Context

Het context diagram is vaak een goed punt om mee te beginnen. Het geeft een goed beeld van het hele landschap, het geeft het eigenlijke software systeem weer met de belangrijkste gebruikers en externe systemen waar het systeem van afhankelijk is. Details zijn hierbij niet belangrijk, die komen in diepere lagen aan bod.

In dit artikel gebruik ik het voorbeeld van een website waar je pizza’s kunt bestellen. Pizza’s bestel je op een website, je betaald je bestelling en de lokale pizzabezorger komt de pizza thuis bezorgen. Zowel het betaalsysteem als het systeem van de lokale pizzabezorger zijn buiten de scope van ons softwaresysteem maar wel onderdeel van het grote geheel.

Containers

Elk softwaresysteem is opgebouwd uit verschillende containers. Het gaat hier niet om Docker containers, C4 gebruikte deze term al voordat Docker populair werd. Denk bij een container aan een webapplicatie, een API of een database. In dit diagram gaat het er vooral om welke containers er zijn en wat de onderliggende relaties zijn.

Er begint nu meer duidelijk te worden over de architectuur van het systeem. Blijkbaar bestaat het systeem uit een Angular webapplicatie, een API en een database. De API lijkt het meest complex, maar er zijn nog te weinig details beschikbaar.

Component

Het component diagram geeft een detailweergave van een container. Welke belangrijke onderdelen zijn er nodig om een container te ontwikkelen, wat zijn de taken van elk onderdeel en wat zijn belangrijke technische implementatiedetails.

Code

Vreemd genoeg wordt het gebruik van het vierde niveau, code, afgeraden. Althans, zo vreemd is het niet. De meeste software-ontwikkelprogramma’s zijn, al dan niet met behulp van plug-ins, prima in staat om UML-diagrammen te genereren op basis van code. Zo heb ik hieronder een voorbeeld van UML, vanuit code gegenereerd. Code wijzigt vaak sneller dan de architectuur en het handmatig bijhouden van code diagrammen kan dan een tijdrovende en overbodige taak worden.

Het bovenstaande voorbeeld komt bijvoorbeeld uit de JetBrains Rider IDE, het genereren van dergelijke diagrammen is goed te automatiseren, zelfs het automatisch updaten van documentatie is daardoor mogelijk.

Tools

C4 diagrammen kunnen met verschillende tools gemaakt worden. Er zijn plug-in’s beschikbaar voor de meeste software-ontwikkelprogramma’s, er is een online editor beschikbaar, het kan zelfs met websites als draw.io. Denk er bij het ontwerpen wel aan dat versiebeheer onmisbaar is. Online websites maken het werken met C4-modellen een stuk lastiger. Ontwerpen en aanpassen vanuit een IDE of andere editor maakt het werk vaak een stuk eenvoudiger.

Het bovenstaande voorbeeld maakt gebruik van de PlantUml implementatie van het C4-model. Deze implementatie is beschikbaar via GitHub. Het contextdiagram, het eerste diagram in dit artikel, ziet er in code zo uit:

@startuml

!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml

title Pizza Shop - Context Diagram

Person(client, "Hungry customer", "A customer, ordering a pizza.")

Enterprise_Boundary(pizza_enterprise, "Pizza Shop") {
    System(pizza_app, "Pizza Website", "Web shop where customers can order pizza's, side dishes and drinks.")
}

Rel(client, pizza_app, "Order details")

System_Ext(payment_provider, "Payment provider", "Managing payments.")
System_Ext(local_pizza_shop, "Local Pizza Bakery", "Baking pizza's, delivering to local customers.")

Rel_R(pizza_app, payment_provider, "Payment details")
Rel_L(pizza_app, local_pizza_shop, "Order details")

Rel_U(payment_provider, client, "Payment details")
Rel_U(local_pizza_shop, client, "Order updates")
@enduml

Het is mogelijk om de stijl aan te pakken, kleuren te veranderen, eigenlijk is alles aan te passen. Let er op dat je vooral aandacht besteed aan de duidelijkheid van de diagrammen, kleuren voegen daar lang niet altijd iets aan toe!

Conclusie

Eén van de weinige keren dat ik software documentatie daadwerkelijk gebruikt heb zien worden was bij projecten waar het C4-model gebruikt was. De hiërarchische aanpak helpt om de juiste detaillering te geven. Opdrachtgevers en architecten gebruiken de context en containers, Software Engineers kijken sneller naar de details van de componenten en de samenhang hiervan bij de containers, Systeem Engineers helpt het om inzicht te krijgen in beheersvraagstukken.

De eenvoud en eenduidigheid maakt dat het C4-Model¹ snel geadopteerd wordt en kennis van het C4-model¹ is bruikbaar bij alle projecten. Door de verschillende niveaus op te splitsen blijft elk niveau relatief eenvoudig en daarmee goed onderhoudbaar, uitermate geschikt van voor Agile projecten. Als een bestaand project slecht gedocumenteerd kan het teams helpen door interactief aan de slag te gaan met het C4-model. Ontwerp gezamenlijk de verschillende diagrammen waarbij door middel van discussies veel kennis opgedaan kan worden van het reeds bestaande systeem.

Wil je meer weten van het C4-model? Bekijk dan vooral de presentatie Visualising software Architecture with the C4 model ³ van Simon Brown op de C4-model website ¹.

Bronnen