Het maken van goede software staat of valt bij een goed proces om tot die goede software te komen. Hierbij zijn verschillende methodieken bruikbaar, waarbij agile en waterval veel voorkomen. Bij beide methodieken zijn verschillende fasen van software engineering te ontdekken die sequentieel (waterval) of meer iteratief (agile) uitgevoerd worden. Deze fases zijn Analyse, Ontwerp, Implementatie en Testen. Mijn collega Bas Michielsen heeft hier een aantal artikelen over geschreven die in deze fasen onderverdeeld zijn (zie https://www.bazzz.nl/)

Er zijn inmiddels bijna evenveel methodes om software gestructureerd te maken dan dat er projecten zijn. Denk hierbij aan de UML flow, C4 model, Kruchten 4+1, enzovoorts. Al deze methodieken hebben met elkaar gemeen dat er op een gestructureerde manier via een aantal diagrammen software ontworpen wordt. Sommige diagrammen komen in bijna elke methode wel terug – zoals bijvoorbeeld klassendiagrammen – en weer anderen komen minder terug, of zijn onder verschillende termen bekend – zoals bijvoorbeeld conceptueel model.

Om kennis te maken met software engineering wordt vaak gekozen voor een subset van deze diagrammen, die voor de verschillende fases voldoende basis geven. In dit artikel zal ik een overzicht geven van een aantal van deze onderdelen die in deze fases terug kunnen komen en hoe deze samenhangen. Het is hierbij belangrijk te beseffen dat dit niet DE waarheid is, maar een mogelijke manier om hiernaar te kijken. ^[1]Afhankelijk van de complexiteit en het type project wat je doet kunnen er onderdelen bijkomen of weggelaten worden. Je bent vrij hierin keuzes te maken, het is wel handig om te zorgen dat hierbij een … Continue reading

Welke diagrammen maak je?

In onderstaand plaatje is een overzicht te zien van de verschillende onderdelen die een software project kan bevatten. Hierbij staan de rode delen voor de analyse fase, de groene delen voor de ontwerpfase en de blauwe delen voor de implementatiefase. De zwarte pijlen zijn die onderdelen waar we van de ene fase naar de andere gaan. ^[2]De testfase die eerder genoemd is, heb ik hier niet als losse fase in het overzicht weergegeven, omdat deze wat mij betreft integraal onderdeel van de fases zijn en niet (langer) als losse fases … Continue reading

Opmerkingen op het schema

Er van uitgaande dat je weet wat de verschillende onderdelen betekenen (zie daarvoor eventueel ook de informatie op https://www.bazzz.nl)

Leeswijzer

Zoals je in bovenstaande plaatje kunt zien begint alles bij de requirements en volgt alles daaruit. Het diagram kun je vervolgens gebruiken om op allerhande manieren te bekijken hoe diagrammen samenwerken:

Als ik een bepaald diagram ga maken, kan ik in het diagram vinden welke andere diagrammen daarvoor als input dienen. Stel ik wil het conceptueel model gaan maken, dan kan ik in dit diagram zien dat ik daarbij de requirements en de use cases gebruik.

Andersom kun je ook kijken vanuit het onderdeel wat ik gemaakt heb en bepalen wat hierna komt: Stel ik heb het conceptueel model gemaakt, dan kan ik zien dat die als input gebruikt wordt voor het klassendiagram van de logica en het database ontwerp. Dat zijn dan dus ook mogelijke diagrammen om na het conceptueel model te gaan maken.

Dit diagram is ook te gebruiken als je een probleem aan het oplossen bent. Stel dat je in je conceptueel model een probleem tegenkomt, wat mogelijk vanuit een eerder diagram komt, dan kun je terugkijken. Voor het conceptueel model worden Use cases en requirements als input gebruikt dus het is goed die twee onderdelen ook te controleren.

Wat is het verhaal?

Bij elk diagram / onderdeel wat je maakt moet om te beginnen één vraag centraal staan: wat is het verhaalvan dit diagram? Oftewel: welk deel van de analyse / ontwerp / code moet hier centraal staan. Alles wat daar niet aan bijdraagt laat je weg. Bij de requirements hoef ik bijvoorbeeld niet op te nemen welk UI framework gebruikt gaat worden: dit is een keuze die je op zijn vroegst in het ontwerp (maar idealiter pas in de implementatie) maakt. Het kan wel zo zijn dat je in de requirements een non-functional hebt die aangeeft dat de UI via een webbrowser benaderbaar moet zijn. Dat verkleint de OPTIES in het ontwerp en de implementatie, maar legt nog geen details vast. 

Architectuur vs Klassendiagram lagen

De archtectuur en het klassendiagram lagen lijken qua flow erg op elkaar. Beiden laten zien hoe de opzet van de hele applicatie, maar vanuit een ander gezichtspunt: een architectuur vertelt welke componenten er zijn en welke van deze componenten met elkaar verbonden zijn, terwijl het klassendiagram lagen vertelt hoe deze componenten verbonden zijn.

Vergelijk dit met het bouwen van een huis. In de architectuur van het huis is bepaald WAAR de trap geplaatst moet worden en in de meer detailtekeningen wordt uitgewerkt WAT voor trap geplaatst moet worden (wenteltrap / rechte trap, hout / steen, wel of geen leuning). De architectuur heeft dan invloed op wat in de detailtekening mogelijk is (als ik slechts ruimte in de architectuur laat voor een wenteltrap, zal een rechte trap niet passen en het probleem niet oplossen)

Klassendiagram Logica vs Klassendiagram lagen

Deze twee diagrammen vertellen beiden een ander verhaal en het is goed deze diagrammen gescheiden te houden. de focus bij het Klassendiagram logica ligt op de requirements / use cases: Hoe komt het gedrag wat ik wil gaan aanbieden terug in het hart van het systeem – de logica. Het Klassendiagram lagen vertelt juist hoe die verschillende lagen met elkaar een samenwerking aangaan dit probleem op te lossen. Denk weer aan het maken van een gebouw: Bij de Klassendiagram Logica wordt gedefinieerd dat het om een woonhuis gaat, met op de benedenverdieping een woonkamer, keuken en toilet en op de eerste verdieping de slaapkamers en een badkamer. Het gaat hier dan niet over HOE ik van de benedenverdieping bij de bovenverdieping kom, dat komt juist in de Klassendiagram lagen: Het blijkt een stenen wenteltrap te zijn.

Ik begin met de use cases, dus de requirements zijn af…

Helaas (of misschien juist: gelukkig) gaat dat niet op. Het overzicht van de verschillende onderdelen helpt ook als er iets fout gaat. Stel: je bent inmiddels met het klassendiagram bezig, maar je komt erachter dat je niet genoeg informatie hebt om het klassendiagram te kunnen maken. Door de pijlen de andere kant op te volgen kun je dan uitvinden of het probleem eerder in het proces zit.

In het voorbeeld van het klassendiagram werkt dat dan als volgt:

het klassendiagram heeft een probleem. Je gaat terug bij de pijlen kijken en dat kan dus in het conceptueel model of in de use cases zitten. Dit zijn dan dus de 2 onderdelen om te bekijken wat er mis is. Je bekijkt dit en het blijkt dat je conceptueel model klopt, maar je in je use cases een stuk gedrag niet beschreven hebt. Dan ga je kijken naar alle onderdelen die voor de use cases als input gebruikt worden – in dit geval de requirements. Uit de controle van de requirements blijkt dat je de requirement beschreven had, maar vergeten was de bijbehorende use case te schrijven… Oeps. Gelukkig betekent dit dat je de use case kan toevoegen en klaar bent. 

Nou, niet helemaal: de volgende stap is het weer volgen van de pijlen naar de andere onderdelen die mogelijk impact hebben: het conceptueel model en het tesplan. Het conceptueel model was gelukkig al gecontroleerd en klopt, dus die is klaar en het database ontwerp hoeft dus niet gecontroleerd te worden. Het tesplan moet wel nog even gecontroleerd worden en gegeven dat de use cases een directe input van het testplan zijn, zullen er waarschijnlijk enkele tests toegevoegd moeten worden. Doordat je pas bij het klassendiagram was kun je het testrapport voor nu negeren: er is nog geen code die getest kan worden. Nu is alles weer gecontroleerd en kun je verder met je klassendiagram. 

Op deze manier kun je dus zorgen dat je steeds weet waar je mee bezig bent, blijft de documentatie in lijn met je code en kun je de kans exponentieel vergroten dat je code langdurig onderhoudbaar blijft