Datenvisualisierung Softwarequalität auf iOS-Geräten

Inhaltsverzeichnis

I Abbildungsverzeichnis

II Quelltextverzeichnis

III Abkürzungsverzeichnis

1 Einleitung
1.1 Voraussetzungen
1.2 Motivation
1.3 Problemstellung

2 Theoretische Grundlagen
2.1 Softwaremetriken
2.1.1 C und C++
2.1.2 Designmetriken
2.1.3 HIS-Metriken
2.1.4 Java
2.1.5 Weitere Metriken
2.2 Tableau
2.2.1 Tableau REST API
2.2.2 Tableau Vizportal API
2.2.3 Tableau JavaScript API
2.3 Eingesetzte Programmiersprachen
2.3.1 JavaScript
2.3.2 Swift
2.4 Softwarearchitektur Theorie
2.4.1 Model View Controller
2.4.2 Target-Action
2.4.3 Delegation
2.4.4 Reaktive Programmierung
2.5 Eingesetzte Frameworks
2.5.1 WebKit
2.5.2 JavaScriptCore
2.5.3 RxSwift

3 Anforderungen an das System
3.1 Zielbestimmungen
3.2 Produkteinsatz
3.3 Produktfunktionen
3.3.1 An- und Abmelden
3.3.2 Speichern von Daten
3.3.3 Einstellungen
3.3.4 Teilen von Inhalten
3.4 Produktdaten
3.5 Produktleistungen
3.6 Qualitätsanforderungen
3.7 Ergänzungen
3.7.1 Realisierung
3.7.2 Authentifizierung
3.7.3 Portierbarkeit

4 Softwarearchitektur Umsetzung
4.1 Klassendiagramm
4.2 Implementierung: Model View Controller
4.2.1 Model
4.2.2 View
4.2.3 Controller
4.3 Target-Action
4.4 Delegation
4.5 Navigation
4.6 Reaktive Programmierung mittels Rx

5 Entwicklung der iOS Applikation
5.1 Authentifizierung
5.1.1 Uberprufung der Session
5.1.2 Verschlässelung mittels RSA PKCS1
5.1.3 Anmeldung
5.1.4 Implementierung Authentifizierung in Swift
5.2 Optimierung Dashboard zur mobilen Darstellung
5.3 Einbindung Dashboards
5.3.1 Einbindung Tableau HTML
5.3.2 Einbindung iOS Applikation
5.4 Implementierung Tableau JavaScript API
5.4.1 Kommunikation
5.4.2 Initialisierung
5.4.3 Filterfunktionen
5.4.4 Funktionen zum Setzen von Parametern
5.4.5 Eventhandler
5.4.6 Hilfsfunktionen
5.5 User Interface
5.6 Features
5.6.1 Speichern von Sessions
5.6.2 Teilen von Dashboards
5.6.3 3D Touch Support
5.6.4 Schnellnavigationsleiste

6 Schlussbetrachtung
6.1 Zusammenfassung
6.2 Fazit
6.3 Ausblick

7 Quellenverzeichnis

In der vorliegenden Masterarbeit wird die Entwicklung einer Applikation zur Darstellung von Softwarequalität auf Smartphones für das mobile Betriebssystem iOS beschrieben. Grundlage hierfär bildet eine Anwendung, die aus dem Quelltext von Softwareprojekten Metriken in Bezug auf Qualitätsmerkmale extrahiert. Die Daten wurden zur Visualisie­rung mit Hilfe der Anwendung Tableau aufbereitet und optisch ansprechend gestaltet.

Die hiermit erstellten Dashboards, die in Konzernen äblicherweise zum Reporting einge­setzt werden, können auf einem Server in Form von interaktiven Oberflächen auf Basis von HTML, CSS und JavaScript publiziert werden. Diese Dashboards werden in eine mobile Applikation eingebunden und mit einer nativen Benutzerschnittstelle versehen. Folgende Kernprobleme wurden hierbei geläst:

- Authentifizierung auf einem beliebigen mittels Tableau konfigurierten Server
- Einbindung der Dashboards
- Optimierung der Darstellung fur Gerate mit kleinen Displays
- Implementierung von Interaktionen mit Hilfe der Tableau JavaScript API

Im theoretischen Teil werden die Grundlagen der eingesetzten Entwurfsmuster sowie Pro­grammiersprachen vorgestellt und im Hinblick auf ihren jeweiligen Einsatzzweck erlautert. Anschließend wird detaillierter auf reaktive Programmierung und das dahinterliegende Konzept eingegangen. Den Abschluss des theoretischen Teils bildet dabei die Einfuährung in die Entwicklung von iOS Applikationen.

Der Hauptteil erlautert zunächst die Läsung der oben genannten Kernprobleme. Dar­auf aufbauend wird die Entwicklung der Applikation „Software Metrics“ detaillierter mit Bezug auf die im theoretischen Teil erläuterten Designkonzepte beschrieben.

Abschließend wird das Ergebnis dieser Arbeit kritisch im Hinblick auf Portierbarkeit be­trachtet und ein Ausblick auf Erweiterungsmoäglichkeiten gegeben.

I Abbildungsverzeichnis

Abb. 1 Dashboard Gesamtqualität, Screenshot aus eigener Anfertigung

Abb. 2 Model View Controller Design Pattern von [Inca]

Abb. 3 Target-Action Design Pattern von [Incb]

Abb. 4 Visualisierung des Delegate Design Pattern von [Ban16]

Abb. 5 Eventsequenz eines Observable<Orientation> von [FP17]

Abb. 6 Operatoren zur Bearbeitung von Events der Geräteausrichtung von [FP17]

Abb. 7 JavaScriptCore Hauptklassen von [Ves]

Abb. 8 Use Case Diagramm der Anwendung „Software Metrics“, erstellt mit Hilfe von https://creately.com

Abb. 9 Schaubild Systemarchitektur „Software Metrics“, Screenshot aus eige­ner Anfertigung

Abb. 10 Klassendiagramm;Software Metrics“ - schematische Darstellung, Screens­hot aus eigener Anfertigung

Abb. 11 Model Klassen „Software Metrics“, Screenshot aus eigener Anfertigung 30 Abb. 12 View Klassen Software Metrics“, Screenshot aus eigener Anfertigung

Abb. 13 View Controller Lifecycle von [Incf]

Abb. 14 Controller Klassen „Software Metrics“, Screenshot aus eigener Anfer­tigung

Abb. 15 Filterauswahl, Screenshot aus eigener Anfertigung

Abb. 16 Anmeldeprozess App Software Metrics“, Screenshot aus eigener An­fertigung

