UC-BEH-MOD-004 — Module-actiefstatus wijzigen
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-MOD-004 |
| Naam | Module-actiefstatus wijzigen |
| 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-002, UC-BEH-MOD-003, 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 | POP-BEH-MOD-ACTIVE-STATUS-CONFIRM |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
Deze usecase beschrijft hoe een beheerder de reguliere actiefstatus van een technische module wijzigt.
IsActive bepaalt of de moduleversie regulier beschikbaar is voor docenten bij het aanmaken of aanpassen van oefeningen. Een module mag pas inactief worden gemaakt wanneer er geen actieve concrete oefeningen of actieve oefenkoppelingen meer bestaan die naar die module verwijzen.
De statuswijziging staat los van IsVisibleForTesting. Test-zichtbaarheid wordt afzonderlijk beheerd en mag niet impliciet worden gewijzigd door het uitschakelen of inschakelen van de reguliere actiefstatus.
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:
- Inschakelen of uitschakelen van IsActive.
- Blokkeren van uitschakelen bij actieve Exercises die naar de module verwijzen.
- Bevestiging met verplichte reden.
- Auditbaar vastleggen van statuswijziging.
- Gescheiden houden van IsActive en IsVisibleForTesting.
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.
- Test-zichtbaarheid wijzigen; dit hoort bij UC-BEH-MOD-005.
- Modulemigratie uitvoeren om afhankelijkheden op te ruimen; dit hoort bij UC-BEH-MOD-007 en UC-BEH-MOD-008.
- Hard verwijderen van technische moduleversies.
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 de detailweergave van één module geopend. |
| PRE-006 | De actuele impactwaarden voor actieve oefeningen zijn server-side beschikbaar. |
| PRE-007 | De sectie Module toont de huidige IsActive-status. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | IsActive is gewijzigd wanneer alle voorwaarden geldig waren. |
| POST-002 | UpdatedByUserId en UpdatedAtUtc zijn bijgewerkt. |
| POST-003 | De statuswijziging is auditbaar vastgelegd met reden. |
| POST-004 | IsVisibleForTesting is niet impliciet gewijzigd. |
| POST-005 | Bij actieve afhankelijkheden is geen statuswijziging uitgevoerd. |
6. Trigger
De usecase start wanneer de beheerder de reguliere actiefstatus van de module wijzigt en de actie bevestigt.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|---|---|---|---|---|
| 1 | Beheerder | Sectie Module | Kiest actiefstatus wijzigen. | De frontend vraagt actuele afhankelijkheden op. | IsActive doelwaarde. |
| 2 | Backend | Autorisatiecomponent | Controleert beheerdercontext. | Alleen beheerder mag status wijzigen. | Server-side autorisatie. |
| 3 | Backend | Impactcontrole | Controleert actieve concrete oefeningen. | Uitschakelen wordt geblokkeerd zolang Exercises naar deze module verwijzen. | Exercises.ExerciseModuleId. |
| 4 | Backend | Impactcontrole | Controleert actieve oefenkoppelingen. | Uitschakelen wordt geblokkeerd zolang actieve koppelingen via deze module bestaan. | TeacherLevelCategoryExercises, Exercises. |
| 5 | Frontend | Popup | Toont bevestiging met verplichte reden. | De beheerder bevestigt bewust de statuswijziging. | PopupKey POP-BEH-MOD-ACTIVE-STATUS-CONFIRM. |
| 6 | Beheerder | Popup | Bevestigt met reden. | De backend verwerkt de statuswijziging. | Reason verplicht. |
| 7 | Backend | ModuleService | Wijzigt IsActive. | Alleen IsActive en auditvelden worden aangepast. | ExerciseModules.IsActive. |
| 8 | Backend | Historiecomponent | Registreert statuswijziging. | Actor, tijdstip, oude waarde, nieuwe waarde en reden worden vastgelegd. | Beheeraudit / modulehistory. |
| 9 | Frontend | Sectie Module | Toont nieuwe status en actiebeperkingen. | Beschikbare acties worden herberekend. | Detailreadmodel. |
8. Alternatieve en exceptionele processtromen
| ID | Vanaf stap | Situatie | Systeemgedrag | Popup / melding | Datamutatie |
|---|---|---|---|---|---|
| ALT-001 | 2 | Gebruiker is geen beheerder. | De backend weigert de statuswijziging. | Niet van toepassing. | Geen. |
| ALT-002 | 3 | Er bestaan actieve concrete oefeningen. | Uitschakelen wordt geblokkeerd met uitleg dat eerst migratie of loskoppeling nodig is. | Niet van toepassing. | Geen. |
| ALT-003 | 4 | Er bestaan actieve oefenkoppelingen. | Uitschakelen wordt geblokkeerd. | Niet van toepassing. | Geen. |
| ALT-004 | 5 | Beheerder annuleert. | De status blijft ongewijzigd. | POP-BEH-MOD-ACTIVE-STATUS-CONFIRM. | Geen. |
| ALT-005 | 6 | Reden ontbreekt. | De bevestiging wordt geweigerd. | POP-BEH-MOD-ACTIVE-STATUS-CONFIRM. | Geen. |
| ALT-006 | 7 | Module is intussen gewijzigd. | De backend herlaadt de module en voert geen verouderde statusovergang uit. | Niet van toepassing. | Geen. |
9. Business rules
| ID | Business rule |
|---|---|
| BR-001 | IsActive bepaalt reguliere beschikbaarheid voor docenten. |
| BR-002 | Een technische module mag pas inactief worden gemaakt wanneer geen actieve concrete oefeningen naar deze module verwijzen. |
| BR-003 | Uitschakelen mag historische ExerciseRuns niet verwijderen of wijzigen. |
| BR-004 | IsActive en IsVisibleForTesting zijn gescheiden statusvelden. |
| BR-005 | Wijzigen van IsActive maakt geen modulemigratie aan. |
| BR-006 | Een statuswijziging vereist verplichte reden en auditregistratie. |
| BR-007 | Hard verwijderen van ExerciseModules is niet toegestaan via deze beheerflow. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-001 | ExerciseModuleId is verplicht en moet bestaan. |
| VAL-002 | De gewenste IsActive-doelwaarde moet verschillen van de actuele waarde. |
| VAL-003 | Bij uitschakelen moet het aantal actieve Exercises op deze module nul zijn. |
| VAL-004 | Bij uitschakelen moet het aantal actieve oefenkoppelingen via deze module nul zijn. |
| VAL-005 | Reason is verplicht en maximaal 500 tekens. |
| VAL-006 | De beheerderrol wordt vlak vóór opslaan opnieuw gevalideerd. |
| VAL-007 | Gelijktijdige statuswijzigingen moeten veilig worden gedetecteerd. |
11. Datamutaties en events
| ID | Mutatie / event | Toelichting |
|---|---|---|
| MUT-001 | Update ExerciseModules | IsActive, UpdatedByUserId en UpdatedAtUtc worden aangepast. |
| MUT-002 | Beheeraudit / modulehistory | Statuswijziging wordt vastgelegd met oude waarde, nieuwe waarde, actor, tijdstip en reden. |
12. Geen datamutaties
| ID | Geen mutatie | Reden |
|---|---|---|
| NO-001 | IsVisibleForTesting | Wordt niet impliciet gewijzigd. |
| NO-002 | Exercises | ExerciseModuleId en IsActive van oefeningen blijven ongewijzigd. |
| NO-003 | ExerciseRuns | Historische runs blijven ongewijzigd. |
| NO-004 | ExerciseModuleMigrations | Geen migratie wordt aangemaakt. |
| NO-005 | ExerciseHistory | Geen oefeninghistory wordt geschreven door statuswijziging op module. |
13. State diagram
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
| PopupKey | Gebruik |
|---|---|
| POP-BEH-MOD-ACTIVE-STATUS-CONFIRM | Bevestiging van actiefstatuswijziging met verplichte reden. |
De popupinhoud, knopteksten, inputlabels en themakeuze blijven bronhoudend in het popupregister en popup-themes.
18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Document | Afleiding |
|---|---|
| Functioneel Ontwerp | Een module mag pas inactief worden gemaakt wanneer geen oefeningen meer naar die moduleversie verwijzen. |
| Technisch Ontwerp | Technisch Ontwerp: oefencatalogus, oefenmodulecontract, background jobs en teststrategie beschrijven de technische uitwerking. Statuswijziging raakt ExerciseModules.IsActive en audit; geen migratie of runwijziging. |
| Software Requirements Specification | SRS moet blokkeren bij actieve Exercises en actieve oefenkoppelingen. |
| Database | Gebruikt ExerciseModules, Exercises en eventueel TeacherLevelCategoryExercises voor impactcontrole. |
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-004-001 | SRS-ADM-004 SRS-ADM-001 SRS-MOD-003 AC-ADM-004 AC-ADM-001 AC-MOD-003 | IsActive van een module alleen door beheerders laten wijzigen |
REQ-BEH-MOD-004-002 | SRS-AUTH-001 SRS-LRN-009 SRS-ADM-004 SRS-ADM-005 SRS-ADM-001 SRS-MOD-003 AC-AUTH-001 AC-LRN-009 AC-ADM-004 AC-ADM-005 AC-ADM-001 AC-MOD-003 | Uitschakelen blokkeren zolang actieve concrete oefeningen naar de module verwijzen |
REQ-BEH-MOD-004-003 | SRS-AUTH-001 SRS-ADM-004 SRS-ADM-005 SRS-ADM-001 SRS-MOD-003 AC-AUTH-001 AC-ADM-004 AC-ADM-005 AC-ADM-001 AC-MOD-003 | Uitschakelen blokkeren zolang actieve oefenkoppelingen via de module bestaan |
REQ-BEH-MOD-004-004 | SRS-ADM-001 AC-ADM-001 | IsVisibleForTesting niet impliciet wijzigen door een IsActive-wijziging |
REQ-BEH-MOD-004-005 | SRS-ADM-001 AC-ADM-001 | Een verplichte reden vragen vóór statuswijziging |
REQ-BEH-MOD-004-006 | SRS-ADM-001 SRS-NFR-AUD-001 AC-ADM-001 AC-NFR-AUD-001 | De statuswijziging auditbaar vastleggen |
REQ-BEH-MOD-004-007 | SRS-LRN-009 SRS-ADM-004 SRS-ADM-001 SRS-MOD-003 AC-LRN-009 AC-ADM-004 AC-ADM-001 AC-MOD-003 | Geen historische runs verwijderen of herschrijven door een module uit te schakelen |