Beurteiler / Beurteilerin Ass.-Prof. Dipl.-Ing. Dr. Ein

Eingereicht von Harald Krump, BSc Angefertigt am Institut für Wirtschaftsinformatik - Software Engineering Beurteiler / Beurteilerin Ass.-Prof. Dipl.-Ing. Dr. Rainer Weinreich Mitbetreuung Stefan Haselböck, MSc September 2017

Ein Werkzeug für das Review-gestützte Erstellen von Software Architekturwissen

Masterarbeit zur Erlangung des akademischen Grades

Master of Science im Masterstudium

Wirtschaftsinformatik

25. Oktober 2017 Harald Krump 2/78

EIDESSTATTLICHE ERKLÄRUNG

Ich erkläre an Eides statt, dass ich die vorliegende Masterarbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht habe. Die vorliegende Masterarbeit ist mit dem elektronisch übermittelten Textdokument identisch. Ort, Datum Unterschrift


Kurzfassung

Architekturwissen wird meist aus Erfahrung und Fachwissen aufgebaut. Um dieses implizite Wissen, das sich in den Köpfen der Architekten beziehungswiese der Stakeholder befindet, in explizites, für alle zugängliches, Wissen umzuwandeln, ist es von Vorteil, ein Wissensmanagementwerkzeug einzusetzen. Ein wesentlicher Vorteil eines Wissensmanagementwerkzeugs ist die Transformation des impliziten Wissens eines Architekten in explizites Wissen. Entscheidungen welche von Architekten getroffen wurden, müssen auch für andere nachvollziehbar dokumentiert werden. Dafür ist es notwendig, dass bei jeder Entscheidung eine sinnvolle Begründung hinterlegt wird. Eine wichtige Aufgabe für die Sicherstellung der Qualität von explizitem Architekturwissen ist das Review des gespeicherten Architekturwissens. Um Architekturwissen mit einem Reviewprozess zu unterstützen, bedingt es den Einsatz eines Werkzeugs für Review-gestütztes Erstellen von Software Architekturwissen. Deswegen beschäftigt sich diese Arbeit mit der Umsetzung eines Werkzeugs, welches die Architekten bei der Erstellung von Software Architekturwissen unterstützt und zusätzlich einen Reviewprozess für die Validierung des erstellten Wissens anbietet. Das Hauptaugenmerk bei der Entwicklung galt der Erfassung und dem Review von Architekturwissen auf Basis einer grafischen Notation dieses Wissens.


Abstract

Architectural knowledge is something gained by experience and deep technical expertise. In order to convert the implicit knowledge of the software architects and stakeholders into explicit knowledge that is available to a broad group of people, it is very beneficial to use a knowledge management system. The main advantage of such a knowledge management system is the exact transformation from implicit knowledge of the experts into explicit knowledge. Decisions made by the architect have to be documented comprehensively and reproducible. It is therefore necessary to enrich each decision with a useful justification. An important part of assuring a high level of quality of explicit architectural knowledge is to review the stored architectural knowledge. In order to support the architectural design with a review process, a review-based architectural knowledge tool is necessary. This work investigates the implementation of such a tool, supporting the software architect in designing and creating software architectural knowledge and introducing a review process to validate and assure the quality of the created architectural knowledge. The main focus of the developed tool was the acquisition of architectural knowledge in the form of a graphical notation. In addition, a review process was implemented, which is also based on the representation of architectural knowledge using the implemented graphical notation.


Inhaltsverzeichnis 1. Einleitung ................................................................................................................................ 7

1.1. Ziel ................................................................................................................................... 7 1.2. Aufbau der Arbeit ............................................................................................................. 7

2. Begriffe und Grundlagen ........................................................................................................ 8 2.1. Softwarearchitektur .......................................................................................................... 8

2.1.1. Architekturwissen .................................................................................................... 9 2.1.2. Architekturwissensmanagement ........................................................................... 10 2.1.3. Architekturentscheidungen ................................................................................... 13 2.1.4. Metamodell für Microservice Entscheidungsmodelle .......................................... 14

2.2. Reviews ......................................................................................................................... 16 2.2.1. Klassifikation von Reviews ...................................................................................... 17 2.2.2. Anwendungsbereiche von Reviews ........................................................................ 20 2.2.3. Teilnehmer zum Review motivieren ........................................................................ 25

3. Werkzeug aus Nutzersicht .................................................................................................... 28 3.1. Grundkonzepte .............................................................................................................. 28 3.2. Review Prozess ............................................................................................................. 28 3.3. Verwalten der Entscheidungsmodelle ............................................................................ 33

3.3.1. Menü-Reiter ........................................................................................................... 34 3.3.2. Suchen nach Entscheidungsmodellen ................................................................. 36 3.3.3. Filtern nach Kategorien ......................................................................................... 37 3.3.4. Zuweisung eines Reviews für ein Entscheidungsmodell .................................... 38 3.3.5. Berichtsgenerierung eines Reviews ..................................................................... 39 3.3.6. Erstellen eines Entscheidungsmodells ................................................................ 39 3.3.7. Löschen von Entscheidungsmodellen .................................................................. 40

3.4. Review von Entscheidungsmodellen ............................................................................. 40 3.4.1. Elemente einem Entscheidungsmodell hinzufügen ............................................ 40 3.4.2. Elemente editieren ................................................................................................. 42 3.4.3. Element ändern ..................................................................................................... 43 3.4.4. Element löschen .................................................................................................... 43 3.4.5. Elemente kommentieren ....................................................................................... 43 3.4.6. Beziehung zwischen Elementen erstellen ........................................................... 43 3.4.7. Beziehung zwischen Entscheidungsmodellen erstellen ..................................... 43 3.4.8. Beziehung zwischen Elementen löschen ............................................................. 43 3.4.9. Kommentieren eines Entscheidungsmodells ....................................................... 44 3.4.10. Änderungshistorie ................................................................................................. 44 3.4.11. Anzeige des Referenzmodells .............................................................................. 45

4. Softwarearchitektur und Implementierungsaspekte ............................................................. 46 4.1. Verwendete Technologien ............................................................................................. 46

4.1.1. Spring Framework ................................................................................................... 46 4.1.2. Neo4j ....................................................................................................................... 47 4.1.3. Swagger .................................................................................................................. 48 4.1.4. AngularJS 1.5 .......................................................................................................... 49 4.1.5. VisJS ....................................................................................................................... 50

4.2. Datenmodell ................................................................................................................... 52 4.3. Backend ......................................................................................................................... 55


4.4. Frontend ......................................................................................................................... 58 4.4.1. Tab-Container ......................................................................................................... 58 4.4.2. Filter ......................................................................................................................... 60 4.4.3. Visualisierung .......................................................................................................... 63 4.4.4. Logaufzeichnungen ................................................................................................. 66 4.4.5. Reviewzuweisung .................................................................................................... 67 4.4.6. Review ..................................................................................................................... 67

5. Zusammenfassung ............................................................................................................... 69 5.1. Fazit ............................................................................................................................... 69 5.2. Ausblick .......................................................................................................................... 69


1. Einleitung

Die Architektur eines Softwaresystems ist eines der wichtigsten Konzepte der Softwareentwicklung (Weinreich und Buchgeher 2009). Sie gehört zu den ersten Artefakten, die in der Entwicklung produziert werden und enthält frühe und langlebige Designentscheidungen. Ein späterer Wechsel der Architektur während der Entwicklung wird meist sehr kostenintensiv. Dazu hat sich im letzten Jahrzehnt die Sicht auf die Softwarearchitektur erheblich erweitert (Weinreich und Groher 2016). Während Softwarearchitektur in früheren Arbeiten als die Strukturen eines Softwaresystems und ihre nach außen sichtbaren Eigenschaften (Leath und Ollanik 1983; Miller, Wade und Wallis 1984) definiert wurde, wird sie in jüngeren Arbeiten als die Summe der Designentscheidungen und deren Begründungen gesehen (Jansen und Bosch 2005). Ansätze zum Erfassen und Dokumentieren von Designentscheidungen werden im Architekturwissensmanagement behandelt. Davenport und Prusak (Davenport und Prusak 1998) beschreiben Wissensmanagement als einen Prozess der die gemeinsame Nutzung, Verbreitung, Erstellung, Erfassung und das Verständnis des Wissens eines Unternehmens vereinfacht. Diesen Prozess bezeichnet Dalkir (Dalkir 2011) als Wissensmanagement-Zyklus mit den Aktivitäten Wissenserfassung, Wissensaustausch, Wissensverbreitung, Wissenserwerb und Wissensanwendung. Um diesen Wissensmanagement-Zyklus zu unterstützen, bietet sich der Einsatz von Reviews als Methode zur Überprüfung und Verfeinerung des erfassten Wissens an. Reviews haben nach Masak (Masak 2009) das Hauptziel, Fehler aufzuspüren und eine Bewertung für einen Gegenstand abzugeben. Damit können die Schritte Wissenserfassung, Wissensaustausch und Wissensverbreitung unterstützt werden.

1.1. Ziel

Das Ziel dieser Arbeit ist die Entwicklung eines Werkzeugs für das Review-gestützte Erstellen von Software Architekturwissen, wobei der Fokus auf Entscheidungsmodellen für Microservice-Architekturen liegt. In einem Forschungsprojekt des Instituts für Wirtschaftsinformatik – Software Engineering werden aktuell solche Modelle in Kooperation mit Firmen erstellt (Haselböck, Weinreich und Buchgeher 2017a; Haselböck, Weinreich und Buchgeher 2017b). Diese Modelle sollen mit einem Review-basierten Verfahren validiert werden. Das zu erstellende Werkzeug soll es ermöglichen, neues Software Architekturwissen mit einer grafischen Notation zu erfassen und dieses über ein Review-basiertes Verfahren von unterschiedlichen Stakeholdern validieren zu lassen.

1.2. Aufbau der Arbeit

In Kapitel 2 werden Begriffe und Grundlagen definiert, die für das Verständnis der Arbeit wichtig sind. Wichtige Begriffe die in diesem Kapitel vorgestellt und diskutiert werden sind Softwarearchitektur, Architekturwissen und Review. In Kapitel 3 werden die Grundkonzepte und der eingesetzte Reviewprozess für das entwickelte Werkzeug vorgestellt. Auf Grundlage dieses Prozesses wird die Funktionalität des Werkzeugs aus Nutzersicht vorgestellt, wobei der Fokus auf der Erfüllung Einsatzszenarien liegt. In Kapitel 4 werden die Architektur des entwickelten Werkzeugs und ausgewählte Aspekte der Implementierung vorgestellt. Kapitel 5 enthält ein Fazit und einen Ausblick auf mögliche Erweiterungen des Werkzeugs.


2. Begriffe und Grundlagen

Dieses Kapitel erklärt und diskutiert grundlegende Konzepte und Begriffe, welche von Relevanz für diese Arbeit sind und zum besseren Verständnis des realisierten Ansatzes beitragen. Im ersten Teil dieses Kapitels werden die wichtigsten Begriffe und Grundlagen im Bereich Softwarearchitektur behandelt. Dabei werden vor allem auch zugehörige Konzepte, wie das Architekturwissensmanagement vorgestellt. Im zweiten Teil dieses Kapitels werden Grundlagen, Klassifizierung und Anwendungsgebiete von Reviews beschrieben. Neben den wesentlichen Eigenschaften eines Reviews werden unterschiedliche Arten von Reviews vorgestellt.

2.1. Softwarearchitektur

Für den Begriff Softwarearchitektur, gibt es kein einheitliches, präzises Begriffsverständnis, Taylor, Medvidovic und Dashofy (Taylor, Medvidovic und Dashofy 2009) definieren Softwarearchitektur wie folgt: „A software system's architecture is the set of principal design decisions made about the system.“ (Taylor, Medvidovic und Dashofy 2009) Diese Definition beschreibt eine Softwarearchitektur als die Menge der wichtigsten Entwurfsentscheidungen, die im Rahmen des Systementwurfs getroffen werden. Dabei können Designentscheidungen auch aus Details, wie Algorithmen oder Datenstrukturen, bestehen. Eine andere Definition liefern Wolf und Perry (Wolf und Perry 1992) und zwar dass eine Softwarearchitektur aus einem mathematischen Tripel besteht: „Architecture = {elements, form, rationale}“ (Wolf und Perry 1992) Die Architektur beschreibt hierbei die wichtigsten Systemelemente und deren Beziehungen zueinander und zu deren Umwelt. Qualitätsattribute beantworten die „Wofür“-Fragen für eine Architektur. Die Form repräsentiert die Beziehungen der individuellen Elemente und hilft bei der Beantwortung der „Wie“-Fragen an eine Architektur. Schließlich liefern die Begründungen die Absichten, die Annahmen, die durchdachten Auswahlen und alle anderen Informationen die nicht klar auf der Hand liegen, die dennoch wichtig sind, für eine Architektur. Die Begründungen sollen die „Warum“-Fragen für eine Architektur beantworten. Im Buch „Software-Architektur“ von (Vogel u. a. 2009) wird beschrieben, dass eine Software-Architektur auf den ersten Blick, im Gegensatz zu physisch greifbaren Dingen, wie Gebäuden oder Wohnräumen, nicht unmittelbar ersichtlich wird. Jedoch benötigt jedes Software-System eine Architektur. Die Softwarearchitektur wird durch Regeln, die aufgrund von Anforderungen definiert wurden, gestaltet. Eine weitere Definition findet sich im (ISO/IEC/IEEE 42010 2011) und definiert eine Architektur wie folgt: „Its fundamental organization–embodied in its components and their relationships to each other and their environment.“ (ISO/IEC/IEEE 42010 2011)


Diese Definition definiert zeigt jedoch, dass die Elemente und deren Beziehungen im Mittelpunkt stehen. Architektur ist also im Zusammenhang mit Software schwer greifbar. Unter dem Begriff „Architektur“ selbst versteht man die Struktur eines Bauwerks oder eines Software-Systems, und unter dem Begriff Architekturdesign die vom Menschen ausgeführte Tätigkeit zum Entwurf dieser Struktur.

2.1.1. Architekturwissen

Architekturwissen gliedert sich laut Nonaka und Takeuchi (Nonaka und Takeuchi 1995) in implizites Wissen, explizites Wissen, anwendungsorientiertes und anwendungsspezifisches Wissen. Das implizite Wissen wurde vom Architekten beziehungswiese anderen Stakeholder aus Erfahrung und Fachwissen aufgebaut. Das explizite Wissen hingegen ist die Produktion und Kodifizierung von Artefakten wie einer Architekturbeschreibung. Lago und Avgeriou (Lago und Avgeriou 2006) beschreiben die Unterschiede zwischen anwendungsorientierten und anwendungsspezifischen Architektur-Kenntnissen. Das anwendungsorientierte Wissen ist eine Form des Bibliothekswissens, das in mehreren Anwendungen unabhängig der Domäne angewendet werden kann. Das anwendungsspezifische Wissen beinhaltet alle Entscheidungen, die während des Architektur-Prozesses eines bestimmten Systems und der Architektur-Lösungen getroffen wurden. Fahrenhorst und Boer (Farenhorst und Boer 2009) unterteilen das Architekturwissen in vier Hauptansichten um den Gebrauch und die Bedeutung zu verstehen. Diese vier Ansichten sind: ! Musterorientiert

Die Katalogisierung von Entwurfsmustern brachte die Software-Ingenieure dazu, bewährte Lösungen für wiederkehrende Probleme zu dokumentieren. Entwurfsmuster in der Softwareentwicklung dienen zwei Zwecken und zwar erstens als wiederverwendbare Lösungen, die auf wiederkehrende Probleme angewendet werden können, und zweitens als Vokabular, das einen gemeinsamen Bezugsrahmen bietet, was das Teilen des Architekturwissens zwischen den Entwicklern erleichtert. Entwurfsmuster unterliegen keiner Standardvorlage, obwohl sie in der Regel nach bestimmten Vorlagen dokumentiert werden.

! Dynamisch-orientiert

Ein formalerer Ansatz für Architekturwissen findet sich bei den dynamisch-orientierten Softwarearchitekturen. Solche Systeme können ihre Architektur während der Laufzeit dynamisch anpassen. So können beispielsweise ohne manuelles Eingreifen oder Herunterfahren Upgrades durchgeführt werden. Dynamische Systeme müssen in der Lage sein, sich selbst reflektieren zu können. Das bedeutet das Architekturwissen muss für einen Computer verständlich chiffriert werden.

! Anforderungsorientiert

Die Architektur bildet meist das Konstrukt um die Anforderungen erfüllen zu können. Jedoch können manche innovativen Anforderungen nicht im Detail spezifiziert werden ohne das Wissen, über vorhandene Lösungsansätze. Deshalb benötigt man Wissen über mögliche Lösungswege um detaillierte Anforderungen geben zu können. Dieser


Anforderungsorientierte Ansatz für Architekturwissen entwickelt die Anforderungen und die Architektur daher gemeinsam.

! Entscheidungsorientiert

In aktuellen Arbeiten scheint sich der Blick auf die Architektur vom Endergebnis zu der Begründung hinter diesem Ergebnis zu verlagern. Es sollten nicht nur die daraus resultierenden Architekturen berücksichtigen werden, sondern auch die Designentscheidungen und das dazu in Beziehung stehende Wissen, welches die Argumentationen hinter diesem Ergebnis darstellt. Das gesamte Architekturwissen muss verwaltet werden, um die Systementwicklung zu begleiten und damit den Verlust des Wissens zu verhindern. Die Behandlung von Designentscheidungen als vorrangige Tätigkeit ermöglicht die Berücksichtigung einer breiten Palette von Bedenken und Problemen, einschließlich technischer, geschäftlicher, politischer und sozialer Fragen. Architekten müssen alle diese Bedenken in ihrer Entscheidungsfindung berücksichtigen. Um die Gestaltung der Architektur gegenüber anderen Stakeholder zu rechtfertigen, spielt die Kommunikation der Architektur-Designentscheidungen eine zentrale Rolle.

Aus der Erklärung der vier Ansichten sieht man laut Fahrenhorst und Boer (Farenhorst und Boer 2009), dass es keine allgemeine Definition für Architekturwissen gibt. Die offensichtliche Bedeutung der entscheidungsorientierten Betrachtung bei der Erörterung und Definition von Architekturwissen kann erklärt werden, wenn man die Zusammenhänge zwischen dieser Ansicht und den anderen Ansichten betrachtet. Die Entscheidungen scheinen die Verbindung zwischen den verschiedenen Ansichten zu sein. Harrison, Avgeriou und Zdun (Harrison, Avgeriou und Zdun 2007) erklären die Beziehung zwischen Mustern und Entscheidungen so, dass die beiden Konzepte komplementär zueinanderstehen. Die Verwendung von Entwurfsmustern in der Systemgestaltung bedingt die Auswahl einer Lösung, damit sind Entscheidungen mit dem Entwurfsmuster im zielsystemspezifischen Kontext verbunden. Die Verbindung zwischen der entscheidungsorientierten und dynamisch-orientierten Ansicht erläutert von Bradbury et al. (Bradbury u. a. 2004), ist die ermöglichte Automatisierung von Agenten die Designentscheidungen entweder selbst treffen oder die menschlichen Architekten über mögliche Probleme und anhängige Entscheidungen informieren. Formale grafbasierte Architekturdarstellungen eignen sich besonders für die augenblickliche Begründung. Die Beziehung zwischen Designentscheidungen und Anforderungen kann aus zwei Richtungen betrachtet werden. Die erste Richtung von Bosch (Bosch 2004) ist durch die konzeptionelle Teilung der Architektur-Designentscheidung in einen Anforderungsteil und einen Lösungsteil. Der Anforderungsteil stellt die Untermenge der Systemanforderungen dar, auf die der Lösungsteil eine Lösung liefert. Hingegen beschreibt Lamsweerde (Lamsweerde 2003), dass für alternative Ziele und Zuordnungen Entscheidungen getroffen werden müssen, die am Ende unterschiedliche Architekturen erzeugen. Entscheidungen können Teile dieser unterschiedlichen Ansichten über Architekturwissen vereinheitlichen, weil sie sich eng mit verschiedenen Ausprägungen von Architekturwissens-Konzepten beschäftigen.

2.1.2. Architekturwissensmanagement

Das Architekturwissen kann den Softwareentwicklungsprozess verbessern. Jedoch wenn das Wissen nicht verwaltet wird, wird das kritische Designwissen zu einem impliziten Wissen des


