Modul (Software)

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Modul (Softwarearchitektur))

Ein Modul (neutrum, das Modul[1]) ist im Software Engineering ein Baustein eines Softwaresystems, der bei der Modularisierung entsteht, eine funktional geschlossene Einheit darstellt und einen bestimmten Dienst bereitstellt.[2]

Module sind charakteristisch für die Programmierung nach dem Programmierparadigma der modularen Programmierung. Module können weitere Module bzw. auch mit anderen Bezeichnungen benannte Konstrukte (wie Funktion, Prozedur, Klasse u. a.) enthalten. So ist die Zerlegung der Programmfunktionalität in einer Hierarchie möglich. Module können die in ihnen festgelegten Datenstrukturen und Methoden gegebenenfalls vererben bzw. fremden Modulen den Zugriff erlauben oder verbieten.

In den verschiedenen Programmiersprachen und Entwicklungsumgebungen und deren zeitlicher Entwicklung haben sich zahlreiche unterschiedliche Implementierungsformen von Modulen (mit zum Teil unterschiedlichen Bezeichnungen) entwickelt. Auch wird der Ausdruck Modul häufig synonym zu Begriffen wie Unterroutine, Prozedur, Unterprogramm, Programmteil, Programm-Modul[3][4] verwendet.

Als Speicherobjekt für Programmcode ist „Modul“ eine typisierende Bezeichnung für die Inhalte in einer Programmbibliothek, wobei ein Modul häufig eine Zusammenfassung thematisch zusammengehöriger Prozeduren, Funktionen, Klassen, Konstanten und ggf. weiterer Programmierobjekte ist. Module gibt es auch für Hauptprogramme, sie können alternativ unterschiedliche Arten von Programmcode (wie Quelltext, Zwischencode, Maschinenprogramm) repräsentieren.

Zu unterscheiden ist ein Modul von einer Komponente, die in der Funktionalität eine Hierarchieebene höher angesiedelt ist und die (Basis-)Funktionalitäten von Modulen zu (fachspezifischen) Diensten kombiniert. Jedoch werden derartige Komponenten im Sprachgebrauch (zum Beispiel bei SAP[5]) manchmal ebenfalls „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.[6] Entwurf und Definition von Modulen und Schnittstellen ist Teil der Designphase in der Softwareentwicklung.

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 können:

Module als Strukturierungsmittel im Quelltext

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 kompiliertes Unterprogramm aufgerufen werden.

Klassen in der Objektorientierung

Eine spezielle Form von Modul/Modularisierung sind die 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 anderen Modulen sind in der Regel statisch.

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.

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.
Zusammenwirken von aufrufendem und aufgerufenem Programm(teil) im Detail: Siehe Unterprogramm.

Module 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“,[7] 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.

Der Modulbegriff bei SAP

In der Software von SAP werden einzelne Anwendungen „Modul“ genannt.[8] Dies entspricht jedoch dem softwaretechnischen Modulbegriff nur im weitesten Sinn, und gilt als Zusammenfassung von Funktionalität auf einem betriebswirtschaftlichen Level, den ein Anwender optional erwerben und nutzen kann.

Siehe auch

Weblinks

Wiktionary: Modul – Bedeutungserklärungen, Wortherkunft, Synonyme, Übersetzungen

Einzelnachweise

  1. ↑ Duden, Band 5, Fremdwörterbuch, 7. neu bearbeitete und erweiterte Auflage, Mannheim 2001
  2. ↑ Gabler [1] Definition Modul
  3. ↑ psion user-club OPL-Kurs Teil 4 [2] denn einen Teil der Module („synonym: Prozeduren, ...“) werden wir wiederverwenden
  4. ↑ econstor.eu [3] Seite 19: ... inwieweit ein Programm in Unterprogramme (Module) zerlegt ist, ...
  5. ↑ tse.de [4] SAP-R3-Module
  6. ↑ Y. Malayia, J. Denton,: Module size distribution and defect density. (pdf) (Nicht mehr online verfügbar.) In: 11th International Symposium on Software Reliability Engineering (ISSRE’00). Oktober 2000, archiviert vom Original am 1. August 2018; abgerufen am 1. August 2018 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/pdfs.semanticscholar.org
  7. ↑ Microsoft Erstellen einer VBA-Prozedur Funktionen in Standard- oder Klassenmodulen (Memento vom 8. April 2014 im Internet Archive)
  8. ↑ SAP ERP Was ist ERP? [5] „Jede Anwendung, also jedes ERP-Modul, ist auf einen Geschäftsbereich ausgerichtet.“
Abgerufen von „https://de.wikiup.org/index.php?title=Modul_(Software)&oldid=221535804“