Veröffentlicht: von

Problemstellung

Die Entwicklung von Cross-Plattform Anwendungen stellt, insbesondere für kleine Unternehmen, noch immer eine große Herausforderung dar: Gewöhnlich wird zur Umsetzung C++ und etablierte Bibliothekslösungen wie Qt genutzt. Aus wirtschaftlicher Sicht kann dies eine große Herausforderung darstellen, da die Verfügbarkeit von erfahrenen C++-Entwicklern im Vergleich zu etwa erfahrenen JavaScript-Entwicklern deutlich geringer ist, durch das geringe Angebot jedoch auch die Gehälter für diese Entwickler oft sehr hoch sind. Ähnlich verhält es sich mir C++-Cross-Plattform-Bibliotheken, die entweder wie Qt für eine kommerzielle Verwendung lizensiert  werden müssen, oder im Falle von freien Bibliotheken wie GTK++ oft veraltet sind und keine moderne User Experience bieten.

Electron soll dieses Problem lösen: Durch die Chromium-Engine, Node.js und V8 ist man in der Lage mittels JavaScript, CSS und HTML Desktop-Anwendungen mit Plattform-übergreifend gleicher Funktonalität sowie Aussehen zu erstellen. Die Entwicklung mit Javascript ist aus den oben angeführten Gründen auch aus wirtschaftlicher Sicht interessant. Ebenso ist Electron aus Usability-Gründen interessant, da durch die Verwendbarkeit populärer JavaScript-Bibliotheken eine zeitgemäße und von Web-Anwendungen vertraute User-Experience geschaffen werden kann. Letztlich besteht auch die Möglichkeit eine mit Electron umgesetzte Anwendung als Browser-basierte Web-Anwednung verfügbar zu machen, oder gar auf dieser Grundlage eine Mobile-Variante zu entwickeln.

Durch die relative Neuheit der Technologie sind bisher größtenteils Anwendungen mit nur geringem Funktionsumfang umgesetzt worden. Die wenigsten haben eine höherwertige grafische Aufmachung und basieren auf wenig rechenintensiven Operationen. In der Arbeit soll geklärt werden, inwiefern sich Electron zur Umsetzung von komplexen Anwendungen eignet.

Unter dieser Definition werden Anwendungen verstanden, die auf großen Mengen komplex aufgebauten, voneinander abhängigen Daten operieren. Diese sollten grafisch ansprechend präsentiert werden und für den Nutzer intuitiv und schnell erfassbar sowie veränderbar sein. Dabei muss der Nutzer immer unmittelbares Feedback auf seine Aktionen erhalten, Ladezeiten sollten minimal sein und Animationen bzw. die Bildwiederholungsraten müssen flüssig sein. Eine weitere Konkretisierung sowie Quantifizierung der genannten Merkmale wird Teil der Arbeit sein.

Weitere zu untersuchende Aspekte sind die folgenden:

  • Aus Usability-Sicht soll untersucht werden, wie komplex es sich gestaltet, auf verschiedenen Plattformen, insbesondere PC und MacOS, tatsächlich das gleiche „Look-And-Feel“ zu erreichen.
  • 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.

Durch die Nutzung von Webtechnologien zur Umsetzung von Anwendungen und Chromium zur Darstellung soll auch untersucht werden, wie komplex sich die Portierung einer Electron-Anwendung als Web-Anwendung gestaltet. Dies ist besonders aus wirtschaftlicher Sicht interessant, um neue Anwendergruppen zu erreichen.

Für viele Electron-Projekte existierte bereits eine Vorlage in Form einer Web-Anwendung: Der umgekehrte Weg, eine Web-Anwendung aus einer bestehenden Electron-Anwendung zu entwickeln wurde, wenn überhaupt, nur selten gegangen. Inwiefern und unter welchen Umständen eine solche Herangehensweise sinnvoll und machbar ist soll ein weiterer zentraler Punkt der Arbeit sein.

Abgeleitete Forschungsfrage

