Viewpoints als Konzept zum nachhaltigen Traceability und Model Management in Enterprise Architecture

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1. Einführung
1.1 Motivation
1.2 Problem definieren
1.3 Relevanz des Themas
1.4 Ziel der Arbeit
1.5 Organisation der These

2. Theoretischer Background
2.1 Viewpoints in Enterprise Architecture
2.2 Modellmanagement in Viewpoints
2.3 Traceability in Enterprise Architecture

3. Klassifikation und Standard von Viewpoints in Enterprise Architecture
3.1 Klassifikationen von Viewpoints
3.2 Konzeptueller Standard von IEEE 1471

4 Enterprise Architecture Frameworks
4.1 Viewpoint in Frameworks
4.1.1 Zachmann’s EAF
4.1.2 TOGAF
4.1.3 Kruchten’s 4+1 View Modell von Architektur
4.1.4 Department of Defense Architecture Framework (DoDAF)
4.2 Differenzen zwischen Konzepten von Views
4.3 Methoden für die Auswahl von Viewpoints
4.4 Problemen bei Multi-Viewpoints Konzept
4.5 Abstraktionsmethoden
4.6 Definieren von Modellierungssprachen

5. Traceability im Kontext von Viewpoints
5.1 Ursachen für die Einführung
5.2 Zunehmende Notwendikeit für Traceability und Kommunikation
5.3 Konzeptuelles (Referenz-) Tracemodell
5.4 Klassifikation von Traceability-Links laut Ramesh
5.5 Traceability Techniken
5.6 Toolsupport

6. Casestudy

Diskussion

Zusammenfassung

Anhang

Literaturverzeichnis

Abbildungsverzeichnis

Abb.1.: Niveau und Arten von Views

Abb.2.: Klassifikation von Viewpoints laut Leite

Abb.3.: VORD-Prozessmodell

Abb.4.: Viewpoints template laut Nuseibeh et al

Abb.5.: Elemente von Enterprise Architecture

Abb.6.: Konzeptuelles Framework von IEEE 1471-2000

Abb.7.: Zachmann's Framework für EA

Abb.8.: TOGAF Architecture Development Cycle (TOGAF specification)

Abb.9.: Kruchten's 4+1 View Model of Architecture

Abb.10.: DoDAF Viewpoints

Abb.11.: Abstraktionsniveau

Abb.12.: Four-level Metamodel Hierarchie von UML

Abb.13.: Viewpoints, Modellierungssprachen und deren Beziehungen

Abb.14.: Meta-Hierarchie von verschiedenen Modellen in Projekten

Abb.15.: Viewpoints und Modellierungssprachen

Abb.16.: UML Use Case von CLIX-Portal

Abb.17.: UML Class Diagram

Abb.18.: Activity Diagram (Studentenaufnahme)

Abb.19.: Verschiedene Typen von Traceability

Abb.20.: Traceability Metamodell

Abb.21.: "Low-end" Traceability Modell von Ramesh

Abb.22.: Submodell von Anforderungsmanagement

Abb.23.: FORT-Prozess

Abb.24.: Prozess von "capability engineering"

Abb.25.: Case Traceability in Viewpoints

Abb.26.: Integration von Tools, um Traceability zu erfüllen

Abb.27.: Traceability Matrix von einem Teil CLIX

Abb.28.: Viewpoint resolution

Abb.29.: Strategie „viewpoint resolution“

Abb.30.: Details in Design-Prozess

Abb.31.: Meta-Modell von Traceability mit Typen von Traceability-Links

Abb.32.: VBRT-Methode

Abb.33.: Meta-Modell von FORT (Ahn und Chong)

Abb.34.: Event-Based Traceability

Abb.35.: Prozess von CGT laut Cleland-Huang

Abb.36.: Traceability Rule-Based Methode laut Spanoudakis

Abb.37.: TraceM Konzeptuelles Framework laut Sherba et al.

Abb.38.: Architecture Rationale Model laut Tang und Han

Abb.39.: Architecture Decomposition with AR laut Tang und Han

Tabellenverzeichnis

Tab.1.: Vergleich von Viewpoints

Tab.2.: Prioritätsniveau und Klassifikation von Artefakten

Tab.3.: Pre-RS Tracing Prozess

Tab.4.: Schritte und Aktivitäten für die Erstellung von Eigenschaftsmodellen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einführung

Heutzutage Softwaresysteme werden als kritischer Bestandteil des Unternehmens. Die zentrale Rolle bei der Planung und Implementierung von komplexen Systemen spielt dabei die Verwendung von Viewpoints. Der Begriff „View“ wurde im Kontext von Software Architektur von Zachmann in seinem „Zachmann Framework“ in 1970 eingeführt.

1.1 Motivation

In der Ära steigender Information ist es unmöglich die Komplexität oder Änderungen von Prozessen oder Anforderungen im Unternehmen ohne Einbeziehung von Enterprise Architecture (EA) aufzunehmen. Die Softwarearchitektur dient als Entwurf für das Projekt von System. Architecture Enterprise Framework (EAI) kann die grundlegende Infrastruktur für die Hardware, Software und Netzwerk beschreiben und wie die zusammenwirken. Dabei gestaltet jedes Anspruchsperson, das in das Projekt involviert ist, seine eigene Aussicht, ob er Design-Entwickler oder End-User. Er fokussiert auf das Problem von seiner Perspektive mittels spezifischen Modellen und Methoden. Viewpoint definiert das ganze Konzept von Software-Entwicklung, die Notation und der technischer Support auf verschiedenes Abstraktionsniveau. Es existiert zurzeit eine Menge von Frameworks, die spezifischer oder standardmäßiger Charakter aufweisen und in Projekt einbezogen werden können. Die Unterschiede und Ähnlichkeiten werden im Rahmen der Arbeit kurz vorgestellt.

Jede Ansicht stellt in Form von Modellen dar. Die Möglichkeiten von Menschen die ganze Komplexität auf einmal umzufassen sind begrenzt. Deshalb ist es sinnvoll das ganzes Konzept durch Abgrenzung auf eine Reihe von den kleinen Views dividieren. Die Modellbildung ist eine von den geprüften und allgemein anerkannten Techniken, die das Verständnis von der Komplexität von System während der Entwicklungsphase erleichtern. Die Einführung von Abstraktionsniveau erlaubt dem Entwickler auf spezielle Aspekte von System zu fokussieren und die Information bezüglich der spezifischen Notation und der Aussichtspunkten von Anspruchspersonen zu übermitteln.

