View model

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.^[1][2]

Since the early 1990s there have been a number of efforts to prescribe approaches for describing and analyzing system architectures. A result of these efforts have been to define a set of views (or viewpoints). They are sometimes referred to as architecture frameworks or enterprise architecture frameworks, but are usually called "view models".

Usually a view is a work product that presents specific architecture data for a given system. However, the same term is sometimes used to refer to a view definition, including the particular viewpoint and the corresponding guidance that defines each concrete view. The term view model is related to view definitions.

The purpose of views and viewpoints is to enable humans to comprehend very complex systems, to organize the elements of the problem and the solution around domains of expertise and to separate concerns. In the engineering of physically intensive systems, viewpoints often correspond to capabilities and responsibilities within the engineering organization.^[3]

Die Spezifikationen komplexer Systeme sind meist so umfangreich, dass niemand sie vollständig erfassen kann. Zudem haben wir alle unterschiedliche Interessen an einem System und unterschiedliche Gründe, die Spezifikationen zu untersuchen . Ein Manager wird andere Fragen zur Systemstruktur stellen als ein Systementwickler. Das Konzept des Viewpoint-Frameworks bietet daher verschiedene Sichtweisen auf die Spezifikation eines komplexen Systems, um die Kommunikation mit den Stakeholdern zu erleichtern. Jede Sichtweise spricht eine Zielgruppe an, die sich für bestimmte Aspekte des Systems interessiert. Jede Sichtweise kann eine spezifische Sprache verwenden , die Vokabular und Präsentation für die jeweilige Zielgruppe optimiert. Die Viewpoint-Modellierung hat sich als effektiver Ansatz für den Umgang mit der inhärenten Komplexität großer verteilter Systeme erwiesen.

Die in IEEE Std 1471-2000 beschriebenen Architekturbeschreibungsmethoden nutzen mehrere Sichten, um verschiedene Problembereiche abzudecken, wobei sich jede Sicht auf einen spezifischen Aspekt des Systems konzentriert. Beispiele für Architekturframeworks, die mehrere Sichten verwenden, sind Kruchtens „4+1“-Sichtmodell , das Zachman-Framework , TOGAF , DoDAF und RM-ODP .

In den 1970er Jahren entstanden in der Softwareentwicklung Methoden zur Modellierung mit mehreren Sichten. Douglas T. Ross und K. E. Schoman führten 1977 die Konstrukte Kontext, Standpunkt und Perspektive ein, um den Modellierungsprozess bei der Definition von Systemanforderungen zu strukturieren. ^{[ 4 ]} Laut Ross und Schoman verdeutlicht ein Standpunkt, „welche Aspekte für die Erreichung des Gesamtzwecks [des Modells] als relevant erachtet werden“ und legt fest: Wie betrachten wir [ein zu modellierendes Objekt]?

Als Beispiele für Sichtweisen werden in diesem Beitrag technische, operative und wirtschaftliche Sichtweisen angeführt. 1992 veröffentlichten Anthony Finkelstein und andere eine bedeutende Arbeit zu Sichtweisen. ^{[ 5 ]} Darin heißt es: „Eine Sichtweise kann als Kombination der Idee eines ‚Akteurs‘, einer ‚Wissensquelle‘, einer ‚Rolle‘ oder eines ‚Agenten‘ im Entwicklungsprozess und der Idee einer ‚Sicht‘ oder ‚Perspektive‘ verstanden werden, die ein Akteur vertritt.“ Ein wichtiger Gedanke dieser Arbeit war die Unterscheidung zwischen „einem Darstellungsstil , dem Schema und der Notation, mit der die Sichtweise ausdrückt, was sie wahrnimmt“, und „einer Spezifikation , den im Stil der Sichtweise formulierten Aussagen, die bestimmte Bereiche beschreiben“. Nachfolgende Arbeiten, wie beispielsweise IEEE 1471 , haben diese Unterscheidung beibehalten, indem sie die Begriffe „Sichtweise“ und „Sicht“ separat verwenden.

