Modell anzeigen - View model

Weitere Verwendungszwecke finden Sie unter Ansichtsmodell (Begriffsklärung) .
Die TEAF- Matrix der Ansichten und Perspektiven.

Ein Ansichtsmodell oder ein Ansichtspunkt- Framework in Systems Engineering , Software Engineering und Enterprise Engineering ist ein Framework, das einen kohärenten Satz von Ansichten definiert , die beim Aufbau einer Systemarchitektur , Softwarearchitektur oder Unternehmensarchitektur verwendet werden sollen . Eine Ansicht ist eine Darstellung eines gesamten Systems aus der Perspektive einer verwandten Reihe von Anliegen.

Seit Anfang der neunziger Jahre wurden verschiedene Anstrengungen unternommen, um Ansätze zur Beschreibung und Analyse von Systemarchitekturen vorzuschreiben. Diese jüngsten Bemühungen definieren eine Reihe von Ansichten (oder Standpunkten). Sie werden manchmal als Architektur-Frameworks oder Enterprise-Architektur-Frameworks bezeichnet , werden jedoch normalerweise als "Ansichtsmodelle" bezeichnet.

Normalerweise ist eine Ansicht ein Arbeitsprodukt, das bestimmte Architekturdaten für ein bestimmtes System darstellt. Jedoch wird der gleiche Begriff manchmal bezieht sich auf eine Ansicht verwendete Definition , einschließlich dem speziellen Betrachtungspunkt und die entsprechenden Führung , die definiert , die jeweils konkrete Ansicht. Der Begriff Ansichtsmodell bezieht sich auf Ansichtsdefinitionen.

Überblick

Der Zweck von Ansichten und Standpunkten besteht darin, es dem Menschen zu ermöglichen, sehr komplexe Systeme zu verstehen , die Elemente des Problems und die Lösung nach Fachgebieten zu organisieren und Bedenken zu trennen . Beim Engineering physisch intensiver Systeme entsprechen Gesichtspunkte häufig den Fähigkeiten und Verantwortlichkeiten innerhalb der Engineering-Organisation.

Die meisten komplexen Systemspezifikationen sind so umfangreich, dass keine einzelne Person alle Aspekte der Spezifikationen vollständig erfassen kann. Darüber hinaus haben wir alle unterschiedliche Interessen in einem gegebenen System und verschiedene Gründe für die Prüfung des Systems ‚s Spezifikationen . Ein Unternehmensleiter stellt einem Systemaufbau andere Fragen als ein Systemimplementierer. Das Konzept des Standpunkt-Frameworks besteht daher darin, separate Standpunkte für die Spezifikation eines bestimmten komplexen Systems bereitzustellen, um die Kommunikation mit den Stakeholdern zu erleichtern. Jeder Standpunkt befriedigt ein Publikum mit Interesse an einer bestimmten Reihe von Aspekten des Systems. Jeder Standpunkt kann eine bestimmte Standpunktsprache verwenden , die das Vokabular und die Präsentation für das Publikum dieses Standpunkts optimiert. Die Ansichtspunktmodellierung hat sich zu einem effektiven Ansatz für den Umgang mit der inhärenten Komplexität großer verteilter Systeme entwickelt.

Architekturbeschreibungspraktiken, wie in IEEE Std 1471-2000 beschrieben , verwenden mehrere Ansichten, um mehrere Problembereiche anzusprechen, die sich jeweils auf einen bestimmten Aspekt des Systems konzentrieren. Beispiele für Architektur-Frameworks, die mehrere Ansichten verwenden, sind das "4 + 1" -Ansichtsmodell von Kruchten , das Zachman Framework , TOGAF , DoDAF und RM-ODP .

Geschichte

In den 1970er Jahren tauchten in der Softwareentwicklung Methoden zur Modellierung mit mehreren Ansichten auf. Douglas T. Ross und KE Schoman führen 1977 den Konstruktkontext, den Standpunkt und den Standpunkt ein, um den Modellierungsprozess in der Definition der Systemanforderungen zu organisieren. Laut Ross und Schoman macht ein Standpunkt "klar, welche Aspekte für das Erreichen ... des Gesamtzwecks [des Modells] relevant sind" und bestimmt, wie wir [ein zu modellierendes Thema] betrachten.

