Lesprogramma
1 Introductie van de werkwijze
We bespreken de onderstaande zaken:
- Docenten
- Werkwijze
- Hoe ziet een week eruit
- Huiswerk
- Weekopdracht
- Toetsing
- GitHub Classroom
- IntelliJ
en zorgen ervoor dat iedereen klaar is om met het vak te beginnen.
Ook laten we zien wat we in deze week gaan doen en leggen we de weekopdracht kort uit.
2 Context van een informatiesysteem
Wat denk je dat er allemaal komt kijken bij het runnen van een boerderij?
Het geheel van ‘de werkelijkheid’ waar een systeem op gebaseerd is, noemen we het domein.
📺 Bekijk klassikaal deze video: Hoe gebruikt een boer moderne technieken? | Schooltv
Wat moet het systeem allemaal weten om boeren te helpen bij hun beslissingen?
3 Analyseren van het domein
in groepjes aan de slag met de opdracht om entiteiten, attributen en relaties te identificeren voor dit probleem(domein):
Jullie bouwen een systeem voor een aardappelboer die via een dashboard wil zien hoe zijn percelen erbij liggen en wanneer hij moet zaaien/oogsten/bemesten.
Vervolgens presenteert elk groepje kort (2-3 minuten) hun inzichten waarop we klassikaal proberen tot één gezamenlijk domeinoverzicht te komen op basis van de input.
Een dergelijk overzicht van het domein met entiteiten, attributen en relaties noemen we ook wel een domeinmodel.
Een domeinmodel geeft geen enkele informatie over hoe de actor (aardappelboer) kan/wil interacteren met het systeem om zijn doel te bereiken. We noemen dit dan ook wel een statisch model van het domein, maar in de volgende les gaan we kijken naar domain storytelling om ook de interactie inzichtelijk te maken. We noemen zo'n model van (gewenst) gedrag ook wel een dynamisch model.
Ditzelfde patroon hebben jullie misschien al eens gezien bij het beschrijven van een gerealiseerde oplossing met een klassendiagram (statisch model) en bijbehorende sequentiediagrammen (dynamisch model) in UML. Volgende week komt aan bod hoe het (probleem) domein terug kan komen in de oplossing.
:::
4 Modelleren van Mastermind
De weekopdracht van week 1 draait om het modelleren van het domein van het spel Mastermind. Lees de casus voor meer informatie over het probleem (domein) waar je deze week een oplossing (domein) voor in kaart gaat brengen.
📖 casusbeschrijving van week 1 is hier te vinden: <jouw repo van week 1>/weekopdracht/casusbeschrijving/README.md>.
Wellicht heb je dit spel zelf in bezit of ken je iemand die het spel heeft, dan is het helpend om dit spel weer eens te spelen. Daarbuiten kun je dit ook met een digitale variant spelen. Hierbij ben je echter alleen 'code breaker'. De beoogde applicatie uit de weekopdracht gaat juist de rol van 'code maker' pakken (het zetten van witte en zwarte pinnetjes), maar in je domein analyse ga je het hele spel modelleren: zowel code breaker als code maker en het bord waarop ze spelen en de onderliggende regels.
Een 'computerspel' is geen typisch 'domein', meestal werk je in een bepaald bedrijf met een bepaald domein.
Denk voor een complex domein Bijvoorbeeld aan netwerkbeheerder 'Alliander' in Arnhem die voor het stroomnetwerk van Gelderland en andere delen van het land het 'middenspanning' deel verzorgt. Alliander heeft hier eigen ICT'ers voor in dienst die software schrijven met bijvoorbeeld overzichten van storingen en onderhoudsplanningen.
Ook kun je voor een ICT concultancy bedrijf die software maakt voor meerdere klanten in verschillende domeinen.
Een spel is echter ook een domein, en ook een goed domein om mee te beginnen, omdat het zijn eigen concepten en regels heeft en een meer afgebakend domein dat je sneller kunt exploreren. We focussen hierbij minder op de visuele vormgeving en bediening zoals je bij OOPD deed, maar meer op de logica en structuur van het spel.
Bij voldoende tijd kun je alvast aan de slag met de voorbereiding op de volgende les, en hierbij ook benodigde stukken (H1 en H2) uit de reader lezen en/of oefenen met Domain Storytelling tool egon.io.