Zusammenfasssend lässt sich die Forschungsfrage der Arbeit wie folgt zusammenfassen:

  • Ist es möglich, unter den oben genannten Definition als komplex geltende Anwendungen mit Electron umzusetzen?
  • Welche Vor- und Nachteile bietet Electron gegenüber anderen Möglichkeiten und worauf muss bei der Entwicklung mit Electron geachtet werden?

Vorgehen

Es muss ein Anforderungskatalog erstellt werden, der klar und verständlich zusammenfasst, welche Anforderungen an eine komplexe Software mit den weiter oben beschriebenen Merkmalen gestellt werden. Aufgrund dieser Anforderungen sollen typische Komponenten, wie beispielweise interaktive Textfelder oder interaktive Flowcharts, bestimmt werden. Diese sollen später zur  praktischen Überprüfung umgesetzt werden. Zunächst werden jedoch die Vor- und Nachteile sowie besondere Merkmale von Electron herausgearbeitet, sowie möglicher Alternativen vorgestellt und vergleichen. Zum Vergleichen der Alternativen mit Electron werden neben der Umsetzbarkeit der vorher als notwendig definierten Komponenten auch wirtschaftliche und nutzer- sowie entwicklerseitige Anliegen herangezogen.

Schließlich werden ein oder mehrere Proof-Of-Concepts zur Umsetzung der definierten Komponenten erstellt. Dazu werden Komponenten gewählt die in Software Articy:draft verwendet werden, die durch das Erfüllen der genannten Anforderungen an eine komplexe Software  als Praxisbeispiel dient. Nach der Umsetzung der Proof-of-Concepts soll durch eine praktische Umsetzung abgeschätzt werden wie komplex sich die Portierung als Web-Anwendung gestaltet. Weiterhin soll die Portierung auf mobile Geräte erprobt werden und abgeschätzt werden, ob eine Anpassung unter wirtschaftlichen sowie entwicklungstechnischen Gesichtspunkten anstatt einer kompletten Neuentwicklung zu rechtfertigen ist.

Externer Kooperationspartner

Articy Software GmbH

Bearbeiter

Jonas Frenz

Abgabe

Ende 2017

Veröffentlicht: von

Problemstellung

Durch die stetig steigende Komplexität von Softwaresystemen und den damit verbundenen hohen und umfangreichen Kundenanforderungen im Bereich der funktionalen als auch nicht-funktionalen Anforderungen kann die Wahl einer geeigneten Architekturform erfolgsentscheidend für ein Projekt sein. Hierbei können die Ausprägungen der nicht-funktionalen Anforderungen, wie Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Wartbarkeit, Übertragbarkeit, als Anhaltspunkt für die passende Architektur dienen. Außerdem können die Anforderungen Ausschlag für die zu verwendenen Strukturen, Komponenten, Bibliotheken und Frameworks bei der Entwicklung geben.
Bei der Planung von JavaScript Web Applikation müssen diverse Entscheidungen früh im Projekt getroffen werden und wirken sich nachhaltig auf die Qualität der entwickelten Applikation aus. Die Entscheidungen betreffen zum einen die Frage, ob eine Client- oder Serverseitige-Architektur in Frage kommt und welchen internen Aufbau (Single-Page- oder Multi-Page-Applikation) der Client aufweisen soll. Darüber hinaus müssen passende JavaScript-Frameworks ausgewählt werden, um die gestellten Anforderungen möglichst einfach und kostengünstig umsetzen zu können.

Im Rahmen der Masterarbeit sollen daher bestehende Architekturmuster für JavaScript Web Applikationen betrachtet und miteinander verglichen werden. Des Weiteren sollen bestehende JavaScript Clients analysiert werden, um Gemeinsamkeiten in der Umsetzung der zugrunde liegenden Aufgabe und wiederkehrende Problemstellungen aufzudecken. Auf diese Weise soll eine Sammlung von Best-Practices für die Erstellung von JavaScript Clients herausgearbeitet werden.  Auf Grundlage der daraus gewonnen Erkenntnisse soll letztendlich eine Referenzarchitektur entstehen, die als Orientierungshilfe für die zu treffenden Architekturentscheidungen dient.