Abb. 17 Tableau Dashboard auf verschiedenen Endgeraäten, Screenshot aus ei­gener Anfertigung

Abb. 18 OverallQualityViewController in Explosionsdarstellung, Screens­hot aus eigener Anfertigung

Abb. 19 Main.Storyboard „Software Metrics“ innerhalb Interface Builder, Screen­shot Integrated Development Environment (IDE) Xcode aus eigener Anfertigung

Abb. 20 Einbindung UIWebView mittles Interface Builder, Screenshot aus eige­ner Anfertigung

Abb. 21 UIWebViewDelegate von [Incd]

Abb. 22 Tableau JavaScript Application Programming Interface (API) Top- Level Class Diagram von [Inch]

Abb. 23 Tableau Filter Klassendiagramm von [Inch]

Abb. 24 Thumb-zone mapping von [Ing]

Abb. 25 Navigation Applikation Software Metrics“, Screenshot aus eigener Anfertigung

Abb. 26 Feature: Speichern von Sessions, Screenshot aus eigener Anfertigung .

Abb. 27 Feature: Teilen von Dashboards, Screenshot aus eigener Anfertigung .

Abb. 28 Feature: 3D Touch Support, Screenshot aus eigener Anfertigung . . .

Abb. 29 Feature: Schnellnavigationsleiste, Screenshot aus eigener Anfertigung .

II Quelltextverzeichnis

1 Definition einer Variable als „optional“

2 Optional Binding

3 Definition und Implementierung des NSCopying Protokolls

4 Observable bei Überprüfung der Gültigkeit eines Tableau Servers

5 Operatoren zur Bearbeitung von Events der Gerüteausrichtung von [FP17]

6 Interface TableauViewController

7 Interface Builder - Funktion IBAction

8 Protokoll ParameterViewControllerDelegate

9 Implementierung ParameterViewControllerDelegate in der Klasse QualityViewController

10 Delegator - ParameterViewController

11 Aufruf von Delegate Funktionen ParameterViewController

12 Setzen der Delegate-Variable ParameterViewControllerDelegate

13 Vizportal API Endpoint generatePublicKey

14 Interface TableauApiController

15 RX Funktion loginWithUsername

16 JavaScriptCore JSContext

17 Funktion encryptMessage

18 Einbindung Tableau Hypertext Markup Language (HTML)

19 Initialisierung Tableau JavaScript API

20 Funktion onFirstInteractive()

21 Funktion initWebView(withUrl dashboardUrl: String)

22 Funktionen Tableau JavaScript API

23 JavaScript Funktion sendValuesToApplication

24 UIView Extension

III Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Das Thema dieser Arbeit ist die Datenvisualisierung von Softwarequalität auf iOS-Gerät- en. Die offizielle Definition von Softwarequalitatsmetrik nach IEEE Standard 1061 lautet:

„Eine Softwarequalitätsmetrik ist eine Funktion, die eine Software-Einheit in einen Zahlenwert abbildet, welcher als Erfüllungsgrad einer Qualitätseigenschaft der Software-Einheit interpretierbar ist.“

Diese Metriken geben jedoch keine Auskunft uber die korrekte Umsetzung einer Funk­tion, sondern sind lediglich Qualitatsmerkmale über Wartbarkeit, Erweiterbarkeit oder Verständlichkeit der Software.

Grundlage fur die Arbeit bildet eine Anwendung, die aus dem Quelltext von Software­projekten, Metriken in Bezug auf Qualitatsmerkmale extrahiert. Diese kann auf verschie­dene Softwareprojekte angewendet werden. Diese Daten werden anschließend mit Hilfe der Software Tableau aufbereitet und in Diagramme und Grafiken umgewandelt. Die Veröffentlichung ist entweder äber die Software selbst oder äber die Einbindung in Web­seiten äber HTML und JavaScript moglich. Die Diagramme und Grafiken von Tableau werden als Worksheets und Dashboards bezeichnet. Bei einem Worksheet handelt es sich um ein einzelnes Element, wäahrend Dashboards eine Komposition von mehreren Work­sheets meint. Diese sind in dem Sinne interaktiv, da sie Bedienelemente zum Filtern und Modifizieren der Daten beinhalten.

Das Ziel dieser Arbeit ist es, diese bereits bestehenden Dashboards, die unter dem Namen „SW-Quality“ auf einem mit Tableau konfigurierten Server veröffentlicht wurden, in eine iOS Applikation zu integrieren. Hierbei sollen diese zum einen fuär die mobile Darstellung optimiert und zum anderen das User Interface (UI) durch ein natives ersetzt werden.

1.1 Voraussetzungen

Voraussetzung fur die Arbeit sind die bereits auf einem Tableau-Server veröffentlichten Dashboards „Gesamtqualität“, „Qualitätsanalyse“ und „Releases und Benchmarks“. Das Dashboard Gesamtqualität ermäglicht zunächst die Auswahl von verschiedenen Software­projekten, die sich näher untersuchen lassen. Im oberen Teil sind Pakete bzw. Komponen­ten in einem Kacheldiagramm visualisiert. Diese entsprechen beispielsweise bei einem Java Projekt Packages, die dazu genutzt werden, mehrere Klassen in einem Geltungsbereich zu vereinen. Die farbliche Kodierung gibt jeweils Auskunft uber deren Qualitätsindex. Dabei korreliert Rot mit niedriger, Gelb mit mittlerer und Grun mit hoher Qualität.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Dashboard Gesamtqualität

Abbildung 1 zeigt das Dashboard Gesamtqualitat, das im Folgenden exemplarisch erläu­tert werden soll. Es gibt dem Nutzer die Möglichkeit, sich äber die Qualitat verschiedener Softwareprojekte zu informieren und deren Ursprung zu ergränden. Das Dashboard stellt insgesamt sechs Worksheets in einer Visualisierung dar. Im Speziellen sind dies: Packages, Softwarequality Flower, Quality Index, Traffic Light, Title und Core Metrics.

Tableau Dashboards sind äblicherweise so strukturiert, dass der obere Teil dazu genutzt wird, darunterliegende Grafiken zu filtern, um detaillierte Informationen uber selektierte Elemente zu erhalten. Wird ein Package im Bereich Pakete/Komponenten selektiert, so werden in einer Infobox Informationen uber Verzeichnis, Dateien und Defekte ausgegeben. Weiterhin werden die Bereiche Qualitaätsindex, Programmdateien und Projekteckdaten dazu genutzt, detaillierte Informationen äber das selektierte Package anzuzeigen.

