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

by alexanderSoftware Engineering Basis

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.