1) Software-Architektur ist die Aufteilung eines Softwaresystems in Teile mit abgegrenzten Aufgaben.  Ausgangspunkt der Architekturmodellierung ist ein so hoher Abstraktionsgrad, dass das ganze SW-System noch als Ganzes dargestellt werden kann, aber gleichzeitig schon Verteilung von Aufgaben und persistenten Daten sowie Schnittstellen nach außen in der Modellierung sichtbar sind.

2) Die Arbeit eines Software-Architekten ist die Zerlegung der Software in Teile, sodass eine Verringerung oder Aufhebung von Abhängigkeiten zwischen diesen Teilen möglich ist. Eine gute Architektur hat geringe Kopplung zwischen den Teilen und hohe Kohäsion innerhalb ihrer Teile.

3) UML-Paketdiagramme sind aus Klassendiagrammen entstanden und gehören nun zu den Model-Management-Diagrammen der UML. Paketdiagramme bestehen (auf der obersten Ebene) aus Paketen und einer Benutzungstruktur. In den Paketen dürfen beliebige UML-Modellelemente enthalten sein. Paketdiagramme sollen ALLE Abhängigkeiten (Benutzung, Referenzierung, Kommunikation) zwischen Paketen, Modulen und Klassen darstellen. (Häufig passiert es, dass Paketdiagramme erstellt werden, in denen nur die erwünschten ABhängigkeiten eingezeichnet sind, während das wirkliche SW-System viel mehr Abhängigkeiten aufweist. So ein Diagramm hilft dann nicht sehr viel.

4) Jedes Modell-Element gehört zu genau einem ("Heimat-")Paket, in dem es definiert wird, kann aber in beliebig vielen anderen Paketen referenziert werden. Der Name des Modell-Elements muss nur in seinem Heimat-Paket eindeutig sein, da Pakete Namensräume definieren.

5) Ein Paket ist eine schachtelbare Einheit, die Klassen und Module (aber auch andere Pakete sowie jeden anderen UML-classifier) enthalten kann ("Verzeichnis"). Ein Paket wird als großer Ordner (Rechteck mit Lasche oben links) gezeichnet. In der Lasche steht der Name des Pakets. Im Rechteck dürfen die enthaltenen Elemente des Pakets gezeichnet werden. In der ikonisierten Form wird das Paket als kleiner Ordner gezeichnet, wobei im Rechteck der Name des Pakets steht.
                 
Paketsymbol (links: groß, rechts: ikonisiert)

6) Ein Modul ist eine nicht schachtelbare, nicht instanzierbare Einheit ("Datei") und wird als Rechteck mit überlagerten breiten Rechtecken über dem linken Rand gezeichnet (Andeutung der Schnittstelle). Bei Modulen gibt es ebenso die große Form, wie auch die kleine Form:

Modul, Beispiel “VAT” (oben: groß, rechts:ikonisiert)

7) Eine Klasse ist eine instanzierbare Einheit für Quellcode (Daten und Funktionen) und wird als Rechteck gezeichnet.

Klassensymbol (kleine Form)

8) Pakete, Module und Klassen können durch andere UML-Diagramme weiter spezifiziert werden.

9) Schnittstellen sind eine Sonderform von Klassen, bei denen nämlich Attribute sowie die Implementierung von Methoden bewusst ausgelassen werden. In UML werden Schnittstellen als Stereotyp für Klassen eingeführt. Das Symbol ist der sog. Lollipop. Jedes Klassensymbol kann durch Linien mit den Schnittstellen verbunden werden, die die Klasse realisiert.
 


10) Die Referenzierung (Benutzung) wird als Pfeil mit gestrichelter Linie gezeichnet. In Paket- diagrammen ist die Referenzierung azyklisch. In C / C++ wird die Referenzierung auf der Quelltext- Ebene durch "#include" realisiert (Java: uses). Die Referenzierung auf Binärebene wird durch Binden ("Linker") realisiert; in Java erledigt das der Compiler. Echte kreisförmige Abhängigkeiten sind nicht realisierbar (entsprechend sind zyklische "#include"s nicht übersetzbar).

11) Schnittstellen können die Abstraktion unterstützen, indem man anstelle einer eigentlichen Klasse lediglich die tatsächlich benötigte Schnittstelle einsetzt. Zur Laufzeit ersetzt das Programm die Schnittstelle beim Start einfach durch ein spezielleres Objekt ("Polymorphie") oder aber die Schnitt- stelle leitet alle einlaufenden Aufrufe jedesmal weiter an die echte Klasse ("Delegation"). Im Entwurf steht aber in jedem Fall nur die Schnittstelle anstelle der Implementierung. Die Schnittstellen sind selber von keinen oder sehr wenigen anderen Paketen abhängig ! Referenzpfeile von der Schnittstelle laufen nur in Richtung der Datentyp-Definitionen für die in der Schnittstelle verwendeten Parameter.

Implementierung von “interface” durch “class”

12) Anhand der Aufgabenverteilung durch die swimlanes in Aktivitätsdiagrammen lässt sich eine erste Architektur festlegen, die dann erweitert und verfeinert wird. Dabei sollten folgende Architekturprinzipien berücksichtigt
werden:

13) "much Cohesion" (Kohäsion, Zusammenhalt) Pakete mit vielen Abhängigkeiten untereinander gehören in das gleiche übergeordnete Paket. Gruppen von Paketen, die untereinander nur wenige Abhängigkeiten besitzen, sollten nicht in das gleiche übergeordnete Paket eingruppiert werden,da sie vermutlich nicht logisch zusammengehören.