Der Bereich Qualitäatsindex zeigt die Qualitaät der selektierten Komponenten. Dieser kann einen Wert von 0 bis 100 annehmen. Je großer der Qualitätsindex, desto niedriger ist die Qualitaät. Das darunterliegende Balkendiagramm dient zur zusaätzlichen Visualisierung des Wertes, indem es den erreichten Wert auf einer Skala mit Markierungen anzeigt. Hohe Qualität wird bei Werten von 0 bis 6, mittlere Qualitat bei Werten zwischen 6 bis 50 und niedrige Qualitat bei Werten gräßer 50 bis 100 erreicht.

Der Bereich Programmdateien zeigt alle zu der entsprechend selektierten Komponente gehörigen Dateien in einem Bubble Chart. Dabei entspricht der Umfang jeder Kugel jeweils dem Umfang der entsprechenden Quelltextdatei. Die farbliche Kodierung ist analog zu den Kategorien Pakete/Komponenten bzw. Qualitatsindex. Bei der Selektion einzelner Dateien werden Informationen über ausgewöhlte Metriken der Datei angezeigt. Dies sind zyklomatische Komplexitöt, Defekte und der exakte erreichte Qualitatsindex.

Im Bereich Projekteckdaten werden, jeweils zu der entsprechend ausgewöhlten Kompo­nente, Informationen in tabellarischer Form angezeigt. Beispielsweise die Anzahl der Da­teien, Lines of Code (LOC), Kommentarzeilen und das Verhaltnis von Kommentarzeilen zu Codezeilen.

Die obere Leiste unterhalb des Dashboardtitels wird dazu genutzt, Informationen zu se­lektieren und zu filtern. Zunöchst kann das zu untersuchende Projekt selektiert werden. Im nöchsten Element wird der zu untersuchende Metriktyp ausgewöhlt. Mögliche Aus­wahlmöglichkeiten sind hierbei: Code, Design oder beides gleichzeitig. Die Box Metrik­gruppe ermöglicht die Auswahl spezieller Gruppierungen von Metriken. Mögliche Werte sind: C and C++, Designmetriken, HIS-Metriken, Java, NONE und weitere Metriken. Ele­mente können inkludiert und exkludiert werden. Die folgende Auswahlleiste ermoglicht das Filtern und Selektieren einzelner und mehrerer spezieller Softwaremetriken. Dabei handelt es sich z.B. um: Calling Functions, Count of Couples, Comment Density, Count of Instance Methods oder Count of All Methods. Abschließend konnen auch noch einzelne Pakete/Komponenten ausgewaöhlt werden. Dies erfolgt analog zu der Auswahl im Bereich Pakete/Komponenten.

Diese Arten von Dashboards sollen nun fur die mobile Darstellung optimiert und in eine iOS Applikation integriert werden. Tableau Visualisierungen sind ublicherweise für die Verwendung auf Desktopcomputern optimiert, wobei die Interaktion mir einer Maus oder ahnlichen Eingabeelementen erfolgt.

Tableau bietet mehrere Moöglichkeiten, auf Inhalte programmatisch zuzugreifen. Im Spe­ziellen sind dies die APIs „Tableau REST API“, „Tableau JavaScript API“ und „Tableau Vizportal API“. Diese Schnittstellen konnen dazu genutzt werden, Ressourcen program­matisch abzufragen und auch das User Interface komplett zu ersetzten.

1.2 Motivation

Die entwickelte Anwendung soll es Unternehmen, die Tableau einsetzten, ermöglichen, auf Reports mit Hilfe einer App zuzugreifen. Diese soll den Komfort nutzen, den native Anwendungen in Bezug auf das User Interface bieten. Das entwickelte System muss alle Funktionen, die auch die ursprnngliche Anwendung verfögt, besitzen.

1.3 Problemstellung

Folgende Kernprobleme mussen hierbei gelöst werden:

- Authentifizierung auf einem beliebigen mittels Tableau konfigurierten Server
- Optimierung der Darstellung fur Gerate mit kleinen Displays
- Einbindung der Dashboards
- Implementierung von Interaktionen mit Hilfe der Tableau JavaScript API

Dashboards werden ublicherweise auf einem mit Tableau konfigurierten Server veröffent­licht. Der Nutzer muss sich hierauf anmelden konnen, um Zugriff auf die gewunschten Visualisierungen zu erhalten. Die Verschlösselung von sensiblen Daten erfolgt unter Ver­wendung des RSA Verfahrens.

Die ursprönglich veröffentlichten Dashboards „Gesamtqualitöt“, „Qualitatsanalyse“ und „Release und Benchmarks“ sind nicht fur eine mobile Darstellung optimiert. Die einge­betteten Bedienelemente lassen sich nur schwer auf einem Smartphone mit Touchscreen bedienen.

Ublicherweise erfolgt die Einbindung von Dashboard öber HTML und JavaScript. Eine Schnittstelle fur eine dem Betriebssystem iOS konforme Programmiersprache, besteht nicht. Die Visualisierungen mössen so eingebunden werden, dass eine Interaktion öber för iOS native Benutzereingaben erfolgen kann.

Tableau ermoglicht das Steuern und Modifizieren von Dashboards uber die Tableau Java­Script API. Gewunschte Funktionalitäten mussen unter Verwendung dieser Schnittstellen implementiert werden. Anschließend muss eine Kommunikationsmäglichkeit zwischen den Programmiersprachen JavaScript und Swift geschaffen werden.

2 Theoretische Grundlagen

Im Folgenden wird auf die zugrunde liegenden theoretischen Grundlagen, die zur Um­setzung der oben genannten Problemstellungen benötigt werden, eingegangen. Dies sind Schnittstellen von Tableau, Softwarearchitektur, Programmiersprachen und verwendete Frameworks.

2.1 Softwaremetriken

Vor den Grundlagen der Technologien zur Realisierung des Systems soll kurz auf Software­metriken eingegangen werden. Diese geben keine Auskunft uber die korrekte Umsetzung einer Funktion oder dessen Performance, sondern sind lediglich Qualitätsmerkmale uber Wartbarkeit, Erweiterbarkeit oder Verstandlichkeit der Software. Es soll ein Uberblick uber die Einteilung von Softwaremetriken gegeben und einzelne Metriken kurz erlautert werden.

Softwaremetriken kännen nach verschiedenen Aspekten klassifiziert werden. Da diese im Kontext der verwirklichten Arbeit dargestellt werden, wird hier auf die Klassifikation nach Metrikgruppen wie im Workbook „SW-Quality“ angewandt eingegangen. Weiterhin werden die Metriken nach Designmetriken und Codemetriken unterteilt.

2.1.1 C und C++

Die Gruppe ,,C und C++“ vereint spezielle Metriken fur C- und C++ -Softwareprojekte.

Single Exit Point at End

Gibt an ob die Funktion jeweils nur ein return-Statement enthält.

