BABE Ș-BOLYAI UNIVERSITÄT CLUJ-NAPOCA FAKULTÄT FÜR MATHEMATIK UND INFORMATIK INFORMATIK IN DEUTSCHER SPRACHE BACHELORARBEIT [TITEL] Betreuer Dr…. [612296]

BABE Ș-BOLYAI UNIVERSITÄT CLUJ-NAPOCA

FAKULTÄT FÜR MATHEMATIK UND INFORMATIK

INFORMATIK IN DEUTSCHER SPRACHE

BACHELORARBEIT

[TITEL]

Betreuer
Dr. Diana Troanc ă, Lector Universitar

Eingereicht von
Pirpidel Sebastian-Gheorghe

2017

2
Inhalt
Kapitel 2 ………………………………….. …………………………………………… …………………………………………… ……………… 3
Technologien ……………………………….. …………………………………………… …………………………………………… ………….. 6
Buildwerkzeuge – Gradle und Vergleiche ………… …………………………………………… ……………………………………. 6
Einführung …………………………………. …………………………………………… …………………………………………… …….. 6
Ziele von Buildwerkzeugen ……………………. …………………………………………… ………………………………………… 6
Make ………………………………………. …………………………………………… …………………………………………… ……….. 6
Ant ……………………………………….. …………………………………………… …………………………………………… …………. 6
Maven ab Version 2 ………………………….. …………………………………………… …………………………………………… .. 7
Gradle …………………………………….. …………………………………………… …………………………………………… ……….. 7
Praktischer Vergleich………………………… …………………………………………… …………………………………………… .. 8
Spring (Boot) ………………………………. …………………………………………… …………………………………………… ……… 10
Kurze Einführung zum Spring Framework …………. …………………………………………… …………………………….. 10
Spring Boot ………………………………… …………………………………………… …………………………………………… …… 10
ORM und Persistenz ………………………….. …………………………………………… …………………………………………… … 12
Hibernate ………………………………….. …………………………………………… …………………………………………… ……. 12
JPA ……………………………………….. …………………………………………… …………………………………………… ………. 12
Spring Data JPA …………………………….. …………………………………………… …………………………………………… .. 13
Benutzerdefinierte Methoden und Queries ……….. …………………………………………… ………………………………. 13
Automatische Benutzerdefinierte Queries ……….. …………………………………………… ……………………………….. 13
Manuelle Benutzerdefinierte Queries …………… …………………………………………… ………………………………….. 14
Front-End ………………………………….. …………………………………………… …………………………………………… ……….. 15
Angular ……………………………………. …………………………………………… …………………………………………… …….. 15
Twitter Bootstrap …………………………… …………………………………………… …………………………………………… … 15
Implementierung – Backend ……………………. …………………………………………… …………………………………………… .. 17
Projektstruktur …………………………….. …………………………………………… …………………………………………… ……… 17
Spring Boot ………………………………… …………………………………………… …………………………………………… ………. 18
Model – Entity ……………………………… …………………………………………… …………………………………………… ….. 18
Repository …………………………………. …………………………………………… …………………………………………… ……. 19
Controller …………………………………. …………………………………………… …………………………………………… …….. 20
Besondere Controller ………………………… …………………………………………… …………………………………………… …. 20
Data Storage Controller ……………………… …………………………………………… ………………………………………….. 20
Variant Builder …………………………….. …………………………………………… …………………………………………… …. 22
Implementierung – Frontend …………………… …………………………………………… …………………………………………… .. 25
ng ………………………………………… …………………………………………… …………………………………………… ……………. 25
ngModel ……………………………………. …………………………………………… …………………………………………… ……. 25
ngFor………………………………………. …………………………………………… …………………………………………… ……… 25
Backend Service …………………………….. …………………………………………… …………………………………………… …… 25
Literaturverzeichnis ………………………… …………………………………………… …………………………………………… ………. 30

3
Kapitel 2

In der Automotive-Industrie gibt es sehr viele komp lexe technische Dokumente, die für alle
Bestelltypen und Modelljahre gleichzeitig erstellt und nachgepflegt werden müssen. Porsche
hat ein eigenes Publikationssystem erstellt, welche s alle XML Dokumente, Teile und
Beziehungen in einer relationalen Datenbank speiche rt. Dieses Werkzeug soll dazu dienen,
diese Strukturen, die verschiedenen Versionen eines Dokumentes, sowie auch dessen Teile
besser besichtigen zu können.

Mein Projekt sollte es also einfach machen, für ein e gegebene Doku-ID-Nummer die
Modelljahre und Bestelltypen, für welche das Dokume nt veröffentlicht wurde, auf der
Schnellen sehen zu können. Dazu sollte man noch lei cht ablesen können, für welche dieser
Modelle das Dokument noch keine Freigabe zur Publiz ierung hat. Es gibt Fahrzeuge, für die
es schon Dokumente im Voraus gibt, also bevor es di ese auf dem Markt gibt. Bei diesen wird
man dann leicht feststellen können, warum das gegeb ene Dokument nicht auf dem
Prodkutivsystem gefunden werden kann. Ähnlich gibt es dann Fahrzeuge, für die ein
bestimmtes Dokument oder Teil eines Dokumentes gelö scht wurde, was dann auch in der
Benutzeroberfläche ersichtlich sein sollte.

Variantenbildung

Ein komplexer Teil des Prototyps, der nicht so leic ht veranschaulicht werden kann, ist die
Variantenbildung. Hierzu muss man einiges mehr in B etracht ziehen. Jedes Modul und HKap
hat eine Restriktion, und zwar gibt es für jedes ei n Feld, das „ModelljahrAb“ heißt. Dieses
gibt uns an, ab welches Jahr ein solcher Teil des D okumentes gültig ist. Man muss zuerst für
die HKap-Id, die eigentliche Id des Dokumentes, das „ModelljahrAb“ und die Bestelltypen
bestimmen, z.B. für HKap „80009976“, MJ ab 2015, BT ypen „9AAAA1“,“9ABBC1“. Diese
Daten geben uns an, was die größte Ausprägung diese s Dokumentes sein könnte, also könnte
es maximal für alle Jahre ab „ModelljahrAb“ und für alle Bestelltypen des HKaps
freigegeben worden sein. Jeder Bestelltyp hat eine sogenannte „Model Restriction“. Das ist
die Einschränkung eines Bestelltypes auf Modelljahr e, beziehungsweise für welche Jahre
diese verfügbar sind, z.B. Bestelltyp „9AAAA1“ für 2016, 2017, 2018, Bestelltyp
„9ABBC1“ für 2016, 2017. Man muss jetzt herausfinde n, ab welches Jahr die einzelnen Teile