Seit Anfang der 1990er-Jahre gab es zahlreiche Bestrebungen, Ansätze zur Beschreibung und Analyse von Systemarchitekturen zu kodifizieren. Diese werden oft als Architekturframeworks oder auch als Viewpoint-Sets bezeichnet . Viele dieser Frameworks wurden vom US-Verteidigungsministerium finanziert , einige entstanden jedoch auch aus internationalen oder nationalen Initiativen der ISO oder des IEEE . Die IEEE Recommended Practice for Architectural Description of Software-Intensive Systems ( IEEE Std 1471-2000 ) legte nützliche Definitionen von Sicht, Viewpoint, Stakeholder und Anliegen sowie Richtlinien für die Dokumentation einer Systemarchitektur durch die Verwendung mehrerer Sichten fest, indem Viewpoints angewendet werden, um den Anliegen der Stakeholder Rechnung zu tragen . ^{[ 6 ]} Der Vorteil mehrerer Sichten besteht darin, dass verborgene Anforderungen und Meinungsverschiedenheiten zwischen Stakeholdern leichter aufgedeckt werden können. Studien zeigen jedoch, dass die zusätzliche Komplexität der Abstimmung mehrerer Sichten diesen Vorteil in der Praxis zunichtemachen kann. ^{[ 7 ]}

IEEE 1471 (jetzt ISO/IEC/IEEE 42010:2011 , System- und Softwareentwicklung – Architekturbeschreibung ) legt den Inhalt von Architekturbeschreibungen fest und beschreibt deren Erstellung und Verwendung in verschiedenen Szenarien, darunter präzedenzbasierte und beispiellose Entwürfe, evolutionäre Entwürfe und die Erfassung von Entwürfen bestehender Systeme. In all diesen Szenarien ist der Gesamtprozess gleich: Identifizierung der Stakeholder , Erfassung ihrer Anliegen, Festlegung einer Reihe von Sichtweisen und anschließende Anwendung dieser Sichtweisenspezifikationen zur Entwicklung der für das jeweilige System relevanten Sichtweisen. Anstatt eine bestimmte Reihe von Sichtweisen vorzugeben, bietet der Standard einheitliche Mechanismen und Anforderungen, anhand derer Architekten und Organisationen ihre eigenen Sichtweisen definieren können. 1996 wurde das ISO-Referenzmodell für offene verteilte Verarbeitung ( RM-ODP ) veröffentlicht, um ein nützliches Rahmenwerk für die Beschreibung der Architektur und des Entwurfs von groß angelegten verteilten Systemen bereitzustellen.

Eine Systemsicht ist eine Darstellung des Systems aus der Perspektive eines bestimmten Standpunkts. Dieser Standpunkt konzentriert sich auf spezifische Aspekte des Systems und blendet Details aus, um ein vereinfachtes Modell zu erstellen, das nur die für den jeweiligen Standpunkt relevanten Elemente enthält. Beispielsweise fokussiert sich ein Sicherheitsstandpunkt auf Sicherheitsaspekte, und ein Sicherheitsstandpunktmodell enthält die sicherheitsrelevanten Elemente eines allgemeineren Systemmodells. ^{[ 8 ]}

Eine Ansicht ermöglicht es dem Benutzer, einen Teilbereich eines bestimmten Interessengebiets zu untersuchen. Beispielsweise kann eine Informationsansicht alle Funktionen, Organisationen, Technologien usw. darstellen, die eine bestimmte Information nutzen, während die Organisationsansicht alle Funktionen, Technologien und Informationen einer bestimmten Organisation zeigt. Im Zachman-Framework umfassen Ansichten eine Gruppe von Arbeitsergebnissen, deren Entwicklung spezifische analytische und technische Expertise erfordert, da sie sich auf das „Was“, „Wie“, „Wer“, „Wo“, „Wann“ oder „Warum“ des Unternehmens konzentrieren. Arbeitsergebnisse der Funktionsansicht beantworten beispielsweise die Frage „Wie wird die Mission erfüllt?“. Sie lassen sich am einfachsten von Experten für funktionale Dekomposition mithilfe von Prozess- und Aktivitätsmodellierung entwickeln. Sie zeigen das Unternehmen aus der Perspektive der Funktionen. Sie können auch Organisations- und Informationskomponenten darstellen, jedoch nur in Bezug auf die Funktionen. ^{[ 9 ]}

Im Systems Engineering bezeichnet ein Blickwinkel die Aufteilung oder Einschränkung von Aspekten eines Systems. Die Wahl eines Blickwinkels ermöglicht es, Probleme in diesen Bereichen getrennt zu behandeln. Eine sinnvolle Auswahl von Blickwinkeln unterteilt zudem den Systementwurf in spezifische Fachgebiete. ^{[ 3 ]}