Unreachable Code

Hiermit werden unerreichbare Codesegmente detektiert. Dieser Quelltext ist aufgrund bestimmter Bedingungen nicht erreichbar und somit äberflussig.

2.1.2 Designmetriken

Die Definition von Designmetriken nach Dumke lautet wie folgt: „Designmetriken beziehen sich auf den Systementwurf und damit vor allem auf die Architektur bzw. Struktur des Software-Systems“ (vgl. [Dum13]). Das heißt, hier werden nicht einzelne Funktionen oder Module untersucht, sondern auf einer hoäheren Abstraktionsebene Klassenstruktur und Vererbung analysiert.

CBO (Count of Coupled Classes)

Anzahl anderer Klassen, die mit der zu untersuchenden Klasse gekoppelt sind.

IFANIN (Count of Base Classes)

Anzahl der unmittelbaren Basisklassen.

LCOM (Percent Lack of Cohesion)

Errechnet sich aus der Abweichung von 100 Prozent minus dem Durchschnitt der „cohe­sion“ für Klassenfunktionen. Eine Funktion wird als „cohensive“ bezeichnet, wenn sie nur eine einzelne Aufgabe ausführt.

NIM (Count of Intance Methods)

Anzahl der Instanzmethoden der zu untersuchenden Klasse.

NIV (Count of Instance Variables)

Anzahl der Instanzvariablen der zu untersuchenden Klasse.

NOC (Count of Derived Classes)

Anzahl der unmittelbaren Subklassen der zu untersuchenden Klasse.

RFC (Count of All Methods)

Anzahl aller Methoden der zu untersuchenden Klasse. Hierzu zühlen auch vererbte Me­thoden.

WMC (Count of Methods)

Anzahl aller lokalen Methoden einer Klasse.

2.1.3 HIS-Metriken

Die HIS (Hersteller initiative Software) besteht aus fìinf Arbeitsgruppen der Automobil­hersteller Audi, BMW Group, Daimler, Porsche und Volkswagen. Das Ziel dieser Ver­einigung ist die Herstellung von einheitlichen Standards in den Bereichen Standardsoft­waremodulen fur Netzwerke, Prozessreifegradermittlung, Softwaretests, Softwaretools und dem Programmieren von Steuergeraten (vgl. [Kud]). Im Zuge dessen wurden standardi­sierte Metriken festgelegt, auf die hier genauer eingegangen wird. Der Wertebereich in Klammern entspricht den in der Dokumentation der HIS-Metriken angegebenen Werten.

Called Functions (HIS6, CALLS)

Die Metrik gibt Auskunft darüber, wie viele Funktionen innerhalb einer Funktion aufge­rufen werden. Wird eine Untermethode mehrmals aufgerufen, so zählt diese nur einmal. (Wertebereich: 0-7)

Calling Functions (HIS5, CALLING)

Gibt Auskunft daräber, von wie vielen Unterfunktionen die zu untersuchende Funktion aufgerufen wird. (Wertebereich: 0-5)

Comment Density (HIS1, COMF)

Beschreibt das Verhältnis von der Anzahl an Kommentaren zu der Anzahl an Anweisun­gen. Gibt Auskunft uber die Verstandlichkeit des Quelltextes. Der Wert sollte nicht gräßer als 1 sein. (Wertebereich: > 0,2)

Cyclomatic Complexity (HIS4, v(G))

Zyklomatische Komplexität wurde von McCabe in der wissenschaftlichen Fachzeitschrift „IEEE Transactions on Software Engineering“ definiert (vgl. [McC76]). Die Idee dahin­ter ist, dass ein Softwaremodul ab einer bestimmten Komplexität für den Nutzer nicht mehr verstaändlich ist. Die auch als McCabe-Metrik bezeichnete Softwaremetrik orientiert sich am Kontrollflussgraphen, der zur Programmoptimierung eingesetzt wird. Der Ansatz hierbei ist, dass die Gute nicht nur vom Umfang des Quelltextes abhangig ist, sondern von seiner Strukturiertheit. Bei einem bestehenden Kontrollflussgraphen berechnet sich zyklomatische Komplexitaät wie folgt:

Abbildung in dieser Leseprobe nicht enthalten

Wobei e der Anzahl der Kanten, n der Anzahl der Knoten und p der Anzahl der Zu­sammenhangskomponenten des Graphen entspricht. Nach der deutschsprachigen Anwen­dergruppe fur Software-Metrik und Aufwandschatzung e.V. wird diese Metrik oft als In­dikator fur potenzielle Qualitatsprobleme eingesetzt. Sie ist ein Maß fär die Anzahl der Testfalle (vgl. [Ae04]). (Wertebereich: 0 - 10)

Function Parameters (HIS7, PARAM)

Gibt Auskunft uber das Interface der Funktion, indem sie die Anzahl der zu ubergebenden Parameter beräcksichtigt. (Wertebereich: 0-5)

Language scope (HIS11, VOCF)

Abbildung in dieser Leseprobe nicht enthalten

„Language scope“ ist ein Indikator für Kosten, die aufgewendet werden müssen, um eine Funktion instand zu halten oder zu ündern. Er berechnet sich wie folgt:

Dabei entspricht N1 der Summe aller Operatoren, N2 der Summe aller Operanden, nl der Anzahl der unterschiedlichen Operatoren und n2 der Anzahl der unterschiedlichen Operanden. (Wertebereich: 1-4)

Number of call levels (HIS9, LEVEL)

Beschreibt die Tiefe der Verschachtelung innerhalb einer Funktion. (Wertebereich: 0-4)

Number of Paths (HIS2, PATH)

Gibt Auskunft uber die Anzahl der Pfade durch einen Quelltext. Zyklische Pfade werden nicht berücksichtigt. Dient als Hinweis auf mögliche Aufsplittung in mehrere Unterfunk­tionen. (Wertebereich: 1 - 80)

Number of Statements (HIS8, STMT)

Anzahl der Anweisungen innerhalb einer Funktion. Gibt Auskunft uüber die Komplexitaüt der Funktion. (Wertebereich: 1 - 50)

Recursion (HIS12, AP_CG_CYCLE)

Anzahl von Rekursionen innerhalb einer Funktion.

2.1.4 Java

Die Gruppe Java vereint Metriken fur Java-Softwareprojekte. Hierunter fallen: „Unused Instance Variables“, Unused Local Variables“ und Unused Methods“. Sie ent­sprechen: ungenutzter Instanzvariablen, ungenutzter lokalen Variablen und ungenutzter Methoden.

2.1.5 Weitere Metriken