4
des Dokumentes gültig sind, z.B. Modul 1 mit Id „80 023123“, ModelljahrAb 2017 und
Modul 2 mit Id „80992245“, ModelljahrAb 2018.

Hier kann man schon erkennen, dass es zu Unterschie den kommen kann. Das erste Modul ist
für alle Jahre ab 2017 gültig, also überlappt sich das mit Bestelltyp „9AAAA1“ für das
Zeitintervall 2017-2018, das zweite aber nur für di e Jahre nach 2018. Das heißt, dass hier der
gemeinsame Zeitraum nur 2018 ist.

Zur Veranschaulichung:

HKap-Id 80009976
Modelljahrab für HKap 2015
Bestelltypen für HKap 9AAAA1, 9ABBC1

Module für HKap Modelljahrab
Modul 1: 80023123 2017
Modul 2: 80992245 2018

Module gültig für alle Bestelltypen.

Model Restrictions HKap Modul 1 Modul 2
2015 x
9AAAA1 2016 x
9AAAA1 2017 x x
9AAAA1 2018 x x x
9ABBC1 2016 x
9ABBC1 2017 x x

So hat man hier 2 Varianten: eine für das Jahr 2017 nur mit dem ersten Modul und beiden
Bestelltypen, weil dieses Modul auch für 2017 publi ziert wurde und eine zweite für das Jahr

5
2018 mit beiden Modulen und dem Bestelltyp „9AAAA1“ . Die erste ist eine einzige
Variante, weil Varianten als Identifikator die Zusa mmenstellung der Ids zugeordnet
bekommen. In beiden Fällen sind das die Ids des HKa ps und des ersten Moduls, also kommt
derselbe „Schlüssel“ heraus und zwar „80009976, 800 23123“.

Die Varianten schauen also folgendermaßen aus:

Schlüssel Model Restrictions
Variante 1 “80009976, 80023123” 9AAAA1 2017, 9ABBC1 2017
Variante 2 “80009976, 80023123, 80992245” 9AAAA1 20 18

Wie man erkennen kann, fallen die Jahre 2015 und 2 016 aus, obwohl das HKap für 2015
freigegeben wurde und 2016 für den Bestelltyp „9AAA 1“ gültig ist. Das passiert weil keines
der Module in diesen Jahren verfügbar ist. Es kann aber auch vorkommen, dass eines oder
mehrere Module auch für diese Jahre freigegeben wur den und dann gäbe es schon mindestens
eine weitere Variante.

6

Technologien

Buildwerkzeuge – Gradle und Vergleiche
Einführung
„Als Build bezeichnet man den Prozess, in welchem e in Buildwerkzeug andere Werkzeuge
benutzt, um aus dem Quellcode ein funktionierendes Produkt zu schaffen, das von anderen
verwendet werden kann.” (1 S. 78)

Ziele von Buildwerkzeugen
• kleineres Zeitintervall zwischen Codeänderungen und sichtbaren Ergebnissen
• weniger Arbeitsaufwand für Entwickler
• Continuous Integration (Projekt sollte sich zu jede m Zeitpunkt in stabilem Zustand
befinden)
• automatische Fehlerentdeckung (2)

Make
• Vorfahrer der Buildwerkzeuge
• seit 1977
• aktuell noch weitgehend benutzt
• Konzepte heutzutage noch von den meisten Buildsyste men angewendet (2)
Die Vorteile von Make sind, dass es eine globale De finition von Variablen zulässt und
einzelne Ziele des Builds definiert und dass man Ab hängigkeiten deklarieren kann, wie in
modernen Build Tools auch. Deswegen kann es viel we niger dauern bis ein Projekt gebaut
wird.
Die Nachteile dieses Urvaters der Buildwerkzeuge si nd, dass man Zeitstempeln nutzt und
dass das Debugging schwierig ist. Außerdem ist es m ühsam, Make Scripts zu portieren. (2)

Ant
• seit 2000
• sehr ähnlich zu Make

7
• nicht mehr so populär
• wird noch weiterentwickelt (3)
Einige Vorteile von Ant sind, dass dieses Werkzeug plattformunabhängig ist und in Java
implementiert wurde. Die Scripts werden in XML Form erstellt und es gibt eine bessere
Trennung zwischen Buildimplementierung und –definit ion. Ant bietet sehr große Kontrolle
über den Buildprozess und der Entwickler muss keine genaue Verzeichnisstruktur haben,
aber deswegen muss sehr genau angegeben werden, wo alle Daten sind. Hier gibt es aber
auch schon eines der Nachteile und zwar dass die Sk ripte schnell lang werden können, auch
wegen der XML-Struktur. Ant selbst kann aber im Geg ensatz zu Maven keine
Abhängigkeiten verwalten. Dies muss dann mit Hilfe von Plug-ins, wie z.B. Apache Ivy,
gemacht werden. (3)

Maven ab Version 2
• erste Version entstand 2001
• Maven 2 entstand 2005
• sehr viele Standards, geringe Flexibilität (z.B. ei nheitliche Verzeichnisstrukturen,
einheitlicher Buildprozess, Convention over Configu ration)
• Repository
o ermöglicht automatisches Herunterladen von Biblioth eken und Plug-ins
o kann Build-Dauer reduzieren
• Multiprojekte werden unterstützt
• Profile (4)
Ein Vorteil von Maven ist, dass es wie oben erwähnt Standardisierungen fördert. Außerdem
werden Wiederverwendung und eine einheitliche Organ isation der Abhängigkeiten auch
unterstützt. Das Handling wird bei eine großen Anza hl von Abhängigkteiten vereinfacht.
Weil die Ziele in Plug-ins definiert werden, wird d ie Arbeitsteilung zwischen
Konfigurationsmanagement und Softwareentwicklung ge fördert. (4)
Gradle
• neue Version veröffentlicht 2012
• für Projekte in Java, Groovy und Scala gedacht
• benutzt nicht XML sondern DSL (Domänenspezifische S prache)

8
Gradle ist ein flexibles aber modellbasiertes JVM-g estütztes Buildwerkzeug. Gradle erkennt
die allerbesten Ideen aus Make, Ant, Ivy, Maven, Ra ke, Gant, Scons, SBT,
Leinengen , und Buildr an und verbessert sie. Die e rstklassigen Funktionen, die vorher in
verschiedenen Werkzeugen verstreut waren, sind jetz t in einer vereinten Groovy DSL
Sprache für Scripting und einem Java API für Toolin g verfügbar. Gradle hat schon mit der
Version 1.0, die zur Zeit des Schreibens aktuell is t, große Anerkennung von einigen der am
höchsten angesehenen Unternehmen und Open-Source-Ge meinschaften bekommen.
(5 p. xiii).

