In deze artikelenreeks ga ik in op het maken van een diagram voor een software project. In het eerste artikel gaf ik een overzicht hoe ik het maken van een diagram aanpak. Waar de eerste stap ging over het verhaal wat je wilt vertellen, gaat het in dit artikel over de mentale creatie van het diagram. Of in andere woorden: het denkwerk.

Read more: Hoe maak je een diagram? – Deel 3: De mentale creatie

Je weet nu welk verhaal je wilt vertellen en met welk model je dit verhaal gaat vertellen. Nu komt het aan om dit verhaal op de juiste manier te gaan vertellen. In de praktijk zie ik dan vaak de volgende werkwijze Eerst open je de tool waarmee je het model wil gaan maken en vervolgens ga je prutsen tot het model klopt en alles er goed inzit.

Uiteraard is dit een zeer versimpelde weergave van het proces, maar praktische komt het wel vaak neer op ‘prutsen tot het werkt’. Groot probleem van een diagram meteen in de tool te maken is dat je eigenlijk 3 taken tegelijk probeert te doen:

1. Het verhaal wat je wilt vertellen op een goede manier modelleren
2. De syntax van het diagram correct gebruiken
3. De tool op een goede manier gebruiken

Groot nadeel hiervan is dat je dus feitelijk het denkwerk (de eerste taak) en het juist weergeven van dit model (de tweede en derde taak) combineert. Vaak merk ik dan ook dat je merkt dat je in je denkwerk iets anders wilt, je vervolgens lang bezig bent in de laatste 2 taken om dit goed te krijgen, om er dan achter te komen dat de aanpassing geen verbetering is. Je kunt dan ineens alle tijd die je ruzie gemaakt hebt met de tool weggooien.

Daarnaast speelt ook mee dat het brein niet zo heel goed is in meerdere zaken tegelijk doen (switchtasking) en de stappen zijn zo verschillend dat dit tegelijk willen doen, toch echt als switchtasken geldt.

Doe dus eerst taak 1

Om het verhaal goed te modelleren, is het dus verstandig zo min mogelijk afgeleid te raken door randzaken. Het syntactisch correct in de juiste tool brengen van het model is in deze fase van het maken van een model een nogal afleidende randzaak.

Daarom: Als je begint te modelleren. Klap de laptop dicht, zet de PC / telefoon / tablet uit, zoek een whiteboardmarker en een whiteboard en leef je uit. Hoe kleiner de kans dat je stiekem toch de tool alvast opent, hoe beter. Waarom een whiteboard en niet papier? Op een whiteboard is het gemakkelijker om wijzigingen te maken dan op papier (tenzij je natuurlijk potlood of wisbare inkt gebruikt).

We staan dus aan het whiteboard en dan kunnen we dus aan de slag. Maar… wat ga je dan modelleren, en vooral ook: hoe? Het is waarschijnlijk verleidelijk om dan aan de slag te gaan en op het whiteboard te zetten wat in je opkomt. Wat waarschijnlijk betekent dat je wederom ‘aan het prutsen bent tot het werkt’.

Maak een plan!

Prutsen tot het werkt is zelden een goede manier om iets op te lossen. Althans, wel als je de software later ook nog wilt kunnen aanpassen, uitbreiden en vooral: begrijpen. Een goede software engineer weet wat hij waarom doet.

Net zoals we een project opdelen in features en deze features weer opsplitsen in taken, kun je het maken van een model ook opsplitsen in taken. Sterker nog: dit maken van een model is zo standaard, dat er voor elk type model een stappenplan te maken is wat je kunt volgen en wat waarschijnlijk met (kleine) aanpassingen ook voor andere modellen te gebruiken is.

Stappenplan: Klassendiagram

Om dit te illustreren is hieronder mijn persoonlijke stappenplan te vinden voor het maken van een klassendiagram:

1. Welke klassen zijn er in dit systeem
2. Welke klassen zijn gerelateerd (nog niet HOE ze gerelateerd zijn, alleen DAT ze dat zijn)
3. Ontwerp de relaties verder:
   1. Bepaal hoe de relatie van klasse 1 naar klasse 2 is
      1. Is er een relatie?
      2. Wat voor relatie is het?
      3. Is de relatie verplicht of optioneel?
      4. Wat is de multipliciteit?
   2. Bepaal hoe de relatie van klasse 1 naar klasse 2 is
      1. Is er een relatie?
      2. Wat voor relatie is het?
      3. Is de relatie verplicht of optioneel?
      4. Wat is de multipliciteit?
4. Bepaal de attributen
5. Bepaal de operaties
6. Maak de verantwoording van het diagram
   1. Wat is het verhaal (de context, maar ook beperkingen als je bijvoorbeeld een deel van het systeem ontwerpt)
   2. Bespreek aannames en keuzes en vooral: het waarom van deze keuzes.Let op:

Een aantal aandachtspunten:

• Laat triviale en overduidelijke zaken weg: Dat de entiteit Persoon het attribuut Naam heeft is logisch en hoeft dus niet verantwoord te worden
• Als je in het klassendiagram iets op een andere manier oplost als je in het conceptuele model gedaan hebt, is een toelichting essentieel.
• Aannames worden normaal gesproken weggewerkt: of het blijkt een keuze en dan blijft het wel staan, maar dan als expliciete keuze.
• Bovenstaande stappenplan is MIJN manier van het maken van een model, dit betekent dus niet dat het de enige waarheid is (verre van) en ook zeker niet voor iedereen werkt. Zoek je eigen weg, maar standaardiseer wat te standaardiseren is.

In de terugkomdag van Make IT Work heb ik een workshop gegeven rondom OO principes. Hier zijn een aantal onderwerpen in teruggekomen. In dit artikel kom ik terug op de paradigma’s en zijn ook extra bronnen te vinden over de onderwerpen waar we over gesproken hebben.

Continue reading “Make IT Work Extra informatie en bronnen”

In het eerste artikel uit deze reeks hebben we besproken wat manieren zijn om een diagram te maken. In dit artikel gaan we kijken naar de eerste stap van deze methode: Wat is het verhaal?

Continue reading “Hoe maak je een diagram? – Deel 2: Wat is het verhaal wat je wilt vertellen?”

Het maken van een goed diagram is vaak lastig, zeker als je hier nog weinig ervaring mee hebt. Gelukkig is het zo dat veel diagrammen een specifiek doel hebben en volgens een vaste syntax werken. Hierdoor is het al vrij gemakkelijk om een eerste selectie te maken. Daarnaast kun je voor een hoop diagrammen volgens een vaste methode werken, die ook nog eens grotendeels overeenkomt.

Om houvast te bieden kun je een aantal stappenplannen toepassen om tot een correct diagram te komen. Ik zal in deze reeks artikelen een mogelijke werkwijze toelichten die kan helpen om tot de juiste onderdelen van je analyse en ontwerp te komen. Deze werkwijze heeft 3 stappen:

1. Wat is het verhaal van je diagram?
2. De mentale creatie van een diagram
3. De fysieke creatie van een diagram

Continue reading “Hoe maak je een diagram? – Deel 1: Introductie”

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

Continue reading “Software ontwikkeling: Een schematische weergave”