Architekten, dass zu Verlusten oder Problemen führen kann, etwa beim Personalwechsel. Deswegen gibt es laut Dingsøyr und van Vliet (Dingsøyr und van Vliet 2009) eine wachsende Nachfrage nach Werkzeugen zur Speicherung von Wissen, um Design, Entwicklung und Bereitstellung effektiver Wissensmanagement-Strukturen zu erhalten. Das Architekturwissensmanagement soll hierfür Abhilfe schaffen und zwar bei der Erfassung und Verwaltung von Architekturwissen, dass bei Architekturprozessen erzeugt wird. Davenport und Prusak (Davenport und Prusak 1998) definieren das Architekturwissensmanagement als eine Methode, die den Prozess der Teilung, Verteilung, Erstellung, Erfassung und Verständnis des Wissens vereinfacht. Die Motivation Wissensmanagement einzusetzen, ist die Möglichkeit in kürzerer Zeit bessere Entscheidungen zu treffen, die Nacharbeit zu sichern und die Qualität der Produkte zu verbessern. Softwareentwicklung ist ein wissensintensiver Prozess. Eine wissensintensive Arbeit kann verbessert werden, indem man lernt wie das Wissen besser verwaltet wird. Diese Erkenntnis ist das Fundament für Wissensmanagement im Allgemeinen. Dingsøyr und van Vliet (Dingsøyr und van Vliet 2009) belegen, dass es im Softwareentwicklungs-Bereich viele Diskussionen über die Verwaltung und Förderung von Wissen gab. Für die einen ist das Architekturwissensmanagement der Übergang vom anwendungsorientierten zum anwendungsspezifischen Wissen. Für die anderen ist es das Zusammenspiel von implizitem und explizitem Wissen. Lebenszyklus von Architekturwissen

Nava, Capilla und Dueñas (Nava, Capilla und Dueñas 2007) unterteilen den Lebenszyklus in vier Haupttypen von Aktivitäten und zwar dem Entwurf und der Verteilung von Architekturwissen auf der Produzentenseite, sowie der Bewertung und dem Lernen von Architekturwissen auf der Konsumentenseite. Kruchten, Lago und van Vliet (Kruchten, Lago und van Vliet 2006) erklären die Aktivität des Entwurfs von Architekturwissen. Dafür muss bevor eine Entscheidung getroffen wird, eine Begründungshandlung stattfinden. Die Begründung beruht oft auf Annahmen sowie auf der Analyse der Vor- und Nachteile, der Auswirkungen, jeder einzelnen Entscheidung. Darüber hinaus muss die Existenz von Beschränkungen für die Entscheidungen, sowie die Abhängigkeiten berücksichtigt werden, die zwischen aktuellen und früheren Entscheidungen auftreten können. Sobald eine Entscheidung getroffen wurde, sollte ein konkreter Status angegeben werden, wie zum Beispiel ausstehend, genehmigt, abgelehnt oder veraltet und in einer lesbaren Form für die spätere Verwendung aufbewahrt werden. Bevor eine Auswahl getroffen wird, sollten mehrere Alternativen berücksichtigt werden. Bei der Suche nach Alternativen sollte schon angewendetes Architekturwissen mitberücksichtigt werden. Durch das Einpflegen einer Menge von Entscheidungen, kann dieses Architekturwissen mit anderen geteilt werden. In vielen Fällen ist die Grenze zwischen „Produzent“ und „Konsument“ für den Austausch von Aktivitäten nicht klar. „Produzenten“ teilen das vorhandene Wissen und stellen es anderen Stakeholder zur Verfügung. Die „Produzenten“ können auch die Rolle vom „Konsumenten“ von bereits angewendetem Wissen annehmen. Darüber hinaus teilen Architekten das Architekturwissen mit allen am Entwicklungsprozess beteiligten Architekten. Sobald eine Reihe von Designentscheidungen gefällt wurden und die erste Version der Architektur aufgebaut worden ist, muss ein nachfolgender Wartungsprozess durchgeführt


werden um Erkenntnisse aus der Entscheidung für die nächsten Architekturentscheidungen zu bekommen. Die „Konsumenten“ sind zuständig für das Bewerten und Lernen von Aktivitäten. Die Bewertung enthält die Leitlinien und Empfehlungen für die Auswahl der optimalen Entscheidungen unter mehreren Auswahlmöglichkeiten. Die Expertise der Architekten und die Ergebnisse aus der Bewertung verschiedener Alternativen zeichnen die Bewertungs-Aktivitäten aus. Manchmal wird die Beurteilung einer vorherigen Entscheidungsfindung herangezogen, um die richtige Einschätzung durchzuführen. Durch solche Möglichkeiten können bessere Einschätzungen durchgeführt werden, da Architekten aus richtigen und falschen Erfahrungen lernen können. Die Bewertung von Architekturwissen kann genutzt werden, um die Lebensfähigkeit zukünftiger Entscheidungen zu kennen und weitere Empfehlungen zu liefern. Der letzte Schritt ist das Lernen aus existierendem Architekturwissen. Hierbei wird der Architekt zum Architekturwissens-„Konsumenten“ und versucht aus früheren Erfahrungen zu lernen. Dieses Lernen führt implizit dazu, dass sich der Architekt immer mehr von einem Anfänger zu einem Experten entwickelt. Infolgedessen werden zukünftige Architektur-Tätigkeiten voraussichtlich besser ausgeführt. Die Auswertung von gespeichertem Architekturwissen ist eine Möglichkeit, um zu lernen, welche Entscheidungen richtig oder falsch waren und um Unstimmigkeiten im Entscheidungsmodell zu erkennen. Das Einschätzen und Lernen sind oft miteinander verflochten, um die Entscheidungen verstehen zu können. Design-Begründung

Bosch (Bosch 2004) deutet darauf hin, dass eine aussagekräftige Erklärung Informationen enthalten sollte, die den Kontext, die Begründung, die Kompromisse, die Kriterien und die Entscheidungsfindung erklären sollen, die zur Auswahl eines bestimmten Designs aus verschiedenen Gestaltungsmöglichkeiten geführt haben. Im Buch „Rationale Management in Software Engineering“ von Dutoit et al. (Dutoit u. a. 2006) wird diese Art von Wissen als Design-Begründung bezeichnet. Es stellt Wissen dar, das die Antworten auf Fragen zu einer bestimmten Entscheidung liefert, weshalb diese Wahl getroffen wurde. Die Begründung ist die Rechtfertigung hinter Entscheidungen. Die Verfügbarkeit einer Begründung erhöht das Verständnis der Entwickler für das System, sodass es einfacher zu adaptieren oder zu pflegen ist. Wenn frühere Entscheidungen aufgezeichnet worden sind, erleichtert es neue Mitarbeiter in einem Entwicklerteam auszubilden. Allerdings wird die Begründung oft nur teilweise und informell erfasst. Dutoit et al. (Dutoit u. a. 2006) definiert eine Design Begründung als die Argumentation von einzelnen zu entwerfenden Artefakten. Es beinhaltet nicht nur Diskussionen über einzelne Eigenschaften eines Artefakts, sondern auch jeden anderen Grund der das zu entwerfende Artefakt beeinflussen könnte. Bei der Anforderungsspezifikation werden viele Designentscheidungen getroffen, die für die Design Begründung relevant sind. Feedback von der Implementierung beziehungsweise das Testen kann Teil der Design Begründung sein. Die Autoren Regli et al. (Regli u. a. 2000) beschreiben als Absicht hinter einem Design Begründungs-System, dass die Architekten durch ein System beim Denken beziehungsweise Diskutieren für ihre Entscheidungen unterstützt werden sollen. Die Erfassung zu weniger beziehungsweise falscher Informationen kann die Darstellung von Begründungen für


Entwurfsentscheidungen verfälschen. Hingegen kann eine Überflutung von Informationen dazu führen, dass die Architekten das System gar nicht verwenden. Die primäre Anforderung an den Designwissenserfassungsprozess ist es, dass die Design-Begründungen in einer Form erfasst werden, welche die Kommunikation und Wiederverwendung von Designwissen unterstützt. Atwood und Horner (Atwood und Horner 2007) behaupten, dass die momentanen beziehungsweise zukünftigen Design Begründungs-Systeme kaum benutzt werden würden. Sie stützen diese Aussage dadurch, dass es laut ihnen keine nützlichen beziehungsweise benutzerfreundlichen Design Begründungs-Systeme gibt. Ihr Lösungsansatz liegt darin, die Begründung selbst sorgfältig für eine Designbegründung zu definieren. Solch ein System soll grundsätzlich bei der Kommunikation zwischen dem Stakeholder, der Reflexion von Design Optionen und der Analyse der Optionen unterstützen.

2.1.3. Architekturentscheidungen

Nach Vogel et al. (Vogel u. a. 2009) besteht eine Architekturentscheidung aus zwei Punkten. Der erste Punkt besteht aus mehreren Möglichkeiten um die Wahl einer Reaktions- oder Handlungsmöglichkeit für eine bestimmte Situation zu bekommen und dadurch zu entscheiden. Der zweite ist, dass im Rahmen einer Problemlösung, eine Entscheidung nach der Bewertung von Handlungsalternativen eine Alternative gewählt wird. Somit muss der Architekt eine Architektur entwerfen, welche die gestellten funktionalen und nicht-funktionalen Anforderungen berücksichtigt. Der Architekt muss hierbei die Anforderungen priorisieren welche wichtig sind und welche vernachlässigbar. Durch die Auswahl von einer Reihe aus Möglichkeiten entsteht eine Kompromiss Entscheidung. Die Architektur ist das Resultat von Architekturentscheidungen. Steiger und Lippmann (Steiger und Lippmann 2013) unterteilen das Treffen von Entscheidungen in folgende Schritte: ! Entscheidung vorbereiten

Damit eine Entscheidung gefällt werden kann, muss eine Vorbereitung dieser stattfinden. Die Vorbereitung beinhaltet die Formulierung der Ziele, die erreicht werden sollten. Das bedeutet im Kontext der Architektur, dass die funktionalen und nicht-funktionalen Anforderungen erfüllt werden.

! Entschluss für eine Entscheidung

Zum Entscheiden werden bei diesem Schritt die bestehenden Möglichkeiten gegenübergestellt. Jede der Lösungsvarianten hat unterschiedliche Ansätze um die Anforderungen zu lösen. Die Herausforderung darin ist es, die richtige Variante für die Problemstellung zu wählen.

! Entscheidung kommunizieren

Es ist ungenügend, wenn eine Entscheidung getroffen wird, diese jedoch erst auf Nachfrage kommuniziert wird. Um das angestrebte Ziel zu erreichen, muss eine Entscheidung aktiv kommuniziert werden.

! Implementierung beziehungsweise Umsetzung der Entscheidung:

Nach dem Entscheid muss die Entscheidung realisiert werden.


! Beurteilung der Entscheidung Der letzte Schritt ist die Beurteilung der Entscheidungen. Wie beim Architekturwissensmanagement schon erklärt wurde ist es auch hier wichtig, dass implizite Wissen eines Architekten als externes Wissen zu speichern. Dies erleichtert zukünftige Entscheidungen.

Jansen und Bosch (Jansen und Bosch 2005) definierten Software-Architektur als das Resultat von Designentscheidungen. Dadurch bekamen die Designentscheidungen eine immer wichtigere Bedeutung in der Software-Architektur Forschung.

2.1.4. Metamodell für Microservice Entscheidungsmodelle

Um Entscheidungen für Software Architektur nachvollziehbar zu machen, gibt es Ansätze für die Aufzeichnung von Entscheidungsmodellen. Ein Beispiel für solch einen Ansatz ist das von Haselböck et al. (Haselböck, Weinreich und Buchgeher 2017a) entwickelte Metamodell zur Aufzeichnung von Microservice Entscheidungsmodellen. Dieses Metamodell basiert auf der QOC Notation von MacLean et al. (MacLean u. a. 1991) und der Notation von Lewis et al. (Lewis, Lago und Avgeriou 2016). Haselböck et al. (Haselböck, Weinreich und Buchgeher 2017a) haben diese Ansätze jedoch um diverse Elemente erweitert, welche einerseits Microservice spezifisch sind, oder in der durchgeführten Studie als notwendig angesehen wurden. In Abbildung 1 wird das verwendete Metamodell dargestellt und nachfolgend beschrieben.

Die QOC Notation wurde von (MacLean u. a. 1991) entworfen, wobei das Q für Question, O für Options und C für Criteria steht. Zuerst werden die wichtigsten Konstruktionsprobleme identifiziert. Die Optionen stellen mögliche Antworten für die Fragen dar. Die Kriterien versuchen

Abbildung 1: Entscheidungs-Richtlinien Metamodell (Haselböck, Weinreich und Buchgeher 2017a)


die Optionen zu vergleichen beziehungsweise zu beurteilen. Abbildung 1 zeigt das Metamodell, wobei hier die Concerns ähnlich den Questions der QOC Notation interpretiert werden. Die Optionen den Design Optionen und die Implications ähnlich den Criterias zur Evaluierung der Design Optionen stehen. Die Hauptelemente bestehen aus den Concerns, diese Anliegen können potenzielle Ziele, Anforderungen oder andere Stakeholder Bedürfnisse sein. Die Design Areas sind die Entscheidungsräume selbst. Die Design Optionen sind die potenziellen Lösungen zu den adressierten Anliegen, die positive beziehungsweise negative Konsequenzen nach sich ziehen können. Design Optionen können Alternativen zu anderen Design Optionen anbieten beziehungsweise andere Design Optionen ergänzen. Die Implications sind Auswirkungen bedingt durch eine Design Option. Diese können sich positiv oder negativ auf die System Qualität, Organisatorische Strukturen oder die Infrastruktur auswirken. Die potenziellen Lösungen können auch Systemkomponenten benötigen, dargestellt als Technology Options. Dies sind Technologien, welche entweder für eine Design Option oder für eine spezifische Komponente benötigt wird. Für die bessere Verständlichkeit dieses Metamodell dient folgendes Entscheidungsmodell zum Thema Caching, siehe Abbildung 2.

Haselböck et al. (Haselböck, Weinreich und Buchgeher 2017a) definierten das Entscheidungsmodell für das Caching. Das Entscheidungsmodell umfasst drei Anliegen, das erste Anliegen bezieht sich auf das Schreiben von Anforderungsdaten in einen Cache, wenn der Downstream Service nicht verfügbar ist. Diese Anforderungsdaten werden erst dann verarbeitet, wenn der Service wieder verfügbar ist. Das zweite Anliegen bezieht sich auf die Notwendigkeit zwischengespeicherte Daten zu verwenden, wenn der Downstream Service nicht verfügbar ist. Das dritte Anliegen ist die Latenz eines Service Aufrufs zu reduzieren. Diese drei Anliegen sind

Abbildung 2: Metamodell Beispiel


die zuvor erläuterten Concerns, die als Anforderungen für das Caching Entscheidungsmodell fungieren. Das Modell bietet drei verschiedene Caching-Entscheidungsoptionen und zwar das serverseitige Caching, das clientseitige Caching und das proxybasierte Caching. Bei der Verwendung des serverseitigen Caching, wird das Ergebnis in der Nähe oder innerhalb des Services gespeichert. Der Service entscheidet, wann das zwischengespeicherte Ergebnis ungültig ist, deshalb müssen sich die Clients nicht um das Caching kümmern. Somit wirkt sich diese Option positiv auf die Interoperabilität aus, da sie für unterschiedliche Clienttypen verwendet werden kann. Darüber hinaus kann die Caching-Strategie an einem einzigen Ort geändert werden. Im Gegensatz zum clientseitigen Caching reduziert diese Option jedoch nicht die Anzahl der Netzwerk-Hops. Beim clientseitigen Caching ist der Client verantwortlich, wann das zwischengespeicherte Ergebnis ungültig ist. Da die Daten direkt auf dem Client gespeichert sind, ist es hier nicht erforderlich, den Server für jede Anfrage aufzurufen. Dies reduziert die Anzahl von Netzwerk-Hops und erhöht die Verfügbarkeit, da Daten auch gelesen und geschrieben werden können, wenn der Downstream Service nicht verfügbar ist. Dafür besteht die Möglichkeit, dass die im clientseitigen Cache gespeicherten Daten veraltet sind. Das Proxy-basierte Caching basiert auf einer zusätzlichen Systemkomponente zwischen dem Client und dem Server, dem Proxy. Mit dieser Option müssen weder der Client noch der Server das Caching berücksichtigen. Wie beim serverseitigen Caching ist diese Option auch für verschiedene Client-Typen verwendbar. Bei dieser Entscheidungsoption ist es nicht erforderlich den Server für jede Anforderung aufzurufen und deshalb ist das Proxy-basierte Caching auch verwendbar, wenn der Downstream Service nicht verfügbar ist. Wenn der Proxy jedoch selbst nicht verfügbar ist, stehen dem Client keine Daten zur Verfügung. Darüber hinaus reduziert diese Option nicht die Anzahl der Netzwerk-Hops. Das Entscheidungsmodell bietet auch Technologieoptionen für das Caching an. Beim serverseitigen und clientseitigen Caching sind HTTP-Caching und der von NGINX bereitgestellte Mechanismus, zwei mögliche Optionen. Squid oder Varnish implementieren für Proxy-basiertes Caching die erforderliche Proxy-Komponente, indem sie einen Reverse-Proxy bereitstellen.

2.2. Reviews

Der (IEEE Draft Standard for Software Reviews and Audits (Revison of IEEE 1028-1997) 2008) definiert ein Review folgendermaßen: „A process or meeting during which a software product, set of software products, or a software process is presented to project personnel, managers, users, customers, user representatives, auditors or other interested parties for examination, comment or approval.“ (IEEE Draft Standard for Software Reviews and Audits (Revison of IEEE 1028-1997) 2008) Diese Definition führt aus, dass ein Review ein Prozess ist. Dieser Prozess beinhaltet Software Artefakte welche an dafür interessierte Personen vorgestellt wird. Die interessierten Personen, meist Stakeholder, haben die Möglichkeit die Software Artefakte zu prüfen, kommentieren oder zu genehmigen. Laut Rösler, Kneuper und Schlich (Rösler, Kneuper und Schlich 2013) ist ein Review eine Überprüfung eines Fachkonzeptes, einer Publikation oder eines Programms. Sie erklären, dass die Reviewer das Artefakt auf Fehler prüfen, die sonst erst beim Kunden oder beim Testen auftauchen würden. Masak (Masak 2009) begrenzt den Begriff Review auf das Hauptziel, Defekte zu finden und die Bewertung des Gegenstandes. Der Zweck eines Reviews ist es also,


einen Gegenstand von jemand anderen auf Fehler überprüfen zu lassen um Fehler im späteren Betrieb zu vermeiden.

2.2.1. Klassifikation von Reviews

Nachfolgend werden Reviews anhand der Teilnehmer an einem Review klassifiziert. Einerseits können die Teilnehmer ebenbürtig sein, andererseits können die Teilnehmer unterschiedlicher Branchen angehören. Die folgende Auflistung zeigt die Klassifizierung: Peer Review

Reinmann, Sippel und Spannagel (Reinmann, Sippel und Spannagel) definieren ein Peer Review als Qualitätssicherungsverfahren für wissenschaftliche Arbeiten die von gleichrangigen Personen, die Peers genannt werden, bewertet und kommentiert werden. Hornbostel und Simon (Hornbostel und Simon 2006) beschreiben, die Peer-Reviews im wissenschaftlichen Gebiet als selbstverständlich und notwendigen Bestandteil der wissenschaftlichen Kommunikation, um die Glaubwürdigkeit der Arbeit zu gewährleisten. Suls und Martin (Suls und Martin 2009) bekritteln die konventionellen Peer-Review Verfahren, da sie zu lange dauern würden und die Möglichkeiten der neuen Medien kaum Beachtung finden. Ein weiterer negativer Aspekt ist die Auswahl der Gutachter, dem kein bestimmtes Standardverfahren unterliegt. Die Auswahl kann zufällig stattfinden, jedoch aber auch gesteuert werden, um eine bestimmte Bewertung zu erhalten. Der negativste Punkt laut Neidhardt (Neidhardt 2006) ist, dass explizite Mängel, etwa Plagiate, oft gar nicht erkannt werden. Nachfolgend werden die verschiedenen Arten von Peer Reviews elsevier.com (elsevier.com 2017) aufgelistet: ! Einfaches Blindreview

Die Namen der Reviewer sind dem Autor verborgen. Dies ist die traditionellste Methode des Peer Reviews. Ein Vorteil ist die Anonymität der Reviewer, welche unparteiische Entscheidungen herbeiführen soll, da die Reviewer nicht von den Autoren beeinflusst werden können. Ein Nachteil für die Autoren ist, dass die Reviewer die Publizierung hinauszögern können. Durch die Hinauszögerung kann der Reviewer dieses Thema zuerst publizieren. Ein zusätzlicher negativer Aspekt dieser Art ist die überharte Kritik an einer Arbeit, die durch die Anonymität gerechtfertigt wird.

! Doppeltes Blindreview

Bei diesem Verfahren sind sowohl der Reviewer als auch der Autor anonym. Der Vorteil dieser Methode ist die Nichtberücksichtigung von Status und Prestige eines Autors. Es wird nur der Inhalt der Arbeit als Grundlage zur Bewertung herangezogen. Jedoch können die Reviewer den Autor durch den Schreibstil, Gegenstand beziehungsweise durch Selbstzitate identifizieren. Bei manchen Werken ist es auch problematisch, wenn das Herkunftsland oder vorherige kontroverse Werke dadurch nicht berücksichtigt werden können.

! Offenes Review

Hier werden die Reviewer und Autoren offen dargelegt. Auf der einen Seite ergeben sich die Vorteile, dass böswillige Kommentare eingegrenzt werden, Plagiate dadurch eher erkannt werden können und ein offenes und ehrliches Review gefördert wird. Auf der anderen Seite


kann es dazu führen, dass durch die Höflichkeit oder Angst vor Vergeltung, ein Reviewer Kritik zurückhält.

Peer Review Prozess