Als Beispiele für Gesichtspunkte bietet das Papier: technische, betriebliche und wirtschaftliche Gesichtspunkte. Im Jahr 1992 veröffentlichten Anthony Finkelstein und andere ein sehr wichtiges Papier über Standpunkte. In dieser Arbeit: "Ein Standpunkt kann als eine Kombination aus der Idee eines" Akteurs ", einer" Wissensquelle ", einer" Rolle "oder eines" Agenten "im Entwicklungsprozess und der Idee einer" Sichtweise "oder" Perspektive "betrachtet werden "Was ein Schauspieler behauptet." Eine wichtige Idee in diesem Artikel war die Unterscheidung zwischen "einem Darstellungsstil , dem Schema und der Notation, mit der der Standpunkt ausdrückt, was er sehen kann" und "einer Spezifikation , den Aussagen, die im Stil des Standpunkts ausgedrückt werden und bestimmte Bereiche beschreiben". Nachfolgende Arbeiten wie IEEE 1471 bewahrten diese Unterscheidung, indem sie zwei getrennte Begriffe verwendeten: Standpunkt bzw. Ansicht.

Seit Anfang der neunziger Jahre wurden verschiedene Anstrengungen unternommen, um Ansätze zur Beschreibung und Analyse von Systemarchitekturen zu kodifizieren. Diese werden oft als Architektur-Frameworks oder manchmal als Ansichtssätze bezeichnet . Viele davon wurden vom US-Verteidigungsministerium finanziert , einige sind jedoch aus internationalen oder nationalen Bemühungen um ISO oder IEEE hervorgegangen . Unter diesen wurden in der von IEEE empfohlenen Vorgehensweise für die architektonische Beschreibung softwareintensiver Systeme ( IEEE Std 1471-2000 ) nützliche Definitionen für Ansicht, Standpunkt, Stakeholder und Anliegen sowie Richtlinien für die Dokumentation einer Systemarchitektur unter Verwendung mehrerer Ansichten unter Anwendung von Gesichtspunkten festgelegt Anliegen der Stakeholder ansprechen . Der Vorteil mehrerer Ansichten besteht darin, dass versteckte Anforderungen und Meinungsverschiedenheiten zwischen Stakeholdern leichter entdeckt werden können. Studien zeigen jedoch, dass in der Praxis die zusätzliche Komplexität der Abstimmung mehrerer Ansichten diesen Vorteil untergraben kann.

IEEE 1471 (jetzt ISO / IEC / IEEE 42010: 2011 , System- und Softwareentwicklung - Architekturbeschreibung ) schreibt den Inhalt von Architekturbeschreibungen vor und beschreibt deren Erstellung und Verwendung unter einer Reihe von Szenarien, einschließlich beispiellosem und beispiellosem Design, evolutionärem Design und Erfassung des Entwurfs bestehender Systeme. In all diesen Szenarien ist der Gesamtprozess derselbe: Stakeholder identifizieren , Bedenken hervorrufen, eine Reihe von zu verwendenden Gesichtspunkten identifizieren und diese Gesichtspunktspezifikationen dann anwenden, um die für das interessierende System relevanten Ansichten zu entwickeln. Anstatt einen bestimmten Satz von Gesichtspunkten zu definieren, bietet der Standard einheitliche Mechanismen und Anforderungen für Architekten und Organisationen, um ihre eigenen Standpunkte zu definieren. 1996 wurde das ISO-Referenzmodell für Open Distributed Processing ( RM-ODP ) veröffentlicht, um einen nützlichen Rahmen für die Beschreibung der Architektur und des Designs verteilter Großsysteme bereitzustellen.

Modellthemen anzeigen

Aussicht

Eine Ansicht eines Systems ist eine Darstellung des Systems aus der Perspektive eines Gesichtspunkts. Dieser Standpunkt zu einem System beinhaltet eine Perspektive, die sich auf bestimmte Bedenken in Bezug auf das System konzentriert, wodurch Details unterdrückt werden, um ein vereinfachtes Modell bereitzustellen, das nur die Elemente enthält, die sich auf die Bedenken des Standpunkts beziehen. Ein Sicherheitsstandpunkt konzentriert sich beispielsweise auf Sicherheitsbedenken, und ein Sicherheitsstandpunktmodell enthält diejenigen Elemente, die sich auf die Sicherheit eines allgemeineren Modells eines Systems beziehen.

Eine Ansicht ermöglicht es einem Benutzer, einen Teil eines bestimmten Interessenbereichs zu untersuchen. Beispielsweise kann eine Informationsansicht alle Funktionen, Organisationen, Technologien usw. darstellen, die eine bestimmte Information verwenden, während die Organisationsansicht alle Funktionen, Technologien und Informationen darstellen kann, die für eine bestimmte Organisation von Belang sind. In den Zachman Framework- Ansichten umfasst eine Gruppe von Arbeitsprodukten, deren Entwicklung ein bestimmtes analytisches und technisches Fachwissen erfordert, da sie sich entweder auf das „Was“, das „Wie“, das „Wer“, das „Wo“, das „Wann“ oder das „Warum“ konzentrieren. des Unternehmens. Beispielsweise beantworten Arbeitsprodukte von Functional View die Frage „Wie wird die Mission ausgeführt?“. Sie lassen sich am einfachsten von Experten für funktionale Zerlegung mithilfe von Prozess- und Aktivitätsmodellierung entwickeln. Sie zeigen das Unternehmen aus Sicht der Funktionen. Sie können auch Organisations- und Informationskomponenten anzeigen, jedoch nur in Bezug auf Funktionen.