Sichten definieren die Konventionen, Regeln und Sprachen für die Erstellung, Darstellung und Analyse von Sichten. In ISO/IEC 42010:2007 ( IEEE-Std-1471-2000 ) ist eine Sicht die Spezifikation einer einzelnen Sicht. Eine Sicht ist die Repräsentation eines Gesamtsystems aus der Perspektive einer Sicht. Eine Sicht kann aus einem oder mehreren Architekturmodellen bestehen . ^{[ 10 ]} Jedes dieser Architekturmodelle wird mithilfe der Methoden entwickelt, die sowohl für das zugehörige Architektursystem als auch für das Gesamtsystem festgelegt sind. ^{[ 6 ]}

Modellierungsperspektiven stellen verschiedene Möglichkeiten dar, vorab ausgewählte Aspekte eines Systems abzubilden. Jede Perspektive hat einen anderen Fokus, eine andere Konzeptualisierung, einen anderen Ansatz und eine andere Visualisierung dessen, was das Modell repräsentiert.

In der Informationssystemanalyse werden Modellierungsperspektiven traditionell in strukturelle, funktionale und verhaltens-/prozessorientierte Perspektiven unterteilt. Zusammen mit regel-, objekt-, kommunikations- sowie akteurs- und rollenorientierten Perspektiven stellt dies eine Möglichkeit dar, Modellierungsansätze zu klassifizieren ^{[ 11 ].}

Aus jedem beliebigen Blickwinkel lässt sich ein Modell des Systems erstellen, das nur die aus diesem Blickwinkel sichtbaren Objekte enthält, aber gleichzeitig alle im System vorhandenen und für diesen Blickwinkel relevanten Objekte, Beziehungen und Einschränkungen erfasst. Ein solches Modell wird als Blickwinkelmodell oder als Sicht des Systems aus diesem Blickwinkel bezeichnet. ^{[ 3 ]}

Eine gegebene Sicht ist eine Spezifikation des Systems auf einer bestimmten Abstraktionsebene aus einem bestimmten Blickwinkel. Unterschiedliche Abstraktionsebenen beinhalten unterschiedliche Detaillierungsgrade. Höhere Sichtebenen ermöglichen es dem Ingenieur, das Gesamtdesign zu gestalten und zu verstehen sowie Probleme im größeren Kontext zu identifizieren und zu lösen. Niedrigere Sichtebenen ermöglichen es dem Ingenieur, sich auf einen Teil des Designs zu konzentrieren und die detaillierten Spezifikationen zu entwickeln. ^{[ 3 ]}

Im System selbst müssen jedoch alle Spezifikationen der verschiedenen Sichtenmodelle in den realisierten Systemkomponenten berücksichtigt werden. Die Spezifikationen für eine bestimmte Komponente können aus vielen verschiedenen Sichten stammen. Andererseits spiegeln die Spezifikationen, die sich aus der Verteilung von Funktionen auf spezifische Komponenten und deren Interaktionen ergeben, typischerweise eine andere Aufteilung der Belange wider als die in den ursprünglichen Sichten. Daher können zusätzliche Sichten, die die Belange der einzelnen Komponenten und die Bottom-up-Synthese des Systems berücksichtigen, ebenfalls hilfreich sein. ^{[ 3 ]}

Eine Architekturbeschreibung stellt die Architektur eines Systems zu jedem Zeitpunkt hinsichtlich ihrer Komponenten, deren Funktionsweise, der für sie geltenden Regeln und Einschränkungen sowie ihrer Beziehungen untereinander und zur Umgebung dar. Die Architekturdaten werden in einer Architekturbeschreibung für verschiedene Ansichten und Produkte gemeinsam genutzt.

Die Datenschicht enthält die Architekturdatenelemente sowie deren definierende Attribute und Beziehungen. Die Präsentationsschicht umfasst Produkte und Ansichten, die eine visuelle Darstellung ermöglichen, um den Zweck der Architektur, ihre Beschreibung und die durchgeführten Architekturanalysen zu kommunizieren und zu verstehen. Produkte bieten die Möglichkeit, Architekturdaten grafisch, tabellarisch oder textuell darzustellen. Ansichten ermöglichen die Visualisierung produktübergreifender Architekturdaten und organisieren diese logisch für eine spezifische oder ganzheitliche Betrachtung der Architektur.

Der 1977 eingeführte Drei-Schema-Ansatz für die Datenmodellierung kann als eines der ersten Sichtmodelle betrachtet werden. Es handelt sich um einen Ansatz zum Aufbau von Informationssystemen und zum Management von Systeminformationen, der das konzeptionelle Modell als Schlüssel zur Datenintegration propagiert . ^{[ 13 ]} Der Drei-Schema-Ansatz definiert drei Schemata und Sichten:

• Externes Schema für Benutzeransichten
• Das konzeptuelle Schema integriert externe Schemata
• Internes Schema, das physische Speicherstrukturen definiert

Im Zentrum steht das konzeptuelle Schema, das die Ontologie der Konzepte so definiert , wie die Benutzer sie verstehen und darüber sprechen. Das physische Schema beschreibt die internen Formate der in der Datenbank gespeicherten Daten , und das externe Schema definiert die Sicht der Daten, die den Anwendungsprogrammen präsentiert wird . ^{[ 14 ]} Das Framework versuchte, die Verwendung mehrerer Datenmodelle für externe Schemata zu ermöglichen. ^{[ 15 ]}

Im Laufe der Jahre haben die Kompetenz und das Interesse am Aufbau von Informationssystemen enorm zugenommen. Der traditionelle Ansatz konzentrierte sich jedoch größtenteils auf die Definition von Daten aus zwei unterschiedlichen Perspektiven: der „Benutzerperspektive“ und der „Computerperspektive“. Aus der Benutzerperspektive, im Folgenden als „externes Schema“ bezeichnet, werden Daten im Kontext von Berichten und Bildschirmen definiert, die Anwender bei ihren jeweiligen Aufgaben unterstützen. Die erforderliche Datenstruktur aus Nutzungssicht ändert sich mit dem Geschäftsumfeld und den individuellen Präferenzen der Anwender. Aus der Computerperspektive, im Folgenden als „internes Schema“ bezeichnet, werden Daten anhand von Dateistrukturen für Speicherung und Abruf definiert. Die erforderliche Datenstruktur für die Computerspeicherung hängt von der eingesetzten Computertechnologie und dem Bedarf an effizienter Datenverarbeitung ab. ^{[ 16 ]}

Das 4+1- Modell ist ein von Philippe Kruchten 1995 entwickeltes Sichtenmodell zur Beschreibung der Architektur softwareintensiver Systeme. Es basiert auf der Verwendung mehrerer, paralleler Sichten. ^{[ 17 ]} Die Sichten beschreiben das System aus der Perspektive verschiedener Stakeholder, wie z. B. Endbenutzer, Entwickler und Projektmanager. Die vier Sichten des Modells sind die logische, die Entwicklungs-, die Prozess- und die physische Sicht.

Die vier Sichtweisen des Modells befassen sich mit Folgendem:

• Logische Sichtweise : Sie befasst sich mit der Funktionalität, die das System den Endbenutzern bietet.
• Entwicklungsperspektive : Veranschaulicht ein System aus der Sicht eines Programmierers und befasst sich mit dem Softwaremanagement.
• Prozesssicht : Sie befasst sich mit dem dynamischen Aspekt des Systems, erklärt die Systemprozesse und deren Kommunikation und konzentriert sich auf das Laufzeitverhalten des Systems.
• Physikalische Sicht : Sie beschreibt das System aus der Perspektive eines Systemingenieurs. Sie befasst sich mit der Topologie der Softwarekomponenten auf der physikalischen Schicht sowie mit der Kommunikation zwischen diesen Komponenten.

Darüber hinaus werden ausgewählte Anwendungsfälle oder Szenarien zur Veranschaulichung der Architektur herangezogen. Daher enthält das Modell 4+1 Ansichten. ^{[ 17 ]}

Ein Enterprise-Architektur-Framework definiert die Organisation der Struktur und der Sichten einer Unternehmensarchitektur . Da die Disziplin der Enterprise-Architektur und des Enterprise-Engineerings sehr breit gefächert ist und Unternehmen groß und komplex sein können, sind auch die zugehörigen Modelle in der Regel umfangreich und komplex. Um diese Größenordnung und Komplexität zu bewältigen, bietet ein Architektur-Framework Werkzeuge und Methoden, die die Aufgaben fokussieren und die Erstellung wertvoller Artefakte zum richtigen Zeitpunkt ermöglichen.

Architektur-Frameworks werden häufig in der Informationstechnologie und im Management von Informationssystemen eingesetzt . Organisationen können vorschreiben, dass bestimmte Modelle erstellt werden müssen, bevor ein Systemdesign genehmigt wird. Ebenso können sie festlegen, welche Sichten in der Dokumentation beschaffter Systeme verwendet werden sollen – das US-Verteidigungsministerium schreibt beispielsweise vor, dass Ausrüstungslieferanten für Investitionsprojekte ab einem bestimmten Wert bestimmte DoDAF-Sichtungen bereitstellen müssen.