Es kann passieren, dass es notwendig bei der Änderung von Prioritäten oder Zielen des Unternehmens oder wegen der obsoleten Technologie die entsprechenden Anpassungen in Softwaresysteme zu machen. Dabei spielt die Analyse von Veränderungen und Abhängigkeiten zwischen Artefakten, die während des Projektes wie Spezifikationen, Testen, Textbeschreibungen usw., mittels Traceability die zentrale Rolle. Traceability von Software Artefakten wurde als einer der wichtigsten Faktor für die Unterstützung von verschiedenen Aktivitäten in der Software Systementwicklung identifiziert. Im Allgemeinen das Ziel von Traceability ist die Verbesserung von Qualität von Softwaresystem. Im Besonderen Information von Traceability kann die Analyse von auftretenden Auswirkunken und Integration von Veränderungen unterstützen und auch während der Wartung und Evolution des Systems, Aktualisierung von Komponenten, Identifizierung von Alternativen und der Vergleich mit der Anforderungen usw.

1.2 Problem definieren

Seit der Einführung des ersten Konzeptes von Frameworks entstanden eine Reihe von anderen, deren Ziel war es, kontinuierliche Entwicklung des Softwareprojektes zu gewährleisten. Es ist schwierig wegen der Vielfalt von Framework in einzelnen Konzepten zurechtzufinden. Diese Arbeit stellt eine kurze Anweisung dafür bereit, aus welchen Viewpoints jedes einzelne Framework besteht. Außerdem bei der Umgestaltung des Systems, bei der veralteten Technologie ist es nötig, die entsprechenden Anpassungen durchzuführen. Dabei verliert Designer den Überblick über die Relationen und Abhängigkeiten zwischen den Artefakten, wenn das Konzept von Software Engineering nicht hinreichend dokumentiert wurde. An dieser Stelle scheint die Anwendung von Traceability als eine von wichtigsten Faktoren für die Unterstützung von verschiedenen Aktivitäten in der Software Systementwicklung.

1.3 Relevanz des Themas

Es ist klar, dass die Modelle die Kommunikation und das Verständnis des ganzes Konzeptes des Unternehmens erleichtern und machen es möglich, alle Geschäftsprozesse und Abhängigkeiten auf verschiedene Abstraktionsniveau zu dokumentieren.

Die Aufgabe von komplexen Softwaresystemen besteht in der Verfolgung von vorgenommen Veränderungen, um ihren Wert für das Unternehmen beizubehalten. Die Entscheidung hinsichtlich Designs sollten unter unklaren Bedingungen treffen, weil die Konsequenzen von verschiedenen Alternativen nicht genau festgelegt können. An dieser Stelle Traceability hilft die richtige Entscheidungen zu treffen, das Risiko von Inkonsistenzen zu minimieren, und Analyse bei der Auswirkungen von Veränderungen durchzuführen trotz der Meinung, dass es mit der Verschwendung von Zeit und Kostenaufwänden verbunden ist.

1.4 Ziel der Arbeit

Die Hauptidee dieser Arbeit enthält die Identifikation von Differenzen und Ähnlichkeiten zwischen einigen Frameworks. Es gehört auch dazu, welche Modellierungsmethoden und -sprachen an jedem View vorhanden sind und wie die zusammen agieren. Dann wird über die Methodologie und Formen von Traceability und warum ist es wichtig von Anfang des Projektes es einzuführen.

1.5 Organisation der These

Diese Arbeit wird im Folgenden strukturiert:

- Kapitel 2 beschreibt der theoretische Teil der Arbeit: grundlegende Begriffe und Konzepte, die in der These verwendet werden, um den Rest von der Studie zu verstehen.
- Kapitel 3 gibt den Ausblick über vorhandene Arten und Klassifikationen von Viewpoints in EA. Darüber hinaus werden Frameworks DODAF, RM-ODP usw. und Differenzen in der Auswahl von Viewpoints in diesen Konzepten des näheren betrachtet. Das Potenzial der Zahl existierender zurzeit Framework wird damit nicht ausgeschöpft. Des Weiteren werden Kriterien für die Wahl von passenden Viewpoints kurz vorgestellt. Es wird darüber diskutiert, welche Abstraktionsmethoden und Modellierungssprachen für die einzelne View ausgewählt werden können.
- Kapitel 4 beschäftigt sich mit solchen Methode als Traceability im Kontext von Softwareentwicklung. Warum ist es wichtig es von Anfang des Projektes einzuführen und welcher Nutzen daraus herausziehen kann? Es wird danach konzeptuelles Traceability-Modell vermittelt. Es folgenden Traceability-Methodologie und Techniken. Es stellt sich damit die Frage, ob es überhaupt möglich und mit welchem Toolsupport den Prozess von Traceability automatisch zu machen.
- Kapitel 5 gibt das kurze Beispiel mit welchen Methoden es in einem Unternehmen Traceability auf allen Abstraktionsniveau verwirklichen kann.
- In Kapitel 6 wird Case Study über die Integration von Tools vorgestellt, um die komplette Traceability auf allen Viewpoints durchzuführen.
- Danach folgt kurze Diskussion über ausgearbeitete Studie und alle wichtigen Aspekte werden zusammengefasst.

2. Theoretischer Background

Während der Softwareentwicklung es ist zu beachten auf eine Vielzahl von Aspekten sowie welche Modellierungssprachen verwendet werden, welche Hardware müssen konfiguriert werden, mit welchen anderen Systemen es agiert. Die Modellierung von allen diesen Aspekten durch einzelne Modelle ergibt ein komplexes Modell, das kaum nützlich ist. Eine bessere Herangehensweise besteht darin, das ganze System in einzelne Module zu dividieren unter der Benutzung von Abstraktionskriterien. Als Beispiel für solche Art von Abstraktion ist Viewpoints. Mit der Nutzung von diesen Abstraktionskriterien ist möglich, von allen irrelevanten Aspekten zu abstrahieren und eine Reihe von zusammenhängenden Aspekten herauszuheben, was macht das Verständnis von der Komplexität leichter und verbessert die Flexibilität von diesen Modellen.

Bevor wir dem Konzept von Frameworks und der Zielen von Viewpoints näherkommen, werden im Weiteren die grundlegenden Begriffe genau festgelegt. In diesem Teil der Arbeit werden die grundlegenden Begriffe definiert, die mit ausgewählter Thematik verbunden sind.

2.1 Viewpoints in Enterprise Architecture

Der Begriff EA ist nicht immer deutlich festzusetzen. In den meisten Fällen fokussiert er auf Geschäftsprozesse und Softwareentwicklung. Im Allgemeinen EA kann beschrieben werden als der Prozess der Entwicklung eines Unternehmens, wo die einzelnen Objekte stark bezogen untereinander einschließlich materielle und immaterielle Dinge wie Informationen oder Projektziele.