Müller (Müller 2009) erklärt, dass es erforderlich ist, einen auf demselben oder gleichwertigen Fachgebiet tätigen Peer als Gutachter einzusetzen. Nur diesen ist es möglich, einen wissenschaftlichen Text richtig und vollständig zu verstehen, die Qualität zu bewerten und hilfreiche Verbesserungen vorzuschlagen. Die Entscheidung der Veröffentlichung erfolgt aber allein durch den Herausgeber. Der Peer gibt Empfehlungen beziehungsweise Meinungsäußerungen über den Gegenstand des Reviews. Er hat keine Entscheidungskompetenz hinsichtlich der Veröffentlichung einer Arbeit. Im Allgemeinen gilt aber, dass Manuskripte nur dann veröffentlicht werden, wenn die Verfasser die Verbesserungsvorschläge der Peers einbauen. Die Manuskripte werden dem Herausgeber übergeben, danach entscheidet das Herausgebergremium, ob die Arbeit einer formalen Begutachtung genügt oder sofort abgewiesen wird. Ein Ablehnungsgrund kann dabei sein, dass das Manuskript thematisch nicht in das Zielgebiet des Herausgebers reinpasst. Wenn es jedoch akzeptiert wird, wird das Manuskript an verschiedene „Peers“ verteilt, die geeignete Gutachten erstellen können. Nach Rückerhalt der Gutachten kann das Herausgebergremium entscheiden, ob die Originalversion publiziert wird oder die Kommentare beziehungsweise Meinungsempfehlungen vom Autor zur Korrektur einfordern. Die aktualisierte Version vom Autor kann entweder sofort vom Gremium freigegeben werden oder es können weitere Reviews angefordert werden. Dieser Prozess lässt sich wiederholen, bis die Herausgeber zufrieden sind. Der Reviewprozess ist in der Abbildung 3 nochmals bildlich erklärt. Von der Idee über das Recherchieren bis zum fertigen Manuskript, dass dem Verlag gesendet wird. Der Verlag leitet es an drei bis fünf Reviewer weiter und aus den Erkenntnissen der Reviewer wird es entweder akzeptiert, überarbeitet oder abgelehnt.

Abbildung 3: Peer Review Prozess (Woodward-Pratt 2017)


Kollektive Intelligenz

Leimeister (Leimeister 2010) beschreibt, kollektive Intelligenz als kein neues Phänomen. Es steht seit vielen Jahren im Fokus der Wissenschaft und Forschung (Biologie, Sozialwissenschaften, Ingenieurwissenschaften, Informatik etc.). Ein weit verbreiteter Ansatz verfolgt die Wurzeln kollektiver Intelligenzen auf evolutionäre Prozesse und bezieht sich auf Intelligenz in Gruppen. Im Teamsport zum Beispiel bewertet jedes Gruppenmitglied die Gesamtsituation und handelt entsprechend, um das Gesamtziel zu erreichen. Aber auch große Gruppen von Menschen können Entscheidungen treffen, zum Beispiel bei demokratischen Wahlen. Kollektive Intelligenz sehen (Joo und Normatov 2013) als Dienstleistungen, die die Weisheit der Massen einsetzen. Im Kontext von der Informatik wären das die Sozialen Netzwerke, Verteilungs-Dienstleistungen, Reviews beziehungsweise Empfehlungen. Benutzerreview

Mudambi und Schuff (Mudambi und Schuff 2010) definieren ein Benutzerreview als eine Produktevaluierung gleichrangiger Konsumenten. Mithilfe einer hilfreichen Kundenrezension soll der Konsument beim Kaufentscheidungsprozess unterstützt werden. Smith, Menon und Sivakumar (Smith, Menon und Sivakumar 2005) erklären ein Benutzerreview als Mund-zu-Mund Information von Verbrauchern für Verbraucher. Benutzerreviews dienen also als vermeintlich bessere Informationsquelle für Verbraucher, da diese Informationen lebendiger, einfacher beziehungsweise vertrauenswürdiger aufgenommen werden als Attributinformationen vom Produzenten. Otterbacher (Otterbacher 2011) beschreibt Review Communities als wichtige Ressource für den Austausch von Informationen unter den Verbrauchern. Die Benutzer tauschen ihre Erfahrungen über bestimmte Gegenstände gegenseitig aus. Darüber hinaus werden die Unabhängigen Verbraucher dieser Communities als unvoreingenommene Informationsquellen im Vergleich zu einem Hersteller gesehen. Es ist eine Form von Mundpropaganda, die gezeigt hat, dass der Umsatz dadurch beeinflusst wird. Zusätzlich wird das Vertrauen in ein Produkt beziehungsweise in einen Verkäufer gestärkt beziehungsweise geschwächt. Weisheit der Menge

Hwang, Yuan und Weng (Hwang, Yuan und Weng 2011) beschreiben, dass sich im Zeitalter der Sozialen-Medien die von Benutzer generierten Inhalte rasant erhöht haben, da die Nutzer jetzt sowohl „Produzent“ und „Verbraucher“ der digitalen Inhalte sind. Die Rolle der Webseiten Betreiber hat sich vom „Produzenten“ der Beiträge hin zum „Betreiber“ der Plattform, auf der sich die Webseite befindet, geändert. Heute werden die Beiträge des Nutzers als wertvoller Bestandteil für die Durchführung von kollektiver Weisheit behandelt. Die Nutzer werden ermutigt, ihre eigenen Inhalte einzubringen, mit anderen Teilnehmern zu kommunizieren und Informationen auszutauschen. Die kollektive Weisheit setzt auf die interaktiven Beiträge zwischen den Teilnehmern. So kann die kollektive Weisheit nicht zentral gesteuert werden, aber es erfordert einige Mechanismen von Protokollen, um die Entwicklung der kollektiven Weisheit unter verschiedenen autonomen Dienstumgebungen zu erleichtern. Jedoch muss man laut Lykourentzou et al. (Lykourentzou u. a. 2010) beachten, dass diese generierte Qualität der Inhalte im generellen niedriger ist als die generierte Qualität von Experten. Bei der Benutzung von generierter kollektiver Intelligenz ist es also laut Hwang, Yuan und Weng (Hwang, Yuan und Weng 2011) sinnvoll, Expertengruppen für bestimme Domänen einzuführen, die die Qualität der


Inhalte evaluieren. Jedoch können Webseiten wie Wikipedia die Größe der Community ausnützen, um bessere Qualität zu garantieren, da sie durch mehr Mitwirkende die Qualität der Artikel über mehrere Revisionen versichern können. Hierbei erwähnen Pelechrinis et al. (Pelechrinis u. a. 2015), dass es für einen Menschen nicht möglich ist alles über alles zu wissen, deswegen ist Fachwissen kontextabhängig.

2.2.2. Anwendungsbereiche von Reviews

Reviews werden in verschiedenen Anwendungsbereichen eingesetzt. Die Auflistung zeigt die für diese Arbeit wichtigsten Anwendungsbereiche: Software Review

Der (IEEE Draft Standard for Software Reviews and Audits (Revison of IEEE 1028-1997) 2008) legt folgende Reviewarten fest: ! Management Review

Das Management Review ist eine Bewertung, welche vom Management zur Beurteilung des Zustandes beziehungsweise Bestimmung des Status eines Artefakts durchgeführt wird.

! Technisches Review

Das technische Review ist eine fachliche Prüfung auf Übereinstimmung mit der Spezifikation eines zentralen Dokuments wie zum Beispiel ein Entscheidungsmodell für Microservices. Die Bewertung findet hier durch Fachpersonal statt. Das Ziel hinter dem technischen Review ist es eine Diskussion anzuregen, mit dieser Fehler aufzudecken und dadurch technische Probleme lösen zu können. Zusätzlich sollten Alternativen zum Treffen von Entscheidungen bewertet werden.

! Informelles Review

Das informelle Review ist inhaltlich ähnlich dem technischen Review, jedoch leicht abgeschwächt. Es ist meist nur ein Gegenlesen des zu prüfenden Objektes durch einen oder mehreren Kollegen. Eine Liste von Anmerkungen oder das korrigierte Exemplar des zu überprüfenden Objekts genügt. Durch den geringen Aufwand hat das informelle Review eine hohe Akzeptanz und eine weite Verbreitung gefunden. Die Vorteile dieser Reviewart sind der geringe Aufwand und die dadurch entstehenden geringen Kosten. Zusätzlich spielt der soziale Aspekt eine Rolle, da das gegenseitige Kennenlernen und der Austausch unter den Kollegen gefördert werden.

! Komplettlösung

Bei der Komplettlösung geht es laut Myers, Sandler und Badgett (Myers, Sandler und Badgett 2011) darum die Kosten möglichst gering zu halten. Dabei wird versucht, in einem ein bis zwei Stunden dauernden Treffen von gleichgestellten Kollegen Fehler zu finden. Durch die Diskussion von Szenarien und Probeläufen soll ein Verständnis über das Themengebiet entstehen.

! Inspektion

Die Inspektion ist die formalste der Reviewarten die durch die (IEEE Std 610.12-1990 1990) und (IEEE Draft Standard for Software Reviews and Audits (Revison of IEEE 1028-1997)


2008) dokumentiert sind. Hierbei ist es wichtig, dass das zu überprüfende Objekt den geforderten Qualitätsmerkmalen, zusätzlichen Vorgabedokumenten, allen gegebenen Standards, sowie allen Spezifikationen genügt. Dabei sollen alle Abweichungen gefunden und dokumentiert werden. Eine begründete Entscheidung für die Freigabe muss gegeben werden. Metriken um den Entscheidungsprozess zu optimieren müssen ebenfalls erhoben werden. Die erhobenen Daten sollen dem Management vorgelegt werden, welches auf Basis der Daten bessere Entscheidungen für den Fortgang der Entwicklungen treffen können.

Erfolgsfaktoren für Software Reviewsysteme

Linz und Spillner (Linz und Spillner 2012) identifizierten folgende Erfolgsfaktoren für Reviewsysteme: ! Definition der Ziele

Durch die Definition der Ziele sollen Fehler, Ungenauigkeiten beziehungsweise Abweichungen klar ersichtlich werden.

! Mitteilung der Fehler

Die aufgedeckten Fehler sollen objektiv übermittelt werden.

! Psychologischer Aspekt Der psychologische Aspekt ist sehr wichtig. Dem Review Teilnehmer soll das Review als ein positives Erlebnis in Erinnerung bleiben und nicht, dass die Evaluation in die Beurteilung der eigenen Leistung fällt.

! Tester

Durch den Einsatz von Testern als Gutachter werden weitere zu testende Themen aufgeschnappt und zusätzlich wird automatisch die Einarbeitung in das Produkt durchgeführt.

! Auswahl der richtigen Reviewart

Die Auswahl der Reviewart sollte aufgrund der Art und des Niveaus eines Dokuments beziehungsweise unter Berücksichtigung des Kenntnisstandes der beteiligten Reviewer durchgeführt werden.

! Checklisten und Richtlinien definieren

Die Checklisten und Richtlinien sollen den Reviewer unterstützen um die Effektivität der Fehlererkennung zu erhöhen.

! Management

Um Reviews ordnungsgemäß durchführen zu können ist es wichtig, dass das Management genügend Ressourcen mit Zeit und Personal zur Verfügung stellt.

! Ständiges Lernen

Um sich weiterentwickeln zu können sollte man durch die durchgeführten Reviews lernen und das Verfahren ständig verbessern.


Wissenschaftliche Reviews

Wissenschaftlich werden Reviews einerseits zum Review von Publikationen, andererseits für Systematische Reviews der Literatur eingesetzt. Nachfolgend werden diese beiden Arten, samt ihren Unterarten beschrieben. Review von Publikationen:

Sataloff (Sataloff 2011) erläutert die Wichtigkeit von Reviews in der akademischen Community. Die meisten wissenschaftlichen Journale die veröffentlicht werden sind mit Studienergebnissen untermauert. Um von der Korrektheit ausgehen zu können werden diese Ergebnisse reviewt und erst dann für die Veröffentlichung freigegeben. Brownlee (Brownlee 2006) beschreibt den Veröffentlichungsprozess eines Journals. Wenn Wissenschaftler einen Forschungsartikel an den Verlag schicken, macht eine Gruppe von Redakteuren des Journals die erste Entscheidung über ihre Qualität und ihre Eignung für das Journal. Wenn das Paper diesen ersten Schritt übersteht, wählen die Redakteure einige ebenbürtige Wissenschaftler, die der Verlag in dem entsprechenden Wissenschaftsgebiet als fähig betrachtet und bitten diese den Forschungsartikel zu lesen. Diese Reviewer lesen dann den Bericht und geben ihre Meinungen ab.

! Web-basiertes Peer Review System

Das Review Verfahren wird nicht nur bei Softwaretests eingesetzt, sondern auch für Fachpublikationen. Tananbaum und Holmes (Tananbaum und Holmes 2008) erklären dieses Verfahren für Fachpublikation das in dieser Disziplin seit Jahren eingesetzt wird. Mitte der 90er wurden die ersten web-basierten Peer Review Systeme eingeführt. Deren Ziel war es, die Effizienz für Autor, Gutachter, Reviewer und für die veröffentliche Firma zu verbessern. So ein System reduziert die Durchlaufzeit durch die elektronische Übermittlung des Manuskriptes beziehungsweise der Revisionen des Manuskriptes. Dadurch werden auch Kosten gespart die für die Administration, den Druck beziehungsweise die Postgebühren angefallen wären. Das Web-basierte System bietet dem Autor ein Formular, in welchem dieser die Metadaten erfassen und das Manuskript sicher hochladen kann. Darauf folgend wird ein Workflow angestoßen, der die Reviewer benachrichtigt, dass sie ein Review durchzuführen haben. Zudem werden sichere Konten für die wichtigsten Akteure angeboten um den Fortschritt eines Reviews einzusehen. Jeder Reviewer kann seine Verbesserungsvorschläge im System zum Manuskript notieren. Darüber hinaus werden die Akteure zeitlich benachrichtigt, sollten notwendige Arbeitsschritte noch nicht abgeschlossen sein.

! Kollaboratives Peer Review System

Im vorigen Punkt wurden die Vorteile von einem web-basierten Review System erläutert. Carniol, Pham und LeMasurier (Carniol, Pham und LeMasurier 2014) experimentierten im Review Bereich um den Review Prozess zu optimieren. Weltweit verwenden die Wissenschaftler die angebotenen Werkzeuge des Elsevier Verlags, wie zum Beispiel das Anmerken von Dokumenten, das Zitieren von Publikationen oder dem kollaborativem Arbeiten an Forschungsprojekten. Dadurch kam die Idee eines kollaborativem Review Systems und wie man durch so ein System profitieren könnte. Es wurden drei verschiedene Modi für die Versuchsreihe aufgestellt. Eine Eigenschaft hatten alle Modi gemeinsam, die Reviewer waren immer anonym. Nachfolgend werden die drei Modi genauer beschrieben.


Der erste Versuch beinhaltete, dass sie nach ihren Reviews, die sie über den konventionellen Weg durchführten, über den Artikel diskutieren sollten. Der Test inkludierte zehn Manuskripte zu je sechs Reviewern pro Team die teilnahmen. Das Resultat war positiv, da 94% der Teilnehmer angaben, dass ihnen die Art der Diskussion gefiel und in Zukunft an einem ähnlichen Verfahren gerne wieder teilnehmen würden. Fünf Teilnehmer gaben an, dass der interaktive Review Prozess es einfacher und klarer machen würde eine Publikation zu überarbeiten. Zusätzlich empfanden die Reviewer, die Zusammenfassungen der Reviewer, die am Ende der Diskussion angefügt wurde, als hilfreich um einen schnellen Überblick zu bekommen. Während es viele positive Aspekte dafür gibt, war jedoch die Dauer des Prozesses um einiges länger als die des konventionellen Prozesses. Zusätzlich empfanden manche Reviewer die extra Arbeit und die hinzukommende Zeit als Nachteil.

Der zweite Testversuch war komplexer angelegt: Die Reviewer mussten ihr Review mit dem vom Verlag zur Verfügung gestellten Werkzeug direkt durchführen. Das bedeutete, dass alle Anmerkungen direkt in der Datei gemacht werden mussten. Am Ende musste noch ein zusammenfassender Kommentar erstellt werden. Hierfür waren wieder zehn Manuskripte im Einsatz und sieben Reviewer. Das Resultat des Versuches war, dass die Reviewer nur den zusammenfassenden Kommentar erstellt hatten, jedoch keine Anmerkungen machten. Die Diskussionen variierten, manche Publikationen wurden als zu speziell angesehen um wirklich darüber diskutieren zu können. Hingegen bei allgemeineren Publikationen führte es zu umfangreicheren Diskussionen.

Der dritte Experimentversuch war, dass die Reviewer gefragt wurden, ob sie nach dem konventionellen Review Prozess alle gemachten Reviews einsehen möchten. Das Resultat war gemischt und abhängig von den Umständen. Umso größer die Divergenz der Reviewer Sicht auf die Publikation war, umso größer war das Interesse an der Interaktion.

Der Schluss aus der Studie ist, dass ein kollaboratives Werkzeug bei fachlichen Diskussionen die Reviewer unterstützen kann.

Systematisches Review

Petticrew und Roberts (Petticrew und Roberts 2008) beschreiben systematische Reviews als eine Art von Literaturrecherche, welche mehrere Forschungsstudien oder Papers sammelt und kritisch analysiert. Diese Art von Review wird vor der Formulierung einer oder mehrerer Forschungsfragen durchgeführt, da hierdurch die Fragen in einer strukturierten Methodik beantwortet werden können.

Khan et al. (Khan u. a. 2003) erklärt die fünf Schritte eines systematischen Reviews folgendermaßen:

! Formulieren der Fragen

Die Probleme, die durch das Review angesprochen werden sollen, sollten in Form klarer, eindeutiger und strukturierter Fragen vor Beginn des Reviews festgelegt werden. Sobald die Review Fragen festgelegt sind, sollten Änderungen am Protokoll nur erlaubt werden, wenn es nicht anders möglich ist um die Probleme zu durchleuchten.


! Ermittlung der relevanten Arbeit Die Suche nach Studien sollte umfangreich sein. Es sollten mehrere Ressourcen berücksichtigt werden nicht nur virtuell verfügbare Medien, sondern auch gedruckte Medien sollten ohne Sprachbeschränkungen durchsucht werden. Die Auswahlkriterien der Studie sollten direkt aus den Prüfungsfragen abgeleitet und priorisiert werden. Die Gründe für Einbeziehung und Ausschluss sollten aufgezeichnet werden.

! Bewertung der Qualität der Studien

Die Studienqualitätsbewertung ist für jeden Schritt einer Überprüfung relevant. Die Frageformulierung (Schritt 1) und die Studienselektionskriterien (Schritt 2) sollten das minimal annehmbare Designniveau beschreiben. Ausgewählte Studien sollten einer verfeinerten Qualitätsbewertung unterzogen werden, indem allgemeine kritische Richtlinien und designbasierte Qualitätskontrolllisten verwendet werden (Schritt 3). Diese detaillierten Qualitätsbeurteilungen werden zur Erforschung der Heterogenität und zur Unterrichtung über die Eignung der Metaanalyse verwendet (Schritt 4). Darüber hinaus wird dadurch bei der Beurteilung der Stärke der Schlussfolgerungen und Empfehlungen für die zukünftige Forschung (Schritt 5) geholfen.

! Zusammenfassen der Beweise

Die Datenzusammenführung besteht aus der Tabellierung von Studienmerkmalen, Qualität und Wirkungen sowie der Verwendung statistischer Methoden zur Erforschung von Unterschieden zwischen Studien und deren Kombination. Die Erforschung der Heterogenität und ihrer Quellen sollte im Voraus geplant werden (Schritt 3).

! Interpretation der Beweise

Die in jedem der vier oben genannten Schritte hervorgehobenen Themen sollten erfüllt werden. Das Risiko der Veröffentlichung von Verzerrungen und den damit zusammenhängenden Verzerrungen sollten untersucht werden. Die Erforschung der Heterogenität sollte dazu beitragen, festzustellen, ob der Gesamtübersicht vertraut werden kann. Alle Empfehlungen sollten unter Bezugnahme auf die Stärken und Schwächen der Beweise abgestuft werden.

Bewertungs-Review

Laut Mudambi und Schuff (Mudambi und Schuff 2010) sind Kundenrezensionen zunehmend online für eine breite Palette von Produkten und Dienstleistungen verfügbar. Sie ergänzen weitere Informationen, wie Produktbeschreibungen, Gutachten und Fachberatungen. Über automatisierte Empfehlungssysteme können Kunden ihre Erfahrungen anderen zur Verfügung stellen. Forscher zeigten als Vorteil hierfür auf, dass das Bestehen eines Kundenrezensionssystems den Prozess der Kaufentscheidung beeinflusst. Online-Kundenrezensionen können als Peer-generierte Produktbewertungen definiert werden, die auf Firmen- oder Drittanbieter-Webseiten veröffentlicht werden. Einzelhandelswebseiten bieten den Verbrauchern die Möglichkeit, Produktbewertungen mit Inhalt in Form von numerischen Sternbewertungen (in der Regel von ein bis fünf Sternen) und offenen Kunden-Kommentare zum Produkt zu veröffentlichen. Führende Online-Händler wie amazon.com (amazon.com 2017) haben es den Verbrauchern ermöglicht, Produktbewertungen einzureichen die sie schon vor ein paar Jahren gekauft haben. Einige andere Firmen entscheiden, Kundenrezensionen von Amazon.com oder von anderen Online-Händlern zu kaufen und die Bewertungen auf ihren


eigenen Plattformen zu veröffentlichen. Auf diese Weise stellen die Reviews selbst einen zusätzlichen Umsatz für Amazon und andere Online-Händler dar. Dabholkar (Dabholkar 2006) untersuchte die verschiedenen Branchen, die auf Verbraucherbewertungen setzen, wie Reisen tripadvisor.com (tripadvisor.com 2017) und Wohltätigkeitsorganisationen charitynavigator.org (charitynavigator.org 2017). Der Autor unterstreicht die These, dass die Kundenrezensionen bei einer Kaufentscheidung unterstützen. Dies ist der Hauptgrund, warum Verbraucher eine Rating-Webseite nutzen. Mudambi und Schuff (Mudambi und Schuff 2010) erklären, dass die Bewertungen das Potenzial haben, die Verbraucherbesuche zu erhöhen, die Zeit auf der Webseite zu erhöhen und ein Gefühl der Gemeinschaft unter den häufigen Käufern zu schaffen. Da jedoch die Verfügbarkeit von Kundenrezensionen weit verbreitet ist, verschiebt sich der strategische Fokus von einer simplen Kundenrezension zu einer umfassenden Kundenbewertung, durch die Nutzung eines Reviews. Einordnung der Review Anwendungsbereiche:

Tabelle 1 zeigt, dass alle Review-Systeme bei der Durchführung eines Reviews auf ebenbürtige Reviewer setzen bis auf ein Review-System welches auf die kollektive Intelligenz baut. Peer-Review Benutzer Review Management Review X Technisches Review X Informelles Review X Komplettlösung X Inspektion X Web-basiertes Peer Review X Kollaboratives Peer Review X Systematisches Review X Bewertungs-Review X

Tabelle 1: Einordnung der Review Anwendungsbereiche in die Klassifikation

2.2.3. Teilnehmer zum Review motivieren

Laut Schlag (Schlag 2013) besteht die Motivation von Menschen aus der intrinsischen und extrinsischen Motivation. In den Bereich der intrinsischen Motivation fällt die Neugier, der Anreiz, die Erfolgserwartung. Diese Faktoren führen zu einer internen Motivation, jedoch gibt es Bereiche die für einen Menschen eben keine der intrinsischen Faktoren auslöst. Um sich jedoch auch für solche Dinge motivieren zu können gibt es die extrinsische Motivation die aus zwei Faktoren besteht, der Belohnung die eine positive Verstärkung des Gefühls auslöst und dem Zwang, der eine negative Verstärkung des Gefühls auslöst. Nachfolgend wird aus diesen Gründen nur auf die Belohnungen eingegangen. Belohnungen

Eine Wiener Neurologin untersuchte das menschliche Belohnungssystem mit modernsten medizinischen Methoden und veröffentlichte ihre These Silani (Silani 2017). Das Ergebnis ist, dass das menschliche Belohnungssystem der Grundantrieb von menschlichem Handeln ist. Das Verhalten von Menschen wird nicht nur durch primäre Belohnungen gesteuert, etwa Trinken oder Essen, sondern auch von sozialen Aktionen wie Interaktion mit anderen Menschen oder Emotionen. Das menschliche Belohnungssystem setzt sich aus dem „Wollen“ und dem „Mögen“


zusammen. Das „Wollen“ steht für die Bestrebung nach der Belohnung und das „Mögen“ steht für das Vergnügen nachdem Erhalt der Belohnung. Gamification

Im HMD Magazin Praxis der Wirtschaftsinformatik wurde Ende Dezember 2015 (Brosius und Schmidt 2015) ein Artikel veröffentlicht indem die Bedeutung von Gamification in Unternehmen behandelt wird. Auch wenn eine betriebliche Software kein Videospiel an sich ist, regen gewisse Belohnungssysteme mit Auszeichnungen, Punkten oder Orden die Mitarbeiter an um sie zu benützen. Jeder Mensch setzt sich Ziele um diese erreichen zu können, dadurch werden immer mehr Daten aufgezeichnet. Das Phänomen sollte man nutzen um die Mitarbeiter zu motivieren, die betriebliche Software sollte genauso verwendet werden wie ein Spiel. Ein Spiel ist meist selbsterklärend und somit sollte die Software ähnlich aufgebaut sein. Die Produkte und Dienstleistungen sollen immer auf die Nutzer zugeschnitten sein, damit diese dann auch verwendet wird. Beim Kauf von Dingen werden Menschen von den Erfahrungen und Emotionen geleitet. Genau diese Attribute sollten auch in der Anwendung immer mitberücksichtigt werden. Die Arbeit sollte heutzutage begeistern, Angst vor Fehlern nehmen und Potenziale wecken. Deswegen wird jetzt nicht jede betriebliche Anwendung ein Videospiel sein, jedoch sollte es ein Aspekt bei der Entwicklung sein. Nutzer (Spieler) zentriertes Design

Kumar und Herger (Kumar und Herger 2013) beschreiben Gamification als Spieler zentriertes Design. Dabei stehen die Ziele vom Spieler im Mittelpunkt des Design- und Entwicklungsprozesses. Dadurch konzentrieren sich die Entwickler das Produkt so zu entwerfen, dass die Aufgaben möglichst effizient, effektiv und völlig zufriedenstellend abgewickelt werden können. Die Erledigung der Aufgaben sind zwar wertvolle Ziele, jedoch fügt Gamification noch eine wertvolle Ergänzung hinzu. Bei Videospielen werden mit Fortlauf der Aufgaben die Fähigkeiten immer besser, daher versucht das Konzept von Gamification den Spielern auch mehr Macht zu gewähren. Romero und Lambropoulos (Romero und Lambropoulos 2015) erklären, dass zum Umsetzen des Spieler-zentrierten Designs zuerst die Spieler verstanden werden müssen. Hierbei sind die soziodemographischen Aspekte der Mitarbeiter zu verstehen, zum Beispiel das Geschlecht, das Alter, die Bildung, die Berufsgruppe oder der Status. Dafür muss laut Sakamoto, Nakajima und Akioka (Sakamoto, Nakajima und Akioka 2017) eine Anpassung an die soziokulturelle Gesellschaft geschaffen werden um die Spieler zu motivieren. Es muss jedoch auch die interkulturelle Perspektive, sowie die Generationssicht berücksichtigt werden. Ouellet, Romero und Sawchuk (Ouellet, Romero und Sawchuk 2017) führten ein Experiment durch, in welchem Schüler und ältere erwachsene Personen die Aufgabe hatten, in Teams ein Spiel nach den Vorgaben der Experimentleiter zu entwerfen. Der Ansatz der Schüler war auf der Basis von „Trial and Error“. Die Erwachsenen hingegen wählten meist einen reflektierenden Ansatz und haben zuerst die verschiedenen Möglichkeiten ausgelotet. Um Gamification für Unternehmens-Software einsetzbar zu machen müssen folgende Punkte von Stiegler und Zimmermann (Stiegler und Zimmermann 2014) berücksichtigt werden:


! Game Play Beim Game Play sollte das Programm, so wie beim Film, ein Drehbuch haben. Das Game Play stellt die größten Ansprüche an das Programm, da es die eigentlichen Aufgaben beinhaltet und diese für den Spieler effektiv aufbereitet sein sollen. Dafür müssen die Aufgaben, die Belohnungen und der Zuwachs vom Fähigkeitsgrad spezifiziert werden. Um eine Aufgabe bedeutungsvoll einzubauen, wird empfohlen die Bedeutung der Effizienz nach unten zu stufen. Ein weiterer wichtiger Punkt ist die Wiederholbarkeit der Aufgabe, hierfür sollen die Methoden so gebaut sein, dass die Wiederholung der Aufgabe weiterhin unterhaltend ist.

! Game Mechanics

Die Game Mechanics stellen die Spielregeln dar, die für die Implementierung genau definiert werden müssen. Die zwei wichtigsten Aspekte bei der Regelfestlegung sind die Auswahl der richtigen Schwierigkeitsstufen und die Ausbalancierung des Systems auf die verschiedenen Fähigkeiten der Spieler. Es ist wichtig, dass den Spielern zum Erreichen der Ziele ein geeignetes Werkzeug zur Verfügung gestellt wird.

! Game Engine

Die Game Engine ist die technische Implementierung und setzt die definierten Spielregeln in ausführbaren Code um. Bei der Umsetzung der Mechaniken gibt es keine speziellen Vorgaben, diese variieren zwischen den Gamification Projekten.


3. Werkzeug aus Nutzersicht

In diesem Kapitel wird das implementierte Werkzeug aus Nutzersicht vorgestellt. Es wird zunächst der für die Benutzer zugrundeliegende Review Prozess dargestellt. Anschließend werden die zur Unterstützung dieses Prozesses implementierten Funktionen genauer beschrieben.

3.1. Grundkonzepte

Um die in Abschnitt 1.1. definierten Ziele erreichen zu können, müssen zuerst die grundsätzlichen Konzepte abgesteckt sein. Da der Fokus dieser Arbeit auf Software Architekturwissen von Entscheidungsmodellen liegt, beschränkt sich das implementierte Werkzeug auf das von Farenhorst und Boer (Farenhorst und Boer 2009) im Abschnitt 2.1. vorgestellte entscheidungsorientierte Architekturwissen, welches nicht nur die resultierende Architektur berücksichtigt, sondern auch mögliche Alternativen zu Designentscheidungen darstellt. Die Designentscheidungen sollen durch Begründungen dieser das Ergebnis nachvollziehbar machen. Anknüpfend an dieses entscheidungsorientierte Architekturwissen erstellten Haselböck et al. (Haselböck, Weinreich und Buchgeher 2017a) ein Metamodell für Microservice Entscheidungsmodelle, das in Abschnitt 2.1. genauer erläutert wird. Ein weiteres Ziel ist die Validierung solcher Entscheidungsmodelle durch ein Review-basiertes Verfahren. Hierfür wurden im Abschnitt 2.2.1. verschiedene Reviewarten klassifiziert. Dabei stellte sich heraus, dass für ein Review von Software Architekturwissen nur Experten, sogenannte Peers, infrage kommen. Das Software-Architekturwissen ist ein sehr spezifisches Wissen und muss im jeweiligen Kontext betrachtet werden. Somit bedingt die Bewertung einer Software Architektur ein sehr hoher Erfahrungswert im Bereich der Software Architektur, deswegen stellen nur Software Architekten die Anforderungen an einen Reviewer eines Software Architektur Entscheidungsmodells. Somit führt ein Experte ein technisches Review, welches im Abschnitt 2.2.2. genauer erklärt wird, durch und prüft das Entscheidungsmodell auf Fehler oder diskutiert das Entscheidungsmodell mit anderen Experten. Dieses gesammelte Architekturwissen muss verwaltet werden, um den Verlust des Wissens zu verhindern. Die Umsetzung des Werkzeugs benötigt daher die Bündelung dieser Grundkonzepte. Das entscheidungsorientierte Software Architekturwissen wird mit der grafischen Notation von Haselböck et al. (Haselböck, Weinreich und Buchgeher 2017a) erfasst und zusätzlich wird die Möglichkeit eines Reviews eines mit dieser Notation dargestellten Entscheidungsmodells angeboten. Dieser Prozess wird im folgenden Abschnitt 3.2. genauer erläutert.

3.2. Review Prozess

In diesem Abschnitt wird der Review Prozess, auf Basis dessen das Werkzeug erstellt wurde, beschrieben. Zusätzlich werden auch die einzelnen Rollen des Prozesses und die notwendigen Funktionen dargestellt. In Abbildung 4 ist der Reviewprozess anhand eines BPMN-Modells abgebildet.


Abbildung 4: BPMN-Modell - Reviewprozess


Das Modell besteht aus drei verschiedenen Bahnen, die für die unterschiedlichen Rollen (Reviewer und Software Architekten) beziehungsweise für das Werkzeug selbst stehen. Bevor der Reviewprozess beginnen kann, muss der Software Architekt zuerst Entscheidungsmodelle erstellen. Abbildung 5 zeigt den Subprozess der Erstellung eines neuen Entscheidungsmodells. Zu Beginn des Subprozesses wird ein leeres Zeichenblatt angezeigt, auf welchem das Entscheidungsmodell abgebildet wird. Die Erstellung des Entscheidungsmodells basiert auf der grafischen Notation des Metamodells von Haselböck et al. (Haselböck, Weinreich und Buchgeher 2017a) und ermöglicht das Erstellen, Kommentieren, Ändern, beziehungsweise Löschen von Elementen. Die erstellten Elemente können ebenfalls verbunden werden und der Architekt hat die Möglichkeit diese Beziehungen wieder zu löschen. Nach der fertigen Modellierung des Entscheidungsmodells wird dieses gespeichert und ein Reviewer kann dieses neu modellierte Entscheidungsmodell reviewen.

Aus der Sicht des Reviewers beginnt der Prozess mit der Auswahl eines vorhandenen Entscheidungsmodells. Dieses ausgewählte Entscheidungsmodell wird vom Werkzeug kopiert, damit das Referenzmodell nicht verändert wird. Die Kopie enthält dieselben Elemente wie das Referenzmodell. Dieses Modell wird als Reviewmodell bezeichnet. Der Reviewer hat nun die Möglichkeit, entweder das Review für das ausgewählte Entscheidungsmodell durchzuführen oder ein neues, zusätzliches Entscheidungsmodell zu entwerfen. Abbildung 6 zeigt den Subprozess zum Review eines ausgewählten Entscheidungsmodells. Nach dem Aufruf des

Abbildung 5: Subprozess - Neues Entscheidungsmodell erstellen


Reviewmodells wird dem Reviewer das kopierte Entscheidungsmodell angezeigt, welches dieser nun reviewen kann. Dieser Subprozess unterstützt dieselbe Funktionalität wie bei der Erstellung eines neuen Entscheidungsmodells. Es können beim Review ebenfalls Elemente erstellt, kommentiert, geändert, beziehungsweise gelöscht werden. Die Beziehungen können ebenfalls erstellt und gelöscht werden. Jedoch kann das Entscheidungsmodell selbst auch kommentiert werden, um etwaige Anmerkungen zum Entscheidungsmodell zu machen, oder Fragen zum Entscheidungsmodell zu stellen.

Nach Fertigstellung des Reviews durch den Reviewer wird das Reviewmodell auf den Status „fertig“ gesetzt und kann vom Software Architekten begutachtet werden. Der Reviewer hat danach die Möglichkeit, weitere schon angeforderte Reviews von Entscheidungsmodellen durchzuführen oder noch nicht ausgewählte Entscheidungsmodelle für ein Review anfordern. Die Software Architekten haben die Möglichkeit, sich alle fertiggestellten Reviews zu den Entscheidungsmodellen in einer Übersicht anzusehen und diese dementsprechend zu analysieren. Der Software Architekt wählt einen Review Report für ein Entscheidungsmodell aus

Abbildung 6: Subprozess - Review eines ausgewählten Entscheidungsmodells


und erhält vom Werkzeug nach der Generierung des Review Reports ein PDF, welches jegliche Veränderungen am Modell tabellarisch anzeigt. Durch diesen Reviewprozess ergeben sich folgende Einsatzszenarien für das Werkzeug: ! Erstellen und Editieren von Modellen zur Entscheidungsunterstützung in einer grafischen

Darstellung

! Verwalten von Modellen zur Entscheidungsunterstützung über ein nutzerspezifisches Dashboard

! Review von Modellen zur Entscheidungsunterstützung unter Verwendung folgender

Funktionalitäten

" Editieren " Überarbeiten " Kommentieren

! Darstellung der Unterschiede vom Ausgangsmodell zum Reviewmodell ! Rückverfolgung aller Tätigkeiten des Reviewers am Modell mithilfe einer Änderungshistorie Aus der Literatur und den Anforderungen der Einsatzszenarien wurden folgende Stakeholder für das Werkzeug abgeleitet: ! Software Architekten

Diese sind verantwortlich für den Systementwurf und das ihr Wissen dementsprechend im Werkzeug grafisch aufgezeichnet und dokumentiert wird.

! Reviewer

Die Reviewer sind in dem entsprechenden Fachgebiet Experten und beurteilen beziehungsweise bewerten das vom Architekten entworfene Software Architekturwissen.

! Software-Werkzeug

Das Software Werkzeug soll in jeglichem Bereich unterstützend wirken. Es soll helfen bei der Erstellung, bei der Konsistenzprüfung, sowie bei der Berichtsgenerierung zur Auswertung von Reviews.

Benutzerrollen

Zum Abbilden der beiden im Reviewprozess dargestellten Nutzer Reviewer und Software Architekten bietet das Werkzeug die beiden Benutzerrollen User und Admin an. Die Rolle User ermöglicht es, neue Entscheidungsmodelle zu erstellen, eigene vorhandene Entscheidungsmodelle zu verändern und Entscheidungsmodelle zu reviewen. Benutzern, welche die Rolle des Administrators innehaben, haben die gleichen Möglichkeiten wie ein normaler Benutzer und zusätzlich haben sie die Möglichkeit, einem Benutzer ein neues Entscheidungsmodell für einen Review zuweisen zu können. Des Weiteren können sie sich auch einen Bericht zu den durchgeführten Reviews generieren lassen.


Auf Grundlage der beiden Rollen User und Admin gibt die Tabelle 2 einen Überblick über die äquivalenten und unterschiedlichen Funktionalitäten des Werkzeugs, auf die in den nächsten Abschnitten genauer eingegangen wird. Benutzer-Rolle Funktionalität User + Admin Verwalten von Entscheidungsmodellen:

! Übersicht aller Entscheidungsmodelle ! Übersicht über die gerade zu reviewenden Entscheidungsmodelle ! Übersicht über die fertiggestellten Reviews von

Entscheidungsmodellen ! Übersicht der selbst erstellten Entscheidungsmodelle ! Suchen nach Entscheidungsmodellen ! Filtern nach Kategorien ! Review eines Entscheidungsmodells sich selbst zuweisen ! Erstellen eines Entscheidungsmodells ! Löschen eigener Entscheidungsmodelle Review von Entscheidungsmodellen: ! Elemente zu Entscheidungsmodell hinzufügen ! Elemente von einem Entscheidungsmodell ändern ! Elemente eines Entscheidungsmodells löschen ! Elemente in einem Entscheidungsmodell kommentieren ! Beziehung zwischen Elementen erstellen ! Beziehung zwischen Elementen löschen ! Kommentieren vom Entscheidungsmodell ! Änderungshistorie ! Anzeige des Referenzmodells

Admin Verwalten von Entscheidungsmodellen: ! Review eines Entscheidungsmodells einen Benutzer zuweisen ! Berichtsgenerierung eines Reviews ! Löschen von Entscheidungsmodellen

Tabelle 2: Funktionalitäten Übersicht

3.3. Verwalten der Entscheidungsmodelle

Eine grundlegende Funktionalität des Werkzeugs ist die Verwaltung der Entscheidungsmodelle. Dies ist notwendig, damit die Teilnehmer eines Reviews ihre Modelle auswählen und verwalten können. Dazu gibt es allgemeine Ansichten die für alle Nutzer gleich sind, jedoch auch nutzerspezifische Ansichten, um individuell durchgeführte Reviews abzubilden. Es wird auch zwischen nicht registrierten und registrieren Nutzern unterschieden. Nutzer welche nicht für das Werkzeug registriert sind, können sich alle Entscheidungsmodelle ansehen, aber keine Änderungen beziehungsweise Reviews durchführen. Registrierte Nutzer haben nach der Anmeldung die Möglichkeit neue Entscheidungsmodelle zu erstellen, vorhandene Entscheidungsmodelle zu verändern und Entscheidungsmodelle zu reviewen. Nachfolgend werden die dafür implementierten Menü-Reiter beschrieben.


3.3.1. Menü-Reiter

Über den Menü-Reiter, welcher in Abbildung 7 veranschaulicht wird, kann ein Benutzer die Ansicht wechseln.

Folgend werden die einzelnen Menüpunkte des Menü-Reiters, All, Under Review, Review Finished und My Models genauer beschrieben. All

Unter All werden nicht eingeloggten Benutzern und eingeloggten Benutzern alle im System vorhandenen Entscheidungsmodelle angezeigt. Abbildung 8 zeigt drei verschiedene Entscheidungsmodelle, eines zum Speichern von Monitoringdaten, eines für die Fehlertoleranz und eines für die Benutzeroberfläche. Jedes Entscheidungsmodell enthält eine Kurzbeschreibung, den Ersteller, das Erstelldatum, sowie das letzte Änderungsdatum des Entscheidungsmodells.

Abbildung 7: Menü-Reiter


Under Review

Der Reiter Under Review zeigt einem eingeloggten Benutzer alle gerade von ihm unter Review stehenden Modelle. Hingegen kann sich die Rolle Administrator von allen Benutzern, die gerade unter Review stehenden Entscheidungsmodelle anzeigen lassen. Abbildung 9 zeigt aus der Sicht eines Administrators zwei Entscheidungsmodelle, welche zurzeit gereviewt werden.

Review Finished

Beim Reiter Review Finished werden dem eingeloggten Benutzer alle von ihm fertiggestellten Modelle angezeigt. Benutzern mit der Rolle Administrator sehen alle Modelle, bei welchen der Review bereits abgeschlossen wurde, von allen Benutzern. Abbildung 10 zeigt ein abgeschlossenes Review vom Entscheidungsmodell zur Vorbereitung der Bereitstellung von Microservices.

Abbildung 8: Menü-Reiter - All

Abbildung 9: Menü-Reiter - Under Review

Abbildung 10: Menü-Reiter - Review Finished


My Models

Der Menü-Reiter My Models zeigt allen Benutzern, die von ihnen erstellten Entscheidungsmodelle, siehe Abbildung 11. Diese Ansicht wird dem Benutzer ebenfalls über das User-Menü zur Verfügung gestellt, siehe Abbildung 12.

3.3.2. Suchen nach Entscheidungsmodellen

Das Suchen nach Entscheidungsmodellen ist über ein Textfeld oberhalb der Entscheidungsmodelle möglich, siehe Abbildung 13. Nach jeder Eingabe werden die Entscheidungsmodelle überprüft, ob dieses Eingabemuster im Titel vorhanden ist. Somit werden nur noch die Entscheidungsmodelle angezeigt, welche dem Eingabemuster entsprechen.

Abbildung 11: Menü-Reiter - My Models

Abbildung 12: User-Menü - Decision Models


3.3.3. Filtern nach Kategorien

Beim Filtern nach Kategorien werden die Entscheidungsmodelle, je nach Auswahl der Kategorie beziehungsweise Subkategorie, siehe Abbildung 14, angezeigt. Es kann auch nach einer Kategorie beziehungsweise Subkategorie gesucht werden, um auf diese einschränken zu können. Zusätzlich werden dem Benutzer die Anzahl der Entscheidungsmodelle, sowie der Subkategorien als Information zur Verfügung gestellt.

Abbildung 13: Titelsuche

Abbildung 14: Kategoriefilter


3.3.4. Zuweisung eines Reviews für ein Entscheidungsmodell

Zum Auswählen eines Entscheidungsmodells wurde eine Funktion implementiert, welche ein allgemeines Modell in das Profil des Reviewers übernimmt. Das dazu notwendige Zuweisen eines Reviews kann dabei, je nach Rolle, in zwei verschiedenen Formen durchgeführt werden. Ein normaler Benutzer (Reviewer) kann sich nur selbst ein Entscheidungsmodell zum Review zuweisen. Hingegen kann ein Benutzer mit der Administrator Rolle jedem registrierten Benutzer ein Entscheidungsmodell zum Review zuweisen. Das Zuweisen erfolgt über einen Button, der direkt dem Entscheidungsmodell anhängig ist, siehe Abbildung 15.

Klickt ein normaler Benutzer den Review Button, wird dieser gefragt, ob er das Entscheidungsmodell wirklich reviewen will. Nach Bestätigung wird das Entscheidungsmodell geklont und dem Benutzer zugewiesen. Klickt ein Benutzer mit der Rolle Administrator auf denselben Review Button, erscheint jedoch ein Benutzerauswahldialog, siehe Abbildung 16. Nach Auswahl des Benutzers, welchem das Entscheidungsmodell zum Review zugewiesen werden soll, wird das Entscheidungsmodell kopiert und dem Benutzer zugewiesen.

Abbildung 15: Button - Review

Abbildung 16: Benutzerauswahldialog


3.3.5. Berichtsgenerierung eines Reviews

Ein Benutzer mit der „Admin“ Rolle kann sich einen Bericht über alle getätigten Änderungen beziehungsweise Anmerkungen zu einem Review generieren lassen. Hierfür gibt es den „Report“ Button, siehe Abbildung 17. Nach Betätigung dieses „Report“ Buttons öffnet sich der Bericht in einem neuen Fenster.

3.3.6. Erstellen eines Entscheidungsmodells

Für das Erstellen eines neuen Entscheidungsmodells muss der Benutzer in der Übersichtsseite den „Plus“ Button betätigen, siehe Abbildung 18. Danach erscheint ein Eingabedialog, welcher die notwendigen Daten zum Hinzufügen eines neuen Entscheidungsmodells abfragt. Hierbei müssen die Kategorie und der Titel angegeben werden, die Subkategorie beziehungsweise die Beschreibung kann leer bleiben. Nach Betätigung des „Add“ Button wird ein neues leeres Entscheidungsmodell erzeugt.

Abbildung 17: Button - Report

Abbildung 18: Button - Plus


3.3.7. Löschen von Entscheidungsmodellen

Das Löschen von Entscheidungsmodellen ist rollenabhängig. Die Funktionalität wird über einen Button, siehe Abbildung 19, der direkt beim Entscheidungsmodell platziert ist, ausgelöst. Nach Betätigung des „Delete“ Buttons wird der Benutzer gefragt, ob er wirklich das Entscheidungsmodell löschen will, wie in Abbildung 20 veranschaulicht. Nach Bestätigung des Dialogs wird das Entscheidungsmodell entfernt.

3.4. Review von Entscheidungsmodellen

In diesem Kapitel werden alle Funktionen beschrieben, welche für den Review eines ausgewählten Entscheidungsmodells benötigt werden. Dies beinhaltet das Hinzufügen, Ändern, Löschen und Kommentieren von Elementen und das Erstellen und Löschen von Beziehungen zwischen Elementen. Auch wird das Hinzufügen von allgemeinen Kommentaren zum Modell und die Änderungshistorie beschrieben.

3.4.1. Elemente einem Entscheidungsmodell hinzufügen

Ein neues Element, welches ein Element nach der Notation von (Haselböck, Weinreich und Buchgeher 2017a) ist, kann über einen rechten Mausklick auf eine Position im Blatt und der Option Add Node oder über die Quick Item Option hinzugefügt werden. Abbildung 21 und Abbildung 22 zeigen das Hinzufügen auf dem Zeichenblatt über den rechten Mausklick.

Abbildung 19: Button - Delete

Abbildung 20: Bestätigungsdialog zum Löschen


Abbildung 22 zeigt, dass nach der Betätigung der Add Node Option der Benutzer ein Dialogfenster zur Erstellung eines neuen Elements erhält. Bei diesem Dialog muss der Benutzer zuerst einen Elementtypen auswählen, den Namen dafür definieren und eine Begründung kann für dieses Element angeführt werden. Es kann auch die Option gesetzt werden, dass es sich um ein firmenspezifisches Element handelt. Ein Kommentar muss abgegeben werden, da dieser Kommentar als Grund für die Änderung des Entscheidungsmodells aufgezeichnet wird.

Abbildung 21: Neues Element hinzufügen rechter Mausklick

Abbildung 22: Dialogfenster für neues Element


Beim Hinzufügen über die Quick Item Option muss zuerst der Elementtyp ausgewählt werden, siehe Abbildung 23. Nach Auswahl des gewünschten Elements werden die auszufüllenden Attribute für das Element geöffnet, siehe Abbildung 24.

Nach dem Hinzufügen eines Elements wird es grafisch am Zeichenblatt dargestellt.

3.4.2. Elemente editieren

Die vorgestellten Elemente können nicht nur hinzugefügt werden, sondern auch bei der Erstellung eines Modells oder beim Review eines Modells editiert, kommentiert beziehungsweise gelöscht werden. Damit diese vorgenommenen Änderungen nachvollziehbar sind, werden diese aufgezeichnet. Die Aufzeichnungen dienen zum einen für die Wiederherstellung einer Änderung und zum anderen für die Erstellung des Review Berichts. Die grafische Notation von Haselböck et al. (Haselböck, Weinreich und Buchgeher 2017a) definiert Kanten von Knoten zu anderen Knoten, wie einer Entscheidungsoption zu einer Auswirkung. Dafür bietet das Werkzeug nach der Erstellung der einzelnen Knoten die Funktion an Knoten mit Kanten zu verbinden. Das Werkzeug verbindet nur die in der grafischen Notation festgelegten verknüpften Knoten miteinander. Bei der Erstellung der Elemente wurden diese begründet, wenn sich die Begründung ändern sollte ist es im Nachhinein möglich die Begründung zu ändern. Falls es sich herausstellen sollte, dass ein Element falsch eingezeichnet ist, kann dieses auch gelöscht werden. In weiterer Folge werden diese Funktionalitäten erläutert.

Abbildung 23: Neues Element hinzufügen Quick Item

Abbildung 24: Neues Quick Item Element


3.4.3. Element ändern

Ein Element kann mittels rechten Mausklick und der Betätigung der „Change Properties“ Option geändert werden. Diese Funktionalität ermöglicht dem Benutzer zum einen die Korrektur von Begründungen oder Kommentaren zu Elementen und zum anderen zur Anpassung eines Entscheidungsmodells, falls sich bei Elementen Eigenschaften verändert haben, wie zum Beispiel die Wichtigkeit, die Bewertung oder das Firmen-spezifische Merkmal. Nach dem Speichern der Änderungen werden die aktualisierten Informationen am Zeichenblatt dargestellt.

3.4.4. Element löschen

Ein Element kann mittels rechten Mausklick und der Betätigung der „Delete Node“ Option gelöscht werden. Nach Betätigen der Option wird das Element vom Zeichenblatt entfernt.

3.4.5. Elemente kommentieren

Ein Element kann beim Hinzufügen, siehe Abbildung 22 oder bei einer Änderung kommentiert werden und dient als Hilfestellung für spätere Nachvollziehbarkeit. Zusätzlich kann ein Kommentar für ein Element über einen rechten Mausklick und der Betätigung der „Add Comment“ Option abgegeben werden.

3.4.6. Beziehung zwischen Elementen erstellen

Das Zusammenspiel der Elemente wird durch die Beziehungen über Kanten deutlich. Die Kanten können zwischen den Elementen gezogen werden. Ein rechter Mausklick auf eine leere Position im Zeichenblatt ermöglicht dem Autor eine Verbindung zu ziehen, siehe Abbildung 21.

3.4.7. Beziehung zwischen Entscheidungsmodellen erstellen

Ein Entscheidungsmodell kann ähnlich zu einem anderen Entscheidungsmodell sein. Für die Darstellung dieser Beziehung wird ein zusätzliches Feld neben dem Zeichenblatt angeboten. Die Beziehung wird nicht grafisch am Zeichenblatt dargestellt, sondern textuell neben dem modellierten Entscheidungsmodell. Hierbei unterstützt ein Eingabefeld bei der Auswahl des ähnlichen Entscheidungsmodells, da das Eingabefeld nur schon existierende Entscheidungsmodelle dem Benutzer anzeigt und somit auch nur diese dem Entscheidungsmodell als ähnliches Entscheidungsmodell hinzugefügt werden können.

3.4.8. Beziehung zwischen Elementen löschen

Eine Beziehung kann mittels rechten Mausklick und der „Delete Edge“ Option entfernt werden. Nach dem Betätigen der Option wird die Kante vom Zeichenblatt entfernt.


3.4.9. Kommentieren eines Entscheidungsmodells

Das Kommentieren vom Entscheidungsmodell selbst bietet den Benutzern die Möglichkeit sich über ein Entscheidungsmodell auszutauschen. Neben dem Zeichenblatt befindet sich die Möglichkeit einen Kommentar zum Entscheidungsmodell zu schreiben, siehe Abbildung 25.

3.4.10. Änderungshistorie

Die Änderungshistorie zeichnet jede Änderung am Entscheidungsmodell auf, siehe Abbildung 26. Diese Änderungen sind durch einen Klick auf den rot umrandenden Button wieder rückgängig machbar.

Abbildung 25: Kommentieren vom Entscheidungsmodell

Abbildung 26: Änderungsaufzeichnungen


3.4.11. Anzeige des Referenzmodells

Bei Durchführung eines Reviews zu einem Entscheidungsmodell ist es möglich, sich das Referenzmodell anzeigen zu lassen (siehe Abbildung 27). Jedoch sind Änderungen nur am Review Modell das sich in der linken Hälfte befindet möglich.

Referenzmodell Reviewmodell

Abbildung 27: Referenzmodellansicht


4. Softwarearchitektur und Implementierungsaspekte

Dieses Kapitel stellt die technischen Aspekte des implementierten Werkzeugs vor. Zu Beginn wird auf die wesentlichen Technologien eingegangen, die für die Implementierung des Werkzeugs verwendet wurden. Zum Abschluss dieses Kapitel werden einzelne Systemkomponenten und dessen Aufbau im Detail vorgestellt.

4.1. Verwendete Technologien

Das im 3. Kapitel erläuterte Werkzeug bedingt den Einsatz verschiedener Technologien für die Umsetzung und Implementierung. Folgend werden die eingesetzten Technologien und das Datenmodell näher erläutert. Um die Anforderungen für ein Review gestütztes System zu erfüllen, wurde die Literatur, siehe Abschnitt 2.2. herangezogen. Das Werkzeug ist eine Client-Server Anwendung und beinhaltet deshalb eine Backend-, sowie eine Frontend-Komponente. Die Backend-Komponente wurde in der Programmiersprache Java mit der Erweiterung Spring Boot des Springframeworks, siehe Abschnitt 4.1.1. realisiert. Für den Erstellungs- und Abhängigkeits-Prozess für das Springframework wurde Maven eingesetzt. Das Spring Web MVC-Modul wurde zur Definition der REST-Schnittstellen für die Backend-Komponente verwendet. Die Schnittstellen werden mit diesem Modul standardmäßig als JSON-Endpunkt zur Verfügung gestellt. Die Backend-Komponente ist für die Erstellung, Bearbeitung und Löschung der notwendigen Informationen für Architekturwissen verantwortlich. Dies wird in Form von REST-Schnittstellen für die weitere Verarbeitung in der Frontend-Komponente zur Verfügung gestellt. Die Frontend-Komponente wurde in der Programmiersprache JavaScript mit dem clientseitigen JavaScript-Webframework AngularJS in der Version 1.5, siehe Abschnitt 4.1.4. realisiert. Für die visuelle Darstellung des Architekturwissens wurde VisJS, siehe Abschnitt 4.1.5. eingesetzt. VisJS ist eine auf JavaScript basierende dynamische Visualisierungsbibliothek, die als einfaches Erweiterungspaket in AngularJS eingebunden werden kann

4.1.1. Spring Framework

Für die Backend-Komponente wurde das Spring Framework gewählt, welches ein Java Applikationsframework ist. Das Framework wird in der Dokumentation von (Johnson u. a. 2017) beschrieben, es ist sehr weit verbreitet und bietet somit eine gute Unterstützung bei der Erstellung von Java Applikationen. Das Abhängigkeitsmanagement im Spring Framework ist eine Kernkompetenz, welche auch zur Umsetzung der gewünschten Funktionalität im Backend genützt wird. Der Vorteil dieses Mechanismus ist die einfache Austauschbarkeit von Komponenten. Die modulare Aufbauweise vom Spring Framework ermöglicht es nur jene Module zu verwenden, die von der Applikation auch wirklich benötigt wird. Das Spring Framework lässt sich zusätzlich durch Plug-Ins erweitern, damit auch speziell benötigte Technologien verwendet werden können. Die zusätzlich verwendeten Spring Framework Module für die Implementierung der Backend-Komponente sind Spring Boot, Spring Web MVC und Spring Data Neo4j.


! Spring Boot Zur Entwicklung der Backend-Komponente wurde Spring Boot (spring.io 2017a), ein erweiterndes Modul vom Spring Framework, verwendet. Damit lassen sich einfache Stand-Alone-Applikationen entwickeln. Der große Vorteil ist der integrierte Webserver, weswegen keine WAR Datei in Produktion gebracht werden muss. Das Abhängigkeitsmanagement von Spring Boot verwendet automatisch kompatible Versionen von Abhängigkeiten, dass die Bedienung sehr vereinfacht.

! Spring Web MVC Für die Erstellung von REST-Schnittstellen wurde die Spring Web MVC Erweiterung verwendet, welche auf dem Model-View-Controller-Muster basiert. Die Dokumentation von Spring Web MVC (spring.io 2017b) beschreibt, dass mit diesem Modul eine sehr flexible Datenanbindung geboten wird, da es nicht mehr notwendig ist zusätzliche Basisklassen oder Framework spezifische Interfaces implementieren zu müssen um auf Objekte zugreifen zu können.

! Spring Data Neo4j

Die Dokumentation von Spring Data Neo4j (spring.io 2017c) beschreibt die Erweiterung um das Spring Data Neo4j Modul. Dieses Modul bietet erweiterte Funktionen, um die annotierten Entity-Klassen der Neo4j Graphendatenbank zuzuordnen. Das Modul baut die Basis für die Interaktion mit dem Graphen auf und wird auch für die Spring Data Repository-Unterstützung verwendet. Spring Data Neo4j ist eine Kernkomponente des Spring Data Projektes.

4.1.2. Neo4j

Zum Speichern der Elemente und den Beziehungen der Elemente wird eine Graphdatenbank, welche über das Spring Framework eingebunden wird verwendet. Ein Graph ist eine Ansammlung von Knoten und Kanten. Die Kanten verbinden die Knoten und stellen dadurch die Beziehungen dar. Entitäten werden hierbei in Form von Objekten persistiert und mittels der Beziehungen, die auch Objekte sind, miteinander verbunden. In Neo4j werden die Knoten und Kanten als JSON-Objekt dargestellt. Jedes JSON-Objekt beinhaltet eine eindeutige ID, kann mehrere primitive Datentypen, Listen beziehungsweise ganze Objekte beinhalten. Somit können fast alle Informationen in Form eines Graphen gespeichert werden. Die Kanten besitzen immer eine bestimmte Richtung und zeigen daher immer von einem Knoten zu einem anderen, das hat zur Folge, dass ein gerichteter Graph entsteht. Um mit einer Neo4j Datenbank kommunizieren zu können wurde eine Quersyntax namens Cypher entwickelt, diese schickt über die REST-Schnittstelle der Datenbank die Abfragen. Diese Quersyntax ermöglicht es Informationen sehr einfach zu speichern, zu verändern, abzufragen beziehungsweise zu löschen. Für die schnelle und einfache Interaktion liefert Neo4j standardmäßig eine Webapplikation mit. Mit dieser kann man schnelle Datenbankabfragen durchführen und die Ergebnisse werden, wie in Abbildung 28 dargestellt, übersichtlich in einem Graphen dargestellt. (Pokorný 2015) untersuchte das Gebiet der Graphdatenbanken und stellte fest, dass die am häufigsten genutzte Graphdatenbank Neo4j ist. Der größte Vorteil einer Graph-orientierten Datenbank im Gegensatz zu einer relationalen Datenbank ist, dass sie bei komplexen Beziehungen platzsparend arbeitet. Bei relationalen Datenbanken kosten komplexe Beziehungen beim Modellieren schon viele Ressourcen und der Aufbau von Wissensdatenbanken wird in der Regel für Graphendatenbank modelliert. Außerdem ist der


Performance Unterschied bei komplexen Abfragen, die mehrere Joins bei relationalen Datenbanken bedeutet, ein weiterer Vorteil. Da bei relationalen Datenbanken die Zugriffszeit bei zunehmender Datenbankgröße sich erheblich erhöht, bei Graphendatenbanken hingegen die Zugriffszeit relativ konstant bleibt. Einer der größten Vorteile von Neo4j ist die Flexibilität, da bei laufenden Betrieb jederzeit zur Laufzeit neue Knoten beziehungsweise Kanten eingeführt werden können ohne das laufende System zu beeinflussen. Die Skalierungsfähigkeit von Neo4j und die Aufteilung auf mehrere Cluster zum Betrieb auf mehreren Servern sind weitere Vorteile von Neo4j.

4.1.3. Swagger

Zur Dokumentation der Schnittstellen bietet die OpenAPI Specification (swagger.io 2017) ein Werkzeug namens Swagger, deren Kernfunktionalität die automatisierte Generierung der Schnittstellen-Dokumentation direkt vom Quellcode ist. Das Ziel hinter dem Werkzeug ist eine standardisierte und sprachenunabhängige Dokumentation für die REST-Schnittstellen anzubieten. Die REST-Schnittstellen-Dokumentation wird nach der Integration und Konfiguration von Swagger direkt aus dem Quellcode generiert und kann unter einer anpassbaren URL, die in der Swagger Spezifikation festgelegt wurde, aufgerufen werden. Nach der Installation der Swagger-UI wird die Swagger Spezifikation in einer Weboberfläche aufbereitet angezeigt, siehe Abbildung 29. Die Weboberfläche zeigt alle Schnittstellen, unter welchem Pfad und mit welcher HTTP-Aufrufmethode die Abfragen durchgeführt werden können. Nach Auswahl einer Schnittstelle besteht die Möglichkeit über das HTML-Dokument die Schnittstelle zu testen. Durch die Anzeige der Beschreibung und der Möglichkeit die Aufrufparameter einzugeben kann man einen schnellen Funktionstest der Schnittstelle durchführen.

Abbildung 28: Graphergebnis vom Browser


4.1.4. AngularJS 1.5

Für die Implementierung der Frontend-Komponente wurde mit AngularJS 1.5 ein clientseitiges JavaScript-Webframework gewählt. Dieses Framework, näher erläutert in (Green und Seshadri 2013), bietet durch ihre Verbreitung eine gute Unterstützung bei der Erstellung von Webanwendungen. Die Generierung eines HTML-Dokuments basiert hierbei auf dem HTML Standard und dessen Erweiterungen, die clientseitig generiert werden. AngularJS basiert auf dem Model-View-ViewModel-Muster, das eine Variante des Model-View-Controller-Musters ist. Das Hauptziel dahinter ist die Trennung von Logik und Darstellung für moderne UI-Plattformen, wie in diesem Anwendungsfall für die Frontend-Komponente HTML5, zu erreichen. Diese lose Kopplung erfordert einen Datenbindungsmechanismus zwischen den Komponenten. Ein großer Vorteil dieser Technologie ist die Trennung der Anwendungsschichten. Dadurch können die UI-Designer sich um die Benutzerfreundlichkeit kümmern und die Entwickler können sich rein um die Geschäftslogik kümmern. Hierbei wird die funktionale Trennung von Model und View

Abbildung 29: Schnittstellenübersicht


eingesetzt. Um dies gewährleisten zu können, wird ein Datenbindungsmechanismus eingesetzt. Die drei Komponenten sind das Model, die View, beziehungsweise das ViewModel. In AngularJS wird ein clientseitiges Model zusammen mit der Logik in einem Controller definiert, das bedeutet es entsteht dadurch ein ViewModel. Anschließend werden alle Controller in ein Modul zusammengefasst und dieses Modul mittels des in AngularJS vorhandenen Abhängigkeits-Injektions-Container in die Applikation eingebunden. Dieser Mechanismus verbindet die View mit dem Model, dabei entsteht eine bidirektionale Datenbindung. Die Services von AngularJS enthalten die Geschäftslogik und binden meist externe Ressourcen wie REST-Webservices ein. In diesem Anwendungsfall werden die von der Backend-Komponente definierten REST-Schnittstellen aufgerufen. AngularJS bietet hierbei vordefinierte Services, die durch das $-Zeichen erkennbar sind. Die bidirektionale Kommunikation wird durch sogenannte Scopes erreicht. Jeder Controller besitzt hierfür ein eigenes $scope Objekt, mit diesem werden die zum Controller zugehörigen Daten beziehungsweise Funktionen gekapselt. Die Kommunikation zwischen Controllern funktioniert über das Publish-Subscribe-Verfahren. Ein Controller teilt den zuhörenden Controllern über das Service $broadcast mit, dass sich etwas geändert hat und die empfangenden Controller können darauf reagieren. Die View Zuordnung funktioniert durch Routen. Hierbei werden für URLs bestimmte Routen definiert und somit die spezifischen Ansichten festgelegt. Mit dem $location-Objekt wird die Seitennavigation simuliert. Außerdem ermöglicht AngularJS benutzerdefinierte HTML-Elemente und –Attribute, die Direktiven bezeichnet werden, zu erstellen. Es gibt auch vordefinierte Direktiven die durch den ng-Namensraum im Präfix erkennbar sind.

4.1.5. VisJS

Eine Anforderung an das Werkzeug war das Erstellen und Editieren von Modellen zur Entscheidungsunterstützung in einer grafischen Darstellung. Da als Frontend-Komponente ein JavaScript-Framework ausgewählt wurde, fiel die Wahl auf VisJS, da dieses Framework Netzwerkgraphen darstellen kann, auf Ereignisse reagieren kann, ein HTML5 Canvas Bild zeichnet und eine gute Dokumentation der Funktionen bietet. Netzwerkgraphen sind ideal, um die Verbindungen zwischen Daten darzustellen, ob hierarchische Organigramme, Routen oder wie bei diesem Werkzeug zur Erstellung von Architekturwissen. Eine hilfreiche Unterstützung ist der Aufbau einer hierarchischen Gliederung, somit können Elemente aufgrund ihres Typs angeordnet werden. (VISJS 2017) ist eine dynamische, browserbasierte Visualisierungsbibliothek. Die Bibliothek ist so konzipiert, dass sie einfach zu bedienen ist, große Mengen an dynamischen Daten bewältigen kann und die Manipulation beziehungsweise Interaktion mit Daten ermöglicht. Die VisJS Bibliothek bietet nicht nur Netzwerkgraphen für die Darstellung, da jedoch das Werkzeug lediglich die Netzwerkgraphen einbindet, wird auch nur auf die Einstellmöglichkeiten des Netzwerkgraphen eingegangen. Einer der Ausgangspunkte der Visualisierungen mit VisJS ist, dass sie mit dynamischen Daten umgehen können und dadurch auch die Manipulation der Daten unterstützt. Dies funktioniert über ein flexibles Schlüssel-Wert-basiertes DataSet. Durch die Bereitstellung eines DataSet mit Daten für die Visualisierung, können Änderungen im DataSet abonniert werden und diese Änderungen werden automatisch an die Ansicht weitergegeben. Änderungen der Daten können durch einen Server verursacht werden, der Updates auf einen Client oder andere interaktive Komponenten in der Webanwendung pusht. Umgekehrt können Daten in einer der


Visualisierungen manipuliert werden. Zum Beispiel kann ein REST-Client auf Änderungen hören und automatisch Änderungen am Server durchführen. Ein DataSet besteht aus einem Feld von speziellen Daten die man darstellen möchte, wie die folgende Abbildung 30 zeigt.

Das Beispiel erstellt zwei Knoten mit jeweils einer eindeutigen ID, einem Text, einem Datum, sowie einer Gruppe. Die angegebene Kante wird von der eindeutigen ID zwei zu der ID drei gezogen. Zum Hinzufügen, Verändern und Löschen von Knoten oder Kanten bietet das DataSet die Funktionen Add, Update und Delete. Nachfolgend sind diese drei Funktionen genauer beschrieben. Add

Dem DataSet können ein einzelnes Element oder mehrere Elemente gleichzeitig über ein Feld hinzugefügt werden. Das Hinzufügen eines Elements kann fehlschlagen, wenn bereits ein Element mit derselben ID vorhanden ist. Die Funktion gibt ein Feld mit den IDs der hinzugefügten Elemente zurück. Den Aufruf dieser Funktion zeigt Abbildung 31.

Update

Beim DataSet können Elemente über die Funktion update verändert werden. Diese Funktion verändert eine oder mehrere vorhandene Elemente. Hierbei kann es sich um ein einzelnes Element oder ein Feld aus Elementen handeln. Wenn ein Element nicht existiert, wird es erstellt. Die Funktion gibt ein Feld mit den IDs der geänderten Elemente zurück, siehe Abbildung 32.

Abbildung 30: DataSet Beispiel

Abbildung 31: HInzufügen von Elementen zum DataSet


Remove

Beim DataSet können auch Elemente entfernt werden, wobei es hier möglich ist über eine einzelne ID oder über das einzelne Element selbst ein Element zu löschen. Es funktioniert jedoch auch mehrere Elemente über ein Feld mit deren IDs oder über ein Feld von Elementen zu entfernen. Die Funktion gibt ein Feld mit den IDs der entfernten Elemente zurück, siehe Abbildung 33.

Über das soeben erklärte DataSet kann ein Netzwerkgraph erstellt werden. Hierfür wird in der aufrufenden Ansicht die vis-network-Direktive aufgerufen mit den Attributen der Daten und deren Optionen. Beim Optionen Attribut werden die Eigenschaften des Graphen festgelegt, wie die Höhe, die Breite, die Sprachumgebung, die Knoteneinstellungen, die Kanteneinstellungen, die Gruppen, das Layout, die Interaktionen oder auch die Manipulation um einige Einstellmöglichkeiten zu nennen. Ein Beispielaufruf der Direktive zeigt Abbildung 34.

4.2. Datenmodell

Nach der Definition der Anforderungen und der Vorgabe des Metamodell für Microservice Entscheidungsmodelle von (Haselböck, Weinreich und Buchgeher 2017a) wurde ein Datenmodell erstellt. Dieses Datenmodell orientiert sich primär an diesem Metamodell und erfasst zusätzlich die bei den Anforderungen definierten Rückverfolgungen aller Tätigkeiten. Das Datenmodell, welches dem eigenen Review gestützten Werkzeug zugrunde liegt, wird in Abbildung 35 gezeigt. Wie im Abschnitt 4.1.2. erläutert wurde, können durch die Verwendung der Neo4j-Graphendatenbank die Informationen wie in Abbildung 35 visualisiert dargestellt ist auch in der Datenbank persistiert werden.

Abbildung 32: Ändern eines Elements des DataSets

Abbildung 33: Entfernen eines Elements aus dem DataSet

Abbildung 34: Anzeige eines Graphen


Der zentrale Knoten des Datenmodells ist der DesignArea Knoten. Dieser Knoten repräsentiert die Einheit eines Entscheidungsmodells und beinhaltet den Titel, die Beschreibung des Entscheidungsmodells, den Status ob veröffentlicht oder nicht, den Status vom Review ob gerade das Entscheidungsmodell gereviewt wird oder schon fertiggestellt wurde, die Positionen der einzelnen Elemente die visuell durch VisJS angezeigt werden, welches Referenzmodell das Original ist und in welche Kategorie beziehungsweise Subkategorie dieses Entscheidungsmodell fällt. Ein Entscheidungsmodell weist zusätzliche Beziehungen auf. Die Beziehung vom Typ HAS_CREATOR führt zum User Knoten. Der Status der Veröffentlichung soll den Nutzern zeigen, ob das Modell schon fertiggestellt ist oder eben noch daran gearbeitet wird. Dieser Benutzerknoten beinhaltet den Vor- und Nachnamen, sein Passwort, seinen Benutzernamen, sowie seine Email Adresse. Die Beziehung vom Typ HAS_CHANGED führt zum Log-Knoten. Dieser Aufzeichnungsknoten beinhaltet die Aktion, welche zur Änderung führte, die Wiederherstellungsaktion, sowie das Datum wann die Änderung gemacht wurde. Dieser Knoten hat natürlich auch eine Beziehung vom Typ HAS_CREATOR zum User-Knoten. Ein Entscheidungsmodell kann auch eine Beziehung zu sich selbst haben die vom Typ RELATED_TO_DA ist.

Abbildung 35: Datenmodell


Ein Entscheidungsmodell beinhaltet die Elemente Concern beziehungsweise DesignOption die durch die Beziehung HAS_POTENTIAL_CONCERN und analog dazu HAS_DESIGN_OPTION miteinander verbunden sind. Der Typ HAS_POTENTIAL_CONCERN beinhaltet die Begründung des Anliegens, die Anordnungsreihenfolge, einen Kommentar dafür, ob das Element sichtbar ist, sowie ob es sich um ein firmenspezifisches Element handelt und führt zum Concern-Knoten. Das Firmen auch spezielle Sonderfälle abdecken können, wurde eine Markierung für firmenspezifische Elemente eingeführt. Der Anliegen Knoten beinhaltet die Eigenschaften des Namens, der Definition, sowie der Begründung. Der Typ HAS_DESIGN_OPTION beinhaltet die Begründung der Entscheidungsoption, die Anordnungsreihenfolge, einen Kommentar dafür, ob das Element sichtbar ist, sowie ob es sich um ein firmenspezifisches Element handelt. Vom DesignOption-Knoten gibt es eine Beziehung zu dem Concern-Knoten. Die Beziehung vom Typ ADDRESSES_CONCERN beinhaltet die Begründung für das Anliegen, die Anordnungsreihenfolge, einen Kommentar dafür, ob das Element sichtbar ist, sowie ob es sich um ein firmenspezifisches Element handelt. Eine Entscheidungsoption kann auch ein Entscheidungsmodell beeinflussen diese Beziehung vom Typ AFFECTS_DA führt zum DesignArea-Knoten. Die Beziehung vom Typ AFFECTS_DA beinhaltet ebenso die Begründung für die Beeinflussung, die Anordnungsreihenfolge, einen Kommentar dafür, ob das Element sichtbar ist, sowie ob es sich um ein firmenspezifisches Element handelt. Eine Entscheidungsoption kann sich von einer anderen Entscheidungsoption ergänzen, dass wird mit der Beziehung COMPLEMENTS_DO dargestellt. Andererseits kann eine Entscheidungsoption auch eine Alternative zu einer Entscheidungsoption sein, dies wird mit der Beziehung ALTERNATIVE_DO dargestellt. Beide Beziehungen beinhalten dieselben Eigenschaften wie der Begründung, einen Kommentar dafür, sowie die Sichtbarkeit des Elements. Die Beziehungstypen HAS_IMPLICATION und REQUIRES_COMPONENT führen zum Implication-Knoten, respektive zum Component-Knoten. Die Beziehung HAS_IMPLICATION beinhaltet zu den Standardeigenschaften wie der Begründung der Auswirkung, der Anordnungsreihenfolge, dem Kommentar dafür, ob das Element sichtbar ist, sowie ob es sich um ein firmenspezifisches Element handelt, noch zusätzlich die Eigenschaften einer Gewichtung („Benefit“, „Benefit and Cost“, „Cost“) und ob es sich um eine wichtige Auswirkung handelt oder nicht. Der Implication-Knoten enthält die Eigenschaften des Namens, der Definition, der Begründung, sowie den Auswirkungstyp (System quality, Organization, Infrastructure). Die Beziehung REQUIRES_COMPONENT beinhaltet wieder die Standardeigenschaften wie die Begründung für einen spezifischen technischen Komponenten, die Anordnungsreihenfolge, einen Kommentar dafür, ob das Element sichtbar ist oder nicht, sowie ob es sich um ein firmenspezifisches Element handelt. Der TechnologyOption-Knoten kann entweder eine Entscheidungsoption oder eine spezifische technische Komponente implementieren, diese Beziehungen sind gekennzeichnet durch IMPLEMENTS_DO, respektive IMPLEMENTS_COMPONENT. Beide Beziehungen beinhalten dieselben Eigenschaften wie die Begründung der Implementierung, die Anordnungsreihenfolge,


einen Kommentar dafür, ob das Element sichtbar ist, sowie ob es sich um ein firmenspezifisches Element handelt.

4.3. Backend

Die zentrale Verwaltung der Entscheidungsmodelle findet in der Backend-Komponente statt, welches die Daten persistiert und aufbereitet. Diese Komponente stellt die Verbindung zur Graphendatenbank her, welches die Daten der Entscheidungsmodelle gemäß dem in Abschnitt 4.2. definierten Datenmodell abspeichert. Der Hauptfokus der Komponente liegt darauf REST-Schnittstellen zur Verfügung zu stellen, um eine zustandslose Kommunikation zum Frontend gewährleisten zu können. Die Backend-Komponente reagiert in dieser Form der Anwendung nur auf HTTP-Anfragen. Die Realisierung der REST-Schnittstellen basierte auf einer Schichtenarchitektur, die in Abbildung 36 zu sehen ist. Das Schichtenmodell enthält vier Ebenen, in der ersten Ebene sind die Controller, welche die Definition der REST-Schnittstellen nach außen repräsentieren. Die Controller rufen die nächste Ebene auf und zwar die jeweilig definierte Service-Methode für den Controller. Die Service-Klasse enthält pro REST-Schnittstellen Aufruf eine entsprechende Methode dafür. Die Service-Klassen enthalten keine Geschäftslogik, diese wird in der dritten Schicht der Business-Schicht implementiert. Die Service Methode übernimmt hierbei die Aufgabe, die Geschäftslogik mit den definierten Methoden entsprechend zu kombinieren. Der Zugriff auf die Graphendatenbank erfolgt über die letzte Schicht der Data Schicht. Hierbei holt die Geschäftslogik die nötigen Daten für die Abarbeitung der Logik aus dieser Schicht. Der Aufruf der Komponenten erfolgt über Interfaces, diese geschichtete Architektur soll den Austausch der Funktionsbereiche erleichtern.

Für die Implementierung der Backend-Komponente werden das Spring Boot Modul, das Web-MVC-Modul für die Definition der Rest-Schnittstellen und das Spring Data Neo4j Plug-In

Abbildung 36: Schichtenarchitektur


verwendet. Dieses Plug-In ermöglicht die einfache Verbindung zur Graphendatenbank. Die Kommunikation erfolgt über das HTTPS-Protokoll. Durch dieses Plug-In ist es ebenfalls möglich das Object-Graph Mapping Konzept einzusetzen. Dadurch können Domain-Objekte um Annotationen erweitert werden. Diese können danach direkt in die Graphendatenbank gespeichert werden. Ein Beispiel hierfür ist die Speicherung der Knoten in die Graphendatenbank, die mittels der NodeEntity-Annotation, welche für die Java Klasse definiert werden muss, erreicht wird. Eine Beziehung zwischen den Knoten kann über die Relationship-Annotation erreicht werden. In Abbildung 37 sieht man die Erweiterung des DesignArea-Elements mit der Spring Data Neo4j NodeEntitiy-Annotation. Durch diese Annotation wird automatisch eine Gruppe von vordefinierten Methoden zum Speichern und Abfragen in der Graphendatenbank zur Verfügung gestellt. Durch das Speichern eines DesignArea-Elements werden zusätzlich zum Knoten DesignArea auch die definierten Eigenschaften wie der Titel, die Beschreibung, der Veröffentlichungsstatus, der Reviewstatus, die JSON-Positionen der Elemente, das Referenzmodell, die Kategorie und die Subkategorie angelegt. Zusätzlich werden die Beziehungen, die mit der Relationship-Annotation angegeben werden, erzeugt. Die Abfrage eines Knoten erstellt automatisch ein Java Objekt mit den definierten Eigenschaften, die zugleich mit den Daten von der Datenbank befüllt sind.

Abbildung 37: Object Graph Mapping


Damit eine Transaktion zwischen der Graphendatenbank und dem Backend stattfinden kann, gibt es Repository-Klassen. Eine Repository-Klasse definiert jene Operationen, welche auf den Graphenknoten angewendet werden können. Somit ist für jeden Graphenknoten eine Repository-Klasse zu erstellen. Ein Beispiel hierfür ist Abbildung 38, die das Repository für den DesignArea-Knoten zeigt.

Eine Repository-Klasse stellt Standardoperationen zur Verfügung, welche durch das Spring Data Plug-In definiert wurden. Die Standardoperationen beinhalten das Speichern eines Knoten, das Finden eines einzelnen Knoten, das Finden aller Knoten, die Anzahl der Knoten, das Löschen eines Knoten oder die Überprüfung ob ein Knoten existiert. Dazu können wie Abbildung 38 zeigt noch eigene Operationen definiert werden. Eine Cypher-Query erlaubt es, benutzerdefinierte Abfragen an die Graphendatenbank zu erstellen. Die Query-Annotation definiert dafür die Abfrage an die Graphendatenbank und der nachstehende Methodenkopf wird der Query zugewiesen. Damit die Repository-Klassen in der Geschäftslogik vom Backend verwendet werden können, werden diese mit Hilfe der Autowired-Annotation in die Klassen eingebunden. Abbildung 39 zeigt die Einbindung in die Geschäftslogik und die Abfrage eines Entscheidungsmodelltitels mit der eindeutigen ID als Parameter.

Für die Schnittstellendokumentation wurde das in Punkt 4.1.3. vorgestellte Werkzeug Swagger verwendet. Die Swagger-Dokumentation bietet eine übersichtliche Darstellung der angebotenen Schnittstellen, siehe Abbildung 40.

Abbildung 38: Repository-Klasse

Abbildung 39: Transaktion zwischen Graphendatenbank und Backend


! Authentication-Controller

Der Authentication-Controller bietet die benötigten Schnittstellen für die Benutzerauthentifzierung.

! Comment-Controller

Der Comment-Controller enthält jene Schnittstellen die für die Kommentare der Entscheidungsmodelle benötigt werden.

! DesignArea-Controller

Der DesignArea-Controller bietet Schnittstellen für das Abfragen, Hinzufügen und Klonen von Entscheidungsmodellen. Zusätzlich werden auch Schnittstellen zum Ändern und Löschen von Entscheidungsmodellen zur Verfügung gestellt.

! DesignOption-Controller

Mit dem DesignOption-Controller werden Schnittstellen für das Abfragen, Hinzufügen, Ändern und Löschen von Entscheidungsoptionen angeboten.

! Log-Controller

Der Log-Controller bietet Schnittstellen für die Aufzeichnung und Abfrage von Veränderungen am Entscheidungsmodell.

! TechnologyOption-Controller

Der TechnologyOption-Controller bietet Schnittstellen für das Abfragen, Hinzufügen, Ändern und Löschen von Technologischen Optionen.

4.4. Frontend

Das Frontend dient für die Verwaltung der Entscheidungsmodelle durch den Benutzer, sowie der Visualisierung und Aufbereitung der vom Backend gelieferten Daten für ein Entscheidungsmodell.

4.4.1. Tab-Container

Im Frontend werden die Ansichten über die vordefinierten statischen Services von AngularJS navigiert. Die Ansichten befinden sich hierbei in einem Tab-Container, welcher auf ein Klick-

Abbildung 40: Swagger - Schnittstellenübersicht


Ereignis die nötigen Änderungen auslöst, wie neue Daten vom Backend holen und die dafür notwendige Ansicht laden. All

Der Tab All bietet dem Nutzer alle verfügbaren Entscheidungsmodelle. Die Ansicht besitzt einen bestimmten Zustand der beim Aufruf geladen wird, wie Abbildung 41 zeigt.

