 |
 |
 |
|
| 4.24 Elementarmethode "Moduldiagramme" (MODIAG) |
4.24 Elementary Method "Module Diagrams" (MODIAG)
 Inhalt
|
|
|---|
1 Identifikation/Definition der Methode
/Booch, 1994/ Object-Oriented Analysis and Design with Applications
2 Kurzcharakteristik der Methode
Ziel und ZweckDie 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, 1994/.
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, 1997/ 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
| Nr. | Aktivität | Beschreibung |
|---|---|---|
| 4.1 | SE4.1 - 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 die Teilprojekte SW-Architektur.Lösungsvorschläge und SW-Architektur.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 Schnittstellenübersicht.Systeminterne Schnittstellen ein.
|
| 4.2 | SE5.1 - 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.SW-Komponenten-/SW-Modul-Beschreibung aus Sicht der Zuordnung von Klassen und Objekten ab. |
5 Schnittstellen
| Nr. | Schnittstellen | Bemerkung | Information (Anhang 1) |
|---|---|---|---|
| 5.1 | 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 | 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 | 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, 1997/ Unified Modeling Language, Version 1.0 Links to the V-Model Mailinglist
Mail 0200 - Re: Methodenzuordnung fuer UML (200)
|
|
|
This page online • GDPA Online • Last Updated 08.Oct.2002 by C. Freericks |