Die Unterteilung in Schichten bietet folgende Vorteile:
-
Schichten helfen, ein IT-System mit Qualitätsattributen für Modifizierbarkeit und Portierbarkeit zu versehen. Eine
Änderung an einer unteren Schicht, die keine Auswirkung auf die Schnittstelle hat, erfordert keine Änderung an
einer darüber liegenden Schicht. So kann zum Beispiel jeder mit dem Standard J2EE™ konforme Anwendungsserver frei
und ohne Änderung an der Software auf Anwendungsebene ersetzt werden. Eine Änderung an einer höheren Schicht hat
keinen Einfluss auf die unteren Schichten, sofern sie sich nicht auf die Anforderungen an untere Schichten
auswirkt. Änderungen an einem mehrschichtigen Softwaresystem, die keine Schnittstellen betreffen, sind generell auf
nur eine Schicht begrenzt.
-
Schichten sind Teil der Planungsrolle, die die Architektur bei der Konstruktion des Systems spielt. Wenn Entwickler
wissen, in welchen Schichten sich ihre Software befindet, kennen Sie die Services, auf die Sie in der
Codierungsumgebung setzen können. Schichten können Arbeitszuordnungen für Entwicklerteams definieren. (Dies ist
jedoch nicht immer der Fall.)
-
Schichten sind Teil der Kommunikationsrolle, die die Architektur inne hat. Bei einem großen System nimmt die Zahl
der Abhängigkeiten unter den Modulen rasch zu. Die Organisation der Software in Schichten mit Schnittstellen ist
ein wichtiges Tool bei der Verwaltung der Komplexität und beim Informationsaustausch mit den Entwicklern über die
Struktur.
-
Schichten unterstützen die Analyserolle der Architektur. Sie können genutzt werden, um die Auswirkungen von
Änderungen am Design zu analysieren.
Die Unterteilung in Schichten kann strikt oder nicht strikt sein. Ein striktes Schichtungsschema bedeutet, dass
Komponenten nur Komponenten derselben Schicht oder aus den direkt darunter liegenden Schichten verwenden können. Bei
einem nicht strikten Schichtungsschema können Komponenten derselben Schicht oder aus allen darunter liegenden
Schichten verwenden. Beachten Sie jedoch, dass Komponenten generell keine Komponenten aus höheren Schichten verwenden
sollten. Wenn Komponenten von Komponenten höherer Schichten abhängig sind, wird es schwierig, die Komponenten der
höheren Schichten zu ersetzen, ohne die Komponenten der darunter liegenden Schicht ändern zu müssen. Weitere
Informationen hierzu sowie zum Modellierungsverfahren für Schichten finden Sie im Konzept Lösungspartitionierung.
Es ist wichtig, dass Sie die hier beschriebenen Softwareschichten nicht mit denen des Dreischichtenmodells
(3-Tier-Architekturmodell mit Front-End, Anwendungsschicht und Back-End) verwechseln. Die Zuordnung zu Maschinen in
einer Verteilten Umgebung, der Datenfluss zwischen Elementen und das Vorhandensein bzw. die Nutzung von
Kommunikationskanälen werden tendenziell Schichtdiagrammen nach dem Dreischichtenmodell dargestellt, die manchmal kaum
von Diagrammen der Softwareschichten zu unterschieden sind. Schichtdiagramme nach dem Dreischichtenmodell enthalten
häufig bidirektionale Pfeile, um eine Art der bidirektionalen Kommunikation anzuzeigen. In einem Diagramm der
Softwareschichten ist bidirektionale (symmetrische Kommunikation) eher negativ. Darüber hinaus basiert die Zuordnung
einer Komponente zu einer Schicht des Dreischichtenmodells auf den Platzierungsregeln, die beim Definieren der
Operationsarchitektur berücksichtigt werden, und sie wird von den erforderlichen Systemmerkmalen auf Serviceebene
bestimmt. Der Hauptunterschied zwischen Diagrammen der Softwareschichten und Abbildungen nach dem Dreischichtenmodell
besteht darin, dass es in ersteren keinen konkrete Platzierung gibt, wohingegen in letzteren klar definierte Positionen
vorhanden sind.
Faustregeln für die Unterteilung in Schichten
-
Alle Komponenten, die anwendungsunabhängige Geschäftsfunktionen bereitstellen, könnten einer Schicht zugeordnet
werden. Anwendungsunabhängige Geschäftsfunktionen sind z. B. das "Kundenmanagement" und das "Produktmanagement" für
einen Bereich verschiedener Anwendungen.
-
Alle Komponenten, die technische Funktionen wie Fehlerbehandlung, Authentifizierung, Protokollierung und Prüfung
bereitstellen, könnten einer anderen (logischen) Schicht zugeordnet werden. Diese Komponenten sind geschäfts- und
anwendungsunabhängig. In manchen Fällen kann die räumliche Nähe technischer und funktionaler Komponenten eine
Zuordnung beider zu einer gemeinsamen Schicht erforderlich machen. Dies sind Entscheidungen hinsichtlich der
Architektur und müssen als solche dokumentiert werden.
-
Middlewarekomponenten wie das Message-Queuing und relationale DBMS-Software können einer weiteren Schicht
zugeordnet werden. Dies wird auch als die "Struktur" oder das "Gefüge" (Fabric) bezeichnet.
Beispiel
Die folgende Abbildung zeigt eine SOA-Sicht mit typischen (und tatsächlich empfohlenen) Schichten für die verschiedenen
Elemente einer Lösung.
In diesem Schichtungsschema lässt sich recht einfach herausfinden, welcher Schicht unsere Komponenten zuzuordnen sind.
Wir werden die relevanten Komponenten unseres Beispiels "Rent-a-Car" in die Servicekomponentenschicht stellen. Schauen
Sie sich dazu die folgende Abbildung an. Da wir ein Modell mit strikter Schichtung wünschen, werden wir die
UML-Komposition nutzen, um unsere Komponenten in die Servicekomponentenschicht aufzunehmen, und die Funktionalität der
Servicekomponenten nur über Stellvertreter-Ports verfügbar machen, die dieselbe Schnittstelle wie die Servicekomponente
selbst bereitstellen.
|