Skip to main content

UC-BEH-DOCSUP-008 — Leerling aan niveau toevoegen

1. Kerngegevens

VeldWaarde
Usecase-IDUC-BEH-DOCSUP-008
NaamLeerling aan niveau toevoegen
DomeinBeheerder / Docentondersteuning
Primaire actorBeheerder
Secundaire actor(en)Frontend, backend, database, autorisatiecomponent, docentondersteuningcomponent, historiecomponent
RolcontextActieve beheerdercontext; server-side bepaald vanuit de ingelogde gebruiker
Betrokken schermenContent > Docent ondersteuning
Gerelateerde usecasesUC-BEH-DOCSUP-001, UC-BEH-DOCSUP-002, UC-BEH-DOCSUP-003, UC-BEH-DOCSUP-004, UC-BEH-DOCSUP-005, UC-BEH-DOCSUP-006, UC-BEH-DOCSUP-007, UC-BEH-DOCSUP-009, UC-BEH-DOCSUP-010, UC-BEH-DOCSUP-011, UC-BEH-DOCSUP-012, UC-BEH-DOCSUP-013, UC-BEH-DOCSUP-014
Primaire entiteitenUsers, UserRoles, Roles, TeacherLevels, TeacherLevelCategories, TeacherLevelCategoryExercises, Exercises, ExerciseModules, ExerciseHistory, LevelCollaborators, LevelStudentAuthorizations, UserRelationships
Secundaire entiteiten / eventsRelationshipEvents, SystemMessages, beheerlog, docentondersteuning-readmodels, autorisatiecomponent
Gerelateerde popupsPOP-BEH-DOCSUP-ADD-STUDENT-CONFIRM
PopupregisterOntwerpbronnen — Popup-register
MoSCoWMust

2. Omschrijving

Deze usecase beschrijft hoe een beheerder vanuit de tab Leerlingtoegang een leerling aan een niveau van de geselecteerde docentcontext toevoegt.

De actie is supportgericht en gebruikt bestaande geldige docent-leerlingrelatiecontext. Docentondersteuning maakt niet stilzwijgend een nieuwe leerlingrelatie aan.

Bij succesvolle koppeling ontstaat of activeert een niveauautorisatie voor de leerling binnen de docentcontext en wordt de wijziging auditbaar vastgelegd.

Uitgangspunten

  • Docentondersteuning werkt altijd vanuit één gekozen docentcontext.
  • De beheerder heeft supportgerichte inzage, maar mutaties blijven beperkt tot expliciete beheeracties met audit.
  • Centrale categorie- en module-identiteit worden niet vanuit deze pagina beheerd.
  • Server-side autorisatie is leidend; clientstate mag geen objecttoegang afdwingen.
  • Historische runs, resultaten en PDF-contexten worden niet herschreven.

3. Scope

Deze usecase beschrijft:

  • Selecteren van een leerling die aan het niveau toegevoegd mag worden.
  • Controleren van docent-leerlingrelatie of toegestane beheercontext.
  • Aanmaken of heractiveren van een niveauautorisatie.
  • Vastleggen van actor, tijdstip en reden waar vereist.
  • Informeren van de leerling via systeembericht wanneer de leerling een actief intern account heeft.

Deze usecase beschrijft niet:

  • Centraal categoriebeheer; dat blijft bronhoudend in Beheerder / Categorieën beheren.
  • Centraal technisch modulebeheer; dat blijft bronhoudend in Beheerder / Modules beheren.
  • Volledig account- en rolbeheer; dat blijft bronhoudend in Beheerder / Accountbeheer.
  • Reguliere docentflows vervangen; docentondersteuning is supportgericht en niet de primaire docentinterface.
  • Live meekijken tijdens actieve oefeningen; beheerders mogen geschiedenis analyseren, maar niet live meekijken.
  • Popupteksten, knopteksten of inputlabels specificeren; usecases verwijzen uitsluitend naar PopupKey.

3.1 Afbakening met aangrenzende domeinen

OnderdeelAfbakening
Docent / OefenaanbodDocenten beheren hun eigen niveaus, categorieën en oefeningen via de reguliere docentflows; docentondersteuning biedt beheerderinzage en gerichte correctie.
Beheerder / Categorieën beherenCentrale categorie-identiteit, migratie en statuswijziging worden daar beheerd, niet in docentondersteuning.
Beheerder / Modules beherenTechnische modulemetadata en modulemigraties worden daar beheerd; docentondersteuning kan alleen concrete oefeningcontext inspecteren.
Beheerder / AccountbeheerRollen, accountstatus en account lifecycle horen daar; docentondersteuning gebruikt bestaande account- en relatiecontext.
Generiek / RelatiesRelaties en uitnodigingen blijven bronhoudend in het relatiedomein; docentondersteuning kan alleen bestaande geldige context gebruiken of een expliciete beheeractie auditen.

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 > Docent ondersteuning.
PRE-004De pagina gebruikt actuele serverdata; clientstate, routeparameters of verborgen formuliervelden bepalen geen autorisatie, docentcontext, niveaucontext of oefeningcontext.
PRE-005De ondersteuningsweergave voor één docent is geopend.
PRE-006Er is één niveau geselecteerd binnen deze docentcontext.
PRE-007De kandidaat-leerling heeft een geldige relatie- of toegangscontext voor deze docent.