Der Benutzer ruft mit dem Klick auf All die in AngularJS definierte URL auf, der globale Service $stateProvider kümmert sich um die Navigation zum richtigen Zustand, welcher den Aufruf der Ansichten steuert. Die Ansichten beinhalten entweder eine HTML-Datei, welche geladen wird, oder direkt den HTML-Code und den in AngularJS eingesetzten Controller. Zusätzlich kann der Zustand dem Controller weitere Variablen als Parameter übergeben. Über resolve können diese Parameter definiert werden. Dieses Beispiel zeigt nach Aufruf der Default-URL werden die Ansichten der Entscheidungsmodellauflistung und der Kategorieauswahl aufgerufen, welche die fetchStrategy-Variable dem Controller mitübergeben. Under Review

Diese Ansicht besitzt ebenfalls einen Zustand, siehe Abbildung 42. Der Zustand enthält eine andere URL, jedoch dieselben views-Eigenschaften, da sich lediglich die Daten ändern die angezeigt werden und nicht die Ansicht selbst. Das bedeutet es wird eine andere fetchStrategy-Variable übergeben, die durch den Controller andere Daten vom Backend lädt und diese der Ansicht zur Verfügung stellt. Hier wird die aufrufende REST-Schnittstellen URL so angepasst, dass nur jene Entscheidungsmodelle, die einem selbst zugeordnet sind, zurückgeliefert werden.

Abbildung 41: Zustand - All


Review Finished

Diese Ansicht besteht ebenfalls aus einen Zustand, der sich zum Tab Under Review nur dadurch unterscheidet, dass hier die boolesche Variable des Entscheidungsmodells zum Überprüfen ob das Review bereits beendet wurde den Wert true aufweist.

My Models

Diese Ansicht besteht aus einem Zustand, der dieselben Parameter besitzt wie der All-Tab, ausgenommen der Prüfung des Autors.

Der Zustand definiert hier den Pfad, der vom vordefinierten statischen Service $stateProvider aufgerufen werden kann. Die URL definiert die Navigationsseite der Webseite. Die Anordnung der Views auf der Webseite wird über die Eigenschaft views gesetzt. Jede dieser Ansichten enthält eine definierte HTML Ansicht, die durch einen Controller, dass über das Model-View-ViewModel-Muster wie im Punkt 4.1.4. erläutert wurde, die benötigten Daten zur Anzeige liefert. Die Eigenschaft resolve überliefert den Controller die angegebene fetchStrategy-Variable mit dem Aufrufstyp, dass die ausgewählten Entscheidungsmodelle geladen werden sollen. Im Controller selbst wird dafür die entsprechende REST-Schnittstellen URL zusammengebaut.

4.4.2. Filter

Da es sehr viele Entscheidungsmodelle geben kann, wurde die Möglichkeit geschaffen, nach den Entscheidungsmodellen zu filtern. Einerseits kann die Filterung über die

Abbildung 42: Zustand - Under Review


Kategorieselektierung erfolgen. Andererseits kann auch nach bestimmten Entscheidungsmodelltiteln gesucht werden.

Kategorieauswahl

Die Kategorieauswahl zeigt zu Beginn alle Kategorien die bei den Entscheidungsmodellen geladen wurden. Zusätzlich zu den Kategorien werden deren Entscheidungsmodelle und Subkategorien summiert angezeigt. Nach Klick auf eine Kategorie wird der von AngularJS vordefinierte $filter-Service eingesetzt, welcher jedes Entscheidungsmodell gegen die gewählte Kategorie überprüft, wie Abbildung 43 zeigt.

Nach dem Klick werden nur noch die Entscheidungsmodelle der gewählten Kategorie angezeigt. Wenn die Kategorie noch Subkategorien beinhaltet, siehe Abbildung 44, dann kann auch auf die Subkategorien per Klick darauf gefiltert werden, da wie in Abbildung 43 zu sehen ist auch die gewählte Subkategorie zur Filterung mitgegeben wird.

Im Controller ist die aufgerufene Funktion definiert, siehe Abbildung 45. Die Funktion erhält von der Ansicht jedes Entscheidungsmodell Element und überprüft dieses ob die gewählte Kategorie beziehungsweise Subkategorie enthalten ist. Wenn das Entscheidungsmodell die gewählte Kategorie enthält wird dieses der Ansicht zurückgegeben und angezeigt. Wenn die Kategorie oder die Subkategorie nicht enthalten ist wird kein Element zurückgegeben.

Abbildung 43: Filter für Kategoriewahl

Abbildung 44: Subkategorieselektierung


Es gibt zusätzlich auch die Möglichkeit nach Kategorien beziehungsweise Subkategorien zu suchen um nach diesen zu filtern. Hierbei wird auf die zentrale Funktionalität der Datenbindung der Variablen von AngularJS zurückgegriffen. Durch eine Eingabe an der Ansicht hört der Controller mit $watch auf die Veränderung des Werts der Variable. Bei einem Ereignis filtert der Controller automatisch nach dem Namen der Kategorie beziehungsweise Subkategorie, wie Abbildung 46 zeigt.

Abbildung 45: Filtermethode

Abbildung 46: Kategoriefilter nach Name


Titelsuche

Genauso gibt es die Möglichkeit direkt nachdem Entscheidungsmodelltitel zu suchen. Hier wird wie bei der Filterung für Kategorienamen auf die $watch Veränderung einer Variable gewartet und auf Grund dieser Änderung gefiltert, die Funktionsweise ist analog zu der Namenskategorie Filterung.

4.4.3. Visualisierung

Ein Einsatzszenario ist das Erstellen und Editieren von Modellen zur Entscheidungsunterstützung in einer grafischen Darstellung. Abbildung 47 zeigt den Titel und die Beschreibung die für den Autor editierbar sind. Darunter wird dem Nutzer die Möglichkeit geboten ein Quick Item zu erstellen, dies bietet die Möglichkeit schnell und einfach ein neues Element einzufügen. Die Buttons Notation und Log sollen dem Nutzer helfen um einerseits das gewählte Metamodell zu verstehen und nach getätigten Schritten diese über das Log zu sehen und rückgängig machen zu können. Das Visualisierungsfeld liegt direkt unter diesen Buttons.

Beim Hinzufügen neuer Elemente müssen die übergebenen Daten für jedes spezifische Element im Controller aufbereitet werden. Dabei werden die von der Ansicht übermittelten Daten passend für den jeweiligen Backend-Controller aufbereitet und übermittelt. Zusätzlich werden die Daten in einen Knoten für das VisJS DataSet umgewandelt. Dies wird benötigt um den Knoten visualisiert am Zeichenblatt darstellen zu können. Hierfür sind folgende Attribute notwendig:

! Group

Die Gruppe definiert den Typ des Elements. Somit werden bei der Visualisierung des Elements die Eigenschaften des Typs, wie zum Beispiel die Hintergrundfarbe und die Darstellungsform bestimmt.

Abbildung 47: Visualisierungsansicht


! Label Das Label definiert den Namen des Knoten der visuell dargestellt wird.

! Title

Das Titel Attribut zeigt dem Benutzer ein Popup, wenn sich dieser mit der Maustaste über den Knoten befindet. Dieses Werkzeug verwendet das Titel Attribut für die Anzeige der Begründung, wie Abbildung 48 zeigt.

! ShapeProperties

Die Formeigenschaft definiert ein firmenspezifisches Element, dass eine unterbrochene Umrandung, anstatt einer durchgezogenen Umrandung anzeigt. In Abbildung 49 wird der Unterschied der Darstellung dargestellt.

! Comment Das Kommentar Attribut wird für die Anzeige eines Kommentars für das Element benötigt.

! Koordinatenpunkte

Für die Koordinatenpunkte x und y gibt es jeweils ein eigenes Attribut, damit der Knoten richtig auf den Zeichenblatt positioniert wird.

Abbildung 48: Begründungsanzeige

vs.

Abbildung 49: firmenspezifisches vs. normales Element


Beim Ziehen von neuen Relationen wird automatisch im Controller geprüft, ob diese Beziehung im Datenmodell abgebildet ist. Wenn ja, dann werden die Daten vom Startknoten und die Daten vom Endknoten aufbereitet und an das Backend gesendet. Hierbei steht die Prüfung auf den möglichen Beziehungstypen im Vordergrund, da dieser entscheidend ist, welche REST-Schnittstelle aufgerufen wird. Bei diesem Werkzeug sind alle Knoten Beziehungen eindeutig, bis auf jene zwischen zweier Entscheidungsoptionen, da eine Entscheidungsoption alternativ oder komplementär zu einer anderen Entscheidungsoption sein kann. Diese Unterscheidung der Relation wird anders, als bei den anderen Beziehungen gezogen und zwar mit einem rechten Mausklick auf den Startknoten und der Auswahl zwischen der „Add Alternative Design Option“-Option und „ Add Complement Design Option“-Option, wie Abbildung 50 zeigt. Nach Auswahl einer der Optionen kann die Relation zwischen den beiden Entscheidungsoptionen gezogen werden.

Die Beziehung eines Entscheidungsmodells zu einem ähnlichen Entscheidungsmodell wird nicht am Zeichenblatt visuell dargestellt, sondern als Tagging-Funktion neben dem Zeichenblatt angeboten. Hier hat der Benutzer die Möglichkeit, sich entweder alle Entscheidungsmodelle anzeigen zu lassen, wie Abbildung 51 zeigt oder mithilfe der Autocomplete-Funktion nur jene Entscheidungsmodelle, welche dem eingegebenen Wortmuster entsprechen, siehe Abbildung 52 anzeigen zu lassen. Diese Funktionen werden über eine Direktive gesteuert, welche zum Anzeigen der Daten alle Entscheidungsmodelle mit deren Titel lädt und zusätzlich die Attribute für das Hinzufügen eines neuen Tags, das Löschen eines Tags, das Klicken eines Tags beinhaltet. Diese Attribute haben alle Funktionen hinterlegt, welche zuständig sind für das Speichern in die Datenbank, das Löschen von der Datenbank, beziehungsweise das Springen zu dem ausgewählten Entscheidungsmodell. Ein weiteres wichtiges Attribut ist das Kennzeichen, dass nur Entscheidungsmodelle hinzugefügt werden können die geladen wurden. Bei der Autocomplete-Direktive wird das Attribut für das Anzeigen der Daten beim Betätigen des Pfeil-Zeigers nach unten und die Quelle der Daten, die überprüft werden, wenn eine Eingabe stattfindet, definiert.

Abbildung 50: Entscheidungsoptionsbeziehungen


4.4.4. Logaufzeichnungen

Jede Änderung an einem Entscheidungsmodell wird mitaufgezeichnet und in der Graphendatenbank gespeichert. Damit werden folgende Daten gespeichert:

! Bearbeiter ! Aktion die ausgeführt wurde ! Wiederherstellungsmechanismus

Der in der visualisierten Darstellung enthaltene Button für die Aufzeichnungs-Funktion zeigt alle Änderungen, siehe Abbildung 53. Eine Änderung kann durch Klick auf den Button, der links neben dem Bearbeiter positioniert ist, rückgängig gemacht werden.

Hierfür werden einfach die von der Graphendatenbank geladenen Änderungen in einer „ng-repeat“-Direktive dem Benutzer zur Verfügung gestellt, wie Abbildung 54 zeigt. Der Klick auf den Button löst die Wiederherstellung der Aktion aus.

Abbildung 51: Tagging alle Entscheidungsmodelle

Abbildung 52: Autocomplete für Tagging

Abbildung 53: Logdarstellung


In der Log-Direktive werden alle aufgezeichneten Veränderungen am Entscheidungsmodell zeitlich sortiert dargestellt. Jedem Eintrag wird der Wiederherstellungsbutton angehängt, welcher die Funktion zur Wiederherstellung der Aktion aufruft bei Betätigung. Außerdem wird dem Eintrag noch die Zeit der Änderung angehängt, diese wird ersichtlich wenn sich der Nutzer mit der Maus über dem Eintrag befindet.

4.4.5. Reviewzuweisung

Eine Reviewzuweisung für ein Entscheidungsmodell kann, wie im 3. Kapitel erklärt wurde, von einem normalen Benutzer oder einem Admin Benutzer durchgeführt werden. Deswegen wird im Frontend der Button für die Reviewzuweisung nur angezeigt, wenn ein Benutzer eingeloggt ist. Des Weiteren bekommt der Button die Anweisung für das Klonen des ausgewählten Entscheidungsmodells nach Klick auf diesen. Zusätzlich werden nur jene Entscheidungsmodelle für eine Reviewzuweisung freigegeben, welches kein Review eines Entscheidungsmodells ist. Ein Review eines Entscheidungsmodells ist ein Klon eines Entscheidungsmodells. Jedoch mit der Unterscheidung, dass das Attribut des Referenzmodells die eindeutige ID des Entscheidungsmodells ist, welches reviewt wird. Die Abbildung 55 zeigt die Button-Direktive für die Reviewzuweisung.

Die Button-Direktive prüft, ob der Benutzer eingeloggt ist und ob es sich um ein Referenzmodell handelt, wenn diese Bedingungen erfüllt sind wird dem Benutzer ein Button angezeigt, welcher die Funktion des Klonens bei Betätigung aufruft.

4.4.6. Review

Beim Review können Elemente und Beziehungen erstellt, kommentiert, geändert beziehungsweise gelöscht werden. Ein Benutzer mit der Rolle Admin hat nun die Möglichkeit sich aus dem erstellten Review einen Bericht generieren zu lassen, welcher einen Überblick über das Review gibt, wie Abbildung 56 zeigt. Dieser Bericht lädt alle Logaufzeichnung des Reviews, bereitet diese Daten tabellarisch auf und kreiert mit diesen Daten eine PDF-Datei, siehe Abbildung 57.

Abbildung 54: Log-Direktive

Abbildung 55: Reviewzuweisung - Direktive


Die Funktion öffnet ein neues Fenster, holt sich den aktuellen Benutzer der sich diesen Report generieren lässt, ruft die REST-Schnittstelle für die Logaufzeichnungen auf und legt den Titel des Reports fest. Die Reportdaten werden nun in einer tabellarischen Form aufbereitet und als PDF-Datei erstellt. Die erstellte PDF-Datei wird nun in dem neuen Fenster geladen.

Abbildung 56: Report

Abbildung 57: Report - Funktion


5. Zusammenfassung

Dieses Kapitel beinhaltet einen kurzen Überblick über die behandelten Themen dieser Arbeit. Des Weiteren wird ein Ausblick mit möglichen Erweiterungen des entwickelten Werkzeugs beschrieben.

5.1. Fazit

Zusammenfasend kann gesagt werden, dass das entwickelte Werkzeug für das Review-gestützte Erstellen von Software Architekturwissen eine Hilfestellung für das Forschungsprojekt, des Instituts für Wirtschaftsinformatik – Software Engineering, darstellt. Das Speichern von explizitem Wissen wird durch das Werkzeug ebenso unterstützt, wie ein Review Prozess, welcher Schwachpunkte von Architekturentscheidungen aufdecken sollte. Mit diesem Werkzeug ist es nun möglich, eine Menge von Entscheidungsmodellen zu verwalten und über ein Review-basiertes Verfahren von Experten validieren zu lassen. Für das Review werden Experten als Reviewer eingesetzt und nicht die breite Masse, wie im Punkt 2.2.1. erläutert.

5.2. Ausblick

Abschließend ein kurzer Ausblick über mögliche Erweiterungen des Werkzeugs. Das in dieser Arbeit vorgestellte Werkzeug unterstützt bisweilen das Erstellen von Architekturwissen und den Review von Architekturwisssens. Folgend werden noch mögliche Erweiterung aufgelistet. ! Empfehlungssystem

Architekten und mögliche andere Stakeholder besitzen oft nicht im jedem Bereich das notwendige Know-how um Entscheidungen treffen zu können. Dafür wäre es sinnvoll, den Stakeholdern eine Entscheidungsempfehlung zur Verfügung zu stellen. Dies soll auf Basis eingegebener Anliegen, Anforderungen oder Ziele implementiert werden.

! Dokumentation von Entscheidungen

Entscheidungen bezüglich der Software Architektur werden oft aufgrund von Zeitmangel nicht ausreichend dokumentiert. Durch die Verwendung von Entscheidungsmodellen, welche mögliche verschiedene Design Optionen ohnehin enthalten, wäre es möglich, eine Dokumentation mit wenig Zeitaufwand zu erstellen.

! Motivation der Teilnehmer Beim letzten Punkt geht es um die Motivation der Review Teilnehmer. Dies ist aus mehreren Hinsichten wichtig. Einerseits will man mehr Teilnehmer zum Review motivieren. Andererseits sollen die bereits gewonnenen Teilnehmer möglichst aktiv bleiben und viele verschiedene Bereiche reviewen. Dies hat zur Folge, dass die Entscheidungsmodelle öfter gereviewt werden, was sich positiv auf die Qualität der Modelle auswirkt. Dabei könnte eine Art Belohnungssystem für Review Teilnehmer eingeführt werden.


Abbildungsverzeichnis Abbildung 1: Entscheidungs-Richtlinien Metamodell (Haselböck, Weinreich und Buchgeher 2017a) ......................................................................................................................................... 14 Abbildung 2: Metamodell Beispiel ............................................................................................... 15 Abbildung 3: Peer Review Prozess (Woodward-Pratt 2017) ....................................................... 18 Abbildung 4: BPMN-Modell - Reviewprozess .............................................................................. 29 Abbildung 5: Subprozess - Neues Entscheidungsmodell erstellen ............................................. 30 Abbildung 6: Subprozess - Review eines ausgewählten Entscheidungsmodells ........................ 31 Abbildung 7: Menü-Reiter ............................................................................................................ 34 Abbildung 8: Menü-Reiter - All ..................................................................................................... 35 Abbildung 9: Menü-Reiter - Under Review .................................................................................. 35 Abbildung 10: Menü-Reiter - Review Finished ............................................................................ 35 Abbildung 11: Menü-Reiter - My Models ..................................................................................... 36 Abbildung 12: User-Menü - Decision Models .............................................................................. 36 Abbildung 13: Titelsuche ............................................................................................................. 37 Abbildung 14: Kategoriefilter ....................................................................................................... 37 Abbildung 15: Button - Review .................................................................................................... 38 Abbildung 16: Benutzerauswahldialog ........................................................................................ 38 Abbildung 17: Button - Report ..................................................................................................... 39 Abbildung 18: Button - Plus ......................................................................................................... 39 Abbildung 19: Button - Delete ...................................................................................................... 40 Abbildung 20: Bestätigungsdialog zum Löschen ......................................................................... 40 Abbildung 21: Neues Element hinzufügen rechter Mausklick ..................................................... 41 Abbildung 22: Dialogfenster für neues Element .......................................................................... 41 Abbildung 23: Neues Element hinzufügen Quick Item ................................................................ 42 Abbildung 24: Neues Quick Item Element ................................................................................... 42 Abbildung 25: Kommentieren vom Entscheidungsmodell ........................................................... 44 Abbildung 26: Änderungsaufzeichnungen ................................................................................... 44 Abbildung 27: Referenzmodellansicht ......................................................................................... 45 Abbildung 28: Graphergebnis vom Browser ................................................................................ 48 Abbildung 29: Schnittstellenübersicht .......................................................................................... 49 Abbildung 30: DataSet Beispiel ................................................................................................... 51 Abbildung 31: HInzufügen von Elementen zum DataSet ............................................................ 51 Abbildung 32: Ändern eines Elements vom DataSet ................................................................... 52 Abbildung 33: Entfernen eines Elements aus dem DataSet ........................................................ 52 Abbildung 34: Anzeige eines Graphen ........................................................................................ 52 Abbildung 35: Datenmodell ......................................................................................................... 53 Abbildung 36: Schichtenarchitektur ............................................................................................. 55 Abbildung 37: Object Graph Mapping ......................................................................................... 56 Abbildung 38: Repository-Klasse ................................................................................................ 57 Abbildung 39: Transaktion zwischen Graphendatenbank und Backend ..................................... 57 Abbildung 40: Swagger - Schnittstellenübersicht ........................................................................ 58 Abbildung 41: Zustand - All ......................................................................................................... 59 Abbildung 42: Zustand - Under Review ....................................................................................... 60 Abbildung 43: Filter für Kategoriewahl ......................................................................................... 61 Abbildung 44: Subkategorieselektierung ..................................................................................... 61 Abbildung 45: Filtermethode ........................................................................................................ 62 Abbildung 46: Kategoriefilter nach Name .................................................................................... 62


Abbildung 47: Visualisierungsansicht .......................................................................................... 63 Abbildung 48: Begründungsanzeige ............................................................................................ 64 Abbildung 49: firmenspezifisches vs. normales Element ............................................................ 64 Abbildung 50: Entscheidungsoptionsbeziehungen ...................................................................... 65 Abbildung 51: Tagging alle Entscheidungsmodelle ..................................................................... 66 Abbildung 52: Autocomplete für Tagging .................................................................................... 66 Abbildung 53: Logdarstellung ...................................................................................................... 66 Abbildung 54: Log-Direktive ........................................................................................................ 67 Abbildung 55: Reviewzuweisung - Direktive ................................................................................ 67 Abbildung 56: Report ................................................................................................................... 68 Abbildung 57: Report - Funktion .................................................................................................. 68 Tabellenverzeichnis Tabelle 1: Einordnung der Review Anwendungsbereiche in die Klassifikation ........................... 25 Tabelle 2: Funktionalitäten Übersicht .......................................................................................... 33