EA ist eine vereinfachte Repräsentation von den grundlegenden Struktur und Organisation von Unternehmen. Sie ist ein Plan, der die Grundzüge und Charakteristik und Struktur einer Organisation beschreibt. Es wurde von Institute of Electrical und Electronic Engineers (IEEE) so genannte “Recommended Practice for Architectural Description of Software-Intensive Systems” eingeführt.^[1] Der Standard schließt die Definitionen als Architekt, Interessengruppen, Architektur, View und Viewpoints von Architektur ein. Die Richtlinie definiert die folgende Schlüsselbegriffe als:

- System ist die Zusammenstellung von Komponenten, das die spezifische Funktionen oder eine Reihe von Funktionen ausführt.
- Architektur ist die fundamentale Organisation von System mit ihren Komponenten, ihren Beziehungen zueinander und zu der Umgebung sowie eine Liste von Prinzipen, die den Entwurf und die Entwicklung von System bestimmen.
- View ist eine Darstellung des gesamten Systems aus der Perspektive der Anspruchsperson. Darüber hinaus ist View aus mehreren Modellen zusammengestellt. In diesem Zusammenhang kann Viewpoint als Standard oder eine Vorlage für die Entwicklung von View sein.

The Open Group (2003) gibt die nächste Definition:

- EA setzt sich aus verschiedenen Elementen und deren Beziehungen in allen Bereichen EA wie Business, Daten, Applikationen und Technologie zusammen.^[2]

Zachmann bezeichnet EA als:

- Eine Reihe von zusammenhängenden Artefakten, deren Ziel ist es, das ganze System oder Unternehmen zu beschreiben betreffend seiner Konsturktion, Wartung und der weiteren Entwicklung.

Aus den vorangegangenen Begriffen in unserem Kontext man folgt, dass EA eine Struktur und Beziehungen der vorhandenen Komponenten von verschiedenen Perspektiven einschließt.

Diese Richtlinie gibt auch die Definition von EA als die Zusammensetzung von Viewpoints jeder einzelnen Interessengruppe, die in das Projekt involviert ist. Jedes Viewpoint ist mit View verbunden. A View ist eine Darstellung von dem ganzen System aus der Perspektive von stakeholder auf den einzelnen Aspekt. Diese Methode benutzt man in mehreren Frameworks als Zachmann, RM-ODP, TOGAF usw. Als Beispiel das System kann nicht nur von der Sicht von Design, Implementierung sondern von der Stand einzelnen Personen oder involvierten Systemen beschrieben werden. Diese Methode ist insbesondere effektiv wo gibt es eine Menge von Artefakten und Beziehungen zwischen denen. Aus diesen Begriffen folgt, dass die Aufgabe von Viewpoint sich mit der Komplexität des Systems bewältigen.

Laut Garland, Views von Architektur stellen die Darstellung von der Architektur, die für Konstruktion, Untersuchung, Leitung, Training von Personal, Testen und Ausführung anderen technischen Zielen, bezogen auf Erstellung, Instandhaltung und Entwicklung von System.^[3] Die Notwendigkeit von Verwendung von View bedingt durch:

- Die Dokumentation von Anfang des Projektes und nachhaltige Verbesserung der Entwicklung.
- Gewährleistung von Beachtung aller Beschränkungen und der Spezifität des Projektes.
- Tracking über durchlaufenden Änderungen und Einführungen neuer Artefakten.
- Unterstützung von Kommunikation in allen Phasen des Projektes usw.

2.2 Modellmanagement in Viewpoints

Abbildung in dieser Leseprobe nicht enthalten

Ein Modell Abb.1. ist eine Darstellung eines Teils der realen Welt durch eine bestimmte Repräsentation (z.B. textuelle Beschreibung, Diagrammen usw.) ^[4] Auf diese Weise bezeichnet das Modell alle relevanten Aspekte des Systems. Andersrum gesagt, es vereinfacht, vernachlässigt und abstrahiert Irrelevantes. In Software Entwicklung kann als Bsp. dafür UML-Modell verwendet werden. Zu den Aufgaben von Modellmanagement gehören u.a.:

Verwaltung von der Modelle:

- Das Schaffung von Repositories
- Aufbau von Bibliotheken
- Klassifikation von (Teil-) Modellen und Modellelementen
- Überwachung neuer Modelle und Spezifikationen

Modellqualität & Modellintegration

- Bewertung von Modellen
- Gewährleistung von Konsistenz zwischen Modellen

Modelltransformation oder so genannte mappings

- Umwandlung eines Modells in ein anderes (z. B. Code-Erstellung)

Modellmanagement fasst somit alle Modellelemente durch Strukturierung durch Pakete und gewährleistet besseres Verständnis durch Analyse von Systemausschnitten und Teilsystemen. Modell-Management dient auch dazu, eine mächtige Entwicklungsumgebung zur Verfügung zu stellen in solchen Gebieten, wie Datenintegration, Software-Engineering oder Netzwerk-Modellierung. Aber die grundlegende Idee hinter Modell-Management is es, eine Reihe von Konstrukten zur Änderung von Modellen und Transformation bereitzustellen. Es wird dadurch eine Minderung von Entwicklungsaufwand gewährleitet. Als Beispiel dafür sind solche Konstrukts wie match, merge, compose, extract usw.

2.3 Traceability in Enterprise Architecture

Der Begriff Traceability wurde im Kontext von Requirements Traceability in den 1970er Jahren eingeführt, um die Abweichungen zwischen des tatsächlichen Softwareverhalten und den Kundenforderungen zu vermeiden. Software Traceability ist ein entscheidender kritischer Erfolgsfaktor von der Softwareentwicklung. Während der Evolution des Projektes tauchen eine Menge von Produkten, Artefakten und die Relationen zwischen denen auf. Eine von Aufgaben von Traceability besteht in der Überwachung von der Änderung der Beziehungen zwischen diesen Artefakten und der Dokumentation aller einbezogenen Spezifikationen. IEEE(1994) bezeichnete Traceability als:

- Die Möglichkeit von Software das bestimmte Grad der Beziehungen zwischen Artefakten bereitzustellen, insbesondere für die Komponenten, die Beziehungen als Vorgänger-Nachfolger oder Haupt-Untergeordnet haben.

Ramesh und Jarke definieren der Begriff wie:

- Die Charakteristik von einem System, in dem die Anforderungen eindeutig mit ihren Quellen und den Artefakten, die während der Entwicklung von System erstellt wurden, verbunden sind. Als Beispiel, das Lastenheft kann Business Anforderung, Benutzeranfrage, Regeln, Spezifikation zu den Schnittstellen, Standards zu anderen Quellen einschließen.^[5]

In den Projekt werden Vielzahl von Interessengruppen involviert, sowie Sponsoren, Projektmanager, Analysten, Designers, Programmierer und End-User. Die Aufgabe von Traceability besteht in der Unterstützung der verschiedenen Interessen, Prioritäten und Zielen. Viele Probleme und Schwierigkeiten im Ausführen von Traceability liegen insbesondere in diesem Aspekt.^[6]

Gotel und Finkestein bezeichneten die Definition als:

- Die Fähigkeit, um eine Anforderung in beiden Richtungen, vorwärts und rückwärts, zu beschreiben und verfolgen, über ihre Entwicklung und Spezifikation zu ihrer anschließenden Entwicklung und Einsatz und über kontinuierliche Verbesserung in jede Phase von Lebenszyklus.^[7]

Edwards und Howell geben die Definition als:

- Traceability garantiert die Unterstützung von Beziehungen zwischen der Anforderungsspezifikation, Design und der endgültigen Implementierung.^[8]

Laut Spanoudakis und Zisman Traceability ist die Fähigkeit die entstandenen während der Entwicklung des Systems Artefakten zu verfolgen, um das gesamte System von verschiedenen Perspektiven und Niveaus von Abstraktion zu allen Interessengruppen zu beschreiben.^[9]

In anderer Interpretation Wrigt schreibt, dass mittels requirements traceability Softwareentwickler kann die Anforderungen von Kunden nachprüfen und ob das System ganz die Anforderungen erfüllt oder ob es keine unnötige Bestandteile oder Funktionalitäten in System vorhanden sind.^[10]

Der Nutzen von der Verwendung von Software Traceability (ST) liegt in der besseren Nachprüfung und Validierung der Kundenanforderung, niedrigeren Wartungskosten und besserer Einschätzung von der Softwarequalität. Außerdem es unterstützt die folgenden Aktivitäten als das Verständnis des Systems, Analyse von Auswirkungen, Fehlerbehebung und Kommunikation zwischen Entwickler und Kunden.

Trotz aller Vorteile ist es nicht so leicht eine vollständige Nachprüfung durch alle Phasen der Softwareentwicklung durchzuführen.^[11] Der Zusammenfluss der einzelnen Faktoren durch die Verteilung zwischen verschiedenen Gruppen, die Heterogenität von Artefakten und verwendeten Tool, die schnelle Änderung der Eigenschaften von Komponenten stellt die große Herausforderung für Traceability Management. Die Artefakte sind durch die unterschiedlichen Gruppen verteilt und deswegen schwerzugänglich sind. Wegen der Heterogenität es ist schwer, durch mehrere Formate und Abstraktionsniveau Traceability durchzuführen. Mangelnde Interoperabilität von Toolsupport macht es schwierig die Repräsentation von Linken darzustellen. Da Beziehungen zwischen Komponenten sich ständig ändern, werden sie schnell obsolet. Dies alles trägt zu den hohen Kosten für die Unterstützung von Traceability bei. Zuletzt ist es der Mangel vom angemessenen Toolsupport für die Ermittlung und Aufrechterhaltung der Abhängigkeiten zwischen Prozess Design und Implementierung.

3. Klassifikation und Standard von Viewpoints in Enterprise Architecture

3.1 Klassifikationen von Viewpoints

Software System besteht aus einer Reihe von komplexen Teilen. Laut Leite es besteht aus Managerial, Organisazional und Computional Aspekten und setzt eine Vielzahl von verschiedenen Ressourcen (Menschen, Software, Hardware, Spezifikationen usw.) in Abb.2. ein.^[12] Nächste Klassifikation basiert auf der Forschung von Leite.^[13] In seiner Recherche der Autor klassifizierte der Einsatz von Viewpoints in drei orthogonale Richtungen, Viewpoints als eine Stellungnahme, Services und Spezifikation. Viewpoint als Services stellt als ein wichtiger Ausgangspunkt für die Erhebung von Daten und die Modellierung von Kundenanforderung dar. Viewpoint als Spezifikation zeigt, dass die Integration unter heterogenen Teilen in komplexen Systemen eine wesentliche Herausforderung sein kann.

Abbildung in dieser Leseprobe nicht enthalten

Viewpoint als eine Stellungsnahme:

Die Software Engineering umfasst eine Menge von Akteure, die in das Projekt involviert sind. Sie haben eigene Sicht auf das System. Aber diese Perspektive sind nur zum Teil komplett oder hat unvollständige Beschreibung des ganzen Systems. Von daher die Integration von verschiedenen Sichten kann zum Verständnis des ganzen Konzeptes beitragen. Die Methodik vergleicht verschiedene Sichten von einer Ausgangssituation und teilweise unterstützt den Verhandlungsprozess, um verschiedene Meinungen in Einklang zu bringen. Es existiert eine Menge von Vorteilen in dieser frühen Phase von Projektplanung. Es können die möglichen Streitfragen während des Entwicklungsprozesses behandelt werden, eine von denen die Validierung bei der Kreation von Anforderungskatalog. Konfliktinteressen können früher in der Entwicklung identifiziert werden.

Viewpoint als Services:

Eine von den Aufgaben von Softwaresystem besteht darin, automatische Unterstützung zur Erfüllung der Ziele, wo es früher den Prozess manuell ausgeführt war. Als Beispiel dafür führt Leite das Prinzip von Ambulanz an. Es betrachtet in der Studie von Kotonya und Sommerville die Method von „Viewpoint-oriented requirement definition method“ (VORD), wo es die Service zur potentiellen Benutzergruppe in Abb.3. behandelt werden.^[14] In diesem Konzept die Entwicklung von System schließt ins Projekt alle Interessengruppen mit verschiedenen Sichten. Die Methode stellt explizit die Identifikation von allen relevanten Entitäten bereit und gibt eine Reihe von Viewpoint-Klassen. Dadurch setzt es eine Menge von Entscheidungsregeln voraus, um den Prozess des Customizing von Viewpoint zu einem bestimmten System durchzuführen. Gemäß der Methode VORD kann zu weitem Spektrum angewendet werden, von der textuellen Beschreibungen zu der formalen Sprache. Die Hauptidee liegt in der Verbesserung von Kommunikation zwischen den Benutzer und Softwareentwickler. Laut der Autoren basiert die Diskussion nämlich auf drei iterativen Aspekten:

- Strukturierung und Identifikation von Viewpoint.
- Dokumentation von Viewpoint.
- Erstellung von Spezifikation und Anforderungsanalyse.

Die Abbildung zeigt die Reihenfolge vom Prozess. Der erste Schritt beginnt mit der Identifizierung von relevanten Viewpoints im Bereich vom Problembereich, der analysiert werden sollte, und der seinerseits mit seiner Strukturierung ist verbunden. Der Ausgangspunkt für die Identifizierung von Viewpoints ist die abstrakte Stellungsnahme von dem organisatorischen Bedarf und das Abstract von verwendeten Viewpoint-Klassen. Der zweite Schritt fokussiert auf das Problem von Dokumentation. Viewpoints-Dokumentation besteht aus der Name von Viewpoint, Anforderung, Beschränkungen zu Anforderungen und zu den Quellen. Zu der Viewpoint-Anforderung gehören unter anderem eine Reihe von Services, Kontrollmechanismen und nicht funktionale Anforderungen. Dritter Schritt befasst sich mit der Spezifikation von funktionalen und nicht funktionalen Anforderungen in der angemessenen Form. Die entsprechende Notation variiert von der natürlichen Sprache bis formale und strukturierte Notation.

Viewpoints und seine Anforderungen werden in das zentrale Repository. Es dient als Input zu den Anforderungs- und Bedarfsanalyse. Die Zielvorgabe von Prozessanalyse ist eine Grundlage für die Korrektheit von der Dokumentation zu schaffen und mögliche Konflikte von Anforderung zwischen allen Viewpoints aufzudecken.

Die aufgeführte Methodik fokussiert auf die Unternehmens- und Organisationsaspekte. Laut Kotonya und Sommerville die Prozesse von Softwareentwicklung konzentrieren sich vielmehr auf Benutzerprobleme als die organisatorischen Aspekte, was zu der unvollständigen Softwareanforderung führt. Um das entstandene Problem zu lösen, es wurde von ihnen der Begriff „indirekte Viewpoints“ eingeführt, die mit organisatorischen, bezogenen auf Services, Aspekten integrieren, aber nicht unmittelbar mit ihnen interagiert.

Viewpoint als Spezifikation:

Software Engineering fordert die exakte Zusammenarbeit von verschiedenen Komponenten als Software, Hardware, Mapping von Software, Kommunikationssschnittstelle usw. Somit die Spezifikation soll angemessen diese Menge, die aus verschiedenen Fragmenten besteht, unterstützen. Im Ergebnis die endgültige Spezifikation soll alle Vielfalt von Methoden umfassen. Das Problem von Softwareentwicklung steigt immer bei der Vergrößerung von der Komplexität auf. Die Notation wird in verschiedenen Anforderungssprachen und an individuelle Stufe repräsentiert. Viele von Methoden werden nachher überprüft. In diesem Zusammenhang scheint die Arbeit von Nuseibeh et al. in Abb.4. sehr interessant zu sein.^[15] In seiner Studie wurde die Integration von heterogenen Komponenten diskutiert. Es wurde ein Framework entwickelt, das partiell representation knowledge, development process knowledge und specification knowledge einkapselt. An dieser Stelle soll Framework diese Fragmente, präsentiert als Viewpoint, zu der eindeutigen Spezifikation integrieren. Es kann der Durchführung, Organisation von Softwareentwicklung helfen, um spezifisches Template zur Speicherung von verschiedenen Viewpoints anzubieten.

Laut der Autoren die starke Seite von Framework ist die Fähigkeit verschiedene Komponente zu integrieren. Es kann die Relation zwischen Fragmenten von

Spezifikationen darstellen und nachprüfen, die mittels mehreren Methoden und Notationen erstellt wurden. Nuseibeh sieht den positiven Aspekt bei der Einführung von diesem Framework in dem, dass die Repräsentation, Entwicklung und Spezifikation in jedem von View eingekapselt sind. Dies erleichtert sowie das lokale Management als auch die Distribution von Komponenten. Der weitere Vorteil besteht darin, dass die Komponenten von System in verschiedenen Entwicklungsphasen eingesetzt werden können.

Sommerville identifiziert Viewpoint-orientierte Analysis als die Methode für die Betrachtung von System bei mehreren Perspektiven. Es garantiert das frühere Entdecken von Konflikten zwischen verschiedenen Interessenbeteiligten.^[16] Viewpoints können als eine Herangehensweise für Klassifikation von stakeholders und anderen Quellen von der Softwareanforderung sein. Sommerville gliedert Viewpoints auf drei generische Typen:

- Interagierte Akteure stellen eine Gruppe von Menschen oder andere Systemen dar, die indirekt mit dem System interagieren. In dem einfachen Banksystem es kann z.B. eine Interaktion von einem Kunden mit der Datenbank des Bankkontos.
- Indirekte Viewpoints präsentieren stakeholder, wer benutzt das System nicht direkt, aber er beeinflusst ebenfalls die Systemanforderung. Als Beispiel dafür können das Bankmanagement und der Sicherheitsdienst.
- Domain viewpoints präsentieren Charakteristik von Domain und Beschränkungen, die auf die Softwareanforderung einwirken. Im Banksystem es könnte als Bsp. ein Standard für die Kommunikation unter Banken sein.

Typescherweise diese Viewpoints garantieren die Differenz von Anforderungstypen. Interagierte Viewpoints stellen die detaillierte Systemanforderung für die Eigenschaften von System und seine Schnittstelle dar. Indirekte Viewpoints dienen eher zur Ermittlung von organisationaler Anforderungen und Beschränkungen auf höheren der Ebene. Und Domain Viewpoints gewährleisten Domain Beschränkungen des Systems.

Laut Sommerville es ist schwer von Anfang an alle relevanten für das System Viewpoints zu identifizieren. Um diesen Prozess zu erleichtern, ist mehr spezifische Viewpoints-Typen zu definieren:

- Anbieter von Services für das System und Empfänger von Services.
- Systemen, die mittels Schnittstellen zu System, interagiert werden müssen.
- Regeln und Standards für das System.
- Andere Quellen von sowohl geschäftliche als auch nichtfunktionale Systemanforderungen
- Technische Viewpoints bezeichnen die Anforderungen von Menschen, die das System entwickeln, verwalten und instandhalten müssen.
- Marketing und andere Viewpoints, die Produktanforderungen und seine Eigenschaften entwickeln und auf welche Weise das System soll externes Image von der Organisation wiederspiegeln.

