Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

22.04.1983 - 

Structured-Analysis-Denken in Datenflüssen, Folge 4:

"Türen" steuern die Modulbeziehung

Nachdem in der dritten Folge der Serie von Dr. Peter Hruschka ausführlich auf die "Structured Analysis" eingegangen wurde, beschäftigt sich der Autor in dieser Ausgabe mit der Methode des modularen Designs. Das Ziel dieser Methode liegt darin, hierarchische Strukturen aufzubauen, um nach den Kriterien des Information Hiding zu einer exakten Beschreibung des Objektes zu gelangen. Die Kommunikation der Moduln findet dabei über definierte Schnittstellen statt.

Modular Design ist eine Methode, deren Hauptziel es ist, die Architektur eines Systems so zu gestalten, daß wesentliche Entwurfskriterien wie

- Unabhängigkeit (minimale Schnittstellen),

- Portabilität oder

- Änderungsfreundlichkeit gewährleistet sind (siehe Sch. 81).

Ziel von Modular Design ist die Schaffung einer hierarchischen Modulstruktur nach den Kriterien des Information Hiding. Da der Begriff "Modul" in vielen verschiedenen Zusammenhängen und vielen verschiedenen Bedeutungen benutzt wird, ist eine nähere Erklärung notwendig.

Module "reden" über Schnittstellen

Ein Modul ist die Einheit, die alle Funktionen (Programme) und Daten enthält, die zusammen entworfen und implementiert werden. Wenn Änderungen durchgeführt werden, dann ist das Objekt dieser Änderung das Modul, nicht die einzige Funktion.

Das Kriterium, weshalb Funktionen zusammengefaßt werden, ist das des "Information Hiding" /Par 71/. Jedes Modul verbirgt eine oder mehrere Entwurfsentscheidungen nach außen; es versteckt die Implementierungsdetails. Derartige Moduln werden oft als abstrakte Datentypen bezeichnet. Sie stellen die Realisierung eines Datentyps mit den zugehörigen Zugriffsfunktionen dar.

Die Kommunikation zwischen Moduln findet über Schnittstellen statt, die über die verborgenen Informationen nichts aussagen und damit unabhängig von der Implementierung sind.

Ein Modul kann also als Zaun betrachtet werden, der einige Objekte einschließt und von der Umwelt abkapselt. Diese Objekte sind Daten und Funktionen. In diesem Zaun gibt es einige Türen (die Schnittstellen) durch die man (kontrollierten) Zugriff zu Objekten hinter dem Zaun erlangen kann. Der Zaun hat aber keine Lücken, so daß unkontrollierte Verwendung von Objekten innerhalb des Zaunes ausgeschlossen ist.

Abbildung 9 zeigt beispielhaft die Struktur von zwei Moduln. Die Rahmen stellen die Einheit. Modul" dar (den "Zaun"); die Kästchen stellen die Funktionen dar und die Ovale die Daten.

Betrachten wir nun die Schnittstellen etwas genauer. Da ein Modul als Abstraktion von Entwurfsentscheidungen betrachtet wird, sollen sicherlich die Strukturen der Daten und die Algorithmen der Funktionen außerhalb des Moduls niemandem bekannt sein.

Exportschnittstellen sind Türen

Wesentliche Informationen für jemanden, der dieses Modul benutzen will, sind Angaben darüber, was das Modul leistet. Diese Information erhält man, sobald man weiß, welche Funktionen das Modul zur Verfügung stellt. Man braucht also nur die Funktionen zu kennen, nicht jedoch die Realisierung der Funktionen. Über Funktionen kann man dann auf Daten des Moduls zugreifen und diese manipulieren.

Bei Modular Design werden diese Informationen als Exportschnittstelle eines Moduls bezeichnet. Die Exportschnittstelle enthält Angaben über die Namen und Parameter von Funktionen, die von einem Modul nach außen zur Verfügung gestellt werden.

Funktionen, die in der Exportschnittstelle eines Moduls auftreten, werden als Exportfunktionen bezeichnet. Alle übrigen Funktionen eines Moduls (so F2 in Abbildung 10) werden als interne Funktionen ("hidden functions") bezeichnet.

Exportschnittstellen sind also eine Art von Türen, die im Modulzaun zur Umgebung enthalten sind.

Eine weitere Frage muß man sich stellen: Wer benutzt eigentlich diese Türen? Die Antwort darauf ist: andere Moduln - oder anders ausgedrückt: andere Teile des Programmsystems, die sich dieser Leistungen bedienen wollen. In Modular Design müssen diese anderen Moduln ihren Wunsch aber bekanntmachen. Sie müssen es offenlegen, daß sie Exportfunktionen anderer Moduln benutzen wollen.

In Modular Design bezeichnet man die Bekanntgabe der Wünsche als Importschnittstelle eines Moduls und die benutzten Funktionen als Importfunktionen. Die Importschnittstelle bildet die zweite Art von Türen im Modulzaun.

"Ein Modul A benutzt Modul B" ist so zu interpretieren, daß Funktionen des Moduls A Funktionen des Moduls B aufrufen. Modul A kann auf diese Weise. Funktionen (und dadurch auch indirekt Daten) eines anderen Moduls in kontrollierter Art verwenden.

Durch die so definierte "Benutzt"-Relation erhält man eine hierarchische Anordnung von Moduln. In Abbildung 11 benutzt das Modul A die Moduln B, C und E; Modul B benutzt Modul D; Modul C benutzt Modul D und E.

In Modular Design wird zyklische Benutzung zwischen Moduln ausgeschlossen. Dadurch erhält man immer eine eindeutige, hierarchische Struktur. Innerhalb eines Moduls sind zyklische Funktionsabrufe (direkt oder indirekt rekursive Funktionen) zulässig.

Modular Design hat als Ziel die hierarchische Modulstruktur. Diesem Ziel nähert man sich mit einem iterativen Verfahren an. Dazu gibt Modular Design noch Hilfestellung: - Modular Design benutzt die Information, die in der Anforderungsanalyse und -definitionsphase gesammelt wurde.