GP SS18_A02: Architektur-Blueprint für Microservice-Landschaften (am Beispiel Projektbörse Campus Gummersbach)

Veröffentlicht: von

Problembeschreibung

Eine Microservice-Architektur verfolgt den Ansatz, ein IT-System (in der Regel eine webbasierte Anwendung) als Suite von weitgehend unabhängigen vertikalen Modulen aufzubauen. Diese können (weitgehend) unabhängig voneinander deployed und betrieben werden und benötigen nur ein Minimum an zentraler Kommunikationsinfrastruktur. Kommunikation zwischen Front- und Backend erfolgt über leichtgewichtige Protokolle wie etwa REST.

Dieser Architekturstil erlaubt es, ganze Anwendungslandschaften nach Geschäftsfähigkeiten zu segmentieren. Die resultierenden Teilfunktionalitäten können dann in Form von Microservices implement und lose gekoppelt werden. So entstehen Systeme von Anwendungen, die einerseits miteinander kommunizieren, und andererseits jeweils mit einem Höchstmaß an Unabhängigkeit entwickelt und gewartet werden können.

Eine Microservice-Architektur bietet sich daher besonders an, um Softwareprojekte an der Hochschule (wie dem Campus Gummersbach) zu realisieren. Es ist offensichtlich sinnvoll, Systeme zur Verwaltung von Räumen, Praktika, Veranstaltungen, Projekten, Prüfungen etc. miteinander zu vernetzen. Andererseits werden diese Anwendungen von verschiedenen Gruppen mit verschiedenen Technologien gepflegt. Eine enge Abstimmung ist an der Hochschule weder sinnvoll noch durchsetzbar.

Um solchen Projekten ein Maximum an Freiheit bei Technologiewahl und Umsetzungsform zu gewähren, wäre ein Architektur-Blueprint für Basistechnologien zur Umsetzung von Services und Koppelung von Schnittstellen eine große Hilfe. Dies soll im Rahmen dieses Projekts an einem konkreten Beispiel konzipiert und pilotiert werden.

Projektbeschreibung

Ziel des Projekts ist es, für die Applikationslandschaft „Campus Gummersbach“ einen Architektur-Blueprint, basierend auf dem Microservices-Ansatz, zu konzipieren.

Dieses Konzept soll am Beispiel der Projektbörse Campus GM pilotiert werden. In der Master-Veranstaltung Anforderungsmanagement (SS17) wurde hierfür eine Anforderungsspezifikation (Lastenheft) erstellt. Darauf aufbauend hat die Master-Veranstaltung FAE eine Architekturspezifikation (Pflichtenheft) erstellt. Je nach Teilnehmerzahl wird/werden einer oder mehrere Services der Projektbörse sowie prototypisch entwickelt. Dazu werden Mocks eines oder mehrere Umsysteme (wie etwa ILIAS oder HOPS) erstellt.

Diese Pilotanwendung wird genutzt, um den entwickelten Architektur-Blueprint zu validieren und offene Fragen zu identifizieren.

Beitrag des Projektpartners Capgemini

Projektpartner ist Capgemini (Axel Burghof, Senior Delivery Architect). Capgemini entwickelt für den Einsatz in Kundenprojekten die Devon-Plattform, eine Best-of-Breed-Sammlung von Technologien und Good Practices. Die Zielstellung von Devon ist durchaus vergleichbar mit dem Ziel des Architektur-Blueprints für den Campus. Daher kann Devon als Anregung, Vergleichsmaßstab und Grundlage für das Projekt genutzt werden. Capgemini kann wiederum die Ergebnisse des Projekts in die Devon-Entwicklung zurückfließen lassen. Daher wird Axel Burghof die Entwicklung eng begleiten.

Projektmethodik

Die Umsetzung des Projekts sowie die Erstellung des Evaluationsberichts wird nach agiler Methodik (Scrum mit Elementen aus XP) erfolgen. Die agilen Teamprozesse werden gemäß Typ-A-Definition von Prof. Stumpf methodisch begleitet. Das Projekt wird in (vermutlich vierwöchige) Sprints gegliedert. Axel Burghof von Capgemini wird bei den Sprint Reviews zugegen sein.

Learning Outcomes

  • Praxiserfahrung mit Microservice-Architekturen
  • Erfahrung in der Konzeption und Pilotierung eines praxisnahen, umfangreichen Softwareprojekts
  • Gelegenheit zur konkreten Verwendung von „Bleeding Edge“ Technologien
  • Erfahrung mit agiler Entwicklungsmethodik in einem realistischen Softwareprojekt
  • Expertise in Kommunikation und Dokumentation
  • Teamwork- und Projektmanagement-Erfahrung