Abgeleitete Forschungsfrage

  • Welche typischen Aufgaben bestehen bei der Implementierung von JavaScript Clients und welches JavaScript-Framework eignet sich für welche Problemstellung?
  • Welche erprobten Architekturmuster existieren für JavaScript Clients und wie sieht deren Umsetzung in der Praxis aus?
  • Wie lässt sich eine Referenzarchitektur für JavaScript Clients definieren und wie sieht deren Umsetzung aus?

Vorgehen

Die erste Phase der Masterarbeit sieht die Einarbeitung in die Thematik vor. Dabei erfolgt die Auseinandersetzung mit der entsprechenden Fachliteratur im Bereich von bestehenden Architekturmustern, wie die Serviceorientierte Architektur (SOA), die Resource-oriented Client Architektur (ROCA) und die Qualitätssoftwarearchitektur (Quasar). Des Weiteren werden verschiedene Formen von Softwarearchitekturen bei JavaScript Web Apps betrachtet. Dabei liegt der Fokus auf den Unterschieden von Single-Page-, Multi-Page- sowie Echtzeitwebapplikationen und dem in diesem Zusammenhang eingesetzten Model-View-Controller-Pattern. Darüber hinaus werden verschiedene JavaScript-Frameworks untersucht, wobei sich die Auswahl der jeweiligen Frameworks hierbei an Frameworks, die bei Capgemini aktiv zum Einsatz kommen, orientiert.

Die zweite Phase befasst sich mit der Untersuchung von Architekturmustern und deren Umsetzung bei JavaScript Clients in der Praxis. Hierbei sollen Open Source Applikationen auf wiederkehrende Architekturmuster hin analysiert werden, um herauszufinden, welche typischen, wiederkehrenden Aufgaben bei der Erstellung von Clients existieren und wie diese durch den Einsatz von JavaScript-Frameworks unterstützt werden.

In der dritten Phase soll aus den zuvor gesammelten Analyseergebnissen eine Referenzarchitektur für JavaScript Clients erstellt werden. Dazu sollen die für eine Referenzarchitektur notwendigen Konventionen herausgearbeitet werden. Anschließend sollen, auf Grundlage dessen, die Definition einer Referenzarchitektur und eine abschließende praktische, exemplarische Anwendung der Referenzarchitektur an verschiedenen JavaScript-Frameworks erfolgen.

In der letzten Phase erfolgen die Ergebnissicherung und die wissenschaftliche Aufbereitung dessen in Form der Masterarbeit.

Externer Kooperationspartner

Capgemini Köln

Bearbeiter

Sebastian Domke

Abgabe

Ende 2017

Veröffentlicht: von

Problemstellung

In vielen Unternehmen werden Konfigurationsdateien verwendet, um Softwaremodule für ihren projektspezifischen Einsatz anzupassen. Das Erstellen von Konfigurationsdateien kann komplex sein und dadurch viel Zeit in Anspruch nehmen. Aus diesem Grund bietet es sich an, den Entwicklungsprozess durch Editoren zu unterstützen.

Die Konfigurationsdateien sind in der Regel unternehmensspezifisch. Das kann dazu führen, dass es notwendig wird, einen unternehmensspezifischen Editor zu erstellen, der die speziellen Anforderungen seines Einsatzkontextes abdeckt.

Die Arbeit soll sich mit einer Technologieauswahl für einen unternehmensspezifischen grafischen Editor befassen. Diese soll mittels eines Proof-of-Concept der kritischen,  unternehmensspezifischen Anforderungen an einen solchen Editor überprüft werden. Dabei soll insbesondere die Frage geklärt werden, ob (und wenn ja, wie) trotz der speziellen Anforderungen grafische Standard-Frameworks zum Einsatz kommen können, um die Entwicklungskosten zu minimieren.

Als Untersuchungsgegenstand dient das Anlagenvisualisierungsystem UniWare, mit dem der Materialfluss und Zustand der Anlagensteuerung eines Logistiksystems überwacht werden kann. Der zu erstellende Editor dient dazu, Uniware-Anlagenmodelle zu erstellen.

Abgeleitete Forschungsfrage

  • Welche Technologie bietet sich an, um einen grafischen Editor für Anlagemodelle zu realisieren? Ist eine Eigenentwicklung nötig, oder können Standard-Frameworks verwendet werden?
  • Welche Kompromisse ergeben sich durch Standard-Frameworks, und wie kann man deren Auswirkungen minimieren?