Standpunkte

In der Systemtechnik ist ein Gesichtspunkt eine Partitionierung oder Einschränkung von Bedenken in einem System. Die Annahme eines Standpunkts ist verwendbar, so dass Probleme in diesen Aspekten separat behandelt werden können. Eine gute Auswahl an Gesichtspunkten unterteilt das Design des Systems auch in bestimmte Fachgebiete.

Ansichtspunkte bieten die Konventionen, Regeln und Sprachen zum Erstellen, Präsentieren und Analysieren von Ansichten. In ISO / IEC 42010: 2007 ( IEEE-Std-1471-2000 ) ist ein Ansichtspunkt eine Spezifikation für eine einzelne Ansicht. Eine Ansicht ist eine Darstellung eines gesamten Systems aus der Perspektive eines Gesichtspunkts. Eine Ansicht kann aus einem oder mehreren Architekturmodellen bestehen . Jedes dieser Architekturmodelle wird unter Verwendung der Methoden entwickelt, die durch das zugehörige Architektursystem sowie für das gesamte System festgelegt wurden.

Modellierungsperspektiven

Das Modellieren von Perspektiven ist eine Reihe verschiedener Möglichkeiten, um vorgewählte Aspekte eines Systems darzustellen. Jede Perspektive hat einen anderen Fokus, eine andere Konzeptualisierung, Widmung und Visualisierung dessen, was das Modell darstellt.

In Informationssystemen besteht die traditionelle Art, Modellierungsperspektiven zu teilen, darin, die strukturellen, funktionalen und verhaltens- / prozessualen Perspektiven zu unterscheiden. Dies ist zusammen mit Regel-, Objekt-, Kommunikations- sowie Akteur- und Rollenperspektiven eine Möglichkeit, Modellierungsansätze zu klassifizieren

Ansichtspunktmodell

In jedem Ansichtspunkt ist es möglich, ein Modell des Systems zu erstellen, das nur die Objekte enthält, die von diesem Standpunkt aus sichtbar sind, aber auch alle Objekte, Beziehungen und Einschränkungen erfasst, die im System vorhanden und für diesen Standpunkt relevant sind. Ein solches Modell wird als Standpunktmodell oder als Ansicht des Systems von diesem Standpunkt aus bezeichnet.

Eine bestimmte Ansicht ist eine Spezifikation für das System auf einer bestimmten Abstraktionsebene unter einem bestimmten Gesichtspunkt. Unterschiedliche Abstraktionsebenen enthalten unterschiedliche Detailebenen. Übergeordnete Ansichten ermöglichen es dem Ingenieur, das gesamte Design zu gestalten und zu verstehen sowie Probleme im großen und ganzen zu identifizieren und zu lösen. Mit Ansichten auf niedrigerer Ebene kann sich der Ingenieur auf einen Teil des Entwurfs konzentrieren und die detaillierten Spezifikationen entwickeln.

Illustration der Ansichten, Produkte und Daten in Architecture Framework.

Im System selbst müssen jedoch alle in den verschiedenen Gesichtspunktmodellen enthaltenen Spezifikationen in den realisierten Komponenten des Systems berücksichtigt werden. Und die Spezifikationen für eine bestimmte Komponente können aus vielen verschiedenen Blickwinkeln gezogen werden. Andererseits spiegeln die Spezifikationen, die durch die Verteilung von Funktionen auf bestimmte Komponenten und Komponenteninteraktionen hervorgerufen werden, typischerweise eine andere Aufteilung der Bedenken wider als in den ursprünglichen Gesichtspunkten. Daher können auch zusätzliche Gesichtspunkte nützlich sein, die sich mit den Anliegen der einzelnen Komponenten und der Bottom-up-Synthese des Systems befassen.

Architekturbeschreibung

Eine Architekturbeschreibung ist eine Darstellung einer Systemarchitektur zu jeder Zeit in Bezug auf ihre Bestandteile, wie diese Teile funktionieren, die Regeln und Einschränkungen, unter denen diese Teile funktionieren, und wie sich diese Teile aufeinander und auf die Umgebung beziehen. In einer Architekturbeschreibung werden die Architekturdaten von mehreren Ansichten und Produkten gemeinsam genutzt.

