Nachdem wir uns im ersten Teil unserer Blog-Reihe mit der Anforderungsanalyse und deren modellbasierten Dokumentation beschäftigt haben, widmen wir uns im zweiten Teil der Designphase. Diese hat folgende Ziel

• Identifikation  der Hardware- und Software-Komponenten
• Zuordnung der Software- zu den Hardware-Komponenten sowie
• Beschreibung der Schnittstellen zwischen den Software- und Hardware-Komponenten.

Der Fragestellung, welche Funktionalität aus der Analyse in welcher SW- oder HW-Komponente realisiert werden soll, widmen wir uns im dritten Teil unserer kleinen Blogserie.

Um die oben genannten Ziele übersichtlich und verständlich in UML abbilden zu können, empfehlen wir Ihnen, die System-Architektur aus verschiedenen Blickwinkeln zu betrachten. Durch die Einnahme einer bestimmten Sicht können Sie sich bei der Modellierung auf einen Aspekt konzentrieren und andere, für den Fokus weniger wichtige Aspekte, außen vor lassen. Die Kombination aller Sichten ergibt die System-Architektur als Ganzes.

In diesem Blog stellen wir Ihnen drei Sichten vor:

• Logische Sicht: Modellierung der Software-Komponenten, deren Schnittstellen und Zuordnung zu den Hardware-Komponenten (Kapitel 4)
• Physikalische Sicht: Modellierung der Hardware-Komponenten, deren Schnittstellen und Verbindungen (Kapitel 5)
• Funktionale Sicht: Modellierung der Funktionalitäten unabhängig von der verwendeten Hardware (Kapitel 6)

Dabei ist darauf zu achten, dass diese drei Sichten nicht in der angegebenen Reihenfolge entstehen müssen. Modellieren Sie den Aspekt zu genau der Zeit, an der es Ihnen den größtmöglichen Nutzen bringt.

Für die Modellierung der System-Architektur nehmen wir einen weiteren Use Case Leihobjekt suchen für unser Bibliothekssystem hinzu, so dass wir etwas mehr Funktionalität in der System-Architektur modellieren können.

4. Logische Sicht

In der logischen Sicht liegt unser Hauptfokus auf den Software-Komponenten des Systems, ihren Schnittstellen untereinander und ihren Verbindungen zu den Hardware-Komponenten.

Zur Darstellung nutzen wir ein Struktur-Diagramm der UML, das Komponenten-Diagramm. Für die Software-Komponenten verwenden wir UML-Komponenten mit dem Stereotyp software. Die Hardware-Komponenten werden ebenfalls durch UML-Komponenten modelliert, allerdings verwenden wir hier den Stereotyp hardware oder einen mehr differenzierten Stereotyp, z.B. server für die Komponenten Datenbank und Datenverarbeitung (hier dargestellt durch einen grauen Zylinder auf der rechten Seite der UML-Komponente). Wie die Verbindung zwischen den Analyse-Elementen und den Software-Komponenten hergestellt wird, beschreiben wir im dritten Teil unserer Blog-Reihe.

Jede Software-Komponente muss auf einer Hardware ausgeführt werden, was wir mit einer executedOn-Beziehung zwischen Software-Komponente und der entsprechenden Hardware-Komponente modellieren. Beispielsweise wird die Software-Komponente Kundenauthentifizierung auf dem KundenClient ausgeführt. Diese Komponente wird hier stellvertretend für alle in der physikalischen Sicht modellierten KundenClient-Instanzen (siehe Kapitel 5) verwendet. Damit ist implizit ausgedrückt, dass auf jeder KundenClient-Instanz eine Instanz der Software-Komponente Kundenauthentifizierung ausgeführt wird.

Die Schnittstellen modellieren Sie über Provided- und RequiredInterfaces und verbinden sie mit einer gerichteten dependency-Verbindung vom Required- zum ProvidedInterface. An den Ports können Sie Verbindungsdetails, beispielsweise eine IP-Adresse oder das Kommunikations-Protokoll, modellieren. Da über einen Port verschiedene Datenstrukturen, beschrieben durch Interfaces, übertragen werden können, ist es möglich einem UML-Port mehrere Provided- und/oder RequiredInterfaces zuzuordnen. Mit Hilfe von gerichteten delegate-Beziehungen lassen sich die Schnittstellen des Bibliothekssystems an die hierarchisch unterhalb des Bibliothekssystems liegenden Software-Komponenten delegieren, die diese, wie in unserem Beispiel, implementieren oder weiter delegieren.

