Benutzeroberflächen

Die zu entwickelnden Benutzeroberflächen von Schleupen.CS 3.0 haben einige Ziele, die sich von Bausteinen des Backends unterscheiden. Hierzu gehören unter anderem:

• Benutzbarkeit
  • einheitliches Look & Feel
  • Orientierung der Benutzerführung an Geschäftsprozessen
  • Übergreifendes Portal, aus dem Geschäftsprozesse gestartet werden
• Portabilität
  • Web-Browser als einzige Voraussetzung für Nutzung
  • Unterstützung von mobilen Endgeräten (Tablets)
• Wartbarkeit
  • Wiederverwendung von Funktionalität (auch über Geschäftsprozesse hinweg)
  • Testmöglichkeit des Codes
• Effizienz
  • Modellierung und Generierung zur Vermeidung von schablonenhaften Implementierungstätigkeiten
• Konsistenz
  • Nutzung des Microsoft .NET-Ökosystems bezüglich Entwicklungswerkzeugen und Basistechnologien
• Erweiterbarkeit
  • Bessere Reaktionsfähigkeit auf Regulierung und andere kurzfristige Änderungen im Markt
  • Kunden können eigene Geschäftsprozesse definieren
  • Kunden können Daten, Services und das User Interface anpassen (Beispiel: Kundennummern mit n Stellen)
  • Customizing erfolgt durch Kunden oder Dienstleister (z.B. durch die Schleupen Individual-Entwicklung)
  • Mit denselben Entwicklungswerkzeugen wie die Schleupen.CS-Entwicklung (Dogfooding)

Insbesondere soll die Darstellung für den Endbenutzer vereinheitlicht werden. Daher wird ein einheitlicher Portalrahmen verwendet, in dem sich sich die einzelnen Seiten (= Dialogschritt) sogenannter Dialogabläufe einbetten.

Geschäftsprozesse können über das Start-Menü gestartet werden, die über einen Dialogablauf initiiert werden. Ein Dialogablauf besteht aus mehreren Seiten, den sogenannten Dialogschritten. Benachrichtigungen, sogenannte Notifications, werden ebenfalls im Portal dargestellt: Diese sind Rückmeldungen aus Dialogschritten, aber insbesondere auch aus der Hintergrund-Verarbeitung an den End-Benutzer. Sind Benutzer-Eingriffe erforderlich, so werden durch die Hintergrund-Verarbeitung Aufgaben eingestellt, die ebenfalls im Portal erscheinen.

In der folgenden Abbildung wird dargestellt, wie Dialogabläufe sich in übergreifende Geschäftsprozesse analog zu den Workflows einbetten. Zoomen wir noch tiefer in die Umsetzung, so stellt ein Dialogschritt einen Teil eines Dialogablaufs dar, der selber wiederum aus Controls und Containern besteht. Serviceaufrufe können dann auf verschiedenen Ebenen angeschlossen werden, insbesondere im Dialogschritt und Dialogablauf.

Architekturüberblick UI

Dialogschritte (=DialogSteps) sowie Dialogabläufe (= DialogFlows) sind Bestandteile der orchestrierenden Geschäftsprozesskomponenten. Dabei findet das Muster MVVM als zentrales Muster in Dialogschritten Anwendung. Die hierbei verwendeten Designbausteine unterstützen hierbei insbesondere eine gute Testbarkeit.

Die Schleupen.CS-Presentation-Engine stellt insbesondere das Rahmenwerk für die Laufzeit bereit. Dieses teilt sich grob in einen Teil, der im Browser als HTML und Javascript-Code ausgeführt wird und einen Teil, der im PresentationServer als C#-Code ausgeführt wird, auf. Die Kommunikationsstrecken der wichtigsten Bausteine zeigt folgende Abbildung:

Dabei ist ein DialogStep im Browser als Javascript-Code der Baustein, der u.a. mehrere Controls beinhaltet. Diese hält Client-seitig den Zustand. Da hier Redux verwendet wird, sind diese Werte an einen Redux-Store gebunden, der den Status hält. Über diesen Store sind die Server-seitigen Daten verknüpft, die über HTTP-REST-Calls gelesen werden und bei Server-seitigen Änderungen in den Store zurückgespielt werden.

Im Presentation-Server kommen die bereits oben beschriebenen Bausteine DialogStep, ViewModel etc. zum Tragen. Jeder DialogStep hat mindestens ein ViewModel über die eine oder mehrere Properties gebunden sind. Diese besitzen die Server-seitige Repräsentation der an die Controls gebundenen Werte.

Diese ViewModels werden durch den Entwickler durch das Laden von Daten per Web-Service-Aufruf befüllt. Die Service-Aufrufe selber sind im ViewModel angebunden.

Dialogabläufe werden in der Business Process Model Notation modelliert und sind somit bzgl. der Granularität ein Schritt im Geschäftsprozess:

Derartige Dialoglabläufe binden Dialogschritte, Sub-Dialogabläufe und Skript-Tasks zusammen. Skript-Tasks führen hierbeit C#-Code aus, beispielsweise um einen Service aufzurufen.

Um dem DRY-Prinzip zu genügen, kann Dialogschritt-übergreifender Code in Bibliotheken (= Libraries) gebündelt werden. Von diesen gibt es zwei Ausprägungen: Normale Bibliotheken zur Vermeidung von Redundanz und ContractLibraries, die einen Vertrag zwischen anbietendem Baustein (z.B DialogSchritt) und nutzendem Baustein (z.B. DialogFlow) darstellen.

Tooling

Zur Umsetzung der Benutzeroberflächen werden diese in Schleupen.CS 3.0 mit einem Tool namens WebModeler modelliert. Dieser wird für die Bausteine

• Dialogschritt, der eine Seite innerhalb des Portals darstellt,
• Dialogablauf, der mehrere Dialogschritte wie in einem Wizard zusammenbindet,
• Library, zur Bereitstellung einer Bibliothek im UI-Kontext
• ContractLibrary, zur Bereitstellung einer Vertrags-Bibliothek im UI-Kontext

verwendet. Weiterführende Implementierungen in C# werden ebenfalls mit dem WebModeler oder mit dem Visual Studio bewerkstelligt.

Dialogschritte, Libraries und ContractLibraries können auch sinnvoll in XML ohne WebModeler editiert werden. Für das Entwickeln von C# Code wird der Einsatz von Visual Studio empfohlen.