5.  Traceability im Kontext von Viewpoints  52

5.1  Ursachen für die Einführung.  53

5.2  Zunehmende Notwendikeit für Traceability und Kommunikation.  53

5.3  Konzeptuelles (Referenz-) Tracemodell.  59

5.4  Klassifikation von Traceability-Links laut Ramesh  63

5.5  Traceability Techniken  64

5.6  Toolsupport.  76

6.  Casestudy.  81

Diskussion   85

Zusammenfassung   87

Anhang II   

Literaturverzeichnis.   XIV

III

Abbildungsverzeichnis   

Abb.1.  : Niveau und Arten von Views  6

Abb.2.  : Klassifikation von Viewpoints laut Leite  10

Abb.3.  : VORD-Prozessmodell  12

Abb.4.  : Viewpoints template laut Nuseibeh et al.  13

Abb.5.  : Elemente von Enterprise Architecture.  15

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

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

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

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

Abb.10.  : DoDAF Viewpoints.  26

Abb.11.  : Abstraktionsniveau  40

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

Abb.13.  : Viewpoints, Modellierungssprachen und deren Beziehungen  44

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

Abb.15.  : Viewpoints und Modellierungssprachen  47

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

Abb.17.  : UML Class Diagram.  50

Abb.18.  : Activity Diagram (Studentenaufnahme)  51

Abb.19.  : Verschiedene Typen von Traceability.  58

Abb.20.  : Traceability Metamodell  60

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

Abb.22.  : Submodell von Anforderungsmanagement  61

Abb.23.  : FORT-Prozess  67

Abb.24.  : Prozess von "capability engineering"  69

Abb.25.  : Case Traceability in Viewpoints  76

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

Abb.27.  : Traceability Matrix von einem Teil CLIX  82

Abb.28.  : Viewpoint resolution  VII

IV

Abb.29.  : Strategie „viewpoint resolution“  VII

Abb.30.  : Details in Design-Prozess.  VIII

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

Abb.32.  : VBRT-Methode.  IX

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

Abb.34.  : Event-Based Traceability  X

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

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

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

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

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

V

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

VI

Abkürzungsverzeichnis

ACM Association for Computing Machinery ADL ADM AOM API ARM Architecture Rationale Method C4ISR Command, Control, Communications, Computers, Intelligence, Surveillance und Recconnaissance CASE Computer-aided software engineering CDM ConMan CORE DM2 DoD DODAF DOORS DSL DXL EA Enterprise Architecture EAF Enterprise Architecture Framework EAI Architecture Enterprise Framework EBT ERM FA FORT Feature-Oriented Requirement Tracing GCT Goal Centric Traceability HB IA IBM International Business Machine IR Information Retrieval IREQ

IT LDM LSI Latent Semantic Indexing VII

MOF Meta Object Facility OCL Object Constraint Language OMG Object Management Group OO ID IEEE KEF NFA PES PR RM-ODP RSD requirement statement document RTOM SIG SQA SR TAFIM TM Traceability-Modell TM Traceability Matrix TOGAF UCD UML Unified Modeling Language VBRT VORD VSM

VWPI XML eXtensible Markup Language XPath XML Path Language VIII

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ä-

1

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.

2

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.

3

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. ¹ 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.

¹ Vgl. IEEE 1471 (2000): IEEE Recommended practice for architectural description of software-intensive systems - Description.

4

• 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. ² 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, In-standhaltung und Entwicklung von System. ³ Die Notwendigkeit von Verwendung von View bedingt durch:

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

³ Vgl.Garland, J.; Anthony R.:Large-Scale Software Architecture, John Willey&Sons Ltd.,Chichester 2003, S.2.

5

• 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

⁴ 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.

6

• 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 Spon-soren, Projektmanager, Analysten, Designers, Programmierer und End-User. Die Aufgabe von Traceability besteht in der Unterstützung der verschiedenen

⁵ Vgl. Ramesh, B.; Jarke, M.: Towards reference models for requirements traceability. In: IEEE Transactions on Software Engineering, Vol.27, No.1 2001, S. 58.

7

Interessen, Prioritäten und Zielen. Viele Probleme und Schwierigkeiten im Ausführen von Traceability liegen insbesondere in diesem Aspekt. ⁶ 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. ⁷ 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. ¹⁰ 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. ¹¹ Der Zusammenfluss der einzelnen Faktoren durch die Verteilung zwischen verschiedenen Gruppen, die

⁶ 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.

⁷ 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.

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

⁹ 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.

¹⁰ Vgl. Wright, S.: Requirements Traceability -What? Why? And How? In: IEE Colloqium, Computing and Control Division, Digest Number 1991/180, December 2, S. 1.

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

8

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.

9

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. ¹² Nächste Klassifikation basiert auf der Forschung von Leite. ¹³ 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.

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 Verhand-

¹² 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.

¹³ 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.

10

lungsprozess, 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 „View-point-oriented requirement definition method“ (VORD), wo es die Service zur potentiellen Benutzergruppe in Abb.3. behandelt werden. ¹⁴ 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

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

11

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

12

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. ¹⁵ 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. ¹⁶ 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:

¹⁵ 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.

¹⁶ Vgl. Sommerville, I.: Software Engineering, 8. Aufl., Addison-Wesley Publishers Limited 2007, S. 175.

13

• 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 Di-

14

mensionen in Framework ausgewählt, das Ziel und der Inhalt in Abb.5. ¹⁷ 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.

¹⁷ 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.

15