Hierunter werden Metriken aufgelistet, die unter keine der oben genannten Kategorien passen. Darunter faüllt nur die Metrik Program Unit Max Nesting Depth“, die daruber Auskunft gibt, wie weit ein Programm verschachtelt ist.

2.2 Tableau

Tableau ist eine Software zur Datenvisualisierung und wird üblicherweise in Unternehmen zum Reporting eingesetzt. Damit lassen sich interaktive Tabellen und Grafiken erstellen, die anschließend über die Software an Mitarbeiter verteilt bzw. als Webcontainer auf Internetseiten veröffentlich werden künnen.

Die Software ist auf allen güngigen Plattformen verfugbar. Des Weiteren gibt es auch eine Server- und eine Onlinevariante, die eine Bearbeitung der Daten im Browser erlaubt. Tableau ermoglicht das Verbinden mit lokalen Daten sowie die Anbindung an große Da­tenbanken. Dabei unterstutzt es alle güngigen Formate sowie die Vernetzung mit Cloud- Applikationen wie Google Analytics und Salesforce.

Tableau ist auch in deutscher Sprache verfugbar. Um die Verstündlichkeit vor allem in Bezug auf die Anbindung der Tableau JavaScript API zu erleichtern, werden im Text ausschließlich die englischen Begriffe verwendet. Zum Beispiel „Worksheet“ anstatt „Ar­beitsblatt“.

Bei einer immer grüßer werdenden Datenmenge hat es sich Tableau zum Ziel gesetzt, diese Daten intuitiv durch visuelle Werkzeuge zu erschließen. Im ersten Schritt koünnen verschieden Datenquellen ausgewühlt, über einen Dataconnector miteinander verbunden und zur weiteren Bearbeitung aufbereitet werden. Anschließend werden aus diesen Daten Worksheets erstellt. Ein Worksheet enthalt eine einzelne Ansicht sowie Container, Legen­den und den Datenbereich. Aus diesen Worksheets künnen dann wiederum Dashboards erstellt werden, die eine Sammlung von Ansichten darstellen. Eine Story enthült eine Se­quenz von Arbeitsblüttern oder Dashboards, die hiermit eine Geschichte erzahlen und Informationen ubermitteln (vgl. [Incg]).

Üblicherweise werden Worksheets zur Erkundung und Visualisierung der Daten und Dash­board und Stories zur Prüsentation und Verteilung an andere Mitarbeiter verwendet.

2.2.1 Tableau REST API

Mit der Tableau REST API künnen Tableau Server Ressourcen uber HTTP verwaltet und geaündert werden. Die API bietet einen einfachen Zugriff auf Funktionen hinter Datenquel­len, Projekten, Arbeitsmappen, Benutzern und Standorten auf einem Tableau-Server. Sie kann dazu benutzt werden, eigene benutzerdefinierte Anwendungen zu erstellen oder In­teraktionen mit Tableau Server-Ressourcen zu verwirklichen. Die Tableau REST API wurde fuür das Projekt dieser Arbeit nicht verwendet und wird nur der Vollstüandigkeit halber erwühnt.

2.2.2 Tableau Vizportal API

Die Vizportal API ist eine von Tableau intern verwendete Schnittstelle, für die keine öffentliche Dokumentation existiert. Es ist die Technologie, die es Web-Klienten von Ta­bleau Server ermöglicht, sich auf dem Server anzumelden und Daten abzurufen. Viele Funktionen wie beispielsweise eine Authentifizierung sind uber die offizielle Tableau Java­Script API nicht moglich. Die Vizportal API schließt diese Lucke. Üblicherweise erfolgt die Anmeldung an einem Tableau Server uöber die Weiterleitung an eine Anmeldeseite, die bei Erfolg einen entsprechenden Cookie setzt. Dies erfullt jedoch nicht die Anspriiche einer nativen Applikation, da sie sich nur öber den Ümweg eines Browsers benutzen lösst.

Tableau mobile, die offizielle App för iOS verwendet diese Schnittstelle. Fur das Projekt wurde ein Zugriff durch Reverse Engineering der Tableau Vizportal API auf die Login Funktion ermoglicht.

2.2.3 Tableau JavaScript API

Die Tableau JavaScript API kann dazu genutzt werden, Tableau Visualisierungen in eigene Webanwendungen zu integrieren und mit diesen zu interagieren.

Dies umfasst folgende Kernaspekte:

- Anzeigen von Visualisierungen von Tableau Server, Tableau Public und Tableau Online auf Webseiten.
- Dynamisches Laden und Skalieren von Visualisierungen.
- Zugriff auf die zugrundeliegenden Daten.
- Filtern der angezeigten Daten.
- Markieren von Daten.
- Das Reagieren auf Ereignisse.
- Speichern von Sitzungen.
- Exportieren von Visualisierung als Bild oder PDF.

Ziel der API ist es, Interaktionen die uöblicherweise vom Benutzer erfolgen, uöber eine Schnittstelle zu ermöglichen. Somit wird das Interface durch ein eigenes, speziell fur den entsprechenden Kontext optimiertes, ersetzt.

2.3 Eingesetzte Programmiersprachen

Die Verfügbarkeit der APIs von Tableau erfordert es, die Applikation mit mehreren Pro­grammiersprachen zu verwirklichen, da diese insbesondere zur Steuerung der Benutzer­oberflüchen nur für JavaScript verfügbar sind. Das mobile Betriebssystem iOS unterstützt mit dem Framework JavaScriptCore die Zusammenarbeit von JavaScript- mit Swift­Quelltext. Im folgenden soll kurz auf die verwendeten Sprachen eingegangen werden.

2.3.1 JavaScript

JavaScript dient zur dynamischen Darstellung von HTML- und CSS-Inhalten. Die Sprache wird clientseitig im Browser des Anwenders ausgefuhrt und muss von diesem unterstutzt werden. Sie kann entweder uber eine externe Datei innerhalb des HTML-HEAD Elements eingebunden oder direkt im Dokument mit Hilfe des script“ Elements untergebracht werden.

Die Sprache ist dynamisch typisiert und objektorientiert und lüsst sich je nach Bedarf objektorientiert, prozedural oder funktional programmieren. Insbesondere die verwendete Tableau JavaScript API enthült auch reaktive Ansütze, die den Umgang mit asynchronen Operationen erleichtert.

2.3.2 Swift

