Viewpoints als Konzept zum nachhaltigen Traceability und Model Management in Enterprise Architecture E-Book
Roman Litvinov
36,99 €
Mehr erfahren.
- Herausgeber: GRIN Verlag
- Sprache: Deutsch
- Veröffentlichungsjahr: 2011
Diplomarbeit aus dem Jahr 2010 im Fachbereich Informatik - Wirtschaftsinformatik, Note: 2.6, Universität des Saarlandes, Sprache: Deutsch, Abstract: In der Realität ist es schwierig in der Vielfalt von den verschiedenen Frameworks zurechtzufinden. Oft fehlt dem Entwickler den gesamten Überblick über die Entwicklung von Software.Traceability hilft dabei alle Beziehungen vorwärts und rückwärts von der Spezifikation identifizieren, dokumentieren und speichern.Viewpoint als Spezifikation zeigt, dass die Integration in den heterogenen Systemen mit verschiedenen Komponenten. Dabei werden in einem UML-Diagramm die Beziehungen zwischen diesen Elementen gezeigt. Zur Betrachtung wegen ihrer Spezifität werden die nächsten EAF wie Zachmans, TOGAF, DODAF und Kruchtens genommen. Der weitere Schritt wird in die Richtung von der Identifizierung der Differenzen von Views in den ver-schiedenen Frameworks durchgeführt. Als Ergebnis wird eine Tabelle zusammengestellt, in der die verschiedenen Views von den angeführten Frameworks gegenübergestellt sind. Die Basis für die Tabelle werden die Viewpoints von Zachmans-Framework genommen.Bei der Benutzung von mehreren Viewpoints entstehen unvermeindlich die Inkonsistenzen. Diesen Aspekt als auch die falsche Auswahl von Viewpoint werden in Abschnitt „Problemen bei der Multi-Viewpoints Konzept“ diskutiert.In diesem Aspekt scheint es sehr interessant die Benutzung von Metamodell, das von OMG eingeführt wurde. Auf jedem von View werden gemäß diesem Modell die verschiedenen Arten von Modellierungssprachen definiert. In einem Metamodell werden die Zusammenhänge zwischen Konzepten, Notation, Modelle und Viewpoint definiert. Jedes Viewspoint wird durch die eigene Sprache ausgeprägt, ob es Enterprise, Informational, Computational, Engineering oder Technology Viewpoint sei. Dabei werden die verschiedenen Beispiele hinsichtlich jeder Viewpoints, welche Modellierungssprache von UML-Konzept verwendet werden können. Fünfter Abschnitt ist Traceability und seiner Rolle im Kontext von Viewpoints gewidmet.In der Praxis existiert man eine Reihe von Tools für die Realisierung von Traceability-Konzept, wobei Tools sowohl manuelle als auch automatische Me-thode unterstützen können. In der Arbeit werden einige von denen wie DOORS, Rational RequisitePro und Caliber RM betrachtet. In letzten Teil der Arbeit wird Case Study betrachtet.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Ähnliche
Page 5
Tabellenverzeichnis
Tab.1.: Vergleich von Viewpoints.................................................................... 30 Tab.2.: Prioritätsniveau und Klassifikation von Artefakten............................. 68 Tab.3.: Pre-RS Tracing Prozess........................................................................ 70 Tab.4.: Schritte und Aktivitäten für die Erstellung von Eigenschaftsmodellen. X
Page 6
Abkürzungsverzeichnis
ACM Association for Computing Machinery ADLADM AOMAPI ARM Architecture Rationale Method C4ISR Command, Control, Communications, Computers, Intelligence, Surveillance und Recconnaissance CASE Computer-aided software engineering CDMConMan COREDM2 DoDDODAF DOORSDSL DXL EA Enterprise Architecture EAF Enterprise Architecture Framework EAI Architecture Enterprise Framework EBTERM FA FORT Feature-Oriented Requirement Tracing GCT Goal Centric Traceability HBIA IBM International Business Machine IR Information Retrieval IREQ
IT LDM LSI Latent Semantic IndexingVII
Page 7
MOF Meta Object Facility OCL Object Constraint Language OMG Object Management Group OOID IEEE KEF NFA PES PRRM-ODP RSD requirement statement document RTOMSIG SQA SR TAFIM TM Traceability-Modell TM Traceability Matrix TOGAFUCD UML Unified Modeling Language VBRTVORD VSM
VWPI XML eXtensible Markup Language XPath XML Path LanguageVIII
Page 1
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 Frame-work (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ä-
Page 2
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 Fra-mework 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 ver-bunden ist.
Page 3
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 DO-DAF, 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.
Page 4
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.1Der 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.
1Vgl.IEEE 1471 (2000):IEEE Recommended practice for architectural description of software-intensive systems - Description.
Page 5
•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.2Zachmann 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, In-standhaltung und Entwicklung von System.3Die Notwendigkeit von Verwendung von View bedingt durch:
2The Open Group (2009):TOGAF Version 9. The Open Group architecture framework. http://www.opengroup.org. Abruf am 2010-05-05.
3Vgl.Garland,J.; Anthony R.:Large-ScaleSoftware Architecture, John Willey&Sons Ltd.,Chichester 2003, S.2.
Page 6
•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
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
4Vgl.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.
Page 7
• 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.