Ich habe mich entschlossen in meinem Projekt Gradle anzuwenden, da es zur Zeit das
beliebteste, einfachste und beste Werkzeug für Buil ds zu sein scheint. Außerdem ist Gradle
sehr gut mit Spring integriert, das in meiner Anwen dung auch eine wichtige Rolle spielt.

Praktischer Vergleich
Im Folgenden befinden sich zum Vergleich Skripte in Ant, Maven und Gradle die dieselbe
Wirkung haben.

Ant:
<project>
<target name =”clean” >
<delete dir =”classes” />
</target>

<target name =”compile” depends =”clean” >
<mkdir dir =”classes” />
<javac srcdir =”src” destdir =”classes” />
</target>

<target name =”jar” depends =”compile” >
<mkdir dir =”jar” />
<jar destfile =”jar/HelloWorld.jar” basedir =”classes” >
<manifest>
<attribute name =”Main-Class”
value =”antExample.HelloWorld” />
</manifest>
</jar>
</target>

<target name =”run” depends =”jar” >
<java jar =”jar/HelloWorld.jar” fork =”true” />
</target>
</project>

9
(6)

Maven:
<project xmlns =”http://maven.apache.org/POM/4.0.0”
xmlns:xsi =”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation =”http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd ”>
<modelVersion> 4.0.0 </modelVersion>
<groupId> baeldung </groupId>
<artifactId> mavenExample </artifactId>
<version> 0.0.1-SNAPSHOT </version>
<description> Maven example </description>
<dependencies>
<dependency>
<groupId> junit </groupId>
<artifactId> junit </artifactId>
<version> 4.12 </version>
<scope> test </scope>
</dependency>
</dependencies>
</project>
(6)

Gradle:
apply plugin : ‘java’

repositories {
mavenCentral()
}

jar {
baseName = ‘gradleExample’
version = ‘0.0.1-SNAPSHOT’
}

dependencies {
compile ‘junit:junit:4.12’
}
(6)

10
Spring (Boot)
Kurze Einführung zum Spring Framework
Das Spring Framework ist ein Open-Source Anwendungs framework, das als Ziel die
Vereinfachung der Java Enterprise (J2EE) Entwicklun g hat. Im Gegensatz zu einstufigen
Frameworks wie Hibernate versucht man mit Spring be i der Strukturierung ganzer
Anwendungen auf einer konsistenten, produktiven Wei se zu helfen, indem man die
bestmöglichen einstufigen Frameworks zusammenbringt , um eine kohärente Architektur
erstellen zu können. Spring ermöglicht es, die Vort eile von J2EE genießen zu können und zur
selben Zeit die Komplexität, die der Anwendungscode aufweist, herunter zu bringen.
Die Basis von Spring besteht darin, Enterprise-orie ntierte Services für „Plain Old Java
Objects“ (POJOs) implementierbar zu machen. Das ist in einer J2EE-Umgebung besonders
wertvoll, aber Anwendungscode in Form von POJOs ist in verschiedenen
Laufzeitumgebungen leicht wiederverwendbar. (7)

Spring Boot
Spring Boot versucht die Spring Entwicklung zu vere infachen. Deswegen strebt
Spring Boot danach, so weit wie Spring zu reichen, im Sinne von Funktionalität. Spring Boot
bietet ein neues Paradigma für die reibungslose Ent wicklung von Spring Anwendungen. Mit
Spring Boot hat man die Möglichkeit Spring Anwendun gen mit mehr Agilität zu entwickeln
und sich gleichzeitig auf die Funktionalitäten der Anwendung, mit minimalem (oder
möglicherweise keinem) Gedenken an Spring selbst zu konfigurieren, konzentrieren zu
können. Eines der Hauptaufgaben von Spring Boot ist es in der Tat, Spring aus dem Weg zu
räumen, damit man wichtigere Sachen fertig bekommen kann.
Obwohl Spring im Sinne von Komponentencode leichtg ewichtig war, war es
schwergewichtig von der Konfiguration her. Am Anfan g musste man Spring in XML
konfigurieren (und ganz viel davon). Diese Probleme wurden später teilweise beseitigt, zum
Beispiel durch Komponenten-Scanning mit Hilfe von A nnotationen, welches einen großen
Teil der XML Konfiguration für die Komponenten entf ernte. Aber trotzdem bedeutete das
nicht, das man so nichts mehr konfigurieren musste.
Um einige Spring Features wie Spring MVC oder Tran saktionsmanagement
ermöglichen zu können, musste man explizite Konfigu rationsdateien schreiben, entweder in

11
XML oder Java. Für Funktionen von Drittanbietern ga lt dasselbe. Mit Spring Boot wurde das
alles geändert.
Nehmen wir als Beispiel eine einfache webbasierte „Hello World“-Anwendung. In
Spring müsste man dafür Spring MVC und Servlet API konfigurieren, eine web.xml Datei
haben, eine Projektstruktur, inklusive einer Maven oder Gradle Datei für Abhängigkeiten,
einen Controller der auf HTTP Requests mit „Hello W orld“ antwortet und einen
Webanwendungsserver wie Tomcat für das Deployment d er App. Was hier auffällt ist, dass
aus dieser Liste ein einziges Element für die Hello World-Funktionalität spezifisch ist: der
Controller. Alle anderen sind generische Dateien di e für jede Webanwendung, entwickelt mit
Spring, notwendig sind. Aber, wenn alle springbasie rte Webapplikationen diese Sachen
benötigen, warum müsste man das noch explizit zur V erfügung stellen?
Der Controller allein kann eine komplette (obwohl eine einfache) Springanwendung
sein:
@RestController
class HelloController {
@RequestMapping(‘‘/’’)
def hello() {
return ‘‘Hello World’’
}
}
Man braucht keine Konfiguration, keine web.xml, kei ne Buildspezifikation, nicht
einmal einen Anwendungsserver. Das ist die ganze An wendung. Spring Boot kümmert sich
selbst um die notwendige Logistik für die Ausführun g der App. Auf ähnlicher Weise macht
es Spring Boot möglich, durch Autowiring und Aspect Oriented Programming, sehr einfach,
schnell und effizient sich an einer Datenbank verbi nden zu können, Repositories bauen zu
können und REST Requests zu behandeln und zu defini eren. (8)

