Tools & Materials

Für jede Aufgabe das richtige (Software-) Werkzeug

Bagger für Sandhaufen, Hammer für NagelDas ist die Grundlage des Tools & Materials (T&M) Konzepts von Heinz Züllighoven, das im Object-Oriented Construction Handbook beschrieben ist (ISBN 978-1558606876). Die Perspektive des Anwenders wird dabei in den Mittelpunkt gestellt, da die Software ihn in seiner Arbeit optimal unterstützen soll. Dabei wird die gesamte Systemmodellierung betrachtet, also weit mehr als die Benutzerschnittstelle. Für die hier betrachtete Spring-Vaadin-Groovy-Architektur sind vor allem die Konzepte zum Entwurf und zur Strukturierung der Anwendungsdomain interessant. Sie geben dem im vorigen Kapitel vorgestellten CQRS den geeigneten Unterbau.

T&M Prinzipien
Benutzerzentriert:
Konzepte, Sprache und Arbeitsweise des Benutzers steht im Mittelpunkt. Daher werden soweit irgend möglich die Begriffe des Benutzers in der Strukturierung der Software verwendet. Dies entspricht der Verwendung der Ubiquitous Language im Domain Driven Design (DDD).
Leitbild:
Leitbild der Softwareentwicklung ist die optimale Unterstützung der Nutzer bei der Anwendung des entstehenden Softwareprodukts. Das Anwendungsumfeld und die Rolle und Qualifikation der Nutzer bestimmen daher die Funktionalität der Software. Die Anwendung von T&M wurde für den verantwortlich handelnden qualifizierten Nutzer beschrieben.
Arbeitsplatz:
Die Software stellt dem Nutzer einen virtuelle Arbeitsumgebung zur Verfügung, in der er mit den für die Tätigkeit üblichen Materialien und Verfahren arbeiten kann.
Material und Werkzeuge:
Arbeitsmaterial wird durch die Software abgebildet und in geeigneter Weise dargestellt. Zu seiner Bearbeitung hat der Nutzer passende Werkzeuge zur Verfügung. Wiederkehrende Routinetätigkeiten werden von Automaten übernommen. Für die Organisation der Arbeitsmaterials stehen geeignete Container zur Verfügung.

Werkzeug, Automat, Material

Bei der objektorientierten Entwicklung werden die Kategorien Werkzeug, Automat, Material und fachliche Container als Grundlagen für das Klassenmodell genommen. Die Konzepte der Anwender finden sich in der Software wieder. Alle Klassen der Applikationsebene werden daher einer dieser Kategorien zugeordnet. Die Anwender müssen die Grundstruktur der Software verstehen können. Daher werden die Namen von Klassen, Attributen und Methoden entsprechend ihrer Benennungsweise gewählt. Auch die Organisation der Software wird entsprechend der Anwendersicht realisiert. Um diese Vorgaben zu erreichen müssen Anwender intensiv in die Softwareentwicklung einbezogen werden. Das kann mit agilen Entwicklungsmethoden gut realisiert werden.

In früheren deutschsprachigen Veröffentlichungen von Züllighoven wird daher auch von der  WAM Methode gesprochen.

Material
ist das Arbeitsmaterial des Anwenders, z.B. Schadensmeldung, Kreditantrag, Steuererklärung, Projektplan

  • Gegenstände, die im Rahmen einer Aufgabe Teil des Arbeitsergebnisses werden
  • werden durch Werkzeuge und Automaten bearbeitet
  • verkörpern fachliche Konzepte → müssen für Bearbeitung geeignet sein
  • Eigenschaften „realer“ Arbeitsgegenstände lassen sich oft auf Softwarematerialien übertragen
  • Werkzeug und Material lassen sich oft nur in Arbeitssituationen unterscheiden
  • Gegenstände können arbeitssituationsabhängig Material oder Werkzeug sein („Das Werkzeug bearbeiten“)
