Skip to main content

UC-BEH-CAT-003 — Categoriegegevens wijzigen

1. Kerngegevens

VeldWaarde
Usecase-IDUC-BEH-CAT-003
NaamCategoriegegevens wijzigen
DomeinBeheerder / Categorieën beheren
Primaire actorBeheerder
Secundaire actor(en)Frontend, backend, database, autorisatiecomponent, categoriebeheercomponent, historiecomponent
RolcontextActieve beheerdercontext; server-side bepaald vanuit de ingelogde gebruiker
Betrokken schermenContent > Categorieën beheren
Gerelateerde usecasesUC-BEH-CAT-001, UC-BEH-CAT-002, UC-BEH-CAT-004, UC-BEH-CAT-005, UC-BEH-CAT-006, UC-BEH-CAT-007
Primaire entiteitenCategories, CategoryHistory, CategoryMigrations, TeacherLevelCategories, TeacherLevelCategoryExercises
Secundaire entiteiten / eventsUsers, ExerciseRuns, SharedExercises, categoriebeheer-readmodels
Gerelateerde popupsPOP-BEH-CAT-EDIT-CONFIRM
PopupregisterOntwerpbronnen — Popup-register
MoSCoWMust

2. Omschrijving

Deze usecase beschrijft hoe een beheerder de centrale categorie-identiteit wijzigt: naam, kleur en icoon. Omdat deze identiteit door meerdere docenten, niveaus en leerlingweergaven kan worden gebruikt, is elke wijziging een beheeractie met verplichte bevestiging en reden.

De wijziging wordt opgeslagen op Categories en per inhoudelijk gewijzigd veld vastgelegd in CategoryHistory met ActionType UPDATE_NAME, UPDATE_COLOR of UPDATE_ICON. Een gecombineerde opslagactie kan dus meerdere historyregels opleveren.

De usecase wijzigt alleen de centrale identiteit. Zij wijzigt geen docentniveaukoppelingen, oefenkoppelingen, autorisaties, historische runs of gedeelde oefeningen.

Uitgangspunten

  • Categorieën zijn centrale onderwijsinhoud en geen private docentlabels.
  • Naam, kleur en icoon vormen samen de centrale categorie-identiteit.
  • Beheeracties op categorieën zijn volledig server-side gevalideerd.
  • Historische resultaten behouden hun oorspronkelijke categoriecontext.
  • Popupinhoud blijft bronhoudend in het centrale popupregister.

3. Scope

Deze usecase beschrijft:

  • Wijzigen van centrale categorienaam.
  • Wijzigen van centrale categoriekleur.
  • Wijzigen van centrale categorie-icoon.
  • Valideren van uniekheid, kleurformaat en iconkey.
  • Bevestiging met verplichte reden vóór definitieve verwerking.
  • Vastleggen van CategoryHistory per gewijzigd veld.

Deze usecase beschrijft niet:

  • Docentniveaubeheer, leerlingautorisaties of oefeningconfiguratie wijzigen; die blijven bronhoudend in docentflows of docentondersteuning.
  • Nieuwe centrale categorieën aanmaken vanuit beheer; categorie-aanmaak is bronhoudend in de docentflow of via technische migratie wanneer dat expliciet nodig is.
  • Historische exercise runs herschrijven; bestaande runs behouden hun oorspronkelijke categoriecontext.
  • Popupteksten of knopteksten specificeren; usecases verwijzen uitsluitend naar PopupKey.
  • Status wijzigen of soft-delete; dit hoort bij UC-BEH-CAT-004.
  • Migreren naar een andere categorie; dit hoort bij UC-BEH-CAT-005 en UC-BEH-CAT-006.
  • Docentcontextspecifieke volgorde of koppelingen wijzigen.

3.1 Afbakening met aangrenzende domeinen

OnderdeelAfbakening
Docent / OefenaanbodDocenten koppelen categorieën aan niveaus en maken waar toegestaan nieuwe centrale categorieën aan; beheer past de centrale identiteit en onderhoudsacties toe.
Beheerder / DocentondersteuningSupport op concrete docentstructuren mag categoriegebruik inspecteren, maar centrale categorie-identiteit wordt hier beheerd.
Leerling / OefenaanbodLeerlingen zien alleen afgeleide toegankelijke categorieën; deze bundel bepaalt niet zelfstandig leerlingtoegang.
Database-informatieCategories, CategoryHistory en CategoryMigrations blijven de technische bron voor centrale categorie-identiteit en audit.

4. Pre-condities