12
ORM und Persistenz
Hibernate
Seit vielen Jahren ist Persistenz ein heißes Thema in Diskussionen in der Java-
Gemeinde. Es gibt noch viele Unklarheiten. Ist das Thema schon durch relationelle
Technologie gelöst, oder muss es spezielle Java Tec hnologien dafür geben? Sollte man die
primitivsten Operationen wie CRUD (create, read, up date, delete) per Hand definieren oder
sollte das alles automatisiert werden? Wie kann man Portabilität erreichen wenn jedes
Datenbankmanagementsystem sein eigenes SQL Dialekt hat? Sollte man SQL komplett
abschaffen und eine unterschiedliche Datenbanktechn ologie sowie Objektdatenbanksysteme
fördern? Die Debatte ist noch lange nicht zu Ende, aber eine Lösung, die „object /relational
mapping“ (ORM) heißt, hat breite Zustimmung gefunde n. Hibernate ist eine open-source
ORM-Service Implementierung.
Hibernate ist ein ehrgeiziges Projekt, das als Zie l eine komplette Lösung zum
Problem des persistenten Datenmanagements in Java z u sein, hat. Es stellt die Verbindung
zwischen der Anwendung und der relationalen Datenba nk her, sodass der Entwickler auf das
gegebene Geschäftsproblem fokussiert bleiben kann. Hibernate ist eine nicht intrusive
Lösung. Man muss nicht allzu vielen Hibernate-spezi fischen Regeln und Design Patterns
folgen wenn man die persistenten Klassen und die Ge schäftslogik definiert. Deswegen
integriert sich Hibernate nahtlos sowohl in neuen, als auch in existierenden Projekten. (9)

JPA
JPA (Java Persistence API) hat als Ziel eine Stand ardisierung des Basis-API sowie
der Metadaten eines objektrelationalen Persistenzme chanismus für Java. Es ist hier aber nicht
die Rede über ein fertiges Framework, sondern um ei ne Spezifikation bei der Hibernate auch
als Entwickler eine Rolle spielt. JPA ist nicht nur für Geschäftsanwendungen, Java EE
gedacht, sondern auch für normale Java-SE-Anwendung en. Das Projekt hatte als Inspiration
andere Persistenzframeworks wie TopLink, Hibernate und JDO. Deswegen benutzt JPA auch
POJOs um die Entitäten darzustellen, wie Hibernate, weil es dieselben Prinzipien befolgt.
Um die Metadaten zu definieren verwendet man die in Java 5.0 neu hinzugefügten
Annotations, die direkt in den Entity-Klassen angeg eben werden. Man hat als Alternative
auch XML.

13
Entity-Klassen können konkrete oder abstrakte Java- Klassen sein. Es werden hierzu
Vererbung, polymorphe Assoziationen und polymorphe Abfragen unterstützt. Die
persistenzrelevanten Attribute können in den Klasse n durch Annotations mit Mapping- und
anderen Metadaten versehen werden. Für die Verwaltu ng der Entities ist ein Entity Manager
zuständig. Er stellt das API für den Zugriff auf ei nen Persistenzkontext bereit. Unter
Persistenzkontext versteht man eine Menge von Entit y-Objekten, in der jede Instanz einer
Datenbankentität höchstens ein entsprechendes Java- Objekt im Kontext hat. Ein Entity
Manager verwaltet immer genau einen Persistenzkonte xt.
JPA verfügt über mehrere Module und eines davon is t der „Hibernate Core“. Dieser
ist die Grundlage für alle Hibernate-Anwendungen. E r stellt verschiedene Schnittstellen für
die Konfiguration, die Transaktionen und die Sessio n bereit und wird vom Entity Manager
verwendet als Persistenz-Engine. (10)

Spring Data JPA
Mit Hilfe von Spring Data muss man keine DAOs (Data Access Object) mehr
implementieren, um die Verbindung zwischen Datenban kentitäten und Java-Objekte
herzustellen. Dazu muss aber unser Repository die J PA-spezifische „Repository“-
Schnittstelle erweitern und zwar die „JpaRepository “. Das ermöglicht dann Spring Data diese
Schnittstelle automatisch zu finden und für sie ein e Implementierung einzuspielen. (11)
Durch die Erweiterung dieser Schnittstelle stehen uns die wichtigsten CRUD-
Methoden für den Standard-Datenzugriff automatisch implementiert zur Verfügung. (11)

Benutzerdefinierte Methoden und Queries
Für personalisierte Zugriffsmethoden und Queries b ietet Spring JPA einige Optionen
an. Eine davon ist es, einfach eine neue Methode di rekt in der Schnittstelle, die uns als
Repository dient, zu definieren. (11)

Automatische Benutzerdefinierte Queries
Es gibt die Möglichkeit, automatische personalisie rte Queries zu schreiben. Wenn
Spring Data eine neue „Repository“-Implementierung erstellt analysiert es alle in der

14
Schnittstelle definierten Methoden und versucht aut omatisch aus den Methodennamen
Queries zu generieren. Das hat einige Einschränkung en, aber es ist eine sehr leistungsfähige
und elegante Art neue benutzerdefinierte Methoden, mit geringstem Entwicklereinsatz, zu
schreiben. (11)
Das wird auf folgender Weise getan. Sagen wir dass eine Entität das Feld „name“
besitzt (und die Java Bean Standardmethoden „getNam e“ und „setName“). Wir definieren die
„findByName“ Methode in unserer Repository, die aut omatisch die Attribute der Java Klasse
erkennt und ein korrektes Query selber erstellt:
public interface IFooDAO extends JpaRepository< Foo, Long >{
Foo findByName( String name ); (11)
}
Das ist ein sehr einfaches Beispiel, aber es wird eine sehr viel breitere Menge an
Schlüsselwörter vom Query-Creation-Mechanismus unte rstützt. (11)

Manuelle Benutzerdefinierte Queries
Durch die „@Query“ Annotation kann man selbst Quer ies definieren, direkt in der
Repositoryschnittstelle:
@Query(“SELECT f FROM Foo f WHERE LOWER(f.name) = L OWER(:name)”)
Foo retrieveByName(@Param(“name”) String name); (11 )