Das Zachman-Framework , das ursprünglich 1987 von John Zachman bei IBM entwickelt wurde, ist ein Rahmenwerk für Unternehmensarchitektur, das eine formale und hochstrukturierte Möglichkeit bietet, ein Unternehmen zu betrachten und zu definieren.

Das Framework dient der Organisation architektonischer „Artefakte“ unter Berücksichtigung der Zielgruppe (z. B. Geschäftsinhaber und Entwickler) und des jeweiligen Problems (z. B. Daten und Funktionalität). Zu diesen Artefakten können Entwurfsdokumente, Spezifikationen und Modelle gehören. ^{[ 19 ]}

Das Zachman-Framework wird häufig als Standardansatz zur Beschreibung der grundlegenden Elemente der Unternehmensarchitektur herangezogen . Das Zachman-Framework wurde von der US-Bundesregierung als „weltweit anerkanntes integriertes Framework für das Change-Management in Unternehmen und den dazugehörigen Systemen“ anerkannt. ^{[ 20 ]}

Das Referenzmodell der Internationalen Organisation für Normung (ISO) für offene verteilte Verarbeitung ( RM-ODP ) ^{[ 21 ]} spezifiziert eine Reihe von Sichtweisen zur Partitionierung des Entwurfs eines verteilten Software-/Hardwaresystems. Da die meisten Integrationsprobleme beim Entwurf solcher Systeme oder in sehr ähnlichen Situationen auftreten, können sich diese Sichtweisen als nützlich erweisen, um Integrationsaspekte zu trennen. Die RM-ODP-Sichtweisen sind: ^{[ 3 ]}

• Die Unternehmensperspektive , die sich mit dem Zweck und dem Verhalten des Systems im Hinblick auf die Geschäftsziele und Geschäftsprozesse der Organisation befasst.
• Der Informationsstandpunkt befasst sich mit der Art der vom System verarbeiteten Informationen sowie mit den Einschränkungen bei deren Nutzung und Interpretation.
• Der rechnerische Ansatz befasst sich mit der funktionalen Zerlegung des Systems in eine Reihe von Komponenten, die spezifische Verhaltensweisen aufweisen und an Schnittstellen interagieren.
• Die ingenieurwissenschaftliche Sichtweise , die sich mit den Mechanismen und Funktionen befasst, die zur Unterstützung der Interaktionen der Rechenkomponenten erforderlich sind.
• Die technologische Perspektive befasst sich mit der expliziten Auswahl von Technologien für die Implementierung des Systems, insbesondere für die Kommunikation zwischen den Komponenten.

RMODP definiert ferner die Anforderung, dass ein Entwurf Spezifikationen zur Konsistenz zwischen verschiedenen Sichtweisen enthalten muss, einschließlich: ^{[ 3 ]}

• die Verwendung von Unternehmensobjekten und -prozessen bei der Definition von Informationseinheiten
• die Verwendung von Unternehmensobjekten und -verhaltensweisen zur Spezifizierung des Verhaltens von Rechenkomponenten sowie die Verwendung von Informationseinheiten zur Definition von Rechenschnittstellen
• die Verknüpfung von technischen Entscheidungen mit Rechenschnittstellen und Verhaltensanforderungen
• die Erfüllung der Informations-, Rechen- und Ingenieursanforderungen in den gewählten Technologien

Das Department of Defense Architecture Framework (DoDAF) definiert einen Standard zur Organisation einer Unternehmensarchitektur (EA) oder Systemarchitektur in komplementäre und konsistente Sichten. Es eignet sich besonders für große Systeme mit komplexen Integrations- und Interoperabilitätsherausforderungen und ist offenbar einzigartig in seiner Verwendung von „ operativen Sichten “, die den Betriebsbereich des externen Kunden detailliert beschreiben, in dem das entwickelte System eingesetzt werden soll.

Das DoDAF definiert eine Reihe von Produkten, die als Mechanismen zur Visualisierung, zum Verständnis und zur Aneignung des breiten Spektrums und der Komplexität einer Architekturbeschreibung mittels grafischer, tabellarischer oder textueller Mittel dienen. Diese Produkte sind in vier Ansichten unterteilt:

• Übergreifende Gesamtansicht (AV),
• Operative Sicht (OV),
• Systems View (SV) und die
• Technische Normenansicht (TV).

