Oefencatalogus, niveaus, categorieën en oefeningen

7.1 Doel

De oefencatalogus beschrijft de functionele samenhang tussen niveaus, centrale categorieën, niveau-categorie-koppelingen, concrete oefeningen en technische modules.

Dit hoofdstuk legt vast hoe deze objecten samen bepalen:

• welk oefenaanbod een leerling ziet;
• welke onderwijsinhoud een docent beheert;
• welke centrale onderhoudsacties door beheer worden uitgevoerd;
• welke configuratie door technische modules wordt geleverd;
• welke historische context behouden blijft voor resultaten, geschiedenis, PDF-export, delen en live meekijken.

De oefencatalogus is geen volledige kopie van de onderliggende usecases, schermdocumentatie, database-informatie of modulehandleidingen. Die bronnen blijven leidend voor procesdetails, schermspecifieke onderdelen, technische opslagvelden, modulevelden en popupteksten.

Dit FO-hoofdstuk beschrijft vooral de domeingrenzen, bron van waarheid, zichtbaarheid, lifecycle, autorisatie en samenhang tussen catalogusobjecten.

7.2 Domeinafbakening

Onderdeel	Binnen dit hoofdstuk	Buiten dit hoofdstuk
Niveaus	Functionele betekenis, open/privé/inactief, eigenaarschap, collaborators en leerlingtoegang als context voor oefenaanbod.	Volledige docent-leerlingrelatieflow, relatie-uitnodigingen en detailbeheer van leerlingautorisaties.
Centrale categorieën	Centrale identiteit, hergebruik, status, migratie en effect op niveaukoppelingen.	Volledige beheer-GUI voor categorieën en alle schermspecifieke invoervelden.
Niveau-categorieën	Koppeling tussen docentniveau en centrale categorie, volgorde, afgeleide actieve status en leerlingzichtbaarheid.	Vrije categorievarianten per docent of aparte privé-categorieën.
Concrete oefeningen	Functionele oefening binnen niveau-categoriecontext, status, naam, icoon, moduleverwijzing, configuratie en audit.	Modulespecifieke volledige configuratiehandleiding en leerlingvraagweergave per module.
Technische modules	Functionele grens tussen oefening en module, modulekeuze, modulebeschikbaarheid en beheerimpact.	Technisch implementatieontwerp, codecomponenten, dependency injection en interne modulecode.
Moduleconfiguratiepayload	Functionele rol van JSON/base64, moduleKey, schemaVersion en modulevalidatie.	Een volledige technische schema-specificatie per module.
Leerlingzichtbaarheid	Afgeleide zichtbaarheid van niveaus, categorieën en oefeningen binnen actuele context.	Volledige leerling-run-lifecycle, resultaten, geschiedenis en PDF-export.
Historische context	Effect van wijzigingen op bestaande runs, gedeelde oefeningen en resultaten.	Detailweergave van resultaatpopup, statistiekberekening en exportlayout.

Een wijziging in één laag mag niet impliciet brondata in een andere laag wijzigen.

Voorbeelden:

• een categoriemigratie herschrijft geen afgeronde runs;
• een modulemigratie herschrijft geen oude resultaatpayloads;
• een oefening in onderhoud zetten verwijdert geen geschiedenis;
• een ingetrokken niveauautorisatie verwijdert geen historische resultaten;
• een beheerwijziging aan modulemetadata wijzigt niet automatisch concrete docentconfiguraties.

7.3 Bronpositie

De oefencatalogus gebruikt meerdere bronlagen.

Bronlaag	Betekenis voor dit hoofdstuk
FO	Beschrijft de functionele samenhang tussen catalogusobjecten, zichtbaarheid en domeingrenzen.
Usecases	Beschrijven procesflows voor openen, selecteren, aanmaken, koppelen, configureren, activeren, testen, migreren en autoriseren.
Schermdocumentatie	Beschrijft zichtbare schermonderdelen, acties, lege toestanden, waardelagen en schermspecifieke UI-context.
Database-informatie	Beschrijft brondata, readmodels, history, persistente grenzen en payloadopslag.
Oefenmodule-documentatie	Beschrijft modulevelden, modulevalidatie, vraaggeneratie, runtimeopties en voorbeeldpayloads.
Ontwerpbronnen	Beschrijven business rules, autorisatiematrix, statusmodellen, command-register, event-register en popupregister.
Mockups	Ondersteunen visuele interpretatie, maar zijn geen bron voor definitieve productieaantallen of autorisatieregels.

Het FO mag de kern van deze bronnen functioneel samenvatten, maar dupliceert geen volledige usecases, schermdocumentatie, databasekolommen of moduleconfiguraties.

7.4 Domeinobjecten en bron van waarheid

Object	Functionele betekenis	Bron van waarheid
Niveau	Onderwijscontext zoals groep, klas of leerjaar waarbinnen een docent onderwijsinhoud structureert.	TeacherLevels
Niveau-eigenaarschap	Actuele eigenaar van een niveau en eventuele overdracht.	TeacherLevels.OwnerTeacherUserId, TeacherLevelOwnershipTransfers
Collaborator	Extra docent met bewerkrecht op één niveau.	TeacherLevelCollaborators
Centrale categorie	Gedeelde onderwijsinhoudelijke tag met centrale naam, kleur en icoon.	Categories, CategoryHistory
Categoriemigratie	Auditbare samenvoeging of omzetting van een broncategorie naar een doelcategorie.	CategoryMigrations, CategoryHistory
Niveau-categorie	Koppeling tussen één niveau en één centrale categorie.	TeacherLevelCategories
Concrete oefening	Configureerbare oefening binnen niveau-categoriecontext.	Exercises, TeacherLevelCategoryExercises
Oefeninghistorie	Auditlaag voor wijzigingen aan concrete oefeningen.	ExerciseHistory
Technische module	Administratief vrijgegeven technische oefenmodule.	ExerciseModules
Modulemigratie	Beheeractie die concrete oefeningen naar een andere modulecontext kan overzetten.	Modulemigratieregistratie en ExerciseHistory
Oefenrun	Uitvoering van een oefening door een gebruiker, met context, voortgang en resultaten.	ExerciseRuns, ExerciseRunProgress
Gedeelde oefening	Administratief ontvangen shared-record vóórdat de ontvanger eventueel een eigen run start.	SharedExercises

Readmodels, overzichten, tellers, filters, categoriekaarten, module-impactwaarden en badges zijn afgeleid uit deze brondata. Zij vormen geen tweede bron van waarheid.

7.5 Functionele hoofdstructuur

De catalogusstructuur loopt functioneel van grof naar concreet:

1. een docent beheert één of meer niveaus;
2. een niveau koppelt centrale categorieën;
3. een niveau-categorie bevat concrete oefeningen;
4. een concrete oefening verwijst naar precies één technische module;
5. de module levert configuratievelden, validatie en vraaggeneratie;
6. een leerling start vanuit een toegankelijke concrete oefening een oefenrun;
7. de run bewaart de historische context en voortgang.

Deze structuur is belangrijk omdat mutaties op een hoger niveau niet automatisch lagere historische context herschrijven.

Voorbeelden:

• een wijziging aan de centrale categorienaam raakt actuele catalogusweergave, maar niet automatisch opgeslagen snapshotwaarden van gedeelde oefeningen;
• een ingetrokken collaborator verliest nieuw bewerkrecht, maar oude ExerciseHistory blijft bestaan;
• een module die inactief wordt, kan nieuwe starts blokkeren, maar oude runresultaten blijven historisch uitleesbaar;
• een niveau dat inactief wordt, verdwijnt als actuele leerlingcontext, maar blijft als historische context in runs bestaan.

7.6 Verantwoordelijkheden per rolcontext

Rolcontext	Verantwoordelijkheid binnen de oefencatalogus	Functionele grens
Leerling	Ziet beschikbare categorieën en actieve oefeningen binnen actuele toegankelijke niveaucontext.	Kan geen categorieën, niveaus, oefeningen of moduleconfiguraties beheren.
Docent	Beheert eigen niveaus, categorie-koppelingen, concrete oefeningen, configuratie, status en docenttesten.	Beheer is begrensd tot eigen niveaus of niveaus waarop de docent actieve collaborator is.
Collaborator	Werkt mee aan onderwijsinhoud binnen een specifiek niveau.	Krijgt geen leerling-, resultaat-, geschiedenis- of live-meekijktoegang door collaboration alleen.
Beheerder	Beheert centrale categorie-identiteit, categoriestatus, categoriemigratie, modulemetadata, modulebeschikbaarheid en modulemigratie.	Beheerdercontext is geen vrije bypass op normale docent- of leerlingflows.
TestDocent	Kan waar toegestaan testzichtbare modules gebruiken binnen expliciete testcontext.	Testzichtbaarheid maakt een module niet regulier beschikbaar voor leerlingen of gewone docenten.
Ouder/voogd	Raadpleegt resultaten en geschiedenis via ouder-/voogdcontext in andere hoofdstukken.	Kan geen oefeningen namens een kind starten, configureren, beantwoorden of activeren.

7.7 Niveaus

Een niveau is de onderwijscontext waarbinnen een docent onderwijsinhoud organiseert.

Een niveau bevat minimaal:

• naam;
• optionele beschrijving;
• actuele eigenaar;
• actief/inactief-status;
• zichtbaarheid voor leerlingtoegang;
• aanmaak- en wijzigingsinformatie;
• gekoppelde categorieën;
• eventuele collaborators;
• eventuele leerlingautorisaties.

Een niveau is docent-specifiek. De naam hoeft niet globaal uniek te zijn, omdat verschillende docenten dezelfde onderwijsnaam kunnen gebruiken voor eigen contexten.

7.8 Niveauvormen

Niveauvorm	Leerlingtoegang	Functionele consequentie
Open niveau	Een leerling mag het niveau als actuele niveaucontext gebruiken wanneer het niveau actief is en de overige toegangseisen kloppen.	Open niveaugebruik maakt geen docent-leerlingrelatie en geen expliciet autorisatierecord aan.
Privéniveau	Een leerling mag het niveau alleen gebruiken via actieve docent-leerlingrelatie en actieve niveauautorisatie.	Toegang vervalt voor nieuw starten en normaal hervatten zodra relatie of autorisatie vervalt.
Inactief niveau	Niet bruikbaar als actuele leerlingcontext.	Historische runs kunnen het niveau nog als opgeslagen context tonen.

Open of privé bepaalt de toegangspoort tot het niveau. Het bepaalt niet zelfstandig of iedere categorie of oefening zichtbaar is. Daarvoor blijven categorie-koppeling, oefeningstatus, modulebeschikbaarheid en server-side contextcontrole nodig.

7.9 Eigenaarschap en collaborators

Een niveau heeft altijd precies één actuele eigenaar.

Daarnaast kan een niveau actieve collaborators hebben. Een collaborator mag onderwijsinhoud binnen dat specifieke niveau bewerken wanneer de collaboration actief is.

Collaboratorrechten betekenen functioneel:

• categorieën binnen het niveau bekijken;
• bestaande centrale categorieën koppelen waar toegestaan;
• concrete oefeningen binnen het niveau beheren;
• oefeningconfiguraties wijzigen waar toegestaan;
• oefeningstatus aanpassen waar toegestaan;
• docenttesten uitvoeren waar toegestaan.

Collaboratorrechten betekenen niet:

• toegang tot leerlingen van de eigenaar;
• toegang tot leerlingresultaten;
• toegang tot leerlinggeschiedenis;
• live meekijken;
• niveauautorisaties aan leerlingen beheren, tenzij een aparte geldige docent-leerlingcontext en autorisatieflow dat toestaan;
• centrale categorie-identiteit beheren;
• technische modules beheren.

Eigenaarschap, collaboration en leerlingtoegang blijven dus drie verschillende lagen.

7.10 Eigendomsoverdracht

Eigendomsoverdracht wijzigt de actuele eigenaar van een niveau.

Bij eigendomsoverdracht geldt:

• het niveau blijft hetzelfde domeinobject;
• gekoppelde categorieën blijven gekoppeld;
• concrete oefeningen blijven bestaan;
• bestaande ExerciseHistory blijft append-only;
• historische runs worden niet herschreven;
• leerlingautorisaties moeten volgens de onderliggende docent- en toegangsregels consistent blijven;
• de oude eigenaar kan eventueel collaborator blijven wanneer de overdrachtsflow dat ondersteunt.

Bij accountverwijdering of anonimisering van een eigenaar mag geen actief verweesd niveau overblijven. De precieze overdrachts- of deactivatieregels blijven bronhoudend in account- en docentstructuurbronnen.

7.11 Centrale categorieën

Categorieën zijn centrale gedeelde domeinobjecten.

Een centrale categorie bevat minimaal:

• naam;
• icoonsleutel;
• kleurwaarde;
• aanmaker;
• aanmaakmoment;
• laatste wijzigingsinformatie;
• soft-delete- of statusinformatie;
• historie.

Naam, kleur en icoon vormen samen de centrale categorie-identiteit. Deze identiteit mag niet per docent, niveau of leerlingcontext afwijken, omdat dezelfde categorie in meerdere niveaus en leerlingweergaven herkenbaar en semantisch gelijk moet blijven.