15
Front-End
Angular
• AngularJS, veröffentlicht 2009, ist die ursprünglic he Angular Version
• JavaScript Framework für dynamische Webanwendungen – keine Seitenneuladung
nötig – werden auch SPAs (Single Page Application) genannt
• beliebt für die Erstellung von Webseiten mit Widget s die in jedem Browser schnell
laufen
• ermöglicht Data Binding zwischen Modell und HTML ta gs
• Angular 2 entwickelt in 2009 und 2014
• Angular 4 veröffentlicht März 2017
• Angular 5 veröffentlicht November 2017
(12)

AngularJS wurde mit riesig großem Interesse empfang en, weil es ein tolles Werkzeug
zur schnellen Erstellung von Anwendungsprototypen w ar. Es war flexibel weil man die
HTML-Basis einer Seite benutzen konnte und zügig da rauf bilden konnte und es aus
statischem HTML in einer beweglichen, reaktionsfähi gen, attraktiven App umwandeln
konnte. (12)
Angular 2, 4 und 5 sind sehr ähnlich zueinander und alle unterschiedlich vom
ursprünglichen AngularJS. AngularJS läuft auf Webbr owsern und diese benötigen JavaScript,
deswegen ist JavaScript die Plattform für AngularJS und Angular. Ab Version 2 aber hat man
die Möglichkeit mit neuerem JavaScript und TypeScri pt zu arbeiten, einem Superset von
JavaScript.
TypeScript wurde von Microsoft entwickelt und dient dazu die Unterschiede
zwischen JavaScript und modernen strukturierten Spr achen, wie zum Beispiel Java oder C#,
zu überbrücken, seien das Strong Typing, Decorators , Enumerationen und so weiter. Der
Code wird danach in JavaScript umgewandelt um auf d en Browsern laufen zu können. (12)

Twitter Bootstrap
Bootstrap ist ein open-source Front-End-Framework z ur Erstellung reaktionsfähiger
Webseiten. Bootstraps Kombination von HTML, CSS und JavaScript macht es einfach
robuste Seiten zu bilden, ohne viel Code. Dank eine s vorgegebenen Netzsystems kann man
leicht Layouts basteln und das Styling der Buttons, Navigationselementen und Tabellen sieht

16
schon vom Anfang an durch minimales Anwenden von Bo otstrap toll aus. Durch das
Hinzufügen einiger JavaScript-Plugins hat man schon interaktive Elemente auf seiner Seite
fertig. (13)
Wenn man ein neues Projekt startet bietet Bootstrap gleich eine große Anzahl an
nützliche Werkzeuge an. Alles was man tun muss, ist die „bootstrap.css“ CSS-Datei und
optional die „bootstrap.js“ JavaScript-Datei auf de r Seite einzubeziehen und schon ist man
fertig. (13)

17
Implementierung – Backend
Projektstruktur
Obwohl die Anzeige in der Anwendung auf Deutsch ges taltet wurde, habe ich bei der
Implementierung Englisch benutzt, weil das die Stan dard Sprache für Programmierung ist.

Meine Projektstruktur sieht folgendermaßen aus:

Die Anwendung ist in 5 Paketen unterteilt, jede dav on spezialisiert sich auf das
Erfüllen einer bestimmten Rolle in der Anwendung. I ch werde sie vom „primitivsten“ zum
kompliziertesten kurz beschreiben.
Im Paket „model“ habe ich die verschiedenen Objekte definiert, die für meine App
notwendig sind, manche davon sind analog den Entitä ten aus der Datenbank. Darauf werde
ich später zurückkommen.
In „repository“ befinden sich alle Schnittstellen, die „JpaRepository“ erweitern und in
denen die notwendigen Funktionen für den Umgang mit Metadaten definiert sind.
Das Paket „service“ enthält alle Rest Services und ihre Schnittstellen. Diese rufen die
in den Repositories angegebenen Methoden auf und st ellen so die Verbindung zu den
Controllern bereit.
Alle Controller befinden sich im gleichnamigen Pake t. Die meisten sind
RestController, dessen Methoden auch über Links auf gerufen werden können, um auf sie
Zugriff vom Frontend zu haben. Hier gibt es auch di e Variantenbildung, eines der wichtigsten
Elemente meiner Arbeit.

18
In „init“ gibt es eine Klasse, welche die Anwendung zur Datenbank verbindet und
somit die für Spring Data JPA notwendigen Objekten zur Verfügung stellt. Hier werden
URL, Benutzernamen und Passwort für die Datenbank a ngegeben.
Die Datei „application.properties“ enthält wichtige Daten für das Deployment des
Servers, sowie Port (hier 9123) und Datenbank-Drive r.
„build.gradle“ ist der Ort wo Abhängigkeiten für da s Projekt, wie zum Beispiel Spring
Data JPA, Spring Rest, Hibernate und Super CSV defi niert werden, um importiert werden zu
können.
Spring Boot
Model – Entity
Wir fangen mit den Klassen aus dem Paket „model“ an . Um die Tabellen aus der
Datenbank in Java Objekten umwandeln zu können, bra uchen wir die Annotationen
„@Entity“ und „@Table“, damit Spring Boot das beim Generieren der Beans erkennen kann:

Der Tabellenname aus der Datenbank muss auch angege ben werden, damit das Java
Objekt zur richtigen Entität verbunden werden kann, in diesem Fall ist das
„DOC_DOCUMENT_FILE“.
Für jede Klasse wurden auch Getters, Setters, Konst ruktor und toString() definiert,
diese sind aber Standard und konnten schnell durch automatische Generierung erstellt
werden. Was aber hier noch zu tun bleibt, ist die G etters mit den Namen der Tabellenspalten
zu versehen, ähnlich wie die Klasse selbst, sodass auch die Spalten richtig zugeordnet
werden.

Der Primärschlüssel muss zusätzlich mit der Annotat ion „@Id“ versehen werden. Das
ist für jede solche Klasse verpflichtend, sonst wir d Spring einen Fehler werfen. Bei den
restlichen Objekten muss nur die „@Column“ Annotati on angegeben werden, zusammen mit
dem Namen der Spalte, in diesem Fall „PK_DOCUMENT_F ILE“. Da dieses Feld ein

19
Primärschlüssel ist muss das eindeutig sein (unique = true) und das darf nicht null sein
(nullable = false). Man kann das für jede beliebige Spalte angeben, jedoch reicht bei den
meisten nur der Name.
Repository
Alle Repositories sind einfache Schnittstellen die das im Spring Data JPA
verfügbaren „JpaRepository“ erweitern. Deswegen erf olgt das ganze Mapping und die DAO-
Erstellung für die Transaktionen und die Übertragun gen zwischen Anwendung und der
Oracle Datenbank automatisch. Wir müssen hier nicht s konfigurieren, sondern nur den
Objekttyp angeben (die entsprechende Klasse aus „mo del“) und die Art des Primärschlüssels.
Außerdem kann man nach Willen Methoden zur Suche un d Lieferung von bestimmten
Entitäten oder Listen von Entitäten nennen, ohne di ese implementieren zu müssen, falls sie
automatisch von JPA erkannt werden können.

