UC-OVG-LIVE-004 — Live voortgang van kind volgen

1. Kerngegevens

Veld	Waarde
Usecase-ID	UC-OVG-LIVE-004
Naam	Live voortgang van kind volgen
Domein	Ouder/voogd / Online en live meekijken
Primaire actor	Ouder/voogd
Secundaire actor(en)	Frontend, backend, database, realtime service
Rolcontext	Actieve ouder-/voogdcontext; server-side bepaald vanuit de ingelogde gebruiker
Betrokken schermen	Live meekijkweergave
Gerelateerde usecases	UC-OVG-LIVE-003, UC-OVG-LIVE-005, UC-OVG-LIVE-007
Primaire entiteiten	ExerciseRuns, ExerciseRunProgress, LiveViewAudit, SignalRMessages
Secundaire entiteiten / events	LiveProgressUpdated
Gerelateerde popups	POP-OVG-LIVE-SESSION-ENDED, POP-OVG-LIVE-ACCESS-DENIED
Popupregister	Ontwerpbronnen — Popup-register
MoSCoW	Must

2. Omschrijving

Deze usecase beschrijft hoe een ouder/voogd de actuele voortgang van een kind volgt tijdens een live-meekijksessie. Na elk bevestigd antwoord van het kind wordt de voortgang door de leerlingflow server-side opgeslagen en via realtime updates zichtbaar voor bevoegde meekijkers.

De ouder/voogd ziet de actuele vraag, voortgang en status, maar kan geen antwoord wijzigen, geen vraag overslaan en geen feedback naar de oefenrun schrijven.

Uitgangspunten

• Server-side voortgang is bron van waarheid.
• SignalR transporteert updates.
• De weergave is read-only.
• LiveViewAudit blijft open tijdens de sessie.
• Einde van de run beëindigt liveweergave veilig.

3. Scope

Deze usecase beschrijft:

• ontvangen van voortgangsupdates;
• tonen van actuele vraag en beantwoorde vragenstatus;
• bijwerken van voortgangsindicator;
• afhandelen van run-afronding of verlaten oefencontext;
• voorkomen dat de meekijker mutaties uitvoert.

Deze usecase beschrijft niet:

• antwoorden geven;
• score aanpassen;
• vraagvolgorde beïnvloeden;
• resultaat als eigenaar van run wijzigen.

3.1 Afbakening met aangrenzende domeinen

Onderdeel	Afbakening
Leerling / Oefenen en voortgang	De leerlingflow schrijft ExerciseRunProgress, totalen en runstatus. Deze usecase leest alleen de opgeslagen voortgang.
Docent / Online en live meekijken	De technische liveweergave kan gelijkend zijn, maar docentautorisatie blijft beperkt tot eigen docentcontext en niveauautorisaties.
Generiek / Relaties	De actieve ouder-/voogdrelatie bepaalt de toegang; relatievorming en uitnodigingen blijven buiten deze live-usecases.
Technische realtime-laag	SignalR transporteert updates; de server-side opgeslagen voortgang blijft bron van waarheid.

4. Pre-condities

| 001 | Live sessie is gestart. | | 002 | LiveViewAudit staat open. | | 003 | Run is actief of wordt net beëindigd. | | 004 | Realtimeverbinding is actief. |

5. Post-condities

| 001 | Voortgang is actueel getoond. | | 002 | Geen oefenstatus is gewijzigd door ouder/voogd. | | 003 | Bij einde run is vervolgafhandeling gestart. | | 004 | LiveViewAudit blijft herleidbaar. |

6. Trigger

Het kind bevestigt een antwoord of de server verwerkt een voortgangswijziging binnen de actieve run.

7. Normale processtroom

Stap	Actor / component	Actie	Resultaat	Data / controle
1	Kind / oefenscherm	Bevestigt antwoord	Leerlingflow verwerkt voortgang	ExerciseRunProgress
2	Backend	Slaat voortgang op binnen leerlingflow	Nieuwe bronstatus beschikbaar	Database
3	Realtime service	Publiceert update	Meekijker ontvangt voortgang	SignalR group
4	Frontend	Ververs actuele vraagstatus	Ouder/voogd ziet live stand	LiveViewModel
5	Frontend	Markeert beantwoorde vragen	Vraaglijst wordt bijgewerkt	Progress status
6	Backend / frontend	Detecteert eventueel einde run	Live-eindeafhandeling wordt voorbereid	ExerciseRuns

7.1 Scherm- en routegedrag

• De Online-pagina gebruikt ouder-/voogdcontext als actieve rol-ingang.
• De liveweergave is volledig read-only en bevat geen antwoord- of interventieacties.
• Actuele status wordt na relevante gebeurtenissen opnieuw afgeleid uit server-side voortgang.
• Bij gecombineerde rollen bepaalt de gekozen contexttab welke dataset en filters zichtbaar zijn.

8. Alternatieve en exceptionele processtromen

| 001 | Update komt te laat of dubbel binnen: frontend past idempotente volgordecontrole toe. | | 002 | Run wordt afgerond: liveweergave toont afsluiting en beëindigt sessie via UC-OVG-LIVE-007. | | 003 | Relatie vervalt tijdens sessie: vervolgupdates worden gestopt en toegang wordt veilig beëindigd. | | 004 | Meekijker heeft naar eerdere vraag gebladerd: actuele update wordt gemarkeerd, maar scherm blijft in browse-modus. | | 005 | Realtimeverbinding valt weg: UC-OVG-LIVE-008 wordt gestart. |

8.1 Afhandeling van verouderde of ongeldige clientstate

• De backend herhaalt autorisatie bij iedere raadpleeg-, filter-, export- of liveactie.
• Oude routeparameters, browserselecties en clientcache worden genegeerd wanneer de actuele server-side context geen toegang geeft.
• De frontend mag het scherm herstellen door het actuele readmodel opnieuw op te vragen.

9. Business rules

| 001 | Meekijkweergave wijzigt geen run. | | 002 | Updates komen pas na server-side verwerking door de leerlingflow. | | 003 | Actuele vraag wordt bepaald uit opgeslagen voortgang. | | 004 | Meerdere meekijkers mogen dezelfde update ontvangen. | | 005 | Bij einde van run wordt liveweergave veilig beëindigd. |

9.1 Readmodel- en tellerdefinities

Waarde	Definitie	Uitsluitingen / grenzen
Actuele vraag	Vraagpositie volgens server-side voortgang.	Niet alleen clientstate van leerling.
Vraagstatus	Onbeantwoord, goed, fout of Geen idee waar bekend.	Alleen read-only.
Voortgangsteller	Vraag x van n.	Afgeleid uit rungegevens.
Live-modus	Meekijker volgt actuele vraag tenzij handmatig gebladerd.	Browse-modus in UC-OVG-LIVE-005.

9.2 Autorisatie- en privacygrenzen

• De zichtbare dataset wordt altijd server-side beperkt tot actieve ouder-/voogdrelaties.
• Een gebruiker met gecombineerde rollen krijgt binnen deze route geen impliciete docent- of beheerderinzage.
• Resultaat- en livegegevens van niet-gekoppelde kinderen worden nooit gedeeltelijk getoond.

10. Datavalidatie

| 001 | Update moet bij dezelfde run horen. | | 002 | LiveViewAudit moet nog open zijn. | | 003 | Meekijker moet nog geautoriseerd zijn. | | 004 | Updatevolgorde moet consistent zijn. | | 005 | Payload mag geen bewerkbare leerlinginvoer aan meekijker geven. |

11. Datamutaties en events

| 001 | Geen mutatie door ouder/voogd. | | 002 | De voortgangsmutatie behoort tot de leerlingantwoordflow en valt buiten deze usecase. | | 003 | Functioneel event LiveProgressUpdated beschrijft de realtime publicatie van reeds opgeslagen voortgang. |

12. Geen datamutaties

| 001 | Geen antwoordmutatie door ouder/voogd. | | 002 | Geen scoremutatie door ouder/voogd. | | 003 | Geen relatiemutatie. | | 004 | Geen wijziging van oefenconfiguratie of vraagvolgorde. |

13. State diagram

Niet van toepassing. Deze usecase volgt een bestaande live sessie en wijzigt zelf geen persistent statusobject. Het beëindigen van de sessie valt onder UC-OVG-LIVE-007.

14. Decision flow

15. Data lifecycle diagram

16. Sequence diagrammen

17. Popupverwijzingen

PopupKey	Gebruik
POP-OVG-LIVE-SESSION-ENDED	Wordt gebruikt wanneer de live sessie eindigt doordat de run is beëindigd.
POP-OVG-LIVE-ACCESS-DENIED	Wordt gebruikt wanneer actuele autorisatie tijdens de sessie ontbreekt.

Popupteksten, knopteksten, inputlabels en themakeuzes worden niet in deze usecase gedupliceerd. Het popupregister en de popupthemes blijven bronhoudend.

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

| 001 | Live meekijken volgt opgeslagen voortgang en is read-only. | | 002 | Updates worden vrijwel direct gedeeld na bevestigde antwoorden. | | 003 | LiveViewAudit scheidt live monitoring van autorisatie-audit. |

18.1 Impact voor database-informatie en ontwerpbronnen

| 001 | Autorisatiematrix moet ouder-/voogdraadpleging onderscheiden van docentraadpleging. | | 002 | Usecase-scherm-matrix moet de betrokken ouder-/voogdschermen koppelen aan deze usecase. | | 003 | Usecase-requirement-matrix moet de requirements uit hoofdstuk 19 opnemen. | | 004 | LiveViewAudit en realtime-afhandeling moeten ouder-/voogdrolcontext expliciet ondersteunen. |

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.

Er zijn voor deze usecase geen aparte requirement-afleidingen vastgelegd. De procesbeschrijving blijft broncontext voor de SRS-traceability.