Fast alle Softwaresysteme interagieren mit anderen Systemen der Organisation. Aus diesem Grund bei der Planung der neuen Systems müssen weitere Interaktionen entworfen werden. Die Schnittstellen von anderen Systemen bei der Definition von Viewpoints sind auch zu bestimmen, weil es die Konfiguration des neuen Systems beeinflussen könnte. Andererseits die neuen Systeme sollen den existierenden Regeln und Standards anpassen und dies seinerseits beschränkt die Softwareanforderung.

Um das richtige Viewpoint auszuwählen, es wurde von Steen et al. die Definition und Klassifikation von Viewpoints durchgeführt. Dafür wurden zwei Dimensionen in Framework ausgewählt, das Ziel und der Inhalt in Abb.5.^[17] Die folgenden Typen von der Softwarearchitektur definieren diese Dimensionen:

- Designing: Design-Viewpoint unterstützt Designer und Architekten in der Entwicklung von Prozessdesign vom ersten Entwurf bis zu detailliertes Design. Typischerweise Design-Viewpoint setzt sich aus Diagrammen wie z.B. UML zusammen.
- Deciding: Es unterstützt Manager im Prozess von Entscheidung wie bei dem Entwurf oder bei der Erstellung von Modellen mittels analytischen Techniken. Als Bsp. dafür sind Querverweise-Tabelle, Listen oder Berichten.

Informing: die Methode hilft allen Beteiligten das Konzept von Softwarearchitektur zu verstehen. Bsp. dafür sind Illustrationen, Animationen, Flyer.

Das Ziel von dieser Klassifikation laut Steen ist es, den Entwicklern und anderen Beteiligten bei der Suche nach einem passenden Viewpoint zu unterstützen. Mit dem aufgeführten Framework ist es möglich, ein typisches Viewpoint zu finden.

3.2 Konzeptueller Standard von IEEE 1471-2000

In 2000 the IEEE Computer Society etablierte Standard 1471-2000. Er stellt als eine solide theoretische Grundlage für die Definition, Analyse und Beschreibung der Architektur von Softwaresystemen, View, Viewpoints, Architekturmodell, Kommunikation und den Vergleich von verschiedenen Architekturen. Der Standard fokussiert hauptsächlich auf softwareintensive Systeme wie z.B. Informationssystem, so genannte „embedded systems“ und gemischte aus mehreren Komponenten bestehende Systeme. In seinem Konzept Standard IEEE 1471 standardisiert nicht den ganzen Prozess von der Softwareentwicklung und deswegen normiert nicht Modellierungssprachen, Methodologie oder Standards. Stattdessen stellt der Standard als „recommende practice“ mit einer Reihe von Konzepten und Vorgaben bereit.

In IEEE 1471 Views nehmen die zentrale Stelle in der Dokumentation von Softwarearchitektur. Die Architektur schließt ein oder mehrere Views in Abb.6. ein.^[18] In diesem Framework konzentriert der Schwerpunkt auf View oder Viewpoints. Viewpoints sind mit den spezifischen Interessen aller Beteiligten im System verbunden und bestehen aus den nächsten Komponenten:

- Das System hat eine Architektur.
- Eine Architektur kann bei einer oder mehreren Architekturbeschreibungen definiert werden.
- Dazu gehören eine in den Projekt involvierten Gruppe von Menschen, View, Viewpoints, Modellen und Meinungen.
- Eine Anspruchsperson hat ein oder mehreren Meinung.
- Eine Meinung hat die Relation zu einem oder mehreren Anspruchspersonen.
- Ein Viewpoint umfasst eine oder mehrere Meinungen und Anspruchspersonen.
- Ein View gehört zu einem Viewpoint.
- Ein Viewpoint definiert die Methode für das Modell.
- Ein View hat ein oder mehrere Modelle und ein Modell ist ein Teil von einem oder mehreren Views.

IEEE 1471 stellt eine Reihe von relevanten Viewpoints von Softwarearchitektur mit ihren Spezifikationen als Meinungen, Modellierungssprachen, Modellen und Analysemethoden.

Obwohl IEEE Standard nicht ideal ist, stellt er die konsequente Vorgehensweise für die Einführung von EA. Er beantwortet auch die Frage, auf welche Weise kann man die meisten Probleme bei der Entwicklung von Software vermeiden.

Abbildung in dieser Leseprobe nicht enthalten

Abb.6.: Konzeptuelles Framework von IEEE 1471-2000

IEEE 1471 unterscheidet die nächsten Viewpoints:

- Business Architecture View. Hier werden die Stellungnahmen von Anspruchspersonen und den Ablauf von Business Informationen zwischen allen im Projekt beteiligten Personen und Business Prozessen betrachtet.
- Data Architecture View. An dieser Stelle steigt die Bedeutung von Datenbanken der Entwicklern, Designer, die für die Weiterentwicklung und Integration von verschiedenen Systemkomponenten relevant sind.
- Applications Architecture View reguliert das Verhalten von Softwareentwickler und deren Person, die für die Entwicklung und Integration der Applikationen von verschiedenen Softwarekomponenten verantwortlich sind.
- Technology Architecture View ist für die Systemadministratoren und Systemmanager, die für die Komposition von Soft- und Hardware im System verantwortlich sind.

4 Enterprise Architecture Frameworks

Die Softwarearchitektur spielt die wesentliche Rolle in der Entwicklung von Enterprise Architecture Framework (EAF). Dazu gehören unter anderem die Anforderungsanalyse, Softwaredesign, Entwicklung und Hardwarekonfiguration. Die Aufgabe von Architektur in diesem Zusammenhang besteht in der systematischen Analyse und Design, um ein einheitliches Konzept für die Entwicklung von Informationssystemen (IA) bereitzustellen. EAF bieten dafür das Verständnis für die kontinuierliche Herangehensweise von IA und stellt das konzeptuelle Instrument für die Entwicklung von EA bereit. Frameworks stellen Design von Prototyp dar, die auf allgemeine Vorgehensweise und Best Practices basieren. EAF ist nicht nur die Architektur, sondern das Konzept von Modellen, Prinzipen, Services, Methoden, Standards, Design-Konzept, Komponenten und Konfigurationen, die als Richtlinie für die Entwicklung von spezifischen Aspekten von System sind.