5. Post-condities

IDResultaat
POST-001De leerling heeft toegang tot het gekozen niveau binnen de docentcontext wanneer de koppeling slaagt.
POST-002De niveauautorisatie is auditbaar vastgelegd.
POST-003Er ontstaat geen nieuwe docent-leerlingrelatie door deze usecase.
POST-004De systeemberichtcommunicatie is gekoppeld aan de autorisatiemutatie wanneer de leerling een actief intern account heeft.
POST-005De structuur- en samenvattingsaantallen kunnen opnieuw worden afgeleid.

6. Trigger

De usecase start wanneer de beheerder in Leerlingtoegang een leerling selecteert en toevoegen aan het gekozen niveau bevestigt.

7. Normale processtroom

StapActorComponent / contextHandelingResultaatBelangrijke gegevens
1BeheerderLeerlingtoegang-tabKiest Leerling toevoegen voor niveau.De frontend opent de geselecteerde niveaucontext.LevelId.
2BackendAutorisatiecomponentControleert beheerdercontext.Alleen beheerder mag supportmutatie uitvoeren.Server-side rolcontext.
3BackendDocentContextServiceValideert LevelId binnen docentcontext.Niveau buiten context wordt geweigerd.TeacherLevels.
4BackendRelatieServiceControleert kandidaat-leerlingcontext.Alleen geldige relatie/toegangscontext is toegestaan.UserRelationships.
5BeheerderPopupBevestigt de actie en geeft reden indien gevraagd.De definitieve actie wordt gestart.POP-BEH-DOCSUP-ADD-STUDENT-CONFIRM.
6BackendAutorisatieServiceMaakt of heractiveert niveauautorisatie.Leerling krijgt niveautoegang.LevelStudentAuthorizations.
7BackendAuditServiceLegt wijziging vast.Supportactie is herleidbaar.Beheerlog / history.
8BackendSystemMessageServiceInformeert leerling indien van toepassing.Systeemcommunicatie volgt bestaande regels.SystemMessages.

8. Alternatieve en exceptionele processtromen

StapSituatieAfhandelingPopupKeyDatamutatie
2Beheerdercontext is ongeldig.De backend weigert de actie en toont een veilige blokkade.POP-BEH-DOCSUP-NO-ACCESSGeen.
3De geselecteerde docent bestaat niet of is niet toegankelijk.De ondersteuningsweergave wordt niet geopend of wordt veilig teruggezet naar het overzicht.POP-BEH-DOCSUP-SAVE-ERRORGeen.
4Het gekozen object bestaat niet meer.De pagina toont dat het object niet beschikbaar is en ververst de context.Niet van toepassingGeen.
5De readmodeldata is tijdelijk incompleet.De beschikbare gegevens worden getoond met veilige ontbrekend-status; ontbrekend wordt niet als nul geïnterpreteerd.Niet van toepassingGeen.
6De beheerder gebruikt een oude route of clientstate.De backend negeert de clientcontext en herleidt de actuele context opnieuw.Niet van toepassingGeen.

9. Business rules

IDBusiness rule
BR-UC-BEH-DOCSUP-008-001Een leerling kan alleen aan een niveau worden toegevoegd binnen een geldige docentcontext.
BR-UC-BEH-DOCSUP-008-002De actie mag geen nieuwe docent-leerlingrelatie aanmaken.
BR-UC-BEH-DOCSUP-008-003De leerling moet een geldige bestaande relatie- of beheerbare toegangscontext hebben.
BR-UC-BEH-DOCSUP-008-004Dubbele actieve niveauautorisaties zijn niet toegestaan.
BR-UC-BEH-DOCSUP-008-005Heractiveren van een eerder ingetrokken autorisatie moet auditbaar zijn.
BR-UC-BEH-DOCSUP-008-006De wijziging mag geen resultaten of historische runs aanmaken of wijzigen.
BR-UC-BEH-DOCSUP-008-007Communicatie naar de leerling is informatief en vormt niet de bron van autorisatie.

10. Datavalidatie

