Leseprobe
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1. Einleitung
1.1 Motivation und Problematik
1.2 Zielsetzung
1.3 Abgrenzung
1.4 Aufbau der Arbeit
1.5 Sprachliche Konventionen
2. Grundlagen
2.1 Software-Architektur
2.2 Semantic Web
2.3 Webservices
2.4 Chatbots
2.5 Konversations-Assistenten
2.6 Begrifflichkeiten im Kontext
3. Sollkonzeption
3.1 Systemkurzbeschreibung
3.2 Anforderungsermittlung
3.2.1 Anforderungsübersicht
3.2.2 Anwendungsfälle
3.2.3 Prozesse
3.2.4 Systemumgebung
3.2.5 Funktionale- und nichtfunktionale Anforderungen
3.3 Evaluierung der Umsetzungsmöglichkeiten
3.3.1 Direkte Kommunikationslösung
3.3.2 Individuelle Applikationslösung
3.3.3 Portallösung
3.3.4 SWS-Lösung
3.3.5 Eigene-Schnittstellenlösung
3.3.6 Evaluierung der Umsetzungsmöglichkeiten
3.4 Standardisierter Datenaustausch
3.5 Ganzheitliche Umsetzungslösung
4. Entwurf und Architektur
4.1 Systemkontext
4.1.1 (Micro-)Applikation
4.1.2 Chatbot
4.1.3 (Haupt-)System
4.2 Prozesse
4.2.1 Systemanfrage / Hauptprozess
4.2.2 Asynchrone Datengewinnung
4.2.3 (Unternehmens-)Schnittstellenregistrierung/ -suche
4.2.4 Benutzererkennung
4.2.5 Datenanfrage klären
4.2.6 Prozessverarbeitung
4.3 Prinzipien/ Policy
4.3.1 Makro-Architektur
4.3.2 Micro-Architektur
4.4 Design-Pattern
4.5 Datenhaltung
4.5.1 Systemeigene Datenhaltung
4.5.2 Datenbereitstellung im Unternehmen
4.5.3 Prozessbereitstellung im Unternehmen
4.6 Interaktionsdesign
4.6.1 Grafische Benutzerschnittstelle
4.6.2 Natürliche Benutzerschnittstelle
5. Bewertung
5.1 Chancen für Unternehmen am Markt
5.1.1 Vertriebsmittel
5.1.2 Support-Mittel
5.1.3 Marketingmittel
5.2 Sicherheitsaspekte
5.2.1 Chatbot und AI
5.2.2 Datenschutz
5.2.3 Schnittstellenlösung
5.3 Vollständigkeit
5.3.1 Authentifizierung
5.3.2 Plattformen
5.3.3 Payment
6. Ergebnis
6.1 Ausblick
6.2 Erweiterungen
6.2.1 Home Documents for HTTP APIs
6.2.2 Web Payments
5.2.3 Web Authentication & WebSocket API
6.2.4 Direkte Implementierung
6.3 Kritik und Fazit
Literaturverzeichnis
7. Anhang
A Funktionale Systemanforderungen
B Nicht-funktionale Systemanforderungen
C Kriterienbeschreibung der Evaluation
D Sprachliche Konventionen dieser Arbeit
Abstract (english): Due to the technological developments and the recent efforts of large IT corporations regarding intelligent assistants (Siri, Cortana, Alexa, Google Assistant, ...), this scientific article will clarify the question of whether conversation assistants can be enabled to steer several companies, with different structures and services, by means of a central application, to enable an all-encompassing application.
Existing technologies in the system context will be examined. The design of the sought-after system is subject to requirements corresponding to the initial question and which can be implemented with existing technologies. In addition, the current model for the integration of third-party providers in the platforms is analyzed and various implementations for the realization of the target system are presented and evaluated. The solution of this analysis involves the integration of standardized schemas in the existing semistructural online presentations of companies. Furthermore, a central evaluation of this data as well as the intelligent output through a cross-platform chatbot is proposed to fulfill the set system objectives. A design of the evaluated system is then presented and the necessary software architecture is determined. After an assessment of the system, prospects and extensions that for the system are pointed out. The conclusion recognizes that the implementation of the system is not only feasible, but can also be applied in numerous situations. For optimal use of the concept, the system should not be managed independently, but should be integrated into the conversation assistant and used in parallel to the existing connection for third-party providers.
Abstract (deutsch): Aufgrund der technologischen Entwicklungen und den jüngsten Bemühungen der großen IT-Konzerne in Richtung intelligenter Assistenten (Siri, Cortana, Alexa, Google Assistant, …) soll in dieser freien wissenschaftlichen Arbeit die Frage geklärt werden, ob Konversations-Assistenten dazu befähigt werden können mehrere Unternehmen, mit unterschiedlichen Strukturen und Services, mittels einer zentralen Anwendung, anzusteuern, um so eine allumfassende Anwendung zu ermöglichen.
Es werden die bestehenden Technologien in dem Systemkontext untersucht. Zur Konzeption des gesuchten Systems werden Anforderungen erhoben, die der Ausgangsfrage entsprechen und eine Umsetzbarkeit mit bestehenden Technologien ermöglichen. Zusätzlich wird das aktuelle Modell, zur Eingliederung von Drittanbietern in den Plattformen, analysiert und verschiedenste Umsetzungslösungen zur Realisierung des Zielsystems aufgezeigt und evaluiert. Die Lösung der Arbeit sieht eine Einbindung von standardisierten Schemata, in den vorhandenen semistrukturellen Onlineauftritten von Unternehmen, vor. Des Weiteren wird eine zentrale Auswertung dieser Daten, sowie die intelligente Ausgabe durch einen plattformübergreifenden Chatbot, vorgeschlagen, um die gesetzten Systemziele zu erfüllen. Es wird ein Entwurf des evaluierten Systems aufgezeigt und die notwendige Software-Architektur bestimmt. Nach einer Bewertung des Systems werden zum Schluss die Aussichten und Erweiterungen aufgezeigt, die dem System bevorstehen. Das abschließende Fazit erkennt, dass das System in seiner Umsetzung nicht nur machbar ist, sondern auch kontextübergreifend angewendet werden kann. Zur optimalen Nutzung des Konzeptes sollte das System nicht eigenständig geführt werden, sondern in den Konversations-Assistenten integriert- und parallel zur bestehenden Anbindung für Drittanbieter verwendet werden.
„Tout ce qu'un homme est capable d'imaginer, d'autres hommes seront capables de le réaliser“
[ Alles, was ein Mensch sich heute vorstellen kann, werden andere Menschen einst verwirklichen. ]
- Jules Verne, 1880
Abbildungsverzeichnis
Abb. 1: Aktuelle Einbindung von Drittanbietern versus Zielsystem
Abb. 2: UML-Anwendungsfalldiagramm - Begrifflichkeiten im Kontext
Abb. 3: Beispiel der Domainhierarchie unter schema.org
Abb. 4: Starburst-Visualisierung der Hierarchie auf schema.org
Abb. 5: Rezept in HTML codiert
Abb. 6: Rezept in HTML codiert mit Microdata-Schemata
Abb. 7: Der generelle Hauptprozess zur Verwendung eines Webservices
Abb. 8: Der generelle Hauptprozess einer OAuth-Ausführung
Abb. 9: Die Typisierungen von Chatbots
Abb. 10: Generalisierter Hauptprozess eines Chatbots
Abb. 11: Nutzung von Sprachassistenten in Deutschland 2016 (in Millionen)
Abb. 12: Grundsätzlicher Aufbau und Kontext des Zielsystems
Abb. 13: Grundlegende Illustration zum Zweck des Zielsystems
Abb. 14: Hierarchie der technologischen Komponenten der beeinflussenden Elemente
Abb. 15: Ziele der beeinflussenden Nutzergruppen im Zielsystem
Abb. 16: Hauptanwendungsfalldiagramm für das Zielsystem mit grundlegenden Funktionen
Abb. 17: Hauptprozessmodell für das Zielsystem mit grundlegenden Funktionen
Abb. 18: Systemkontextdiagramm mit den wesentlichen Teilen
Abb. 19: Anforderungen am Zieldiagramm
Abb. 20: Modell der Umsetzungslösung: "Direkte Komunikationslösung"
Abb. 21: Modell der Umsetzungslösung: "Individuelle Applikationslösung"
Abb. 22: Modell der Umsetzungslösung: "Portallösung"
Abb. 23: Modell der Umsetzungslösung: "SWS-Lösung"
Abb. 24: Modell der Umsetzungslösung: "Eigene-Schnittstellenlösung"
Abb. 25: Veranschaulichung der Übertragungswege mit Formataustausch
Abb. 26: Bsp. eines Webseitenbaumes mit den beispielhaften Schemata
Abb. 27: Modell zur Übersicht der Lösung im Kontext
Abb. 28: Allgemeiner Systemkontext des Zielsystems
Abb. 29: BPMN zum Hauptprozess des Zielsystems
Abb. 30: BPMN zum Prozess "Asynchrone Datengewinnung " des Zielsystems
Abb. 31: BPMN zum Prozess "Schnittstellenregistrierung, bzw. -suche " des Zielsystems
Abb. 32: BPMN zum Prozess "Benutzererkennung" des Zielsystems
Abb. 33: BPMN zum Prozess "Datenanfrage klären" des Zielsystems
Abb. 34: BPMN zum Prozess "Prozessverarbeitung" des Zielsystems
Abb. 35: Aufteilung der Systemhauptbestandteile
Abb. 36: Beispielhafte Abbildung der Datenhaltung im Zielsystem
Abb. 37: Beispiel eines Webseitenstrukturbaumes mit Schemata-Informationen
Abb. 38: Gegenüberstellung eines Reservierungs-Prozesses von BPMN & Schema-Action
Abb. 39: Die Markup-Möglichkeiten der Cortana-GUI
Abb. 40: Die Markup-Möglichkeiten der Facebook-Messenger-GUI
Abb. 41: Umsatz mit digi. Assistenten weltweit in Millionen US-$ mit Endkunden bis 2021
Abb. 42: Nutzung von digitalen Assistenten weltweit in Millionen bis 2021
Abb. 43: Vorstellbare Einsatzszenarien für Chatbots in Deutschland
Abb. 44: Globaler Umsatz von eCommerce in US-$ bis 2020
Abb. 45: Vergleich der Anwendung von E-Mail und Messengern in drei Generationen
Abb. 46: Umfrage ob Unternehmen binnen 24 Stunden unabhängig des Wochentages antworten sollten
Abb. 47: Umfrage nach den bevorzugten Kommunikationswegen im eCommerce
Abb. 48: Umfrage, ob Unternehmen via Messenger kontaktierbar sein sollten
Abb. 49: Mögliche Einsatzbereiche von Chatbots im Kundenkontakt
Abb. 50: Wachstum der monatl aktiven Nutzer in Messengern in Millionen
Abb. 51: Fav. Kommunikationswege zum Kontakt zu Unternehmen nach Altersgruppe
Abb. 52: Geschichtliche Entwicklung der Mensch-Maschine-Interaktion (Computer)
Abb. 53: Abbruch von Onlineeinkäufen in eCommerce der letzten zehn Jahre
Abb. 54: Hauptprozess des zukünftigen Bezahlvorganges im WWW nach der Webpayment-Arbeitsgruppe des W3C
Abb. 55: Aktuell möglicher Bezahlprozess in Edge und Chrome mit der digitalen Brieftasche
Abb. 56: Unternehmenszukäufe im Bereich der künstlichen Intelligenz
Abb. 57: Reservierungen in der Google-Suche durch strukturierte Daten
Tabellenverzeichnis
Tabelle 1: Systembeeinflussende Elemente
Tabelle 2: Gewichtungstabelle der Evaluierungskriterien
Tabelle 3: Gewichtete Evaluierung der Umsetzungsmöglichkeiten
Tabelle 4: Gegenüberstellung der Ausgabe versch. Kommunikationswege
Tabelle 5: Vergleich des Umsatzwachstums zwischen trad. Off- und
Online-Unternehmen
Tabelle 6: Funktionale Systemanforderungen an das Zielsystem
Tabelle 7: Nicht-funktionale Systemanforderungen an das Zielsystem
Tabelle 8: Kriterienbeschreibung der Evaluation
Tabelle 9: Sprachliche Konventionen dieser Arbeit
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1. Einleitung
Es existiert, besonders im filmischen Bereich (gehäuft im „Science Fiction“-Genre), eine Vielzahl an futuristischen Beispielen (Her[1], Iron man[2], Hal9000, iRobot, …) bei denen Computersysteme und deren natürliche Interaktionen mit ihren Anwendern veranschaulicht werden. Betrachtet man diese, so fällt auf, dass zur Eingabe natürliche Eingabemethoden (bspw. die Sprache) verwendet werden und, dass die computergestützten Assistenten diese vielfältigen Eingaben nicht nur entgegennehmen, sondern auch auf eine natürliche Weise antworten. Diese Assistenten haben dabei vollen Zugang auf sämtliche Anwendungen auf dem System und im Internet und können diese uneingeschränkt verwenden. Dadurch können Prozesse am Endgerät nicht nur wesentlich effektiver gestaltet werden, sondern es könnte die Verwendung und den Stellenwert von Computern in der Gesellschaft komplett verändern.
Diese Arbeit beschäftigt sich mit den Umsetzungsmöglichkeiten, den Potentialen und den Einsatzgebieten einer universellen Applikation, die diese filmischen Visionen wahrwerden lässt. Hiermit sollen die Grenzen der konventionellen Systeme aufgebrochen werden, indem Konversations-Assistenten dazu befähigt werden, Prozesse und Inhalte jeglicher Art durch Webservices zu nutzen, um diese den Anwendern auf möglichst natürliche Art darzubieten. Der Lösungsansatz, der sich in der Evaluation als beste Umsetzung herausstellt, wird weiterverfolgt und zur Umsetzung konzeptionell ausgearbeitet. Das so kreierte Konzept des Systems wird dabei so ausgestaltet, dass die Technik in die Basis der Konversations-Assistenten (CAApp) eingebunden werden kann. Zusätzlich werden die eingesetzten Technologien einzeln und im Kontext unternehmerisch ausgewertet und ihre Zukunftsträchtigkeit bewertet.
1.1 Motivation und Problematik
Die Menschen suchten seit Beginn des Computerzeitalters nach immer besseren und intuitiveren Methoden der Mensch-Maschine-Interaktion - angefangen mit Hebeln und Schaltern, über Tastatur und Maus bis hin zum Schreiben mit der Hand. Allerdings ist eine der natürlichsten und sichersten Eingabemethoden bisher, aufgrund ihrer Komplexität, außen vor geblieben – die Spracheingabe.[3]
Die verbale Kommunikation ist eine äußerst natürliche Beschaffungsart für Informationen, welche persönlich, experimental, kritisch und zugleich mit Spaß verbunden sein kann.[4] Sollte es möglich sein, einen nahezu fließenden und personalisierten Gesprächsverlauf (Natural User Interface, kurz: NUI) mit dem Anwender zu kreieren, so wäre nicht nur eine überlegene Form der Eingabe geschaffen, sondern ein neues Marktsegment, welches die bisherigen Beschaffungs- sowie Informationsaustauschmärkte in Frage stellen könnte.
“[…] Human language is the new UI layer. Digital assistants are meta apps, or like the new browsers. Intelligence is infused into all your interactions. That's the rich platform that we have. […]”[5]
Die neuen CAApp sollen das ermöglichen. Bisweilen haben diese sich auf die Interaktion mit betriebssystemverbundenen Applikationen und einfachen Suchmaschinen-funktionalitäten beschränkt. Ende 2016 haben sämtliche große Anbieter von Konversations-Assistenten ihre Schnittstellen (API) für Drittanbieter freigegeben.[6]
„[…] the real power of any AI assistant right now is in the third-party integration […].”[7]
Durch die Offenlegung der API ist es nun möglich den CAApp einen Zugang zum Internet und den Anwendungen von Drittanbietern zu ermöglichen. Durch die Schaffung dieser neuen Plattformen eröffnen sich komplett neue Marktsegmente und Chancen. Durch diese Technologie kann eine Software kreiert werden, die sämtliche Informationen und Aktionen in sich vereint – eine universelle Applikation (App). Durch die daraus resultierenden Möglichkeiten könnten viele Applikationen und Programme obsolet werden; davon besonders betroffen: Einkaufs-Applikationen, welche den größten Markt ausmachen. Die meisten dieser Apps sind in ihrer Gesamtheit redundant und stellen lediglich eine alternative Darstellungsform gegenüber dem Webauftritt, bzw. den Webservices des jeweiligen Unternehmens dar.[8]
Die Bereitstellung von Drittanbieter-Software gleicht einer Bereitstellung neuer Apps im gleichnamigen Store. Die Möglichkeit den CAApp eine neue Fähigkeit zu verleihen scheint zunächst einfacher, da lediglich die begrenzten Schnittstellenanbindungen bedient werden müssen und eine aufwendige GUI entfällt. Durch eine Umsetzung können gleichzeitig mehrere Endgeräte mit den verschiedensten Betriebssystemen (OS) bedient werden.[9] In dieser Diskussion wird oftmals vergessen, dass es auch mehrere CAApp gibt, die bedient werden wollen und, dass die gesamte Technik auf Chatbots mit künstlicher Intelligenz (AI) mit maschinellen Lernen (machine learning) aufbaut, was bisweilen eine immense technologische Herausforderung darstellt. Daher erscheint die bisherige Einbindung von Drittanbietern in CAApp nicht optimal gelöst zu sein, was diese Arbeit ebenfalls zu beheben versucht.[10]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1 : Aktuelle Einbindung von Drittanbietern versus Zielsystem
System- und geräteübergreifende Konversations-Assistenten sind die Zukunft der Technologie-Branche und werden neue Marktsegmente eröffnen. Die Möglichkeiten sind vielfältig, allerdings ist die bisherige Anbindung, bzw. Freischaltung für Drittanbieter ein einfaches Vermarktungsmodell, welches lediglich aus der „App-Ära“ übernommen wurde. Für die Komplexität der neuen Anwendungen für CAApp sind diese Modelle allerdings wenig geeignet. Der technologische Fortschritt erlaubt es über alternative Realisierungsmöglichkeiten nachzudenken – zentralisierte Systeme, die es ermöglichen, verschiedenste Unternehmen mit heterogenen Services und Informationen, zusammenzubringen. Eine entsprechende Umsetzung in Kombination mit CAApp lässt eine Applikation zu, die den bisherigen Markt in Frage stellt.[11]
1.2 Zielsetzung
Ziel dieser Arbeit ist es, die Möglichkeiten einer realistischen und wirtschaftlichen Umsetzung eines Systems herauszuarbeiten, das fähig ist, mittels Konversations-Assistenten auf sämtliche Unternehmen und dessen Informationen und Prozesse zuzugreifen. Es soll hierzu ein beispielhafter Realisierungsansatz gefunden werden, welcher in einem Konzept zur softwaretechnischen Realisierung mündet.
In dieser Arbeit soll das Potential der notwendigen Technologien und dessen Weiterentwicklung, bzw. Zusammenstellung zum Zielsystem herausgearbeitet werden. Hauptsächlich muss zur Konzeption die Frage geklärt werden, wie eine effektive, effiziente, benutzerfreundliche und zukunftsträchtige Verbindung einer CAApp mit den Webservices mehrerer Unternehmen, aus den unterschiedlichsten Branchen und unternehmerischen Zielen, vollzogen werden kann. Es soll ein grobes Konzept zur Realisierung dieses Ansatzes in Verbindung mit Software-Architektur erstellt werden, welches die Regeln, die Implementierung und die Kommunikation auf beiden Seiten regelt. Es werden die Absatzchancen durch den Einsatz dieser Technologien für Unternehmen beleuchtet und dessen Marktpotential. Dabei soll zudem ein Ausblick und ein Fazit des konzeptionellen Systems gezogen werden. Die Arbeit soll anhand eines Fallbeispiels Kapitel für Kapitel eine praxisnahe Anwendung, bzw. Umsetzung der theoretischen Ausführungen demonstrieren.
1.3 Abgrenzung
Diese Arbeit enthält keine Implementierung oder Realisierung des konzeptionierten Systems. Die Funktionsweise der künstlichen Intelligenz und deren Ausgestaltung wird nicht behandelt. Die Sicherheitsaspekte werden aber nicht im Detail geklärt. Die Arbeitsweise hinter den verwendeten Technologien werden nicht hinterfragt oder vollständig aufgeschlüsselt. Die Herangehensweise und Umsetzung des Chatbots zu der Mensch-Maschine-Kommunikation wird nicht näher erläutert. Es wird weder tief auf die Ausgestaltung der Datenbank eingegangen, noch auf die Wahl der passenden Datenbanktechnologie. In der Arbeit werden keine moralischen, philosophischen oder politischen Einflüsse eingearbeitet oder bewertet. Es wird vorausgesetzt, dass die Verwendung der Webservice-Technologie die geeignetste Umsetzung zur Abwicklung von Geschäftsprozessen (GP) für das System darstellt.
1.4 Aufbau der Arbeit
Im ersten Teil dieser Arbeit werden die Grundlagen der eingesetzten Systeme und den dahinterstehenden Techniken erläutert. Hier soll das Prinzip der Softwaresysteme analysiert und vermittelt werden.
Im Hauptteil werden zunächst die Umgebung und die Anforderungen an das System, welches eigenständig zwischen CAApp und den Webservices der Unternehmen agieren soll, ermittelt. Dabei werden Anforderungen aufgenommen, welche grundlegend zur Erfüllung des Zielsystems notwendig und dabei unabhängig von den Umgebungssituationen sind. Im nächsten Schritt werden Umsetzungsmöglichkeiten, zur Verwirklichung des Zielsystems, zunächst herausgearbeitet und im Anschluss evaluiert. Im nächsten Abschnitt erfolgt der Systementwurf und die dazugehörige Software-Architektur. Die Bewertung der einzelnen Technologien und des Systems als Ganzes wird im letzten Abschnitt des Hauptteils behandelt. Dabei werden die Chancen in den jeweiligen Anwendungsgebieten untersucht und die Zukunftsträchtigkeit versucht zu ergründen. Zudem werden Sicherheitsaspekte des Systems analysiert und fehlende Implementierungen und Fragen beschrieben, die nicht abschließend oder zufriedenstellend beantwortet werden konnten.
Im Schlussteil wird ein Ausblick anhand von Statistiken, Umfragen und Entwicklungen erarbeitet, welches die zukünftigen Aussichten des Systems, seinen Auswirkungen auf die Unternehmenslandschaft und dessen Potential herausgearbeitet. Zusätzlich werden Technologien vorgestellt, die sich aktuell in der Entwicklung befinden und zukünftig im System integriert werden sollten. Im letzten Abschnitt des Fazits und der Kritik werden die jeweiligen Technologien kritisch bewertet und ein ausführliches Fazit zum System gezogen.
1.5 Sprachliche Konventionen
Da verschiedene Begrifflichkeiten, bzw. Rollenumschreibungen in den Ausführungen immer wieder zum Einsatz kommen, sollen diese, wie sie in der Arbeit zu verstehen sind, an dieser Stelle erläutert werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2 : UML-Anwendungsfalldiagramm - Begrifflichkeiten im Kontext
Die in der Tabelle 9: Sprachliche Konventionen dieser Arbeit im Anhang D zu findenden Begrifflichkeiten, die dort ausführlich beschrieben werden, sind: Plattform (Basis, bzw. OS, auf der die CAApp aufbaut), Unternehmen (über das Internet informations- sowie prozesswiedergebendes Konstrukt), Anwender (Benutzer des Systems) und System (das konzipierte Zielsystem).
2. Grundlagen
In diesem Kapitel werden die Begrifflichkeiten und Technologien behandelt, um für die Gesamtarbeit eine Wissensgrundlage zu schaffen – sowohl für die Verständlichkeit, als auch für die Argumentation.
2.1 Software-Architektur
Die Software-Architektur beschreibt die Strukturen eines Systems – seine Komponenten (Clients und Server, Filter, Objekte und Datenbanken), dessen Verbindungen untereinander und die nach außen sichtbaren Elemente. Die Architektur richtet sich nach den Anforderungen an das System und dessen Qualitätsattributen, wie beispielsweise Produkteinführungszeit, Kosten, geplante Lebensdauer, Marktausrichtung, Endgeräte und Integrationsfähigkeit. Beim Design der Architektur handelt es sich um eine Reihe von Entscheidungen, die auf einer Vielzahl von Faktoren beruhen, wovon jede dieser Entscheidungen erhebliche Auswirkungen auf die Qualität des Systems haben kann.[12]
Ausgehend von der Arbeit von Mary Shaw und David Garlan im Jahre 1996, fanden die Autoren Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman folgende Definition für die Software-Architektur:
“Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.”[13]
Die grundlegende Software-Architektur mit ihren Design-Entscheidungen bildet die Basis für sämtliche nachfolgenden Entscheidungen und Möglichkeiten des Systems – daher sind diese Entscheidungen ausschlaggebend für eine gemeinsame Architektur. Durch wiederverwertbare und übertragbare Abstraktionen (Entwurfsmuster, auch Pattern genannt) ermöglicht die Architektur, unabhängig des Systems, die Weitergabe der bereits erstellten Funktionalitäten. So können bei neuen Design-Entscheidungen oder dem Neuaufsetzen des Systems diese Fragmente neu verwendet werden.[14]
Die Software-Architektur eines Systems ist ausschlaggebend für dessen Qualität, Verständlichkeit und Modifizierbarkeit. Sie dient als Kommunikationsmittel, zur Veranschaulichung von früheren Design-Entscheidungen und als wiederverwendbare und übertragbare Abstraktion von Softwaresystemen.[15]
Es gibt, ausschlaggebend an den gesetzten Qualitätsattributen und der Art der Software, verschiedenste Architekturmodelle und Herangehensweisen. In dieser Arbeit wird sich hauptsächlich mit den Plug-In-Architekturen beschäftigt. Diese werden aktuell in der Webentwicklung hauptsächlich angewendet (SOA-Stile)[16] und ermöglichen eine gute Mischung aus der guten Erweiterbarkeit, bedingt durch die modulare Bauweise, und dem großen Funktionsumfang.[17]
Die serviceorientierte Architektur (SOA) ist ein Architekturkonzept (technisch wie geschäftlich), welches auf eine möglichst hohe ökonomische Wertschöpfung abzielt. Durch die vom Konzept der Serviceorientierung durch SOA optimierten Infrastrukturen sollen Prozesse effektiver, sicherer, kostengünstiger und wartungsfreundlicher umgesetzt werden.[18]
Der „ressourcenorientierte“ Architekturstil von SOA stellt die Interaktionsbasis des Internets dar und abstrahiert dabei jede Information als adressierbare Ressource. Dieser Architekturstil greift die Konzepte, der verteilten Architektur als Kommunikationsgrundlage, des „World Wide Web“s (WWW) mit dessen Kerntechnologien, das Netzwerkübertragungsprotokoll „Hypertext Transfer Protocol“ (HTTP) und dem „Uniform Resource Identifier“ (URI), auf.[19] Inspiriert wurde dieses Vorgehen durch die Dissertation von Roy Fiedling[20], der in seiner Untersuchung zum Erfolgsmodell Internet versucht hat, die Prinzipien hinter den Web-Technologien auf die Konstruktion nativer Anwendungen zu replizieren. Aus seinen zusammengetragenen Designkriterien und Erkenntnissen wurde, aufbauend auf die SOA-Prinzipien, „Representational State Transfer“ (REST) geschaffen, auf dessen Idee weite Teile des Zielsystems aufbauen.[21]
2.2 Semantic Web
„The Web can reach its full potential only if it becomes a place where data can be shared and processed by automated tools as well as by people. For the Web to scale, tomorrow's programs must be able to share and process data even when these programs have been designed totally independently. The Semantic Web is a vision: the idea of having data on the web defined and linked in a way that it can be used by machines not just for display purposes, but for automation, integration and reuse of data across various applications.“[22]
Die Anzahl an elektronischen Daten verschiedensten Typs steigt von Jahr zu Jahr. Besonders im Internet findet sich ein Großteil der Daten an, die zwar öffentlich zugänglich sind, aber nur von Menschen richtig interpretiert werden können; aufgrund ihrer semistrukturierten Art. Semistrukturell, da Webseiten durch „Tags“ und „Anker“ zwar grundlegend strukturiert sind, aber ihre Inhaltswiedergabe, Struktur und Herkunft unstrukturiert sind.[23] Um maschinelles Auslesen der Webseiten und Services zu ermöglichen, stellt die Initiative schema.org ein Markup zur Verfügung, welches semantische Zusammenhänge durch standardisierte Annotationen zur Auszeichnung von Webseiten-Inhalten ermöglicht. Zu diesem Zweck wird beispielsweise ein „Hypertext Markup Language“ (HTML)-Code mit Zusatzinformationen (sogenannten Schemata) zur Auszeichnung des Inhaltes angereichert; für eine maximale Kompatibilität wahlweise in den Formaten: Microdata, JSON-LD oder/ und RDFa.[24] Auf diese Weise können aus semistrukturellen Daten- strukturierte Daten erzeugt werden, die durch Verknüpfungen untereinander komplexe Strukturen abbilden können.[25]
Eine interne Weiterentwicklung der Schema-Modelle wird stets vorangetrieben. Allerdings werden parallel dazu von ausgewählten Unternehmensvertretern Erweiterungen zu den Schemata erstellt, welche für spezifische „Dinge“ angewendet werden können und eine tiefere Beschreibung dieser ermöglichen (beispielsweise die „Health and Lifesciences“-Erweiterung[26], die für medizinische und therapeutische Dinge explizitere Auszeichnungen bereitstellt). Durch die Auszeichnung mit Schemata können nicht nur Webseiteninhalte Maschinen zugänglich gemacht werden, sondern sämtliche Dinge von Interesse – somit ist das semantic web, mit seinem Konzept des „Giant Global Graph“, ein Teil des „Internet of Things“ (IoT).[27]
„Schema.org is a collaborative, community activity with a mission to create, maintain, and promote schemas for structured data on the Internet, on web pages, in email messages, and beyond. […] “[28]
Schema.org basiert auf der Absprache zwischen den größten IT-Tech-Unternehmen. Somit können die auf schema.org geschaffenen Veröffentlichungen als Standard angesehen werden, der von den Plattform- und Client-betreibern einheitlich interpretiert werden.[29]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3 : Beispiel der Domainhierarchie unter schema.org
Das Markup von schema.org bringt eine auf dem Konzept der OOP aufbauende Auszeichnung mit sich: ein hierarchisch strukturiertes Set bestehend aus Typen und Eigenschaften. Mittels Typen werden die inhaltlichen Elemente grob ihrer Kategorie zugeordnet. Eigenschaften versehen diese Typen mit definierten Werten, sodass eine genaue Zuordnung stattfinden kann. Schema.org bestimmt dabei, welche Typen und Eigenschaften verwendet werden können und wie diese untereinander arrangiert- oder auch verlinkt sind. Der Versuch eine Vielzahl der Objekte der Welt mit diesem Modell abzubilden führt zu einer beachtlichen Sammlung an verschiedensten Grundtypen, die, wie in der Abb. 4: Starburst-Visualisierung der Hierarchie auf schema.org zu sehen ist, untereinander hierarchisch organisiert sind.[30]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4 : Starburst-Visualisierung der Hierarchie auf schema.org[31]
“Structured data is picking up on the Web, particularly in the search world. Semantic structuring of content provides a wide range of advantages compared to unstructured information.“[32]
Internetseiten mit ihren Inhalten, Services und Strukturen sind darauf ausgelegt von Menschen betrachtet zu werden, entsprechend schwierig ist es für Programme diese zu interpretieren. Durch Schemata können sämtliche Inhalte, auch solche, die speziell für Menschen geschaffen wurden, für den Computer lesbar gemacht werden.
Beispiel (gesuchte Ausgabe): „Unser 15min Möhreneintopf Gericht des Tages ist ein klassischer Eintopf mit 210kcal, 10g Fett bestehend aus:
- Karotten und
- Kartoffeln
und wird vom Sternekoch Tim Rosin präsentiert.
Einfachen alles schneiden und im Topf eine Stunde lang köcheln. “
Abbildung in dieser Leseprobe nicht enthalten
Abb. 5 : Rezept in HTML codiert
Dem deutschen Leser wird der Inhalt und seine Zuordnung zu den Rezepten klar verständlich sein. Auch, dass es sich um einen vermeintlich bekannten Sternekoch handelt und welche Zutaten verwendet werden. Mit der Kennzeichnung durch Schemata, wie in der Abb. 6: Rezept in HTML codiert mit Microdata-Schemata zu sehen ist, bekommen Maschinen die Möglichkeit Inhalte korrekt zu interpretieren und im richtigen Kontext zu betrachten. Durch diese Vorgehensweise können Informationen korrekt kategorisiert und einsortiert werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 6 : Rezept in HTML codiert mit Microdata-Schemata
2.3 Webservices
„A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.“[33]
Webservices dienen folglich als ein über das Internet kommunizierter Funktionsaufruf an einem Server (Schnittstelle) – als eine Art Zwischenschicht zwischen Systemen in einem Netzwerk (siehe hierzu Abb. 7: Der generelle Hauptprozess zur Verwendung eines Webservices). Der Vorteil von Webservices ist, dass sie auf eine bestimmte Menge von Daten fokussiert sind. Das bedeutet, dass versucht wird, lediglich relevante Informationen zu übertragen, was zu einer kleineren Datengröße und einer schnelleren Übertragungsgeschwindigkeit führt. Allerdings sind nicht alle Webservices gleich, da es verschiedene Webservice-Typen gibt, mit unterschiedlichen Übertragungsformaten und -formatierungen.[34]
Webservices können für Webanwendungen genutzt werden, wenn diese gewisse Benutzerschnittstellen (UI) zur Anzeige/ Eingabe von Informationen bereitstellen; pauschal sind diese allerdings nicht gleichzusetzen.[35]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 7 : Der generelle Hauptprozess zur Verwendung eines Webservices[36]
Webservices haben zwei hauptsächliche Rollen: die des „service requestors“ (System, das Daten anfragt) und die des „service providers“ (System, welches Daten ausliefert). Zur Kommunikationsrealisierung stellt die sogenannte Web Service Description Language (WSDL) eine Schnittstelle zur Verfügung mit definierten Eigenschaften. Im Anschluss werden über SOAP zur Laufzeit Aufrufe versendet.[37]
Semantic Web Services: Semantic Web Services (SWS) sind Webservices, also eine Art Schnittstellen, die aus der Verwendung des Semantic Web, also aus der Auszeichnung der unstrukturierten Inhalte mit semantischen Inhalten, eine eigene Schnittstelle darstellen, da diese nun von „Maschinen“ korrekte interpretiert werden können. Dabei stellt der service provider lediglich eine Webseite mit schematisierten Inhalten zur Verfügung – service requestor können dann beliebige Crawler sein, die den Standard unterstützen, bzw. auslesen können.[38]
OAuth:
„OAuth is the standardization and combined wisdom of many well established industry protocols. It is similar to other protocols currently in use (Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Upcoming API, Flickr API, Amazon Web Services API, etc). Each protocol provides a proprietary method for exchanging user credentials for an access token or ticker. OAuth was created by carefully studying each of these protocols and extracting the best practices and commonality that will allow new implementations as well as a smooth transition for existing services to support OAuth.“[39]
Die grundlegenden Einheiten von OAuth ist der „Ressourceneigentümer“ (Eigentümer der Daten), der „Ressourcenserver“ (Verwalter der Daten), der „Autorisierungsserver“ (Überprüft die Berechtigung der Anfrager) und die „Client-Anwendung“ (bestrebendes System, welche die Daten anfragen möchte). Der Prozess erfolgt wie folgt: Zunächst muss der Autorisierungsserver die Client-Anwendung registrieren, indem eine Identifikationsnummer und Token zugewiesen wird. Nach erfolgreicher Authentifizierung des Ressourceneigentümers, werden die geforderten Daten vom Ressourcenserver der Client-Anwendung zur Verfügung gestellt.[40]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 8 : Der generelle Hauptprozess einer OAuth-Ausführung[41]
2.4 Chatbots
„[…] chatbots are programs that respond to natural language text and, optionally, voice inputs in a humanlike manner. They can execute tasks given specific commands (think voice control, or most Slack bots), but their raison d’être is that they listen, talk and seem to converse.“[42]
Chatbots (auch: Chat-Bots, software-/ messenger agents, intelligent virtual/ personal assistant/ agent, .ai oder im Deutschen Dialogprogramme genannt), sind Anwendungen, die für gewöhnlich gepaart mit einer gewissen Intelligenz und Lernfähigkeit, eingegebene „natürliche“ Daten auswerten und entsprechend der Eingaben eigenständig (zumeist über eine Auswertung über das WWW) Aufgaben generiert und löst.[43]
Diese „Bot-Gattung“ sollte nicht mit sogenannten „social bots“ oder „Botnet“ verwechselt werden – diese haben einen anderen Aufbau, Aufgabenbereich und unterscheiden sich stark in ihrer Funktionsweise vom Chatbot.[44]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 9 : Die Typisierungen von Chatbots[45]
„Chatbots have suddenly become the biggest thing in tech.“[46]
Die Idee dahinter ist bereits alt und wird bereits seit langem umgesetzt – allerdings steht erst heute das Knowhow und die Technologie zur Verfügung, um eine reibungslose Kommunikation zwischen Anwender und Anwendung stattfinden zu lassen. Das Konzept wurde daher erst jetzt wiederentdeckt und löst aktuell einen Hype aus – obwohl die Technologie noch in den Kinderschuhen steckt. Chatbots werden in ihrer aktuellen Ausführung gerne als etwas bessere Kommandozeileninterpreter (CLI) betrachtet.[47]
„[…] We've spent far too much time having to learn to talk like a computer. Now it's time for computers to learn to talk like us.“[48]
Ein Chatbot ist zumeist ein internetbasierter Kommunikationsservice, der über Messenger-Plattformen (bspw. Facebook-Messenger, Twitter, Skype, Telegram, Kik, …) oder ein (Betriebs-)System (Windows, iOS, Android, …) angeschlossen ist und über diese nach Gebrauch angesteuert wird. Dabei kann der Chatbot für verschiedenste Aktionen verwendet werden – darunter die direkten Konversationsaktionen. Zu den direkten Aktionen gehören zumeist Offline-Befehle und Befehle für das jeweils vom Bot unterstützte System (Termine einsehen, Kontakte anlegen, Hardware bedienen, Software bedienen, et cetera). Die Konversationsaktionen (indirekte Aktionen) werden zumeist auf Grundlage bestimmter Phrasen oder Stichwörter aus der Anwendereingabe heraus aktiviert und an einen bestimmten Drittanbieter vermittelt.[49]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 10 : Generalisierter Hauptprozess eines Chatbots
2.5 Konversations-Assistenten
Konversations-Assistenz-Programme (CAApp) sind Systeme, die dem Anwender Informationen liefern oder diesem helfen Aufgaben zu erledigen. Diese Assistenten bieten eine Funktionsmischung aus den Fähigkeiten wie der Spracherkennung, dem Sprachverstehen, der Schriftbildübersetzung, der kontextbezogenen Stifteingaben und vielen Weiteren – zusammenfassend ist es die Umwandlung einer beliebigen Eingabe eines Anwenders in ein für den Computer zu verarbeitendes Datenformat. Je nach Herausgeber und funktionalem Umfang werden Konversations-Assistenten auch Sprachassistenten, personelle Assistenten, Konversationsagenten, AI assistants oder auch automatic speech recognation (ASR) agents genannt. Gekoppelt werden Konversations-Assistenten oftmals mit Chatbots, welche die Logik des Sprachverständnisses bereitstellen; oftmals gekoppelt mit einer künstlichen Intelligenz und Lernfertigkeiten (mehr dazu siehe 2.4 Chatbots).[50]
Unter Konversations-Assistenten lassen sich sowohl Messenger-Dienste (Facebook, Whatsapp, Trello, Skype, …), welche automatische Konversation und automatischen Informationsaustausch zulassen, als auch „smarte Assistenten“ (Cortana, Siri, Alexa, Google Assistent, …), die selbige Services bereitstellen, einordnen. Der entscheidende Part der smarten Assistenten, als auch der Messenger-Dienste, ist der Chatbot, der die Verarbeitung der Eingabedaten zum Vollzug einer Konversation zwischen der Anwendung und dem Anwender zielführend übernimmt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 11 : Nutzung von Sprachassistenten in Deutschland 2016 (in Millionen)[51]
Diese Technologie ist folgend aufgebaut: Sollte der Endanwender die Spracheingabe wählen, so spricht dieser in das Mikrofon. Die so erzeugten Sprachsignale werden digitalisiert, von Störsignalen und Nebengeräuschen bereinigt und normalisiert. Im nächsten Schritt wird das Sprachsignal einer Merkmalsextraktion unterzogen. Hierbei wird das Sprachsignal in die Größen Zeit, Frequenz und Intensität unterteilt und in Zeitabschnitte eingeteilt. Mit den gewonnenen Daten kann mittels statistischen Verfahren ermittelt werden, zu welchem Phonemen (Klangwortgruppen) die Spracheingabe zunächst am ehesten entspricht, um anschließend aus den gegebenen Wörtern der Phonemen-Gruppe die statistisch korrekten Wörter der Spracheingabe zuzuordnen. Die so entstandene Zeichenkette ist nun auf dem Stand der direkten textuellen Eingabe des Endanwenders (an dieser Stelle fangen Messenger-Dienste an, da diese die direkten Texteingaben erhalten). Im Anschluss werden die extrahierten Wörter-, bzw. Wortgruppen ausgewertet und anschließend ggf. der Lernfähigkeit zugeführt. Die ausgewerteten Eingaben des Algorithmus werden dem angebundenen Programm (im Kontext dieser Arbeit einem Chatbot), zur weiteren Verarbeitung und Interpretation, zugeführt.[52]
2.6 Begrifflichkeiten im Kontext
Um ein vollständiges Bild der Begrifflichkeiten, den Zusammenhängen untereinander und der Bedeutung für diese Arbeit zu erlangen, werden diese hier erläutert.
Die Software-Architektur bestimmt den Aufbau, die Funktionalität und das Auftreten gegenüber anderen Systemen – dem Komplex einer Software (Applikation/ Anwendung). Hiermit können sowohl die Ausgestaltung des Zielsystems, als auch die vom Unternehmen benötigten Schnittstellen und Ressourcen beschrieben werden. Die Schemata sind eine Möglichkeit der Auszeichnung von Daten, damit diese strukturiert und für andere „Maschinen“, über eine Anbindung durch beispielsweise eine Schnittstelle in Form von Webservices, standardisiert übermittelt werden können. Dabei regelt der Webservice die Ausgestaltung des Datenaustausches zwischen den Systemen über das Internet. Der Chatbot kann mit den aus dem Webservice gewonnenen Daten so arbeiten, dass dieser befähigt wird, dem Anwender die gewünschten Inhalte zu liefern und Aktionen in seinem Interesse auszuführen. Der Vorteil des Chatbots ist zusätzlich, dass dieser mit einer gewissen Intelligenz und Lernfähigkeit einen möglichst natürlichen und intuitiven Inhaltsaustausch mit den Anwendern sicherstellen kann. Zur Kommunikation mit dem Chatbot kann ein Konversations-Assistent verwendet werden, der die Interpretation der Anwendereingaben vornimmt und diese zur benötigten Anwendung (unter anderem dem Chatbot) weiterleitet und die Ausgaben der jeweiligen Anwendung zentral wiedergibt.
3. Sollkonzeption
In diesem Kapitel soll das Konzept zur Realisierung des Zielsystems, und somit die Lösung der softwaretechnischen Problematik, geschaffen werden. Hierzu werden die Anforderungen an das System herausgearbeitet, die Herausforderungen und Umsetzungsmöglichkeiten werden analysiert, beschrieben und evaluiert. Zudem wird die Art der Datenübermittlung beschrieben und final das Konzept zur Umsetzung des Systems zusammengefasst.
In dem Sollkonzept soll die Frage geklärt werden, wie eine wirtschaftlich- sowie technisch sinnvolle Umsetzung des Systems aussehen könnte – wie Kommunikations-Assistenten multilateral, über ein gemeinsames System, Unternehmen ansteuern können und dabei verschiedenste Informationen und Prozesse der Unternehmen automatisch wiedergeben, bzw. ausführen können.
Fallbeispiel:
Das folgende Fallbespiel soll die Herangehensweise zur Umsetzung des Systems unterstützen und zum besseren Verständnis sowie zur Herleitung von Systemanforderungen beitragen. Dabei werden die Produkte und Leistungen bewusst oberflächlich gehalten, um die Austauschbarkeit unter Unternehmen zu verbildlichen.
Die Organisation „XYZ“ beschäftigt 200 Mitarbeiter im Herzen Deutschlands. Zur Erweiterung ihres Marketing- sowie Vertriebspotentials möchte XYZ nun neue Wege beschreiten. Um ihre individualisierbaren Produkte zu vertreiben, Informationen zu Produkten und dem Unternehmen zu vermitteln und um Termine mit Vertretern des Unternehmens an ihre Kunden zukünftig zu vermitteln, sollen diese, neben dem telefonischen Angebot und dem Internetauftritt, zukünftig, auch plattform- sowie geräteunabhängig über CAApp abrufbar sein.
3.1 Systemkurzbeschreibung
Das System besteht aus drei wesentlichen Komponenten, welche zur Veranschaulichung in einer Allegorie zum menschlichen Körper gesetzt werden: die Verbindungsstelle (Sinnesorgane), die zwischen den Konversations-Assistenten und dem Chatbot vermittelt, dem Chatbot (Gehirn), der aus den Anwendereingaben die Bedürfnisse und Intensionen dieser ermittelt und entsprechende Prozesse ausführt, und dem zentralen Hauptsystem (Nervensystem), welches die Datenhaltung organisiert.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 12 : Grundsätzlicher Aufbau und Kontext des Zielsystems
Die Verbindung zwischen der CAApp und dem Chatbot ist notwendig, da die Plattformbetreiber dieses Konstrukt zur Eingliederung von Drittanbietern in ihr System gewählt haben. Die Verbindung wird in der Regel durch eine Applikation (App) hergestellt. Durch diese lassen sich die Dienste des Systems buchen. Die Applikation erfasst die Freigaben, Daten und Eingaben vom Anwender und dessen verwendete Plattform. Die App leitet die Eingaben vom Anwender, abhängig von der Plattform und dessen Schnittstellen, mehr oder weniger direkt, zum Chatbot weiter.
Der Chatbot ist eine zumeist vom System abgegrenzte Komponente, die die Intelligenz des Systems darstellt. Der Chatbot empfängt die Anwendereingaben und die Informationen der App und verarbeitet diese. Mit seiner künstlichen Intelligenz versucht er die Befehle, bzw. Wünsche des Anwenders zu verstehen und stellt ggf. kontextbezogene Nachfragen an. Hierzu verwendet er maschinelles Lernen und bestimmte Fähigkeiten, bzw. kognitive Services, um die Interaktion mit dem Anwender stetig zu verbessern. Die Informationsbeschaffung sowie die Prozessausführung bedürfen einer Kommunikationsschleife (Loop), in welcher der Chatbot die Zusammenhänge zwischen den Eingaben des Anwenders herstellen muss.[53] Der Chatbot liefert der Applikation kontextbezogen die jeweils auszugebenen Daten in dem passenden Markup.[54] Die aus der Konversation bezogenen Eingabedaten und die zuvor gesicherten Daten, über dem Anwender, werden über eine Schnittstelle vom und zum Hauptsystem geliefert.
Das Hauptsystem ist das Verbindungsstück zwischen den Unternehmen und dem Chatbot. Es ist primär zur Datenhaltung und für die Verwaltung dieser zuständig. Das Hauptsystem puffert die Daten der Unternehmen vorzugsweise vor, sodass die Abwicklung und die Bewertung der Daten unabhängig von den Serverkapazitäten des Unternehmens sind und die Bearbeitung der Anfragen möglichst schnell vonstattengehen kann. Bei Geschäftsprozessen (GP) stellt das Hauptsystem direkte Anfragen an das Unternehmen, um aktuelle Zahlen und Vorgaben zu erhalten; dabei wird der Geschäftsprozess mit den möglichen Prozesswegen und benötigten Informationen vom Unternehmen vorgegeben. Um den Vorgang für den Anwender schnellstmöglich abzuschließen versucht das Hauptsystem möglichst viele der bereits gewonnenen Informationen zu verwenden; natürlich in einer vorherigen Absprache mit dem Informationsinhaber. Das Hauptsystem steht für weitere Anfragen des Unternehmens innerhalb und für Benachrichtigungen außerhalb des Prozesses, zur Verfügung. Zusätzlich sichert das Hauptsystem die Eingaben und Informationen des Anwenders, um diese für zukünftige Anfragen, Benachrichtigungen und Prozesse verwenden zu können.
3.2 Anforderungsermittlung
Zur Erfassung und Skizzierung der Systemarchitektur werden zunächst die Anforderungen an das System ermittelt. Aufbauend hierauf werden die besten Umsetzungsmöglichkeiten erstellt und bewertet.
3.2.1 Anforderungsübersicht
Um die komplexen Anforderungen an das System fassen zu können und diese aus einer systematischen Logik zu eruieren, wird zunächst der Kontext betrachtet.
Zweck des Systems:
Es soll eine Möglichkeit geschaffen werden, die es Endanwendern ermöglicht, über Konversations-Assistenten (Facebook Messenger, Siri, Cortana, Google Assistent, Alexa, …) Bestellungen aufzugeben, Dienstleistungen in Anspruch zu nehmen, Termine zu verwirklichen (zusammengefasst: verschiedenste Geschäftsprozesse unabhängig umzusetzen) und eine zuverlässige, wie aktuelle Informationswiedergabe zu ermöglichen. Hierzu soll eine universelle und zentrale softwaretechnische Lösung gefunden werden, welche beliebig viele Unternehmen mit deren heterogenen Services und Informationen auf einmal bedienen kann, auf eine, für den Endanwender, möglichst native und natürliche Art der Interaktion mit dem System. Ausgangspunkt für das System sind die Schnittstellen für Drittanbieter der Konversations-Assistenten, das WWW und die Unternehmen mit deren Systemen.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 13 : Grundlegende Illustration zum Zweck des Zielsystems
Systembeeinflussende Elemente:
In diesem Kapitel werden die beeinflussenden Elemente ausfindig gemacht, die eine direkte oder indirekte Verbindung zum System aufweisen. In der folgenden Tabelle werden die wichtigsten Elemente in Bezug auf die Systemsicht aufgeführt; anschließend werden diese näher beschrieben.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1 : Systembeeinflussende Elemente
Systembetreiber:
Personen aus dem Umfeld des Systembetreibers haben einen unmittelbaren Einfluss auf die Anforderungserhebung. Sie sind Anwender im Backend und/ oder helfen den Anwendern des Systems. Als Entscheider und stark reflektierende Nutzer des Systems sind sie eine wichtige Quelle zur Anforderungserhebung. Für die Systembetreiber muss das System tadellos funktionieren und stets verfügbar sein, wobei die Generierung von Traffic, bedingt durch eine große Nutzerschaft (sowohl Unternehmen, als auch Endanwender) im Vordergrund steht.
Endanwender:
Die Gruppe der Anwender sind die Endnutzer des Systems und stellen die potentiellen Kunden der angeschlossenen Unternehmen dar. Dazu gehören Personen (juristisch wie natürlich), die Bestellungen ordern, Dienstleistungen in Anspruch nehmen, Termine buchen oder Informationen abrufen möchten. Die Leistung des Systems soll in einer natürlichen, schnellen, intelligenten, lernfähigen und intuitiven Art abgerufen werden können von möglichst vielen Endgeräten, unabhängig ihrer Plattformzugehörigkeit.
Vertriebspartner:
Vertriebspartner sind Unternehmen, welche ihre Dienstleistungen, Informationen, Services und Produkte über das System vertreiben/ bewerben möchten. Dabei ist ihnen der Vertrieb und das Marketing durch das System wichtig. Unternehmen müssen ihre Softwarestrukturen mit denen des Systems, bzw. mit denen der CAApp verbinden.
Systemplattformen:
Der Endanwender arbeitet mit den jeweiligen Konversations-Assistenten, welche sich auf seinem jeweiligen Betriebssystem, bzw. Plattform befindet. Um auf das System zugreifen zu können, müssen jeweilige Begrifflichkeiten, bzw. Keywords oder Micro-Applikationen (ggf. Bezug durch einen Store) aufgerufen werden. Einen kleinen Überblick vermittelt die folgende Abbildung:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 14 : Hierarchie der technologischen Komponenten der beeinflussenden Elemente
Die Plattformen geben die Voraussetzungen für die Applikationen, die Schnittstellen, die Funktionalitäten und die Schemata vor. Das System muss deren Vorgaben erfüllen und eine reibungslose Abwicklung und Interaktion ermöglichen.
Justiz:
Die Justiz ist stets darauf bedacht, die Anwender zu schützen. Durch einen festgelegten Katalog an Anforderungen, Regeln und vorgegebenen Prozessschritten gibt sie viele unverhandelbare Vorgaben an das System vor.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 15 : Ziele der beeinflussenden Nutzergruppen im Zielsystem
3.2.2 Anwendungsfälle
Da die Anwendungsfälle für ein System, welches versucht „alles zu können in der digitalen Welt“, recht schwer fassbar sind, werden in diesem Abschnitt die grundlegenden Anwendungsfälle beschrieben: dem der Informationswiedergabe und dem der Prozessausführung. Die Wiedergabe von verschiedensten Informationen und Aktionen ist die Grundlage aller Möglichkeiten, die innerhalb eines NUI geleistet werden können. Dabei können innerhalb der zwei grundlegenden Anwendungsfälle die Zugriffsarten in direkt- und indirekt unterschieden werden (siehe hierzu Kapitel 2.5 - Konversations-Assistenten). Diese Grundlagen erlauben es nicht nur über Webservices auf Unternehmensdaten und Geschäftsprozesse zuzugreifen, sondern auch auf den Zugriff interner Anwendungen; so wäre ein Zugriff des CAApp auf beispielsweise Computerspiele denkbar.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 16 : Hauptanwendungsfalldiagramm für das Zielsystem mit grundlegenden Funktionen
3.2.3 Prozesse
Die im Abschnitt 3.2.2 - Anwendungsfälle behandelten Fälle werden in diesem Abschnitt einem in BPMN modellierten Prozess dargestellt. Da die genaue Umsetzung erst im späteren Abschnitt der Arbeit evaluiert wird, werden Prozesse, die ein tieferes Verständnis der Funktionsweise des Systems vermitteln im Abschnitt 4.2 - Prozesse vorgestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 17 : Hauptprozessmodell für das Zielsystem mit grundlegenden Funktionen
3.2.4 Systemumgebung
In der Systemumgebung wird das System mit seinen Randbedingungen, Grenzen und im Kontext wiedergegeben, sodass der Umfang überschaubar wird.
Randbedingungen:
In diesem Abschnitt werden die Randbedingungen für die relevanten Nutzerzielgruppen beschrieben; dabei wird auf einen großen Nutzerkreis, die Rechtssicherheit und die Performance wertgelegt.
Jeder CAApp bringt sein eigenes Markup mit, welches im jeweiligen Umfeld des Anwenders eine (grafisch) aufbereitete Ausgabe, dem Kontext der Interaktion entsprechend, bereitstellt. Die jeweiligen Markups sind zu verwenden und vielseitig einzusetzen. Zusätzlich sollten möglichst viele interne Anwendungen (bspw. Kontaktliste oder Kalender) mit eingebunden werden, sodass ein applikationsübergreifendes Erlebnis mit vielen Erleichterungen für den Anwender geliefert werden kann.
Die Bereitstellung und flexible Anknüpfung an Schnittstellen Dritter ist ein zentraler Aspekt, um möglichst viele Unternehmen mit ihren Bestandssystemen anzusprechen und so eine schnelle und unkomplizierte Anbindung an das System zu ermöglichen. Zur sicheren und einfachen Anbindung zwischen den Systemen muss eine ausführliche Schnittstellenbeschreibung zur Verfügung gestellt werden, welche möglichst einfach und universell in der Umsetzung ist.
Zur einfachen Wartung und zum einfachen Update sollte die Geschäftslogik des Systems zentral und plattformungebunden abgelegt werden. Die jeweiligen Applikationen der Plattformen greifen dann auf dieses zentrale System über eine Schnittstelle zu. Die jeweiligen Applikationen halten sich an den Style-Guidelines der jeweiligen Plattformen und sollten sich möglichst nahtlos in das Plattformgefüge einbinden. Um nicht von unbekannten Servern und Systemen abhängig zu sein und die schnellste Auslieferung der gewünschten Daten zu ermöglichen sollte eine zentrale Datensammlung angelegt werden.
Für eine rechtssichere und standardisierte Softwareergonomie sind die Richtlinien nach der (EN) ISO 9241 ff einzuhalten. Da in dem System ein gewisser Zahlungsverkehr stattfinden kann, ist ggf. die ISO 15408 ff umzusetzen und deren Regularien einzuhalten. In der jeweils gewählten Programmiersprache der Systemkomponenten ist die objektorientierte Programmierung (OOP) mit deren Regularien einzusetzen.
Systemgrenzen:
Das System erhält kein eigenes Zahlungssystem, sondern nutzt nach Möglichkeit die Zahlungsmöglichkeiten der jeweiligen Plattform. Das System bietet keine Spiele oder ähnliche Unterhaltungsmöglichkeiten der Medienwelt direkt an. Es werden lediglich GP und Informationen ver- bzw. aufgearbeitet. Da es sich lediglich um eine Erweiterung der jeweiligen Konversations-Assistenten handelt ist in den Plattform-Applikationen keine direkte Oberfläche anzufertigen. Die Integration eines Advertising- oder Affiliate-Programmes ist ebenfalls nicht Bestandteil des Systems.
Systemkontext:
Im Kontext-Diagramm werden die Teile des Systems offenbart. Die Systembasis bildet hierbei den Mittelpunkt und stellt die gepufferten Daten den jeweiligen Anwendungen zur Verfügung.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 18 : Systemkontextdiagramm mit den wesentlichen Teilen
[...]
[1] Siehe http://www.herthemovie.com/
[2] Siehe http://www.ironman-derfilm.de/
[3] Vgl. [Mee16], S. 114
[4] Vgl. [Lan15], S. 12ff
[5] Microsoft's CEO Satya Nadella at Microsoft Developers Build Conference, 30.3.2016
[6] Siehe https://developer.microsoft.com/en-us/cortana, https://developers.google.com/actions/, https://developer.amazon.com/alexa, https://developers.facebook.com/products/messenger/
[7] [Mih16]
[8] Vgl. [Sch16]
[9] Vgl. [Ohl16]
[10] Vgl. [Kun16]
[11] Vgl. [Ohl16]
[12] Vgl. [Bas03], S. 74ff
[13] Philippe Kruchten, Grady Booch, Kurt Bittner und Rich Reitman, basierend auf (Shaw and Garlan 1996)
[14] Vgl. [Mcg03], S. 36
[15] Vgl [Bas03], S. 26ff
[16] Vgl. [Fie00], S. 24f
[17] Ebd., S. 107f
[18] Vgl. [Sta07], S. 10ff
[19] Vgl. [Fie00], S. 28f
[20] Ebd.
[21] Ebd., S. 76ff
[22] [Her13]
[23] Vgl. [Abi97], S. 1f
[24] Vgl. [Kdd97], S. 271f
[25] Vgl. [Her13]
[26] Siehe http://health-lifesci.schema.org/
[27] Vgl. [Abi97], S. 1f
[28] [Sch17]
[29] Vgl. [Kha13], S. 2f
[30] Vgl. [Kdd97], S. 272
[31] [Dan15]
[32] [Kha13], S. 1
[33] [Wsa04], S. 7
[34] Vgl. [Alo04], S. 124ff
[35] Vgl. [Fie00], S. 45f
[36] Vgl. [Wsa], S. 9
[37] Vgl. Ebd., S. 7f
[38] Vgl. [Owl04]
[39] [Ham07]
[40] Vgl. [Har12], S. 8ff
[41] Vgl. Ebd., S. 7
[42] [Kun16]
[43] Vgl. Ebd.
[44] Vgl. [Oen16], S. 92
[45] Vgl. [Nwa96], S. 66
[46] [Kun16]
[47] Ebd.
[48] Global Director for Mobile Product Management Kriti Sharma at Sage, 1.12.2016
[49] [Kun16]
[50] Vgl. [Por17], S. 3f
[51] [Stat1]
[52] Vgl. [War99], Kapitel 6
[53] Vgl. [Nwa96], S. 65f
[54] Vgl. [Fgt17]