6 Modularisierung und Software-Architekturen (S. 143-144)

Die Qualität eines Software-Produktes hängt in besonderem Maße von der Güte des Entwurfes ab. Die Hauptaufgabe im Rahmen der Entwurfsphase besteht darin, die Architektur des geplanten Software-Produktes festzulegen. Ausgehend von einer Systemspezifikation wird in der Entwurfsphase die Systemarchitektur mit dem Ziel entworfen, den in der Systemspezifikation festgelegten Funktionsumfang mit möglichst geringem Aufwand verfügbar zu machen und zu gewährleisten, dass die Qualitätsforderungen erfüllt und die Architektur an sich ändernde Anforderungen schnell, sicher und mit möglichst wenig Aufwand angepasst werden kann.

Der Entwurfsprozess umfasst grob skizziert die folgenden Tätigkeiten: problemadäquate Zerlegung des Gesamtsystems in Module (= Komponenten) und Spezifikation der Wechselwirkungen zwischen den Modulen; Festlegung der Anforderungen an die Module, das heißt, Festlegung der Modulschnittstellen; Entwurf der Algorithmen zur Bereitstellung der durch die Modulschnittstellen definierten Funktionalität. Der Modularisierung – mit Bedacht auf die Wiederverwendung bereits vorhandener Komponenten – kommt beim Entwurf und bei der Gestaltung der Systemarchitektur zentrale Bedeutung zu.

Der Blick auf die Modularisierung (= Strukturierung) eines Software-Systems erlaubt uns eine „grobkörnige" Betrachtung des Software-Produktes, aus der wir insbesondere feststellen können, welche Schnittstellen die Module haben und wie die Module untereinander interagieren. Im Mittelpunkt der Gestaltung der Software-Architektur steht daher die Modularisierung beziehungsweise Strukturierung des Software-Systems. Die Qualität der Modularisierung von Software-Systemen, die in der Entwurfsphase des Software-Entwicklungsprozesses festgelegt wird, ist ausschlaggebend für den Verlauf der weiteren Entwicklungsphasen und die Qualität des Endproduktes. Außerdem schafft eine adäquate Modularisierung die technische Voraussetzung für die Schaffung wiederverwendbarer Software-Komponenten.

In diesem Abschnitt führen wir zuerst das Modulkonzept als Grundlage für die Konstruktion von Software-Komponenten ein (Abschnitte 6.1 bis 6.4). Um die Beschreibungsproblematik von Software-Architekturen einigermaßen in den Griff zu bekommen, ist ein Teil dieses Kapitels der Diskussion von Architekturmustern gewidmet. Sie sind ein Mittel zur Beschreibung der Architektur von Software-Systemen (Abschnitt 6.5). Eine der Schwierigkeiten beim Entwurf einer Software-Architektur besteht darin, dass nicht exakt definierbar ist, was eine „gute" Modularisierung ausmacht und wie wir vorzugehen haben, um zu Aussagen zur Güte der Architektur zu gelangen. In Abschnitt 6.6 stellen wir die Software Architektur Analyse Methode (SAAM) vor, die ein pragmatischer Lösungsansatz zur Evaluierung einer Software-Architektur ist.

Die aspektorientierte Programmierung kann als Querschnittsmodularisierungstechnik gesehen werden, die zu einer flexiblen Modularisierung führt. Ihr ist ein eigener Abschnitt (Abschnitt 6.7) gewidmet. Die aspektorientierte Programmierung gehört zu den jüngeren Entwicklungen im Bereich der Modularisierungstechniken und ist ein in den letzten Jahren viel diskutiertes Forschungsgebiet (siehe dazu zum Beispiel die Web- Referenzen zu aspektorientiertem Programmieren und Colyer et al, 2004). Das zeigt, dass die Forschung im Bereich der Modularisierung von Software-Systemen bei weitem noch nicht abgeschlossen ist.

6.1 Software-Module

Module sind, wenn man die Entwicklung von Programmiersprachen und von Strukturierungskonstrukten betrachtet, Ende der 1970er Jahre eingeführt worden, weil die bis dahin benutzten Strukturierungskonstrukte Prozedur und Funktion keine der wachsenden Systemkomplexität angemessene Strukturierung erlaubten. Prozeduren und Funktionen repräsentieren Algorithmen. Das heißt, sie fassen einzelne Anweisungen zu einer Einheit zusammen. Module hingegen fassen mehrere Prozeduren und/oder Funktionen sowie die Daten, auf denen diese operieren, zu einer Einheit zusammen. Man unterscheidet zwischen der Schnittstelle eines Moduls und dessen Implementierung. Die (Programmier-)Schnittstelle führt die Namen und Parameter der Funktionen, Prozeduren und Daten an, die von anderen Modulen verwendet werden können. Wir definieren einen Modul (=Software-Komponente) als ein Stück Software mit einer Programmierschnittstelle.

Das mögliche Zusammenspiel mehrerer Module ist durch ihre Programmierschnittstellen festgelegt. Genau genommen ist zwischen zwei Arten von Schnittstellen zu unterscheiden: Die Programmierschnittstelle ist die Exportschnittstelle, die angibt, welche Operationen und Daten ein Modul anderen Modulen zur Verfügung stellt. Die Importschnittstelle gibt an, was ein Modul von anderen Modulen benutzt. Wenn wir nachfolgend nicht explizit zwischen Export- und Importschnittstelle unterscheiden, meinen wir mit Schnittstelle die Exportschnittstelle.

Reiser und Wirth, 1992, beschreiben das Modulkonzept wie folgt:

It provides mechanisms for:

1. structuring of a program into independent units;

2. the declaration of variables that keep their value for the duration the module is active (that is, in memory) – these variables are called global to the module;

3. export of variables and procedures to be used in other modules. The module therefore provides the facilities for abstractions.