Literaturverzeichnis 1. amazon.com. 2017. Über Kundenrezensionen. Einzelhandelswebseite. Amazon.de

Hilfe: Über Kundenrezensionen. 14. August. https://www.amazon.de/gp/help/customer/display.html?nodeId=201470700 (zugegriffen: 14. August 2017).

2. Atwood, Michael E. und John Horner. 2007. Redesigning the Rationale for Design

Rationale. In: Human-Computer Interaction. Interaction Design and Usability, 11–19. Springer, Berlin, Heidelberg, 22. Juli. doi:10.1007/978-3-540-73105-4_2, https://link.springer.com/chapter/10.1007/978-3-540-73105-4_2 (zugegriffen: 13. Juli 2017).

3. Bosch, Jan. 2004. Software Architecture: The Next Step. In: Software Architecture,

194–199. Springer, Berlin, Heidelberg, 21. Mai. doi:10.1007/978-3-540-24769-2_14, https://link.springer.com/chapter/10.1007/978-3-540-24769-2_14 (zugegriffen: 3. Juli 2017).

4. Bradbury, Jeremy, James Cordy, Juergen Dingel und Michel Wermelinger. 2004. A

Survey of Self-management in Dynamic Software Architecture Specifications. In: , 28–33. ACM. doi:10.1145/1075405.1075411, http://dx.doi.org/10.1145/1075405.1075411 (zugegriffen: 12. Juli 2017).

5. Brosius, Christoph und Ralf Schmidt. 2015. Moment mal! HMD Praxis der

Wirtschaftsinformatik 52, Nr. 6 (1. Dezember): 813–815. doi:10.1365/s40702-015-0182-9, (zugegriffen: 6. Juni 2017).

6. Brownlee, Christen. 2006. Peer review under the microscope: One journal’s

experiment aims to change science vetting. Science News 170, Nr. 25 (16. Dezember): 392–393. doi:10.2307/4017427, (zugegriffen: 9. August 2017).

7. Carniol, Karen, John Pham und Meredith LeMasurier. 2014. Experimenting with

collaborative peer review. Reviewers’ Update. November. https://www.elsevier.com/reviewers-update/story/innovation-in-publishing/experimenting-with-collaborative-peer-review (zugegriffen: 6. Juni 2017).

8. charitynavigator.org. 2017. FAQs. Charity Navigator. 14. August.

http://www.charitynavigator.org/index.cfm?bay=content.view&cpid=4580 (zugegriffen: 14. August 2017).

9. Dabholkar, Pratibha A. 2006. Factors Influencing Consumer Choice of a „Rating

Web Site“: An Experimental Investigation of an Online Interactive Decision Aid. Journal of Marketing Theory and Practice 14, Nr. 4: 259–273. doi:10.2307/40470901, (zugegriffen: 9. August 2017).

10. Dalkir, Kimiz. 2011. Knowledge management in theory and practice. 2nd ed.

Cambridge, Mass: MIT Press. 11. Davenport, Thomas H. und Laurence Prusak. 1998. Working Knowledge: How

Organizations Manage what They Know. Harvard Business Press.


12. Dingsøyr, Torgeir und Hans van Vliet. 2009. Introduction to Software Architecture

and Knowledge Management. In: Software Architecture Knowledge Management, 1–17. Springer, Berlin, Heidelberg. https://link.springer.com/chapter/10.1007/978-3-642-02374-3_1 (zugegriffen: 12. Juli 2017).

13. Dutoit, Allen H., Raymond McCall, Ivan Mistrík und Barbara Paech. 2006.

Rationale Management in Software Engineering: Concepts and Techniques. In: Rationale Management in Software Engineering, 1–48. Springer, Berlin, Heidelberg. https://link.springer.com/chapter/10.1007/978-3-540-30998-7_1 (zugegriffen: 17. Juli 2017).

14. elsevier.com. 2017. What is peer review? Verlag. What is peer review?. 13.

September. https://www.elsevier.com/reviewers/what-is-peer-review (zugegriffen: 13. September 2017).

15. Farenhorst, Rik und Remco C. de Boer. 2009. Knowledge Management in

Software Architecture: State of the Art. In: Software Architecture Knowledge Management, 21–38. Springer, Berlin, Heidelberg. https://link.springer.com/chapter/10.1007/978-3-642-02374-3_2 (zugegriffen: 12. Juli 2017).

16. Green, Brad und Shyam Seshadri. 2013. AngularJS. 1. Aufl. Beijing ; Sebastopol,

CA: O’Reilly & Associates. 17. Harrison, N. B., P. Avgeriou und U. Zdun. 2007. Using Patterns to Capture

Architectural Decisions. IEEE Software 24, Nr. 4 (Juli): 38–45. doi:10.1109/MS.2007.124, .

18. Haselböck, Stefan, Rainer Weinreich und Georg Buchgeher. 2017a. Decision

Guidance Models for Microservices – Service Discovery and Fault Tolerance. In: . Larnaca, Cyprus, August.

19. ---. 2017b. Decision Models for Microservices – Design Areas, Stakeholders, Use

Cases, and Requirements. In: . Canterbury, September. 20. Hornbostel, Stefan und Dagmar Simon, Hrsg. 2006. Wie viel (In-)Transparenz ist

notwendig? : peer Review revisited. iFQ-Working Paper 1. Bonn. http://nbn-resolving.de/urn:nbn:de:0168-ssoar-39867 (zugegriffen: 7. August 2017).

21. Hwang, Yuan-Chu, Soe-Tsyr Yuan und Jung-Hui Weng. 2011. A study of the

impacts of positive/negative feedback on collective wisdom—case study on social bookmarking sites. Information Systems Frontiers 13, Nr. 2 (1. April): 265–279. doi:10.1007/s10796-009-9186-8, (zugegriffen: 4. Juli 2017).

22. IEEE Draft Standard for Software Reviews and Audits (Revison of IEEE 1028-

1997). 2008. IEEE Draft Standard for Software Reviews and Audits (Revison of IEEE 1028-1997). IEEE Unapproved Draft Std P1028_Draft7.0, Feb 2008.

23. IEEE Std 610.12-1990. 1990. IEEE Std 610.12-1990. IEEE Std 610.12-1990

(Dezember): 1–84. doi:10.1109/IEEESTD.1990.101064, .


24. ISO/IEC/IEEE 42010. 2011. ISO/IEC/IEEE Systems and software engineering –

Architecture description. ISO/IEC/IEEE 42010:2011(E) (Revision of ISO/IEC 42010:2007 and IEEE Std 1471-2000) (Dezember): 1–46. doi:10.1109/IEEESTD.2011.6129467, .

25. Jansen, A. und J. Bosch. 2005. Software Architecture as a Set of Architectural

Design Decisions. In: 5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05), 109–120. doi:10.1109/WICSA.2005.61, .

26. Johnson, Rod, Juergen Hoeller, Keith Donald, Colin Sampaleanu, Rob Harrop,

Thomas Risberg, Alef Arendsen, u. a. 2017. Spring Framework Reference Documentation. Entwicklerseite. Spring Framework Reference Documentation. 22. September. https://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/ (zugegriffen: 22. September 2017).

27. Joo, Jaehun und Ismatilla Normatov. 2013. Determinants of collective intelligence

quality: comparison between Wiki and Q&A services in English and Korean users. Service Business 7, Nr. 4 (1. Dezember): 687–711. doi:10.1007/s11628-013-0183-0, (zugegriffen: 4. Juli 2017).

28. Khan, Khalid S, Regina Kunz, Jos Kleijnen und Gerd Antes. 2003. Five steps to

conducting a systematic review. Journal of the Royal Society of Medicine 96, Nr. 3 (März): 118–121. (zugegriffen: 9. August 2017).

29. Kruchten, Philippe, Patricia Lago und Hans van Vliet. 2006. Building Up and

Reasoning About Architectural Knowledge. In: Quality of Software Architectures, 43–58. Springer, Berlin, Heidelberg, 27. Juni. doi:10.1007/11921998_8, https://link.springer.com/chapter/10.1007/11921998_8 (zugegriffen: 19. Juni 2017).

30. Kumar, Janaki Mythily und Mario Herger. 2013. Gamification at Work: Designing

Engaging Business Software. s.l.: The Interaction Design Foundation. 31. Lago, Patricia und Paris Avgeriou. 2006. First Workshop on Sharing and Reusing

Architectural Knowledge. SIGSOFT Softw. Eng. Notes 31, Nr. 5 (September): 32–36. doi:10.1145/1163514.1163526, (zugegriffen: 3. Juli 2017).

32. Lamsweerde, Axel van. 2003. From System Goals to Software Architecture. In:

Formal Methods for Software Architectures, 25–43. Springer, Berlin, Heidelberg, 22. September. doi:10.1007/978-3-540-39800-4_2, https://link.springer.com/chapter/10.1007/978-3-540-39800-4_2 (zugegriffen: 12. Juli 2017).

33. Leath, C.L. und S.J. Ollanik. 1983. Software Architecture for the Implementation of

a Computer-Aided Engineering System. In: , 137–142. IEEE. doi:10.1109/DAC.1983.1585639, http://ieeexplore.ieee.org/document/1585639/ (zugegriffen: 2. Oktober 2017).

34. Leimeister, Jan Marco. 2010. Collective Intelligence. Business & Information

Systems Engineering 2, Nr. 4 (1. August): 245–248. doi:10.1007/s12599-010-0114-8, (zugegriffen: 10. Juli 2017).


35. Lewis, Grace A., Patricia Lago und Paris Avgeriou. 2016. A Decision Model for

Cyber-Foraging Systems. In: 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), 51–60. Venice, Italy: IEEE, April. doi:10.1109/WICSA.2016.38, .

36. Linz, Tilo und Andreas Spillner. 2012. Basiswissen Softwaretest: Aus- und

Weiterbildung zum Certified Tester - Foundation Level nach ISTQB-Standard. dpunkt.verlag.

37. Lykourentzou, Ioanna, Katerina Papadaki, Dimitrios J. Vergados, Despina Polemi

und Vassili Loumos. 2010. CorpWiki: A self-regulating wiki to promote corporate collective intelligence through expert peer matching. Information Sciences 180, Nr. 1. Special Issue on Collective Intelligence (2. Januar): 18–38. doi:10.1016/j.ins.2009.08.003, (zugegriffen: 10. Juli 2017).

38. MacLean, Allan, Richard M. Young, Victoria M. E. Bellotti und Thomas P. Moran.

1991. Questions, Options, and Criteria: Elements of Design Space Analysis. Hum.-Comput. Interact. 6, Nr. 3: 201–250. doi:10.1207/s15327051hci0603&4_2, .

39. Masak, Dieter. 2009. Der Architekturreview: Vorgehensweise, Konzepte und

Praktiken. Springer-Verlag. 40. Miller, R.C., D.A. Wade und C. Wallis. 1984. Data general desktop generation

model 10: Architecture and implementation. Proceedings of the IEEE 72, Nr. 3: 312–321. doi:10.1109/PROC.1984.12862, (zugegriffen: 2. Oktober 2017).

41. Mudambi, Susan M. und David Schuff. 2010. What Makes a Helpful Review? A

Study of Customer Reviews on Amazon.com. SSRN Scholarly Paper. Rochester, NY: Social Science Research Network. https://papers.ssrn.com/abstract=2175066 (zugegriffen: 9. August 2017).

42. Müller, Uwe Thomas. 2009. Peer-Review-Verfahren zur Qualitätssicherung von

Open-Access-Zeitschriften. Humboldt-Universität zu Berlin, Philosophische Fakultät I, 22. Januar. https://edoc.hu-berlin.de/handle/18452/16537 (zugegriffen: 7. August 2017).

43. Myers, Glenford J., Corey Sandler und Tom Badgett. 2011. The Art of Software

Testing. 3. Aufl. Hoboken, N.J: John Wiley & Sons. 44. Nava, Francisco, Rafael Capilla und Juan C. Dueñas. 2007. Processes for

Creating and Exploiting Architectural Design Decisions with Tool Support. In: Software Architecture, 321–324. Springer, Berlin, Heidelberg, 24. September. doi:10.1007/978-3-540-75132-8_34, https://link.springer.com/chapter/10.1007/978-3-540-75132-8_34 (zugegriffen: 26. Juni 2017).

45. Neidhardt, Friedhelm. 2006. Fehlerquellen und Fehlerkontrollen in den

Begutachtungssystemen der Wissenschaft. In: Wie viel (in-)Transparenz ist notwendig? - Peer Review Revisited. Institut für Wirtschaftsinformatik, Universität Göttingen. http://www.forschungsinfo.de/Publikationen/Download/working_paper_1_2006.pdf.


46. Nonaka, Ikujiro und Hirotaka Takeuchi. 1995. The Knowledge-Creating Company:

How Japanese Companies Create the Dynamics of Innovation. Oxford, New York: Oxford University Press.

47. Otterbacher, Jahna. 2011. Being Heard in Review Communities: Communication

Tactics and Review Prominence. Journal of Computer-Mediated Communication 16, Nr. 3 (1. April): 424–444. doi:10.1111/j.1083-6101.2011.01549.x, (zugegriffen: 8. August 2017).

48. Ouellet, Hubert, Margarida Romero und Kimberly Sawchuk. 2017. Promoting

Intergenerational Participation Through Game Creation Activities. In: Game-Based Learning Across the Lifespan, hg. von Margarida Romero, Kimberly Sawchuk, Josep Blat, Sergio Sayago, und Hubert Ouellet, 79–89. Advances in Game-Based Learning. Springer International Publishing. http://link.springer.com/chapter/10.1007/978-3-319-41797-4_6 (zugegriffen: 13. Juni 2017).

49. Pelechrinis, Konstantinos, Vladimir Zadorozhny, Velin Kounev, Vladimir

Oleshchuk, Mohd Anwar und Yiling Lin. 2015. Automatic evaluation of information provider reliability and expertise. World Wide Web 18, Nr. 1 (1. Januar): 33–72. doi:10.1007/s11280-013-0249-x, (zugegriffen: 4. Juli 2017).

50. Petticrew, Mark und Helen Roberts. 2008. Why Do We Need Systematic Reviews?

In: Systematic Reviews in the Social Sciences: A Practical Guide, 1–26. Blackwell Publishing Ltd, 11. Januar. http://onlinelibrary-1wiley-1com-1m6nkvr7o00af.han.ubl.jku.at/doi/10.1002/9780470754887.ch1/summary (zugegriffen: 9. August 2017).

51. Pokorný, Jaroslav. 2015. Graph Databases: Their Power and Limitations. In:

SpringerLink, 58–69. Springer, Cham, 24. September. doi:10.1007/978-3-319-24369-6_5, https://link-1springer-1com-1um9stg060046.han.ubl.jku.at/chapter/10.1007/978-3-319-24369-6_5 (zugegriffen: 29. August 2017).

52. Regli, W. C., X. Hu, M. Atwood und W. Sun. 2000. A Survey of Design Rationale

Systems: Approaches, Representation, Capture and Retrieval. Engineering with Computers 16, Nr. 3-4 (1. Dezember): 209–235. doi:10.1007/PL00013715, (zugegriffen: 13. Juli 2017).

53. Reinmann, Gabi, Silvia Sippel und Christian Spannagel. Peer Review für Forschen

und Lernen: Funktionen, Formen, Entwicklungschancen und die Rolle der digitalen Medien. https://www.researchgate.net/publication/242576193_Peer_Review_fur_Forschen_und_Lernen_Funktionen_Formen_Entwicklungschancen_und_die_Rolle_der_digitalen_Medien (zugegriffen: 7. August 2017).

54. Romero, M. und N. Lambropoulos. 2015. Digital game creation as a creative

learning activity. In: 2015 International Conference on Interactive Mobile Communication Technologies and Learning (IMCL), 338–342. November. doi:10.1109/IMCTL.2015.7359615, .


55. Rösler, Peter, Ralf Kneuper und Maud Schlich. 2013. Reviews in der System- und

Softwareentwicklung: Grundlagen, Praxis, kontinuierliche Verbesserung. dpunkt.verlag.

56. Sakamoto, Mizuki, Tatsuo Nakajima und Sayaka Akioka. 2017. Gamifying

collective human behavior with gameful digital rhetoric. Multimedia Tools and Applications 76, Nr. 10 (1. Mai): 12539–12581. doi:10.1007/s11042-016-3665-y, (zugegriffen: 12. Juni 2017).

57. Sataloff, Robert T. 2011. Peer Review in Publication. Journal of Singing 68, Nr. 1

(1. September): 45. (zugegriffen: 9. August 2017). 58. Schlag, Bernhard. 2013. Intrinsische und extrinsische Motivation. SpringerLink:

21–26. doi:10.1007/978-3-531-18959-8_4, (zugegriffen: 9. August 2017). 59. Silani, Giorgia. 2017. Wie Belohnungen unser Verhalten steuern. Universität Wien.

6. Juni. https://medienportal.univie.ac.at/uniview/forschung/detailansicht/artikel/wie-belohnungen-unser-verhalten-steuern/ (zugegriffen: 6. Juni 2017).

60. Smith, Donnavieve, Satya Menon und K. Sivakumar. 2005. Online peer and

editorial recommendations, trust, and choice in virtual markets. Journal of Interactive Marketing 19, Nr. 3 (1. Juni): 15–37. doi:10.1002/dir.20041, (zugegriffen: 14. August 2017).

61. spring.io. 2017a. Spring Boot. Entwicklerseite. Spring Boot. 22. September.

http://projects.spring.io/spring-boot/ (zugegriffen: 22. September 2017). 62. ---. 2017b. Web MVC framework. Entwicklerseite. 22. Web MVC framework. 22.

September. https://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html (zugegriffen: 22. September 2017).

63. ---. 2017c. Spring Data Neo4j. Entwicklerseite. Spring Data Neo4j. 22. September.

http://projects.spring.io/spring-data-neo4j/ (zugegriffen: 22. September 2017). 64. Steiger, Thomas und Eric Lippmann, Hrsg. 2013. Handbuch Angewandte

Psychologie für Führungskräfte. Berlin, Heidelberg: Springer Berlin Heidelberg. http://link.springer.com/10.1007/978-3-642-34357-5 (zugegriffen: 1. August 2017).

65. Stiegler, Andreas und Gottfried Zimmermann. 2014. Gamification in the

Development of Accessible Software. In: Universal Access in Human-Computer Interaction. Design and Development Methods for Universal Access, 171–180. Springer, Cham, 22. Juni. doi:10.1007/978-3-319-07437-5_17, https://link.springer.com/chapter/10.1007/978-3-319-07437-5_17 (zugegriffen: 13. Juni 2017).

66. Suls, Jerry und René Martin. 2009. The Air We Breathe: A Critical Look at

Practices and Alternatives in the Peer-Review Process. Perspectives on Psychological Science: A Journal of the Association for Psychological Science 4, Nr. 1 (Januar): 40–50. doi:10.1111/j.1745-6924.2009.01105.x, .


67. swagger.io. 2017. Swagger. Entwicklerseite. Home - Swagger. 22. September. https://swagger.io/ (zugegriffen: 22. September 2017).

68. Tananbaum, Greg und Lyndon Holmes. 2008. The evolution of Web-based peer-

review systems. Learned Publishing 21, Nr. 4 (Oktober): 300–306. doi:10.1087/095315108X356734, (zugegriffen: 6. Juni 2017).

69. Taylor, Richard N., Nenad Medvidovic und Eric Dashofy. 2009. Software

Architecture: Foundations, Theory, and Practice. 1. Aufl. Hoboken, NJ: John Wiley & Sons.

70. tripadvisor.com. 2017. Wie schreibe ich eine Bewertung? TripAdvisor Hilfe. 14.

August. http://www.tripadvisorsupport.com/hc/de/articles/200614877-Wie-schreibe-ich-eine-Bewertung- (zugegriffen: 14. August 2017).

71. VISJS. 2017. vis.js - A dynamic, browser based visualization library. Technologie.

vis.js - A dynamic, browser based visualization library. 30. August. http://visjs.org (zugegriffen: 30. August 2017).

72. Vogel, Oliver, Ingo Arnold, Arif Chughtai, Edmund Ihler, Timo Kehrer, Uwe Mehlig

und Uwe Zdun. 2009. Software-Architektur. Heidelberg: Spektrum Akademischer Verlag. http://link.springer.com/10.1007/978-3-8274-2267-5 (zugegriffen: 23. Mai 2017).

73. Weinreich, Rainer und Georg Buchgeher. 2009. Software Architecture

Engineering. 74. Weinreich, Rainer und Iris Groher. 2016. Software architecture knowledge

management approaches and their support for knowledge management activities: A systematic literature review. Information and Software Technology 80 (1. Dezember): 265–286. doi:10.1016/j.infsof.2016.09.007, .

75. Wolf, Alexander L. und Dewayne E. Perry. 1992. Foundations for the Study of

Software Architecture. ACM SIGSOFT Software Engineering Notes 17: 40–52.

Documents

Beurteiler / Beurteilerin Ass.-Prof. Dipl.-Ing. Dr. Ein