14) "few Coupling" Zwischen Paketen (der oberen Ebene) sollten nur wenige Abhängigkeiten bestehen. Pakete, zwischen denen viele Abhängigkeiten bestehen, sollten eher ein Paket bilden.

15) "stable abstractions principle" Einen Sonderfall des "few coupling" bilden "dünne", kommunale Pakete, in denen Definitionen, jedoch keine Implementierungen aufgeführt sind. Somit ist die allgemeine Definitionsdatei "common.h" erlaubt, obwohl sie u.U. recht viele Definitionen und recht viele einlaufende Referenzpfeile besitzt. Solch ein kommunales Paket darf aber lediglich Schnittstellen und Symboldefinitionen enthalten, jedoch keinen Code. Solch ein Paket passt zum Prinzip "few coupling", weil zwar viele Pakete auf common.h verweisen, jedoch jede dieser Abhängigkeiten sich nur auf Symbole und nicht auf Code bezieht und somit eine "dünne" Abhängigkeit ist. Praktischerweise befinden sich in solchen Paketen mit vielen einlaufenden Abhängigkeiten nur sehr stabile Definitionen, da jede Änderung einen hohen Freigabe- und Übersetzungsaufwand mit sich bringen würde. Jede sich häufig ändernde Definition würde in praktischen Projekten bald ausgekoppelt und in einem zusätzlichen Paket mit weniger einlaufenden Referenzen gespeichert.

16) "only Acyclic Dependencies" Abhängigkeiten zwischen Paketen dürfen keine Zyklen bilden. Zum einen ist ein Zyklus ein starker Hinweis auf eine logische Zusammengehörigkeit eines Systems von Klassen. Zum anderen sind  Zyklen organisatorisch (Freigabe neuer Versionen, Übersetzung) umständlich zu handhaben.

17) "Release Reuse Equivalency Principle" (RRP) Die Umfänge freizugebender Versionen müssen sich nach der Wiederverwendbarkeit von Paketen richten. "The granule of reuse is the granule of release." Klassen, die miteinander wiederverwendet werden, sollten also im gleichen Paket sein, damit sie auch gemeinsam freigegeben werden. Ansonsten würden bei der Wiederverwendung Versionskonflikte entstehen, die nur durch die gleichzeitige Freigabe mehrerer Pakete behebbar sind. Die Benutzer von Klassen, die wiederum von anderen Klassen abhängen, wollen sich auf eine gemeinsame Freigabe neuer Versionen verlassen.

17) "Common Closure Principle" (CCP) Pakete, die sich gemeinsam ändern, gehören zusammen. "Classes that change together, belong together." Klassen, die sich gemeinsam ändern, sollten im gleichen Paket sein. Begründung wie bei RRP.

18) "Common Reuse Principle" (CRP) Pakete sollen nur Software enthalten, die gemeinsam (wieder)verwendet wird. "Classes that aren’t reused together should not be grouped together." Andernfalls würde eine neue Version dieses Pakets auch neue Versionen für darin enthaltene, jedoch unveränderte Klassen mit sich bringen. Benutzer dieser unveränderte, jedoch neu ausgelieferten Klassen müssten neu übersetzen, ohne dass sich irgendetwas geändert hätte - das Paket wäre zu groß und damit auch der Generieraufwand nach Freigaben.

19) RRP, CRP und CCP widersprechen einander und es gibt keine eindeutige Lösung, die alle Prinzipien voll erfüllt. Ebenso sind die Ziele, einerseits möglichst wenige Pakete, jedoch andererseits möglichst kleine Pakete zu finden, zueinander widersprüchlich. Eine passende Architektur kann ebenso mittels "Durchspielen" von Aktivitäts- und Sequenzdiagrammen gefunden werden, die diese Diagramme den Kommunikationsaspekt dynamisch darstellen.

20) Strukturelle Muster bewährter Architekturen sind als Architekturmuster in der Literatur zu finden. Das bekannteste Architekturmuster ist "multi-tier" mit den Ebenen Präsentation ("oben"), Anwendung ("Mitte") ....,  Datenbank ("unten"). Die obere Schicht darf dabei von der unteren abhängen, jedoch nicht umgekehrt. Die 3-tier-Architektur kennt die Pakete "Datenbank" (auch für Hardware-Interfaces, Ressourcen, Standard-Schnittstellen, legacies), "Anwendung", (die eigentlichen Berechungen) sowie "Präsentation" (auch "Bedienoberfläche",  User Interface =UI, Graphical User Interface = GUI).

21) Nach dem “stable abstractions principle”, ändert sich in der 3-tier-Architecture die “Datenbank”- Ebene bzw. die Schnittstelle dahin nicht, die Schnittstelle in die “Anwendungsebene” hingegen leichter. Änderungen an der Präsentation sind ohne Auswirkungen auf die restliche SW möglich.


22) Der Ansatz, die Architektur aus dem (UML-)Modell abzuleiten, heisst Model-Driven Architecture (MDA). Eine typische Vorgehensweise dabei ist, aus den Use-Case-Diagrammen und UC-Detailed- Descriptions zunächst Aktivitätsdiagramme abzuleiten und darin mit "swimlanes" eine erste Aufteilung vorzunehmen. Weitere UML-Diagramme konkretisieren dann diese Einteilung, wobei eine iterative Bearbeitung der verschiedenen Diagramme naheliegend und erwünscht ist. Hinweis: Die Firma Interactive Objects (iO), Freiburg, ist der erste Partner der OMG in Europa, der das Gütesiegel "Qualified Service Provider" für seine Beratungsleistungen rund um MDA erhalten hat. iO berät große Firmen, gibt Schulungen und publiziert Schriften zu MDA.