Für die Benennung der Schnittstellen verwenden wir das Muster <Abkürzung der Quelle>.<Datenname>, damit direkt ersichtlich ist wer diese Schnittstelle anbietet und um welche Daten es sich handelt. Sie können dieses Muster natürlich Ihren Bedürfnissen anpassen.

Durch die Übertragung der Software-Komponenten-Schnittstellen auf die physikalischen Schnittstellen der entsprechenden Hardware-Komponenten, können Sie festlegen über welche physikalische Schnittstelle die Datenkommunikation verläuft. Auf diese Weise wird deutlich, dass die Software-Komponente Kundenauthentifizierung den von der Bibliotheksdatenverarbeitung (BDV) angebotenen Such-Service, BDV.Leihobjektsuche, über Ethernet ansprechen muss.

5. Physikalische Sicht

In der physikalischen Sicht liegen der Fokus auf der Hardware und deren physikalischen Schnittstellen untereinander. In Abhängigkeit vom betrachteten System ist eine mehr oder weniger detaillierte Modellierung der Hardware-Komponenten notwendig. Im Bereich von eingebetteten Systemen beispielsweise möchten die Entwickler genau wissen, über welche physikalische Schnittstelle oder Leitung ihre Daten transportiert oder auf welchem Board und den darauf befindlichen Prozessortypen bzw. -kernen die Software-Komponenten ausgeführt werden. Für solche Systeme ist eine detaillierte Modellierung der Hardware-Architektur Voraussetzung für die Entwicklung der System-Architektur.Entwickeln Sie allerdings eine Web-Anwendung, die auf mehreren PCs ausgeführt wird, ist vor allem die Vernetzung der PCs und weniger die detaillierte Hardware-Architektur eines jeden PCs von Bedeutung.

Wir möchten die tatsächlich aufzustellende Hardware zeigen, weshalb wir Instanzen der in der logischen Sicht erstellten Hardware-Komponenten verwenden. Mit Hilfe von Ports modellieren wir physikalische Schnittstellen. Über einen Stereotyp lässt sich der Steckertyp angeben, beispielsweise RJ-45, und über den Port-Name die Bezeichnung der physikalischen Schnittstelle, z.B. LAN. Die Verbindung zweier Ports durch eine physikalische Leitung modellieren Sie mit Hilfe eines Connectors, der mit Hilfe eines Stereotyps, z.B. 1GBit/s Ethernet, näher spezifizieren werden kann. Den Connector-Name können Sie, wie schon beim Port, für die Bezeichnung der physikalischen Leitung verwenden. Diese Semantik von Port-/Connector-Namen und Port/Connector-Stereotyp ist nur ein Beispiel und wird nicht durch die UML vorgegeben. Es steht Ihnen frei, die Semantik Ihren Bedürfnissen anzupassen.

6. Die funktionale Sicht

In der funktionalen Sicht stellen wir nur die Zusammenarbeit unserer SW-Komponenten bzgl. der Funktionalitäten unseres Systems dar. Bei der Einnahme dieser Sicht auf die System-Architektur müssen Sie sich keine Gedanken über die verwendete Hardware machen. Stellen Sie sich vor, Sie haben optimale Bedingungen und müssen weder auf die Verarbeitungsleistung eines Prozessors, auf die Bandbreite eines Kommunikationsmediums oder auf eine abteilungsbezogene Aufteilung der Funktionalitäten Rücksicht nehmen. Unserer Erfahrung nach ist diese Sichtweise gerade bei gewachsenen Systemen zur Refaktorisierung der Funktionalitäten unabhängig von der verwendeten Hardware-Architektur oder bei der Neuentwicklung von Systemen zur Identifizierung der benötigten SW-Komponenten hilfreich.

Zur Modellierung der Funktionalitäten verwenden wir UML-Komponenten mit dem Stereotyp functional. Eine Funktionalität entspricht einer in der Analyse definierten Aufgabe unseres Systems, also einem Use Case oder einem Teil eines solchen.

Dargestellt werden die UML-Elemente in einem Strukturdiagramm der UML, dem Komponenten-Diagramm. Ein Diagramm der funktionalen Sicht für das Bibliothekssystem für den Use Case „Leihobjekt suchen“ ist in Abbildung 4 zu sehen. Das Bibliothekssystem verwendet zur Realisierung die angegebenen SW-Komponenten.

Im letzten Teil unserer Blog-Serie zeigen wir Ihnen, wie Sie die Nachverfolgbarkeit der UML-Elemente aus der Analyse in die Design-Phase und innerhalb dieser modellieren können, so dass Sie überprüfen können, ob beispielsweise jedes Analyse-Element auch wirklich im Design berücksichtigt wurde und von welcher Software-Komponente es realisiert wird.