 | ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights | ||||||||||||||||||||||||||||||||||||||||||||||
| Wissensbrowser starten | ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||
|  | |  | |  | |
| ||||||
| ||||||
|  | | ||||
| ||||||
Verfahren |
|
Architekturbeschreibung mit UML 1.x |
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| Beschreibung | |||||||||
| |||||||||
| UML ist die de facto Standardsprache für Software-Design. Die Stärken von UML liegen in objekt-orientierter Analyse und -Design. UML kann phasenübergreifend in Analyse, Spezifikation und Entwurf verwendet werden.
Die Meinungen über die Verwendbarkeit von UML zum Architekturentwurf differieren. Drei publizierte Meinungen sind:
Die Elemente einer Architekturbeschreibung mit UML sind vorwiegend Klassen und Objekte. Schnittstellen werden über Interfaces dargestellt. Spezifische Modellelemente zur Beschreibung von Architekturen sind vorhanden, aber nicht vollständig oder mehrdeutig. Komponenten und Verbinder, im Sinne der Architecture Description Languages, fehlen. Explizit modellierbare Abhängigkeiten von Komponenten sind noch nicht in der UML enthalten. Zur Beschreibung des Verhaltens gibt es Kollaborationsdiagramme, Sequenzdiagramme, Zustandsdiagramme und Aktivitätsdiagramme. Über die OCL können für Klassen und Interfaces Konsistenzbedingungen (Invarianten, Vor- und Nachbedingungen) festgelegt werden. UML bietet große Flexibilität in der Verwendung der Notation. Ein Verlust an Präzision hat allerdings geringere Analysierbarkeit bzw. Simulierbarkeit der Modelle zur Folge. Missverständnisse über die Bedeutung einzelner Diagramme sind Ursache für Fehler. Erweiterung von UML über Profile Ein Profil erweitert die UML um Modellelemente, ohne das UML-Metamodell zu verändern. Für technische Architekturen wie Enterprise JavaBeans befinden sich derzeit Profile in der Diskussion. Ein Profil für Framework-Architekturen wurde im ViSEK-Projekt entwickelt und beschrieben. Die Elemente der Architecture Description Languages wie Komponenten, Verbinder und Konfigurationen werden als Stereotype in einem Profil dargestellt. Das Profil definiert zusätzliche Entwurfsregeln über OCL-Constraints. UML-Modellierungswerkzeuge unterstützen Profile. Zusätzliche Werkzeuge sind nicht erforderlich und Methodenbrüche durch Wechsel der Notation gibt es nicht. Die Stereotype des Profils stellen die Architektur explizit dar. Die Analysemöglichkeiten, die einen der Mehrwerte der ADLs ausmachen, sind wegen der nach wie vor recht informellen Darstellung begrenzt. Erweiterung der UML um ADL-Konzepte Eine Alternative zu den Profilen ist die tiefer gehende Erweiterung der UML um Diagrammarten und zusätzliche Modellierungselemente. Hier wird der Sprachkern der UML (das Metamodell) geändert. Dieser Ansatz hat den gravierenden Nachteil, dass für derartige Erweiterungen alle Werkzeuge modifiziert werden müssen. Hier fehlt sowohl eine entsprechende Mächtigkeit der UML-Modellierungswerkzeuge als auch der ADL-Entwicklungs- und Analysewerkzeuge. | |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
Eintrag kommentieren | ||||
| ||||
 | Übergeordnet | | ||
| ||||
|
| | ||
|
| | ||
| ||||
| ||||
| ||||
| ||||
| Architekturbeschreibung... | ||||
| ||||
| ||||
| ||||
| ||||
| Ansprechpartner | | ||
| ||||
|
| | ||
| ||||
| ||||
| ||||
| Weitere Themen | | ||
| ||||
|
| | ||
|
| | ||
|
| | ||
|
| | ||
| ||||
| ||||
| | | ||
| ||||||||||||||
|
