Modellierungsmethoden

Grundlagen

Software versucht einen Ausschnitt der realen Welt mit ihren Zusammenhängen, Funktionsweisen und Bezügen abzubilden. Hierfür werden informatische Modelle erstellt. Diese Modelle versuchen möglichst genau eine spezifische Anwendungsdomäne zu beschreiben. Die Digital Humanities beschäftigen sich sehr häufig mit Anwendungsdomänen, die um kulturelle und/oder geisteswissenschaftliche Zusammenhänge und Forschungsdaten kreisen. Eng mit einer Anwendungsdomäne in Beziehung steht die jeweilige Fachsprache, mittels derer die Wissensobjekte der Domäne beschrieben werden. Man kann bis zu einem gewissen Grad davon sprechen, dass in den Digital Humanities zusammen mit der Anwendungsdomäne häufig auch eine Wissensdomäne modelliert wird.

Diese Grundlagen gelten prinzipiell für alle Arten der Softwareentwicklung, also natürlich auch für die Entwicklung von Webanwendungen im geistes- und kulturwissenschaftlichen Umfeld. Für die Modellierung von Software haben sich verschiedene Methodologien herausgebildet. Teilweise stehen diese in Bezug zu einer bestimmten Software-Entwicklungsphilosophie, womit häufig ein Vorgehensmodell zur Entwicklung von Software gemeint ist. Insgesamt lässt sich Softwareentwicklung in folgende, nicht immer trennscharfe Bereiche unterteilen:

  1. Übergreifende Vorgehensmodelle ("Entwicklungphilosopie" bzw. Entwicklungsprinzip),
  2. die damit in Beziehung stehenden Modellierungsmethoden,
  3. die Entwurfs- und Architekturmuster für eine Software, die mit den Modellen in Beziehung stehen,
  4. die bei der Entwicklung verwendeten Programmierparadigmen,
  5. die Entwicklungsmethoden, die im Entwicklungsprozess Anwendung finden,
  6. sowie die verwendeten Entwicklungswerkzeuge und Instrumente.

Die nachfolgenden Abschnitte stellen beispielhaft einige Modellierungsansätze, Entwurfsmuster, Programmierparadigmen, Entwicklungsmethoden und Werkzeuge vor, die im Umfeld der weborientierten Anwendungsentwicklung häufig anzutreffen sind.

Weiterführende Informationen:

Modellierungsmethoden

Die Modellierung der Anwendungsdomäne einer Software ist unabhängig von spezifischen Programmiersprachen, Tools oder Frameworks. Es gibt jedoch zahlreiche Software-Frameworks, mit denen sich eine solche Modellierung recht einfach in Programmcode überführen lässt. Beispiele für unterschiedliche Modellierungsansätze von Software sind:

Domain Driven Design

Domain Driven Design (DDD) ist eine konzeptionelle Herangehens- und Denkweise an die Modellierung von Software. Der Ansatz wurde 2003 von Eric Evans in seinem gleichnamigen Buch geprägt. Das Hauptaugenmerk bei DDD fällt auf die Einführung einer ubiquitären (allgemein verständlichen) Sprache, die auf allen Stufen der Softwareentwicklung, von der Konzeption bis auf die Ebene des Programmcodes, verwendet wird. Durch regelmäßige Iterationen nach dem DDD-Prinzip ist es möglich, die Software genauer an die sich kontinuierlich verändernde Projektrealität anzupassen. Die Codebasis bleibt dabei immer im Einklang mit der Modellierungsebene. Domain Driven Design steht daher agilen Vorgehensmodellen nahe.

DDD legt besonders großen Wert auf die Fachlichkeit einer Anwendungsdomäne, die mittels der ubiquitären Sprache abgebildet werden soll. Daher steht die Kommunikation zwischen Softwareentwickler_innen und Domänenexpert_innen im Zentrum der Methode. Ein Domänenmodell basiert auf Objekten, die für die einzelnen Bestandteile der zu modellierenden Fachdomäne stehen und unterschiedliche Eigenschaften haben. Dadurch steht DDD dem objektorientierten Programmierparadigma nahe.

Ein Domänenmodell kann aus folgenden Bestandteilen bestehen:

Begriff Erklärung / Beispiel aus der STURM-Webanwendung
Entitäten (entities) Objekte mit eigener Identität: Briefe, Personen, Orte, Werke etc.
Wertobjekte (value objects) Objekte, die über ihre Eigenschaften definiert sind: Geokoordinaten, Datierungen
Assoziationen (associations) Beziehungen der Objekte untereinander: Personen und Briefe, Sende- und Empfangsvorgang
Aggregate (aggregates) Zusammenschlüsse von Entitäten, Wertobjekten und Assoziationen zu logischen Einheiten. Aggregate gewährleisen die Konsistenz und funktionale Integrität der Fachdomäne: Brief, Datierung, Sende- und Empfangsort gehören zum Aggregat "Briefe"
Serviceobjekte (services) Dienste für Objekte der Fachdomäne: Normdatenresolver für Personen und Orte
Ereignisse (events) Ereignisse, die eine Zustandsveränderung in der Fachdomäne bzw. bei ihren Objekten auslösen: ein Suchereigniss, ein Publikationsereignis für neu edierte Briefe
Fabriken (factories) In der objektorientierten Programmierung wird die Erstellung von Objekten gerne sogenannten "Fabriken" übergeben. Dies sind spezielle Objekte, die anhand eines Entwurfsmusters Objekte erzeugen. Dadurch wird vermieden, dass die Herstellungslogik am konkreten Objekt selbst implementiert wird. Das Fabrikobjekt hingegen kann ausgetauscht werden: Ein Briefobjekt benötigt ein neues Personenobjekt. Das Briefobjekt stellt das Personenobjekt aber nicht selbst her (mittels "new"), sondern fordert es bei einer Fabrik an.
Repositorien (repositories) Repositorien abstrahieren das Speichern (Persistieren) und Laden (Rekonstituieren) von Domänenobjekten. Sie sind zwischen die Infrastrukturschicht (bspw. eine Datenbank) und die Schicht mit der Anwendungslogik geschaltet. Dadurch kann die Infrastrukturschicht ausgetauscht werden, ohne das die Schicht mit der Anwendungslogik geändert werden muss.

