iOS-Praktikum Wintersemester 2015/2016

Ein Blick unter die Haube der App „in|Forming“

1. Dezember 2016Sacha Catelin und Olaf Schumacher

Nachdem wir in den ersten beiden Teilen der Blog-Reihe den Ablauf des Praktikums und die App in|Forming beschrieben haben, wollen wir im dritten Teil einen Blick unter die Haube der App werfen und dabei ihre Dimensionen aus verschiedenen Perspektiven betrachten. Ein Blick in die Zukunft folgt am Ende des Artikels.

Das Systemdesign

Das Smartphone ist derzeit der einzige Bestandteil des Systems. Es erlaubt den Zugriff auf verschiedene Datenquellen – wie GPS, Internetressourcen, Adressbücher, Fotos und Kalender – sowie  die Speicherung von Informationen im lokalen Datenspeicher. Die App kann auf unter Berücksichtigung drei verschiedener Aspekte aufgeteilt werden: die einzelnen Schichten, die einzeln funktionalen Module sowie die dynamischen Gesichtspunkte.

Schichtenarchitektur von in|Forming

Präsentations-Layer    

Der Präsentations-Layer folgt der Model-View-Controller-Architektur, die eine Trennung der Verantwortlichkeiten des Präsentations-Layers in Datenmodell (Model), Darstellung (View) und deren Steuerung (Controller) forciert.

Business-Layer

In diesem Layer wird die Logik der Anwendung implementiert.  Bei der App in|Forming liegt der Schwerpunkt in der Interpretation und Aufbereitung der gesammelten Daten.

Data-Access-Layer

Die Architektur des Datenmanagements unserer App besteht aus mehreren Schichten:

  • Die unterste Schicht ist die Datenbank. Diese wird vom Core Data Framework verwaltet, welches das Mapping der Entitäten innerhalb des Entity-Relationship-Models der Datenbank auf die Modellklassen unserer Anwendung abbildet.
  • Die Datenzugriffsschicht ist die folgende Schicht und besteht aus dem DatabaseContext und DALContext. Hier definieren wir die CRUD-Operationen (Create, Read, Update, Delete) für die Speicherung der einzelnen Modellklassen. Zudem wird hier von den realen Umsetzungen und Dialekten des Datenzugriffs auf allgemeine Zugriffsmethoden abstrahiert, damit es einfacher ist, die zugrundeliegenden Komponenten – wie die Datenbank – gegen andere Implementierungen auszutauschen.

Ein Beispiel: MongoDB verwendet die Methode find(), EntityFramework verwendet get() und Coredata hingegen fetch(), um einen Datensatz aus dem Datenspeicher zu lesen.
Durch die Implementierung von CRUD-Methoden findet eine Entkopplung von der verwendeten Datenbank und dem eingesetzten Framework statt.

Modell 

Das Objekt-Modell findet schichtübergreifend Verwendung. Im Mittelpunkt des Modells steht der Benutzer:

  • Album: Der Benutzer kann mehrere Alben haben, die jeweils aus mehreren Fotos bestehen.
  • Contact: Er kann ein oder mehrere Kontakte haben, welche jeweils mehrere Telefonnummern oder Adressen haben können. Einem Kontakt kann auch ein Foto zugeordnet sein.
  • Calendar: Darüber hinaus kann der Benutzer verschiedene Kalender haben, in denen Ereignisse gespeichert und Erinnerungen hinterlegt sind, die kategorisiert werden können. Sie können zudem mit Aktivitäten verbunden sein, welche durch Text Mining bestimmt werden.
  • Location: Für den Benutzer kann es einen oder mehrere Aufenthaltsorte geben, die auf verschiedene Arten ermittelt werden können:
    • GPS-Koordinaten von Fotos
    • Kalendereinträge und Kontakte, bei denen eine Adresse hinterlegt ist
  • Activity: Kalendereinträgen oder bestimmten Orten können außerdem Aktivitäten zugeordnet werden. Teilweise ist es sogar möglich, auf Basis des besuchten Ortes auf die Aktivität zu schließen.

Subsysteme und Module

Man kann die Systemarchitektur außerdem aus der funktionalen Sicht betrachten. Hierbei wird die Anwendung nach funktionalen Aspekten aufgeteilt.

UserDataManagement