7.12 Categorie-identiteit

Voor centrale categorieën gelden de volgende regels.

Regel	Betekenis
Eén centrale naam	De zichtbare categorienaam komt uit het centrale categoriemodel.
Eén centrale kleur	De categorie behoudt overal dezelfde kleurwaarde.
Eén centrale icoonkeuze	De categorie behoudt overal dezelfde icoonidentiteit.
Geen docentvariant	Een docent maakt geen eigen verborgen variant met afwijkende betekenis.
Geen niveauvariant	De niveau-koppeling bevat geen afwijkende naam, kleur of icoon.
Beheerbare correctie	Beheer kan centrale gegevens corrigeren wanneer daar een geldige reden voor is.
Auditbaar	Wijzigingen zijn herleidbaar omdat ze meerdere contexten kunnen beïnvloeden.

Een docent kan dus wel een nieuwe centrale categorie aanmaken via de docentflow, maar die categorie wordt daarna onderdeel van het centrale model.

7.13 Categorie aan niveau koppelen

Een niveau-categorie is de koppeling tussen een docentniveau en een centrale categorie.

Deze koppeling bevat contextspecifieke gegevens zoals:

• niveau;
• centrale categorie;
• sortering;
• afgeleide actieve status;
• aanmaakinformatie.

De koppeling bevat niet:

• eigen categorienaam;
• eigen categoriekleur;
• eigen categorie-icoon;
• eigen leerlingautorisatie;
• eigen moduleconfiguratie;
• eigen categoriebeheerstatus buiten de centrale categorie.

Een docent met bewerkrecht op het niveau kan bestaande centrale categorieën koppelen. Het systeem moet dubbele actieve koppelingen tussen hetzelfde niveau en dezelfde centrale categorie voorkomen.

7.14 Effect van categorie koppelen

Het koppelen van een centrale categorie aan een niveau:

• maakt geen nieuwe centrale categorie aan;
• wijzigt geen centrale categorie-identiteit;
• maakt geen concrete oefening aan;
• maakt geen moduleconfiguratie aan;
• wijzigt geen leerlingrelaties;
• wijzigt geen niveauautorisaties;
• maakt de categorie nog niet automatisch zichtbaar voor leerlingen;
• verstuurt niet automatisch systeemberichten aan leerlingen.

Leerlingzichtbaarheid ontstaat pas wanneer binnen dezelfde niveau-categoriecontext minimaal één actieve, startbare concrete oefening beschikbaar is en de leerling toegang heeft tot de niveaucontext.

7.15 Nieuwe categorie via docentflow

Wanneer een docent geen passende bestaande centrale categorie vindt, kan de docent via de docentflow een nieuwe centrale categorie aanmaken.

Daarbij geldt:

• de docent werkt vanuit een geldige docentcontext;
• de docent werkt binnen een geselecteerd niveau;
• de docent kiest naam, kleur en icoon;
• de backend controleert uniciteit en geldigheid;
• de nieuwe categorie wordt centraal opgeslagen;
• de nieuwe categorie wordt gekoppeld aan het geselecteerde niveau;
• de categorie is daarna niet privé voor de docent.

De UI moet de docent stimuleren eerst bestaande categorieën te hergebruiken. Onnodige doublures zijn toegestaan als fouttoestand of menselijke keuze, maar moeten later via beheer kunnen worden gecorrigeerd of gemigreerd.

7.16 Categoriestatus en soft delete

Een centrale categorie kan actief, gedeactiveerd, gemigreerd of soft-deleted zijn volgens beheerregels.

Voor functioneel gedrag geldt:

Toestand	Betekenis voor nieuwe koppelingen	Betekenis voor bestaande historie
Actief	Mag waar toegestaan worden gekoppeld en gebruikt.	Historie blijft normaal herleidbaar.
Gedeactiveerd	Niet normaal kiesbaar voor nieuwe koppelingen.	Bestaande historische context blijft bestaan.
Gemigreerd	Broncategorie is niet langer normaal kiesbaar; doelcategorie is leidend voor nieuw gebruik.	Migratie blijft auditbaar; historische runs worden niet herschreven.
Soft-deleted	Verdwijnt uit normale beheer- en keuzeweergaven waar passend.	Audit en historische verwijzingen blijven behouden.

De exacte beheeracties horen bij het categoriebeheerdomein. FO-07 legt vooral vast dat zulke acties geen onbedoelde herschrijving van historische oefencontext mogen veroorzaken.

7.17 Categoriemigratie

Categoriemigratie is een centrale beheerderactie voor situaties waarin dubbele of semantisch overlappende categorieën zijn ontstaan.

Migratie is niet hetzelfde als:

• hernoemen;
• soft delete;
• deactiveren;
• een categorie uit één niveau verwijderen;
• een docentflow voor categorie koppelen.

Bij categoriemigratie wordt een broncategorie functioneel omgezet naar een bestaande doelcategorie.

7.18 Regels voor categoriemigratie

Regel	Functionele betekenis
Bestaande doelcategorie	De doelcategorie moet bestaan en verschillen van de broncategorie.
Verplichte reden	De beheerder geeft een reden op die auditbaar wordt vastgelegd.
Impactanalyse	Vóór uitvoering wordt bepaald welke niveaus, categorie-koppelingen en oefeningen geraakt worden.
Herberekening vlak vóór uitvoering	De backend herberekent impact en conflicten vlak vóór opslaan.
Geen dubbele koppelingen	TeacherLevelCategories en oefenkoppelingen worden niet blind gedupliceerd.
Conflictbehandeling	Conflicten worden aantoonbaar en controleerbaar afgehandeld.
Transactioneel	Migratierecord, koppelingen, historie en eventuele systeemcommunicatie blijven consistent.
Historie behouden	De broncategorie blijft historisch herleidbaar.
Geen run-herschrijving	Afgeronde runs, gedeelde-oefening-snapshots, resultaatcontexten en PDF-contexten behouden hun historische context.

Betrokken docenten kunnen via systeemcommunicatie worden geïnformeerd wanneer de beheerflow dit ondersteunt. De tekst van zulke communicatie blijft bronhoudend in systeemberichttemplates.

7.19 Concrete oefeningen

Een concrete oefening is een configureerbare oefening binnen één niveau-categoriecontext.

Een concrete oefening bevat minimaal:

• generieke oefeningnaam;
• generiek oefeningicoon;
• status actief/in onderhoud;
• verwijzing naar technische module;
• modulespecifieke configuratiepayload;
• aanmaak- en wijzigingsinformatie;
• eventuele bronverwijzing bij kopie;
• history.

Een concrete oefening is niet hetzelfde als een technische module.