Es wurde eine Vielzahl von Framework eingeführt. Einige von denen sind für die interne Nutzung für die Realisierung spezifischer Zielen geeignet und andere werden für die Etablierung von Standards eingesetzt. Die Mehrheit wurde für die spezielle Domain (kritische Einsatzgebiete oder IT der großen Organisationen) entwickelt.^[19] Der Fokus der anderen hängt von der Art von Information (Typen von Modellen oder Daten) ab, die für die Dokumentation von Architektur notwendig sind. Andere sind strategisch orientiert oder basieren auf Referenzmodellen und Standardtechnologie. Die Aufgabe von EAF liegt unter anderem in der Identifizierung von existierenden Artefakten in der Organisation wie strategische Ziele, Normen, Standards.^[20] Im Unternehmen gibt es explizit bereit existierende Prinzipen und Strategien. EAF unterstützt dabei bei der Abbildung expliziter und impliziter Architektur. Zu den Vorteilen von EAF im Kontext von der Einführung von Viewpoints gehören die nächsten als:

- Sie geben den einheitlichen Überblick und das Verständnis von der Organisation (Akteure, Rollen, Regeln, Ziele, Vorgänge usw.)
- Optimierung von Geschäftsprozessen während der Strukturierung.
- Beseitigung von Duplikaten und bessere Unterstützung bei der Entscheidung
- Überführung von strategischen Zielen zur endgültigen Implementierung.^[21]

Der Kernpunkt der Einführung von Framework-Konzept ist das Bestreben alle Fachkenntnissen und Potentialen von Unternehmen wie Informationstechnologie (IT) (Datenbank-Technologie, Kommunikation-Technologie) oder organisatorische Aufgaben (Business Process Reengineering und Workflow Redesign) zusammenzufassen. Es ist zu beachten, dass IS mehr als eine traditionelle Technologie (z.B. Middleware für Datenbanken), Standard für die Benutzeroberfläche usw. Der Prozess der Integration ist mit höheren Kosten und menschlichen Ressourcen verbunden. Der Vorteil von IS ist dabei eine Verbesserung von Verfügbarkeit der Information und Einrichtung von einheitlichen Standards im Unternehmen. Der Begriff Framework ist hier als die Voraussetzung, Konzept, Best Practices angesehen.

4.1 Viewpoint in Frameworks

EAF benutzen im Allgemeinen Viewpoints für die Erstellung von Views, die verschiedenen Perspektive von System wie Business-, Informations-, Software- und technische Architektur in der Form von Modellen darstellen. Mit der Einführung von den neuen Technologie und Software-Applikationen Frameworks werden mehr komplexer als zuvor. Andererseits die eigene Struktur von Organisationen entwickelt sich rapid. Aus diesem Grund die Verwendung von mehreren Viewpoints bei der Entwicklung von Softwarearchitektur ist unabdingbar. Es existieren sowohl einfache Formen von Frameworks als auch die Frameworks mit spezifischen Zielen. Dabei die Einführung von Viewpoints macht es möglich, die spezifischen Informationen in konkreten Views zu positionieren. Jedes View stellt eine eigene Perspektive von System dar. Außerdem betrachtet man die Viewpoints als die Unterstützung von der Konsistenz von den zusammenhängenden Informationen. Im Weiteren wird über den wichtigsten Aspekt als Traceability diskutiert, weil jedes Framework die entsprechenden Instrumente und Techniken dafür bereitstellt. Auch hilft dabei die Möglichkeit der Integration von verschiedenen Tools. In der Realität die Vielzahl von Organisationen die eigenen Frameworks mit ihren spezifischen Viewpoints entwickeln. Zu bekannten Frameworks gehören unter anderem Zachmann Framework (Sowa & Zachmann, 1992), DoDAF (Department of Defense architechture framework) Architecture Methodology (DoD, 2003), TOGAF (The Open Group Architecture Framework, 2005) usw. Jedes Framework hat die eigene Methodologie, die aus der Philosophie der Softwareentwicklung besteht. Außerdem, um den Prozess der Entwicklung zu unterstützen, stellt das Framework die verschiedenen Tools, Modelle und Methode bereit.

4.1.1 Zachmann’s EAF

EAF war in 1980 von Zachmann als der Klassifikationsentwurf das Konzept für die Organisation von Beschreibungsmethoden (Modelle, Bilder, Diagrammen oder textuelle Dokumentation) vorgeschlagen. Er schrieb in seiner Arbeit „To keep the business from disintegrating, the concept of informations systems architechture is becoming less of an option and more of a necessity”.^[22] Das Zachmann Framework ist eine generische Klassifikation für Designergebnisse.^[23]

Die Idee von Framework besteht darin, dass der Entwickler einer Richtlinie zufolge mit einer Komplexität von EA bewältigen könnte. Darüber hinaus gibt das Framework die Möglichkeit die Isolation von einzigen Aspekten, um die Fehler und Störungen nicht weiter das gesamte System beeinträchtigen können. Diese Zerteilung ist einer wichtiger Standpunkt, weil wie vorher gesagt, der Mensch nicht die ganze System mit seiner Komplexität auf einmal wahrnehmen kann. Framework hat zwei Dimensionen: Perspektiven und Aspekten. Das Ziel war der Aufbau und das Verständnis des Konzeptes, in dem die verschiedenen Typen von Modellen mit ihren Artefakten in Abb.7. vorhanden sind.^[24] Es gibt keine feste Anleitung an die Reihenfolge von Prozessen. Das Prinzip liegt in guter Organisation und in der Sicherstellung deutlicher Beziehungen und der Vollständigkeit von allen Aspekten. Es war festgestellt, dass keine IS-Architektur, sondern eine Reihe von solchen Architekturen existiert. Im Kontext von der Arbeit sind von Interesse die Perspektiven oder Viewpoints. Sie werden sich als „Planner“, „Owner“, „Designer“, „Builder“, „Subcontractor“ und „Functioning Enterprise“definiert. Diese Personen und ihre Interessen stellen ihrerseits die Anforderungen zum System.

- Planner (Scope) Darstellung ist eine Repräsentation von der Größe, Form und Umfang des Systems.
- Owner View (Business Modell) beschreibt die die Zielen von Systemen.

Die letzten zwei Perspektive dienen zur Identifizierung von Wiederverwendbarkeit der Alternativen in der Organisation. Sie sind als das Fundament für die

weitere Entwicklung. Auch es ist eine gute Möglichkeit für den Business Expert im Plan die nötigen Prioritäten zu identifizieren.

- Designer (Information) bezeichnet Datenmodellierung, Applikations-, Interfacearchitektur, Business Regeln.
- Builder View (Technology Model) ist eine von Designer View Adaptation, um die vorhandene Technologie und Anforderungen zu integrieren.
- Subcontractor (Detaillierte Beschreibung) ist noch kein Endprodukt, aber die Teile von Fertigkomponenten von der ganzen Struktur. Diese Sicht orientiert sich eher auf aktuelle Implementierung von Aktivitäten.

