đź”— Diagrammes de communication CV-builder

Note

đź“ş Diagrammes SVG de ce document

Documents liĂ©s : Diagrammes de sĂ©quences · Diagrammes d’Ă©tats · Diagramme de classes

Track Fonctionnel 2TUP — Phase 2 : Modèle dynamique

Le diagramme de communication (ex-diagramme de collaboration) est la vue duale du diagramme de sĂ©quence : il montre les mĂŞmes messages, mais organisĂ©s autour de la structure des liens entre participants plutĂ´t que le long de l’axe du temps. Notation UML :

  • participants en rectangles : Classe (composant Vue, composable, service Spring, collection MongoDB)

  • messages numĂ©rotĂ©s (1., 2., 3.…) le long des liens, la flèche indiquant le sens d’envoi

  • retours en pointillĂ©s (ex. lastSavedAt)

  • les frontières navigateur / backend sont matĂ©rialisĂ©es quand la collaboration les traverse

Les trois collaborations documentées ici reflètent le code réel : deux sont 100 % côté navigateur (export PDF, score & conseils) et une seule traverse le backend (sauvegarde automatique).

Sauvegarde automatique (UC19)

Diagramme de communication - Sauvegarde automatique

Contexte : il n’existe ni timer 30 s, ni brouillon sĂ©parĂ©, ni IndexedDB. L’autosave est un watchDebounced de 2 secondes (deep) posĂ© sur store.cvData dans CvWorkspaceView, actif uniquement si currentCvId est dĂ©fini ; les actions IA validĂ©es dans le chat Clara dĂ©clenchent en plus des appels impĂ©ratifs Ă  autoSave().

Participant RĂ´le

: formulaires / actions IA

8 formulaires de section + actions du chat Clara — mutent cvData

store : useCvBuilderStore

store Pinia unique — détient cvData, currentCvId, lastSavedAt

: CvWorkspaceView

héberge le watchDebounced 2 s et appelle store.autoSave()

: CvDocumentController

endpoint REST PUT /api/v1/cv-documents/{id} (Bearer JWT)

: CvDocumentService

service applicatif — contrĂ´le d’ownership (userId), update(…​)

: CvDocumentRepositoryAdapter

isole le MongoRepository bloquant sur Schedulers.boundedElastic()

MongoDB : cvDocuments

collection persistant l’intĂ©gralitĂ© du CV (champ data schemaless)

Liens numérotés :

  1. mutation cvData — un formulaire de section ou une action IA validée modifie le store

  2. watchDebounced( 2 s, deep ) — CvWorkspaceView observe store.cvData et se dĂ©clenche après 2 s d’inactivitĂ©

  3. store.autoSave( ) — upsert complet du document courant

  4. PUT /api/v1/cv-documents/{id} — appel axios (ou POST /cv-documents si le CV n’a pas encore d’id)

  5. CvDocumentService.update( ) — vĂ©rification d’ownership (userId ≠ → DomainException « Not authorized »)

  6. adapter → boundedElastic — le repository Mongo bloquant est exécuté hors event-loop Netty

  7. upsert cvDocuments — écriture MongoDB, puis retour pointillé CvDocumentResponse → mise à jour de lastSavedAt

Lecture : toute mutation de cvData (1) est absorbĂ©e par le debounce de 2 s (2) ; l’upsert (3-7) traverse la frontière HTTPS/JWT une seule fois, et le retour lastSavedAt alimente l’indicateur « EnregistrĂ© » de l’Ă©diteur. accentColor et selectedTemplate ne sont pas surveillĂ©s par ce watcher.

Export PDF (UC11)

Diagramme de communication - Export PDF

Contexte : l’export PDF est entièrement rĂ©alisĂ© dans le navigateur — PDF vectoriel produit par la boĂ®te d’impression via window.print(). Aucun PDF n’est gĂ©nĂ©rĂ© ni stockĂ© cĂ´tĂ© serveur : l’endpoint REST exportCv rĂ©pond 501 NOT_IMPLEMENTED. Le chemin raster html2canvas-pro + jsPDF est prĂ©sent dans le code mais jamais appelĂ©.

