UC-BEH-MOD-002 — Modulebeheer openen
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-MOD-002 |
| Naam | Modulebeheer openen |
| Domein | Beheerder / Modules beheren |
| Primaire actor | Beheerder |
| Secundaire actor(en) | Frontend, backend, database, autorisatiecomponent, modulebeheercomponent, historiecomponent, strategy-interface |
| Rolcontext | Actieve beheerdercontext; server-side bepaald vanuit de ingelogde gebruiker |
| Betrokken schermen | Content > Modules beheren |
| Gerelateerde usecases | UC-BEH-MOD-001, UC-BEH-MOD-003, UC-BEH-MOD-004, UC-BEH-MOD-005, UC-BEH-MOD-006, UC-BEH-MOD-007, UC-BEH-MOD-008, UC-BEH-MOD-009, UC-BEH-MOD-010 |
| Primaire entiteiten | ExerciseModules, Exercises, ExerciseHistory, ExerciseModuleMigrations, ExerciseRuns, Users |
| Secundaire entiteiten / events | TeacherLevels, TeacherLevelCategories, TeacherLevelCategoryExercises, UserRoles, modulebeheer-readmodels, strategy-interface |
| Gerelateerde popups | Niet van toepassing |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
Deze usecase beschrijft hoe een beheerder vanuit het moduleoverzicht de detail- en beheerweergave van één technische module opent.
De detailweergave is bewust tweestaps: eerst selecteert de beheerder één module in het overzicht, daarna opent hij of zij de beheerpagina van die module. De titel toont de actuele weergavenaam en versie, bijvoorbeeld Modulebeheer - Basisrekenen V2.3.1.
De detailweergave bevat minimaal de onderdelen Intro / uitleg, Module, Migreren - docent, Migreren - alles en Geschiedenis. Elk onderdeel heeft een eigen doel en mag geen beheer van concrete docent-oefeningen overnemen.
Uitgangspunten
- Technische modules worden administratief beheerd in ExerciseModules en niet runtime ontdekt uit assemblies of codepaden.
- Een concrete oefening verwijst altijd naar precies één ExerciseModules-record.
- Modulebeheer wijzigt centrale modulemetadata en onderhoudsacties, niet de inhoudelijke docentconfiguratie van oefeningen.
- Historische runs behouden hun oorspronkelijke modulecontext.
- Popupinhoud blijft bronhoudend in het centrale popupregister.
3. Scope
Deze usecase beschrijft:
- Valideren van de geselecteerde ExerciseModuleId.
- Laden van modulemetadata en gebruiksimpact.
- Tonen van de beheerweergave voor precies één module.
- Beschikbaar maken van tabbladen of secties Intro / uitleg, Module, Migreren - docent, Migreren - alles en Geschiedenis.
- Afhandelen van ontbrekende of niet-toegankelijke modulecontext.
Deze usecase beschrijft niet:
- Concrete docent-oefeningen configureren of de modulespecifieke configuratiepayload bewerken; dat blijft bronhoudend in docentflows of docentondersteuning.
- Leerlingruns, resultaten, geschiedenis of gedeelde oefeningen herschrijven; historische runs behouden hun oorspronkelijke modulecontext.
- Nieuwe technische modulecode leveren of implementeren; modulecode blijft onderdeel van de technische codebase.
- Popupteksten, knopteksten of inputlabels specificeren; usecases verwijzen uitsluitend naar PopupKey.
- Modulegegevens opslaan; dit hoort bij UC-BEH-MOD-003.
- Status- of testzichtbaarheid wijzigen; dit hoort bij UC-BEH-MOD-004 en UC-BEH-MOD-005.
- Migraties definitief uitvoeren; dit hoort bij migratieusecases.
3.1 Afbakening met aangrenzende domeinen
| Onderdeel | Afbakening |
|---|---|
| Docent / Oefeningen configureren | Docenten kiezen en configureren concrete oefeningen op basis van beschikbare modules; centrale technische module-identiteit wordt hier beheerd. |
| Beheerder / Docentondersteuning | Support kan concrete docentstructuren en oefeningen inspecteren, maar centrale modulemetadata en migraties worden hier beheerd. |
| Leerling / Oefenen en resultaten | Leerlingruns blijven historische uitvoeringen en worden niet herschreven door modulebeheer. |
| Database-informatie | ExerciseModules, ExerciseModuleMigrations en ExerciseHistory dragen de technische module-identiteit, migratieaudit en oefeninghistorie. |
4. Pre-condities
| ID | Voorwaarde |
|---|---|
| PRE-001 | De gebruiker is succesvol ingelogd in OefenHub. |
| PRE-002 | De backend heeft server-side vastgesteld dat de gebruiker een actieve beheerderrol heeft. |
| PRE-003 | De beheerder bevindt zich binnen de beheeromgeving via Content > Modules beheren. |
| PRE-004 | De pagina gebruikt actuele serverdata; clientstate, routeparameters of verborgen formuliervelden bepalen geen autorisatie of module-identiteit. |
| PRE-005 | De beheerder heeft in het moduleoverzicht precies één module geselecteerd. |
| PRE-006 | De geselecteerde module bestaat als ExerciseModules-record. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | De detail- en beheerweergave van de geselecteerde module is geladen. |
| POST-002 | De titel is gebaseerd op actuele modulemetadata. |
| POST-003 | De beheerder ziet de relevante onderdelen voor modulebeheer. |
| POST-004 | Geen modulemetadata, oefening of run is gewijzigd. |
| POST-005 | Bij ontbrekende modulecontext wordt teruggevallen op het overzicht. |
6. Trigger
De usecase start wanneer de beheerder vanuit het moduleoverzicht de actie Open beheer kiest.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|---|---|---|---|---|
| 1 | Beheerder | Moduleoverzicht | Kiest Open beheer. | De frontend vraagt de detailcontext voor de geselecteerde module op. | ExerciseModuleId. |
| 2 | Backend | Autorisatiecomponent | Controleert beheerdercontext. | Alleen beheerder mag detailbeheer openen. | Server-side autorisatie. |
| 3 | Backend | ModuleService | Valideert dat de module bestaat. | Een niet-bestaande module wordt niet geopend. | ExerciseModules.Id. |
| 4 | Backend | ModuleService | Laadt modulemetadata. | DisplayName, CodeReference, Version, IsActive en IsVisibleForTesting worden geladen. | ExerciseModules. |
| 5 | Backend | Impactreadmodel | Laadt detailimpact. | Koppelingen, docenten, unieke leerlingen en totaal gebruik worden afgeleid. | Exercises, ExerciseRuns, docentstructuur. |
| 6 | Frontend | Modulebeheer | Toont titel en onderdelen. | Intro, Module, Migreren - docent, Migreren - alles en Geschiedenis zijn beschikbaar. | Detailreadmodel. |
| 7 | Frontend | Modulebeheer | Bepaalt beschikbare acties. | Acties worden getoond of uitgeschakeld op basis van status, impact en autorisatie. | Afgeleide UI-status. |
8. Alternatieve en exceptionele processtromen
| ID | Vanaf stap | Situatie | Systeemgedrag | Popup / melding | Datamutatie |
|---|---|---|---|---|---|
| ALT-001 | 1 | Geen module geselecteerd. | De actie Open beheer is niet beschikbaar of wordt geweigerd. | Niet van toepassing. | Geen. |
| ALT-002 | 2 | Gebruiker is geen beheerder. | De backend weigert toegang. | Niet van toepassing. | Geen. |
| ALT-003 | 3 | Module bestaat niet meer. | De beheerder keert terug naar het overzicht met veilige melding. | Niet van toepassing. | Geen. |
| ALT-004 | 5 | Impactreadmodel kan niet volledig worden opgebouwd. | De detailweergave toont modulemetadata en markeert impactwaarden als niet beschikbaar. | Niet van toepassing. | Geen. |
| ALT-005 | 7 | Een actie is door actuele status niet toegestaan. | De actie wordt uitgeschakeld met functionele toelichting. | Niet van toepassing. | Geen. |
9. Business rules
| ID | Business rule |
|---|---|
| BR-001 | Modulebeheer wordt altijd geopend voor precies één ExerciseModules-record. |
| BR-002 | De detailtitel is gebaseerd op actuele modulemetadata en niet op vrij bewerkbare paginatiteltekst. |
| BR-003 | De beheerweergave bestaat minimaal uit Intro / uitleg, Module, Migreren - docent, Migreren - alles en Geschiedenis. |
| BR-004 | De sectie Module beheert modulemetadata en statusvelden; concrete oefeningen worden daar niet geconfigureerd. |
| BR-005 | De migratiesecties werken vanuit de geopende bronmodule. |
| BR-006 | Actiebeschikbaarheid wordt server-side bepaald en mag niet uitsluitend op clientstate steunen. |
| BR-007 | Het openen van detailbeheer veroorzaakt geen datamutatie. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-001 | ExerciseModuleId is verplicht en moet bestaan. |
| VAL-002 | De beheerderrol wordt opnieuw server-side gevalideerd bij openen. |
| VAL-003 | De titel mag alleen worden samengesteld uit DisplayName en Version van de actuele module. |
| VAL-004 | Impactwaarden worden server-side afgeleid. |
| VAL-005 | Beschikbare acties worden bepaald uit IsActive, IsVisibleForTesting en actieve afhankelijkheden. |
| VAL-006 | Routeparameters mogen geen modulecontext afdwingen zonder databasevalidatie. |
11. Datamutaties en events
| ID | Mutatie / event | Toelichting |
|---|---|---|
| MUT-001 | Geen functionele mutatie | Openen van modulebeheer is een leesactie. |
| MUT-002 | Geen event | Er wordt geen ExerciseHistory- of ExerciseModuleMigrations-record aangemaakt. |
12. Geen datamutaties
| ID | Geen mutatie | Reden |
|---|---|---|
| NO-001 | ExerciseModules | Metadata en statusvelden blijven ongewijzigd. |
| NO-002 | Exercises | Geen oefening wordt aangepast. |
| NO-003 | ExerciseRuns | Geen run wordt gewijzigd. |
| NO-004 | ExerciseModuleMigrations | Geen migratie wordt aangemaakt. |
| NO-005 | ExerciseHistory | Geen oefeninghistory wordt geschreven. |
13. State diagram
Niet van toepassing. Deze usecase opent een bestaande modulecontext en wijzigt geen persistent statusobject. Beschikbare secties en acties worden afgeleid uit server-side autorisatie, modulemetadata en impactreadmodels.
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
Niet van toepassing. Deze usecase gebruikt geen popupregister-popup. Eventuele inline foutmeldingen of lege staten worden als gewone schermfeedback behandeld.
18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Document | Afleiding |
|---|---|
| Functioneel Ontwerp | Modules beheren is een tweestapsflow: overzicht selecteren, daarna detailbeheer openen. |
| Technisch Ontwerp | Technisch Ontwerp: oefencatalogus, oefenmodulecontract, background jobs en teststrategie beschrijven de technische uitwerking. Detailreadmodel combineert ExerciseModules met afgeleide impactwaarden en actiebeschikbaarheid. |
| Software Requirements Specification | SRS moet secties en actiebeschikbaarheid per status en afhankelijkheid definiëren. |
| Database | Geen mutatie; leest ExerciseModules, Exercises, ExerciseRuns en historiebronnen. |
19. SRS-trace
Deze usecase bevat geen normatieve requirementtekst. De centrale eis en acceptatiecriteria staan in de SRS; onderstaande tabel koppelt de usecase-afleiding alleen aan centrale SRS-*- en AC-*-items.
| Usecase-afleiding | Dekt | Usecasecontext |
|---|---|---|
REQ-BEH-MOD-002-001 | SRS-AUTH-004 SRS-ADM-004 SRS-ADM-001 SRS-MOD-003 AC-AUTH-004 AC-ADM-004 AC-ADM-001 AC-MOD-003 | Modulebeheer alleen openen voor precies één geselecteerde module |
REQ-BEH-MOD-002-002 | SRS-AUTH-001 SRS-AUTH-004 SRS-ADM-004 SRS-ADM-001 SRS-MOD-003 AC-AUTH-001 AC-AUTH-004 AC-ADM-004 AC-ADM-001 AC-MOD-003 | De geselecteerde ExerciseModuleId server-side valideren |
REQ-BEH-MOD-002-003 | SRS-ADM-004 SRS-ADM-001 SRS-MOD-003 AC-ADM-004 AC-ADM-001 AC-MOD-003 | De titel samenstellen uit actuele modulemetadata |
REQ-BEH-MOD-002-004 | SRS-TCH-004 SRS-ADM-004 SRS-ADM-001 SRS-MOD-003 SRS-NFR-AUD-001 AC-TCH-004 AC-ADM-004 AC-ADM-001 AC-MOD-003 AC-NFR-AUD-001 | De onderdelen Intro / uitleg, Module, Migreren - docent, Migreren - alles en Geschiedenis tonen |
REQ-BEH-MOD-002-005 | SRS-AUTH-001 SRS-ADM-001 AC-AUTH-001 AC-ADM-001 | Actiebeschikbaarheid server-side bepalen |
REQ-BEH-MOD-002-006 | SRS-LRN-009 SRS-ADM-004 SRS-ADM-001 SRS-MOD-003 AC-LRN-009 AC-ADM-004 AC-ADM-001 AC-MOD-003 | Bij openen van modulebeheer geen module- of oefeningdata wijzigen |