Jede Ansicht stellt bestimmte Perspektiven einer Architektur dar, wie nachfolgend beschrieben. Für jede Systementwicklung wird üblicherweise nur eine Teilmenge des vollständigen DoDAF-Ansichtssatzes erstellt. Die Abbildung veranschaulicht die Informationen, die die operative Ansicht , die System- und Serviceansicht sowie die technische Standardansicht verknüpfen. Die drei Ansichten und ihre – durch gemeinsame Architekturdatenelemente gesteuerten – Wechselbeziehungen bilden die Grundlage für die Ableitung von Kennzahlen wie Interoperabilität oder Leistung sowie für die Messung der Auswirkungen dieser Kennzahlenwerte auf die Effektivität von operativen Missionen und Aufgaben. ^{[ 22 ]}

In der US-amerikanischen Bundesarchitektur bieten Unternehmens-, Segment- und Lösungsarchitektur unterschiedliche Geschäftsperspektiven, indem sie den Detaillierungsgrad variieren und verwandte, aber unterschiedliche Belange behandeln. Ebenso wie Unternehmen selbst hierarchisch organisiert sind, sind auch die verschiedenen Sichtweisen der einzelnen Architekturtypen hierarchisch strukturiert. Die „Federal Enterprise Architecture Practice Guidance“ (2006) definiert drei Architekturtypen: ^{[ 23 ]}

• Unternehmensarchitektur
• Segmentarchitektur und
• Lösungsarchitektur.

Enterprise Architecture (EA) befasst sich per Definition grundlegend mit der Identifizierung gemeinsamer oder geteilter Ressourcen – seien es Strategien, Geschäftsprozesse, Investitionen, Daten, Systeme oder Technologien. EA ist strategisch ausgerichtet; sie unterstützt eine Behörde dabei, zu erkennen, ob ihre Ressourcen optimal auf ihre Mission und ihre strategischen Ziele abgestimmt sind. Aus Investitionssicht dient EA als Grundlage für Entscheidungen über das gesamte IT-Investitionsportfolio. Folglich sind die wichtigsten Stakeholder der EA die Führungskräfte, die dafür verantwortlich sind, dass die Behörde ihre Mission so effektiv und effizient wie möglich erfüllt. ^{[ 23 ]}

Im Gegensatz dazu definiert die Segmentarchitektur einen einfachen Fahrplan für einen Kernaufgabenbereich, eine Geschäftsdienstleistung oder eine Unternehmensdienstleistung. Sie wird vom Business Management gesteuert und liefert Produkte, die die Servicebereitstellung für Bürger und Behördenmitarbeiter verbessern. Aus Investitionssicht beeinflusst die Segmentarchitektur die Entscheidungen für einen oder mehrere Business Cases, die einen Kernaufgabenbereich oder eine gemeinsame Dienstleistung unterstützen. Die Hauptakteure der Segmentarchitektur sind die Verantwortlichen und Manager der einzelnen Geschäftsbereiche. Die Segmentarchitektur ist über drei Prinzipien mit der Unternehmensarchitektur (EA) verwandt: Struktur, Wiederverwendung und Ausrichtung. Erstens übernimmt die Segmentarchitektur das von der EA verwendete Framework, kann aber erweitert und an die spezifischen Bedürfnisse eines Kernaufgabenbereichs oder einer gemeinsamen Dienstleistung angepasst werden. Zweitens nutzt die Segmentarchitektur wichtige, auf Unternehmensebene definierte Ressourcen wieder, darunter Daten, gemeinsame Geschäftsprozesse und Investitionen sowie Anwendungen und Technologien. Drittens orientiert sich die Segmentarchitektur an Elementen, die auf Unternehmensebene definiert sind, wie z. B. Geschäftsstrategien, Mandate, Standards und Leistungskennzahlen. ^{[ 23 ]}

Auf der Suche nach einem „Rahmenwerk zur Modellierung von Weltraumsystemarchitekturen“ definierten Peter Shames und Joseph Skipper (2006) einen „nominalen Satz von Ansichten“ ^{[ 6 ]} , abgeleitet von CCSDS RASDS, RM-ODP, ISO 10746 und konform mit IEEE 1471 .

Diese „Ansichtensammlung“ (siehe unten) stellt eine Liste möglicher Modellierungsperspektiven dar. Nicht alle diese Ansichten sind für jedes Projekt geeignet, und bei Bedarf können weitere Ansichten definiert werden. Beachten Sie, dass für manche Analysen Elemente aus mehreren Perspektiven zu einer neuen Ansicht kombiniert werden können, gegebenenfalls mithilfe einer geschichteten Darstellung.