Participant RĂ´le

Candidat

clique sur le bouton « Exporter »

: EditorPreviewPanel

panneau d’aperçu de l’Ă©diteur — porte le bouton d’export

: useCvVectorExport

composable — orchestre exportVectorPdf()

navigateur : window

moteur d’impression du navigateur (window.print())

: CvPrintDocument

rendu d’impression tĂ©lĂ©portĂ© dans body#cv-print-root — @media print, @page A4 marges 12 mm

Plausible

analytics — reçoit l’Ă©vĂ©nement cv_exported

Liens numérotés :

  1. clic « Exporter » — depuis EditorPreviewPanel

  2. exportVectorPdf( ) — appel du composable

  3. nextTick( ) / requestAnimationFrame — attente que le DOM d’impression soit rendu

  4. window.print( ) — ouverture de la boĂ®te d’impression

  5. rendu CvPrintDocument — mise en page @media print (A4, marges 12 mm, break-inside: avoid)

  6. dialogue « Enregistrer en PDF » — le candidat nomme et enregistre le fichier + l’Ă©vĂ©nement Plausible cv_exported est Ă©mis en parallèle.

Lecture : la collaboration ne comporte aucun lien vers le backend — le pivot est window : le composable lui dĂ©lègue l’impression (4), le navigateur rend CvPrintDocument (5) puis rend la main au candidat via le dialogue système (6).

Score & conseils (UC18)

Diagramme de communication - Score et conseils

Contexte : il n’existe pas de « validation mĂ©tier » bloquante (aucun champ required, aucun CVValidator). L’Ă©cran ATS calcule un score de complĂ©tude et un score ATS purement cĂ´tĂ© client via le composable useCvScoring — aucun appel rĂ©seau.

Participant RĂ´le

Candidat

ouvre l’Ă©cran score (?screen=ats)

: CvAtsScreen

Ă©cran d’affichage — jauge, score ATS, conseils

: useCvScoring

composable de notation (computed réactifs)

store : useCvBuilderStore

source de vérité — cvData lu de manière réactive

Liens numérotés :

  1. ouverture ?screen=ats — navigation interne par query param vers CvAtsScreen

  2. useCvScoring( ) — l’Ă©cran instancie les computed de notation

  3. lecture cvData — accès réactif au store (recalcul automatique à chaque mutation)

  4. notation 8 sections /10 — complétude par section, agrégée en pourcentage

  5. bonus ATS — bonus fixes (nom 15, titre 10, email 10, résumé > 50 c. 15, ≥ 1 exp 20, ≥ 1 formation 10, ≥ 3 compétences 15, ≥ 1 langue 5)

  6. détection 12 clichés — repérage de formules toutes faites codées en dur

  7. affichage jauge + tips — retour pointillĂ© vers l’Ă©cran : jauge, score ATS, conseils contextuels

Lecture : collaboration 100 % client : la notation (4-6) est une chaĂ®ne de computed internes au composable, recalculĂ©e Ă  chaque modification de cvData (3) ; rien n’est persistĂ© et rien ne bloque l’export ou le partage.

Sync Gate — Cohérence avec les autres modèles

  • MĂŞmes messages que les diagrammes de sĂ©quences correspondants — seule la prĂ©sentation change (structure des liens vs axe du temps)

  • Chaque participant est une classe, un composant ou un composable du modèle statique, et chaque lien matĂ©rialise une dĂ©pendance documentĂ©e dans l’architecture backend

  • Frontières respectĂ©es : UC11 et UC18 restent dans le navigateur ; UC19 est la seule collaboration qui traverse HTTPS/JWT jusqu’Ă  MongoDB (via boundedElastic)

Verdict : vues séquence et communication cohérentes entre elles et avec le code réel — validé.