UC-BEH-MOD-003 — Modulegegevens wijzigen
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-MOD-003 |
| Naam | Modulegegevens 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-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 | POP-BEH-MOD-UPDATE-CONFIRM |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
Deze usecase beschrijft hoe een beheerder beheerbare modulegegevens wijzigt in de sectie Module van de detailweergave.
De beheerbare gegevens zijn beperkt. DisplayName mag als leesbare naam worden gewijzigd. CodeReference blijft read-only omdat deze de strategy-interface naar code raakt. Version is read-only of technisch beheerd en wordt niet als vrije inhoudelijke tekst van een concrete oefening behandeld.
Elke inhoudelijke wijziging vereist bevestiging met verplichte reden en wordt auditbaar vastgelegd op modulebeheer- of beheerauditniveau. De wijziging verandert geen concrete oefeningconfiguratiepayloads.
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:
- Wijzigen van DisplayName van de technische module.
- Tonen van CodeReference als read-only technische referentie.
- Tonen van Version als read-only of technisch beheerde versiereferentie.
- Bevestigen van wijzigingen met verplichte reden.
- Vastleggen van actor, tijdstip, oude waarde en nieuwe waarde.
- Afhandelen van conflicten en ongeldige invoer.
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.
- CodeReference vrij wijzigen via de GUI.
- Version als vrije contenttekst wijzigen wanneer deze technisch beheerd is.
- Module actief of inactief maken; dit hoort bij UC-BEH-MOD-004.
- Test-zichtbaarheid wijzigen; dit hoort bij UC-BEH-MOD-005.
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 sectie Module is zichtbaar. |
| PRE-007 | De actuele modulemetadata is geladen. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | DisplayName is gewijzigd wanneer alle validaties slagen. |
| POST-002 | UpdatedByUserId en UpdatedAtUtc zijn bijgewerkt. |
| POST-003 | De wijziging is auditbaar vastgelegd met oude en nieuwe waarde en reden. |
| POST-004 | CodeReference en Version zijn niet door deze GUI-flow gewijzigd. |
| POST-005 | Concrete oefeningen, payloads, runs en modulemigraties blijven ongewijzigd. |
6. Trigger
De usecase start wanneer de beheerder in de sectie Module een beheerbaar veld aanpast en Opslaan kiest.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|---|---|---|---|---|
| 1 | Beheerder | Sectie Module | Wijzigt DisplayName. | De frontend markeert de wijziging als nog niet opgeslagen. | DisplayName. |
| 2 | Frontend | Sectie Module | Toont CodeReference en Version als read-only. | De beheerder kan deze velden niet vrij wijzigen. | CodeReference, Version. |
| 3 | Beheerder | Sectie Module | Kiest Opslaan. | De frontend vraagt bevestiging met reden. | PopupKey POP-BEH-MOD-UPDATE-CONFIRM. |
| 4 | Beheerder | Bevestigingspopup | Bevestigt met reden. | De backend verwerkt de wijziging. | Reason verplicht. |
| 5 | Backend | Autorisatiecomponent | Controleert beheerdercontext opnieuw. | Clientstate is niet leidend. | Server-side autorisatie. |
| 6 | Backend | ModuleService | Valideert DisplayName. | Naam moet verplicht, uniek genoeg en binnen lengtegrenzen zijn. | ExerciseModules.DisplayName. |
| 7 | Backend | ModuleService | Past ExerciseModules aan. | UpdatedByUserId en UpdatedAtUtc worden gezet. | ExerciseModules. |
| 8 | Backend | Historiecomponent | Registreert de wijziging. | Oude en nieuwe waarde, actor, tijdstip en reden worden vastgelegd. | Beheeraudit / modulehistory. |
| 9 | Frontend | Sectie Module | Toont de bijgewerkte modulegegevens. | De detailtitel wordt bijgewerkt. | Actueel readmodel. |
8. Alternatieve en exceptionele processtromen
| ID | Vanaf stap | Situatie | Systeemgedrag | Popup / melding | Datamutatie |
|---|---|---|---|---|---|
| ALT-001 | 3 | Beheerder annuleert. | De wijziging wordt niet opgeslagen en de oude waarde blijft leidend. | POP-BEH-MOD-UPDATE-CONFIRM. | Geen. |
| ALT-002 | 4 | Reden ontbreekt. | De bevestiging wordt geweigerd. | POP-BEH-MOD-UPDATE-CONFIRM. | Geen. |
| ALT-003 | 5 | Gebruiker is geen beheerder meer. | De backend weigert de wijziging. | Niet van toepassing. | Geen. |
| ALT-004 | 6 | DisplayName is leeg of te lang. | Opslaan wordt geweigerd met veldfout. | Niet van toepassing. | Geen. |
| ALT-005 | 6 | DisplayName conflicteert functioneel met een andere moduleversie. | Opslaan wordt geweigerd of vraagt expliciete correctie volgens uniciteitsregel. | Niet van toepassing. | Geen. |
| ALT-006 | 7 | Module is intussen gewijzigd. | De backend detecteert conflict en vraagt herladen vóór opslaan. | Niet van toepassing. | Geen. |
9. Business rules
| ID | Business rule |
|---|---|
| BR-001 | DisplayName is de leesbare module-identiteit voor beheer- en selectielijsten. |
| BR-002 | CodeReference is een technische strategy-sleutel en blijft read-only in deze flow. |
| BR-003 | Version is read-only of technisch beheerd en wordt niet als vrij contentveld behandeld. |
| BR-004 | Wijziging van DisplayName verandert geen ExerciseModuleId van bestaande oefeningen. |
| BR-005 | Wijziging van modulemetadata herschrijft geen historische ExerciseRuns. |
| BR-006 | Iedere inhoudelijke modulewijziging vereist een verplichte reden. |
| BR-007 | Oude en nieuwe waarde moeten auditbaar blijven. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-001 | DisplayName is verplicht. |
| VAL-002 | DisplayName is maximaal 150 tekens. |
| VAL-003 | DisplayName mag geen uitsluitend witruimte bevatten. |
| VAL-004 | CodeReference uit clientpayload wordt genegeerd of geweigerd wanneer het als wijziging wordt aangeboden. |
| VAL-005 | Version uit clientpayload wordt geweigerd wanneer dit veld niet als technisch wijzigbaar is gemarkeerd. |
| VAL-006 | Reason is verplicht en maximaal 500 tekens. |
| VAL-007 | De module moet bij opslaan nog bestaan en niet gelijktijdig conflicterend gewijzigd zijn. |
11. Datamutaties en events
| ID | Mutatie / event | Toelichting |
|---|---|---|
| MUT-001 | Update ExerciseModules | DisplayName, UpdatedByUserId en UpdatedAtUtc worden bijgewerkt. |
| MUT-002 | Beheeraudit / modulehistory | Wijziging wordt vastgelegd met veldnaam, oude waarde, nieuwe waarde, actor, tijdstip en reden. |
12. Geen datamutaties
| ID | Geen mutatie | Reden |
|---|---|---|
| NO-001 | CodeReference | Wordt niet via deze GUI-flow gewijzigd. |
| NO-002 | Version | Wordt niet als vrije tekst gewijzigd. |
| NO-003 | Exercises | ExerciseModuleId en configuratiepayloads blijven ongewijzigd. |
| NO-004 | ExerciseRuns | Historische runcontext blijft ongewijzigd. |
| NO-005 | ExerciseModuleMigrations | Metadatawijziging maakt geen migratie aan. |
13. State diagram
Niet van toepassing. Deze usecase wijzigt modulemetadata, maar introduceert geen zelfstandig statusobject. De toegestane route wordt uitgewerkt in de decision flow en de data lifecycle.
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
| PopupKey | Gebruik |
|---|---|
| POP-BEH-MOD-UPDATE-CONFIRM | Bevestiging van modulemetadatawijziging 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 | Modulegegevensbeheer is beperkt tot beheerbare metadata en houdt technische referenties gescheiden van concrete oefeningen. |
| Technisch Ontwerp | Technisch Ontwerp: oefencatalogus, oefenmodulecontract, background jobs en teststrategie beschrijven de technische uitwerking. Update raakt ExerciseModules en een audit-/historylaag; CodeReference en Version blijven read-only in de GUI-flow. |
| Software Requirements Specification | SRS moet lengte, verplichte reden, read-only velden en conflictcontrole afdwingen. |
| Database | Gebruikt ExerciseModules; geen mutatie op Exercises, ExerciseRuns of ExerciseModuleMigrations. |
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-003-001 | SRS-ADM-004 SRS-ADM-001 SRS-MOD-003 AC-ADM-004 AC-ADM-001 AC-MOD-003 | DisplayName van een technische module door beheerders kunnen laten wijzigen |
REQ-BEH-MOD-003-002 | SRS-ADM-001 AC-ADM-001 | CodeReference read-only tonen in de beheer-GUI |
REQ-BEH-MOD-003-003 | SRS-ADM-001 AC-ADM-001 | Version read-only of technisch beheerd tonen |
REQ-BEH-MOD-003-004 | SRS-ADM-004 SRS-ADM-001 SRS-MOD-003 AC-ADM-004 AC-ADM-001 AC-MOD-003 | Een verplichte reden vragen vóór opslaan van modulemetadata |
REQ-BEH-MOD-003-005 | SRS-ADM-001 SRS-NFR-AUD-001 AC-ADM-001 AC-NFR-AUD-001 | Oude en nieuwe waarde auditbaar vastleggen |
REQ-BEH-MOD-003-006 | SRS-CAT-003 SRS-LRN-009 SRS-ADM-001 AC-CAT-003 AC-LRN-009 AC-ADM-001 | Door een metadatawijziging geen concrete oefeningconfiguratiepayload wijzigen |
REQ-BEH-MOD-003-007 | SRS-ADM-001 SRS-NFR-SEC-001 AC-ADM-001 AC-NFR-SEC-001 | Gelijktijdige wijzigingen veilig detecteren of afhandelen |