Werkzeug
Mit Unterstützung von Werkzeugen kann der Anwender mit seinem Material arbeiten, z.B. Tarifrechner, Suchwerkzeug, Task-Tracker, Planning Poker

  • Mit Werkzeugen werden Materialien im Rahmen einer Aufgabe verändert oder untersucht
  • Werkzeuge unterstützen (und symbolisieren) wiederkehrende Arbeiten
  • Werkzeuge können sich für verschiedene fachliche Zwecke eignen
    → Anwendung auf unterschiedliche Materialien
    → Geeignete Handhabung notwendig
  • Konzeptionelle Eigenschaften „realer“ Werkzeuge lassen sich oft übertragen
    → Handhabung, Gestalt i.A. anders als bei den Vorbildern
Automat
Automaten übernehmen wiederkehrende Routineaufgaben, z.B. Mailing an Verteilerliste, Reporting, Continuous Integration

  • Arbeitsmittel zur Bearbeitung von Materialien im Rahmen zu erledigender Aufgaben
  • Erledigen lästige Routinetätigkeiten als definierte Folge von Arbeitsschritten
    → festes Ergebnis
    → keine Eingriffe durch Benutzer notwendig
  • Laufen unauffällig im Hintergrund
    → Start durch Benutzer oder Arbeitsumgebung
    → ggf. periodische Ausführung
  • Können auf Zustand überprüft werden
  • Können in einem vorgegebenen Rahmen konfiguriert werden
Fachliche Container
Fachliche Container helfen dem Anwender, sein Material zu organisieren und Abläufe zu standardisieren, z.B. Vorgangsakte, Kundenakte, Adressbuch

  • Können Materialien aufnehmen, verwalten, ordnen, herausgeben
    → (Inhalts-) Verzeichnisse führen
    → unterschiedliche Such- und Sortierungskriterien bereitstellen
  • Enthalten viele gleichartige Materialien oder einen definierten Satz zusammengehöriger unterschiedlicher Dinge
  • Vergegenständlichen oft (Arbeits-) Prozesse in Form von Vorgängen (z.B. Kreditakte, Bauakte)
    → können der Koordination von Arbeitsprozessen dienen, welche die Kooperation mehrerer Beteiligter voraussetzen
    → können als Ablage für gemeinsame Materialien mehrerer Beteiligter dienen

Anwendung von T&M Prinzipien

Die Kategorien von T&M lassen sich mit dem ECB-Konzept von Entity-, Controller- und Boundary-Klassen verbinden. Materialien kann man dabei eindeutig den Entities zuordnen. Bei fachlichen Containern ist dies nicht mehr ganz so eindeutig, da die Container auch Abläufe organisieren können. Es liegt daher nahe, die Container in zwei Klassen aufzuspalten, eine Entity, die die Sammlung von Materialien verwaltet, und ggf. einen Controller, der die Abläufe steuert. Automaten sind überwiegend Controller, die interne Aufgaben in der Anwendungsdomain übernehmen und nur eine einfache Schnittstelle mit der Außenwelt haben. Bei Werkzeugen ist die Zuordnung weniger klar. In jedem Fall haben sie eine komplexe Schnittstelle zum Anwender. Je nach Aufgabe können sie auch eine größere Controller-Funktionalität besitzen. Daher werden Werkzeuge und Automaten am besten wieder in einen Controller-Anteil und einen Boundary-Anteil aufgeteilt.