Concrete oefening	Technische module
Docentgerichte onderwijsconfiguratie.	Codegedreven oefenlogica.
Heeft naam en icoon voor catalogusweergave.	Heeft technische CodeReference en modulemetadata.
Hoort bij een niveau-categoriecontext.	Is centraal geregistreerd in modulebeheer.
Bevat modulespecifieke configuratiepayload.	Levert configuratiecomponent, validatie en vraaggeneratie.
Kan actief of in onderhoud zijn.	Kan centraal actief, inactief of testzichtbaar zijn.

7.20 Oefening aanmaken

Een nieuwe concrete oefening ontstaat pas na succesvol opslaan van de configuratieflow.

Daarvoor moet minimaal gelden:

1. de docent heeft een geldige actieve docentcontext;
2. er is een geselecteerd niveau;
3. de docent is eigenaar of actieve collaborator met bewerkrecht op dat niveau;
4. er is een geldige niveau-categoriecontext;
5. de gekozen technische module is beschikbaar binnen de actuele rol- en testcontext;
6. generieke oefeninggegevens zijn geldig;
7. modulespecifieke configuratie is geldig volgens de module;
8. de opslagactie wordt server-side opnieuw geautoriseerd.

Het openen van de pagina Nieuwe oefening of het selecteren van een technische module maakt nog geen concrete oefening aan.

7.21 Oefeningmetadata

Naam en icoon van een concrete oefening horen bij de oefening zelf.

Zij zijn functioneel bedoeld voor:

• catalogusweergave;
• leerlingfrontpage;
• categorie-overzichten;
• oefeningstartpagina;
• resultaatcontext;
• geschiedenis;
• PDF-context;
• docentoverzichten.

Wanneer dezelfde waarden ook in de modulepayload voorkomen voor moduleweergave of configuratiegemak, moet duidelijk blijven welke laag leidend is.

Waarde	Leidende laag
Catalogusnaam van de oefening	Generieke oefeningmetadata.
Catalogusicoon van de oefening	Generieke oefeningmetadata.
Module-interne displayvelden	Moduleconfiguratiepayload, voor zover modulespecifiek.
Vraaginhoud	Run- en voortgangspayload zoals gegenereerd vanuit moduleconfiguratie.

De generieke oefeningmetadata blijft leidend voor catalogusweergave.

7.22 Oefeningstatus en activering

De concrete oefeningstatus wordt functioneel gedragen door de actieve status van de oefening.

Status	Betekenis	Gevolgen
In onderhoud	De oefening bestaat, maar is niet beschikbaar voor normale leerlingstarts.	Niet zichtbaar of startbaar voor leerlingen; wel beheerbaar en testbaar door bevoegde docentcontext.
Actief	De oefening is door een bevoegde docent actief gezet.	Kan zichtbaar en startbaar worden wanneer niveau-, categorie-, autorisatie- en modulecontext geldig zijn.

Een nieuwe oefening start standaard in onderhoud.

Activeren vereist minimaal:

• geldige generieke oefeningmetadata;
• geldige moduleconfiguratie;
• beschikbare technische module;
• geldige niveau-categoriecontext;
• bevoegde docentcontext;
• server-side validatie op het moment van activeren.

In onderhoud zetten voorkomt nieuwe leerlingstarts, maar verwijdert geen afgeronde geschiedenis, resultaten, PDF-exportcontext of gedeelde-oefening-snapshots.

7.23 Oefening kopiëren

Een docent kan een open of toegankelijke oefenconfiguratie als uitgangspunt gebruiken wanneer de onderliggende usecase dat toestaat.

Kopiëren betekent:

• er ontstaat een nieuwe concrete oefening;
• de nieuwe oefening krijgt eigen naam, icoon, configuratie en status;
• de bron blijft ongewijzigd;
• wijzigingen in de kopie werken niet terug naar de bron;
• de kopie kan een bronverwijzing krijgen voor analyse en groepering;
• de kopie start volgens de normale statusregels, meestal in onderhoud.

Kopiëren is dus geen gedeelde live-referentie naar dezelfde oefeningconfiguratie.

7.24 Moduleconfiguratiepayload

De modulespecifieke configuratie van een concrete oefening wordt generiek opgeslagen als JSON/base64-payload.

De technische module bepaalt:

• welke configuratievelden bestaan;
• welke velden verplicht zijn;
• welke combinaties geldig zijn;
• hoe vraaggeneratie plaatsvindt;
• hoe antwoordvalidatie werkt;
• welke module-instellingen doorwerken in leerlingweergave;
• welke module-instellingen doorwerken in resultaten.

OefenHub bepaalt:

• contextcontrole;
• opslaglocatie;
• oefeningstatus;
• auditregistratie;
• koppeling aan niveau en categorie;
• koppeling aan technische module;
• startbaarheid voor leerlingen;
• generieke run-lifecycle;
• generieke resultaat- en geschiedeniscontext.

7.25 moduleKey en schemaVersion

Binnen de bestaande oefeningconfiguratiepayload zijn moduleKey en schemaVersion leidend voor module- en schemaherleidbaarheid.

Er wordt geen extra generieke databasekolom geïntroduceerd voor schemaherleidbaarheid zolang deze bestaande payloadvelden de benodigde herleidbaarheid bieden.

Payloadveld	Functionele betekenis
moduleKey	Herleidt welke modulefamilie of modulevariant de configuratie inhoudelijk beschrijft.
schemaVersion	Herleidt welk configuratieschema door de module verwacht wordt.

De administratieve moduleverwijzing op de oefening blijft daarnaast nodig om de technische module in OefenHub te koppelen aan ExerciseModules.

Deze twee lagen vullen elkaar aan:

• ExerciseModules bepaalt welke technische module administratief gekozen is;
• de payload beschrijft de modulespecifieke configuratie en schemaherleidbaarheid;
• runpayloads bewaren de vraag- en voortgangscontext van een concrete uitvoering.

7.26 Voorbeelden van modulevelden

Een modulepayload kan onder meer velden bevatten voor:

• operation mode of vraagtype;
• getalbereiken;
• exacte toegestane waarden;
• uitkomstgrenzen;
• balansregels;
• standaard/minimum/maximum aantal vragen;
• beperkingen op vraaggeneratie;
• allowMarkAsDunno;
• showAnswerAfterSubmit;
• module-interne displaywaarden.

Deze velden worden niet als generieke cataloguskolommen gemodelleerd wanneer zij alleen voor één module of modulefamilie betekenis hebben.

Alleen gegevens die platformbreed querybaar, autorisatiegevoelig, historisch verplicht of domeinbreed herbruikbaar zijn, horen buiten de payload relationeel beschikbaar te zijn.