In diesem Beispiel hat die Klasse „DocDocumentFile “ ein Attribut, das „documentId“
heißt und vom Typ java.util.Long ist. Darum kann ma n einfach eine Methode angeben, die
solche Entitäten nach einem bestimmten „documentId“ sucht und diese wird mit Hilfe von
JPA richtig implementiert. Man muss aber darauf ach ten, dass man solche Methoden genau
nach einer bestimmten Form schreibt, zum Beispiel „ findBy {Klassenattribut }({Attributtyp }
demoAttribut)“. JPA unterstützt viel mehrere solche Schlüsselwörter. Hier brauchte ich
beispielsweise eine Abfrage die mir die Entität lie fert, die eine bestimmte „documentId“-
Nummer besaß und bei der das Feld „revision_delete“ null war. In einem solchen Fall macht
es JPA möglich durch einfaches Schreiben von
„findBy {Klassenattribut }And {Klassenattribut2 }IsNull ({ Attributtyp } demoAttribut)“, das
gewünschte Ziel zu erreichen.
Um eine benutzerdefinierte Abfrage zu machen, habe ich in folgenden Beispielen
einige dank „@Query“ selbst definieren können.

20
Ich habe eine Methode benötigt, die alle Einheiten vom Typ „DocMetadata“ lieferte,
die einen bestimmten MetadatenTyp hatten und dessen „documentIds“ in einer Liste
enthalten waren. In der „@Query“ schreibt man eine einfache SQL-Abfrage, jedoch muss
man hier beachten dass man nicht den Tabellennamen sondern den Java-Klassennamen beim
„select“ angeben muss (DocMetadata). Mit Hilfe von „@Params“ kann man die Parameter,
die in der Abfrage mit „:“ vorgesehen sind, schnell und einfach bestimmen.

Diese Abfrage war erforderlich, um den größten Wer t aus einer Tabelle holen zu
können, dessen Entität aber auch ein bestimmtes „do cuIden“ hatte. Wie vorhin erklärt erfolgt
das leicht durch eine kurze SQL-Abfrage und die Ang abe der Parameter.
Controller
Ein RestController dient als Brücke zwischen dem F rontend und dem Backend, weil
er Rest-Anfragen abfangen kann. Um das zu tun brauc ht man dazu ausgedachte Methoden:

An dem mit „value“ bezeichneten Link wird man dies e Methode aufrufen können,
nachdem die Anwendung gestartet wurde. Man kann hie r interessanterweise Eingaben direkt
validieren (@Valid), indem man in der entsprechende n Klasse Validierungen implementiert.

Besondere Controller
Data Storage Controller

Es gibt ein Paar Dateien, XMLs und PDFs die der An wendung in der Datenbank
direkt zur Verfügung stehen, aber um die Metadaten für eine Dokumenten-ID-Nummer
herunterladen zu können, musste ich aus den unverar beiteten Datenbankeinträgen eine Datei
erzeugen. Dazu schienen CSV-Dateien (comma sepparat ed values) die beste Lösung. Diese
können beispielsweise mit Microsoft Excel geöffnet und bearbeitet werden.

21

Dazu habe ich „StatefulBeanToCsvBuilder“ aus der O pen-Source-Bibliothek
„OpenCSV“ angewendet. Mit Hilfe von diesem konnte i ch aus einer Liste von Metadaten ein
„ResponseEntity<byte[]>“ erzeugen, der von Spring a ngeboten wird und der von Webseiten
abgefangen werden kann. Ich habe zuerst eine Liste von „DocMetadata“ erstellt, indem ich
die entsprechende Methode aus dem „DocMetadataContr oller“ aufruft, die mir alle
Metadaten für eine Doc-ID-Nummer zurückliefert.
Abbildung 1
Danach habe ich einen „OutputStreamWriter“ definie rt, der die Daten an einem
„ByteArrayOutputStream“ weitergab. Der „StatefulBea nToCsvBuilder“ ist eigentlich dafür
ausgedacht, um die Daten direkt in einer lokalen Da tei auf dem Rechner zu speichern, aber so
konnte ich das vermeiden und die CSV-Datei in einer lokalen Variable („baos“)
aufzubewahren. Man gibt dem „StatefulBeanToCsvBuild er“, wie in der Abbildung zu sehen
ist, die Klasse an und wenn man die Funktion „write “ aufruft wandelt er automatisch die
Liste („ArrayList“) docMetadataList um. Danach kann man aus dem „baos“ ein Byte-Array
erzeugen und den benutzen um die Antwort der Method e in Form von
„ResponseEntity<byte[]>“ liefern zu können.
Abbildung 2
Man kann auch den Namen der Datei bestimmen, indem man im „Header“ vom Typ
„CONTENT_DISPOSITION“ den gewünschten Namen erzeugt , in meinem Fall wollte ich
die Dokumenten-ID-Nummer auch haben. Man muss hier außerdem auch die Endung für die
Datei angeben, für diese Datei also „.csv\“(END_CSV ).