Die Anwendung der T&M Prinzipien hat daher Auswirkungen auf zwei unterschiedliche Phasen der Softwareentwicklung:

  • Für die Modellierung ergeben sich Regeln, wie Klassenmodelle der Anwendungsdomain aufgebaut werden. Jede Klasse soll sich eindeutig einer der Kategorien Material, Werkzeug, Automat, fachlicher Container zuordnen lassen. Wenn diese Zuordnung nicht klar ist, müssen die Verantwortungsbereiche der Klassen neu aufgeteilt werden. Eine sinnvolle Modellierung von Werkzeugen und Automaten wird nur gelingen, wenn die Arbeitsprozesse, die von der Software unterstützt werden sollen, gut verstanden sind. Eine ausführliche Use Case Analyse oder ein äquivalentes Vorgehen ist daher sehr wichtig. Fachliche Container, die auch Arbeitsprozesse implementieren, sollten grundsätzlich in einen passiven Container (→Entity) und einen zugeordneten Controller aufgespalten werden.
    Die Arbeitsplatz-Metapher wird berücksichtigt, indem die zu einem Arbeitsplatz gehörenden Use Cases zusammengefasst werden. Wird bei der Modellierung der Schnittstelle zum Anwender weiterhin das CQRS-Prinzip angewandt, so werden diese zusammengehörenden Use Cases in zusammengehörende Query- und Command-Modelle abgebildet.
  • Die Implementierung hängt stark von der verwendeten Plattform und Architektur ab und lässt dem Design einige Spielräume. Eine zentrale Designentscheidung ist dabei, in welchem Umfang Werkzeuge clientseitig oder serverseitig implementiert werden sollen. Dabei können folgende Gesichtspunkte eine Rolle spielen (unvollständige Liste):
    • Dauer und Umfang des Vorgangs, der durch das Werkzeug unterstützt wird:
      • Lange Vorgänge, an denen möglicherweise mehrere Akteure beteiligt sind, gehören auf den Server. Beispiel: Lebensversicherungsvertrag vorbereiten (→ viele Akteure).
      • Aufgaben, die den Zugriff auf sehr viele Daten benötigen, gehören auf den Server. Beispiel: Suche von Flugverbindungen (→ viele Daten, die nicht auf den Client übertragen werden müssen).
      • Arbeitsvorgänge, bei denen vom Anwender viele Varianten durchgespielt werden müssen, sollten möglichst auf den Client verlagert werden. Beispiel: Was-wäre-wenn-Planungen (→ viele freie Parameter für den Anwender, Spreadsheet-ähnliche UI ideal).
    • Technologie auf Client-Seite:
      • Kann das Werkzeug (mit vertretbarem Aufwand) auf Client-Seite implementiert werden?
      • Ist die Kommunikation schnell genug, um umfangreiche Daten zum Client zu übertragen?
Implementierung mit der Spring-Vaadin-Groovy-Architektur

Die Client-Seite wird auch in Java/Groovy implementiert und vom (GWT-) Compiler in JavaScript-Komponenten und damit verbundene serverseitige Java-Komponenten aufgeteilt. Bei der Implementierung sollte die durch diese Architektur relativ intensive Kommunikation zwischen diesen Komponenten beachtet werden. Vaadin bietet bei der Konfiguration der Komponenten viele Möglichkeiten, um übermäßigen Datenverkehr zu vermeiden, bspw. durch dynamisches Nachladen von Tabellen, Zeitüberwachungen bei der Tastatur-Eingabe usw.

Material
Implementierung als POJO oder POGO und passendes Spring Repository (→ Entity). Wenn Entities direkt bearbeitet werden (z.B. Erfassung von Stammdaten), ist dafür noch eine entsprechende Spring Bean (→ Boundary Objekt) erforderlich, die das Query-Modell für das UI bereitstellt und die Eingaben als Commands entgegennimmt.
Werkzeug
Nach dem CQRS Prinzip stellt eine Spring Bean das geeignete Query-Modell als DTOs bereit (→ Boundary Objekt), mit dem die Vaadin-Klasse die Werkzeugfunktionalität realisieren kann. Von der Komplexität und Art des Werkzeugs ist abhängig, ob eine weitere Spring Bean innerhalb der Applikationsdomain benötigt wird (→ Controller), z.B. für länger laufende oder anwenderübergreifende Use Cases.
Automat
Implementierung als Spring Bean (→ Controller). Konfiguration oder Ausgabe von Ergebnissen kann ggf. über andere Spring Beans und DTOs (→ Boundary Objekte) erfolgen.
Fachliche Container
De wesentliche Aufgabe eines Containers ist die Verwaltung seines Inhalts. Das kann sehr gut wie eine Entity implementiert werden. Zur Bereitstellung für den Anwender wird noch eine Spring Bean (→ Boundary Objekt) und eine Vaadin UI-Klasse benötigt. Such- und Sortierkriterien werden als Commands an die Bean gesendet.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.