7.27 Technische modules

Technische modules worden administratief beheerd in ExerciseModules.

Een technische module bevat minimaal of conceptueel:

• leesbare naam;
• technische CodeReference;
• versie-informatie;
• actiefstatus;
• testzichtbaarheid;
• connectiviteits- of beschikbaarheidsinformatie;
• gebruiksimpact;
• beheerhistorie.

Modules worden niet runtime ontdekt door docenten. Een docent kiest uit modules die administratief beschikbaar zijn gesteld.

De technische implementatie wordt pas aangesproken wanneer de generieke applicatie op basis van de moduleverwijzing en module-strategie de juiste component nodig heeft.

7.28 Modulebeheer versus oefeningbeheer

Beheeractie	Domein	Wat wordt gewijzigd	Wat wordt niet gewijzigd
Modulegegevens wijzigen	Beheerder — modules	Modulemetadata zoals weergavenaam of status, waar toegestaan.	Concrete oefeningnaam, icoon of docentconfiguratie.
Module actief/inactief zetten	Beheerder — modules	Beschikbaarheid van technische module voor nieuw gebruik of inzet.	Historische runs en resultaten.
Testzichtbaarheid wijzigen	Beheerder — modules	Beschikbaarheid voor testcontexten.	Reguliere leerlingbeschikbaarheid.
Modulemigratie	Beheerder — modules	Expliciet geselecteerde oefening- of modulekoppelingen volgens migratieregels.	Oude runpayloads, resultaten en historische PDF-context.
Oefening configureren	Docent — oefeningen	Concrete oefeningmetadata en moduleconfiguratiepayload.	Centrale modulemetadata.

Modulebeheer is dus geen verborgen ingang om docentconfiguraties inhoudelijk te bewerken.

7.29 Modulebeschikbaarheid

Voor modulebeschikbaarheid gelden meerdere lagen.

Laag	Betekenis
Administratief actief	Module mag regulier worden gebruikt wanneer overige context klopt.
Testzichtbaar	Module mag zichtbaar zijn voor expliciete testcontexten, zonder reguliere beschikbaarheid.
Technisch koppelbaar	CodeReference kan door de applicatie naar een module-implementatie worden vertaald.
Configuratie geldig	De opgeslagen oefeningconfiguratie past bij de module en schemaVersion.
Startbaar	De oefening kan door een leerling gestart worden binnen actuele context.

Een module kan administratief bestaan maar niet startbaar zijn voor leerlingen.

Voorbeelden:

• module is alleen testzichtbaar;
• module is inactief;
• moduleconfiguratie is ongeldig geworden;
• technische moduleimplementatie is niet beschikbaar;
• gekoppelde concrete oefening staat in onderhoud;
• leerling heeft geen toegang tot de niveaucontext.

7.30 Docenttesten

Een docent kan een concrete oefening testen binnen een oefeningcontext die hij of zij mag beheren.

Een docenttest gebruikt zoveel mogelijk dezelfde generieke run- en modulemechanismen als een leerlingrun, maar blijft functioneel testdata.

Een docenttest:

• gebruikt de actuele oefeningconfiguratie;
• gebruikt de gekoppelde technische module;
• mag tijdelijke voortgang opslaan zolang de test actief is;
• wordt als testrun gemarkeerd;
• levert geen permanente leerlinggeschiedenis op;
• telt niet mee voor populaire categorieën;
• telt niet mee voor recent geoefend;
• telt niet mee voor normale leerling-, docent- of ouderresultaten;
• activeert de oefening niet;
• wijzigt de oefeningconfiguratie niet;
• wordt na afronding, verlaten of geplande opruiming verwijderd of buiten normale geschiedenis gehouden volgens de testdataregels.

Testbaarheid is bedoeld om configuratie en modulegedrag te controleren. Testresultaten zijn geen historische onderwijsresultaten.

7.31 Leerlingzichtbaarheid

De leerling ziet geen vrije catalogus van alle niveaus, categorieën, oefeningen of modules.

De leerlingweergave is een server-side afgeleid readmodel op basis van minimaal:

• actieve leerlingrol;
• actieve accountstatus;
• actuele niveaucontext;
• open- of privéniveauregels;
• actieve docent-leerlingrelatie waar vereist;
• actieve niveauautorisatie waar vereist;
• actieve niveau-categorie-koppeling;
• actieve concrete oefening;
• modulebeschikbaarheid;
• oefeningstatus;
• eventuele feature- of systeeminstellingen;
• actuele server-side autorisatie.

Zichtbare UI is nooit autorisatiebewijs.

7.32 Zichtbaarheidsregels voor leerlingen

Element	Zichtbaar voor leerling wanneer	Startbaar voor leerling wanneer
Niveau	Het niveau actief is en de leerling het niveau als context mag gebruiken.	Niet van toepassing; niveau is context, geen oefening.
Categorie	De categorie binnen de actuele niveaucontext actief is en minimaal één onderliggende oefening beschikbaar is.	Niet rechtstreeks startbaar; categorie leidt naar oefeningen.
Oefening	De oefening actief en beschikbaar is binnen toegankelijke categorie- en niveaucontext.	De oefening actief is, de module bruikbaar is en de actuele leerlingcontext toegang heeft.
Oefening in onderhoud	Niet zichtbaar in reguliere leerlingcatalogus.	Niet startbaar.
Niet-afgeronde run	Niet als nieuwe catalogusoefening, maar als hervatbare context waar toegestaan.	Hervatbaar wanneer dezelfde oefening en actieve niveaucontext nog geldig zijn.
Historische run	Alleen via geschiedenis/resultaatcontext.	Niet als actuele startautorisatie.

Wanneer toegang later vervalt, blokkeert dit nieuw starten en normaal hervatten binnen die context. Historische raadpleging volgt de regels van resultaten en geschiedenis.

7.33 Frontpage en categorie-ingangen

De leerling-frontpage en headercategorieën tonen alleen afgeleide beschikbare categorieën binnen de actuele leerling- en niveaucontext.

Voor frontpageblokken geldt:

• populaire categorieën worden afgeleid uit afgeronde runs binnen toegankelijke context;
• recent geoefend gebruikt afgeronde runs binnen relevante context;
• verder oefenen verwijst alleen naar een hervatbare niet-afgeronde run binnen dezelfde oefening en actieve niveaucontext;
• lege toestanden zijn normaal wanneer geen toegankelijke categorieën of oefeningen beschikbaar zijn;
• frontpage- en headerweergave zijn geen autorisatiebewijs.

De structurele frontpageprincipes blijven bronhoudend in het frontpagehoofdstuk. FO-07 beschrijft alleen hoe de catalogusdata daaraan bijdraagt.

