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 Visualisierung 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 für Geräte mit kleinen Displays,
• Implementierung von Interaktionen mit Hilfe der Tableau JavaScript API.
Im theoretischen Teil werden die Grundlagen der eingesetzten Entwurfsmuster sowie Programmiersprachen vorgestellt und im Hinblick auf ihren jeweiligen Einsatzzweck erläutert. Anschließend wird detaillierter auf reaktive Programmierung und das dahinterliegende Konzept eingegangen. Den Abschluss des theoretischen Teils bildet dabei die Einführung in die Entwicklung von iOS Applikationen.
Der Hauptteil erläutert zuna ̈chst die Lösung der oben genannten Kernprobleme. Darauf 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 betrachtet und ein Ausblick auf Erweiterungsmöglichkeiten gegeben.
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 Visualisierung mit Hilfe der Anwendung Tableau aufbereitet und optisch ansprechend gestaltet.
Die hiermit erstellten Dashboards, die in Konzernen äblicherweise zum Reporting eingesetzt 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 Programmiersprachen 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. Darauf 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 betrachtet 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 eigener Anfertigung
Abb. 10 Klassendiagramm;Software Metrics“ - schematische Darstellung, Screenshot 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 Anfertigung
Abb. 15 Filterauswahl, Screenshot aus eigener Anfertigung
Abb. 16 Anmeldeprozess App Software Metrics“, Screenshot aus eigener Anfertigung
Abb. 17 Tableau Dashboard auf verschiedenen Endgeraäten, Screenshot aus eigener Anfertigung
Abb. 18 OverallQualityViewController in Explosionsdarstellung, Screenshot aus eigener Anfertigung
Abb. 19 Main.Storyboard „Software Metrics“ innerhalb Interface Builder, Screenshot Integrated Development Environment (IDE) Xcode aus eigener Anfertigung
Abb. 20 Einbindung UIWebView mittles Interface Builder, Screenshot aus eigener 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 Funktion, sondern sind lediglich Qualitatsmerkmale über Wartbarkeit, Erweiterbarkeit oder Verständlichkeit der Software.
Grundlage fur die Arbeit bildet eine Anwendung, die aus dem Quelltext von Softwareprojekten, Metriken in Bezug auf Qualitatsmerkmale extrahiert. Diese kann auf verschiedene 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 Webseiten ä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 Worksheets 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 Softwareprojekten, die sich näher untersuchen lassen. Im oberen Teil sind Pakete bzw. Komponenten 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äutert 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 Komponente, Informationen in tabellarischer Form angezeigt. Beispielsweise die Anzahl der Dateien, Lines of Code (LOC), Kommentarzeilen und das Verhaltnis von Kommentarzeilen zu Codezeilen.
Die obere Leiste unterhalb des Dashboardtitels wird dazu genutzt, Informationen zu selektieren 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 Auswahlmöglichkeiten sind hierbei: Code, Design oder beides gleichzeitig. Die Box Metrikgruppe ermöglicht die Auswahl spezieller Gruppierungen von Metriken. Mögliche Werte sind: C and C++, Designmetriken, HIS-Metriken, Java, NONE und weitere Metriken. Elemente 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 Speziellen sind dies die APIs „Tableau REST API“, „Tableau JavaScript API“ und „Tableau Vizportal API“. Diese Schnittstellen konnen dazu genutzt werden, Ressourcen programmatisch 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öffentlicht. Der Nutzer muss sich hierauf anmelden konnen, um Zugriff auf die gewunschten Visualisierungen zu erhalten. Die Verschlösselung von sensiblen Daten erfolgt unter Verwendung des RSA Verfahrens.
Die ursprönglich veröffentlichten Dashboards „Gesamtqualitöt“, „Qualitatsanalyse“ und „Release und Benchmarks“ sind nicht fur eine mobile Darstellung optimiert. Die eingebetteten 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 JavaScript 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 Umsetzung 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 Softwaremetriken 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 „cohesion“ 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 Methoden.
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 Automobilhersteller Audi, BMW Group, Daimler, Porsche und Volkswagen. Das Ziel dieser Vereinigung ist die Herstellung von einheitlichen Standards in den Bereichen Standardsoftwaremodulen fur Netzwerke, Prozessreifegradermittlung, Softwaretests, Softwaretools und dem Programmieren von Steuergeraten (vgl. [Kud]). Im Zuge dessen wurden standardisierte 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 aufgerufen 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 Anweisungen. 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 dahinter 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 Zusammenhangskomponenten des Graphen entspricht. Nach der deutschsprachigen Anwendergruppe fur Software-Metrik und Aufwandschatzung e.V. wird diese Metrik oft als Indikator 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 Unterfunktionen. (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 entsprechen: 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 Datenbanken. 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 „Arbeitsblatt“.
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, Legenden und den Datenbereich. Aus diesen Worksheets künnen dann wiederum Dashboards erstellt werden, die eine Sammlung von Ansichten darstellen. Eine Story enthült eine Sequenz 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 Dashboard 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 Datenquellen, Projekten, Arbeitsmappen, Benutzern und Standorten auf einem Tableau-Server. Sie kann dazu benutzt werden, eigene benutzerdefinierte Anwendungen zu erstellen oder Interaktionen 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 Tableau Server ermöglicht, sich auf dem Server anzumelden und Daten abzurufen. Viele Funktionen wie beispielsweise eine Authentifizierung sind uber die offizielle Tableau JavaScript 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 Programmiersprachen zu verwirklichen, da diese insbesondere zur Steuerung der Benutzeroberflüchen nur für JavaScript verfügbar sind. Das mobile Betriebssystem iOS unterstützt mit dem Framework JavaScriptCore die Zusammenarbeit von JavaScript- mit SwiftQuelltext. 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 Entwicklerkonferenz 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 objektorientierten 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 initialisieren. Solche Probleme werden bei Swift durch die Einfuhrung von „optionals“ gelüst.
Jene werden bei der Variablendefinition durch ein nachgestelltes „?“ hinter dem Variablentyp 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 „Optional 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 Datentyps 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 bieten 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, allgemeine Softwareentwicklungsprobleme zu losen. Apple verfolgt dabei ein Konzept, das auf drei Hauptentwurfsmustern basiert. Dies sind Model View Controller (MVC), TargetAction und Delegation. Grundsätzlich gibt es auch ähnliche Ansätze in anderen Programmiersprachen. 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 Beobachtermusters 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 Programmierung, 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 Logik 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 Objekt dargestellt. Bei der Speicherung von Daten einer Anwendung ist es wichtig, dass sich diese an einer zentralen Stelle befinden. Wahrend der Initialisierung einer Anwendung 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 direkten 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 Frameworks 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 dienen 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 Benutzereingaben, 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 initiierte Events oder Benutzerinteraktionen sein. So losen Interaktionen des Benutzers mit den Schnittstellen des Geraöts, beispielsweise des Touch Screens, Events innerhalb der Anwendung 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 anderen 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 involviert: 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 Programmierungskonzepte 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 CrossPlattform-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, kombiniert und beobachtet werden. Daneben enthalt es Ansätze der funktionalen Programmierung, um Probleme deklarativ zu läsen. Hierdurch wird Code-Isolation, Wiederverwendbarkeit 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 transportieren. 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 weiteren 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 beispielsweise 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 Methode asObservable() hat einen Ruckgabewert vom Typ Observable<Int>. Der Methode subscribe() konnen direkt Closures fur die entsprechenden Eventtypen ubergeben werden. Werden Methoden der aktuellen Klasse aufgerufen, so ist es notwendig, die Referenz 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 kombinieren 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äteausrichtung. Diese kann entweder die Werte .landscape oder .portrait annehmen. Im ersten Schritt wird mit dem filter-Operator .landscape herausgefiltert, sodass nur noch .portrait ubrig bleibt. Anschließend transformiert der map-Operator das enum zu einem 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 Programmierer, low-level Threading, Synchronisations- und Parallelitätsprobleme zu abstrahieren. Scheduling in Rx ist eine fortgeschrittene Technik, die nur fur speziellen Anwendungen 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 anzuzeigen. 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 JSVirtualMachine reprüsentiert wird. Da es in einer JSVirtualMachine nicht moglich ist, mehrere Threads gleichzeitig auszufuühren, koünnen mehrere Klassen erzeugt werden. Jedoch 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 entspricht einem einzigen globalen Objekt; sein Webentwicklungsaquivalent ist ein window Objekt. Im Gegensatz zu virtuellen Maschinen, konnen diese Objekte untereinander austauschen, da sie sich in derselben virtuellen Maschine befinden.
[...]
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.