Gastbeitrag von xdi360 und Projektteampräsentationen zum Themenbereich "ConnectedCar und Carsharing" WASA-Vorlesung am 04.07.2018 09:45 – 10:15 Uhr Gastbeitrag xdi360 Heiko Klarl 10:15 – 11:00 Uhr Eine Microservice-Architektur zur Bereitstellung innovativer Mobilitätsdienste in der ConnectedCar-Domäne MA Irrgang, BA Eisele Pr Lehr, Pr Modrzejewski, Pr Senthilrajah, Se Kostka 11:00 – 11:15 Uhr Vorstellung und Diskussion des Posters für den Markt der Ideen WASA - Gastbeitrag und Projektteampräsentationen

MA Irrgang: Inhaltsübersicht EINFÜHRUNG UND MOTIVATION ZIELE SYSTEMATISCHER ENTWICKLUNGSPROZESS Modellierung mit UML, Identifizierung der Domänenobjekte (1) Im ersten Teil werden die Domänen ConnectedCar bzw. Carsharing vorgestellt und die Masterarbeit wird motiviert. (2) (3) Nach der Motivation werden die Ziele der Arbeit erläutert, um anschließend auf den systematischen Entwicklungsprozess mit der Identifizierung der Domänenobjekte aus den Features und die strukturierte Modellierung der Domäne mittels UML einzugehen. UML Unified Modeling Language WASA - Gastbeitrag und Projektteampräsentationen

EINFÜHRUNG UND MOTIVATION ConnectedCar ist eine sehr junge Domäne Essenzielle Bestandteile noch nicht bekannt Gemeinsames Verständnis nicht gegeben Querschnitt aus vielen Fachbereichen Äußerst umfangreiche Domäne Vielschichtige Problemstellungen Kernkomponenten schwierig zu identifizieren Beispielhafte Betrachtung anhand der Carsharing-Domäne Kunden können Fahrzeuge suchen, reservieren und mieten Fahrzeuge sind in einem Fahrzeugkatalog gespeichert Kunden können Einstellungen wie die Sitzposition fahrzeugübergreifend speichern (1) Die ConnectedCar-Domäne ist noch relativ jung und befindet sich in starkem Wandel. Ständig kommen neue Technologien und Dienste hinzu und bestehende müssen angepasst werden. (1.1) Somit müssen sich die essenziellen Bestandteile der Domäne erst noch herauskristallisieren. Grundsätzlich ist da an die Kommunikation zwischen den Fahrzeugen und die Datenverarbeitung, aber auch die Anwendungsplattformen mit vielfältigen Dienstleistungen und das autonome Fahren zu denken. (1.2) Ein erster wichtiger Schritt ist also das Aufbauen eines gemeinsamen Verständnisses der Domäne für alle Beteiligten aus verschiedenen Fachbereichen. (2) Während der Analyse der ConnectedCar-Domäne hat sich herausgestellt, dass diese einen Querschnitt aus vielen verschiedenen Problemstellungen und Fachbereichen darstellt. Somit sind zusätzlich unterschiedlichste Firmen beteiligt, was die Kommunikation und Findung eines gemeinsamen Nenners weiter verkompliziert. (2.1) Um den Umfang der Domäne zu verdeutlichen müssen nur einige Problemstellungen, mit der gewaltigen Anzahl an Fahrzeugen im Hinterkopf, genannt werden: Kommunikation über Mobilfunknetze, Datenanalyse und Echtzeitmeldungen, Datenschutzkonformität, Sensordatenverarbeitung, offene Plattform für Dienste von Drittanbietern. (2.2) Diese Vielfältigkeit macht es sehr schwierig die Kernkomponenten der Domäne zu identifizieren, weshalb vorerst nur ein Teil der Domäne betrachtet wird. (3) Aus diesen Gründen wird in der Arbeit und dementsprechend auch im Projektteam der Fokus auf das Carsharing gesetzt. Zusammen mit xdi360 sollen im Rahmen des Projektteams zusätzlich einige Fragestellungen bezüglich Carsharing geklärt werden, wobei xdi360 Input zu den fachlichen Zusammenhängen liefert. WASA - Gastbeitrag und Projektteampräsentationen

ZIELE Grundverständnis für die Domäne Konsolidieren bestehender Vorarbeiten zur ConnectedCar-Domäne Carsharing aus dem WS 17/18 HazardWarning aus dem SS 17 Einordnung des Carsharings in das “große Ganze” Systematischer Entwicklungsprozess bis hin zum Microservice Behavior-driven Development (BDD) zur Analyse und zur Ableitung der Domäne DDD zum Entwurf und zur Aufteilung der Dienste Systematisches Ableiten der benötigten Schnittstellen Resultat: Allgemeingültige, wiederverwendbare Dienste (1) Ein wichtiges Ziel ist es ein allgemeines Verständnis für den Aufbau der ConnectedCar-Domäne durch das Analysieren der Carsharing-Domäne zu erhalten. (2) Die Vorarbeiten lassen sich im Wesentlichen in die beiden Teile Carsharing und HazardWarning unterteilen, welche bereits in vorherigen Semestern untersucht und prototypisch implementiert wurden. (2.1) Carsharing ist die bei C&M jüngere Domäne und wurde im letzten Semester durch die Masterarbeit [Ur18] angegangen. Darin wurden mehrere Entwürfe zur ConnectedCar-Domäne und eine prototypische Implementierung einer Carsharing-Anwendung durchgeführt. Diese wurde zur Simulation von Kunden und Fahrzeugverteilungen und zur Analyse von Datenschutzaspekten bereits während der Analyse- und Entwurfsphase genutzt. (2.2) HazardWarning ist ein Dienst der sich stark auf die Eventverarbeitung konzentriert. Dabei werden die Sensoren in den Fahrzeugen in Echtzeit ausgelesen und vorverarbeitet. Anschließend werden die so erzeugten Events wie beispielsweise blockierende Reifen beim Bremsen an einen Server weitergegeben, der dann basierend auf den Daten der Fahrzeuge zum Beispiel eine Glatteiswarnung für das Gebiet aussprechen kann. (4) Eines der Hauptziele der Arbeit ist die Gestaltung eines systematischen Entwicklungsprozesses der von der Analyse über den Entwurf und die Implementierung bis hin zum Microservice reicht. Dieser soll anhand der Carsharing-Anwendung erprobt werden, jedoch grundsätzlich unabhängig von der Domäne sein. Eine Ausnahme hierzu bilden reine Querschnittsdomänen wie beispielsweise das Identity and Access Management, welches dahingehend in [Hü18] betrachtet wird. (4.1) Die Nutzung von Features aus BDD als Analyseartefakt bietet zum einen eine Übersicht über die bereitzustellenden Funktionalitäten und zum anderen ein Werkzeug um deren Umsetzung in der Implementierung zu überprüfen. So kann aus den Features ein erster Entwurf der Context Map als Diskussionsgrundlage erstellt werden. (4.2) Die Modellierung des DDD wird von Evans bewusst nicht genauer spezifiziert, damit jedes Entwicklungsteam den Prozess auf die eigenen Bedürfnisse anpassen kann. Genau das wird in dieser Masterarbeit für die Domänenmodellierung mit UML und dem Enterprise Architect bei C&M durchgeführt. (4.3) Der in [Gi18] entwickelte Prozess zum systematischen Ableiten der Schnittstellen aus dem Domänenmodell soll an diesem Beispiel erprobt und auf seine Tauglichkeit untersucht werden. (5) Das Ziel ist es zu einer Microservicearchitektur zu gelangen, welche grundlegende Dienste bereitstellt, die von vielen Dienstleistern in Anspruch genommen werden können, ohne eigene ähnliche Dienste entwickeln zu müssen. BDD Behavior-Driven Development [Gi18] Pascal Giessler: Domänengetriebener Entwurf von ressourcenorientierten Microservices, 2018. https://team.kit.edu/sites/cm-tm/Mitglieder/3-1.Research/PA_Giessler [Hü18] Tobias Hülsken: Eine Microservice-Architektur für das Identitäts- und Zugriffsmanagement, 2018. https://team.kit.edu/sites/cm-tm/Mitglieder/3-1.Research/MA_Hülsken [Ur18] Christof Urbaczek: Anwendung und Bewertung von Konzepten des Datenschutzes in der Domänenmodellierung am Beispiel der ConnectedCar-Domäne, 2018. https://team.kit.edu/sites/cm-tm/Mitglieder/3-1.Research/MA_Urbaczek WASA - Gastbeitrag und Projektteampräsentationen