Die Programmiersprache Swift wurde im Herbst 2014 auf Apples jahrlicher Entwicklerkon­ferenz WWDC veröffentlicht. Sie soll in Zukunft die Sprache Objective-C ablosen. Diese basiert auf der Programmiersprache C und hat sie um die Moüglichkeit der objektori­entierten Programmierung erweitert. Swift greift absturzsicherere Programmierkonzepte auf und integriert viele neuartige Programmierparadigmen anderer Sprachen, die sich in den letzten Jahren bewaührt haben. Dies sind beispielsweise Subscripts, auch bekannt als Blocks oder Lamda-Ausdruücke, die es ermoüglichen, ganze Codefragmente wie Objekte zu behandeln und die etwa auch als Argumente und Rückgabewerte für Funktionen dienen koünnen.

Die Sprache ist sicher in dem Sinne, dass sie den Entwickler zur sicheren Programmierung zwingt. Dies wird durch die Einführung des Konzeptes der „optionals“ erreicht, wofìir es in anderen Sprachen nichts Vergleichbares gibt. Die meisten Programmabstürze werden durch den Aufruf einer Variablen verursacht, die auf keine Speicheradresse verweist, da eine solche beispielsweise noch nicht initialisiert worden ist. Dies ist möglich, da es in den meisten Programmiersprachen erlaubt ist, Variablen zu definieren, ohne sie zu initia­lisieren. Solche Probleme werden bei Swift durch die Einfuhrung von „optionals“ gelüst.

Jene werden bei der Variablendefinition durch ein nachgestelltes „?“ hinter dem Varia­blentyp gekennzeichnet. Die beiden Zustande, die eine als „optional“ definierte Variable haben darf, sind: „Es gibt einen Wert, und dieser ist gleich x“, oder „Es gibt keinen Wert“, was durch das Signalwort „nil“ gekennzeichnet wird. Listing 1 zeigt die Definition und Initialisierung einer Integer-Variablen als „Optional“. Dies erfolgt in Zeile Nummer 1.

Abbildung in dieser Leseprobe nicht enthalten

Listing 1: Definition einer Variable als optional“

Der wahre Nutzen erschließt sich jedoch erst in Kombination mit dem Konzept des „Op­tional Binding“. Hierbei wird innerhalb des Kopfes einer If-Anweisung der Inhalt einer Optional Variablen an eine lokale definierte Variable gebunden. Falls dies möglich ist, wird das darauf anschließende Codefragment ausgeföhrt. Listing 2 zeigt die Anwendung von „optional binding“. Es wird die lokale Variable actualNumber definiert, der, falls die Konvertierung der String-Variable possibleNumber in ein Integer-Variable erfolgreich ist, ihr Wert zugewiesen wird.

Abbildung in dieser Leseprobe nicht enthalten

Listing 2: Optional Binding

Eine Besonderheit, die vor allem bei Skriptsprachen der Internetprogrammierung hohe Verbreitung hat, ist die Möglichkeit der nachlössigen Handhabung bei der Definition von Variablen. Diese gestaltet sich im Gegensatz zu typischen Script-Sprachen wie Python, VBA oder JavaScript jedoch flexibel. So ist es möglich, die Auswahl des richtigen Daten­typs dem Compiler zu uöberlassen oder diesen explizit anzugeben.

Ein weiteres sehr nuötzliches Feature ist die Einfuöhrung von sogenannten Playgrounds. Dies ist eine in die Apple Entwicklungsumgebung Xcode integrierte Umgebung, die es ermöglicht, Quelltext in Echtzeit auszufuhren und zu modifizieren. Dies erleichtert die Entwicklung enorm, da die aufwendige Einarbeitung in Programmbibliotheken durch das Experimentieren mit Programmcode das Lernen erleichtert. Viele Anbieter von APIs bie­ten dafur bereits vorgefertigte Playgrounds an.

2.4 Softwarearchitektur Theorie

Im Folgenden soll auf die Theorie der verwendeten Softwarearchitektur, insbesondere auf die verwendeten Entwurfsmuster eingegangen werden. Die konkrete Umsetzung in der Applikation „Software Metrics“ wird in Kapitel 4 (S. 27) beschrieben.

Entwurfsmuster (Design Pattern) sind abstrakte Konzepte, die dazu genutzt werden, all­gemeine Softwareentwicklungsprobleme zu losen. Apple verfolgt dabei ein Konzept, das auf drei Hauptentwurfsmustern basiert. Dies sind Model View Controller (MVC), Target­Action und Delegation. Grundsätzlich gibt es auch ähnliche Ansätze in anderen Program­miersprachen. Dennoch ist es lohnenswert, sich in diese Konzepte einzuarbeiten. Nach diesem Paradigma entwickelte Anwendungen ermäoglichen es, Programmcode besser zu recyceln, leichter zu erweitern und einfacher zu warten.

Weiterhin wurden einzelne Komponenten mittels reaktiver Programmierung verwirklicht, die mehrere Konzepte miteinander vereint. Sie wird auch als Erweiterung des Beobach­termusters angesehen.

2.4.1 Model View Controller

Das MVC Design Pattern weist innerhalb der objektorientierten Programmierung einem Objekt eines der drei Rollen Model, View oder Controller zu. Das Muster definiert hierbei nicht nur die Rolle, die es in der Anwendung spielt, sondern legt auch fest, wie Objekte miteinander kommunizieren. Sämtliche Klassen innerhalb des von Apple zur Verfägung gestellten Frameworks, das unter dem Namen Cocoa zusammengefasst wird, basieren auf diesem Prinzip. Abbildung 2 zeigt eine grafische Darstellung des MVC Entwurfsmusters. Dabei kommt die Datenkapselung, ein Paradigma aus der objektorientierten Program­mierung, zur Anwendung. Damit bleiben Daten eines Objekts von außen verborgen und die Kommunikation mit anderen Objekten erfolgt durch definierte Schnittstellen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Model View Controller Design Pattern

Model

Das Model Objekt kapselt alle Daten in Bezug auf die Anwendung und definiert die Lo­gik und Berechnung, die notwendig ist, diese zu verändern. Ein Datenmodell kann z.B. einen Kontakt in einem Telefonbuch bzw. den Charakter in einem Spiel repräsentieren. Diese koännen miteinander agieren und werden haäufig nicht nur durch ein einzelnes Ob­jekt dargestellt. Bei der Speicherung von Daten einer Anwendung ist es wichtig, dass sich diese an einer zentralen Stelle befinden. Wahrend der Initialisierung einer Anwen­dung lassen sie sich hierdurch einfacher wiederherstellen. Da ein Model Objekt säamtliches Wissen und Können in Bezug auf einen bestimmten Problembereich bändelt, kann dieses fär andere Problemstellungen wiederverwendet werden. Idealerweise enthält es keine di­rekten Verbindungen zu einem View Objekt. Die Kommunikation mit Benutzereingaben erfolgt ausschließlich uber das Controller Objekt, welches ihm beispielsweise mitteilt, sein Datenmodell zu aktualisieren. Umgekehrt informiert es das View Objekt, sobald es sich verändert hat und teilt ihm dies uber das Controller Objekt mit. (vgl. [Inca])

