 | ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights | ||||||||||||||||||||||||||||||||||||||||||||||
| Wissensbrowser starten | ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||
|  | |  | |  | |
| ||||||
| ||||||
|  | | ||||
| ||||||
Verfahren |
|
UML alleine zur Architekturbeschreibung nicht ausreichend |
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| Beschreibung | |||||||||
| |||||||||
Einige Eigenschaften von Softwarearchitekturen können nicht oder nur umständlich mit semiformalen Notationen wie etwa der UML oder einer ADL formuliert werden. Hierfür eignen sich natürlichsprachlicher Text oder informelle Schaubilder besser. Ziele dieser Darstellungen sind dann nicht etwa die Generierung von Code, sondern die Kommunikation im Entwicklungsteam und das Transportieren grundlegender Ideen und Regeln. Diese müssen von jedem Teammitglied im Detail verstanden und akzeptiert werden, da sonst die Architektur nicht vollständig umgesetzt werden kann. Nachfolgend sind zwei Beispiele für Architektursachverhalte dargestellt, die nur umständlich mit UML formulierbar sind.
Struktur einer Web-Oberfläche Das Groblayout einer Web-Oberfläche ist beispielsweise kaum mit den Mitteln der UML darstellbar. Hierzu fehlen geeignete Ausdrucksmittel. Stattdessen wird die Oberfläche in Form eines Prototypen oder einfacher Schemazeichnungen dargestellt. In der Abbildung wird die Struktur beispielsweise als schematische Zeichnung dargestellt, ein begleitender Text kann die Elemente zusätzlich erläutern. Entwicklungsregeln gehören ebenfalls zu den kaum formal fassbaren Architektureigenschaften. Denkbar sind beispielsweise folgende Regeln: 1. Ausnahmen (z.B. SQLException) werden immer an der Stelle behandelt, an der entschieden werden kann, wie zu reagieren ist. 2. Die Dialogschicht fängt alle auftretenden Ausnahmen auf und erzeugt daraus ein einheitliches Meldungsfenster in der Oberfläche. 3. In der Präsentationsschicht dürfen keine Ausnahmen erzeugt werden Die genannten Regeln beziehen sich auf große Teile des Quelltextes. Sie können in der Regel nicht über gemeinsame Quelltexte umgesetzt werden, etwa eine gemeinsame Basisklasse. Jeder Entwickler muss sie individuell in die Quelltexte übertragen. Solche Regeln werden häufig durch Texte, Quelltextfragmente und informelle Schaubilder dokumentiert. Die beiden Beispiele sollten verdeutlichen, dass bei der Dokumentation von Softwarearchitekturen nicht auf die natürliche Sprache und auf informelle Schaubilder verzichtet werden kann. | |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
Eintrag kommentieren | ||||
| ||||
 | Übergeordnet | | ||
| ||||
|
| | ||
| ||||
| ||||
| ||||
| ||||
| UML alleine zur Architekturbeschreibung... | ||||
| ||||
| ||||
| ||||
| ||||
| Weitere Themen | | ||
| ||||
|
| | ||
|
| | ||
|
| | ||
| ||||
| ||||
| | | ||
| ||||||||||||||
|