Auf der Datenschicht befinden sich die Architekturdatenelemente und ihre definierenden Attribute und Beziehungen. Auf der Präsentationsebene befinden sich die Produkte und Ansichten, die ein visuelles Mittel unterstützen, um den Zweck der Architektur, ihre Beschreibung und die verschiedenen durchgeführten Architekturanalysen zu kommunizieren und zu verstehen. Produkte bieten eine Möglichkeit, Architekturdaten als grafische, tabellarische oder textuelle Darstellungen zu visualisieren. Ansichten bieten die Möglichkeit, Architekturdaten zu visualisieren, die produktübergreifend sind, und die Daten logisch für eine bestimmte oder ganzheitliche Perspektive der Architektur zu organisieren.

Arten von Systemansichtsmodellen

Drei-Schema-Ansatz

Der Begriff eines Drei-Schema-Modells wurde erstmals 1977 von der dreistufigen ANSI / X3 / SPARC-Architektur eingeführt , die drei Ebenen für Modelldaten festlegte.

Der 1977 eingeführte Drei-Schema-Ansatz für die Datenmodellierung kann als eines der ersten Ansichtsmodelle angesehen werden. Es ist ein Ansatz zum Aufbau von Informationssystemen und zum Systeminformationsmanagement , der das konzeptionelle Modell als Schlüssel zur Erreichung der Datenintegration fördert . Der Drei-Schema-Ansatz definiert drei Schemas und Ansichten:

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

Im Zentrum definiert das konzeptionelle Schema die Ontologie der Konzepte, wenn die Benutzer an sie denken und über sie sprechen. Das physische Schema beschreibt die internen Formate der in der Datenbank gespeicherten Daten , und das externe Schema definiert die Ansicht der Daten, die den Anwendungsprogrammen angezeigt werden . Das Framework versuchte, die Verwendung mehrerer Datenmodelle für externe Schemata zuzulassen.

Im Laufe der Jahre hat die Fähigkeit und das Interesse am Aufbau von Informationssystemen enorm zugenommen. Der traditionelle Ansatz zum Erstellen von Systemen konzentrierte sich jedoch größtenteils nur auf die Definition von Daten aus zwei unterschiedlichen Ansichten, der "Benutzeransicht" und der "Computeransicht". In der Benutzeransicht, die als „externes Schema“ bezeichnet wird, erfolgt die Definition von Daten im Kontext von Berichten und Bildschirmen, die Einzelpersonen bei der Ausführung ihrer spezifischen Aufgaben unterstützen sollen. Die erforderliche Datenstruktur aus einer Nutzungsansicht ändert sich mit der Geschäftsumgebung und den individuellen Vorlieben des Benutzers. In der Computeransicht, die als "internes Schema" bezeichnet wird, werden Daten als Dateistrukturen zum Speichern und Abrufen definiert. Die erforderliche Datenstruktur für die Computerspeicherung hängt von der spezifischen verwendeten Computertechnologie und der Notwendigkeit einer effizienten Datenverarbeitung ab.

4 + 1-Ansichtsmodell der Architektur

Abbildung des 4 + 1- Ansichtsmodells oder der Architektur.

4 + 1 ist ein Ansichtsmodell, das 1995 von Philippe Kruchten entworfen wurde , um die Architektur softwareintensiver Systeme zu beschreiben, die auf der Verwendung mehrerer gleichzeitiger Ansichten basiert. Die Ansichten werden verwendet, um das System aus Sicht verschiedener Interessengruppen wie Endbenutzer, Entwickler und Projektmanager zu beschreiben. Die vier Ansichten des Modells sind logisch, Entwicklung, Prozess und physische Ansicht:

Die vier Ansichten des Modells befassen sich mit:

  • Logische Ansicht : befasst sich mit der Funktionalität, die das System Endbenutzern bietet.
  • Entwicklungsansicht : Veranschaulicht ein System aus Sicht eines Programmierers und befasst sich mit Software-Management.
  • Prozessansicht : Behandelt den dynamischen Aspekt des Systems, erklärt die Systemprozesse und deren Kommunikation und konzentriert sich auf das Laufzeitverhalten des Systems.
  • Physische Ansicht : Zeigt das System aus Sicht eines Systemingenieurs. Es befasst sich mit der Topologie von Softwarekomponenten auf der physischen Ebene sowie der Kommunikation zwischen diesen Komponenten.

Zusätzlich werden ausgewählte Anwendungsfälle oder Szenarien verwendet, um die Architektur zu veranschaulichen. Daher enthält das Modell 4 + 1 Ansichten.

Arten von Ansichten der Unternehmensarchitektur