SYSTEMATISCHER ENTWICKLUNGSPROZESS – Modellierung der Domäne mit UML Konsistentes Nutzen des Enterprise Architect Erstellen von UML-Profilen Leichtgewichtige Modellierungsart Einfach einzubinden und zu erweitern Strategische Modellierung mit der Context Map Taktische Modellierung mit der Relation und Orchestration View Anforderungsanalyse ergab folgende Kernbestandteile Verwalten von Fahrzeugen durch den Provider Suchen, Reservieren und Mieten von Fahrzeugen durch Kunden Verwalten von Kunden mitsamt ihren Fahrzeugeinstellungen Analyse vergangener Buchungen zur Optimierung des Dienstes Kommunikation mit den Fahrzeugen (1) Um so etwas komplexes wie eine Domäne konsistent abzubilden reicht es nicht Werkzeuge für Diagramme wie PowerPoint oder Visio zu verwenden. Stattdessen sollte ein professionelles Modellierungswerkzeug wie der Enterprise Architect eingesetzt werden. Um dieses Werkzeug jedoch produktiv nutzen zu können, sind wesentlich mehr Einarbeitung und einige Richtlinien notwendig, die u.A. in dieser Arbeit aufgestellt wurden. (2) Ein zentraler Bestandteil dieser Richtlinien war die Erstellung von UML-Profilen zur Modellierung der verschiedenen Diagramm- bzw. Modelltypen. Für jedes Diagramm können so die notwendigen Elemente und Beziehungen bereitgestellt werden, welche für die Modellierung benötigt werden. (2.1) Es wurde sich bewusst für die leichtgewichtige Modellierung mit UML-Profilen entschieden und auf eine Anpassung oder Erweiterung des UML-Metamodells, die sogenannte schwergewichtiger Modellierung, verzichtet. (2.2) Einer der Gründe ist, dass die leichtgewichtige Modellierung deutlich einfacher umzusetzen und flexibler einzusetzen ist und zudem weniger Kenntnisse in der Metamodellierung und der UML-Spezifikation benötigt. So kann sichergestellt werden, dass jeder Studierende einen vergleichsweise einfachen Einstieg in die Domänenmodellierung mit UML hat. (3) (4) Bei der Domänenmodellierung unterscheidet man zwischen der strategischen und der taktischen Modellierung. Die strategische Modellierung beschäftigt sich mit der Strukturierung der Bounded Contexts und somit auch der Entwicklerteams, während die taktische Modellierung auf die Funktionalitäten der einzelnen Bounded Contexts eingeht. (5) Die Folgenden Kernfunktionalitäten haben sich durch die Anforderungsanalyse der bestehenden Artefakte und der vorgegebenen Geschäftsziele herausgebildet. Diese gilt es nun in passende Bounded Contexts einzuteilen, welche überschneidungsfrei genau diese Probleme lösen. WASA - Gastbeitrag und Projektteampräsentationen

Context Map Auf dieser Folie ist die vorläufige Context Map zur Carsharing-Domäne zu sehen. Der Hauptfokus liegt auf der Struktur der Context Map; weiterführende inhaltliche Informationen können der nachfolgenden Projektteampräsentation und [Ir18] entnommen werden. (bounded context) Ein Bounded Context enthält genau diejenigen Elemente, die für die Lösung eines bestimmten Problems der Domäne nötig sind. Dabei kann er mit anderen Bounded Contexts kommunizieren, um seine Aufgaben bewältigen zu können. (anti-corruption layer) Eine Antikorruptionsschicht steht in der Regel zwischen einem eigenentwickelten und einem fremden System. Seine Aufgabe ist es die Anbindung des Fremdsystems so robust wie möglich zu gestalten ohne die Qualität des eigenen Domänenmodells durch die fremde Schnittstelle zu beeinflussen. (foreign bounded context) Ein fremder Bounded Context ist ein System, das nicht im Rahmen der Domäne implementiert wird und somit auch keinen Zugriff auf das Domänenmodell erlaubt. Man erhält nur eine, im besten Fall wohldefinierte, Schnittstelle zu dem System. (partnership) Die Partnerschaftsbeziehung sagt aus, dass zwei Bounded Contexts nicht ohneeinander ihre Funktionalitäten bereitstellen können und deshalb gemeinsam entwickelt werden müssen. (customer/supplier) Bei einer Kunden-/Lieferantenbeziehung bietet ein Bounded Context eine Funktionalität als Lieferant an und ein anderer Bounded Context kann diese Funktionalität als Kunde verwenden und zusätzlich bei der Entwicklung mitbestimmen. (conformist) Die Konformistenbeziehung sagt aus, dass der Bounded Context zu dem die Beziehung zeigt bedingungslos die Schnittstelle des anderen Bounded Context akzeptieren und verwenden muss. (Nested-Beziehung) Die Nested-Beziehung (zwischen VehicleInteraction und ManufacturerACL) sagt lediglich aus, dass die Antikorruptionsschicht in dem Bounded Context enthalten ist und nicht als separater Dienst läuft. [Ir18] Chris Irrgang: Eine Microservice-Architektur zur Bereitstellung innovativer Mobilitätsdienste in der ConnectedCar-Domäne, 2018. https://team.kit.edu/sites/cm-tm/Mitglieder/3-1.Research/MA_Irrgang WASA - Gastbeitrag und Projektteampräsentationen

