|
|
|
### Access Levels
|
|
|
|
|
|
|
|
- `+`: public
|
|
|
|
- `#`: protected
|
|
|
|
- `-`: private
|
|
|
|
|
|
|
|
### Text Style
|
|
|
|
|
|
|
|
Constants: ALL_CAPS
|
|
|
|
|
|
|
|
Immutable Attributes: <u>underlined</u>
|
|
|
|
|
|
|
|
Virtual Mehtods: *italic*
|
|
|
|
|
|
|
|
### Examples
|
|
|
|
|
|
|
|
`+ myMethodName(param1: bool, param2: string): bool`
|
|
|
|
|
|
|
|
## UML-Erstellung Guideline
|
|
|
|
|
|
|
|
- UML-Diagramme erstellen zu eigenen Methoden/Klassen die geschrieben werden
|
|
|
|
|
|
|
|
- möglichst direkt nach Fertigstellung der Methoden/Klassen
|
|
|
|
|
|
|
|
- im gleichen Issue wie der Code
|
|
|
|
|
|
|
|
- Review der UML-Diagramme am Ende eines Sprints durch den UML-Director
|
|
|
|
|
|
|
|
- Überprüfung auf Aktualität der UML-Diagramme
|
|
|
|
|
|
|
|
- Überprüfung auf Richtigkeit und Style der UML-Diagramme
|
|
|
|
|
|
|
|
- Optional: Erstellung eines Issues für Developer X zum Nachtragen oder Ergänzen der UMl-Diagramme die in sein Aufgabenfeld fallen
|
|
|
|
|
|
|
|
Durch diesen Ablauf wird ermöglicht, dass es eine aktuelle UML-Ansicht des Projekts über den gesamten Entwicklungsverlauf zur Verfügung steht.
|
|
|
|
|
|
|
|
Änderungen die sich als Verbesserungen des Ablaufs festellen sind gerne erwünscht! |