Vorgehen

Die Arbeit soll in drei Phasen unterteilt werden.

  1. Marktstudie: In der ersten Phase werden die kritischen Anforderungen an einen solchen grafischen Editor aufgestellt. Mit diesen Kriterien wird der Markt auf mögliche grafische Frameworks untersucht, mit deren Hilfe die Anforderungen von Unitechnik an einen grafischen Editor umgesetzt werden können.
  2. Make-or-Buy-Entscheidung: In der zweiten Phase soll auf der Basis der Marktstudie eine Technologieauswahl durchgeführt werden, die sich entweder für eine Eigenentwicklung oder die Realisierung mit einem Standard-Framework entscheidet. Für die Entscheidung wird ein Kosten-Nutzen-Kriteriensystem aufgestellt, gemäß dessen die Alternativen bewertet werden.
  3. Lösungsarchitektur und Proof-of-Concept: In der dritten Phase werden erfolgskritische Anforderungen ausgewählt und die Eignung der ausgewählten Technologie durch einen Prototypen überprüft. Auf Basis dieser Prüfung wird die Technologieauswahl noch einmal abschließend bewertet.

Externer Kooperationspartner

Unitechnik Systems GmbH

Bearbeiter

Florian Bornes

Abgabe

August 2017

Veröffentlicht: von

Problemstellung

Es gibt derzeit verschiedene Cloudanbieter sogenannter „Serverlessdienste“. Durch Nutzen dieser Dienste begibt man sich in eine gewisse Abhängigkeit des Anbieters. Ungeklärt ist jedoch, wie stark eine solche Abhängigkeit tatsächlich ist und mit welchem Aufwand eine Migration zu einem anderen Anbieter verbunden ist. Des Weiteren stellt sich in diesem Zusammenhang die Frage, ob man eine Serverlessarchitektur von vorne herein so planen kann, dass diese möglichst anbieterunabhängig ist bzw. mit möglichst minimalem Aufwand eine Migration durchgeführt werden kann. Dieses Problem soll exemplarisch am Projekt „OC|Expo-Experience“ untersucht werden. Das Projekt wurde in der AWS-Cloud entwickelt, als Vergleichsanbieter soll Microsoft Azure genutzt werden. Der Vergleich beschränkt sich hierbei auf die im Projekt verwendeten Dienste (API-Gateway, Lambda, DynamoDB und Cognito).

Abgeleitete Forschungsfrage

  • Wodurch unterscheiden sich die Serverlessdienste, insbesondere „Lambda“ von AWS und „Functions“ von Microsoft Azure, voneinander?
  • Ist ein Umzug von AWS nach Azure möglich? Wenn ja wie und mit welchem Aufwand? (am Bsp. von OC|Expo-Experience)
  • Wie kann man die Architektur von vorne herein so planen, dass diese möglichst anbieterunabhängig ist?
  • Wie stark (und warum) ist man bei Verwendung der o.g. Dienste an AWS gebunden?

Vorgehen

Zunächst einmal sollen die zentralen Dienste bei AWS und Azure miteinander verglichen werden, um zu ermitteln ob eine äquivalente Verwendung, und wenn ja wie, möglich ist.

Nach dieser ersten Recherche soll für das Projekt OC|Expo-Experience ermittelt und dokumentiert werden, welche Schritte bzw. Anpassungen für eine Migration nötig sind und welchen Aufwand dies (qualitativ) bedeutet. Für das „worst-case“-Szenario, dass ein Umzug nicht oder nur mit erheblichem Aufwand möglich ist, wird dies nachvollziehbar und begründet dokumentiert.

Auf Basis dieser Erkenntnisse sollen dann „good practices“ entwickelt werden, wie man von Beginn an eine möglichst hohe Anbieterunabhängigkeit erreichen kann.

Abschließend kann dann die Frage beantwortet werden, wie stark man sich unter Verwendung der o.g. Services an Amazon bindet.

Projektpartner

Opitz Consulting GmbH

