Softwaredesign

 

Softwaredesign ist die Kunst, den Quelltext einer Anwendung geschickt zu strukturieren. Ziel der Strukturierung ist es, die Erstellung, Pflege und Erweiterbarkeit von Software zu verbessern. Bei 500 Zeilen Quelltext ist gutes Softwaredesign sicherlich nicht wichtig, aber für größere Projekte werden hier einige der wichtigsten Elemente kurz vorgestellt.

Schichtenmodell

In der Regel wird Quelltext auf mehrere Dateien (Module, Klassen) aufgeteilt. Bei vielen Anwendungen wird man eine Dreiteilung einer Aufgabe vorfinden: die Anzeige (Benutzeroberfläche, Fenster), die Programmlogik (eigentliche Berechnung/Verarbeitung) und die Datenhaltung (Datei, Datenbank). Man gibt dieser Unterteilung eine vertikale Struktur (die Benutzoberfläche ist „oben“ und die Datenhaltung „unten“) und spricht von Schichten. Bei manchen Programmen gibt es auch mehr als drei Schichten.
Es ist äußerst sinnvoll, keine schichtübergreifende Module zu programmieren. Es sollte unbedingt vermieden werden, daß innerhalb eines Moduls Programmcode für Benutzoberfläche und Programmlogik, Programmlogik und Datenhaltung oder gar alle drei Bereiche enthalten ist.

Abbildung: Mit Hilfe des Schichtenmodells läßt sich Software relativ einfach gliedern; hier an einem Beispiel mit drei Schichten demonstriert.

Die oberste Schicht enthält Klassen bzw. Funktionen zur Steuerung der grafischen Benutzeroberfläche. Die mittlere Schicht enthält dern Kern der Anwendung: die ihr zugrundeliegende Logik. Die untere Schicht ist von der Benutzeroberfläche am weitesten entfernt und kümmert sich um die Datenhaltung und -zugriffe.

Model View Controller (MVC)

Gutes Software-Design beinhaltet, daß die Art der Darstellung von Daten in einer Software nicht die Form der Datenhaltung beeinflussen oder gar bestimmen sollte. Die internen Datenstrukturen sind demnach vollständig von der Darstellung in Fenstern abgekoppelt.Um dies zu erreichen, wurde das Schema des Model-View-Controllers (kurz MVC) ersonnen; eine Dreiteilung der Software bei der Datenrepräsentation.•    Zum Model gehören diejenigen Softwaremodule, welche die zentrale Datenhaltung samt logischer Struktur beinhalten.

•    Der View bezeichnet die Module zur Anzeige der Daten in Fenstern und anderen GUI-Elementen.

•    Der Controller vermittelt zwischen Model und View. Im Wesentlichen werden die Daten für die Anzeige aufbereitet.

Hintergedanke ist, daß es in einer Anwendung mehr als eine Sicht auf einen Datenbestand geben könnte. Mit MVC werden die typischen „Stolperfallen“ ganz von allein vermieden. Auch die Selektion der darzustellenden Daten (z.B. welche Spalten eine Tabelle angezeigt werden sollen) gestaltet sich einfacher.

Software zuerst modellieren, dann implementieren

Wenn man beim Programmieren größerer Projekte völlig umständlich auf Variablen oder Methoden zugreifen muss, dann ist dies ein klarer Hinweis für ein schlechtes Softwaredesign. Oft ist die Ursache, dass viel zu früh mit der Implementation begonnen wurde. Stellt man während des Programmierens fest, dass das Gesamtkonzept der Software nachteilig ist, so muss der gesamte Quelltext geändert werden – dagegen sträuben sich jedoch die meisten Programmierer. Die Folge ist, dass schlechtes Design weiterlebt und fortan „drumherum“ programmiert wird. Doch irgendwann werden die Programme fehleranfällig und unwartbar. Dies führt oft zum Tod des Softwareprojekts.

Wichtiger Tipp: bei größeren Softwareprojekten empfiehlt es sich, das Konzept vollständig zu erstellen, bevor auch nur die erste Codezeile geschrieben wird. Hierbei kann man Anleihen bei der Unified Modelling Language (UML) machen. UML ist ein Standardverfahren in der professionellen Programmierung und beinhaltet eine ganze Auswahl an Diagrammtypen wie z.B. Objekt-, Anwendungsfall- und Ablaufdiagramme, mit der eine Anwendung vor ihrer Programmierung zunächst modelliert wird.

Es geht bei der UML keineswegs darum, alle diese Diagrammtypen vorzuschreiben oder ein starres Regelwerk einzuführen, das sklavisch zu befolgen ist und einen bei der Arbeit nur behindert. UML hat schon seinen Zweck erfüllt, wenn man sich möglichst viele Gedanken zum Programm vor Beginn der Programmierung macht.

Die UML-Syntax übersteigt sicherlich die Bedürfnisse des Hobbyprogrammierers. Wer das Programmieren für Beruf oder Studium (Naturwissenschaften, Ingenieure, Wirtschaftswissenschaften) braucht, kann durchaus einen Blick über den Tellerrand werfen. Es geht ja auch in erster Linie um eine geeignete Systematik, mit der man die Anforderungen an das Programm zu Beginn möglichst gut zu beschreiben versucht, und einige UML-Diagramme können da wertvolle Dienste leisten. Hier ein Vorschlag für die Diagrammauswahl:

•    Anwendungsfälle: hierbei werden alle verschiedenen Transaktionsmöglichkeiten aufgeschrieben, die der Benutzer zur Programmbedienung haben soll. Ein Anwendungsfall ist eine in sich abgeschlossene Benutzeraktion. Für ein Planetariumsprogramm wären z.B. Karte exportieren, Karte speichern, Karte verschieben, Objekt anwählen, Zeitpunkt setzen, usw. jeweils ein eigener Anwendungsfall. Die Voraussetzungen und Ergebnisse eines jeden Anwendungsfalls sollten mit angegeben werden. (Beispiel)

•    Beim Klassenmodell werden die (Fach-)Klassen der Software identifiziert. Es wird versucht, die Dinge der realen Welt als Datenstrukturen in der Software (Klassen bei der objektorientierten Programmierung bzw. Module in der prozeduralen Programmierung) 1:1 nachzubilden. Sehr viele Aspekte der Programmierung, z.B. welche Methoden oder Funktionen implementiert werden müssen oder wie diese Gegenstände miteinander in Beziehung stehen, ergeben sich dann von selbst. Das Schichtenmodell sollte ebenso wie MVC darin Berücksichtigung finden. Selbst Dinge, die noch zu klären sind, können dort vermerkt werden. (Beispiel)

•    Beim Ablaufdiagramm (kann auch durch ein Flussdiagramm erfolgen) werden alle Pfade, die eine Benutzertransaktion gehen kann, aufgezeichnet. Dabei sind auch alle Fehlerfälle zu erfassen, die vorkommen können (Benutzer macht ungültige Eingabe, Datei nicht vorhanden, Voraussetzung nicht erfüllt, etc.). (Beispiel)

Abbildung: Beispiel eines Flußdiagramms einer Softwareanwendung. Das Aufzeichnen eines Fluß- oder Ablaufdiagramms hat schon vielen Programmierern geholfen, ihr Programm besser zu verstehen, etwaige Probleme zu erkennen und das Programm robuster zu gestalten.

Diese Vorgehensweise helfen, Fehler und Probleme schon sehr frühzeitig zu erkennen und von vornherein richtig darauf zu reagieren. Dies gilt umso mehr, wenn man schon ein wenig Übung darin hat. Man erkennt hier auch das Prinzip: es ist ein Top-Down-Verfahren. Man beginnt mit sehr allgemeinen Anforderungen und geht mit jedem neuen Diagramm immer weiter ins Detail. Eine Ordnung des Systems ergibt sich schon fast von selbst

Durch die Trennung von Modellierung der Software und ihrer Programmierung wird auch die Komplexität des Problems erheblich herabgesetzt.

 

Literatur & Links

 

Entwurfsmuster:


Thinking in patterns

Gamma et al: Entwurfsmuster

Freeman et al: Entwurfsmuster von Kopf bis Fuß



Software zuerst modellieren, dann implementieren:


Oestereich, Analyse und Design in UML 2



Model-View-Controller


http://de.wikipedia.org/wiki/MVC
http://www.dpunkt.de/java/Programmieren_mit_Java/Oberflaechenprogrammierung/40.html



Schichtenmodell:


http://de.wikipedia.org/wiki/Schichtenmodell

 

[zurück...]