Innerhalb des UserDataManagement gibt es die Manager-Komponenten LocationManager, PhotosManager, EventManager und ContactsManager. Die Aufgabe dieser Manager ist das Auslesen der zugeordneten Komponenten über deren Schnittstellen. Zwischen den Komponenten erfolgt der Datenaustausch über den DataInterpreter und es gibt verschiedene Abhängigkeiten zwischen diesen Komponenten – z.B. bietet der Eventmanager Informationen über Kontakte, weil diese an einer Veranstaltung teilnehmen können und der PhotosManager liest GPS-Daten von einem Foto. Diese Abhängigkeiten müssen von der DataInterpreter-Komponente verwaltet werden.

UserDataModeling

Das Subsystem UserDataModeling ist dafür zuständig die Daten, die über das Subsystem UserDataManagement abgerufen wurden, zu verarbeiten und in eigenen Datenstrukturen abzulegen. Die hierfür verwendeten Module DataAccess und DataStorage stellen die Daten später auch wieder zur Verfügung.

UserInterface

Die Controller-Komponente liest die Daten über die Komponente Data Access. Die gelesenen Daten werden dann dem Benutzer angezeigt und über die Komponente View interagiert dieser dann mit der App. Die Verarbeitung der Eingaben findet in der Controller-Komponente statt.

Dynamische Sicht

in|Forming kann auch unter dynamischen Gesichtspunkten betrachtet werden. Das Sammeln der Daten aus den verschiedenen Datenquellen ist ein wiederkehrender Prozess, der mittels eines CronJobs abgearbeitet wird. Dieser Job wird bei der ersten Ausführung von in|Forming gestartet und läuft dann alle 24 Stunden. Seine Hauptaufgabe ist es, den Datenspeicher synchron zu den verfügbaren Daten des Smartphones zu halten.
Der CronJob führt die folgenden Aktivitäten aus:

  • Lesen und Speichern aller neuen Events, Erinnerungen und Kontakte
  • Ermittlung der Aufenthaltsorte und Adressen, die keinem Ort zugeordnet sind und entsprechendes Mapping
  • Lesen aller Events, Erinnerungen und Aufenthalte, die keiner Aktivität zugeordnet sind und entsprechendes Mapping
  • Lesen und Speichern aller Fotos und Alben
  • Information an alle registrierten Listener, dass der CronJob beendet ist

Mögliche Ausbaustufen

Am Ende wollen wir noch einen kurzen Blick auf mögliche Erweiterungen der App werfen.

Datenaustausch über Server oder Peer-2-Peer 

Eine mögliche Ausbaustufe ist der Datenaustausch von Gerät zu Gerät. Es könnten Daten von Personen übertragen werden, die in der Nähe sind. Bei der Peer-2-Peer-Kommunikation müsste der Benutzer allerdings hierfür eine Freigabe geben, diese würde hingegen bei der server-basierten Variante entfallen.

Nächste Schritte 

  • Integration neuer Datenquellen, wie z.B. Health Kit.
  • Nutzung eines Web-Scraper, durch den Informationen über den Benutzer aus seinem Surf-Verhalten gewonnen werden können – auch ohne zusätzliche Berechtigungen.
  • Nutzung der Gesichtserkennung, um zu identifizieren, mit wem der Benutzer zusammen war.
  • Treffen von Vorhersagen – auf Basis der gesammelten Daten könnte man nicht nur Rückschlüsse auf vergangene Aktivitäten des Benutzers ziehen, sondern auch Aussagen über die Zukunft treffen oder Empfehlungen ableiten.

Datensicherheit

Da das Thema Datensicherheit ein Thema ist, das immer mehr an Bedeutung gewinnt, wollen wir in|Forming verwenden, um auch junge Menschen für das Thema zu sensibilisieren. Sie stellen eine wichtige Zielgruppe dar, da durch den selbstverständlichen Umgang mit dem Smartphone die mit mangelnder Datensicherheit verbundenen Bedrohungsszenarien nicht direkt erkannt werden.

Dieser Artikel stellt den Abschluss unserer dreiteiligen Blog-Reihe dar. Wenn ihr Fragen zum iOS-Praktikum habt, dann schreibt uns gerne. Wir freuen uns auf eure Kommentare.

Sacha Catelin und Olaf Schumacher Sacha Catelin und Olaf Schumacher sind beide als IT-Consultants bei adesso in München tätig. Sacha ist in den Bereichen Projektmanagement, Requirements Engineering und Testmanagement bei Rückversicherungen im Einsatz, die Schwerpunkte sind Risikoprüfungs- und CRM-Systeme. Olaf entwickelt bei seinem Kunden Multikanal-Softwarelösungen für den Vertrieb von Privat- und Sachversicherungen.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: