Ga naar hoofdinhoud

Lesprogramma

1. Introductie SoEx​

Introductie waarin het vak, de weekindeling en de toetsing wordt toegelicht.

  • Opdracht & Resultaat
  • Werkwijze
  • Toetsing

Introductie Opdracht & Resultaat​

Casusopdracht (Zie github repository van je groepje) en software guidebook.

Werkwijze​

Deze opdracht heeft een ander karakter dan de FSWD-opdracht. De FSWD-opdracht is een typische implementatie-opdracht, terwijl deze opdracht een typische onderzoeksopdracht is. Daarom gebruiken we geen User Stories om structuur aan te brengen in het werken aan de opdracht, maar Spikes.

Omdat het werken met Spikes nieuw is, hebben we de planning voor de eerste twee weken al vastgelegd. De derde week plannen jullie zelf.

We laten zien hoe Spikes werken en welke taken er typisch onder een spike vallen. Zie voor meer informatie de pagina over Spikes en Taken.

2. Begrippen en Domeinmodel​

Maak een begrippenlijst en een domeinmodel op basis van de TripTop casusbeschrijving en hoofdstuk 3 uit het SGB en plaats dit in 3.2 en 3.3 uit het SGB.

👉 Zie taken 1 t/m 6 van Spike "1. domein onderzoeken"

👉 Voor een concreet stappenplan (DST stappenplan: van domain story naar domeinmodel), zie DoEx: Stappenplan

Ter herinnering en vergelijking in uitklap sectie 2.1 t.m 2.4 twee eerdere voorbeelden van domeinmodellen en een bijbehorende begrippenlijst.

Voorbeeld Mastermindt

2.1 Voorbeeld domeinmodel Mastermind​

e7401c07ea978c0c40c1ed94cccb6417

"Mastermind - Domeinmodel" in natuurlijke taal

Klassendiagram met 6 klasse(n) en 6 relatie(s).

Klassen:

  • Klasse Board met stereotype Aggregate Root, Entity zonder methoden en attributen
  • Klasse Row met stereotype Entity zonder methoden en attributen
  • Klasse CodePattern met stereotype Value Object zonder methoden en attributen
  • Klasse KeyPattern met stereotype Value Object zonder methoden en attributen
  • Klasse CodePeg met stereotype Value Object zonder methoden en attributen
  • Klasse KeyPeg met stereotype Value Object zonder methoden en attributen

Relaties:

  • Board heeft een compositie-relatie met naam 'contains' met Row, multipliciteit 0..8
  • Board heeft een compositie-relatie met naam 'secretCodePattern' met CodePattern, multipliciteit 1
  • Row heeft een aggregatie-relatie met naam 'guess' met CodePattern, multipliciteit 1
  • Row heeft een compositie-relatie met naam 'feedback' met KeyPattern, multipliciteit 1
  • CodePattern heeft een compositie-relatie met CodePeg, multipliciteit 4
  • KeyPattern heeft een compositie-relatie met KeyPeg, multipliciteit 0..4

Fig. 1: Domeinmodel Mastermind.

Dit voorbeeld is de v2-variant uit het stappenplan: het model gebruikt aggregate en root, maar toont de samenhang met klassieke UML-compositie in plaats van de aggregate-boundary 'rectangle' die in DoEx standaard was. Beiden vormen zijn toegestaan in SoEx, maar begin uiteraard met de simpelere v1 variant zonder aggregate en ingewikkeldere 'OO relaties'.

NB: Sommige concepten uit het domein, zoals Guess, hebben we in dit voorbeeld NIET als aparte entiteit gemodelleerd (wel nog als aggregatie-relatie). Dat is in de beoogde applicatie niet nodig is. Dit kwam niet voor in de gedigitaliseerde to-be domain stories; de gebruiker doet de guess door een Row te vullen). In een toekomstige uitbreiding (zie figuur 2), komt mogelijk wel/meer functionaliteit rondom 'guesses', maar dat is software ontwerp nu buiten scope.

"Everything should be made as simple as possible, but not simpler" — Albert Einstein

2.2 Voorbeeld begrippenlijst Mastermind​

Onderstaande begrippenlijst/'glossary' licht de entiteiten uit het domein model toe. We geven voorbeeld waarden van kleuren, en laten keuzes klasse of enum als PegColour voor de implementatie fase. Voor bondigheid hebben we rijen CodePeg en KeyPeg hier weggelaten, maar in je eigen documentatie/SGB moet glossary wel compleet zijn (tenzij je goede reden geeft iets weg te laten).

Mogelijke toekomstige uitbreiding buiten scope

Fig. 2: Mogelijke toekomstige uitbreiding die 'marketing' (nu buiten scope).

BegripKorte toelichting
BoardDe aggregate root met de geheime CodePattern en de gespeelde Row items.
RowEÊn door codebreaker gespeelde regel met een ingevoerde CodePattern en bijbehorende KeyPattern feedback van codemaker.
CodePatternEen patroon van precies 4 CodePeg waarden zonder dubbelen, bijvoorbeeld BLUE-GREEN-PURPLE-YELLOW.
KeyPatternFeedback op een 'guess', opgebouwd uit KeyPeg waarden (BLACK, WHITE, EMPTY).
Voorbeeld casus FilmFestival

2.3 Voorbeeld FilmFestival domeinmodel​

Dit voorbeeld gebruikt een meer zakelijke business case dan Mastermind, met domeinconcepten rond programmering, planning, conflicten en kaartverkoop bij een Filmfestival.