Identifizierung der Domänenobjekte Fachliche Substantive in den Szenarien des Features markieren Feature-Ausschnitte für das CustomerManagement: Scenario: Register with the car sharing service When I want to register with the service And I provide my name, address and billing information And I accept the privacy policy Then I am registered with the service And I can use the service Scenario: Use cloud service providers cross-vehicle Given I am registered with a cloud service provider When I want to use this service in a vehicle Then I add a corresponding cloud service account with a name And provide the appropriate access token Scenario: Automatically adjust seats for identical models Given I rented a vehicle with electric seat adjustment And I customized the seat position When I enter the next vehicle with the same model Then the seat position is automatically adjusted (1) Möchte man Hinweise auf Inhalte der Domäne aus einem Feature extrahieren, muss man bereits bei der Erstellung darauf achten, dass man konsistente Begrifflichkeiten verwendet. Zudem sollten die Features möglichst nicht aus Sicht eines Nutzers auf das Frontend formuliert werden, sondern rein fachlich gestaltet sein. (Register with the car sharing service) Aus diesem Szenario kann abgeleitet werden, dass der Kunde einen Namen, eine Adresse und Zahlungsinformationen benötigt. Wie diese aussehen ist hier nicht genauer spezifiziert, weshalb bei der Adresse auf Name, Postleitzahl, Stadt und Straße zurückgegriffen wird, während bei den Zahlungsinformationen Eigentümer, IBAN und BIC verwendet wird. Diese Definition legt nahe, diese Elemente als Value Objects zu implementieren. Die genauen Spezifikationen müssten in einem späteren Schritt mit dem Auftraggeber besprochen werden. Weiterhin muss der Kunde die Datenschutzbedingungen akzeptieren, um den Dienst ohne Einschränkungen nutzen zu können. (Use cloud service providers cross-vehicle) In diesem Szenario werden Cloud Service Provider und Cloud Service Accounts eingeführt. Bei den Providern handelt es sich um entsprechende Onlinedienste wie bspw. Spotify, während die Accounts die Verknüpfung zu unserem Dienst darstellen. Diese gehören laut Szenario zu einem Provider, können benannt werden und besitzen ein Access Token. Es ist davon auszugehen, dass der Kunde beliebig viele Accounts verknüpfen kann. Die Provider können nun entweder als Enumeration hartkodiert oder als Entität implementiert werden. (Automatically adjust seats for identical models) Dieses Szenario sagt aus, dass ein Kunde pro Fahrzeugmodell (sofern dies elektrisch verstellbare Sitze besitzt) eine Sitzkonfiguration speichern kann, um diese auf allen Fahrzeugen desselben Modells wiederverwenden zu können. Hierzu muss eine neue Entität erstellt werden, die die Sitzposition enthält und dem Fahrzeugmodell zugeordnet ist. Hierbei sei die genaue Speicherung der Sitzposition außen vor gelassen (bspw. als Binärdaten). WASA - Gastbeitrag und Projektteampräsentationen

CustomerManagement (Relation View) «shared entity» Customer name: String address: Address billingInformation: BillingInformation privacyPolicyConsent: boolean acceptPrivacyPolicy(): void revokePrivacyPolicy(): void «entity» SeatPosition headrest: int height: int angle: int position: int CloudServiceAccount accessToken: String provider: CloudServiceProvider «value object» Address postcode: String street: String city: String BillingInformation iban: String bic: String owner: String VehicleModel classification: Classification equipmentLine: String (from Domain Model:: VehicleCatalog) «enumeration» CloudServiceProvider SPOTIFY NETFLIX NETATMO SKYPE TUNEIN 0..* 1 belongs to Auf dieser Folie ist eine beispielhafte Relation View des Bounded Context CustomerManagement zu sehen. Die Relation View ist sehr stark an ein Klassendiagramm aus UML angelehnt. Jeder Bounded Context besitzt genau eine Relation View, welche die Fachlichkeit innerhalb dieser Domäne repräsentiert. Dabei werden Domänenobjekte, die nicht aus dem betrachteten Bounded Context stammen, wie oben mit Hilfe des Namespaces gekennzeichnet. Sollte dieses Domänenobjekt im betrachteten Bounded Context einen anderen Namen und auch andere Eigenschaften haben, wird es aus der importierten Shared Entity abgeleitet, was durch eine Abhängigkeitsbeziehung ausgehend von der neuen abgeleiteten Entität dargestellt wird. (SeatPosition) In diesem Beispiel wurde die Sitzposition in vier Kennzahlen umgewandelt. (VehicleModel) Diese Entität wird von der SeatPosition benötigt und ist deshalb aus dem Bounded Context VehicleCatalog importiert. (Customer) Der Kunde enthält die bereits besprochene Adresse, die Zahlungsinformation und den Namen. Zusätzlich bestand die Anforderung, dass der Kunde die Datenschutzbestimmung akzeptieren muss, aber auch wieder zurücknehmen kann. Hierfür gibt es die beiden Methoden acceptPrivacyPolicy und revokePrivacyPolicy. Sie unterscheiden sich insofern von Gettern und Settern, da hier zusätzlich datenschutzrechtliche Aspekte überprüft werden müssen und somit Domänenlogik enthalten ist. (Address) (BillingInformation) Diese beiden Wertobjekte enthalten genau die Attribute, die in der Szenarioanalyse festgestellt wurden. (CloudServiceAccount) Auch der CloudServiceAccount enthält die aus der Szenarioanalyse bekannten Attribute. (CloudServiceProvider) Hier wurde der CloudServiceProvider einfachheitshalber mit einer Enumeration umgesetzt, welche die unterstützten Provider enthält. WASA - Gastbeitrag und Projektteampräsentationen

CustomerManagement (Orchestration View) Auf dieser Folie ist die vorläufige Orchestration View des Bounded Context CustomerManagement zu sehen. Jeder Bounded Context besitzt genau eine Orchestration View, die symbolisiert, wie die Microservices miteinander kommunizieren. Es werden alle benötigten Entitäten mitsamt deren Herkunfts-Bounded Context und alle bereitgestellten Entitäten inklusive der verwendenden Bounded Contexts modelliert. (shares) Die Shares-Beziehung sagt aus, dass diese Entität aus dem Bounded Context für andere Bounded Contexts zur Verfügung steht und dementsprechend über eine beliebig geartete Schnittstelle bereitgestellt wird. (uses) Die Uses-Beziehung sagt aus, dass dieser Bounded Context die entsprechende geteilte Entität benötigt, um seine Aufgaben zu verrichten. (shared entity) Eine geteilte Entität ist eine Sonderform der normalen Entität, die signalisiert, dass diese Entität auch außerhalb des eigenen Bounded Contexts verwendet wird. Hier bietet es sich ggf. an, diese Entität von der Domänenlogik im eigenen Bounded Context zu entkoppeln. WASA - Gastbeitrag und Projektteampräsentationen

BA Eisele: Inhaltsübersicht Problemstellung Stand der Forschung Einführung Datenschutz WASA - Gastbeitrag und Projektteampräsentationen

Problemstellung Für die grundlegende Funktionalität benötigt ein Carsharing-Dienst nur wenige Informationen Wirtschaftlicher Erfolg stark abhängig von der Auslastungsquote und der Einbindung von Mehrwertdiensten Diese benötigen personenbezogene Daten Consent Manangement für Verwaltung dieser Daten Nicht mehr benötigte personenbezogene Daten haben Löschfristen Modellierung passiver Softwarefunktionalitäten erforderlich (1) Für die grundlegende Funktionalität benötigt ein Carsharing-Dienst mit Fahrzeugidentifikationsnummer, Mitbeginn und –End sowie Mietort und Rückgabeort nur sehr wenige Daten. (2) Beispiele für Mehrwertdienste sind die individuelle Einstellung der Fahrzeuge, Einbindung von Multimedia- sowie Streaminglösungen, etc. Die Einbindung von Mehrwertdiensten kann die Kundenzufriendenheit erhöhen in Kombination mit eines verbesserten Auslastungsquote ermöglicht dies eine deutlich höhere Gewinnmarge. Für jede Verarbeitung, Speicherung braucht der Betreiber eine Rechtsgrundlage in Form einer Zustimmung oder eines Vertrags. (2.1) Das sind das Tracking der vermieteten Fahrzeuge. Damit können Prognosemodelle abgeleitet werden, die die benötigten Fahrzeuge standortbezogen voraussagen. Ein Streamingdienst benötigt Zugriff auf das Kundenkonto. (2.2) Die in (2) genannten Dienste benötigen alle eine gesonderte Einwilligung aufgrund der Zweckkompatibilität. Es ist sinnvoll alles zentral zu verwalten, um die Betroffenenrechte garantieren zu können. (3) Seit Inkrafttreten der DSGVO gelten Löschfristen, die Unternehmen einhalten sollten, um keine hohen Strafen fürchten zu müssen. (3.1) Diese personenbezogenen Daten müssen automatisiert gelöscht werden, da eine aktive Verwaltung für eine große Anzahl an Nutzer einen großen Aufwand erzeugen würde. Deshalb müssen diese Softwarefunktionalitäten frühzeitig bei der Modellierung bedacht werden. DSGVO Datenschutzgrundverordnung WASA - Gastbeitrag und Projektteampräsentationen

Stand der Forschung bzgl. API-Beschreibung Hersteller verhalten sich sehr restriktiv Haben keine Connected-Car-Dienste Stellen REST-API nicht zur Verfügung Community „entschlüsselt“ API teils per Reverse Engineering namhafte Ausnahme ist Mercedes Hier soll ein aktueller Stand der Forschung bezüglich der Bereitstellungen von Connected-Car-APIs verschiedener Autohersteller gegeben werden: (1) Die Automobilbranche hat deutlich längere Entwicklungszyklen und ist mehr auf Sicherheit bedacht, deshalb benötigt die Einführung moderner Dienste einen deutlichen längeren Vorlauf. (1.1) Viele Hersteller haben noch keine Connected-Car-Dienste in ihre Modelle integriert und setzen noch immer auf eine Smartphonekopplung via Bluetooth oder Kabel. Ein Beispiel für einen namhaften Autohersteller ist Ford, (1.2) Nahezu alle anderen Autohersteller, die das Potential der Fahrzeugvernetzung erkannt haben und eigene Lösungen im Einsatz haben, stellen die REST-API für diese Dienste nicht zur Verfügung. Beispielhafte Lösungen hierfür sind das VW Car-Net, Audi Connect oder BWM Connected Drive. (3) Für andere Fahrzeuge mit eingebauten Connected-Car-Diensten muss natürlich trotzdem eine API für die herstellereigenen Systeme existieren. Findige Entwickler finden für bestimmte Fahrzeuge (wie z.B. Tesla allgemein, BMW i3) die Funktion der API der Öffentlichkeit zur Verfügung. Dadurch kann die Dokumentation als auch die Aktualität unzureichend sein. (2) Mercedes gibt Entwickler seit Beginn des Jahres unter https://developer.mercedes-benz.com/apis/connected_vehicle_experimental_api/demo Zugriff auf die API seiner Connected-Car-Lösung, wobei sich diese aktuell noch in einem experimentellen Zustand befindet. Rechts auf der Folie ist die REST-API dargestellt. REST-API Representational State Transfer-Application Programming Interface WASA - Gastbeitrag und Projektteampräsentationen

Domänemodell der Mercedes-API Die Folie zeigt das Domänemodell einer REST-API für Connected-Cars hier am Beispiel derer von Mercedes. WASA - Gastbeitrag und Projektteampräsentationen

Grundlegende Definitionen Datenschutz Als Grundrecht im Grundgesetz, Charta der Grundrechte der Europäischen Union festgehalten Datenschutz: Recht auf informationelle Selbstbestimmung Datensicherheit: technischer Schutz der Daten im Allgemeinen Personenbezogene Daten: Alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person […] beziehen Verbot mit Erlaubnisvorbehalt: Die Verarbeitung ist grundsätzlich verboten, außer die Einwilligung wird ausdrücklich erteilt Zweckkompatibilität: Datenverarbeitung darf nur zu einem Zweck, erfolgen, bzw. muss bei Änderung mit dem ursprünglichen Zweck vereinbar sein (1) Datenschutz ist als Recht auf informationelle Selbstbestimmung in Art. 2 Abs. 1 GG in Verbindung mit Art. 1 Abs. 1 GG indirekt festgehalten. In der Charta der Grundrechte der Europäischen Union ist in Artikel 8 der Schutz personenbezogener Daten festgehalten (2) Recht auf informationelle Selbstbestimmung bedeutet dass jeder Mensch grundsätzlich selbst entscheiden darf, welche seiner persönlichen Daten wem sowie wann zugänglich sein sollen. (3) Technischer und organisatorischer Schutz der Daten vor unbefugter oder unrechtmäßiger Verarbeitung, Verlust, Zerstörung. Also gerade dem Schutz im Allgemeinen unabhängig davon, ob diese einen Personenbezug aufweisen oder nicht. Dies stellen die IT-Sicherheitsziele Integrität und Vertraulichkeit. (4) Natürliche Person bedeutet es muss sich wirklich auf einen Mensch beziehen. Identifizierbar bedeutet wenn die Person mittels einer Zuordnung zu einer Kennung, Namen, Standortdaten, etc. eindeutig identifiziert werden kann. (5) Eine der zentralen Annahmen des Datenschutzrechts. Die Verarbeitung personenbezogener Daten ist grundsätzlich verboten, außer es trifft einer der folgenden Gründe zu (Art. 6 DSGVO): Einwilligung des Betroffenen, es liegt ein berechtigtes Interesse vor, ist erforderlich zur Erfüllung eines Vertrages, etc. (6) Früher Zweckbindung genannt. Die Datenverarbeitung darf nur zu einem Zweck, welcher der betroffenen Person mitgeteilt wurde erfolgen, bzw. bei einer Änderung muss der Zweck mit dem ursprünglichen vereinbar sein. GG Grundgesetz WASA - Gastbeitrag und Projektteampräsentationen

Projektteam: Inhaltsübersicht Vision und Geschäftsziele Technologien Analyse und Refactoring Backend Frontend Datenschutz Demo Ausblick und Erfahrungen (1) Es werden die Vision und die Geschäftsziele des Projekts vorgestellt (2) Danach werden die genutzten Technologien besprochen (3) Zuerst wird von Philipp die Analyse der bestehenden Architektur und das resultierende Refactoring vorgestellt (4) Danach wird von Sinthu das neue Domänenmodell und die neue Context Map des Backends vorgestellt (5) (6) Das Frontend und die neue Datenschutzverordnung werden erläutert (7) (8) Abschließend wird eine kurze Demo durchgeführt sowie Erfahrungen beschrieben WASA - Gastbeitrag und Projektteampräsentationen

Vision und Geschäftsziele Carsharing-Simulation Geschäftsziele Gemeinsames Verständnis der benötigten Informationen Einbindung von Mehrwertdiensten Optimale Auslastung der verfügbaren Fahrzeuge Einhaltung aktueller Datenschutzrichtlinien Fähigkeiten Abbildung des Prozesses zur Fahrzeug- und Servicebereitstellung Erfassung und Speicherung der Fahrzeug- und Kundendaten Simulation und Visualisierung einer Fahrzeugflotte Schnittstellen für Analysesoftware (1) Simulation mit deren Hilfe Industriepartner konzeptionelle Fragestellungen testen und Lösungsansätze evaluieren können. (2.1) Durch ein Domänenmodell und die Definition zentraler Features wird eine projektunabhängige Betrachtung der Problemdomäne ermöglicht. (2.2) Der Kunde wird in Zukunft immer mehr in den Fokus rücken. Mehrwertdienste bezeichnen Services, welche über die Fahrzeugbereitstellung hinausgehen und die Fahrzeugerfahrung individueller machen sollen(z.B. Multimedia-Angebote, Echtzeit-Verkehrsdaten). (2.3) Die Simulation ermöglicht den Test und den Vergleich verschiedener Optimierungsansätze für ein Free-Floating-Modell. Dabei ist es Kunden gestattet ihr Fahrzeug überall im Stadtgebiet abzustellen. (2.4) Seit Mai 2018 ist die neue EU-Datenschutz-Grundverordnung in Kraft getreten. Dies erfordert eine genaue Auseinandersetzung mit den ausgetauschten Daten, die zur Bereitstellung der Dienste notwendig sind. WASA - Gastbeitrag und Projektteampräsentationen

Genutzte Technologien Backend Java, Spring Boot, Cucumber, EA, Swagger, Maven Frontend Angular, Axure Infrastruktur Bitbucket, Docker (1.1) Im Backend werden Java und Spring Boot genutzt um die Services zu spezifizieren. Cucumber wird zum Testen der Service Feature verwendet. Mit Swagger werden die Schnittstellen und mit EA das Domänenmodell dokumentiert. (2.1) Im Frontend werden Angular zur Implementierung genutzt und Axure zum Erstellen von Entwürfen (2.2) Infrastrukturtechnologien sind Bitbucket und Docker mit denen die Services verwaltet und ausgeliefert werden WASA - Gastbeitrag und Projektteampräsentationen

Bisherige Architektur (1) Es existiert eine Benutzeroberfläche welche auf drei verschiedene Services zugreift. Die Services sind: (1.1) RentCar-Service (1.2) FindCar-Service (1.3) CatalogManagement Service (2) Die Services greifen alle auf die gleiche Datenbank zu und haben keine Zugriffe untereinander. Der FindCar-Service liefert alle Fahrzeuge, die sich in der Nähe des Kunden befinden, welcher die Anfrage gestellt hat. Der RentVehicle-Service bildet die rents-Relation zwischen Customer und Vehicle ab und ermöglicht es damit einem Kunden ein Fahrzeug zu mieten. Der CatalogManagement-Service enthält die Kataloge der unterschiedlichen Provider und speichert dabei alle verfügbaren Fahrzeuge. Über diesen Service können Provider Fahrzeuge anlegen und Customer Fahrzeuge anfragen. WASA - Gastbeitrag und Projektteampräsentationen

Microservice Charakteristiken Componentization via Services Organisation around business capabilities Smart endpoints and dumb pipes Decentralized data management Infrastructure automation (1) Microservice-Architektur kann in Services unterteilt werden, welche unabhängige Komponenten darstellen. Diese Komponenten kommunizieren untereinander über bestimmte Mechanismen Am Beispiel: Die Services stellen unabhängige Komponenten dar, jedoch sind sie nicht uneingeschränkt unabhängig auslieferbar, da sie eine gemeinsame Datenbank teilen und daher nur im Zusammenspiel funktionieren. (2) Die Microservice-Architektur teilt sich in Services auf, welche um Geschäftsfähigkeiten organsiert sind und damit konform zu Conway’s Gesetz sind. Am Beispiel: Die Services sind um Geschäftsfähigkeiten organisiert (3) Microservices sollten so entkoppelt und kohäsiv wie möglich sein. Daher sollten die Services sämtliche Logik enthalten und die Kommunikation zwischen den Services keine Logik enthalten und z.B. simple REST-Protokolle(Representational State Transfer) verwenden. Am Beispiel: Die Services kommunizieren untereinander über eine Datenbank anstatt die REST-Schnittstellen der anderen Services zu verwenden. (4) Jeder Service sollte seine eigene Datenbank verwalten Am Beispiel: Charakteristik wird nicht eingehalten, da wie bereits erwähnt alle Services über eine zentrale gemeinsame Datenbank verfügen. (5) Es sollten Continuous Integration und Continuous Delivery Techniken verwendet werden Am Beispiel: Auslieferung der Services ist nicht über Maven und Docker automatisiert. WASA - Gastbeitrag und Projektteampräsentationen

Bisheriges Domänenmodell (1) Es existiert kein Service, welcher die Kunden Entität abbildet (2) Der FindCar-Service hat keine eigene Entität und überschneidet sich mit den Daten im CatalogManagement-Service (3) Es gibt keine separate Buchungs Entität. Daher fällt die Verwaltung der Buchungen in den CatalogManagement-Service. Dies verletzt das Single-Responsibility-Prinzip, da der Catalog-Management-Service ebenfalls zuständig für das allgemeine Verwalten der Fahrzeuge ist. WASA - Gastbeitrag und Projektteampräsentationen

Geplantes Refactoring Datenbankzugriff der Services sollte dezentralisiert werden Jeder Service bekommt eine eigene Datenbank Kommunikation der Services ausschließlich über Schnittstellen Aufteilung der Services nicht optimal Neuer Service für Kundenverwaltung Integration des Find-Car Service in den Catalog-Management-Service Rent-Car-Service wird in Car-Booking-Service umgewandelt (1) Jeder Service erhält sein eigenes Modell und damit seine eigene Datenbank (2) Es werden konsequent die REST-Schnittstellen der Services benutzt, falls man Daten von einem anderen Service benötigt (3.1) Es wird der neue Service Customer-Management-Service eingeführt. Darüber soll es möglich sein, Kunden anzulegen und zu verwalten (3.2) Es wird der Find-Car-Service in den Catalog-Management-Service eingegliedert. Um dies zu erreichen, wird eine neue Schnittstelle innerhalb des Catalog-Management-Service eingeführt. Die entsprechende Logik wird aus dem bestehenden Find-Car-Service kopiert und über die neue Schnittstelle bereitgestellt. (3.3) Die Buchungen, also welcher Kunde welches Fahrzeug zurzeit gebucht hat werden in diesem Service verwaltet und angelegt WASA - Gastbeitrag und Projektteampräsentationen

NACH REFACTORING (1) Die Services sind neu aufgeteilt: (1.1) Der FindCar-Service wurde in den CatalogManagement Service integriert. Die aktuelle Position der Fahrzeuge ist daher nun über diesen Service zu ermitteln. (1.2) Der CustomerManagement-Service wird hinzugefügt und ermöglicht damit das anlegen und ändern von Kunden. Zusätzlich wird über diesen Service die Authentifikation der Kunden durchgeführt. (1.3) Car Booking verwaltet nun die Buchungen (2) Jeder Service hat seine eigene Datenbank, daher müssen die Services über die definierten REST-Schnittstellen kommunizieren. Dies erhöht die Entkoppelung der Services, da Änderungen an der Datenbank nicht alle Services betreffen, sondern nur den Service der diese Datenbank verwendet. WASA - Gastbeitrag und Projektteampräsentationen

Customer Management Service Features Register with a car sharing service Authenticate with a car sharing service (Register with a car sharing service) Der Kunde registriert sich auf der Plattform. Dazu gibt er die benötigten Daten an und gibt seine Einverständnis zur Datenschutzerklärung. Danach wird er entsprechend in der Datenbank angelegt und ist registriert. (Authenticate with a car sharing service) Ein bereits registrierter Kunde möchte sich mit dem Service authentifizieren und ist danach authentifiziert (Manage profile data) Ein authentifizierter Kunde möchte sein Profil aktualisieren. Dazu gibt er die benötigten Daten ein und startet die Anfrage. Danach ist sein Profil gemäß der neuen Daten aktualisiert. (Open my profile) Wenn ein Kunde sein Profil öffnet, sieht er seine Buchungshistorie und seine aktuellen Buchungen. Manage profile data Open my profile WASA - Gastbeitrag und Projektteampräsentationen