IDValidatie
VAL-UC-BEH-DOCSUP-008-001LevelId is verplicht en moet binnen de docentcontext vallen.
VAL-UC-BEH-DOCSUP-008-002StudentUserId is verplicht en moet een leerlingaccount zijn.
VAL-UC-BEH-DOCSUP-008-003De leerling mag niet dezelfde gebruiker zijn als de docent.
VAL-UC-BEH-DOCSUP-008-004De leerling moet voldoen aan geldige relatie- of beheercontextregels.
VAL-UC-BEH-DOCSUP-008-005Er mag nog geen actieve autorisatie voor dezelfde leerling en hetzelfde niveau bestaan.
VAL-UC-BEH-DOCSUP-008-006Een verplichte reden mag niet leeg zijn wanneer de popup of beheerflow die vereist.
VAL-UC-BEH-DOCSUP-008-007De backend moet de autorisatiemutatie transactioneel verwerken.

11. Datamutaties en events

Object / eventMutatie
LevelStudentAuthorizationsAanmaken of heractiveren van autorisatie voor StudentUserId en LevelId.
Beheerlog / historyVastleggen van beheerder, tijdstip, niveau, leerling en reden.
SystemMessagesInformatief bericht aan de leerling wanneer de leerling een actief intern account heeft; het bericht is geen autorisatiebron.

12. Geen datamutaties

ObjectWaarom geen mutatie
UserRelationshipsEr wordt geen nieuwe relatie aangemaakt.
ExerciseRunsGeen run of resultaat wordt aangemaakt of gewijzigd.
ExercisesOefeningen blijven ongewijzigd.
TeacherLevelsNiveaugegevens blijven ongewijzigd.

13. State diagram

14. Decision flow

15. Data lifecycle diagram

16. Sequence diagrammen

17. Popupverwijzingen

PopupKeyGebruik
POP-BEH-DOCSUP-ADD-STUDENT-CONFIRMBevestiging voor het toevoegen van een leerling aan een niveau.
POP-BEH-DOCSUP-SAVE-ERRORFoutafhandeling wanneer de autorisatiemutatie niet kan worden opgeslagen.

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

OnderdeelAfleiding
Functioneel OntwerpFO beschrijft dat docentondersteuning leerlingtoegang gericht kan aanpassen binnen de docentcontext.
Technisch OntwerpTechnisch Ontwerp: technische rolflows, oefencatalogus, relatiebeheer en logging en historie beschrijven de technische uitwerking. TO vereist transactionele verwerking van niveauautorisatie, audit en systeemberichtcommunicatie wanneer de leerling een actief intern account heeft.
Software Requirements SpecificationSRS moet de kandidaatselectie, relatievoorwaarde, dubbele-autorisatieregel en auditplicht vastleggen.
DatabaseSchrijft LevelStudentAuthorizations en beheerhistory; maakt geen UserRelationship aan.

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
REQ-UC-BEH-DOCSUP-008-001SRS-CAT-001
SRS-LRN-009
SRS-TCH-003
SRS-ADM-008
SRS-ADM-001
AC-CAT-001
AC-LRN-009
AC-TCH-003
AC-ADM-008
AC-ADM-001
Een beheerder een leerling aan een niveau kunnen toevoegen binnen docentondersteuning
REQ-UC-BEH-DOCSUP-008-002SRS-CAT-001
SRS-TCH-002
SRS-ADM-001
AC-CAT-001
AC-TCH-002
AC-ADM-001
Afdwingen dat het niveau binnen de gekozen docentcontext valt
REQ-UC-BEH-DOCSUP-008-003SRS-ACC-002
SRS-LRN-009
SRS-ADM-002
SRS-ADM-001
AC-ACC-002
AC-LRN-009
AC-ADM-002
AC-ADM-001
Afdwingen dat de kandidaat een leerlingaccount is
REQ-UC-BEH-DOCSUP-008-004SRS-REL-001
SRS-LRN-009
SRS-TCH-001
SRS-ADM-001
AC-REL-001
AC-LRN-009
AC-TCH-001
AC-ADM-001
Via deze usecase geen nieuwe docent-leerlingrelatie aanmaken
REQ-UC-BEH-DOCSUP-008-005SRS-AUTH-001
SRS-CAT-001
SRS-ADM-001
AC-AUTH-001
AC-CAT-001
AC-ADM-001
Dubbele actieve niveauautorisaties voorkomen
REQ-UC-BEH-DOCSUP-008-006SRS-AUTH-001
SRS-ADM-001
SRS-NFR-AUD-001
AC-AUTH-001
AC-ADM-001
AC-NFR-AUD-001
De autorisatiemutatie auditbaar vastleggen
REQ-UC-BEH-DOCSUP-008-007SRS-LRN-009
SRS-ADM-001
AC-LRN-009
AC-ADM-001
Historische runs en resultaten ongewijzigd laten
REQ-UC-BEH-DOCSUP-008-008SRS-MSG-001
SRS-LRN-009
SRS-ADM-001
AC-MSG-001
AC-LRN-009
AC-ADM-001
Leerlingcommunicatie via de bestaande systeemberichtregels verwerken wanneer van toepassing