Auf der Seite Konzept:
Systemarchitektur können Sie sich über Blickpunkte informieren, von denen aus ein System untersucht werden
kann. Von besonderer Relevanz ist hier der physische Blickpunkt. Dieser Blickpunkt rückt die verteilten
Interaktionen zwischen Objekten im System in den Mittelpunkt und beschreibt die Mechanismen für die Unterstützung der
Verteilung [nachzulesen in Architecting with RM-ODP, Janis Putman, Prentice Hall PTR]. Auf der hier
beschriebenen Ebene gehören zu den logischen Objekten auch Subsysteminstanzen. Das Deployment-Modell unterstützt diesen
Blickpunkt, indem es beschreibt, wie das System physisch verteilt ist, und die physische Unterstützung für verteilte
Interaktionen zwischen den vom System unterstützten logischen Objekten erläutert.
Ein Deployment-Modell muss die Dekomposition des Systems in die Elemente beschreiben, in denen die Verarbeitung
stattfindet. Hierfür werden verschiedene Abstraktionsebenen verwendet: Lokalität (die abstrakteste), Deskriptor und
Implementierung (die am wenigsten abstrakte, auf der die eigentliche Hardware- und Softwareauswahl beschrieben wird).
Diese Ebenen entsprechen mehr oder weniger den Ebenen Konzeptionell, Spezifikation und Physisch, die für das
Deployment-Modell (das verwendet wird, wenn die Anwendung von RUP sich auf die Softwareentwicklung beschränkt)
beschrieben werden. Die gebräuchlichste Manifestation eines Deployment-Modells ist die auf den Design- und
Implementierungsebenen mit UML-Deployment-Diagrammen. Im Folgenden finden Sie eine Einführung in das Konzept des
physischen Blickpunkts Lokalität auf Analyseebene.
Das Lokalitätsmodell stellt die erste, abstrakte, physische Partitionierung und Verteilung des Systems
dar und befasst sich mit den physischen Ressourcen des Systems (Knoten, Einheiten, Sensoren und ihren physischen
Verbindungen und Schnittstellen sowie ihren physischen Merkmalen, z. B. Gewicht, Wärmeentwicklung, Stromverbrauch,
Vibration usw.). Eine Lokalität beschreibt theoretisch, wo Verarbeitung stattfindet (die Semantik von Lokalität
impliziert eine engere Gruppierung von Ressourcen), ohne den genauen geografischen Standort zu definieren und ohne
festzulegen, wie die Verarbeitung realisiert werden soll. Für sehr komplexe, sehr große Systeme ist denkbar, dass das
erste Lokalitätsmodell Lokalitäten enthalten kann, die in weitere Lokalitäten zerlegt werden können (so wie ein
Subsystem weitere Subsysteme enthalten kann). Auf der Deskriptorebene werden die Typen der
Verarbeitungsressourcen an einer Lokalität spezifiziert. Dies sind Knoten, zu denen Datenverarbeitungseinheiten
(Server, Workstations usw.), Personen und andere elektromechanische Einheiten gehören können. Auf der
Implementierungsebene wird die eigentliche Hardware ausgewählt und die Anzahl der Rolleninstanzen (bei Personen)
festgelegt. Hierfür wird eine definierte Gruppe von Konfigurationen, Rechenleistung, Stromverbrauch und anderen
Umgebungsanforderungen, Kosten und Leistung bestimmt. Eine Lokalitätssicht kann beispielsweise zeigen, dass das System
die Verarbeitung an Bord eines Weltraumsatelliten und einer Bodenstation unterstützt. Weitere Beispiele finden Sie in
den Abbildungen im Abschnitt "Lokalitätsdiagramme".
Das Deployment-Modell wird auch verwendet, um die Subsystemoperationen aufzuzeichnen, die in jeder Lokalität
stattfinden. Auf diese Weise werden die zu unterstützenden Rechenanforderungen in der Lokalität bestimmt. Basierend auf
dem in den Lokalitäten zu unterstützenden Verhalten können Kollaborationen von Lokalitäten konstruiert (und in
Interaktionsdiagrammen dargestellt) werden. Diese helfen die Verbindungen zwischen den Lokalitäten zu bestimmen.
Die Lokalitätsdiagramme zeigen die erste Partitionierung, wie die Verarbeitungselemente des Systems verteilt sind und
wie diese verbunden sind. Die Lokalität der Datenverarbeitung ist ein Thema, wenn in erster Linie die nicht
funktionalen Anforderungen betrachtet werden. Für viele Systementwickler ist dies "die Architektur".
Lokalitätsdiagramme setzen sich aus zwei Elementen zusammen:
-
Lokalität - Eine Lokalität ist eine Sammlung von Datenverarbeitungs-, Speicher, strukturellen, elektromechanischen
und Personalressourcen, die Verarbeitung unterstützen (im allgemeinen Sinn) und/oder physisch mit der Umgebung und
anderen Lokalitäten interagieren.
-
Verbindungen - Übertragungswege für Informationen, Masse, Energie oder diskrete physische Elemente, die zwischen
Lokalitäten ausgetauscht werden müssen.
Die Semantik der Lokalitätsdiagramme gleicht der von Deployment-Diagrammen. Lokalitäten werden als stereotypierte
UML-Knoten dargestellt. Im UML-Standard ist ein Knoten ein Klassifizierungsmerkmal, das "ein physisches Objekt ist, das
eine Verarbeitungsressource darstellt, die im Allgemeinen mindestens Hauptspeicher und häufig auch
Verarbeitungskapazitäten besitzt. Zu Knoten gehören Datenverarbeitungseinheiten, aber auch Personal und mechanische
Verarbeitungsressourcen". UML lässt die Erweiterung der Semantik von Knoten und der Assoziationen, die Knoten
miteinander verbinden, durch die Verwendung von Stereotypen und die Anwendung von Eigenschaftswerten zu. Diese Mittel
werden verwendet, um Lokalitäten und Verbindungen zu definieren. Das Symbol für eine Lokalität ist ein abgerundeter
Kubus (siehe Abbildungen im Abschnitt "Lokalitätsdiagramme").
Jeder Lokalität im Deployment-Modell muss eine Beschreibung der abgeleiteten ergänzenden Anforderungen (abgeleitet von
den ergänzenden Spezifikationen) zugeordnet werden, die Qualität (Zuverlässigkeit, Wartungsfähigkeit, Sicherheit usw.),
physische und umgebungsbezogene Anforderungen sowie Entwicklungsvorgaben (Kosten, technische Risiken usw.)
spezifizieren. Auf der Basis dieser Anforderungen werden die eigentlichen Merkmale (jeder Lokalität) bestimmt. Diese
werden natürlich so ausgewählt, dass zumindest die expliziten Anforderungen erfüllt werden, sie können aber auch über
die Anforderungen hinausgehen, wenn dies aus der Sicht eines vernünftigen Engineering-Verfahrens erforderlich sein
sollte, z. B. um unerwartete Nutzungsvolumen abzufangen.
Lokalitäten werden wie folgt charakterisiert:
-
mit Qualitätskennzeichen wie Zuverlässigkeit, Verfügbarkeit, Leistung, Kapazität usw.,
-
mit Managementkennzeichen wie Kosten und technischen Risiken.
Verbindungen werden wie folgt charakterisiert:
-
mit Verbindungsparametern wie Übertragungsgeschwindigkeit, unterstützten Protokollen und physischer
Durchflussgeschwindigkeit,
-
mit Managementkennzeichen wie Kosten und technischen Risiken.
Wenn Sie sich durch das Designmodell arbeiten, können Sie Lokalitäten für einen oder mehrere Knoten präzisieren. Einem
Knoten können auch mehrere Lokalitäten zugeordnet werden. Mit der Freiheit, die die UML-Definition bietet, können
Lokalitäten ganz unterschiedliche Dinge darstellen, die schließlich z. B. als Sammlung von Hardwareplattformen, als
Teil einer Datenverarbeitungsressource oder als zusammenarbeitender Mitarbeiter realisiert werden.
Die Abbildungen zeigen Lokalitätsdiagramme, die unterschiedliche Engineering-Ansätze für ein so genanntes
Click-and-Mortar-Unternehmen (Unternehmen, das auf unterschiedliche Absatzkanäle setzt. Click-and-Mortar-Unternehmen
nutzen neben dem Internet auch die klassischen Vertriebswege). Das Unternehmen hat eine Reihe von
Einzelhandelsgeschäften, Zentrallager und einen Webauftritt. Bei der ersten Lösung ist Verarbeitungskapazität in den
Geschäften verfügbar. Bei der zweiten Lösung sind alle Terminals direkt mit einem Zentralrechner verbunden. In beiden
Fällen können Merkmale für die Lokalitäten festgelegt werden, die für die Realisierung des Designs erforderlich sind.
Heutzutage würden die meisten Leute übereinstimmend sagen, dass das erste Beispiel ein besseres Design darstellt. Die
Lösung im zweiten Beispiel kann in einigen Jahren jedoch überlegen sein.
Lokalitätsdiagramm, Beispiel 1.
Lokalitätsdiagramm, Beispiel 2.
|