Die Perspektiven sind sehr abstrakt definiert und werden schrittweise oben detailliert beschrieben und mehr spezifisch auf der unteren Ebene bis zur Implementierung.^[25] Schekerman glaubt, dass verschiedene Frameworks zur Erstellung von EA verwendet werden können. Ein Framework wird zur Entwicklung von der technischen Architektur und anderes in abteilungsintern Netzwerk implementiert. Im Weiteren kann man für die Entwicklung und Organisation der Konfiguration von der einzelnen unabhängigen Workstation identifizieren. Jede Perspektive oder Viewpoints stellt sich eine Reihe von Anforderungen dar. Sie können additiv zugefügt werden und sollen konsistent mit anderen Modellen sein. In dieser Hinsicht Designer sollen alle Inkonsistenzen zwischen verschiedenen Repräsentationen bei Bedarf korrigiert werden.

Framework umfasst sowohl die technischen Detaille, als auch eine Reihe von Listen, Chart-Diagrammen und die natürlichen Sprachen. Hier werden alle passende Methode, Standard, Techniken oder Toolsupport benutzt. Framework kann tatsächlich als Tool für die Organisation von Metadaten im Unternehmen verwendet werden.

Es benutzt bei der Entwicklung von Softwaresystem traditionell bottom-up View.^[26] Es ist erforderlich von Anfang an das System in bottom-row anschauen. Von diesem Punkt ist mittels neuer Technology oder der automatischen oder manuellen Tools das existierende System zu verbessern. Danach soll der Fokus auf die Perspektive „Designer“ mit weiterer Konzentration auf „Builder“ und „Subcontracter“ liegen. Dabei es ist verschiedene Technologie für die Verbesserung zu verwenden. Diese Methode ist ganz technisch betrachtet. In der Realität es ist schwer „Owner“- oder „Planner“- Perspektive in den Prozess einzuschließen. Trotz aller Beschränkungen gilt das Framework als eine Grundlage für die Erstellung von anderen Konzepten.

[...]

---

^[1] Vgl. IEEE 1471 (2000): IEEE Recommended practice for architectural description of

software-intensive systems – Description.

^[2] The Open Group (2009): TOGAF Version 9. The Open Group architecture framework. http://www.opengroup.org. Abruf am 2010-05-05.

^[3] Vgl. Garland, J.; Anthony R.: Large-Scale Software Architecture, John Willey&Sons

Ltd.,Chichester 2003, S.2.

^[4] Vgl. Desmond, D.: Model-Driven Architecture and Integration. Opportunities and Challenges. www.catalysis.org/publications/papers/2001-mda-reqs-desmond-6.pdf.

Abruf am 2010-05-12.

^[5] Vgl. Ramesh, B.; Jarke, M.: Towards reference models for requirements traceability. In: IEEE

Transactions on Software Engineering, Vol.27, No.1 2001, S. 58.

^[6] Vgl. Ramesh, B.; Edwards M.: Issues in the development of a requirements traceability mod el. In: Proceeding of the International Conference on Requirements Engineering (1993),S. 256.

^[7] Vgl. Gotel, O.; Finkelstein, A.: An Analysis of the requirements traceability problem. In: Proceedings of the First International Conference on requirements engineering (1994), S. 94.

^[8] Vgl. Edwards, M.; Howell, S.: A methodology for systems requirements specification and traceability for large real-time complex systems (1991), S. 3-7.

^[9] Vgl. Spanoudakis, G.; Zisman, A.: Software Traceability: A Roadmap Advances in Software

Engineering and Knowledge Engineering, Chang S.K., 3 Aufl., Word Scientific Publishing 2005, S. 395.

^[10] Vgl. Wright, S.: Requirements Traceability –What? Why? And How? In: IEE Colloqium,

Computing and Control Division, Digest Number 1991/180, December 2, S. 1.

^[11] Vgl. Asuncion, H.; Taylor, R.: Establishing the Connection between Software Traceability and Data Provenance. In: ISR Technical Report#UCI-ISR-07-09, S. 5.

^[12] Vgl. Leite, J.C.S.D et al.: The world’s a stage: a survey on requirements engineering using a

real-case study, S. 17.

^[13] Vgl. Leite, J.C.S.D. et al: Viewpoints on Viewpoints, Joint Proceedings of the SIGSOFT’96

Workshops, The Association for Computing Machinery (ACM) 1996, S. 285.

^[14] Vgl. Kotonya, G.;Sommerville, I.: Requirements Engineering with Viewpoints, Technical Report CSEG/10/1995, CSEG Computing Department, University of Lancaster, S. 7.

^[15] Vgl. Nuseibeh, B. et al: A framework for expressing the relationships between multiple views in requirements specifications, IEEE Transactions on Software Engineering, 20(10) 1994, S. 760.

^[16] Vgl. Sommerville, I.: Software Engineering, 8. Aufl., Addison-Wesley Publishers Limited

2007, S. 175.

^[17] Vgl. Steen, et al.: Supporting Viewpoint-Oriented Enterprise Architecture. Proc. 8th IEEE International Enterprise Distributed Object Computing Conference (EDOC’04), Monte rey,California, September, S. 20.

^[18] Vgl. IEEE Std 1471-2000: IEEE Recommended Practice for Architectural Description of

Software-Intensive Systems-Description, S. 8.

^[19] Vgl. Scheckerman, J.: How to survive in the jungle of Enterprise Architecture Frameworks,

Trafford, 6 Aufl. 2004, S. 86.

^[20] Vgl. Van den Berg, M.; Steenbergen, M.: Building an Enterprise Architecture Practice. Tool, Tips, Best Practices, Springer 2006, S. 48.

^[21] Vgl. Halpin, T. et al.: Enterprise Architecture. Creating Value by Informed Governance, Springer-Verlag, Berlin Heidelberg 2009, S. 42.

^[22] Vgl. Zachmann, J.: http://www.zifa.com, Abruf am 2010-05-11.

^[23] Vgl. Masak, D.: Der Architekturreview. Vorgehensweise, Konzepte und Praktiken, Springer-Verlag Berlin Heidelberg 2010, S. 168.

^[24] Vgl. The Zachman Framework™: The Official Concise Definition,

http://www.zach-maninternational.com/index.php/the-zachman-framework,

Abruf am 2010-05-10.

^[25] Vgl. Scheckerman, J.: How to survive in the jungle of Enterprise Architecture Frameworks, Trafford, 6 Aufl. 2004, S. 135.

^[26] Vgl. Finkelstein, C.: Enterprise Architecture for Integration. Rapid Delivery Methods and Technologies, Artech House 2006, S. 6.