Bearbeiter

Jannik Blähser

Abgabe

August 2017

Veröffentlicht: von

Problemstellung

Die Notwendigkeit zur schnellen, häufigen, unkomplizierten und fehlerfreien Auslieferung von agil entwickelter Software lässt sich aus den Prinzipien des „Agile Manifesto“ ableiten. Continuous Delivery ist dafür in der „klassischen Softwareentwicklung“, wie der Entwicklung einer Desktopanwendung oder einer Webseite, ein hinreichend bekannter und häufig angewandter Prozess.

Auf SaaS Plattformen ist häufig auch ein agiler Entwicklungsprozess gewünscht, denn die Vorteile gelten auf solchen Plattformen ebenso. z.B. verringern sich die Time-to-Market Zeiten für neue Features. Auch hier können die Feedback Loops helfen, schneller bessere Software, die genau die Anforderungen des Business erfüllt, zu entwickeln und bereitzustellen.

In Salesforce, als Vertreter einer SaaS Plattform, kann die Entwicklung und das Testen von der produktiven Umgebung getrennt stattfinden. Dafür stehen sog. Sandboxen zur Verfügung. Zur Übertragung der Änderungen zwischen den verschiedenen Umgebungen stehen mehrere Möglichkeiten zur Verfügung. Zum einen die manuelle Übertragung, die Übertragung per „Change Sets“, bei denen die Änderungen per Klick im UI zusammengefasst und dann übertragen werden, als auch die Übertragung per API. Jedoch können, laut Salesforce, nicht alle Änderungen übertragen werden. Dies betrifft z.B. bestimmten Einstellungen und „Konfigurationsdaten“.

Die Nutzung des API und Einbindung in einen Continuous Integration Server ist möglich. Salesforce selber stellt ein Tool bereit, mit dessen Hilfe das API verwendet werden kann. Auch werben Drittanbieter damit, Continuous Integration / Continuous Delivery zu unterstützen. Alle nutzen jedoch das gleiche API. Jegliche Einschränkungen des API betreffen somit grundsätzlich alle Anbieter bzw. Lösungen. Die automatisierte Übertragung von fast allen Metadaten ist damit möglich, jedoch werden bestimmte Einstellungen und Daten auch von diesen Anbietern nicht übertragen.

 Abgeleitete Forschungsfrage

  • Lässt sich ein Continuous Delivery Prozess auf die Salesforce Cloud Plattform anwenden bzw. umsetzten, wenn ja, wie?
  • Ist es für einen Continuous Delivery Prozess auf der Salesforce Plattform relevant, dass bestimmte Komponenten nicht automatisiert übertragen werden können? Wie relevant ist das Problem in der Praxis und existieren Lösungsmöglichkeiten?

Vorgehen

Es wird im ersten Schritt ein Continuous Delivery Prozess beschrieben. Hierbei soll herausgestellt werden, warum dieser den Entwicklern helfen kann, bessere Software zu liefern. Dabei soll auf die Vor- und Nachteile eines solchen Prozesses eingegangen werden. Des Weiteren werden die Voraussetzungen zur Umsetzung eines solchen Prozesses und die Anforderungen an den Entwicklungsprozess sowie an die Infrastruktur ausgeführt. Es werden die gängigen Tools vorgestellt. Des Weiteren werden Kriterien definiert, die ein Continuous Delivery erfüllen muss.

Es soll weiterhin eine kurze Einordnung bzw. Abgrenzung zu Continuous Integration und Continuous Deployment gegeben werden, da die Definitionen dieser Begriffe bzw. Prozesse nicht immer eindeutig sind.

Nach dem allgemeinen Teil, der einen klassischen Continuous Delivery Prozess beschreibt, der z.B. für das Ausliefern einer Webseite oder einer Desktop Anwendung verwendet werden könnte, soll  kurz die Salesforce Plattform beschrieben werden.