IDVoorwaarde
PRE-001De gebruiker is succesvol ingelogd in OefenHub.
PRE-002De backend heeft server-side vastgesteld dat de gebruiker een actieve beheerderrol heeft.
PRE-003De beheerder bevindt zich binnen de beheeromgeving via Content > Categorieën beheren.
PRE-004De pagina gebruikt actuele serverdata; clientstate, routeparameters of verborgen formuliervelden bepalen geen autorisatie of categorie-identiteit.
PRE-005De beheerder heeft de detailweergave van één categorie geopend.
PRE-006De categorie is niet geblokkeerd voor inhoudelijke wijziging door een lopende migratieactie.
PRE-007De beheerder voert minimaal één inhoudelijke wijziging in.

5. Post-condities

IDResultaat
POST-001Categories bevat de nieuwe naam, kleur en/of icoon.
POST-002UpdatedByUserId en UpdatedAtUtc zijn bijgewerkt.
POST-003Per gewijzigd veld is een CategoryHistory-record aangemaakt.
POST-004Niet gewijzigde velden blijven ongewijzigd.
POST-005Docentniveaukoppelingen, oefenkoppelingen en historische runs zijn niet gewijzigd.

6. Trigger

De usecase start wanneer de beheerder in de sectie Categorie gewijzigde categoriegegevens opslaat.

7. Normale processtroom

StapActorScherm / componentActieSysteemresponsData / regel
1BeheerderSectie CategorieWijzigt naam, kleur en/of icoon.De frontend markeert gewijzigde velden.Formulierdata.
2BeheerderSectie CategorieKiest Opslaan.De backend ontvangt de wijzigingsaanvraag.CategoryId plus nieuwe waarden.
3BackendAutorisatiecomponentControleert beheerdercontext.Alleen beheerder mag centrale identiteit wijzigen.Server-side autorisatie.
4BackendValidatiecomponentValideert naam, kleur, icoon en uniqueness.Ongeldige waarden worden geweigerd.Categories constraints.
5FrontendPopupToont bevestigingspopup met verplichte reden.De beheerder moet de wijziging bevestigen en reden invullen.PopupKey POP-BEH-CAT-EDIT-CONFIRM.
6BeheerderPopupBevestigt de wijziging met reden.De backend verwerkt de wijziging transactioneel.Reason verplicht.
7BackendCategorieServiceSlaat gewijzigde velden op.Categories wordt bijgewerkt.Categories UpdatedAtUtc, UpdatedByUserId.
8BackendHistorieServiceSchrijft history per gewijzigd veld.ActionType volgt het gewijzigde veld.CategoryHistory.
9FrontendDetailweergaveToont bijgewerkte categoriegegevens.Impactwaarden worden opnieuw geladen.Nieuw detailreadmodel.

8. Alternatieve en exceptionele processtromen

IDVanaf stapSituatieSysteemgedragPopup / meldingDatamutatie
ALT-0011Geen veld is inhoudelijk gewijzigd.Opslaan wordt niet uitgevoerd of resulteert in geen mutatie.Niet van toepassing.Geen.
ALT-0024Naam is niet uniek binnen actieve records.De backend weigert de wijziging en toont validatiefeedback.Niet van toepassing.Geen.
ALT-0034ColorHex heeft ongeldig formaat.De backend weigert de wijziging.Niet van toepassing.Geen.
ALT-0044IconKey is onbekend of niet toegestaan.De backend weigert de wijziging.Niet van toepassing.Geen.
ALT-0055Beheerder annuleert de bevestigingspopup.De wijziging wordt niet opgeslagen.POP-BEH-CAT-EDIT-CONFIRM.Geen.
ALT-0066Reden ontbreekt.De bevestiging wordt geweigerd.POP-BEH-CAT-EDIT-CONFIRM.Geen.
ALT-0077Gelijktijdige wijziging door andere beheerder.De backend detecteert verouderde data en vraagt herladen of opnieuw controleren.Niet van toepassing.Geen.

9. Business rules

IDBusiness rule
BR-001Naam, kleur en icoon zijn centrale categorie-identiteit en werken door in alle contexten waar dezelfde categorie zichtbaar is.
BR-002Een wijziging vereist altijd een verplichte reden van de beheerder.
BR-003Per inhoudelijk gewijzigd veld wordt een afzonderlijk CategoryHistory-record geschreven.
BR-004Een gecombineerde wijziging van naam en kleur levert aparte ActionType-regels op.
BR-005Categories.Name moet uniek blijven binnen actieve records.
BR-006Een categoriewijziging herschrijft geen historische ExerciseRuns of SharedExercises-snapshots.
BR-007Docenten kunnen centrale categorie-identiteit niet via hun eigen niveaucontext wijzigen wanneer de categorie gedeeld in gebruik is.

10. Datavalidatie