Das Enterprise Architecture Framework definiert, wie die Struktur und Ansichten einer Unternehmensarchitektur organisiert werden . Weil die Disziplin der Unternehmensarchitektur und des Ingenieurwesens so breit ist und weil Unternehmen groß und komplex sein können, sind die mit der Disziplin verbundenen Modelle auch tendenziell groß und komplex. Um diese Größe und Komplexität zu verwalten, bietet ein Architektur-Framework Tools und Methoden, mit denen die Aufgabe in den Fokus gerückt und wertvolle Artefakte erstellt werden können, wenn sie am dringendsten benötigt werden.

Architektur-Frameworks werden häufig in der Informationstechnologie und der Governance von Informationssystemen verwendet . Eine Organisation möchte möglicherweise vorschreiben, dass bestimmte Modelle hergestellt werden, bevor ein Systemdesign genehmigt werden kann. In ähnlicher Weise möchten sie möglicherweise bestimmte Ansichten angeben, die bei der Dokumentation von beschafften Systemen verwendet werden sollen. Das US-Verteidigungsministerium schreibt vor, dass bestimmte DoDAF-Ansichten von Ausrüstungslieferanten für Kapitalprojekte über einem bestimmten Wert bereitgestellt werden.

Zachman Framework

Vereinfachte Darstellung des Zachman Frameworks mit Erläuterung der Zeilen. Das ursprüngliche Framework ist weiter fortgeschritten. Ein Beispiel finden Sie hier .

Das Zachman Framework , das ursprünglich 1987 von John Zachman bei IBM konzipiert wurde , ist ein Framework für die Unternehmensarchitektur, das eine formale und stark strukturierte Möglichkeit zum Anzeigen und Definieren eines Unternehmens bietet.

Das Framework wird verwendet, um architektonische "Artefakte" so zu organisieren, dass sowohl berücksichtigt wird, auf wen das Artefakt abzielt (z. B. Geschäftsinhaber und Builder) als auch welches bestimmte Problem (z. B. Daten und Funktionalität) behoben wird. Diese Artefakte können Konstruktionsdokumente, Spezifikationen und Modelle enthalten.

Das Zachman Framework wird häufig als Standardansatz zum Ausdrücken der Grundelemente der Unternehmensarchitektur bezeichnet . Das Zachman Framework wurde von der US-Bundesregierung als "... weltweit anerkannt als integriertes Framework für das Management von Veränderungen in Unternehmen und den Systemen, die sie unterstützen" anerkannt.

RM-ODP-Ansichten

Das RM-ODP- Ansichtsmodell, das fünf allgemeine und ergänzende Ansichten zum System und seiner Umgebung bietet.

Das ISO-Referenzmodell (International Organization for Standardization) für Open Distributed Processing ( RM-ODP ) legt eine Reihe von Gesichtspunkten für die Partitionierung des Entwurfs eines verteilten Software- / Hardwaresystems fest. Da die meisten Integrationsprobleme beim Entwurf solcher Systeme oder in sehr analogen Situationen auftreten, können sich diese Gesichtspunkte als nützlich erweisen, um Integrationsprobleme zu trennen. Die RMODP-Gesichtspunkte sind:

  • der Unternehmenssichtpunkt , der sich mit dem Zweck und Verhalten des Systems in Bezug auf das Geschäftsziel und die Geschäftsprozesse der Organisation befasst
  • der Informationsstandpunkt , der sich mit der Art der vom System verarbeiteten Informationen und den Einschränkungen bei der Verwendung und Interpretation dieser Informationen befasst
  • der rechnerische Gesichtspunkt , der sich mit der funktionalen Zerlegung des Systems in eine Reihe von Komponenten befasst, die ein bestimmtes Verhalten aufweisen und an Schnittstellen interagieren
  • der technische Standpunkt , der sich mit den Mechanismen und Funktionen befasst, die zur Unterstützung der Interaktionen der Rechenkomponenten erforderlich sind
  • der technologische Standpunkt , der sich mit der expliziten Auswahl von Technologien für die Implementierung des Systems und insbesondere für die Kommunikation zwischen den Komponenten befasst

RMODP definiert ferner eine Anforderung an ein Design, das Spezifikationen für die Konsistenz zwischen Gesichtspunkten enthält, einschließlich:

  • die Verwendung von Unternehmensobjekten und -prozessen bei der Definition von Informationseinheiten
  • die Verwendung von Unternehmensobjekten und -verhalten bei der Angabe des Verhaltens von Rechenkomponenten und die Verwendung der Informationseinheiten bei der Definition von Rechenschnittstellen
  • die Zuordnung von technischen Entscheidungen mit Rechenschnittstellen und Verhaltensanforderungen
  • die Erfüllung der Informations-, Rechen- und technischen Anforderungen in den ausgewählten Technologien

DoDAF-Ansichten

