1 Identifikation/Definition der Methode
/ Booch, 94 /
2 Kurzcharakteristik der Methode
Ziel und Zweck
Die Methode dient zur objektorientierten Systementwicklung. Sie kann während des physischen Softwareentwurfs eingesetzt werden. Zielsetzung ist es, die Zuordnung von Klassen und Objekten zu Modulen vorzunehmen und Compilierungsabhängigkeiten zwischen Modulen zu zeigen.
Unter dem Begriff "Modul" ist hier eine Programmeinheit zu verstehen, die als Baustein für die physische Softwarestruktur eines Systems dient. Sie wird durch einen Namen identifiziert und enthält Deklarationen, ist im Vokabular einer bestimmten Programmiersprache ausgedrückt und realisiert einige oder alle Klassen und Objekte des logischen Softwareentwurfs. Ein Modul besteht normalerweise aus zwei getrennten Compilierungseinheiten: seiner Schnittstelle (Spezifikation) und seiner Implementation (Rumpf).
Darstellungsmittel
Die Methode wurde von Grady Booch definiert und ist Bestandteil der komplexen Methode "Object-Oriented Analysis and Design (OOAD)" / Booch, 94 /.
Die Modulstruktur der Software kann in Moduldiagrammen graphisch dargestellt werden. Es sind Symbole vordefiniert, mit denen Hauptprogramme, Spezifikationen und Rümpfe namentlich identifiziert werden können. Sind diese Symbole nicht ausreichend, um für die zu verwendende Programmiersprache die separaten Compilierungseinheiten zu unterscheiden, können zusätzliche Symbole definiert werden. Detailinformationen, die einzelne Module näher spezifizieren, können in Textform in ergänzenden Modulbeschreibungen abgelegt werden.
Spezifikationen entsprechen in der Programmiersprache C++ beispielsweise .h-Dateien, die Rümpfe sind die .cpp-Dateien. Die Namen der Module sollten hier mit den Namen der zugehörigen Dateien übereinstimmen. Dateiendungen werden nicht benötigt, da sie in Verbindung mit dem Symbol redundant wären.
Die erste standardisierte Programmiersprache, die eine objektorientierte Softwareentwicklung unterstützt, ist Ada 95. Hier werden Module durch Programmeinheiten ("Program Units") ausgedrückt, für die ebenfalls Spezifikationen und Rümpfe unterschieden werden können.
Compilierungsabhängigkeiten werden durch Pfeile ausgedrückt, die auf die Module zeigen, für die die Abhängigkeit besteht. Beispiele sind die "#include"-Beziehung in C++ und die "with"-Beziehung in Ada.
Bei komplexen Systemen kann im physischen Systementwurf die Gliederung in eine Vielzahl von Modulen notwendig sein. Um die Komplexität und die mögliche Unübersichtlichkeit in der Darstellung zu bewältigen, ist mit Hilfe eines eigenen Symbols die Definition physischer Subsysteme möglich. Diese gruppieren physisch zusammengehörige Module für Klassen, Objekte, freie Unterprogramme und Bibliotheken.
Die Zuordnung von Modulen und Klassen ist gegeben, wenn für jede Klasse eine Spezifikation und ein Rumpf definiert werden. Die Zuordnung von Objekten, freien Unterprogrammen oder Bibliotheken sowie die Zusammenfassung von Klassen in einem Modul müssen jedoch spezifiziert werden. Dies kann in den Moduldiagrammen durch die Zuordnung von Bezeichnern zu Symbolen oder in separaten Klassen- oder Modulbeschreibungen in Textform geschehen.
Der von Booch definierte physische Softwareentwurf ist in die Unified Modeling Language (UML) / Booch, Rumbaugh, Jacobson, 97 / eingeflossen. Die dort definierten "Component Diagrams" stellen einen generalisierten Ansatz der Moduldiagramme dar.
Funktioneller Ablauf
Die Erstellung der Moduldiagramme ist während des Entwurfs durchzuführen, wenn die Beziehungen zwischen den Klassen und Objekten implementierungstechnisch sowohl aus logischer als auch aus physischer Sicht spezifiziert werden. Sie sind in Anlehnung an die Vorgehensweise der verwendeten komplexen Entwicklungsmethode in unmittelbarer Abstimmung mit der Klassen-/Objektmodellierung (Methode KOM ) und der Prozeßbildung (Methode PRODIAG ) zu erzeugen.
Bei der Booch-Methode werden die Moduldiagramme während des Entwurfs in iterativen Durchläufen erzeugt. Bei jedem Durchlauf entstehen detailliertere, verfeinerte oder auch neue bzw. geänderte Module und Beziehungen.
3 Grenzen des Methodeneinsatzes
Die Verwendung der Methode ist immer dann angebracht, wenn die zu verwendende Programmiersprache physische Architekturen konzeptionell unterstützt. Wenn nicht, sind Moduldiagramme unnötig.
Unterstützt die zu verwendende Programmiersprache Compilierungseinheiten, die durch die vordefinierten Symbole nicht abgedeckt werden, so sind zusätzliche Symbole zu definieren.
4 Detaillierung der Methodenzuordnung
4.1 MODIAG in Aktivität SE 4.1-SW "SW-Architektur entwerfen"
Mit Hilfe der Moduldiagramme können SW-Komponenten und SW-Module aus physischer Sicht spezifiziert werden. SW-Komponenten können als "physische Subsysteme" symbolisiert werden. Die Modulbildung aus physischer Sicht ist abzustimmen mit der fachlichen Gliederung, die durch eine Subsystemmodellierung (vgl. Methode SSM ) und die Klassen-/Objektmodellierung (vgl. Methode KOM ) durchgeführt wurde. Werden aus logischer und physischer Sicht unterschiedliche Gliederungen angedacht, so sind diese aufeinander abzustimmen. Die Zuordnung von Hauptprogrammen, Klassen, Objekten, freien Unterprogrammen und Bibliotheken zu Modulen ist zu spezifizieren. Detailinformationen sind in Modulbeschreibungen abzulegen.
In Kombination mit den Methoden "Klassen-/Objektmodellierung" und "Subsystemmodellierung" deckt die Methode im Produkt "SW-Architektur" die Teilprojekte "Lösungsvorschläge" und "Modularisierung/Datenbankentwurf" aus Sicht der Architekturelemente ab.
Die in den Moduldiagrammen dargestellten Compilierungsabhängigkeiten liefern Anhaltspunkte darüber, welche internen Schnittstellen zwischen den SW-Modulen einer SW-Einheit existieren. Diese Angaben fließen in das Teilprodukt "Systeminterne Schnittstellen" des Produkts "Schnittstellenübersicht" ein.
4.2 MODIAG in Aktivität SE 5.1-SW "SW-Komponente/-Modul/Datenbank beschreiben"
Moduldiagramme und Modulbeschreibungen legen u. a. fest, welche Klassen und Objekte einem Modul zugeordnet werden, und bilden zusammen mit Klassen-/Objektmodellen, Subsystemmodellen, Zustandsmodellen und Interaktionsmodellen die Informationsquelle für die Beschreibung der SW-Komponenten und SW-Module im "SW-Entwurf".
Die Methode deckt im Produkt "SW-Entwurf" das Teilprodukt "SW-Komponenten-/SW-Modul-Beschreibung" aus Sicht der Zuordnung von Klassen und Objekten ab.
5 Schnittstellen
5.1 Schnittstelle MODIAG - KOM
Die durch die Methode KOM identifizierten Klassen und Objekte werden durch die Methode MODIAG physischen Programmteilen zugeordnet. Für aktive Objekte, die einen eigenen Steuerfluß haben, können eigene Hauptprogramme festgelegt werden.
5.2 Schnittstelle MODIAG - SSM
Die mit Hilfe der Methode SSM vorgenommene fachliche Gliederung des Systems ist mit der mittels der Methode MODIAG vorgenommenen physischen Gliederung abzustimmen.
5.3 Schnittstelle MODIAG - PRODIAG
Für jeden in der Methode PRODIAG definierten Prozeß muß in der Methode MODIAG ein eigenes Hauptprogramm festgelegt werden.
6 Weiterführende Literatur
/ Booch, Rumbaugh, Jacobson, 97 /