Exposé-Template: Vor der Bearbeitung füllen Sie bitte folgendes Exposé aus und stimmen es mit mir ab: Exposé-Template
Betreuung der Arbeit: Für alle Abschlussarbeiten vereinbare ich mit den Studierenden ein 2-wöchentliches Statusgespräch. Dies gilt auch für die vorbereitenden Praxisprojekte für die Bachelorarbeit. Diese Termine sind zweiwöchentlich immer zur gleichen Uhrzeit am gleichen Tag.
Angebote für Masterarbeiten
In Fortsetzung einer Bachelorarbeit zum gleichen Thema sollen in dieser Arbeit gebräuchliche und für die Softwaretechnik verfügbare UML-Tools bezüglich ihrer Eignung für die Lehre untersucht und verglichen werden. Der Fokus soll dabei auf User Experience und funktionaler Vollständigkeit liegen. Die Untersuchung soll empirische Methoden nutzen und so breit angelegt sein, dass das Ergebnis für die allgemeine Softwaretechnik-Hochschullehre anwendbar ist.
Die Lehr-/Lernplattform ArchiLab versucht, ein umfassendes Angebot für das Erlernen von Softwarearchitektur zu machen. Für die Weiterentwicklung des Selbsttest-/Quizmoduls soll diese Arbeit Möglichkeiten definieren, auch die höheren Taxonomiestufen 3-5 der Revised Bloom’s Taxonomy online zu prüfen. Dies sind „Apply“, „Analyze“ und „Evaluate“. Ein einfaches Abfragen von Wissen genügt hier nicht mehr.
Nichts gefunden?
Ich betreue natürlich nicht nur die oben aufgeführten Themen. Kontaktieren Sie mich gern direkt, wenn Sie …
- eine eigene Idee für eine Abschlussarbeit haben, die thematisch zu meiner fachlichen Ausrichtung passt, oder
- noch keine Idee für eine Arbeit haben, aber gern in Richtung Architektur, EAM oder Agilität arbeiten möchten, oder
- einen potentiellen Projektpartner (Firma) haben, aber noch nicht genau wissen, wie eine in Kooperation betreute Arbeit aussehen könnte.
Im Gespräch können wir dann unverbindlich Optionen und/oder mögliche weitere Themen ausloten.
Laufende oder abgeschlossene Arbeiten
Eine der ersten Phasen in Softwareentwicklungsprojekten und somit die Grundlage für zu entwickelnde Softwaresysteme, stellt der Domänenschnitt und die Komponentenbildung dar. Diverse Autoren beschreiben Ansätze und Patterns für verschiedene Domänen und Architekturstile. Zudem haben viele Unternehmen eigene Ansätze entwickelt, welche sie in ihren Kundenprojekten nutzen. Im Projektalltag ist es aber nicht immer möglich, diesen Ansätzen und Patterns zu folgen. Somit ergeben sich Unterschiede zwischen den dokumentierten Vorgehen und den realen Prozessen in Projekten. Die Arbeit geht diesen Unterschieden nach und versucht eine Systematisierung.
Problemstellung
In der Entwicklung von größeren objektorientieren Softwareprodukten entstehen zumeist eine Vielzahl von Utility- und Helperklassen sowie Methoden in weiteren Klassen verschiedener Schichten, die bestimmte Aspekte der Fachlichkeit wie zum Beispiel Validierung oder Konvertierungen behandeln und in unterschiedlichsten Paketen zu finden sind. Dies führt zu doppeltem Code, da die Codestücke anderen Entwicklern nicht bekannt sind und schwierig gefunden werden. Vor allem spätere Änderungen der Fachlichkeit führen zu Mehraufwand, da diese an mehrere Stellen verteilt ist und erstmal gefunden werden muss. Manchmal fallen diese Probleme erst in späten Testphasen oder gar im Produktionsbetrieb auf, das zu weiteren Problemen führt. Zudem sind auch die APIs und Konstruktoren durch eine Aneinanderreihung von nativen Datentypen fehleranfällig, schlecht les- und wartbar. Dem Code fehlt eine Robustheit, die sich vor allem bemerkbar macht, sobald Entwickler die Projekte verlassen oder neu hinzukommen, die sich im spezifischen Projekt nicht auskennen.
Abgeleitete Forschungsfrage
- Wie kann die vorhandene Fachlichkeit im Code so positioniert werden, dass ein sprechendes Domain Model entsteht und von Entwicklern schneller gefunden und besser verstanden wird?
- Warum lohnt es sich, auch native Attribute in Entitäten als vollwertige fachliche Klassen auszumodellieren?
- Welche Probleme treten bei der Umsetzung in JavaEE-Frameworks auf? Wie können diese gelöst werden?
Vorgehen
Zuerst werden an Hand einer Literaturrecherche die wichtigsten Aspekte des DomainDrivenDesigns mit Prinzipien der Softwareentwicklung (Objektorientierung, Clean Code, Design Patterns, Refactoring) in Verbindung gebracht. Dabei wird besonderen Wert auf Fachlichkeit an der richtigen Stelle, lesbaren Code und Auffindbarkeit gelegt.
Anschließend werden diese Eigenschaften als Anforderungen an ein auf JavaEE-basierendes Framework gestellt. Dabei steht besonders JPA und EJB als Backend, sowie JSF als Frontend im Fokus. Dabei werden auch Negativbeispiele herkömmlicher Programmierung aufgezeigt. Insgesamt wird ein Framework für Rich Domain Models entworfen, welches für eine erhebliche Reduzierung von Utility-Klassen und eine bessere Auffindbarkeit der Fachlichkeit sorgt.
Danach wird das Framework mittels Praxisbeispiele entwickelt und deren Funktionalitäten gezeigt. Abschließend findet noch eine Handlungs- und Einsatzempfehlung des entstandenen Frameworks im Vergleich zur herkömmlichen Programmierung statt.
Bearbeiter
Daniel Janßen
Abgabe
Ende 2017
Die Arbeit untersucht aus Usability-Sicht, wie komplex es sich gestaltet, auf verschiedenen Plattformen, insbesondere PC und MacOS, das gleiche „Look-And-Feel“ zu erreichen. Hierfür wird die Plattform Electron genauer analysiert. Aus Entwicklersicht soll untersucht werden, wie kompatibel Electron mit bestehenden Javascript-Bibliotheken sowie bestehenden Programmstücken in anderen Sprachen ist. Außerdem soll geprüft werden, ob und in welchem Maß plattformspezifischer Code erforderlich ist.
Collaborative Enterprise Architecture kombiniert TOGAF ADM mit der agilen Methodik KANBAN. Im Rahmen einer Einzelfallstudie soll anhand eines konkreten IT Projektes die Anwendbarkeit dieses Ansatzes untersucht und überprüft werden. Ziel ist es, alle Phasen des Collaborative-Enterprise-Architecture-Modells zu durchlaufen und wiederverwendbare Artefakte zu generieren. Die Arbeit wurde im September 2016 abgeschlossen.