Folgende Grafik zeigt einzelne Bestandteile von DDD in Beziehung zueinander:

Grafik: Elemene des Domain Driven Design
Quelle: Moritz Graf, freies Bild

Entwurf der STURM-Anwendungsdomäne

Wir bilden mehrere Gruppen und entwerfen gemeinsam ein Domänenmodell für die STURM-Webanwendung (zunächst auf Papier). Wir werden darauf bei der Implementierung der Geschäftslogik in PHP noch einmal zurückkommen. Folgende Leitfragen sollen dabei zunächst berücksichtigt werden:

  • Was sind die Entitäten, was die Wertobjekte in der STURM-Fachdomäne?
  • Welche Aggregate lassen sich für die Objekte der STURM-Fachdomäne bilden?
  • Welche weiteren Objekttypen gibt es (bspw. Serviceobjekte, Ereignisse etc)?
  • Welche Begrifflichkeiten sollten im Sinne der ubiquitären Sprache für die STURM-Webanwendung in Form eines Glossars angelegt werden?

Weiterführende Informationen:

Entwurfsmuster

Wie in jedem Bereich der professionellen Softwareentwicklung spielen auch im Feld der Webanwendungsentwicklung Entwurfsmuster, also Lösungsmuster für wiederkehrende Problemstellungen eine große Rolle. Insbesondere aktuelle Web Frameworks verwenden (unabhängig von der eingesetzten Programmiersprache) häufig Entwurfsmuster. Eine Beschäftigung mit und eine Kenntnis von Software-Entwurfsmustern ist daher sowohl aus der Projektmanagement- als auch der Entwicklungsperspektive angeraten.

Dabei gilt jedoch: Der Einsatz von Entwurfsmustern sollte mit Bedacht geschehen. Entwurfsmuster sind keine Garantie für gute Software. Werden sie falsch eingesetzt, können sie ein Antimuster bilden und die Softwarequalität negativ beeinträchtigen.

Entwurfsmuster werden in vier Kategorien unterschieden: Erzeugungsmuster, Strukturmuster, Verhaltensmuster und objektrelationale Muster. Daneben gibt es Muster, die sich keiner der vorherigen vier Kategorien zuordnen lassen (bspw. Analysemuster, Architekturmuster oder Integrationsmuster).

Weitere Informationen:

Model - View - Controller (MVC)

Das Model-View-Controller Entwurfsmuster wird (meistens) zu den Software-Architekturmustern gerechnet und ist bereits seit Ende der 1970er Jahre in Gebrauch. Es gehört heute zu den besonders verbreiteten Architekturmustern. Nahezu alle modernen Webframweworks implementieren in der einen oder anderen Ausprägung eine MVC-Architektur.

Unterschieden werden muss in einer klassischen MVC-Architektur zwischen dem Modell (model), das sämtliche Daten der Anwendung enthält bzw. verwaltet, der Präsentationsschicht (view), die für die Darstellung der benötigten Daten zuständig ist und diese vom Modell anfordert sowie der Steuerungseinheit (controller), die zwischen Modell und Präsentation für die Verwaltung von Aktionen zwischen diesen beiden Schichten zuständig ist. Der Controller ist auch für die Interaktion mit den Usern zuständig.

An welcher Stelle innerhalb der MVC-Architektur die Anwendungslogik implementiert wird ist dabei nicht festgelegt. Generell wird aus Gründen einer besseren Erweiterbarkeit aber empfohlen, auf ein slim controller Prinzip zu setzen, die Logik der Steuerungseinheit also auf die Verarbeitung von Nutzerinteraktionen und die Verwaltung der Präsentationsschicht zu konzentrieren, während die eigentliche Anwendungslogik im Modell implementiert wird.

Grafik: Interaktionsdiagramm der MVC Architektur
Quelle: RegisFrey, Public Domain

Bei serverseitigen Webanwendungen (thin client) wertet der Controller meistens die über HTTP eintreffenden Nutzerinteraktionen und Datenpakete aus. Meist kommuniziert der Controller dazu mit dem Model, das in einer bestimmten Programmiersprache implementiert ist und die darzustellenden Daten aus einer Persistenzschicht (bspw. eine relationale Datenbank) lädt. Als View wird häufig eine mit Controller und Model verbundene Template-Engine verstanden, die auf Basis von HTML-Vorlagen die Webseiten erzeugt, die dann vom Controller an den Webserver und von diesem an den Client (also den Browser) zurückgeliefert werden.

Bei clientseitigen Webanwendungen (fat client) kommt es je nach gewählter Implementierung dazu, dass ein oder mehrere Komponenten der MVC-Architektur im Client implementiert sind (also bspw. der vollständige View oder auch das Modell oder Teile des Modells). In solchen Architekturen werden häufig lediglich Daten über HTTP aus der serverseitigen Persistenzschicht nachgeladen, während die Anwendungslogik vollständig im Client abläuft.

Weitere Informationen:

WS 2019/20 – Webbasierte Forschungsapplikationen für die Geisteswissenschaften CC BY-NC-SA 4.0