IDValidatie
VAL-001Name is verplicht, getrimd en maximaal 150 tekens.
VAL-002Name moet uniek zijn binnen actieve Categories-records.
VAL-003ColorHex is verplicht en moet voldoen aan het hex-formaat #RRGGBB.
VAL-004IconKey is verplicht en moet voorkomen in de toegestane categorie-icoonset.
VAL-005Reason is verplicht en maximaal 500 tekens voor CategoryHistory.
VAL-006Alle wijzigingen worden server-side vergeleken met de actuele databasewaarde.
VAL-007CategoryId mag niet via de client worden vervangen door een ander record.

11. Datamutaties en events

IDMutatie / eventToelichting
MUT-001Update CategoriesName, ColorHex en/of IconKey worden bijgewerkt, inclusief UpdatedByUserId en UpdatedAtUtc.
MUT-002CategoryHistory CREATEPer gewijzigd veld wordt één CategoryHistory-regel geschreven met UPDATE_NAME, UPDATE_COLOR of UPDATE_ICON.
MUT-003Auditreadmodel vernieuwenDe beheerweergave leest de actuele categoriegegevens opnieuw.

12. Geen datamutaties

IDGeen mutatieReden
NO-001TeacherLevelCategoriesCategorie-koppelingen aan docentniveaus blijven gelijk.
NO-002TeacherLevelCategoryExercisesOefenkoppelingen blijven gelijk.
NO-003CategoryMigrationsEen gewone identiteitswijziging maakt geen migratierecord aan.
NO-004ExerciseRunsHistorische runcontext wordt niet aangepast.
NO-005SystemMessagesCategoriegegevens wijzigen verstuurt geen systeembericht; de wijziging blijft zichtbaar via CategoryHistory.

13. State diagram

Niet van toepassing. Deze usecase wijzigt categorie-identiteitsvelden, maar kent geen afzonderlijke processtatus. De mutatie- en auditlifecycle staan in hoofdstuk 15.

14. Decision flow

15. Data lifecycle diagram

16. Sequence diagrammen

17. Popupverwijzingen

Deze usecase verwijst uitsluitend naar PopupKey. Popupteksten, knopteksten, inputlabels, acties en themakeuzes blijven bronhoudend in het popupregister en popup-themes.

PopupKeyGebruik
POP-BEH-CAT-EDIT-CONFIRMBevestiging van inhoudelijke categoriewijziging met verplichte reden.

18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification

DocumentAfleiding
Functioneel OntwerpBeheer kan naam, kleur en icoon van centrale categorieën wijzigen met bevestiging en reden.
Technisch OntwerpTechnisch Ontwerp: oefencatalogus, databaseontwerp en historie en background jobs beschrijven de technische uitwerking. Wijzigingen worden transactioneel opgeslagen met CategoryHistory per gewijzigd veld.
Software Requirements SpecificationSRS moet unieke naam, geldig kleurformaat, geldige iconkey en verplichte reden afdwingen.
DatabaseGebruikt Categories en CategoryHistory; geen wijziging aan TeacherLevelCategories of ExerciseRuns.

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-afleidingDektUsecasecontext
UC-BEH-CAT-003-REQ-001SRS-CAT-002
SRS-ADM-001
AC-CAT-002
AC-ADM-001
Beheerders toestaan naam, kleur en icoon van een centrale categorie te wijzigen
UC-BEH-CAT-003-REQ-002SRS-ADM-001
AC-ADM-001
Vóór opslaan een bevestiging met verplichte reden vragen
UC-BEH-CAT-003-REQ-003SRS-CAT-001
SRS-ADM-001
AC-CAT-001
AC-ADM-001
Categorienaam uniek houden binnen actieve categorieën
UC-BEH-CAT-003-REQ-004SRS-ADM-001
AC-ADM-001
ColorHex valideren op #RRGGBB-formaat
UC-BEH-CAT-003-REQ-005SRS-ADM-001
AC-ADM-001
IconKey valideren tegen de toegestane iconset
UC-BEH-CAT-003-REQ-006SRS-ADM-001
SRS-NFR-AUD-001
AC-ADM-001
AC-NFR-AUD-001
Per gewijzigd veld een CategoryHistory-record vastleggen
UC-BEH-CAT-003-REQ-007SRS-CAT-004
SRS-LRN-009
SRS-SHR-008
SRS-ADM-001
AC-CAT-004
AC-LRN-009
AC-SHR-008
AC-ADM-001
Historische exercise runs en gedeelde oefening-snapshots niet herschrijven door een categoriewijziging
UC-BEH-CAT-003-REQ-008SRS-ADM-001
SRS-NFR-SEC-001
AC-ADM-001
AC-NFR-SEC-001
Gelijktijdige wijzigingen veilig detecteren of afhandelen