In einer späteren Präsentation wurde diese nominale Menge von Ansichten als erweiterte Ableitung des semantischen Informationsmodells RASDS vorgestellt. ^{[ 24 ]} RASDS steht hierbei für Reference Architecture for Space Data Systems (Referenzarchitektur für Weltraumdatensysteme). Siehe zweites Bild.

Unternehmensperspektive ^{[ 6 ]}

• Organisationsperspektive – Umfasst Organisationselemente sowie deren Strukturen und Beziehungen. Kann Vereinbarungen, Verträge, Richtlinien und organisatorische Interaktionen beinhalten.
• Anforderungsansicht – Beschreibt die Anforderungen , Ziele und Vorgaben, die das System bestimmen. Legt fest, was das System leisten muss.
• Szenarioansicht – Beschreibt die vorgesehene Nutzung des Systems (siehe Szenarioplanung ). Beinhaltet Benutzeransichten und Beschreibungen des erwarteten Systemverhaltens.

Informationsperspektive ^{[ 6 ]}

• Metamodell-Sicht – Eine abstrakte Sicht, die Informationsmodellelemente sowie deren Strukturen und Beziehungen definiert. Sie definiert die vom System erstellten und verwalteten Datenklassen und die Datenarchitektur.
• Informationssicht – Beschreibt die tatsächlichen Daten und Informationen , wie sie im System realisiert und verarbeitet werden. Datenelemente werden durch die Metamodellsicht definiert und von funktionalen Objekten in anderen Sichten referenziert.

Funktionale Sichtweise ^{[ 6 ]}

• Funktionale Datenflusssicht – Eine abstrakte Sicht, die die funktionalen Elemente des Systems, ihre Interaktionen, ihr Verhalten, die bereitgestellten Dienste, Einschränkungen und Datenflüsse zwischen ihnen beschreibt. Sie definiert, welche Funktionen das System ausführen kann, unabhängig davon, wie diese Funktionen tatsächlich implementiert sind.
• Funktionale Steuerungssicht – Beschreibt die Steuerungsabläufe und Interaktionen zwischen den funktionalen Elementen innerhalb des Systems. Umfasst die Interaktionen der Gesamtsystemsteuerung, die Interaktionen zwischen Steuerungselementen und Sensor-/Aktorelementen sowie die Managementinteraktionen.

Physikalische Sichtweise ^{[ 6 ]}

• Datensystemansicht – Beschreibt Instrumente, Computer und Datenspeicherkomponenten, deren Datensystemattribute und die im System verwendeten Kommunikationsanschlüsse (Busse, Netzwerke, Punkt-zu-Punkt-Verbindungen).
• Telekommunikationsansicht – Beschreibt die Telekommunikationskomponenten (Antenne, Transceiver), ihre Eigenschaften und ihre Anschlüsse (RF- oder optische Verbindungen).
• Navigationsansicht – Beschreibt die Bewegung der wichtigsten Elemente innerhalb des Systems (Trajektorie, Bahn, Umlaufbahn), einschließlich ihrer Wechselwirkung mit externen Elementen und Kräften, die außerhalb der Kontrolle des Systems liegen, aber mit ihm modelliert werden müssen, um das Systemverhalten zu verstehen (Planeten, Asteroiden, Sonnendruck, Schwerkraft).
• Strukturelle Betrachtung – Beschreibt die Strukturkomponenten des Systems (Bus, Streben, Paneele, Gelenke), deren physikalische Eigenschaften und Verbindungen sowie die relevanten strukturellen Aspekte anderer Komponenten (Masse, Steifigkeit, Befestigung).
• Thermische Ansicht – Beschreibt die aktiven und passiven thermischen Komponenten des Systems (Kühler, Lüfter, Lüftungsöffnungen) und deren Anschlüsse (physikalische und Freiraumstrahlung) sowie deren Eigenschaften, zusammen mit den thermischen Eigenschaften anderer Komponenten (z. B. Antenne als Sonnenschutz).
• Leistungsübersicht – Beschreibt die aktiven und passiven Leistungskomponenten des Systems (Solarpaneele, Batterien, RTGs) innerhalb des Systems und deren Anschlüsse sowie die Leistungseigenschaften anderer Komponenten (Datensystem und Antriebselemente als Leistungssenken und Strukturpaneele als Erdungsebene).
• Antriebsansicht – Beschreibt die aktiven und passiven Antriebskomponenten des Systems (Triebwerke, Gyroskope, Motoren, Räder) und deren Verbindungen sowie die Antriebseigenschaften anderer Komponenten.

Ingenieursperspektive ^{[ 6 ]}

