UC-BEH-MOD-010 — Modulegeschiedenis bekijken
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-MOD-010 |
| Naam | Modulegeschiedenis bekijken |
| 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-004, UC-BEH-MOD-005, UC-BEH-MOD-006, UC-BEH-MOD-007, UC-BEH-MOD-008, UC-BEH-MOD-009 |
| 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 de geschiedenis van één geselecteerde technische module raadpleegt.
De geschiedenis toont relevante beheeracties op moduleniveau, waaronder inhoudelijke wijzigingen, statuswijzigingen, wijzigingen van test-zichtbaarheid, docentgerichte modulemigraties, globale modulemigraties en proefuitvoeringen voor zover deze auditbaar zijn vastgelegd.
Geschiedenis is een raadpleegfunctie. Zij is bedoeld voor reconstructie en supportanalyse en wijzigt geen module, oefening, run of migratierecord.
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:
- Laden van modulegeschiedenis voor de geopende module.
- Tonen van actor, datum/tijd, actietype, oude en nieuwe waarde of samenvatting.
- Tonen van migratieregels met bronmodule, doelmodule, scope, docentcontext indien aanwezig en reden.
- Filteren of sorteren binnen de geschiedenisweergave.
- Afhandelen van lege of gedeeltelijk beschikbare historie.
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.
- Geschiedenis wijzigen of verwijderen.
- Volledige technische logs als gebruikersinterface tonen.
- Zoeken in alle systeemlogs buiten modulebeheer.
- Migraties terugdraaien; rollback is een nieuwe bewuste migratie naar een beschikbare module.
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 Geschiedenis is zichtbaar. |
| PRE-007 | Er kunnen nul of meer relevante historie- of migratieregels bestaan. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | De beheerder ziet de beschikbare geschiedenis van de module. |
| POST-002 | Geen historie is gewijzigd of verwijderd. |
| POST-003 | Geen module- of oefeningdata is gewijzigd. |
| POST-004 | Sortering en filtering wijzigen uitsluitend de weergave. |
| POST-005 | Bij ontbrekende historie wordt een lege staat getoond. |
6. Trigger
De usecase start wanneer de beheerder in de modulebeheerweergave de sectie Geschiedenis opent.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|---|---|---|---|---|
| 1 | Beheerder | Modulebeheer | Opent Geschiedenis. | De frontend vraagt modulegeschiedenis op. | ExerciseModuleId. |
| 2 | Backend | Autorisatiecomponent | Controleert beheerdercontext. | Alleen beheerder mag modulegeschiedenis bekijken. | Server-side autorisatie. |
| 3 | Backend | HistorieService | Laadt metadatawijzigingen en statuswijzigingen. | Wijzigingen aan ExerciseModules worden als geschiedenisregels weergegeven. | Beheeraudit / modulehistory. |
| 4 | Backend | HistorieService | Laadt modulemigraties. | Migraties met bron of doel gelijk aan de geopende module worden opgenomen. | ExerciseModuleMigrations. |
| 5 | Backend | HistorieService | Laadt oefeninghistorysamenvattingen waar relevant. | Per-oefening migratieregels kunnen als samenvatting worden gekoppeld. | ExerciseHistory. |
| 6 | Frontend | Geschiedenis | Toont chronologisch overzicht. | Regels tonen actor, tijdstip, domein, actie en reden waar aanwezig. | Read-only. |
| 7 | Beheerder | Geschiedenis | Filtert of sorteert. | De weergave wordt aangepast zonder datamutatie. | Readmodel. |
8. Alternatieve en exceptionele processtromen
| ID | Vanaf stap | Situatie | Systeemgedrag | Popup / melding | Datamutatie |
|---|---|---|---|---|---|
| ALT-001 | 2 | Gebruiker is geen beheerder. | De backend weigert toegang. | Niet van toepassing. | Geen. |
| ALT-002 | 3 | Geen geschiedenis beschikbaar. | De sectie toont een lege staat. | Niet van toepassing. | Geen. |
| ALT-003 | 4 | Migratie verwijst naar historisch bekende module. | De regel gebruikt opgeslagen naam- en versiesnapshots. | Niet van toepassing. | Geen. |
| ALT-004 | 5 | Een onderliggende oefening bestaat niet meer in actieve weergave. | De historyregel blijft zichtbaar via audit- en snapshotinformatie. | Niet van toepassing. | Geen. |
| ALT-005 | 7 | Filter levert geen resultaten op. | De sectie toont een lege filterstaat zonder geschiedenis te wijzigen. | Niet van toepassing. | Geen. |
9. Business rules
| ID | Business rule |
|---|---|
| BR-001 | Modulegeschiedenis is read-only. |
| BR-002 | Migraties worden zichtbaar gemaakt als beheeracties op moduleniveau. |
| BR-003 | Naam- en versiesnapshots blijven leidend voor leesbaarheid van historische migraties. |
| BR-004 | ExerciseHistory blijft de audittrail op oefeningniveau; modulegeschiedenis mag daarvan samenvattingen tonen. |
| BR-005 | Geschiedenisregels mogen niet worden aangepast of verwijderd vanuit de GUI. |
| BR-006 | Rollback van modulemigratie is geen historybewerking maar een nieuwe bewuste migratie. |
| BR-007 | Technische stacktraces of secrets worden niet in de functionele geschiedenis getoond. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-001 | ExerciseModuleId is verplicht en moet bestaan of historisch resolveerbaar zijn. |
| VAL-002 | De beheerderrol wordt server-side gevalideerd. |
| VAL-003 | Filterwaarden mogen alleen de query beperken en geen datamutaties triggeren. |
| VAL-004 | Migratieregels moeten bronmodule, doelmodule, scope, actor, tijdstip en reden tonen waar beschikbaar. |
| VAL-005 | Datum/tijd wordt getoond in gebruikerslokale tijd maar blijft opgeslagen in UTC. |
| VAL-006 | Historyregels worden chronologisch consistent gesorteerd. |
11. Datamutaties en events
| ID | Mutatie / event | Toelichting |
|---|---|---|
| MUT-001 | Geen functionele mutatie | Geschiedenis raadplegen wijzigt geen data. |
| MUT-002 | Geen event | Er wordt geen nieuwe historyregel geschreven door het bekijken van geschiedenis. |
12. Geen datamutaties
| ID | Geen mutatie | Reden |
|---|---|---|
| NO-001 | ExerciseModules | Modulemetadata en status blijven ongewijzigd. |
| NO-002 | ExerciseModuleMigrations | Migratieregels blijven ongewijzigd. |
| NO-003 | ExerciseHistory | Oefeninghistory blijft ongewijzigd. |
| NO-004 | Exercises | Geen oefening wordt aangepast. |
| NO-005 | ExerciseRuns | Geen run wordt aangepast. |
13. State diagram
Niet van toepassing. Deze usecase raadpleegt bestaande history- en migratiegegevens als read-only overzicht en wijzigt geen persistent statusobject.
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 | Modulebeheer toont geschiedenis van inhoudelijke wijzigingen, statuswijzigingen, test-zichtbaarheid en migraties. |
| Technisch Ontwerp | Technisch Ontwerp: oefencatalogus, oefenmodulecontract, background jobs en teststrategie beschrijven de technische uitwerking. Geschiedenisreadmodel combineert module-audit, ExerciseModuleMigrations en relevante ExerciseHistory-samenvattingen. |
| Software Requirements Specification | SRS moet read-only gedrag, snapshotgebruik en filter-/sorteergedrag specificeren. |
| Database | Leest audit/historybronnen zonder mutatie. |
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-010-001 | SRS-ADM-004 SRS-ADM-001 SRS-MOD-003 SRS-NFR-AUD-001 AC-ADM-004 AC-ADM-001 AC-MOD-003 AC-NFR-AUD-001 | Modulegeschiedenis read-only tonen |
REQ-BEH-MOD-010-002 | SRS-ADM-004 SRS-ADM-001 SRS-MOD-005 AC-ADM-004 AC-ADM-001 AC-MOD-005 | Inhoudelijke modulewijzigingen, statuswijzigingen en test-zichtbaarheid tonen |
REQ-BEH-MOD-010-003 | SRS-TCH-001 SRS-ADM-004 SRS-ADM-001 SRS-MOD-004 AC-TCH-001 AC-ADM-004 AC-ADM-001 AC-MOD-004 | Docentgerichte en globale modulemigraties tonen |
REQ-BEH-MOD-010-004 | SRS-ADM-004 SRS-ADM-001 SRS-MOD-003 AC-ADM-004 AC-ADM-001 AC-MOD-003 | Bronmodule, doelmodule, scope, actor, tijdstip en reden tonen waar beschikbaar |
REQ-BEH-MOD-010-005 | SRS-ADM-001 AC-ADM-001 | Naam- en versiesnapshots gebruiken voor historische leesbaarheid |
REQ-BEH-MOD-010-006 | SRS-ADM-001 SRS-NFR-AUD-001 AC-ADM-001 AC-NFR-AUD-001 | Historyregels niet via de GUI laten wijzigen of verwijderen |
REQ-BEH-MOD-010-007 | SRS-RDM-001 SRS-ADM-001 AC-RDM-001 AC-ADM-001 | Filteren en sorteren zonder datamutatie uitvoeren |