7.34 Oefeningstartpagina

De oefeningstartpagina van een leerling wordt alleen geopend nadat server-side is vastgesteld dat de oefening binnen de actuele context toegankelijk is.

De zichtbare acties worden afgeleid uit dezelfde controle.

Actie	Beschikbaarheid	Functionele grens
Verder gaan	Alleen wanneer een hervatbare niet-afgeronde run bestaat binnen dezelfde oefening en actieve niveaucontext.	Hervat geen runs uit andere niveaus of niet langer toegankelijke contexten.
Start nieuwe	Alleen wanneer de oefening actief en startbaar is.	Start pas na expliciete leerlingactie en geldige server-side controle.
Geschiedenis	Beschikbaar volgens resultaat- en geschiedenisregels.	Historische raadpleging geeft geen actuele starttoegang.

De leerling kan op de startpagina het aantal vragen kiezen voor modules die dit ondersteunen. Modulespecifieke configuratie wordt hier niet door de leerling beheerd.

7.35 Starten en hervatten in relatie tot de catalogus

Een nieuwe run ontstaat pas na een expliciete startactie vanuit een toegankelijke oefening.

Bij starten wordt de run gekoppeld aan minimaal:

• gebruiker;
• niveau;
• categorie;
• concrete oefening;
• technische module;
• geldende configuratiecontext;
• vraagpayload;
• voortgangsdata.

Hervatten gebruikt de laatst gestarte niet-afgeronde run binnen dezelfde oefening en actieve niveaucontext, voor zover die run nog normaal hervatbaar is.

Niet-afgeronde runs uit andere niveaus of niet langer toegankelijke contexten worden niet als normale hervatoptie aangeboden.

7.36 Historische runs

Exercise runs bewaren de relevante context van het moment van genereren, starten en afronden.

Daarmee blijven resultaten en geschiedenis uitleesbaar wanneer later:

• een categorie wordt hernoemd;
• een categorie wordt gemigreerd;
• een niveau inactief wordt;
• een oefening in onderhoud wordt gezet;
• een module inactief wordt;
• een modulemigratie plaatsvindt;
• een docentrelatie wordt beëindigd;
• een niveauautorisatie wordt ingetrokken.

Historische runs zijn bron voor:

• resultaatweergave;
• geschiedenis;
• PDF-export;
• ouder-/voogdresultaten;
• docentresultaten binnen docentcontext;
• live-meekijken tijdens lopende run;
• gedeelde-oefeningcontext waar van toepassing.

Historische runs worden niet gebruikt als actuele catalogusautorisatie.

7.37 Gedeelde oefeningen en cataloguscontext

Een gedeelde oefening verwijst naar een bronrun en bevat snapshotwaarden voor niveau, categorie en oefening.

Voor de catalogus betekent dit:

• delen maakt geen nieuwe centrale categorie aan;
• delen maakt geen nieuwe concrete oefeningconfiguratie aan op het moment van delen;
• de ontvanger krijgt eerst een administratief shared-record;
• pas bij daadwerkelijk starten ontstaat een eigen run voor de ontvanger;
• snapshotwaarden blijven staan zoals ze golden op het moment van delen;
• latere categoriemigratie herschrijft het shared-record niet;
• latere naamswijzigingen herschrijven bestaande gedeelde-oefening-snapshots niet.

Gedeelde oefeningen worden inhoudelijk verder uitgewerkt in het hoofdstuk over gedeelde oefeningen.

7.38 Audit en historie

Wijzigingen binnen de oefencatalogus moeten herleidbaar zijn op het juiste niveau.

Wijziging	Audit- of historylaag
Niveau aangemaakt of gewijzigd	Niveau- en docentstructuurhistorie waar voorzien.
Eigendom overgedragen	Eigendomsoverdracht en bijbehorende audit.
Collaborator toegevoegd of ingetrokken	Collaboratorrecord en audit/history.
Centrale categorie gewijzigd	CategoryHistory.
Categorie gemigreerd	CategoryMigrations en categoriehistorie.
Categorie aan niveau gekoppeld	Niveau-categoriebrondata en relevante audit.
Oefening aangemaakt	ExerciseHistory met create-actie.
Oefening gekopieerd	ExerciseHistory met copy-/parentactie.
Oefeningnaam of icoon gewijzigd	ExerciseHistory.
Moduleconfiguratie gewijzigd	ExerciseHistory met module-aangeleverd configitem waar passend.
Oefeningstatus gewijzigd	ExerciseHistory.
Modulemigratie op oefening	Modulemigratieregistratie en ExerciseHistory.

Historyrecords worden niet aangepast of verwijderd door reguliere functionele processen.

Bij gecombineerde wijzigingen mogen meerdere historyrecords ontstaan zodat per aspect zichtbaar blijft wat gewijzigd is.

7.39 Systeemberichten en communicatie

Catalogusmutaties kunnen systeemcommunicatie veroorzaken wanneer een onderliggende usecase dit voorschrijft.

Voorbeelden:

• niveauautorisatie toegekend of ingetrokken;
• collaborator toegevoegd of verwijderd;
• eigendom overgedragen;
• categoriemigratie uitgevoerd;
• modulemigratie uitgevoerd;
• gedeelde oefening ontvangen.

De catalogus zelf bepaalt niet de volledige berichttekst.

Voor systeemcommunicatie gelden de centrale regels:

• systeemberichttemplates blijven leidend voor tekst en placeholders;
• popupteksten worden niet in FO-07 gedupliceerd;
• systeemberichten verwerken geen onderliggende domeinactie automatisch door alleen geopend te worden;
• leerlingen worden tijdens een actieve oefenrun niet afgeleid door badges of systeemnotificatie-overlays.

7.40 Beheerderondersteuning binnen docentcontext

Beheerders kunnen in supportflows docentstructuur, categorieën, oefeningen en modulekoppelingen inspecteren of corrigeren.

Daarbij geldt:

• beheerdercontext wordt server-side bepaald;
• supportacties zijn expliciet en auditbaar;
• beheerdercontext is geen vrije bypass op normale docentflows;
• centrale categorie- en modulebeheeracties blijven in de centrale beheerflows;
• docentondersteuning mag geen verborgen leerling-, resultaat- of live-meekijktoegang creëren buiten expliciete bevoegdheid;
• correcties binnen docentcontext moeten herleidbaar blijven.

7.41 Tellers en readmodels

Overzichten in dit domein tonen vaak aantallen of samenvattingen.

Voorbeelden:

• aantal actieve niveaus;
• aantal categorieën binnen een niveau;
• aantal actieve oefeningen;
• aantal oefeningen in onderhoud;
• aantal actieve docenten per module;
• aantal oefenkoppelingen per module;
• aantal gekoppelde leerlingen per niveau;
• aantal collaborators;
• impact van categoriemigratie;
• impact van modulemigratie.

Per teller moet minimaal duidelijk zijn:

Aspect	Vraag
Domeinobject	Welk object of welke koppeling wordt geteld?
Statusfilter	Tellen alleen actieve records mee?
Soft delete	Worden soft-deleted records uitgesloten?
Context	Is de telling begrensd door docent, niveau, categorie, module of beheercontext?
Testdata	Worden testmodules of testruns uitgesloten?
Distinct-logica	Worden dubbele koppelingen samengevoegd of afzonderlijk geteld?
Autorisatie	Wordt alleen data geteld die de gebruiker binnen die context mag zien?
Tijdvenster	Gaat het om actuele stand, recente wijzigingen of historische impact?

Mockupwaarden zijn voorbeelddata. Zij zijn geen definitieve productieaantallen.

7.42 Autorisatie- en veiligheidsregels

Voor de oefencatalogus gelden de volgende overkoepelende regels.

• Zichtbare UI, routeparameters, filters, bookmarks, browsergeschiedenis en clientstate zijn nooit autorisatiebewijs.
• Iedere categorie-, oefening-, start-, hervat-, beheer-, test- en migratieactie controleert server-side opnieuw de actuele context.
• Leerlingtoegang wordt bepaald op basis van leerlingrol, accountstatus, niveaucontext, open/privéregels, relatie/autorisatie, categorie-koppeling, oefeningstatus en modulebruikbaarheid.
• Docentbeheer werkt alleen binnen niveaus waarop de docent eigenaar of actieve collaborator met bewerkrecht is.
• Collaboratorrechten zijn inhoudsbewerkrechten op niveau-laag en geven geen leerlingresultaat- of live-meekijkrechten.
• Beheerderacties op categorieën en modules zijn centrale onderhoudsacties, geen vrije bewerking van docentflows.
• Ouder-/voogdcontext geeft geen recht om oefeningen namens een kind te starten, hervatten, beantwoorden of configureren.
• TestDocent-context verruimt reguliere leerlingbeschikbaarheid niet.
• Readmodels en tellers zijn afgeleid en mogen toegang nooit verruimen.
• Foutmeldingen mogen geen verborgen categorie-, leerling-, run-, module- of payloaddetails lekken.

7.43 Lege toestanden

Lege toestanden zijn normaal wanneer de gebruiker wel toegang heeft tot de context maar er geen relevante catalogusdata is.

Voorbeelden:

• leerling heeft geen toegankelijke categorieën;
• leerling heeft geen toegankelijke oefeningen binnen een categorie;
• leerling heeft geen hervatbare run;
• docent heeft nog geen niveau;
• docent heeft geen categorieën aan een niveau gekoppeld;
• docent heeft geen oefeningen binnen een categorie;
• er zijn geen beschikbare technische modules voor reguliere oefeningaanmaak;
• er zijn geen testzichtbare modules voor een testcontext;
• beheerder heeft geen categorieën binnen een filter;
• beheerder heeft geen modulemigratie-impact;
• er zijn geen conflicten bij een migratieproef.

Een lege toestand mag informatief zijn en naar een passende vervolgstap verwijzen, maar mag geen verborgen autorisatie- of foutdetails lekken.

7.44 Fouttoestanden

Fouttoestanden ontstaan wanneer cataloguscontext niet veilig bepaald of verwerkt kan worden.

Voorbeelden:

• niveau bestaat niet;
• niveau is inactief voor actuele context;
• docent heeft geen bewerkrecht op niveau;
• collaboratorrecord is ingetrokken;
• categorie bestaat niet of is niet koppelbaar;
• categorie is al actief gekoppeld aan hetzelfde niveau;
• categorie is gemigreerd en niet langer kiesbaar;
• concrete oefening bestaat niet;
• oefening staat in onderhoud bij leerlingstart;
• oefeningconfiguratie is ongeldig;
• technische module is niet beschikbaar;
• module-implementatie kan niet gevonden worden;
• payload bevat onbekende of ongeldige schema-informatie;
• modulevalidatie levert geen genereerbare vragen op;
• leerlingautorisatie is ingetrokken;
• open niveau is niet langer actief;
• routecontext is gemanipuleerd;
• categoriemigratie veroorzaakt onoplosbare conflicten;
• modulemigratie kan niet veilig worden toegepast;
• history kan niet vastgelegd worden.

Bij fouttoestanden toont OefenHub een veilige melding of redirect zonder technische stacktrace, tokens, interne identifiers, verborgen leerlingdata of gevoelige payloadinhoud.

7.45 Relatie tot andere FO-hoofdstukken

Hoofdstuk	Relatie
Rollen, context en autorisatie	Bepaalt rolcontext, combinatierollen, routeguards en server-side autorisatieprincipes.
Applicatieschil, header, footer en navigatie	Beschrijft categorieënmenu, headergedrag en anti-afleiding tijdens oefenen.
Frontpages en overzichtsschermen	Beschrijft frontpageblokken, tellers, read-only gedrag en lege/fouttoestanden.
Relatiebeheer	Beschrijft docent-leerlingrelaties, docent-docentrelaties en relatie als autorisatiebron.
Leerling: oefenen, voortgang en resultaten	Beschrijft run-lifecycle, starten, hervatten, beantwoorden, afronden en resultaten.
Gedeelde oefeningen	Beschrijft ontvangen gedeelde oefeningen, snapshots en ontvangersruns.
Docentfunctionaliteit	Beschrijft docentflows rond leerlingen, autorisaties, oefenaanbod, collaborators en eigenaarschap.
Ouder-/voogdfunctionaliteit	Beschrijft read-only grenzen rond kindresultaten en geschiedenis.
Beheerderfunctionaliteit	Beschrijft beheerderflows rond categorieën, modules, docentondersteuning en centrale onderhoudsacties.
Berichten, communicatie en notificaties	Beschrijft systeemberichten, badges, anti-afleiding en systeemcommunicatie.
Live meekijken	Gebruikt opgeslagen runvoortgang als bron, niet de catalogus als livebron.
PDF-export en resultaatpresentatie	Gebruikt historische runcontext en snapshotwaarden voor export.
Oefenmodules en modulepayloads	Verdiept de modulegrens, payloadschema’s, moduleKey, schemaVersion en module-evolutie.

7.46 Gerelateerde bronverwijzingen