View

Das View Objekt ist das Objekt, das der Nutzer sehen kann. Es beinhaltet die nätigen Algorithmen zur visuellen Darstellung und „weiß“ damit, wie es sich rendern muss und kann auf Benutzereingaben reagieren. Eines seiner Hauptaufgaben ist es, die Daten des Model Objekt anzuzeigen und es zu ermoäglichen, diese Daten zu veräandern. Innerhalb des MVC Patterns ist es gekapselt, wobei die Kommunikation mit dem Objekt Model ausschließlich uber das Controller Objekt erfolgt. Interface Builder, ein Unterprogramm der IDE Xcode, das zur Erstellung von Anwendungen fur Apple Betriebssysteme genutzt wird, enthält eine Vielzahl an vorgefertigten View Objekten. Diese sind unter dem Frame­works UIKit gebundelt und sind beispielsweise Buttons, Labels, Texteingabefelder oder Image Views. (vgl. [Inca])

Controller

Controller Objekte fungieren als Vermittler zwischen View und Model Objekten und die­nen sozusagen als Isolierung zwischen ihnen. Hierdurch wird die Kommunikation unter ihnen geregelt. Zusätzlich nehmen sie Initialisierungs- und Koordinationsaufgaben wahr und managen den Lebenszyklus von Objekten. Ein Controller Objekt interpretiert Benut­zereingaben, die es von dem View Objekt uäbermittelt bekommt und veranlasst daraufhin eine Veraänderung innerhalb des Datenmodells. Umgekehrt wird bei einer Veräanderung des Datenmodells, dies dem View Objekt uber das Controller Objekt mitgeteilt, was eine Neuberechnung des View Modells zur Folge hat. (vgl. [Inca])

2.4.2 Target-Action

Abbildung in dieser Leseprobe nicht enthalten

iOS Apps basieren auf einer eventgesteuerten Programmierung. Das bedeutet, dass der Ablauf einer Anwendung von Ereignissen gesteuert wird. Dies können vom System initi­ierte Events oder Benutzerinteraktionen sein. So losen Interaktionen des Benutzers mit den Schnittstellen des Geraöts, beispielsweise des Touch Screens, Events innerhalb der An­wendung aus, die wiederum die Manipulation von Daten veranlassen. Target-Action ist ein einfaches konzeptuelles Design, bei dem ein Objekt eine Nachricht an ein anderes Objekt schickt, wenn ein gewisses Ereignis eintritt. Dabei bedeutet der Begriff Action, Action Message im Sinne eines Funktionsaufrufs und Target bezeichnet den Empfönger. Abbildung 3 veranschaulicht das Target-Action Design Pattern.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Target-Action Design Pattern

2.4.3 Delegation

Delegation ist ein einfaches Entwurfsmuster, bei dem ein Objekt im Auftrag eines ande­ren handelt und dies durch Protocols ermöglicht. Dies sind abstrakte Vorschriften, die eine Klasse implementieren kann. Dabei werden lediglich Eigenschaften und Funktionen gefordert, die eine Klasse haben soll, wobei die Implementierung je nach Klasse variiert. Konkret gibt es innerhalb des Foundation Frameworks das Protocol NSCopying. Wird dieses von einer Klasse implementiert, so muss es eine Funktion „copy“ zum Kopieren des Objekts besitzen. Die genaue Realisierung dieser Funktion bleibt hierbei jedoch der Klasse uberlassen. Listing 3 (S. 16) zeigt die Deklaration des NSCopying Protocol sowie dessen Implementierung in einer Beispielklasse.

Protokolle werden als Hilfsmittel zur Delegation genutzt. Dabei sind drei Parteien invol­viert: das Protokoll, das Delegate und der Delegator. Hierbei mochte der Delegator Arbeit, im Sinne der Verwirklichung von Funktionen, abgeben. Das Delegate kuömmert sich um dessen Verwirklichung und das Protokoll bietet die vertragliche Grundlage. Abbildung 4 (S. 16) stellt die Aufgaben der einzelnen Parteien dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Visualisierung des Delegate Design Pattern

Abbildung in dieser Leseprobe nicht enthalten

Listing 3: Definition und Implementierung des NSCopying Protokolls

2.4.4 Reaktive Programmierung

Das Konzept der reaktiven Programmierung ist nicht neu, aber seine Kernkonzepte haben in den letzten zehn Jahren ein spürbares Comeback erlebt. In diesem Zeitraum haben sich Web-Anwendungen und mobile Applikationen immer weiter verbreitet. Die Verwaltung komplexer asynchroner Benutzeroberflachen und die Vielzahl an Sensorik in Smartphones haben sie zu einer Notwendigkeit gemacht, während auf Serverseite reaktive Programmie­rungskonzepte schon länger verbreitet sind.

Im Jahr 2009 wurde ein Team von Microsoft damit beauftragt, ein neues client- und serverseitiges Framework zu entwickeln. Es wurde bekannt unter dem Namen „Reactive Extension fär .NET (Rx)“. Es handelte sich um ein installierbares Add-On fär .NET 3.5 und wurde spater eine integrierte Kernbibliothek fur .NET 4.0. Seit 2012 ist der Quelltext äffentlich und kann von Dritten eingesehen, geandert und genutzt werden. Dies hat dazu gefährt, dass Rx auch auf anderen Plattformen implementiert wurde und zu einem Cross­Plattform-Standard geworden ist. Diese sind unter den Namen RxJS, RxKotlin, Rx.NET, RxScala und RxSwift bekannt. Alle Bibliotheken sind bestrebt, das gleiche Verhalten des urspriinglichen Frameworks zu implementieren (vgl. [FP17]). Sie sind zentral uber http://reactivex.io mit einer ausfuhrlichen Dokumentation verfìigbar.

Die Basis von Rx ist die Generierung von Eventsequenzen. Diese können erzeugt, kom­biniert und beobachtet werden. Daneben enthalt es Ansätze der funktionalen Program­mierung, um Probleme deklarativ zu läsen. Hierdurch wird Code-Isolation, Wiederver­wendbarkeit und lose Kopplung erreicht. Weiterhin kann Nebenlaufigkeit über Scheduler verwaltet werden.

Rx vereinfacht in seiner Essenz die Entwicklung von asynchronen Programmen, indem es ihrem Code erlaubt, auf neue Daten zu reagieren und sie in sequentieller, isolierter Weise zu verarbeiten. Es basiert auf den drei Konzepten Observables, Operators und Scheduler.

Observables