dc2821fd195267e08ba3e7f4ad61aab5

PlantUML broncode voor "FilmFestival - Domeinmodel"
@startuml
title FilmFestival - Domeinmodel v2 (met aggregates)

hide methods
hide circle

class Programma <<Aggregate Root, Entity>>
class Vertoning <<Aggregate Root, Entity>>
class Film <<Aggregate Root, Entity>>
class Agenda <<Aggregate Root, Entity>>
class Dagplanning <<Aggregate Root, Entity>>
class Onderdeel <<Value Object>>
class Planningsconflict <<Value Object>>
class Favoriet <<Aggregate Root, Entity>>
class Locatie <<Value Object>>
class Kaartje <<Aggregate Root, Entity>>

Programma o-- "1..*" Vertoning : bevat
Vertoning o-- "1" Film : verwijst naar
Vertoning *-- "1" Locatie : vindt plaats op

Agenda o-- "1..*" Dagplanning : bevat
Agenda o-- "0..*" Favoriet : wensenlijst

Dagplanning *-- "0..*" Onderdeel : planning
Dagplanning *-- "0..*" Planningsconflict : bevat mogelijke conflicten
Onderdeel o-- "1" Vertoning : verwijst naar
Planningsconflict o-- "2..*" Onderdeel : bestaat uit

Favoriet o-- "1" Film : verwijst naar
Kaartje o-- "1" Vertoning : toegang tot
@enduml

Klassendiagram met 10 klasse(n) en 11 relatie(s).

Klassen:

  • Klasse Programma met stereotype Aggregate Root, Entity zonder methoden en attributen
  • Klasse Vertoning met stereotype Aggregate Root, Entity zonder methoden en attributen
  • Klasse Film met stereotype Aggregate Root, Entity zonder methoden en attributen
  • Klasse Agenda met stereotype Aggregate Root, Entity zonder methoden en attributen
  • Klasse Dagplanning met stereotype Aggregate Root, Entity zonder methoden en attributen
  • Klasse Onderdeel met stereotype Value Object zonder methoden en attributen
  • Klasse Planningsconflict met stereotype Value Object zonder methoden en attributen
  • Klasse Favoriet met stereotype Aggregate Root, Entity zonder methoden en attributen
  • Klasse Locatie met stereotype Value Object zonder methoden en attributen
  • Klasse Kaartje met stereotype Aggregate Root, Entity zonder methoden en attributen

Relaties:

  • Programma heeft een aggregatie-relatie met naam 'bevat' met Vertoning, multipliciteit 1..*
  • Vertoning heeft een aggregatie-relatie met naam 'verwijst naar' met Film, multipliciteit 1
  • Vertoning heeft een compositie-relatie met naam 'vindt plaats op' met Locatie, multipliciteit 1
  • Agenda heeft een aggregatie-relatie met naam 'bevat' met Dagplanning, multipliciteit 1..*
  • Agenda heeft een aggregatie-relatie met naam 'wensenlijst' met Favoriet, multipliciteit 0..*
  • Dagplanning heeft een compositie-relatie met naam 'planning' met Onderdeel, multipliciteit 0..*
  • Dagplanning heeft een compositie-relatie met naam 'bevat mogelijke conflicten' met Planningsconflict, multipliciteit 0..*
  • Onderdeel heeft een aggregatie-relatie met naam 'verwijst naar' met Vertoning, multipliciteit 1
  • Planningsconflict heeft een aggregatie-relatie met naam 'bestaat uit' met Onderdeel, multipliciteit 2..*
  • Favoriet heeft een aggregatie-relatie met naam 'verwijst naar' met Film, multipliciteit 1
  • Kaartje heeft een aggregatie-relatie met naam 'toegang tot' met Vertoning, multipliciteit 1

Fig. 3: Domeinmodel Filmfestival

Interpretatie van het model: een dagplanning kan nul of meer Planningsconflict-objecten bevatten tussen ingeplande onderdelen. De gebruiker bewaakt daarmee de haalbaarheid van de dagplanning.

2.4 Voorbeeld Begrippenlijst (FilmFestival)​

Deze begrippenlijst licht de domeintermen uit het figuur 3 kort toe. Voor conciseness zijn properties hier niet volledig uitgewerkt; zo is bijvoorbeeld conflictSoort van Planningsconflict niet opgenomen. Tijdens realisatie en refinement valideren developers zulke details tegen de originele opdrachtbeschrijving en de fine-grained domain stories.

BegripBeschrijving
ProgrammaOverzicht van alle vertoningen van alle films op alle dagen van een editie.
VertoningMoment waarop een specifieke film wordt gedraaid, met locatie, datum en starttijd.
AgendaComplete overzicht van dagplanningen van een festivalbezoeker.
DagplanningGeplande vertoningen van een festivalbezoeker (of groep) voor een specifieke dag.
OnderdeelEen door de bezoeker ingeplande vertoning binnen een dagplanning.
PlanningsconflictIndicatie dat geplande vertoningen overlappen en dus niet allebei bezocht kunnen worden.
FilmInformatie over de film, zoals titel en speelduur.
LocatiePlaats van een vertoning (gebouw, adres, zaal).
KaartjeBewijs om een specifieke vertoning te kunnen bijwonen.
FavorietFilm die een bezoeker wil zien, met status of deze al ingepland is.

3. Q&A over C4 en context diagrammen​

4. Context diagram maken voor de Casusopdracht​

Als er tijd over is, dan is er alvast gelegenheid om te beginnen met het context diagram.