Konzept: Lokalität
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.
Beziehungen
Hauptbeschreibung

Einführung

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.

Lokalitäten und Verbindungen

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.

Lokalitätsdiagramme

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.

Beispiel 1 des Lokalitätsdiagramms

Lokalitätsdiagramm, Beispiel 1.

Beispiel 2 des Lokalitätsdiagramms

Lokalitätsdiagramm, Beispiel 2.