22
Variant Builder
Die Implementierung der Variantenbildung war keine leichte Sache. Der Idee aus dem
Anfang des „Kapitel 2“ folgend musste ich mir eine technische Umsetzung für die
Variantenbildung ausdenken. In diesem Controller we rden viele Ressourcen und
Datenanbieter aus dem ganzen Projekt zusammengebrac ht und benutzt.
Wir fangen mit einer gültigen HKap-ID-Nummer an. D ann suchen wir alle
Bestelltypen die für das HKap gültig sind, indem wi r in der Tabelle „DOC_METADATA“
schauen. Hier sind alle Metadaten für eine Doku-ID- Nummer enthalten, wie zum Beispiel
Erstelldatum, Sprache und so weiter aber uns intere ssieren gerade nur die Einträge für die
Bestelltypen. Wir speichern nur die Werte die uns i nteressieren, also z.B. „9AAAA1“ und
„9ABBC1“.
Für diese Werte bestimmen wir aus der Tabelle „RED SYS_MODELRESTR“ die
gültigen Modelljahre, also für welche Jahre diese b estimmte Fahrzeugmodelle freigegeben
wurden. Diese werden in einem „Java-TreeSet“ gespei chert, sodass sie nach Jahr und
Bestelltyp sortiert bleiben. Sie werden unter Form von „ModelRestrHelper“ gespeichert,
einer Klasse die ich nur dazu definiert habe um die se sortieren zu können, weil sie aus all den
Daten nur das Jahr und den Bestelltyp behält und si e beim Überschreiben der Methode
„compareTo()“ benutzt. Deswegen können diese automa tisch im „TreeSet“ alphabetisch
sortiert bleiben.
Wir müssen nun eine Liste der einzelnen Modulen-ID -Nummern für das gegebene
HKap bereitstellen. Das tun wir indem wir in der Ta belle „DOC_RELATION“ nach den
„TARGET_IDs“ schauen, für die Einträge bei welchen „FK_RELATION_TYPE“ gleich 1
ist, weil das für die Beziehung HKap-Module so vorg eschrieben ist und die „SOURCE_ID“
die eigentliche HKap-Doku-ID ist. Zu dieser Liste f ügen wir auch die HKap-ID-Nummer
selbst hinzu.
Wir brauchen auch eine Liste mit „Model Restrictio ns“ für die einzelnen Module
auch, wie für das HKap am Anfang, also erstellen wi r diese auch, sodass wir schauen können
für welche Bestelltypen diese Module, aber auch das HKap, gültig sind. Wir speichern das
unter Form eines „SortedSetMultimap<Long, String>“, die uns ermöglicht für eine ID-
Nummer eine Liste von Strings zu haben, das heißt d ass jede ID nur einmal erscheinen wird
und die Bestelltypen werden in einer Liste gesammel t, also zum Beispiel „{80023123,
{9AAAA1, 9ABBC1}}“.
Dasselbe tun wir für die „ModelljahrAb“. Wir benut zen ein „HashMap<Long,
Long>“, finden alle Metadaten die den „Modelljahren Ab“ entsprechen, für die einzelnen

23
Module, inklusive HKap und erstellen daraus das Has hMap. Das könnte für eine ID
folgendermaßen aussehen: „{80023123, 2017}, {809922 45, 2018}“.
Wir haben nun alles was wir brauchen um den ersten wichtigen Schritt für die
Variantenbildung zu machen und zwar für welche Mode lljahr-Bestelltyp Kombinationen
welche Module gültig sind. Es muss also geprüft wer den, welche Daten aus der Liste der für
das HKap gültigen Bestelltypen und der entsprechend en Modelljahre auch mit den
Restriktionen für die einzelnen Module übereinstimm en.
Abbildung 1
Im „TreeSet<ModelRestr> yearsForOrderTypesForHKap“ haben wir die am Anfang
dieses Kapitels angesprochenen Bestelltypen und Mod elljahre für das gegebene HKap liegen,
beispielsweise „{9AAAA1, 2016}, {9AAAA1, 2017}, … , {9ABBC1, 2016}, …“. Wir wollen
eine Art Tabelle herstellen, in welcher diese Eleme nte die Schlüssel sind und die
Dokumenten-IDs, in Listen enthalten, die Werte. Des wegen benutzen wir erneut ein
„SortedSetMultimap“ der uns ermöglicht, jedes Mal w enn dieselbe Bestelltyp-Modelljahr
Kombination für eine neue ID vorkommt, die Liste de r IDs für dieses Element zu erweitern.
Wir gehen durch diese Liste und für jedes Element g ehen wir auch das
„SortedSetMultimap modelRestrForDocIds“ durch, das als Schlüssel die Dokumenten-ID
eines Moduls/HKaps hat und als Wert eine Liste von Strings mit den gültigen Bestelltypen.
Wir brauchen aber auch das „ModelljahrAb“ für jedes Element, um zu sehen ob das Modul in
diesem Fall gültig ist, also ob dieses Jahr größer als das Jahr aus
„yearsForOrderTypesForHkap“ ist. Das wird in Abbild ung 1 in der if-Klausel als Erstes
gemacht.
Wir müssen auch noch checken, ob dieses Modul für d en Bestelltyp aus
„yearsForOrderTypesForHkap“ freigegeben wurde. Das tun wir indem wir überprüfen, ob der
jetzige Bestelltyp aus „yearsForOrderTypesForHKap“ im entsprechenden Wert aus
„modelRestrForDocIds“ für die jetzige Dokumenten-ID , der eine Liste von Strings ist,
enthalten ist. Wenn diese zwei Bedingungen erfüllt sind können wir sicher sein dass das

24
Modul für die Bestelltyp-Modelljahr Kombination, be i der wir gerade sind, freigegeben
wurde und können das zur Liste von Modulen für dies e Kombination hinzufügen.
Es folgt nun der zweite und letzte wichtige Schrit t für die Bestimmung der Varianten,
das Umwandeln der Werte in Schlüssel und umgekehrt.
Abbildung 2.1
Abbildung 2.2
Für „variantsTableStep1“ waren die Jahr-Bestelltyp -Kombinationen die Schlüssel und
die Dokumenten-IDs die Werte (siehe Abbildung 1). D iesmal brauchen wir eine Map die
genau andersrum definiert ist, weil Varianten so ge baut und ausgedacht sind (siehe
Abbildung 1, erste Zeile). Man muss die verschieden en Varianten eines Dokumentes
bestimmen können und ein Dokument ist aus HKap und Module gebaut. Deswegen macht es
Sinn zu sehen, für welche Fahrzeuge eine bestimmte Dokumentenvariante gültig ist, sodass
man schauen kann warum beispielweise für ein Paname ra aus 2016 ein Dokument fehlt.
Wir gehen durch die vorher erstellte Liste und füg en bei jedem Element sein Wert,
also die Dokumenten-ID Liste als Schlüssel und dess en Schlüssel als Wert in die neue Liste
hinzu und entfernen so auch die möglicherweise im e rsten Schritt entstandenen Duplikate,
weil die Schlüssel eindeutig sein müssen.
…..Varianten noch nicht im „model“ definiert, va continua……

25
Implementierung – Frontend
Für das Frontend habe ich, wie im Kapitel „Technolo gien“ erwähnt, Angular 5
verwendet, zusammen mit Bootstrap für das Styling d er Buttons und Tabellen.