Das Department of Defense Architecture Framework (DoDAF) definiert eine Standardmethode zum Organisieren einer Unternehmensarchitektur (EA) oder Systemarchitektur in komplementären und konsistenten Ansichten. Es eignet sich besonders für große Systeme mit komplexen Integrations- und Interoperabilitätsproblemen und ist anscheinend einzigartig in der Verwendung von " Betriebsansichten ", die den Betriebsbereich des externen Kunden beschreiben, in dem das Entwicklungssystem betrieben wird.

DoDAF- Verknüpfungen zwischen Ansichten.

Das DoDAF definiert eine Reihe von Produkten, die als Mechanismen zum Visualisieren, Verstehen und Assimilieren des breiten Umfangs und der Komplexität einer Architekturbeschreibung durch grafische, tabellarische oder textuelle Mittel dienen. Diese Produkte sind in vier Ansichten unterteilt:

  • Übergreifende Gesamtansicht (AV),
  • Betriebsansicht (OV),
  • Systems View (SV) und die
  • Technische Standards (TV).

Jede Ansicht zeigt bestimmte Perspektiven einer Architektur, wie unten beschrieben. Für jede Systementwicklung wird normalerweise nur eine Teilmenge des vollständigen DoDAF-Viewset erstellt. Die Abbildung zeigt die Informationen, die die Betriebsansicht , die System- und Serviceansicht und die Ansicht für technische Standards verknüpfen . Die drei Ansichten und ihre Wechselbeziehungen, die von gemeinsamen Architekturdatenelementen bestimmt werden, bilden die Grundlage für die Ableitung von Maßnahmen wie Interoperabilität oder Leistung und für die Messung der Auswirkungen der Werte dieser Metriken auf die operative Mission und die Effektivität der Aufgaben.

Ansichten der Federal Enterprise Architecture

In der US-amerikanischen Federal Enterprise Architecture bieten Unternehmens-, Segment- und Lösungsarchitektur unterschiedliche Geschäftsperspektiven, indem sie den Detaillierungsgrad variieren und verwandte, aber unterschiedliche Anliegen berücksichtigen. So wie Unternehmen selbst hierarchisch organisiert sind, sind auch die unterschiedlichen Ansichten der einzelnen Architekturtypen organisiert. Die Federal Enterprise Architecture Practice Guidance (2006) hat drei Arten von Architektur definiert:

Ebenen und Attribute der Federal Enterprise Architecture
  • Unternehmensstruktur,
  • Segmentarchitektur und
  • Lösungsarchitektur.

Per Definition befasst sich Enterprise Architecture (EA) im Wesentlichen mit der Identifizierung gemeinsamer oder gemeinsam genutzter Assets - unabhängig davon, ob es sich um Strategien, Geschäftsprozesse, Investitionen, Daten, Systeme oder Technologien handelt. EA wird von der Strategie angetrieben; Es hilft einer Agentur zu erkennen, ob ihre Ressourcen richtig auf die Mission der Agentur und die strategischen Ziele ausgerichtet sind. Aus Investitionssicht wird EA verwendet, um Entscheidungen über das gesamte IT-Investitionsportfolio zu treffen. Folglich sind die Hauptakteure der EA die leitenden Angestellten und Führungskräfte, die sicherstellen sollen, dass die Agentur ihren Auftrag so effektiv und effizient wie möglich erfüllt.

Im Gegensatz dazu definiert die Segmentarchitektur eine einfache Roadmap für einen Kernbereich, einen Unternehmensdienst oder einen Unternehmensdienst. Die Segmentarchitektur wird von der Unternehmensführung bestimmt und liefert Produkte, die die Bereitstellung von Diensten für Bürger und Mitarbeiter von Agenturen verbessern. Aus Investitionssicht bestimmt die Segmentarchitektur Entscheidungen für einen Business Case oder eine Gruppe von Business Cases, die einen Kernauftragsbereich oder einen gemeinsamen oder gemeinsamen Service unterstützen. Die Hauptakteure für die Segmentarchitektur sind Geschäftsinhaber und Manager. Die Segmentarchitektur ist durch drei Prinzipien mit EA verbunden: Struktur, Wiederverwendung und Ausrichtung. Erstens erbt die Segmentarchitektur das vom EA verwendete Framework, obwohl es erweitert und spezialisiert werden kann, um die spezifischen Anforderungen eines Kernaufgabenbereichs oder eines gemeinsamen oder gemeinsam genutzten Dienstes zu erfüllen. Zweitens verwendet die Segmentarchitektur wichtige auf Unternehmensebene definierte Assets wieder, einschließlich: Daten; gemeinsame Geschäftsprozesse und Investitionen; und Anwendungen und Technologien. Drittens richtet sich die Segmentarchitektur nach den auf Unternehmensebene definierten Elementen wie Geschäftsstrategien, Mandaten, Standards und Leistungskennzahlen.

