Projektmanagement Softwareentwicklung

Softwareentwicklung für Projektleiter, Manager und Entwickler

IT-Projektmanagement RSS
  • Softwaredesign: Einheitliches Design mit dem Application-Template

    Jörg Hinrichs

    In dem Artikel Designdemokratie: Nein danke! habe ich vor einiger Zeit dargelegt, wieso ich ein einheitliches Design in der Anwendungsentwicklung für sehr wichtig halte. Heute möchte ich darauf aufsetzen und Ihnen das “Application-Template” vorstellen.

    Was ist ein Application-Template?

    Es handelt sich dabei um die Architektur für eine Anwendung, ähnlich wie bei einem Schichtenmodell. Das Application-Template ist aber noch mehr als das: Es stellt ein kleines Framework zur Verfügung, welches die regelmäßig auftretenden Bestandteile einer Anwendung umfasst und deren Zusammenwirken definiert, zum Beispiel:

    • Fehlerverarbeitung
    • Validierung von Eingaben
    • Persistenz für Businessobjekte

    Eigentlich wollte ich auch den Namen “Application-Framework” verwenden, aber der Begriff “Framework” ist mit so vielen anderen Bedeutungen besetzt, dass ich lieber Application-Template benutze.

    Jeder Entwickler, der dieses Template verwendet, ist gezwungen, sich an die Designvorgaben zu halten. Dadurch entsteht automatisch ein einheitliches Design. Natürlich könnte ein Entwickler theoretisch auch außerhalb des Templates programmieren. Das lässt sich jedoch einfach feststellen und auch unterbinden.

    Aufbau des Application-Templates

    Aufbau Application-Template

    Anhand der Grafik können Sie erkennen, dass es sich beim Application-Template im Wesentlichen um einen MVC-Ansatz (Model-View-Controller) handelt.

    Der wichtigste Grundgedanke bei MVC besteht darin, die Business-Logik von der Benutzeroberfläche zu trennen, um die Wiederverwendbarkeit zu maximieren. Das erreicht man, in dem man zwischen Oberfläche und Business-Schicht den Controller platziert, welcher die notwendigen Objekte erzeugt und deren Kommunikation regelt.

    Grundsätzlich wird unterschieden zwischen reinen Lesevorgängen, die lediglich der Anzeige von Informationen auf der Benutzeroberfläche dienen, und Bearbeitungsvorgängen, welche noch zusätzliche Prozesslogik benötigen.

    Eine Abweichung zu MVC gibt es allerdings: Da ich diesen Aufbau unter C#.NET entwickelt habe wollte ich auch den Nutzen aus dem dort implementierten beidseitigen Data-Binding ziehen. Deshalb ist es der View erlaubt, Businessobjekte beim Bearbeiten direkt zu manipulieren, wozu sie in einem reinen MVC erst den Controller aufrufen müsste.

    Schichten, Blöcke und ihre Aufgaben im Application-Template

    Controller

    Wie bereits erwähnt sorgt der Controller für eine Trennung von Benutzeroberfläche und Business-Schicht.

    Aufgaben:

    • Erzeugen von View-, OR- und Prozess-Klassen
    • Bereitstellen von Businessobjekten
    • Auslösen von Geschäftsprozessen über die zugehörigen Prozess-Klassen
    • Benachrichtigung der View-Klassen über Änderungen an Businessobjekten

    View (GUI)

    Diese Schicht beinhaltet die Schnittstelle zum Anwender. Technisch gesehen “kennt” sie vom Rest der Anwendung nur Businessobjekte oder Businessprozesse (als deren Container) und hat keinerlei Verbindung zum Controller.

    Nun, ganz stimmt das nicht. Im Fall von Formularen gibt es in der Regel einen Status, welcher angibt welche der Schaltflächen zum Beenden geklickt wurde. Diesen Status kann der Controller auswerten. Das Formular selbst ist sich dessen aber nicht bewusst.

    Sollte doch einmal eine Kommunikation mit dem Controller notwendig werden, geschieht dies durch Ereignisse, also letzten Endes durch die Implementierung des Observer Design Patterns. Auch in diesem Fall benötigt die Benutzeroberfläche keine direkte Referenz auf den Controller.

    Aufgaben:

    • Anzeige der Businessobjekte
    • Bearbeitung von Businessobjekten
    • Benachrichtigung des Controllers über zwischenzeitlich auszuführende Aktionen

    Businessobjekt

    Das Businessobjekt repräsentiert einen konkreten (Person, Gegenstand) oder abstrakten (Verhalten, Algorithmus, Idee) Aspekt der realen Welt, welche der Anwendung zugrunde liegt. Hierbei handelt es sich um den Teil der Anwendung, welcher am ehesten in anderen Applikationen wiederverwendbar ist. Um das zu erleichtern, soll ein Businessobjekt keine direkte Referenz zu anderen Teilen der Anwendung besitzen.

    Aufgaben:

    • Objektstatus zur Verfügung stellen
    • Konsistenz der Objektdaten gewährleisten
    • Zugriff kontrollieren (Kapselung)

    Business-Prozess

    Dieser Teil der Business-Schicht ist das technische Pendant zu einem Geschäftsprozess (oder eines Teils davon) und entspricht dem Arbeitsvorgang des Benutzers in der Anwendung. Er dient zur Erledigung der Aufgaben, die objektübergreifend notwendig sind, wie z.B. die Prüfung der Berechtigung eines Benutzers oder die Durchführung der Persistenz der beteiligten Businessobjekte.

    Die Wiederverwendbarkeit einer Prozess-Klasse ist weniger wahrscheinlich als bei einem Businessobjekt. Trotzdem besteht diese Möglichkeit, z.B. wenn mehrere Anwendungen sich eine Datenbank teilen. Daher sollte eine Prozess-Klasse ebenfalls keine direkte Referenz zum Controller oder der Benutzeroberfläche enthalten.

    Aufgaben:

    • Objektübergreifende Validierung von Eingaben
    • Berechtigungsprüfung
    • Bereitstellen von Businessobjekten
    • Speichern von Businessobjekten
    • Protokollierung, Überwachungsfunktionen

    OR-Mapper

    Wie der Name bereits sagt, wandelt der OR-Mapper Datenbankinformationen in Businessobjekte um und umgekehrt. In meinem Fall habe ich dafür eine handgestrickte Lösung verwendet, es kann aber genauso gut ein OR-Mapper eines Drittanbieters zum Einsatz kommen.

    Aufgaben:

    • Lesen von Datenmengen über SQL-Anweisungen
    • Generieren von Businessobjekten aus Datenbankinformationen
    • Generieren von SQL-Anweisungen für die Speicherung von Businessobjekten

    Low-Level Datenbankzugriff

    Diese Schicht dient dazu, den Rest der Anwendung unabhängig von der verwendeten Datenbank zu machen. Dazu stellt sie ein Interface zur Verfügung, welches den direkten Zugriff auf die Datenbank abstrahiert.

    Aufgaben:

    • Verbindungsaufbau zur Datenbank
    • Erstellen von Command-Objekten
    • Lesen von Datenmengen aus der Datenbank (als Dataset, Recordset etc.)
    • Transaktionssteuerung bei mehreren aufeinander folgenden Zugriffen

    Schnittstellen zur Softwareentwicklung

    Ich habe in früheren Artikeln schon dargestellt, warum die Analyse von Geschäftsprozessen in der Anforderungsklärung so wichtig ist:

    Geschäftsprozesse
    IT-Projektmanagement: Wann Prozesse und Tools nutzlos sind (2)

    Hier ergibt sich nun eine direkte Verbindung zum Softwaredesign: Die in der Analyse identifizierten Geschäftsprozesse werden im Design auf entsprechende Prozess-Klassen abgebildet.

    Diese Abbildung wird normalerweise nicht 1:1 erfolgen, aber auf jeden Fall sind die Geschäftsprozesse ein guter Startpunkt für den Entwurf der Prozessklassen.

    Eine weitere Verbindung besteht zu Unit-Tests:

    Unit-Tests: Zeitverschwendung?
    TDD (Test-Driven-Development): Wo liegt denn nun tatsächlich der Vorteil?

    In diesem Artikel beschreibe ich, wie und warum man Unit-Tests als Tests für komplette Arbeitsabläufe gestalten sollte. Für diese Konstruktion sind die Prozess-Klassen der optimale Einstieg in die Business-Schicht. Damit können Sie dann auch TDD sehr einfach realisieren.

    Zu guter Letzt

    Das hier vorgestellte Application-Template ist natürlich nur ein Beispiel, welches ich für meine eigenen Zwecke entwickelt habe. Es erhebt keineswegs den Anspruch, für jede Situation geeignet zu sein.

    Sie haben beispielsweise gesehen, dass ich das Feature des beidseitigen Data-Bindings genutzt und dafür das MVC-Modell ein wenig geändert habe. Vielleicht benutzen Sie eine Sprache oder ein Framework, welches gar kein Data-Binding zur Verfügung stellt (oder nur einseitiges). Vielleicht arbeiten Sie nicht mit einer Windows-Anwendung sondern entwickeln eine Web- oder eine Batchanwendung, auf deren Struktur sich bestimmte Vorgaben nicht übertragen lassen.

    Vielleicht arbeiten Sie auch gar nicht mit einer Datenbank als Backend.

    Wenn Sie ein vorhandenes Application-Template ohne Änderungen für eine andere Anwendung verwenden können, dann ist das eher ein Glücksfall. Es kann durchaus sein, dass Sie jedes Mal Anpassungen durchführen müssen.

    Trotzdem müssen Sie das Application-Template beim zweiten Mal nicht komplett neu erstellen. Mit Sicherheit ist es möglich, Bestandteile eines anderen Templates zu übernehmen. Bei einer ähnlich strukturierten Anwendung werden Sie sogar nur wenige Anpassungen vornehmen müssen.

    In jedem Fall bleibt die grundlegende Struktur eines MVC-Ansatzes vorhanden. Das heißt, wenn ein Entwickler eine Anwendung kennt, dann wird er sich in einer anderen viel schneller zurechtfinden. Und das ursprüngliche Ziel, ein einheitliches Softwaredesign zu erhalten, ist auch gewährleistet.

    Hier konnte ich Ihnen erst einmal nur einen Überblick über das Application-Template geben. In einem der nächsten Artikel werde ich Ihnen die Schicht für den Low-Level Datenbankzugriff detailliert vorstellen.

    1 Comment

One Response to “Softwaredesign: Einheitliches Design mit dem Application-Template”

  1. Guten Tag! Vielen Dank für den Artikel. Sehr informativ.

Leave a Reply