Observable<T> ist eine der Hauptklassen und das Fundament von Rx. Mit ihr kännen Sequenzen on Events kreiert werden, die dann eine Momentaufnahme von Daten T trans­portieren. Ein oder mehrere Observer (Beobachter) konnen diesen Eventstrom anschlie­ßend abonnieren und entsprechend auf die ankommenden Daten reagieren. Um dies auch in eigenen Klassen implementieren zu konnen, gibt es das Protokoll ObservableType. Ein Observable kann drei Arten von Events aussenden: „next“, „completed“ oder „error“.

Ein next Event enthält die aktuellste bzw. das entsprechend nächste Event mit seinem Datenelement. Auf diese Weise koännen Beobachter Daten empfangen.

Das completed Event beendet eine Eventsequenz mit Erfolg. Danach können keine wei­teren Events ausgesendet werden.

Das error Event beendet eine Eventsequenz mit einem Fehler. Danach können ebenfalls keine weiteren Events ausgesendet werden.

Diese drei Events sind die Grundlage für Rx. Events können beispielsweise durch das User Interface, Sensorik oder ankommende Netzwerkverbindungen ausgelüst werden. Hierdurch wird lose Kopplung erreicht. Andere Möglichkeiten der Klassenkommunikation wie bei­spielsweise Delegation werden obsolet.

Abbildung in dieser Leseprobe nicht enthalten

Listing 4: Observable bei Uberpriifung der Gültigkeit eines Tableau Servers

Listing 4 zeigt die Verwendung eines Observables bei der Uberprufung, ob es sich bei einem angegebenen Server um einen Tableau Server handelt. Der Aufruf der Metho­de asObservable() hat einen Ruckgabewert vom Typ Observable<Int>. Der Metho­de subscribe() konnen direkt Closures fur die entsprechenden Eventtypen ubergeben werden. Werden Methoden der aktuellen Klasse aufgerufen, so ist es notwendig, die Re­ferenz self als weak zu deklarieren, um einen Strong Reference Cycles zu verhindern. Innerhalb des onNext : Closures wird auf den HTTP Statuscode reagiert und der Nutzer wird, bei Erfolg, zum nöchsten ViewController geleitet. Bei einem Fehler wird er mit einer Fehlermeldung informiert.

Operators

Die zweite Saule von Rx sind Operatoren. Diese werden dazu verwendet, Daten mittels eines funktionalen Ansatzes zu modifizieren. Typische Operatoren sind map, flatMap, filter und reduce. Zusatzlich gibt es noch eine große Anzahl an abgewandelten und spezialisierten Varianten. Das Verhalten ist den in Swift integrierten Operatoren sehr ähnlich. Es lassen sich folglich Collection Types deklarativ bearbeiten.

Operators werden beispielsweisedazu genutzt, um Eventströme miteinander zu kombi­nieren oder zu filtern, bevor ein Beobachter diese abonniert.

Abbildung in dieser Leseprobe nicht enthalten

Listing 5: Operatoren zur Bearbeitung von Events der Gerateausrichtung

Listing 5 zeigt die Verwendung von Operatoren zur Bearbeitung von Events der Geräteaus­richtung. Diese kann entweder die Werte .landscape oder .portrait annehmen. Im ers­ten Schritt wird mit dem filter-Operator .landscape herausgefiltert, sodass nur noch .portrait ubrig bleibt. Anschließend transformiert der map-Operator das enum zu ei­nem String. Abschließend wird der produzierte Text uber . subscribe(onNext : {...}) mittels eines AlertControllers ausgegeben. Abbildungen 5 und 6 veranschaulichen diesen Sachverhalt (S. 18).

Scheduler

Scheduler dienen dazu, Events auf einen anderen Thread zu leiten. Sie erlauben dem Pro­grammierer, low-level Threading, Synchronisations- und Parallelitätsprobleme zu abstra­hieren. Scheduling in Rx ist eine fortgeschrittene Technik, die nur fur speziellen Anwen­dungen benätigt wird. In den meisten Fallen kann auf die vorhandenen Scheduler-Klassen des Frameworks zugegriffen werden. Da Scheduler fur die Verwirklichung des Projektes „Software Metrics“ nicht notwendig sind, wird auch nicht weiter darauf eingegangen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Eventsequenz eines Observable<Orientation>

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Operatoren zur Bearbeitung von Events der Gerateausrichtung

2.5 Eingesetzte Frameworks

Im Folgenden werden verwendete Frameworks kurz vorgestellt. Dies sind zum einen die von Apple angebotenen Frameworks WebKit und JavaScriptCore sowie Open-Source- Frameworks wie RxSwift.

2.5.1 WebKit

WebKit ist ein Framework von Apple, das zum Anzeigen von Webinhalten dient und für iOS und MacOS verfügbar ist. Es fungiert zur Implementierung von Browserfunktionen in eigenen Applikationen. Die Inhalte künnen entweder direkt uber eine URL oder uber lokal gespeicherte HTML-Seiten geladen werden.

WebKit bietet eine Reihe von Klassen und Delegates, um Webinhalte in Fenstern anzuzei­gen. Weiterhin ermüglicht es den Zugriff auf Metadaten sowie das Empfangen von Events, um beispielsweise beim vollstündigen Laden einer Seite gewisse Aktionen durchfuhren zu künnen. Es ist außerdem müglich, Links zu folgen bzw. auf die Historie im Verlauf der geöffneten Seiten zuzugreifen (vgl. [Ince]).

2.5.2 JavaScriptCore

Das JavaScriptCore-Framework bietet Zugriff auf die JavaScript-Engine von WebKit. Es ermüglicht eine leistungsstarke Zusammenarbeit zwischen Swift und JavaScript-Code. Die drei Hauptklassen sind JSVirtualMachine, JSContext und JSValue.

JSVirtualMachine

JavaScript-Code wird in einer virtuellen Maschine ausgefuhrt, die durch die Klasse JS­VirtualMachine reprüsentiert wird. Da es in einer JSVirtualMachine nicht moglich ist, mehrere Threads gleichzeitig auszufuühren, koünnen mehrere Klassen erzeugt werden. Je­doch besitzt jede Instanz einen eigenen Heap und Garbage Collector, weshalb es nicht müglich ist, Objekte zwischen den virtuellen Maschinen auszutauschen.

JSContext

Ein JSContextObjekt stellt eine Ausfìihrungsumgebung für JavaScript-Code dar. Es ent­spricht einem einzigen globalen Objekt; sein Webentwicklungsaquivalent ist ein window Objekt. Im Gegensatz zu virtuellen Maschinen, konnen diese Objekte untereinander aus­tauschen, da sie sich in derselben virtuellen Maschine befinden.

[...]