Nominale Ansichten

Auf der Suche nach "Framework for Modeling Space Systems Architectures" definierten Peter Shames und Joseph Skipper (2006) einen "nominalen Satz von Ansichten", abgeleitet von CCSDS RASDS, RM-ODP, ISO 10746 und konform mit IEEE 1471 .

Abbildung des "Nominal Set of Views".

Diese "Menge von Ansichten", wie unten beschrieben, ist eine Auflistung möglicher Modellierungsansichten. Nicht alle dieser Ansichten können für ein Projekt verwendet werden, und andere Ansichten können nach Bedarf definiert werden. Beachten Sie, dass für einige Analysen Elemente aus mehreren Blickwinkeln zu einer neuen Ansicht kombiniert werden können, möglicherweise unter Verwendung einer geschichteten Darstellung.

In einer letzteren Präsentation wurde dieser nominelle Satz von Ansichten als erweiterte Ableitung des semantischen RASDS-Informationsmodells vorgestellt. Hierbei steht RASDS für Reference Architecture for Space Data Systems. siehe zweites Bild

Enterprise Viewpoint
  • Organisationsansicht - Enthält Organisationselemente sowie deren Strukturen und Beziehungen. Kann Vereinbarungen, Verträge, Richtlinien und organisatorische Interaktionen enthalten.
  • Anforderungsansicht - Beschreibt die Anforderungen , Ziele und Vorgaben , die das System steuern. Sagt, was das System kann.
  • Szenarioansicht - Beschreibt die Art und Weise, wie das System verwendet werden soll, siehe Szenarioplanung . Enthält Benutzeransichten und Beschreibungen des erwarteten Verhaltens des Systems.
Informationsstandpunkt
  • Metamodellansicht - Eine abstrakte Ansicht, die Informationsmodellelemente sowie deren Strukturen und Beziehungen definiert. Definiert die Datenklassen, die vom System und der Datenarchitektur erstellt und verwaltet werden.
  • Informationsansicht - Beschreibt die tatsächlichen Daten und Informationen, wie sie im System realisiert und bearbeitet werden. Datenelemente werden in der Metamodellansicht definiert und in anderen Ansichten von Funktionsobjekten referenziert.
Referenzarchitektur für Weltraumdatensysteme.
Funktionaler Standpunkt
  • Funktionsdatenflussansicht - Eine abstrakte Ansicht, die die Funktionselemente im System, ihre Interaktionen, ihr Verhalten, die bereitgestellten Dienste, Einschränkungen und Datenflüsse zwischen ihnen beschreibt. Definiert, welche Funktionen das System ausführen kann, unabhängig davon, wie diese Funktionen tatsächlich implementiert sind.
  • Funktionssteuerungsansicht - Beschreibt die Steuerungsflüsse und Interaktionen zwischen Funktionselementen innerhalb des Systems. Beinhaltet Interaktionen zur Steuerung des Gesamtsystems, Interaktionen zwischen Steuerelementen und Sensor- / Effektorelementen sowie Verwaltungsinteraktionen.
Physischer Standpunkt
  • Datensystemansicht - Beschreibt Instrumente, Computer und Datenspeicherkomponenten, ihre Datensystemattribute und die im System verwendeten Kommunikationsverbinder (Busse, Netzwerke, Punkt-zu-Punkt-Verbindungen).
  • Telekommunikationsansicht - Beschreibt die Telekommunikationskomponenten (Antenne, Transceiver), ihre Attribute und ihre Anschlüsse (HF- oder optische Verbindungen).
  • Navigationsansicht - Beschreibt die Bewegung der Hauptelemente innerhalb des Systems (Flugbahn, Pfad, Umlaufbahn), einschließlich ihrer Interaktion mit externen Elementen und Kräften, die außerhalb der Kontrolle des Systems liegen, aber mit diesem modelliert werden müssen, um das Systemverhalten zu verstehen (Planeten, Asteroiden, Sonnendruck, Schwerkraft)
  • Strukturansicht - Beschreibt die Strukturkomponenten im System (S / C-Bus, Streben, Paneele, Gelenke), ihre physikalischen Eigenschaften und Verbinder sowie die relevanten strukturellen Aspekte anderer Komponenten (Masse, Steifheit, Befestigung).
  • Wärmeansicht - Beschreibt die aktiven und passiven Wärmekomponenten im System (Heizkörper, Kühler, Lüftungsschlitze) und deren Anschlüsse (physikalische Strahlung und Freiraumstrahlung) und Attribute sowie die thermischen Eigenschaften anderer Komponenten (dh Antenne als Sonnenschutz).
  • Leistungsansicht - Beschreibt die aktiven und passiven Leistungskomponenten im System (Solarmodule, Batterien, RTGs) im System und deren Anschlüsse sowie die Leistungseigenschaften anderer Komponenten (Datensystem und Antriebselemente als Leistungssenken und Strukturelemente als Erdung) Flugzeug)
  • Antriebsansicht - Beschreibt die aktiven und passiven Antriebskomponenten im System (Triebwerke, Kreisel, Motoren, Räder) innerhalb des Systems und ihrer Anschlüsse sowie die Antriebseigenschaften anderer Komponenten