Daran anschließend wird die Entwicklung in Salesforce vorgestellt und beschrieben. Mit Entwicklung ist das Anpassen der Standardumgebung von Salesforce an die Kunden-Anforderungen gemeint. Dies ist möglich u.a. durch Erstellung und Konfiguration neuer oder bestehender Objekte über das Salesforce Userinterface, die dann als Metadaten vorliegen. Um erweiterte Funktionalität bereitzustellen, gibt es die Möglichkeit, diese mit Apex, einer Sprache mit Java ähnlicher Syntax, oder Visualforce, einem Webframework, umzusetzen. Auch hier werden die Entwicklungsumgebung und der Entwicklungsprozess beschrieben. Weiterhin wird das Konzept der Sandboxen in Salesforce vorgestellt.

Nach Vorstellung der Entwicklung in Salesforce soll ein entsprechender Continuous Delivery Prozess für die Salesforce Plattform entworfen und definiert werden. Weiterhin wird ausgearbeitet, wie sich mit Hilfe der Sandboxen eine Development, Testing, Acceptance und Production Umgebung aufbauen und die für Continuous Delivery nötige Automatisierung erreichen lässt und wo deren Grenzen sind. Es existieren Drittanbieter, die eine Continuous Integration bzw. Continuous Delivery Lösung für Salesforce anbieten. Einige dieser Lösungen sollen im Hinblick auf die Funktionalität sowie Realisierung eines echten Continuous Delivery Prozesses analysiert werden.

Die entwickelten und analysierten Prozesse werden mit den Kriterien, die für einen erfolgreichen Continuous Delivery definiert wurden, verglichen und bewertet.

Externer Kooperationspartner

ABLE Management Services GmbH
Steinmüllerallee 2
51643 Gummersbach
Fon +49 2261 5011 0
Fax +49 2261 5011 199
info@able-group.de

Bearbeiter

Dennis Hermanns

Abgabe

Juli 2017

Veröffentlicht: von

Hintergrund

User Interfaces können bei Microservice-basierten Softwaresystemen auf verschiedene Art integriert werden:

  • Bei Self Contained Systems: Jeder MS hat ggfs. seine(n) eigenständige(n) UI-Client(s). Integration erfolgt durch HTML-Verlinkung.
  • Bei Developer Anarchy oder Layered Microservices:
    • Dynamische Inklusion – Microservices stellen Teil-UIs / Fragmente bereit, die durch verschiedene Optionen zu einem Gesamt-UI integriert werden
    • Ein zentrales, monolithisches UI wird von einem dedizierten Team gebaut und nutzt Headless Services.

Darüber hinaus sind Mischformen möglich und in der Praxis üblich.

Problemstellung / Forschungsfrage

Die Arbeit soll die Frage klären, welche der genannten Integrations-Stile wann sinnvoll anwendbar sind, und was typische Stärken und Hindernisse sind.

  1. Kann man ggfs. von Größe und Komplexität der Gesamt-Anwendung auf einen geeigneten UI-Integrationsstil schließen?
  2. Was sind gebräuchliche Integrationsstile bei bekannten, Microservice-basierten Anwendungen (insb. bei E-Commerce-Anwendungen wie Otto oder Amazon)

Die zweite Frage kann durch ein (semi-)empirisches Vorgehen (Umfragen, Experteninterviews) bearbeitet werden.

 

Bearbeiter

Marvin Dick

Veröffentlicht: von

Aus Zeitgründen werden ich das WPF „Grundlagen des Strategischen IT-Managements“ im WS 17/18 nicht anbieten, erst wieder im WS 18/19.

Dies ist aber nur als einmalige Änderung geplant, um mehr Zeit für andere Aktivitäten zu haben. Es wird im Prüfungszeitraum Sep/Okt 17 eine Klausur angeboten. Im WS 18/19 und in nachfolgenden Wintersemestern werde ich das WPF wieder anbieten.

Veröffentlicht: von

Am Fr. 21.7. 10:00 in Raum 0503 (Ferchau-Gebäude) biete ich eine Fragestunde zur ST1-Klausur (Di 25.7. 14:00) an. Ich werde auch noch einmal auf die Aspekte eingehen, die offensichtlich in der ersten Klausur am Ende des letzten Semesters für Sie schwierig waren.

Anmerkung: Es geht nicht um ST2 – die Fragen dazu werden in der Vorlesung am 18.7. diskutiert.