Modul (Software)
Ein Modul (neutrum, das Modul[1]) ist eine abgeschlossene funktionale Einheit einer Software. In verschiedenen Programmiersprachen, in verschiedenen Umfeldern der Softwareentwicklung und im lauf der Jahrzehnte haben sich mitunter verschiedene Bedeutungen des Begriffs „Modul“ entwickelt. Die verbreitetste Bedeutung ist, dass ein Modul eine Zusammenfassung thematisch zusammengehöriger Prozeduren, Funktionen, Klassen, Konstanten und ggf. weiterer Programmierobjekte ist, was es zu einer Vorstufe einer Bibliothek macht. (Zum Beispiel bei VBA[2]) Andererseits wird in manchen Programmierumfeldern der Begriff „Modul“ mitunter gleichgesetzt mit „eine Unterroutine“, kann aber auch (als „Programmmodul“) das Hauptprogramm meinen. Aufgabe eines Moduls ist im Allgemeinen eine Berechnung oder Bearbeitung von Daten, die mehrfach durchgeführt werden muss.
Das Modul als Sammlung von Prozeduren u. ä. ist Basis des Programmierparadigmas der modularen Programmierung. Hier versteht man unter Modul im engeren Sinn entwicklungstechnisch eine Sammlung von eigenständigen Programmteilen, die über eine modulspezifische Schnittstelle aufgerufen werden, zum Beispiel als Funktion oder Prozedur. Ein Modul kann selbst weitere Module einbinden (und Prozeduren aus diesen aufrufen) – so ist eine Hierarchie von Programmaufrufen möglich. Die in Modulen festgelegten Datenstrukturen und Methoden können gegebenenfalls vererbt und von Datenstrukturen in anderen Modulen geerbt werden.
Nicht zu verwechseln ist ein Modul mit einer Komponente, die in der Funktionalität eine Hierarchieebene höher angesiedelt ist und die (Basis-)Funktionalitäten von Modulen zu (fachspezifischen) Diensten kombiniert. Trotzdem werden derartige Komponenten im Sprachgebrauch (zum Beispiel bei SAP[3]) manchmal auch wiederum „Module“ genannt.
Gründe für das Aufteilen von Programmen in Module
Für modulare Programmierung im Allgemeinen
- Aus der ursprünglichen Sicht der Assemblerprogrammierung war der Grund der Aufteilung die mehrfache Verwendung der gleichen Befehlsfolge an unterschiedlichen Stellen des Programms, somit Einsparung von Speicherplatz und die Vermeidung von Codewiederholungen.
- In modernen Technologien des Softwareengineering ist ein weiterer wichtiger Grund die Strukturierung des Softwaredesigns: Der Quelltext von Programmen besteht heute zu Gunsten der besseren Wartbarkeit, Verständlichkeit und Fehlerbehebung aus jeweils kurzen und übersichtlichen Einzelteilen (siehe Modulare Programmierung). Nach diesem Prinzip werden in sich abgeschlossene Teilaufgaben (z. B. Leseroutinen, Gültigkeitsprüfungen, aufwändige Berechnungen) als strukturell getrennte Unterroutinen implementiert (und ggf. an mehreren Stellen im Programmcode aufgerufen). Durch derartige ‚Auslagerungen‘ bleibt der Code übersichtlich; der rechnerinterne Zeit- und Verwaltungsaufwand für die Aufrufe spielt auf modernen Rechenmaschinen praktisch keine Rolle mehr.
Für eigenständige Module
- Ein Aspekt der Softwarearchitektur ist die Herstellung von Unterprogrammen zur Verwendung in mehreren Computerprogrammen/-Anwendungen. Bestimmte technische oder betriebliche Funktionen (zum Beispiel eine Prüfziffernberechnung) können so beispielsweise unternehmensweit einheitlich genutzt werden.
- Module können in unterschiedlichen Programmiersprachen separat erstellt und kompiliert und in Programmbibliotheken zur Verwendung bereitgestellt werden.
- Funktionalitäten können nach dem Baukastenprinzip optional eingebunden werden.
- Für kommerzielle Anwendungen können einzelne Bestandteile separat lizenziert werden.
- Mehrere Entwickler oder Entwicklergruppen können Teile einer Anwendung unabhängig voneinander erstellen und testen.
- Eigenständige Module sind bei Bedarf meist unabhängig von ihren Aufrufprogrammen änderbar (solange ihre Schnittstelle identisch bleibt). In besonderem Maß gilt dies für dynamisch ladbare Module.
Einsatz/Verwendung
Der Einsatz von Modulen entspricht dem Prinzip der Kapselung (encapsulation); denn:
- Die Schnittstelle eines Moduls enthält/benennt nur die Daten(bereiche), die das Modul als Eingabe und Ergebnis der Verarbeitung braucht/liefert.
- Die Implementierung enthält den tatsächlichen Programmcode.
Außerhalb des Moduls bleiben die Verarbeitungsweise und evtl. Modul-eigene Daten verborgen (Prinzip des information hiding).
Große, komplexe Programme können durch den Einsatz von Modulen gegliedert und strukturiert werden. Dies kann in vielerlei Hinsicht von Nutzen sein (vergleiche auch Modularität). Beispielsweise hat die Größe der Module einen Einfluss auf die Fehlerdichte – sie ist am geringsten bei einer Modulgröße von 200 bis 400 Lines of Code.[4] Entwurf und Definition von Modulen und Schnittstellen ist Teil der Designphase in der Softwareentwicklung.
Zu unterscheiden sind Module von den Klassen der objektorientierten Softwareentwicklung:
- Von Klassen können Exemplare in Form von Objekten erzeugt (instanziiert) werden,
- Klassen können Eigenschaften an andere Klassen vererben,
- Polymorphismus erlaubt es Klassen, Eigenschaften zur Laufzeit zu verändern – Beziehungen zwischen Modulen sind statisch.
Das Modulkonzept wurde zuerst von David Parnas publiziert.
Zahlreiche Programmiersprachen unterstützen das Modulkonzept durch integrierte Sprachmittel, beispielsweise Ada, COBOL, D, F, Fortran, Haskell, Java, ML, Modula-2, Oberon, Component Pascal und PL/I. Daneben sind Skriptsprachen wie Perl, Python, PHP und Ruby zu nennen.
Beispiele für Varianten von Modulen
Die nachfolgenden Beispiele zeigen, dass Module in unterschiedlichen technischen Ausprägungen auftreten:
Module als Strukturierungsmittel
Module sind nach den Prinzipien der modularen Programmierung „logische Teilblöcke“, in die die Aufgabenstellung eines Computerprogramms zerlegt wird. Das Modul ist häufig nur als individueller Codeabschnitt im Quelltext definiert, bei OOP kann dieser eine Klasse sein. In diesem Codeabschnitt/Modul können weitere Module enthalten sein oder als eigenständiges, getrennt compiliertes Unterprogramm aufgerufen werden.
Objektmodul (Großrechner IBM-Welt)
Aus einem Quelltext erzeugt ein Compiler oder ein Assembler ein sogenanntes Objektmodul, dessen Anweisungen in Form von Maschinencode in einer Programmbibliothek abgelegt werden. Um ein Programm ausführen zu können, wird sein Objektcode mit dem Objektcode aller aufgerufenen Unterprogramme mit einem sog. Linker 'zusammengebunden', wobei u. a. die Einsprungadressen der Unterprogramme eingesetzt werden. Ergebnis ist ein Lademodul.
Der Aufruf eines Unterprogramms geht im Beispiel zweier fiktiver Module wie folgt vor sich. Siehe auch nebenstehende Grafik:
- Quellcode des rufenden Programms (im Beispiel COBOL-ähnlicher Code):
* Daten:
A.
>Struktur von A, z. B.:
Ax >Format und Längen
Ay ...
B.
B1 (Definitionen, ggf. weitere Teilfelder)
B2 (Definitionen)
B3 (Definitionen)
* Funktionscode:
A-ROUTINE.
A-1. >Befehle-1
Call UPRO Using A, B2.
A-2. >Befehle-2, z. B. Auswerten und Verarbeiten Rückgabewert(e)
A-ROUTINE Exit.
>beliebige weitere Routinen/Befehle
* Programm-Ende
- Quellcode des Unterprogramms, ggf. aus einer anderen Programmiersprache:
- Der daraus erzeugte Objectcode ist im Lademodul des Hauptprogramms eingebunden.
* Datendefinitionen:
A-DAT >Format und Sub-Struktur wie in A; andere Bezeichner möglich!
B-2 dto.
C-x z. B. eigene Definitionen von UPRO
* Funktionscode:
Entry UPRO Using A-DAT, B-2.
>Feldbezeichnungen von Using ggf. abweichend, Reihenfolge identisch zu 'Call'!
>Weitere Befehle des Unterprogramms:
>Mit vollem Zugriff (auch ändernd) auf die Struktur (Einzelfelder) von A-Daten und B2.
Ggf. setzen Returncode, z. B. in B-2 (= B2)
Exit = UPRO-Ende
- Ablauf des Unterprogramm-Aufrufs (Call und Return):
- (vom Compiler generierter Code, bei Assemblerprogrammen vom Programmierer codiert)
* Call im rufenden Programm:
Setzt in einer (vom Compiler angelegten) Hauptspeicher-Adressliste
mit 2 Einträgen die Adresse von A und von B-2
Setzt einen Zeiger (Register, konkret R1) auf die Adressliste
Setzt einen Zeiger (Register 14) auf die Rückkehradresse A-2.
Setzt einen Zeiger (Register 13) auf die Register-Savearea,
(Speicherbereich automatisch vom Compiler reserviert, Details siehe[5])
Lädt Register 15 mit der Adresse (Entrypoint) des Unterprogramms
(die z. B. vom Linkage Editor im Maschinenprogramm eingesetzt wurde)
Verzweigt über R15 in das Unterprogramm
* Entry im Unterprogramm:
>Sichern der Registerstände in die Savearea des rufenden Programms (lt. R13)
Speichern der Adresse dieser Savearea (= Inhalt R13) in einem eigenen Speicherbereich
>Übernehmen der übergebenen Variablen (aus Adressliste lt. R1):
Adr(A-DAT) = aus Adressliste(1. Adresse), Adr(B-2) = aus Adressliste(2. Adresse)
>Verarbeitung – mit Zugriff auf übergebene und eigene Daten sowie individueller Registernutzung
* Rücksprung ins rufende Programm:
>Laden R13 mit der gespeicherten Adresse der Savearea
Rückladen aller Register aus der Savearea lt. R13
>Exit: Verzweigung (= Rückkehr) zu Adresse A-2 im rufenden Programm (lt. Inhalt R14)
Nach demselben Schema (Registerkonventionen, Savearea) könnte das Modul weitere Untermodule aufrufen. Das dazu erforderliche Sichern der Registerstände zum Zeitpunkt des Aufrufs erfolgt jeweils in einer „Savearea“ genannten Speicherstruktur aufrufender Module, die folgenden Aufbau aufweist:
|_A_|_B_|_C_|_D1_|_D2_|_.._|_D15_| = 18 „Fullwords“ (je 4 Bytes) = 72 Bytes
A = nicht belegt, reserviert
B = Adresse der Savearea des aufrufenden Moduls; vom aufgerufenen Modul in seiner eigenen Savearea gesetzt
C = Adresse der Savearea des aufgerufenen Moduls; vom aufgerufenen Modul in der Savearea des aufrufenden Moduls gesetzt
Dn = Inhalt der Register „14 bis 12“ (entspricht R14,R15,R0,R1 .. R12):
vom aufgerufenen Modul in der Savearea des aufrufenden Moduls gespeichert und beim Rücksprung zurückgeladen.
Über die Inhalte von Speicherstelle B und C sind die Saveareas der beteiligten Module in ihrer Aufrufreihenfolge miteinander verkettet; sie zeigen den Stand des jeweils letzten Modulaufrufs, womit sich z. B. im Debug-Modus bei Modultests die Aufruftiefe und die -Reihenfolge ermitteln und nachvollziehen lässt. Einen detaillierten Assembler-Programmcode für die Savearea-Behandlung zeigt dieses Beispiel.
Lademodul (Großrechner IBM-Welt)
Variante A: Hauptprogramme und ihnen (= statisch) hinzugebundene Unterprogramme werden zu einem gemeinsamen ausführbaren Programm als gemeinsames ‚Lademodul <Hauptprogramm>‘ in einer Programmbibliothek abgestellt. Von dort aus können sie zum Beispiel über JCL-Aufrufe (EXEC <Pgm>) aufgerufen werden.
Variante B: Sollen Unterprogramme erst beim Programmlauf (= dynamisch) geladen werden, so wird aus ihrem Objektcode ein einzelnes ‚Lademodul <UPRO>‘ erzeugt, das durch einen Ladebefehl im aufrufenden (Haupt-)Programm über das Betriebssystem geladen und danach – wie bei statisch gebundenen Modulen – zur Verarbeitung aufgerufen wird.
Der Modulbegriff bei MS Access und VBA
Die Entwicklungsumgebung MS Access versteht unter ‚Modul‘ eine Zusammenfassung aller Prozeduren bzw. Funktionen, die für ein Objekt, zum Beispiel ein Formular oder einen Bericht in VBA angelegt wurden. In solchen Modulen können weitere, untergeordnete Teilfunktionen angelegt und ausgeführt werden, zum Beispiel „Ereignisprozeduren“,[6] mit denen beim Ändern eines bestimmten Datenfelds in einem Formular eine individuelle Prüfung erfolgen soll. Zusätzlich können zum Beispiel Module für global gültige Daten (z. B. ‚GLOBAL DATA‘) oder für global ansprechbare Funktionen (etwa ‚GLOBAL CODE‘) angelegt werden.
Siehe auch
Weblinks
Einzelnachweise
- ↑ Duden, Band 5, Fremdwörterbuch, 7. neu bearbeitete und erweiterte Auflage, Mannheim 2001
- ↑ Microsoft Erstellen einer VBA-Prozedur Funktionen in Standard- oder Klassenmodulen ( vom 8. April 2014 im Internet Archive)
- ↑ SAP-R3-Moduletse.de
- ↑ Y. Malayia, J. Denton,: Module size distribution and defect density. (pdf) In: 11th International Symposium on Software Reliability Engineering (ISSRE’00). Oktober 2000, abgerufen am 1. August 2018 (englisch).
- ↑ IBM SAVE
- ↑ Microsoft Erstellen einer VBA-Prozedur Funktionen in Standard- oder Klassenmodulen ( vom 8. April 2014 im Internet Archive)