Automatische Swagger Benutzeroberfläche Änderungen an Schnittstellen müssen immer dokumentiert werden Manuelles aktualisieren ist fehleranfällig und aufwändig Automatisiertes Aktualisieren um dies zu vermeiden Springfox Swagger 2 für Spring REST API als Lösung (1) Falls die Dokumentation der Schnittstellen nicht aktuell ist, ist es denkbar, dass z.B. das Frontend nicht auf die richtigen Schnittstellen zugreift und daher den Service nicht korrekt benutzen kann (2) Eine automatische Dokumentation der Schnittstellen verhindert Fehler und sorgt für eine stets aktuelle Schnittstellendokumentation (3) Durch die Springfox Swagger 2 Implementation ist es möglich vorhandene REST APIs automatisch zu erkennen und zu dokumentieren. Dazu werden, um zusätzliche Informationen über die API und die Antworten bereitzustellen, Annotationen verwendet wie z.B:. @ApiOperation. Um die Swagger Dokumentation zu erzeugen ist die @EnableSwagger2 Annotation notwendig. Diese muss mit der SwaggerConfig Klasse verwendet werden, in welcher die automatische Swagger Dokumentation konfiguriert wird. Weitere optionale Annotationen sind: (3.1) @ApiOperation: Damit wird eine Schnittstellen Operation eine genauere Beschreibung hinzugefügt (3.2) @ApiResponses: Damit werden einzelnen HTTP-Codes in der Antwortdefinition genauere Beschreibungen hinzugefügt oder der Code als mögliche Antwort erst hinzugefügt WASA - Gastbeitrag und Projektteampräsentationen

Context Map – Carsharing (1) Die Context Map vom Carsharing zeigt alle Microservices auf, welche miteinander arbeiten. (1.1) Das CatalogManagement beinhaltet Services, welche dafür Verantwortlich sind um alle Autos zu verwalten. Ein Anbieter kann auch hiermit sein Auto für das Carsharing bereitstellen. (1.2) Das CustomerManagement verwaltet alle Kunden und bietet Kunden die Möglichkeiten an, sich zu registrieren. (1.3) Das CarBookingManagement übernehmt die Hauptaufgaben des Carsharing, nämlich das Reservieren und Mieten der Autos. Es verwaltet unter anderem die Information welches Auto von welchem Kunden gerade gemietet wird. (2) Daran erkennt man, dass CatalogManagement und CustomerManagement mit CarBookingManagement in einer Relation stehen, selbst aber nicht zusammen direkt kommunizieren. WASA - Gastbeitrag und Projektteampräsentationen

Domänenmodell – CatalogManagement (1) Das CatalogManagement besteht aus folgenden Entitäten: (1.1) Provider: Die Aufgabe des Providers ist die Verwaltung eines Katalogs. (1.2) Catalog: Die Aufgabe des Katalogs ist die Verwaltung der bestehenden Autos zum Mieten. (1.3) Vehicle: Das Vehicle beschreibt das Fahrzeug. (2) Außerdem sind zwei Value Objekte vorhanden: (2.1) Manufacturer: Der Manufacturer beschreibt die Marke des Fahrzeugs (wie zB: VW oder BMW). (2.2) Position: Die Position ist eine Kombination aus Längen- und Breitengrad, welche den Standort des Fahrzeugs eindeutig festlegt. (3) Des weiteren gibt es eine Enumeration: (3.1) Size: Die verschiedenen Größen klassifizieren die Fahrzeuge nach Größe. WASA - Gastbeitrag und Projektteampräsentationen

Weitere Domänenmodele Oben sind Domänenmodelle vom CustomerManagement und CarBookingManagement abgebildet. (2) Das Domänenmodell des CustomerManagement besteht aus einer Entität, dem Customer. Dieser beinhaltet folgende Felder: (2.1) Der Name beschreibt den Vor- und Nachnamen des Kunden. (2.2) Die Adresse beschreibt die angegebene Adresse vom Kunden. (2.3) Durch den Wert von „authenticated“ kann man feststellen, ob ein Kunde schon im System angemeldet ist oder nicht. (2.4) Der Wert von „privacyPolicyConsent“ sagt, ob der Kunde den Cookie-Richtlinien zugestimmt hat. (3) Das Domänenmodell des CarBookingManagement besteht aus zwei Entitäten. (3.1) Booking beschreibt eine Buchung mit den wesentlichen Daten, wie CustomerId und VIN (eindeutige Erkennungsnummer eines Fahrzeugs). Außerdem enthält die Buchung einen Buchungstyp, welcher die Art beschreibt, ob es sich bei der Buchung um eine Reservierung oder um eine Buchung handelt. (3.2) Die BookingHistory ist das Logging der abgeschlossenen Buchungen. Dieser beinhaltet die CustomerId, VIN und das Datum an dem das Fahrzeug abgegeben wurde. WASA - Gastbeitrag und Projektteampräsentationen

Orchestration View – Car Booking Management Das CarBookingManagement benutzt das Fahrzeug, welches vom CatalogManagement geteilt wird. (1.1) Das Fahrzeug ist in dieser Beziehung das „shared entitiy“. (2) Das CarBookingManagement benutzt auch den Customer, welches vom CustomerManagement geteilt wird. (2.1) Der Kunde ist in dieser Beziehung das „shared entitiy“. WASA - Gastbeitrag und Projektteampräsentationen

Swagger API – CarBookingManagement (1) Hier ist die vom Springframework automatisch generierte Swagger OpenAPI des CarBookingManagement. Es sind folgende API Schnittstellen vorhanden: (1.1) „booking/{vin}/available“ überprüft ob ein Fahrzeug mit übergebener VIN existiert. (1.2) „booking/{vin}/rent“ mietet das Fahrzeug mit der übergebenen VIN. (1.3) „booking/{vin}/reserve“ reserviert das Fahrzeug mit der übergebenen VIN, sodass kein weiterer Kunde das Fahrzeug mieten kann. (1.4) „booking/{vin}/return“ gibt das gemietet Fahrzeug mit der übergebenen VIN wieder zurück. (1.5) „booking/rented“ gibt alle Fahrzeuge zurück, welche gemietet wurden. (1.6) „booking/rented/{customerId}“ zeigt das Fahrzeug, welche von einem Kunden mit der übergebenen customerId. WASA - Gastbeitrag und Projektteampräsentationen

