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?

Introductie

In een software project kunnen vele analyses, ontwerpen, diagrammen een plaats hebben. Maar hoe bepaal je dan wat je in je project nodig hebt? Je kunt daarvoor gebruikmaken van standaardwerkwijzen om een analyse en ontwerp te maken. Gangbare methoden zijn bijvoorbeeld UML, 4+1 model en C4 model. Elke werkwijze heeft zo zijn voor- en nadelen.

Welke werkwijze en methode je ook gebruikt, het is altijd verstandig kritisch te blijven kijken naar de nut en noodzaak van een model of diagram wat je maakt. Belangrijk is dat vrijwel elke methode een aantal grote brokken heeft:

• Analyse fase: WAT ga je maken
• Ontwerp: HOE ga je dit maken
• Implementatie: De uitwerking van analyse en ontwerp naar WERKENDE en ONDERHOUDBARE software
• Testen: CONTROLEREN dat de code inderdaad aan de requirements voldoet.

In dit artikel is een overzicht te vinden welke modellen je in een software project zou kunnen maken voor elke fase.

Hoe beslis je wat je gaat maken?

Na elk diagram wat je maakt is het goed om op een gestructureerde manier te kijken wat je nodig hebt om verder te komen in je proces om goede software te maken. Hierbij kunnen de volgende stappen helpen:

Stap 1: Welke informatie heb ik al

Als je een model afgerond hebt (en dit bij voorkeur ook op de juiste plaats gedocumenteerd hebt) dan is het aan te raden eventjes uit te zoomen en te kijken naar welke informatie je hebt: Is er al helemaal duidelijk WAT er gemaakt moet worden? Zijn er nog punten onduidelijk in HOE je het maakt? Het kan hierbij helpen om als centrale vraag te gebruiken: “Heb ik alle informatie die nodig is om de implementatie te gaan maken?” Als dit weer even op een rij staat kun je met de tweede stap aan de slag.

Stap 2: Welke informatie heb ik nodig om verder te kunnen?

Als je weet wat je hebt, kun je gaan bepalen wat het volgende model is wat je dichterbij werkende software brengt. Je kunt hierbij vragen gaan stellen en kijken of die vragen relevant zijn, al beantwoord zijn of juist meer informatie nodig is. Onderstaande vragen kunnen daarbij helpen:

Voor de analyse fase:

• Is helemaal duidelijk wat ik moet maken?
  • Hierbij geldt: is duidelijk wat de requirements zijn? Is beschreven welk gedrag het systeem moet hebben in de (re)actie op gebruikersinteractie? Is er een beeld van hoe dit er uit moet zien?
  • Typische modellen / diagrammen die hierbij terug kunnen komen zijn: Functionele en non-functionele requirements, Use cases, UI schetsen, acceptatie testplan
• Waar in de wereld staat dit systeem?
  • Welke externe systeem interacteren met mijn software systeem?
  • Vind er gebruikersinteractie plaats?
  • Wordt er data opgeslagen of uitgelezen?
  • Zijn er externe API’s die gebruikt worden?
  • Vaak maak je voor dit soort diagrammen een context-diagram.
• Is duidelijk welke concepten er in het systeem zitten?
  • Naast het gedrag van het systeem is het ook belangrijk te weten welke data er in een systeem zit. Daarbij komen zaken aan bod als:
  • Welke entiteiten zijn er in dit systeem?
  • Welke attributen hebben de entiteiten?
  • Hoe zijn de entiteiten gerelateerd?
  • Je maakt hier in principe een conceptueel model voor.

Voor de ontwerpfase:

• Hoe worden de verschillende externe systemen gebruikt?
  • In principe is het een goed gebruik om elk extern systeem apart aan te spreken, om te zorgen dat wijzigingen in de externe systemen zo min mogelijk invloed hebben
  • Je kunt daarom vanuit het contextdiagram gaan kijken hoe je deze externe systemen wilt laten samenwerken met het gedrag van het systeem.
  • Een architectuurdiagram kan hierbij helpen.
• Hoe wordt de data opgeslagen?
  • Je hebt vaak meerdere mogelijkheden: (Relationele) databases, bestanden, geheugen, desnoods met hamer en beitel in een steen slaan.
  • Op basis van de keuze voor de opslagmethode kies je een diagram wat daarbij past.
  • Kies je voor een relationele database? Dan is een databaseontwerp (ERD) vaak een passende oplossing
• Hoe komt het gedrag terug in de software?
  • Gegeven de use cases -> waar in het hart van het systeem komen deze terug?
  • Hoe werken de verschillende delen van de architectuur samen?
  • Je kunt hierbij denken aan klassendiagrammen

Als je bepaald hebt wat de volgende stap is die nodig is, dan kun je aan de slag met de derde stap:

Stap 3: Welk verhaal ga ik nu vertellen

Als duidelijk is welke vraag je wilt gaan beantwoorden komt een belangrijke beslissing. Je gaat bepalen welk verhaal je gaat vertellen. Het is hierbij belangrijk om te weten wat je WEL, maar vooral ook NIET wilt vertellen.

Eén van de meest voorkomende diagrammen in een software systeem is het klassendiagram. In theorie kun je hier alles in kwijt maar het is verstandig goed na te denken wat je wilt vertellen. Stel dat de volgende stap die je wilt zetten is: “Hoe komt het gedrag van het systeem terug in de applicatielaag?” Je wilt dan dus laten zien dat elke use case een duidelijk plaats heeft in de logica (het hart) van het systeem.

Het kan dan verleidelijk zijn ook te laten zien hoe de presentatie laag dit aanroept, hoe je dit opslaat in de database en hoe je de lagen via bijvoorbeeld interfaces ontkoppelt. Maar al deze zaken dragen niet bij aan het beantwoorden van de vraag die je opgesteld hebt. Laat al deze zaken dan dus weg.

Let op: Dit betekent niet dat je de bovenstaande zaken niet in je ontwerp mee moet nemen, maar het betekent wel dat je dat niet in DIT diagram doet.

Als je dan je ontwerp gaat maken, kun je steeds terugvallen op je doel: wat wil ik WEL en NIET vertellen met DIT diagram. In de volgende stap ga je dan de keuze maken via welk diagramtype je het verhaal wat je wilt vertellen gaat documenteren.

Stap 4: Met welk model / diagram ga ik dit ontwerpen?

Afhankelijk van de werkwijze die je gekozen hebt, kun je een aantal keuzes maken als het gaat om het maken van een model. Een voorbeeld: Als je de requirements helder hebt, dan is het weergeven van de werking van het gedrag onder andere mogelijk met use cases en user stories. Beide methoden zullen voor- en nadelen hebben en het is goed om deze naast elkaar te leggen om tot een keuze te komen.

Voor andere modellen is er een de-facto standaard die vaak gekozen wordt. Voor een klassendaigram bijvoorbeeld wordt vrijwel altijd gekozen voor een UML Class diagram.

Ga dus voor de keuze gemaakt in stap 3 na: welke diagrammen zijn geschikt om de vraag te beantwoorden. Maak vervolgens een beargumenteerde keuze voor een diagramsoort en ga daar in de volgende fase mee aan de slag. In deel 3 van deze serie zal ik ingaan op hoe je dan vervolgens het gekozen verhaal in de gekozen diagramsoort kan uitwerken.