ng
ngModel
Abbildung 1
Für das Anbinden der HTML Elemente an den Attribute n aus Typescript habe ich
„ngModel“ verwendet, welches den Wert aus einem Inp ut beispielsweise direkt an eine
Variable übertragt und somit ist die Verarbeitung d er eingegebenen Daten viel einfacher.
Abbildung 2
Abbildung 1 zeigt ein DOM-Element aus dem HTML der Home Seite, welches die
Eingabe eines Textes zulässt. Mit Hilfe von „ngMode l“ kann man diese Eingabe direkt an der
Variablen „queryString“ aus Abbildung 2 anbinden, d ie im „home.component.ts“ definiert
wurde. So kann man des Weiteren diese Variable dire kt benutzen, um Backend Abfragen für
die Metadaten oder die Variantenbildung zu machen.
ngFor
Abbildung 3
Die Liste von Modulen, „modulesFromDocRelation“, a us Abbildung 3 wurde im
„home.component.ts“ definiert und sie wird nach dem Suchen nach einer HKap geladen.
Dank „*ngFor“ ist es danach sehr einfach eine Tabel le mit diesen Werten zu befüllen, indem
man für jedes Element der Liste die gewünschten Att ribute je einer Tabellenzelle zuweist,
hier als Beispiel das Attribut „targetId“.
Backend Service
Im „backend.service.ts“ befindet sich die ganze Ve rbindung zum Spring Boot
Backend. Hier wird der Link zu den Backend REST Cal ls angegeben, für mich

26
„http://localhost:9123/“, der dann benutzt wird um die verschiedenen Funktionalitäten der
Controller aufrufen zu können. In unserem Fall hat man die Möglichkeit das „ModelljahrAb“
für ein HKap zu verlangen, die verschiedenen Module für ein HKap zu laden und dessen
Bestelltypen zu bestimmen. All diese Methoden werde n von der Home Seite aufgerufen, die
Antworten werden in Objekte umgewandelt und wie vor hin erklärt, mit Hilfe von „ngFor“ in
HTML-Form dargestellt.

……weitere Erklärungen zum Frontend nachdem es f ertig ist…..

27
Bedienungsanleitung

Abbildung 1

In Abbildung 1 ist die Home Seite der Anwendung zu sehen. Man kann nach einer
HKap-ID suchen und die verschiedenen Dateien für da s HKap und seine Module
herunterladen, seien es gleich die Metadaten aus de r Tabelle „DOC_METADATA“, die
aktuellsten Dateien aus „TBL_PUBL_DOCU_HIST“ oder d ie letzte Version der XML oder
PDF aus „DOC_DOCUMENT_FILE“. Man kann in der „Detai lansicht“ schnell das
Modelljahr ab für unser HKap, aber auch die freigeg ebenen oder nicht freigegebenen (mit rot
markiert) Bestelltypen ablesen, um so auf einem Bli ck schon sagen zu können warum für
eine HkapID etwas fehlt.

Abbildung 2

28
Wie in Abbildung 2 ersichtlich, kann man für die v erschiedenen Varianten eines
Dokumentes die enthaltenen Module auf die Schnelle erblicken und dazu noch im Detail die
enthaltenen Baureihen, Bestelltypen und Modelljahre für die es die Variante gibt, aber auch
durchgestrichen die, für welche das Fahrzeug noch n icht freigegeben wurde.

Abbildung 3
Im letzten Teil der Webseite hat man die Möglichke it auch für alle Versionen eines
Dokumentes, die sich im Laufe der Zeit ändern und a ktualisiert werden, eine Detailansicht
mit mehreren Infos über die für das Dokument freige gebenen Fahrzeuge zu sehen. Außerdem
kann man für all diese Dokumente die entsprechenden Dateien herunterladen, von der
Entstehung des Dokuments, „Meta“, bis zum endgültig en Produkt, die XML oder PDF Datei.

….Die Bilder werden durch Bilder aus der Webseite ersetzt sobald das Frontend fertig ist…..

29
Future Work
Authentifizierung
Die Anwendung könnte durch ein Authentifizierungsme chanismus vielfach verbessert
werden. Das war aber für ein Prototyp nicht der Fal l, weil die Authentifizierung für Porsche
Systeme mit Zertifikaten und Cookies erfolgt, die v om Zentralsystem abhängig sind.
Echtzeit Aktualisierungen
Da Dokumente für Fahrzeuge ständig publiziert und g eändert werden, wäre es
nützlich ein observer-basiertes System zu haben, we lches automatisch Echtzeit-Änderungen
zu den Dokumenten oder der Datenbank in der Benutze roberfläche sichtbar macht.

30
Literaturverzeichnis
1. Doar, Matthew. Practical Development Environments. s.l. : O'Reilly Media, 2005.
2. Bunse, Christian. Freie Universität Berlin Arbeitsgruppe Software En gineering. Freie Universität Berlin
Webseite. [Online] 3. Juli 2008. http://www.inf.fu-berlin.de/ inst/ag-se/teaching/S-
BSE/116_bunse_buildwerkzeuge.pdf.
3. Grund, Raphael und Kirchev, Ivan. RWTH Aachen Fachgruppe Informatik. RWTH Aachen Webseite.
[Online] https://verify.rwth-aachen.de/proseminar/P K17/ausarbeitungen/build_systeme.pdf.
4. Horn, Torsten. www.torsten-horn.de. www.torsten-horn.de. [Online] 2015. www.torsten-horn.de.
5. Tim Berglund, Matthew McCullough. Building and Testing with Gradle. s.l. : O'Reilly Media, 2011.
6. Baeldung. Baeldung – Ant vs Maven vs Gradle. Baeldung. [Online] 1. Januar 2018.
http://www.baeldung.com/ant-maven-gradle.
7. Johnson, Rod, et al. Professional Java Development with the Spring Frame work. s.l. : John Wiley & Sons,
2005. ISBN:0764574833.
8. Walls, Craig. Spring Boot in Action. s.l. : Manning Publications, 2016. ISBN 97816172925 45.
9. Bauer, Christian und King, Gavin. Java Persistence with Hibernate. s.l. : Manning Publications, 2007.
ISBN 1-932394-88-5.
10. Roeder, Daniel. JPA mit Hibernate – Java Persistence API in der Pra xis. s.l. : entwickler.press, 2010.
ISBN: 978-3-86802-240-7.
11. Baeldung. Baeldung – Introduction to Spring Data JPA. Baeldung. [Online] 15. April 2018.
http://www.baeldung.com/the-persistence-layer-with- spring-data-jpa.
12. Clow, Mark. Angular 5 Projects. s.l. : Apress Media, 2018. ISBN-13 (electronic): 97 8-1-4842-3279-8.
13. Spurlock, Jake. Bootstrap. s.l. : O’Reilly Media, 2013. ISBN: 978-1-449-34391- 0.