Bei der Entwicklung von Software verspricht der Entwurf mehrfach verwendbarer Bestandteile Arbeitsersparnis. Je früher aber die an Case-Tools angeschlossenen Generatoren ansetzen oder je höher die Zielsprache angesiedelt ist, desto seltener werden sich mehrfach verwendbare Softwaremodule schreiben lassen.
Ich möchte hier zwischen Mehrfach-Verwendbarkeit von Software in großen und im kleinen unterscheiden. Im großen umfaßt der Begriff die Standardsoftware oder Basissoftware wie Datenbanksysteme. Im kleinen bedeutet er die Konstruktion mehrfach brauchbarer Module bei der Entwicklung von Individualsoftware, eventuell unter Zuhilfenahme von Case-Tools. Im folgenden ist an die Mehrfach-Verwendbarkeit im kleinen gedacht.
Case-Tools gehen oft im Top-down- oder im Outside-in-Verfahren vor. Ausgangspunkt ist der Dualismus von Daten (passiv) und Funktionen (aktiv), was man in der Objektorientierung auch mit den Aspekten "structure" und "behaviour" bezeichnet. Beim Top-down-Vorgehen lautet das Ziel für die aktive Seite, einen möglichst nahtlosen Übergang von den betrieblichen Funktionen hin zu den Softwaremodulen zu finden.
Auf der Suche nach einer "kritischen Ebene"
Verfeinerung durch Zerlegung findet sowohl für Daten als auch für Funktionell statt. Jede Zerlegung muß irgendwann einmal enden. Datenmäßig hört sie bei Datenelementen, funktionsmäßig bei "Funktionselementen" auf. Je tiefer die Zerlegung geht, desto weniger kontextgebunden ist die funktionale Einheit und umso eher mehrfach verwendbar. Die Frage lautet: Gibt es so etwas wie eine "kritische Ebene" für die Mehrfach-Verwendbarkeit von Funktionselementen?
Betrachten wir zwei Extreme: Auf der obersten Ebene stehen betriebliche Funktionen (genauer gesagt ihre Durchdringung mit Software) wie Vertrieb, Auftragsabwicklung und Rechnungswesen. Niemand käme auf die Idee, hier bereits an Mehrfach-Verwendbarkeit zu denken.
Was auf der untersten Ebene steht, ist abhängig vom Zielsystem. Die unterste denkbare Ebene wird also vom Befehlsvorrat des Zielrechners repräsentiert. Die Mehrfach-Verwendbarkeit funktioniert dort hervorragend, sonst würde man unsere Rechner ja nicht universell programmierbar nennen. Üblich ist bei der Softwareentwicklung der Sprachvorrat einer 3GL/4GL mit noch hinreichender Mehrfach-Verwendbarkeit.
Die kritische Ebene, sofern es eine gibt, muß irgendwo zwischen den beiden Extremen liegen. Anders gefragt: Gibt es überhaupt Mehrfach-Verwendbarkeit oberhalb der Sprachebene des Zielsystems? Je höher die Sprachebene, desto seltener ist die Frage mit "ja" zu beantworten. Das beginnt bereits damit, daß neue Datentypen teilweise Aufgaben übernehmen, die früher in kleinen allgemeinen Routinen steckten.
Doch vielleicht ist eine höhere funktionale Ebene für unsere Zwecke ergiebiger. Betrachten wir beispielsweise die Teilaufgabe "Rabatt errechnen" im Rahmen eines Auftragssystems. Das Errechnen von Rabatten mag in verschiedenen Situationen erforderlich sein, die jedoch kontextabhängig sein können. Einflußgrößen sind etwa die Artikelgruppe, die Mengenstaffel, die Kundenklasse oder ein spezielles Abkommen mit dem Kunden.
Das vermutliche Fazit: Für echte Mehrfach-Verwendbarkeit ist die Abhängigkeit von Spezialbedingungen zu stark. Also werfe man Ballast ab und reduziere die Funktionalität auf eine Formel "Listenpreis mal Ermäßigungssatz ergibt Verkaufspreis", wobei die Regeln für das Zustandekommen des Rabattsatzes außen vor bleiben. Einmal beim Verallgemeinern, läßt sich die Mehrfach-Verwendbarkeit weiter erhöhen über " X-Preis in DM mal Prozentsatz ergibt Y-Preis in DM" und "X-Betrag in DM mal Prozentsatz ergibt Y-Betrag in DM" bis hin zu "Zahl1 mal Zahl2 ergibt Zahl3". Damit ist man aber endgültig auf die Ebene der Zielsprache abgesunken!
Betrachten wir ein Beispiel, bei dem die Mehrfach-Verwendbarkeit durch sinnvolle Parametrisierung zustande kommt. Die Aufgabe lautet: "Berechnen des kumulierten Auftragseingangs bezogen auf einen Zeitraum [X 1, X2] und eine Artikelgruppe Y".
Benutzt man für die Datenhaltung ein relationales Datenbanksystem, so läßt sich diese Aufgabe mit nur einem - noch dazu statischen - SQL-Statement lösen. Als Argument, das SQL-Statement noch mit einer eigenen Modul-Hülle zu überziehen, bliebe somit nur die Unabhängigkeit von der Datenhaltung des Zielsystems; das hat allerdings nichts mit einer funktionalen Mehrfach-Verwendbarkeit zu tun.
Nehmen wir schließlich ein Beispiel, das zum einen genügend abstrakt ist, um mehrfach verwendbar zu sein, und andererseits genügend komplex ist, um nicht bereits einem Statement der Zielsprache zu entsprechen. Ein solches Beispiel ist die Aufgabe "Lösen eines linearen Gleichungssystems". Derlei ist aber sicher Bestandteil einer bereits mitgelieferten Softwarebibliothek und braucht als Individualsoftware nicht mehr entwickelt zu werden.
Fazit: Die Domäne selbstgestrickter mehrfach verwendbarer Softwaremodule wird mehr und mehr aufgezehrt sowohl von oben durch Standard-Software als auch von unten von der immer höheren Sprachebene der Zielsysteme. Auch Top-down-orientierte Case-Tools, die einen Programmgenerator beinhalten, tragen dazu bei.
Die traditionellen Hochsprachen leben als Zielsprache des Generators wieder auf, da sie sozusagen noch einen "Mindestabstand" einhalten zwischen der von Personen durchzuführenden funktionalen Zerlegung mit Funktionsbeschreibung in Pseudocode und dem fest vorgegebenen Vorrat an mehrfach verwendbaren Konstrukten der Zielsprache. Ein weiterer Grund ist die fehlende Standardisierung der 4GLs, die sie als Generator-Output wenig sinnvoll erscheinen läßt.
Die Frage, inwieweit mehrfach verwendbare funktionale Einheiten sinnvoll sind, verlagert sich im Top-down-Sinne nach oben. Die Entscheidung wird seltener positiv ausfallen.