Voraussetzungen

  • Programmierkenntnisse
  • Interesse an professioneller Software-Entwicklung
  • Interesse an der Softwarearchitektur
  • Interesse an komplexen Aufgabenstellungen und methodischem Vorgehen
  • Bereitschaft, Teamarbeit tatsächlich physisch gemeinsam (im gleichen Raum, „collocated“) durchzuführen, um zu einem agilen Team zu reifen
  • Bereitschaft, gemäß agiler Vorgehensweise durch geeignete Tools Transparenz über den eigenen Beitrag zur Gruppenleistung zuzulassen

Externe Projektpartner

Capgemini, Niederlassung Köln

Ferchau-Förderpreis für Masterarbeit

Veröffentlicht: von

Die Masterarbeit Entwicklung nachhaltiger KPI-Systeme zur Überwachung der Operationalisierung von Geschäftsstrategien im Bereich EAM von Markus Engelke wurde mit dem Steinmüller-Engineering-Förderpreis ausgezeichnet. Siehe auch hier: https://www.th-koeln.de/hochschule/prozessmodell-fuer-versicherungen-energieeinsparung-fuer-klaeranlagen-geraeuschdaempfung-fuer-belueftungsduesen_49041.php

Herzlichen Glückwunsch!

GP SS17_B05/06: Webinar Bente & Böhmer zu „Rapid IoT Prototyping am Praxisbeispiel einer Versicherung“

Veröffentlicht: von

Am Donnerstag, 2.11.17, wirkten mein Kollege Prof. Dr. Matthias Böhmer und ich an einem Webinar der Firma ThingForward mit, Titel „Rapid IoT Prototyping am Praxisbeispiel einer Versicherung“.

Wir stellen dabei die Ergebnisse zweier Guided Projects aus dem Informatik Master vor, die wir in Zusammenarbeit mit ThingForward und der Gothaer Versicherung betreut haben.

Die Aufzeichnung des Webinars findet sich hier: https://www.youtube.com/watch?v=hfNp7HvdeCo

PP/BA: Good Practices für Kommunikation bei Microservices

Veröffentlicht: von

Microservices bauen im Wesentlichen auf die synchrone Kommunikation via REST sowie eine asynchrone Kommunikation auf. Bei genauerer Betrachtung gibt es allerdings noch eine Anzahl von offenen Fragen, auf die es noch keine allgemein anwendbaren, abgesicherten Antworten gibt.

  • Welches Maturity Level nach Richardson empfiehlt sich bei REST? Gibt es eine allgemeine Antwort, oder muss man differenzieren?
  • Sollte man REST mittels RAML spezifizieren? Gibt es Ausnahmen oder Regeln?
  • Wie sinnvoll sind Alternativen zu REST wie etwas GraphQL? Wann sollte man was nutzen?
  • Kann man allgemein anwendbare Regeln formulieren, wann eher synchrone und wann eher asynchrone Kommunikation sinnvoll ist?
  • Was sind sinnvolle Discovery-Lösungen?
  • …

Diese und weitere Fragen sollten im Rahmen der Arbeit anhand von Literatur untersucht und die Fachmeinung dargestellt werden. Eine Implementierung von Dummy-Funktionalität kann sinnvoll sein, um Effekte bei Wartung und Weiterentwicklung zu beschreiben.

Bearbeiter

Allan Mehlen

PP/BA/MA: Online-Quiz für Bloom’sche Taxonomiestufen höher als 2

Veröffentlicht: von

Dieses Thema kann als Praxisprojekt mit Option auf anschließende Bachelorarbeit bearbeitet werden, oder aber direkt als Bachelorarbeit.

Worum geht es?

Die Revised Bloom’s Taxonomy geht von sechs Stufen des „Beherrschens“ eines Lernstoffes aus:

  1. Remember
  2. Understand
  3. Apply
  4. Analyze
  5. Evaluate
  6. Create

Online-Lerntools wie etwa Quizze bleiben im Allgemeinen bei den Stufen 1-2 stehen, d.h. es wird maximal Wissen abgefragt. Für komplexe Fähigkeiten, wie etwa beim Architekturentwurf, werden aber Fähigkeiten der Stufen 3-5 benötigt.