• Zuordnungsansicht – Beschreibt die Zuordnung funktionaler Objekte zu den entwickelten physischen und rechnergestützten Komponenten innerhalb des Systems, ermöglicht die Analyse der Leistung und dient der Überprüfung der Erfüllung der Anforderungen.
• Software-Sicht – Beschreibt die softwaretechnischen Aspekte des Systems, den Softwareentwurf und die Implementierung von Funktionalitäten innerhalb von Softwarekomponenten, die Auswahl der zu verwendenden Sprachen und Bibliotheken, die Definition von APIs sowie die Umsetzung abstrakter funktionaler Objekte in konkrete Softwareelemente. Einige funktionale Elemente, die mithilfe einer Softwaresprache beschrieben werden, können tatsächlich als Hardware (FPGA, ASIC) implementiert werden.
• Hardware-Ansichten – Beschreibt die hardwaretechnischen Aspekte des Systems, den Hardware-Entwurf, die Auswahl und die Implementierung aller physischen Komponenten, die in das System integriert werden. Es kann mehrere solcher Ansichten geben, die jeweils einer anderen Ingenieursdisziplin zugeordnet sind.
• Sichtweise der Kommunikationsprotokolle – Beschreibt den End-to-End-Entwurf der Kommunikationsprotokolle und der zugehörigen Datentransport- und Datenverwaltungsdienste und zeigt die Protokollstapel, wie sie auf den einzelnen physischen Komponenten des Systems implementiert sind.
• Risikobetrachtung – Beschreibt die mit dem Systemdesign, den Prozessen und Technologien verbundenen Risiken und ordnet anderen in der Architektur beschriebenen Elementen zusätzliche Risikobewertungsattribute zu.
• Regelungstechnische Sichtweise – Analyse des Systems aus der Perspektive seiner Steuerbarkeit, Zuordnung der Elemente zum zu steuernden System und des Regelsystems.
• Integrations- und Testperspektive – Diese Perspektive betrachtet das System aus der Sicht der notwendigen Schritte zur Montage, Integration und zum Test von System, Subsystemen und Baugruppen. Sie umfasst die Überprüfung der korrekten Funktionalität anhand von Szenarien zur Erfüllung der Anforderungen.
• IV&V-Sicht – unabhängige Validierung und Verifizierung der Funktionalität und des ordnungsgemäßen Betriebs des Systems hinsichtlich der Erfüllung der Anforderungen. Erfüllt das System in der entworfenen und entwickelten Form die Ziele und Vorgaben?

Technologische Sichtweise ^{[ 6 ]}

• Normenperspektive – Definiert die Normen, die beim Systemdesign anzuwenden sind (z. B. Kommunikationsprotokolle, Strahlungsbeständigkeit, Lötverfahren). Diese stellen im Wesentlichen Einschränkungen für die Design- und Implementierungsprozesse dar.
• Infrastrukturansicht – Definiert die Infrastrukturelemente, die den Entwicklungs-, Konstruktions- und Fertigungsprozess unterstützen sollen. Dazu gehören Datensystemelemente (Design-Repositories, Frameworks, Tools, Netzwerke) und Hardwareelemente (Chipfertigung, thermische Vakuumanlage, Werkstatt, HF-Testlabor).
• Technologieentwicklung und -bewertung – Beinhaltet die Beschreibung von Technologieentwicklungsprogrammen zur Erstellung von Algorithmen oder Komponenten, die in ein Systementwicklungsprojekt einfließen können. Dazu gehört auch die Bewertung der Eigenschaften ausgewählter Hardware- und Softwarekomponenten, um festzustellen, ob sie für die geplante Mission ausreichend ausgereift sind.

Im Gegensatz zu den zuvor aufgeführten Sichtmodellen listet diese „nominale Menge von Sichten“ eine ganze Reihe von Sichten auf, die es ermöglichen, leistungsstarke und erweiterbare Ansätze zur Beschreibung einer allgemeinen Klasse von softwareintensiven Systemarchitekturen zu entwickeln. ^{[ 6 ]}

• Rahmenwerk für Unternehmensarchitektur
• Organisationsarchitektur
• Softwareentwicklungsmethodik
• Architekturrahmen für das Finanzministerium
• TOGAF
• Zachman-Framework
• Ontologie (Informationswissenschaft)
• Wissenserwerb

Quellenangabe

 Dieser Artikel enthält gemeinfreies Material des National Institute of Standards and Technology.

• Medien zum Thema Ansichtsmodelle auf Wikimedia Commons