NACH REFACTORING Customer UI Provider UI Die Customer UI kommuniziert mit CustomerManagement und CarBookingManagement via REST. (2 Die Provider UI kommuniziert nur mit dem Catalog Management via REST. WASA - Gastbeitrag und Projektteampräsentationen

ConnectedCar: Frontend ARCHITEKTUR CUSTOMER & PROVIDER UIs FEATURES DATENSCHUTZ DEMO This part of the presentation focuses on presenting the frontend layer of the ConnectedCar web-application. (1) First of all, the architecture of the application is described. In detail, the application’s components as well as their communication paths are outlined. (2) The application consists of two main views: the customer view – intended for customers and focusing on providing car-sharing related services to them; and the provider view – intended for the owner of the car fleet to enable vehicle management. (3) Further, the application’s features are displayed (with division into customer and provider features). (5) At the end, a live demo is planned to present the web-application. WASA - Gastbeitrag und Projektteampräsentationen

Frontend: Architektur Customer-UI Alle Feature-Module sind dem Root-Modul zugeordnet Bestandteile eines NgModules: View, Komponente, Service (1) The basic building blocks of an Angular application are NgModules, which provide a compilation context for components. NgModules collect related code into functional sets. An Angular app is defined by a set of NgModules: one root module - (in the case of ConnectedCars called: AppComponent) that enables bootstrapping, and typically many more feature modules. The feature modules are presented in the diagram. (2) Each component consist of: View (*.html), which describes which elements are written into DOM and rendered by the browser. Angular recognizes its own elements (from Angular library), but also standard HTML tags. Styling class (*.css) – to style standard elements into custom ones Component.ts – includes program and business logic. It also defines global variables, which are connected via two-way binding to the view. Component calls methods from service.js and provides them with valid parameters. Service.ts - provides specific functionality not directly related to views. It establishes a connection to the backend server via HTTP using parameters from component. Service providers can be injected into components as dependencies, making the application code modular, reusable, and efficient. WASA - Gastbeitrag und Projektteampräsentationen

Customer UI Features: Create Account Log-in/Log-out Rent a Car unverändert Find a Car Reserve a Car (1) This slide outlines the new features of the application (from the customer’s perspective). (1.1) Create Account: Should a customer not have an account yet, it is possible to create one. The required input is: user name and password. (1.2) Log-In/Log-Out: User is required to log in, before any action (e.g. rent a car) may be taken. At the end of using the application, user should log out. (1.3) Rent a Car: User may rent a car. Prerequisites: User is logged in and specifies the vehicle by its VIN-number. (1.3.1) This feature remains unchanged, since it has been designed and developed by the team in the previous semester. (1.4) Find A Car: User has the possibility to see available vehicles on the map. Each vehicle is labeled with brand and size. (1.5) Reserve A Car: User may reserve a vehicle in advance to be sure that it is still available, once they approach it later. WASA - Gastbeitrag und Projektteampräsentationen

Find a Car Position des Fahrzuges durch einen Marker gekennzeichnet Umsetzung in Open Street Map mithilfe von Leaflet.js Bibliothek Filterung nach Fahrzeug Marken und Größen Änderung der Kartenposition durch Angabe des neuen Ortes (mit Autovervollständigung) OSMNames API (1) A vehicle‘s position is labeled with a blue marker. Once clicked, a popup emerges with the following information: vehicle’s brand and size. (1.1) Vehicle positions are displayed in an Open Street Map [OSM]. Leaflet.js is used to render the map within the DOM of the application. In order to use Leaflet.js it has to be imported into the index.html file (both the Java-Script coding and the styling). While initializing the map, the following properties are specified: map’s id, the center of the map, maximal zoom and access token (used to connect to OSM API) (2) Users may use filters to limit the amount of displayed vehicles. (3) Users may switch to different world locations. For this purpose, they are required to put the first couple of letters of the desired city into the location box. The autocomplete function is used to propose 20 possible locations based on the user’s input. (3.1) OSMNames API [OSMNames] is used to display 20 best hits based on user’s input. This is realized thanks to an external HTTP-request to the OSMNames server (again while using an access token), which returns the list of possible cities. A callback function is called to display them as a list for the user to choose from. [OSM] – Open Street Map. https://www.openstreetmap.de/ [Leaflet] – Leaflet.js. https://leafletjs.com/ [OSMNames] – Open Street Map Names. https://osmnames.org/api/ WASA - Gastbeitrag und Projektteampräsentationen

Provider UI Features: Create New Cars unverändert Manage Cars Manage Rented Cars (1) This slide outlines the new features of the application (from the provider’s perspective). (1.1) Create New Cars: Provider may create new cars and specify their properties: size and brand. (1.1.1) This feature remains unchanged, since it has been designed and developed by the team in the previous semester. (1.2) Mange Cars: Here a list of all available car is displayed. (1.2.1) This feature remains unchanged, since it has been designed and developed by the team in the previous semester. (1.3) Manage Rented Car: Here a list of all rented cars is displayed. WASA - Gastbeitrag und Projektteampräsentationen

Ablauf einer HTTP-Anfrage This slide describes the sequence of operations which take place, when the user interacts with the application (e.g. wishes to rent a car) (1) Once the “Rent” button is clicked, the onCarRentalRequest() event is called. Next, the validity of the user’s input is checked, e.g. if the VIN-number is specified. (2) The component of the RentACar module calls the associated service. In this case, the HTTP-method PUT is used. The URL, containing the VIN-number, is concatenated; the request’s body is filled with the customer’s ID (in JSON format; Customer ID is known as the user logged in beforehand) (3) On the backend site the request is being processed. As soon as the request has come from the frontend to the CarBookingManagment, it is first examined whether the specified CustomerId and VIN at all exist. For this purpose, services from CatalogManagement and CustomerManagement are used. If the validation is successful, it is checked again whether the customer or the vehicle are not present in an exisiting booking. Then the booking is generated or a corresponding error message is generated. (4) Finally, the server sends the response with the status code 200. In this case, a success message is displayed to notify the user. WASA - Gastbeitrag und Projektteampräsentationen

Injectable: Beispiel Jede Angular Komponente hat ihre eigene Injectable-Datei zur Kommunikation mit dem Backend (1) This slide presents how the service file is structured. The base URL is set to the value under which the server may be reached. The customer URL specifies the request’s path, thus ensuring the exchangeability to offer other services under the base URL. In the method itself, the parameters are defined. Customer ID is a global variable accessible application-wide. Further, the method type is set to PUT. Finally, two possible callbacks are declared: success and error. Should the request-call fail, the corresponding error message is displayed in the view. WASA - Gastbeitrag und Projektteampräsentationen

Demo Live Präsentation von Customer & Provider UI Links: https://customer-ui.cm.tm.kit.edu https://provider-ui.cm.tm.kit.edu (1) Full functionality of the application will be presented during a live demo. WASA - Gastbeitrag und Projektteampräsentationen

ConnectedCar: Frontend CUSTOMER Features: Edit Profile & Booking History Cookie Law & DSGVO DATENSCHUTZ Neue Regularien Realisierung CarSharing (1) Für den Benutzer wurde ein Feature bereitgestellt, damit dieser einen besseren Überblick über hinterlegte Daten und getätigte Reservierungen erhalten kann. (1.1) Im Profil hinterlegte Daten können nachträglich durch den Benutzer angepasst bzw. korrigiert werden. (2) Seit Anfang Juni 2018 sind neue Datenschutzregularien in Kraft getreten, die neue Anforderungen an Webmaster, Firmen und Vereine stellen. (2.1) Die wichtigsten neuen Anforderungen, die an Webmaster, Firmen und Vereine anfallen, sollen vorgestellt werden. Auf die Fragestellung, welche Auswirkung und Bedeutung das für die Softwareentwicklung hat, wird ebenfalls eingegangen. (2.2) Die neuen, in Kraft getretenen, Datenschutzregularien wurden im Projekt CarSharing mitberücksichtigt. Die Vorstellung einiger Datenschutzregularien, sollen die realisierten Pflichten, die im Projekt CarSharing berücksichtigt und umgesetzt wurden, hervorheben WASA - Gastbeitrag und Projektteampräsentationen

Edit Profil Kunde kann sein erstelltes Profil bearbeiten Erforderliche Angaben: First name Last name Street Addresse Erhält Rückmeldung Auforderung zur Bestätigung der Privacy Policy Ermöglicht Einblick in die Bestellhistorie Auflistung bisher getätigter Reservierungen Darstellen aktueller Reservierungen (1) Jeder Benutzer von CarSharing kann sein Profil nach seinem persönlichem Status, der sich jeder Zeit ändern kann, anpassen. (2) Um das Profil anzupassen zu können, ist einen vollständige Angabe nötig. Wurden keine Daten im Input-Feld hinterlegt, kann der Benutzer keine Korrektur vornehmen. (2.1) – (2.3) First name, Last Name, Street name sind notwendige Angaben, um ein Post-Request an das Backend senden zu können. (3) Der Benutzer erhält durch einen Popup-Dialog eine Rückmeldung, sobald die Daten im Backend verarbeitet wurden. (4) Damit die Daten an das Backend übermittelt werden können, wird die Zustimmung der Datenschutzvereinbarung des Benutzer erwartet. Andernfalls wird keine Korrektur der angegebenen Daten vorgenommen. (5) Die Booking history erlaubt dem Benutzer einen Überblick der getätigten und aktuellen Reservierungen zu erhalten. (5.1) Latest booking listet alle aktuellen Reservierungen auf, die durch den Benutzer getätigt wurden. (5.2) Old Bookings ermöglicht dem Benutzer vergangene Reservierungen zu verfolgen und miteinander zu vergleichen. WASA - Gastbeitrag und Projektteampräsentationen

Cookie Law & DSGVO Popup-Animation informiert Nutzer über die Datenschutzerklärung Garantiert Einhaltung der neuen Datenschutz-Grundverordnung Erfordert Bestätigung des Nutzers Auswirkungen der neuen DSGVO auf die Softwareentwicklung Privacy by Design Privacy by Default (1) Die Verwendung von Cookies erfordert die explizite Zustimmung des Nutzers. Besucht der Nutzer die Webpräsenz von CarSharing, wird dieser aufgefordert, der Zustimmung nachzukommen. Durch einen Popup-Animation, die beim besuchen der Webseite aufsteigt, wird auf die erforderliche Zustimmung aufmerksam gemacht. (1.1) Durch den Hinweis zur erforderlichen Zustimmung wird die Einhaltung der neuen Datenschutz-Grundverordnung garantiert. (1.2) Der Benutzer wird aufgefordert, die Datenschutzvereinbarung von CarSharing aktiv zu akzeptieren. (2.1) Privacy by Design (PbD) bedeutet, dass Datensicherheit bei der Verarbeitung von Daten von Vornherein berücksichtigt werden muss. Um PbD sicherzustellen, müssen die Regularien des Datenschutzes bereits frühzeitig in die Konzeption neuer Systeme eingebunden werden. Personenbezogene Daten müssen von Beginn der Verarbeitung geschützt werden. (2.2) Mit Privacy by Default wird auf Privacy by Design aufgebaut. Die zu entwickelnde Software sollte nicht nur die Regularien des Datenschutzes zu Verfügung stellen, sondern diese auch von vorneherein standardmäßig aktiviert haben. Fehlende Sicherheitskonfigurationen erlauben oftmals Zugriff auf sensible Daten. Durch Privacy by Default soll sichergestellt werden, dass durch fehlende Sicherheitskonfigurationen kein unerlaubter Zugriff ermöglicht wird. WASA - Gastbeitrag und Projektteampräsentationen

DSGVO - Was sich durch die Grundverordnung ändert Betreiber einer Webseite sind verpflichtet, seine Besucher über Vorgänge aufzuklären, bei denen personenbezogene Daten erhoben werden Jeder einzelne Prozess, bei dem personenbezogene Daten erfasst oder verarbeitet werden, ist zu dokumentieren Unter bestimmten Voraussetzungen ist ein Datenschutzbeauftragter zu benennen SSL-Verschlüsselung bei Log-ins, Web-Formularen ist verpflichtend Die Verwendung von Cookies erfordert die Einwilligung des Besuchers Privacy by default .. (1) Generell gilt in der DSGVO wie auch im alten Bundesdatenschutzgesetz das Gebot der Datenminimierung, nach dem so wenige Daten wie möglich und nur so viele wie unbedingt für den Zweck nötig erhoben werden dürfen. Die DSGVO soll Betreiber dazu zwingen, die Verarbeitung personenbezogener Daten transparenter und sicherer zu gestalten. Von der Datenerhebung Betroffene sollen jederzeit gut informiert sein. Deshalb gelten nun erweitere Auskunftspflichten und das Gebot zu klaren, verständlichen Erklärungen. (2) Bis auf wenige Ausnahmen ist laut DSGVO ein Verzeichnis von Verarbeitungstätigkeiten zu erstellen. Darin wird jeder Prozess, bei dem personenbezogene Daten erfasst und verarbeitet werden, dokumentiert. Außerdem sind Verantwortliche für diese Prozesse zu nennen. Diese Verzeichnisse sind nicht öffentlich, sondern sollen der internen Qualitätskontrolle dienen und außerdem jederzeit auf Anfrage einer Aufsichtsbehörde vorgelegt werden können. (3) Verarbeitet ein Unternehmen oder ein Verein besonders geschützte Daten oder sind mindestens zehn Personen mit Datenbearbeitung beschäftigt, muss ein Datenschutzbeauftragter benannt werden. Er soll laut DSGVO Verantwortliche beraten, Betroffenen helfen den Datenschutz überwachen und insbesondere als Bindeglied zwischen Betreiber und Aufsichtsbehörde dienen. (4) Personenbezogene Daten müssen verschlüsselt zur Webseite gelangen. Aus dem Grundsatz der Integrität und Vertraulichkeit kann abgeleitet werden, dass SSL-Verschlüsselung bei Web-Formularen, Authentifizierung verpflichtend ist. Mailserver und Provider müssen TLS beherrschen und wann immer möglich verwenden. (5) Dienen Cookies nicht nur der Erhaltung des Services, benötigt man laut DSGVO eine „informierte Einwilligung“ des Nutzers. (6) Unternehmen müssen Programme, Apps oder sonstige Anwendungen mit datenschutzfreundlichen Voreinstellungen versehen. Grundsätzlich sollen nur zwingend erforderliche personenbezogene Daten verarbeitet werden. WASA - Gastbeitrag und Projektteampräsentationen

Was wurde im CarSharing umgesetzt ? Es werden nur relevante Daten erhoben Nutzer kann nur durch Bestätigung der Policy den Service benutzen Verwendung von Cookies durch Einwilligung des Besuchers SSL-Verschlüsselung bei Logins, Web-Formularen Privacy by default (1) Es werden nur Daten erhoben die auch nötig sind, um den Carsharing-Service dem Nutzer anbieten zu können. (2) Um die Einwilligung der Datenschutzerklärung des Nutzer zu erhalten, ist eine aktive Zustimmung des Nutzer erforderlich. Andernfalls wird der Service nicht angeboten. (3) Die Verwendung von Cookies wird durch den Nutzer zugestimmt. (4) Die Kommunikation zwischen Client und Server erfolgt durch einen verschlüsselten Kommunikationskanal. (5) Es werden nur zwingend erforderliche personenbezogene Daten verarbeitet. WASA - Gastbeitrag und Projektteampräsentationen