Conception système
Créez le plus petit ensemble de vues qui répond à la question de l'utilisateur. Préférez les fichiers .drawio modifiables pour les diagrammes formels ; respectez la notation, le format, la grille d'évaluation du cours et les fichiers existants. Un fichier XML valide ne prouve pas un modèle correct.
Flux de travail
- Établissez le public, le périmètre du système, la question, le scénario et le niveau d'abstraction. Lisez les exigences/schéma/code fournis ainsi que toute grille d'évaluation. Enregistrez les cardinalités incertaines, les permissions, les règles de cycle de vie et les interfaces externes comme hypothèses ; ne posez de questions que lorsqu'elles modifient matériellement la réponse. N'inventez pas d'infrastructure ou de relations obligatoires.
- Choisissez les vues à l'aide du tableau de routage ci-dessous. Lisez uniquement les références pertinentes ainsi que
diagram-validation.md. Distinguez les preuves de l'état actuel de la conception proposée. Gardez un petit glossaire avec des identifiants de concepts stables lorsque plusieurs diagrammes partagent des concepts. - Construisez un inventaire sémantique avant de placer les formes : participants/éléments, relations avec direction et signification des extrémités, contraintes et identifiants d'exigences. Pour un DFD, ajoutez un dictionnaire de flux et des signatures de décomposition de frontière ; pour un modèle de données, identifiez les clés et les dépendances.
- Suivez la procédure de dessin spécifique au diagramme. Définissez la notation explicitement (par exemple, UML 2, patte d'oie, Gane–Sarson ; contexte puis niveau 0). Séparez les règles sémantiques des choix de disposition recommandés. Résolvez les sources conflictuelles comme décrit dans
sources.md. - Pour Draw.io, lisez
drawio-rendering.mdetlayout.md. Créez des formes et connecteurs natifs avec des identifiants stables, en utilisant un sérialiseur XML. Copiez un exemple pertinent uniquement après avoir remplacé ses faits de domaine. Pour les autres formats, lisezfallbacks.md. - Exécutez
python3 <skill-dir>/scripts/validate_drawio.py <fichier-ou-répertoire>. Réparez les erreurs structurelles rapportées. Utilisez les listes de vérification sémantiques et transversales : le script ne peut pas prouver la correction UML, DFD, ERD ou BPMN. - Ouvrez/importez dans diagrams.net ou exportez à l'aide d'un rendu Draw.io disponible. Inspectez chaque page pour les étiquettes, les extrémités de flèches, le rognage, le containment et les croisements ; ajustez et inspectez à nouveau. Si aucun rendu ne fonctionne, livrez la source modifiable et signalez explicitement le rendu comme non vérifié. N'appelez pas l'analyse XML un test d'ouverture.
- Livrez les fichiers sources, les aperçus utiles et une brève note de vérification/hypothèse. Indiquez exactement quelles vérifications ont été effectuées. Préservez la disposition manuelle existante et les pages non liées lors des modifications ; rafraîchissez les aperçus obsolètes.
Routage de référence
| Question de l'utilisateur | À lire |
|---|---|
| Choix UML / base de notation | uml.md |
| Acteurs et objectifs utilisateur | use-case.md |
| Structure du domaine ou du logiciel | class-diagram.md |
| Un scénario entre collaborateurs | sequence-diagram.md |
| Flux de travail, branches, concurrence | activity-diagram.md |
| Cycle de vie d'une entité basé sur les événements | state-machine.md |
| Instances, liens, modules, placement d'exécution | structural-views.md |
| Communication, synchronisation, aperçu des interactions | advanced-interactions.md |
| Entités, relations, schéma relationnel | erd.md, normalization.md |
| Mouvement des données et décomposition | dfd.md, context-diagram.md |
| Niveaux d'architecture | c4-model.md |
| Collaboration/processus métier | bpmn.md |
| Procédure simple ou transferts de responsabilité | flowchart-swimlane.md |
| Génération / polissage de sortie | drawio-rendering.md, layout.md, fallbacks.md |
| Révision / cohérence multi-vues | diagram-validation.md |
| Provenance des sources / éditions / limites | sources.md |
Convention de sortie
Respectez le chemin de l'utilisateur. Sinon, utilisez docs/diagrams/<système>-<vue>.drawio, avec des aperçus .svg ou .png correspondants lorsque c'est possible. Utilisez <système>-hypothèses.md pour les hypothèses non triviales et <système>-validation.md pour les audits multi-vues. Gardez les exportations temporaires en dehors des livrables finaux. Utilisez des fichiers séparés pour les vues maintenues indépendamment, ou des pages nommées pour un ensemble coordonné. Ne remplacez jamais silencieusement une notation formelle demandée par un organigramme générique.
Vérifications non négociables
- Les faits du modèle doivent provenir de preuves ou d'hypothèses étiquetées.
- Vérifiez la sémantique des extrémités ; une flèche pointant dans le mauvais sens peut rester syntaxiquement valide.
- Une flèche DFD transporte des données ; le flux de contrôle UML/BPMN transporte une signification d'exécution.
- N'inférez pas la propriété du cycle de vie à partir d'une clé étrangère ou d'une phrase vague « a un ».
- Révisez les concepts partagés pertinents ; n'exigez pas des contenus identiques entre des vues de portée différente.
- Gardez les dessins modifiables ; une image intégrée dans un fichier
.drawion'est pas un diagramme natif.
Des exemples et des vérifications exécutables se trouvent dans examples/ et scripts/. Les preuves de test spécifiques au package se trouvent dans TEST-REPORT.md.