Die Lehr-/Lernplattform coalbase 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 diese höheren Taxonomiestufen online zu prüfen. In diesem Projekt / dieser Arbeit sollen Möglichkeiten untersucht und prototypisch implementiert werden, auch höhere Taxonomiestufen als Editor abzubilden.

Das kann am Beispiel der Vorlesungen Softwaretechnik 1 oder 2 geschehen. Es sollte versucht werden, eine komplexe Fragestellung – z.B. ein richtiges Klassendiagramm – in einem Online-Quiz abzubilden.

Bei Interesse

Sie haben allgemeine Rückfragen, konkretes Interesse oder sogar Änderungs-/Erweiterungsvorschläge? Bitte vereinbaren Sie unverbindlich einen Termin mit mir (am einfachsten über https://bente.youcanbook.me/), und wir können die praktische Ausgestaltung des Themas diskutieren.

MA: Kollaborativer UML-Editor

Veröffentlicht: von

Google Docs ist unter Studierenden mittlerweile das de-facto-Standardwerkzeug, wenn es um das kolloborative Editieren von Dokumenten in Gruppen geht, z.B. für Praktikumsabgaben. Das „Killer-Feature“ hierbei ist die Möglichkeit, parallel am selben Dokument zu arbeiten, wobei die individuellen Änderungen bis hinunter auf Satz- oder Wortebene isoliert sind.

UML-Editoren bieten diese Art der kollaborativen Bearbeitung nicht – und aufgrund der hohen Komplexität von UML und des kleinen Nischenmarkts wird sich dies wohl auch nicht ändern. Dennoch wäre ein vergleichbares Feature für UML für die Studienpraxis „Softwaretechnik“ außerordentlich nützlich.

Was aber, wenn man sich auf ein sehr, sehr stark eingeschränktes Subset von UML konzentriert – beispielsweise einfache Klassendiagramme ohne Attribute und Methoden, und nur mit vier verschiedenen Assoziationstypen (Assoziation, Aggregation, Komposition [alle ungerichtet], Generalisierung)?

Die Bachelor- / Masterarbeit soll in einer Art von Machbarkeitsstudie klären, inwieweit für ein solches UML-Subset ein kollaborativer Editor im „Google-Docs-Stil“ machbar wäre.

 

Bearbeiter

Roland Müller

Domänenschnitt im Architekturentwurf: Eine Praxis-Studie

Veröffentlicht: von

Problemstellung

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. Diese Ansätze der Unternehmen bauen dabei auf Erfahrungen aus vorherigen Projekten, als auch auf den Ansätzen und Patterns aus der Literatur auf.

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. Diese Unterschiede fließen nur schwer wieder in die dokumentierten Ansätze zurück.

Abgeleitete Forschungsfrage

  • Welche Ansätze und Patterns existieren in Literatur und Unternehmens-intern? Wo existieren Widersprüche oder Gemeinsamkeiten?
  • Wie wird der Domänenschnitt in realen Projekten durchgeführt und gibt es Unterschiede bei verschiedenen Projektarten?
  • Wie unterscheiden sich reale Vorgehen von den untersuchten Ansätzen und wie können diese Ansätze mit den Erfahrungen aus der Praxis verbessert werden?

Vorgehen

Für die Ansätze aus der Literatur sollen verschiedene Quellen zu unterschiedlichen Ansätzen zusammengetragen werden. Anschließend sollen Gemeinsamkeiten und Unterschiede herausgestellt werden.

Für die Unternehmens-internen Ansätze sollen Ansätze von Capgemini verwendet werden. Diese Beispiele sollen mit den Ergebnissen aus der vorherigen Literaturstudie abgeglichen werden, um Gemeinsamkeiten und Unterschiede aufzudecken.

Die Ergebnisse aus den ersten Beiden Abschnitten sollen anschließend in einer empirischen Studie evaluiert werden. Dazu sollen Interviews mit Architekten von Capgemini und anderen Unternehmen geführt werden, um reale Vorgehen in Kundenprojekten mit den Ergebnissen aus den ersten beiden Abschnitten zu vergleichen.

Abschließend soll eine Aussage über die entdeckten Unterschiede und Gemeinsamkeiten aller drei Abschnitte getroffen werden und Vorschläge für eine Verbesserung der dokumentierten Ansätze gegeben werden.

Bearbeiter und Zeitplan

  • Pascal Dung (in Zusammenarbeit mit der Firma Capgemini)
  • Abgabe ca. Frühjahr 2018