Systementwurf
Erstellen Sie die kleinste Menge an Ansichten, die die Frage des Benutzers beantworten. Bevorzugen Sie bearbeitbare .drawio-Dateien für formale Diagramme; achten Sie auf die angeforderte Notation, das Format, die Kursrichtlinien und vorhandene Dateien. Eine gültige XML-Datei ist kein Nachweis für ein korrektes Modell.
Arbeitsablauf
- Legen Sie Zielgruppe, Systemgrenze, Frage, Szenario und Abstraktionsebene fest. Lesen Sie die bereitgestellten Anforderungen/Schemata/Code und etwaige Rubriken. Notieren Sie unsichere Kardinalitäten, Berechtigungen, Lebenszyklusregeln und externe Schnittstellen als Annahmen; fragen Sie nur nach, wenn sie die Antwort wesentlich verändern. Erfinden Sie keine Infrastruktur oder zwingende Beziehungen.
- Wählen Sie Ansichten anhand der untenstehenden Routingtabelle. Lesen Sie nur die relevanten Referenzen plus
diagram-validation.md. Unterscheiden Sie Belege für den Ist-Zustand vom vorgeschlagenen Entwurf. Führen Sie ein kleines Glossar mit stabilen Konzept-IDs, wenn mehrere Diagramme Konzepte gemeinsam nutzen. - Erstellen Sie ein semantisches Inventar, bevor Sie Formen platzieren: Teilnehmer/Elemente, Beziehungen mit Richtung und Endpunkt-Bedeutung, Einschränkungen und Anforderungs-IDs. Für ein DFD fügen Sie ein Flusswörterbuch und Dekompositionsgrenzensignaturen hinzu; für ein Datenmodell identifizieren Sie Schlüssel und Abhängigkeiten.
- Befolgen Sie das diagrammspezifische Zeichenverfahren. Legen Sie die Notation explizit fest (z. B. UML 2, Crow's Foot, Gane–Sarson; Kontext dann Ebene-0). Trennen Sie semantische Regeln von empfohlenen Layout-Entscheidungen. Lösen Sie widersprüchliche Quellen wie in
sources.mdbeschrieben auf. - Für Draw.io lesen Sie
drawio-rendering.mdundlayout.md. Erstellen Sie native Formen und Verbinder mit stabilen IDs unter Verwendung eines XML-Serialisierers. Kopieren Sie ein relevantes Beispiel erst, nachdem Sie dessen Domänenfakten ersetzt haben. Für andere Formate lesen Siefallbacks.md. - Führen Sie aus:
python3 <skill-verzeichnis>/scripts/validate_drawio.py <datei-oder-verzeichnis>. Beheben Sie gemeldete strukturelle Fehler. Verwenden Sie die semantischen und ansichtsübergreifenden Checklisten: Das Skript kann keine UML-, DFD-, ERD- oder BPMN-Korrektheit beweisen. - Öffnen/Importieren Sie in diagrams.net oder exportieren Sie mit einem verfügbaren Draw.io-Renderer. Überprüfen Sie jede Seite auf Beschriftungen, Pfeilenden, Beschneidungen, Enthaltungen und Kreuzungen; passen Sie an und überprüfen Sie erneut. Wenn kein Renderer funktioniert, liefern Sie die bearbeitbare Quelle und melden Sie die Darstellung explizit als unverifiziert. Bezeichnen Sie XML-Parsing nicht als Test der Öffnungsfähigkeit.
- Liefern Sie Quelldateien, nützliche Vorschauen und eine kurze Verifizierungs-/Annahmenotiz. Geben Sie genau an, welche Prüfungen durchgeführt wurden. Bewahren Sie vorhandenes manuelles Layout und nicht zusammenhängende Seiten bei Bearbeitungen; aktualisieren Sie veraltete Vorschauen.
Referenz-Routing
| Frage des Benutzers | Lesen Sie |
|---|---|
| UML-Auswahl / Notationsgrundlage | uml.md |
| Akteure und Benutzerziele | use-case.md |
| Domänen- oder Softwarestruktur | class-diagram.md |
| Ein Szenario über mehrere Kollaborateure | sequence-diagram.md |
| Workflow, Verzweigungen, Nebenläufigkeit | activity-diagram.md |
| Ereignisgesteuerter Lebenszyklus einer Entität | state-machine.md |
| Instanzen, Links, Module, Laufzeitplatzierung | structural-views.md |
| Kommunikation, Timing, Interaktionsübersicht | advanced-interactions.md |
| Entitäten, Beziehungen, relationales Schema | erd.md, normalization.md |
| Datenbewegung und Dekomposition | dfd.md, context-diagram.md |
| Architekturebenen | c4-model.md |
| Geschäftliche Zusammenarbeit/Prozess | bpmn.md |
| Einfaches Verfahren oder Verantwortungsübergaben | flowchart-swimlane.md |
| Ausgabeerzeugung / Verfeinerung | drawio-rendering.md, layout.md, fallbacks.md |
| Überprüfung / ansichtsübergreifende Konsistenz | diagram-validation.md |
| Quellenherkunft / Editionen / Einschränkungen | sources.md |
Ausgabekonvention
Beachten Sie den Benutzerpfad. Andernfalls verwenden Sie docs/diagrams/<system>-<view>.drawio, mit passenden .svg- oder .png-Vorschauen, wenn möglich. Verwenden Sie <system>-assumptions.md für nichttriviale Annahmen und <system>-validation.md für ansichtsübergreifende Audits. Behalten Sie temporäre Exporte außerhalb der endgültigen Ergebnisse. Verwenden Sie separate Dateien für unabhängig gepflegte Ansichten oder benannte Seiten für einen koordinierten Satz. Ersetzen Sie niemals stillschweigend eine angeforderte formale Notation durch ein generisches Flussdiagramm.
Unverhandelbare Prüfungen
- Modellfakten müssen aus Belegen oder gekennzeichneten Annahmen stammen.
- Überprüfen Sie die Endpunktsemantik; ein Pfeil, der in die falsche Richtung zeigt, kann syntaktisch gültig bleiben.
- Ein DFD-Pfeil transportiert Daten; UML-/BPMN-Kontrollfluss transportiert Ausführungsbedeutung.
- Leiten Sie keinen Lebenszyklusbesitz aus einem Fremdschlüssel oder einem vagen „hat ein“-Ausdruck ab.
- Überprüfen Sie relevante gemeinsame Konzepte; erzwingen Sie keine identischen Inhalte in Ansichten mit unterschiedlichem Umfang.
- Halten Sie Zeichnungen bearbeitbar; ein in eine
.drawio-Datei eingebettetes Bild ist kein natives Diagramm.
Beispiele und ausführbare Prüfungen befinden sich in examples/ und scripts/. Paketspezifische Testnachweise finden Sie in TEST-REPORT.md.