MBED Top Level Ontologie basierend auf den nominalen Ansichten.
Technischer Standpunkt
  • Zuordnungsansicht - Beschreibt die Zuordnung von Funktionsobjekten zu technischen physischen und rechnerischen Komponenten innerhalb des Systems, ermöglicht eine Leistungsanalyse und wird zur Überprüfung der Erfüllung von Anforderungen verwendet
  • Softwareansicht - Beschreibt die Software-Engineering-Aspekte des Systems, das Software-Design und die Implementierung von Funktionen in Softwarekomponenten, wählt die zu verwendenden Sprachen und Bibliotheken aus, definiert APIs und entwickelt abstrakte Funktionsobjekte zu konkreten Softwareelementen. Einige Funktionselemente, die mit einer Softwaresprache beschrieben werden, können tatsächlich als Hardware (FPGA, ASIC) implementiert werden.
  • Hardware-Ansichten - Beschreibt die Hardware-Engineering-Aspekte des Systems, das Hardware-Design, die Auswahl und Implementierung aller physischen Komponenten, die in das System eingebaut werden sollen. Es kann viele dieser Ansichten geben, die jeweils für eine andere technische Disziplin spezifisch sind.
  • Kommunikationsprotokollansicht - Beschreibt das End-to-End-Design der Kommunikationsprotokolle und der zugehörigen Datentransport- und Datenverwaltungsdienste und zeigt die Protokollstapel, wie sie auf jeder der physischen Komponenten des Systems implementiert sind.
  • Risikoansicht - Beschreibt die mit dem Systemdesign, den Prozessen und Technologien verbundenen Risiken und weist anderen in der Architektur beschriebenen Elementen zusätzliche Risikobewertungsattribute zu
  • Ansicht Steuerungstechnik - Analysiert das System unter dem Gesichtspunkt seiner Steuerbarkeit, Zuordnung von Elementen zu einem System unter Steuerung und Steuerung
  • Integrations- und Testansicht - Betrachtet das System aus der Perspektive, was getan werden muss, um System- und Subsysteme sowie Baugruppen zusammenzubauen, zu integrieren und zu testen. Beinhaltet die Überprüfung der ordnungsgemäßen Funktionalität anhand von Szenarien, um die Anforderungen zu erfüllen.
  • IV & V-Ansicht - unabhängige Validierung und Überprüfung der Funktionalität und des ordnungsgemäßen Betriebs des Systems zur Erfüllung der Anforderungen. Entspricht das entworfene und entwickelte System den Zielen?
Technologischer Standpunkt
  • Standardansicht - Definiert die Standards, die beim Entwurf des Systems übernommen werden sollen (z. B. Kommunikationsprotokolle, Strahlungstoleranz, Löten). Dies sind im Wesentlichen Einschränkungen für die Entwurfs- und Implementierungsprozesse.
  • Infrastrukturansicht - Definiert die Infrastrukturelemente, die den Engineering-, Design- und Herstellungsprozess unterstützen sollen. Kann Datensystemelemente (Design-Repositories, Frameworks, Tools, Netzwerke) und Hardware-Elemente (Chipherstellung, Thermovakuumanlage, Maschinenwerkstatt, HF-Testlabor) enthalten.
  • Ansicht "Technologieentwicklung und -bewertung" - Enthält eine Beschreibung der Technologieentwicklungsprogramme, mit denen Algorithmen oder Komponenten erstellt werden können, die in einem Systementwicklungsprojekt enthalten sein können. Beinhaltet die Bewertung der Eigenschaften ausgewählter Hardware- und Softwarekomponenten, um festzustellen, ob sie sich in einem ausreichenden Reifegrad befinden, um für die zu entwerfende Mission übernommen zu werden.

Im Gegensatz zu den vorherigen aufgelisteten Ansichtsmodellen listet dieser "nominelle Satz von Ansichten" eine ganze Reihe von Ansichten auf, mit denen leistungsstarke und erweiterbare Ansätze zur Beschreibung einer allgemeinen Klasse softwareintensiver Systemarchitekturen entwickelt werden können.

Siehe auch

Verweise

Namensnennung

 Dieser Artikel enthält  gemeinfreies Material von der Website des National Institute of Standards and Technology ( https://www.nist.gov) .

Externe Links