Bron	Link
Technisch Ontwerp — oefencatalogus	Oefencatalogus, niveaus, categorieën, oefeningen en modules
Technisch Ontwerp — oefenmodulecontract	Oefenmodulecontract en dynamische module-integratie
Technisch Ontwerp — databaseontwerp	Databaseontwerp, migraties, seeddata en constraints
Database-informatie — Docentstructuur en leerlingtoegang	Docentstructuur en leerlingtoegang
Database-informatie — Configuratie en contentbeheer	Configuratie en contentbeheer
Database-informatie — Oefenruns, delen en voortgang	Oefenruns, delen en voortgang
Usecases leerling — Oefenaanbod en toegang	Oefenaanbod en toegang
UC-LLN-TOEG-001 — Beschikbare categorieën bekijken	Beschikbare categorieën bekijken
UC-LLN-TOEG-002 — Beschikbare oefeningen bekijken	Beschikbare oefeningen bekijken
UC-LLN-TOEG-003 — Oefeningstoegang controleren bij openen	Oefeningstoegang controleren bij openen
UC-LLN-TOEG-004 — Toegang vervalt door ingetrokken autorisatie	Toegang vervalt door ingetrokken autorisatie
UC-LLN-TOEG-005 — Open niveau gebruiken	Open niveau gebruiken
UC-LLN-TOEG-006 — Privéniveau gebruiken via autorisatie	Privéniveau gebruiken via autorisatie
Usecases leerling — Oefenen en voortgang	Oefenen en voortgang
UC-LLN-OEF-001 — Oefening-startpagina openen	Oefening-startpagina openen
UC-LLN-OEF-002 — Verder gaan met niet-afgeronde oefening	Verder gaan met niet-afgeronde oefening
UC-LLN-OEF-003 — Nieuwe oefening starten	Nieuwe oefening starten
Usecases docent — Oefenaanbod, niveaus en categorieën	Oefenaanbod, niveaus en categorieën
UC-DOC-AANB-001 — Oefenaanbod openen	Oefenaanbod openen
UC-DOC-AANB-002 — Niveau selecteren	Niveau selecteren
UC-DOC-AANB-003 — Nieuw niveau aanmaken	Nieuw niveau aanmaken
UC-DOC-AANB-004 — Niveaukerngegevens wijzigen	Niveaukerngegevens wijzigen
UC-DOC-AANB-005 — Categorieën binnen niveau bekijken	Categorieën binnen niveau bekijken
UC-DOC-AANB-006 — Bestaande categorie aan niveau koppelen	Bestaande categorie aan niveau koppelen
UC-DOC-AANB-007 — Nieuwe centrale categorie aanmaken via docentflow	Nieuwe centrale categorie aanmaken via docentflow
UC-DOC-AANB-008 — Categoriegebruik en zichtbaarheid afleiden	Categoriegebruik en zichtbaarheid afleiden
Usecases docent — Oefeningen configureren en testen	Oefeningen configureren en testen
UC-DOC-OEF-001 — Oefeningen binnen categorie bekijken	Oefeningen binnen categorie bekijken
UC-DOC-OEF-002 — Nieuwe oefening aanmaken	Nieuwe oefening aanmaken
UC-DOC-OEF-003 — Technische module selecteren	Technische module selecteren
UC-DOC-OEF-004 — Oefening configureren	Oefening configureren
UC-DOC-OEF-005 — Oefening bewerken	Oefening bewerken
UC-DOC-OEF-006 — Oefening activeren of in onderhoud zetten	Oefening activeren of in onderhoud zetten
UC-DOC-OEF-007 — Oefening kopiëren vanuit open niveau	Oefening kopiëren vanuit open niveau
UC-DOC-OEF-008 — Oefening testen als docent	Oefening testen als docent
UC-DOC-OEF-009 — Testoefening opruimen	Testoefening opruimen
Usecases beheerder — Categorieën beheren	Categorieën beheren
UC-BEH-CAT-001 — Categorieoverzicht bekijken	Categorieoverzicht bekijken
UC-BEH-CAT-002 — Categoriebeheer openen	Categoriebeheer openen
UC-BEH-CAT-003 — Categoriegegevens wijzigen	Categoriegegevens wijzigen
UC-BEH-CAT-004 — Categoriestatus wijzigen	Categoriestatus wijzigen
UC-BEH-CAT-005 — Categoriemigratie voorbereiden	Categoriemigratie voorbereiden
UC-BEH-CAT-006 — Categorie migreren	Categorie migreren
UC-BEH-CAT-007 — Categoriegeschiedenis bekijken	Categoriegeschiedenis bekijken
Usecases beheerder — Modules beheren	Modules beheren
UC-BEH-MOD-001 — Moduleoverzicht bekijken	Moduleoverzicht bekijken
UC-BEH-MOD-002 — Modulebeheer openen	Modulebeheer openen
UC-BEH-MOD-003 — Modulegegevens wijzigen	Modulegegevens wijzigen
UC-BEH-MOD-004 — Module-actiefstatus wijzigen	Module-actiefstatus wijzigen
UC-BEH-MOD-005 — Testzichtbaarheid wijzigen	Testzichtbaarheid wijzigen
UC-BEH-MOD-006 — Moduleconnectiviteit testen	Moduleconnectiviteit testen
UC-BEH-MOD-007 — Modulemigratie docentgericht uitvoeren	Modulemigratie docentgericht uitvoeren
UC-BEH-MOD-008 — Modulemigratie globaal uitvoeren	Modulemigratie globaal uitvoeren
UC-BEH-MOD-009 — Modulemigratie-proefuitvoering controleren	Modulemigratie-proefuitvoering controleren
UC-BEH-MOD-010 — Modulegeschiedenis bekijken	Modulegeschiedenis bekijken
Schermdocumentatie leerling — Frontpage	Leerling frontpage
Schermdocumentatie leerling — Frontpage geen docent	Leerling frontpage geen docent
Schermdocumentatie leerling — Oefening	Oefening
Schermdocumentatie leerling — Start nieuwe	Start nieuwe
Schermdocumentatie docent — Niveaus en categorieën	Niveaus en categorieën
Schermdocumentatie docent — Niveau/categorie modals	Niveau/categorie modals
Schermdocumentatie docent — Nieuwe oefening	Nieuwe oefening
Schermdocumentatie beheerder — Categorieën	Categorieën
Schermdocumentatie beheerder — Modules	Modules
Oefenmodules — Optellen en aftrekken simpel	Optellen en aftrekken simpel
Ontwerpbron — Business rules	Business rules
Ontwerpbron — Autorisatiematrix	Autorisatiematrix
Ontwerpbron — Statusmodellen	Statusmodellen
Ontwerpbron — Command-register	Command-register
Ontwerpbron — Event-register	Event-register
Ontwerpbron — Popup-register	Popup-register