1 Identifikation/Definition der Methode
/ Booch, Rumbaugh, Jacobson, 97 /
2 Kurzcharakteristik der Methode
Ziel und Zweck
Die Methode dient zur objektorientierten Systementwicklung. Diese erfordert die Modellierung von Klassen, von zugehörigen Attributen und Operationen sowie der Beziehungen zwischen den Klassen. Es ist die Aufgabe der Klassenmodellierung, die statische Klassenstruktur in Klassenmodellen festzulegen. Eine Klasse ist in bezug auf die Ausführung eines Systems statisch und definiert die Struktur und das Verhalten ähnlicher Objekte.
Objekte sind als Instanzen von Klassen zu modellieren. Objekte sind in bezug auf die Ausführung eines Systems flüchtig. Sie werden während der Ausführung eines Programms erzeugt, kommunizieren miteinander und werden wieder gelöscht. In der objektorientierten Entwicklung ist es sinnvoll, für konkrete Situationen Objekte und ihre Beziehungen zu modellieren. Es ist die Aufgabe der Objektmodellierung, solche Momentaufnahmen von Objektstrukturen in Objektmodellen festzulegen. Sie kann in den Entwicklungaktivitäten zur Beschreibung eines bestimmten Systemverhaltens, zur Umsetzung einer funktionalen Spezifikation oder anderer Mechanismen, zur Festlegung von Prüffällen und zur Diskussion von Beispielen verwendet werden.
Die Klassen-/Objektmodellierung kann in der objektorientierten Entwicklung sowohl während der Analyse als auch während des Entwurfs eingesetzt werden. Während der Analyse sind die Klassenstruktur bzw. die Objektstrukturen aus Nutzersicht zu modellieren, um auszudrücken, was ein System tut. Im Entwurf sind diese Strukturen zu verfeinern, und es ist festzulegen, wie das System etwas tut.
Bei der Klassenmodellierung sind Attribute zu verwenden, um identifizierende, beschreibende oder auch referenzierende Informationen in einer Klasse zu modellieren. Mit den Operationen sind die Funktionen oder Transformationen festzulegen, die auf Objekte einer Klasse angewendet werden können. Sie können durch die Angabe ihrer Aufgabenstellung bzw. Verantwortlichkeit, ihres Ein- und Ausgabeverhaltens, der Veränderung von Objekten und durch Aussagen über den Systemzustand vor und nach ihrer Ausführung feiner spezifiziert werden. Vererbungsbeziehungen (einfach und mehrfach), Aggregationen und Assoziationen, die weiter verfeinert werden können, sind darstellbar. Aggregationen und Assoziationen sind durch eine Benennung und durch die Angabe von Kardinalitäten zu spezifizieren.
Durch zusätzliche Modellierungsmöglichkeiten, wie beispielsweise die Festlegung von Sichtbarkeiten, die Vergabe von Rollennamen, die Zuordnung von Einschränkungen ("constraints"), die Beschreibung abgeleiteter Attribute und die Verwendung von Beziehungen höherer Ordnung, können die Entwicklungsergebnisse verfeinert werden.
Die Konzepte der Klassenmodellierung können auch eingesetzt werden, um die statischen Aspekte von Schnittstellen von Klassen und Subsystemen (vgl. Elementarmethode " Subsystemmodellierung ") und ihre Anwendung zu definieren. Die Teile von Klassen (Attribute, Operationen) bzw. Subsystemen (Klassen, Beziehungen), die als Schnittstellen definiert werden sollen, können nochmals in eigenen Schnittstellenmodellen gekennzeichnet werden. Diese Schnittstellenmodelle sind in der Notation und den Darstellungsmitteln ebenfalls Klassenmodelle und können die Schnittstellen benennen.
Bei der Objektmodellierung ist die Konsistenz mit der in der Klassenmodellierung festgelegten Klassenstruktur sicherzustellen. Alle spezifizierten Objekte müssen einer Klasse zugeordnet werden können, und alle Beziehungen zwischen Objekten müssen in entsprechenden Klassenbeziehungen repräsentiert werden. Für eine Klassenstruktur kann eine Menge von Objektstrukturen definiert werden.
Darstellungsmittel
In / Booch, Rumbaugh, Jacobson, 97 / kommen als Darstellungsmittel der Klassen-/Objektmodellierung Diagramme und textliche Beschreibungen in Spezifikationen und "Data Dictionaries" zum Einsatz.
Durch die Zusammenarbeit von Booch und Rumbaugh wurden die aus den komplexen Methoden OOAD / Booch, 94 / und OMT / Rumbaugh, 91 /, / Rumbaugh 95a / bekannten Notationen und Darstellungsmittel zur Klassen-/Objektmodellierung vereinheitlicht und weiterentwickelt. Es stehen sehr kompakte Darstellungsmittel zur Verfügung, in denen sowohl in der Analyse als auch im Entwurf die oben genannten Informationen visualisiert werden können.
Für die Klassenmodellierung kommen Klassendiagramme ("Class Diagrams") zum Einsatz, im Bereich der Objektmodellierung sind es die Objektdiagramme ("Object Diagrams"). Mischformen, die generell als "Class Diagrams" bezeichnet werden, sind möglich.
Neben den oben genannten Informationen können in den "Class Diagrams" auch weitergehende Konzepte wie zusammengesetzte Klassen ("Compositions"), parametrierte Klassen ("Parameterized Classes"), Hilfsklassen mit globalen Variablen und Funktionen ("Utility Classes") und Gruppierungen ("Packages") modelliert werden. Operationen können mit den oben beschriebenen Informationsinhalten in "Operation Specifications" näher spezifiziert werden. Genaue Beschreibungen der verwendeten Notation und der Darstellungsmittel sind / Booch, Rumbaugh, Jacobson, 97 / zu entnehmen.
Die Klassenmodellierung ist eine der allgemein anerkannten Hauptaufgaben der objektorientierten Entwicklung. Daher wird sie, wenn auch mit Unterschieden in der Notation, den Darstellungsmitteln und in den Details der spezifizierbaren Informationen, auch in anderen bekannten komplexen objektorientierten Entwicklungsmethoden eingesetzt / Coleman, 94 /, / Jacobson, 92 /, / Shlaer, Mellor, 92 /. Im Gegensatz zu / Booch, Rumbaugh, Jacobson, 97 / werden von diesen beispielsweise unterschiedliche Darstellungsmittel in der Analyse und im Design verwendet, die Informationen auf mehrere Diagrammtypen verteilt oder die Modellierung von Klassen und Operationen in der Analyse getrennt. Die Objektmodellierung wird in anderen Methoden, wenn überhaupt, ebenfalls mit unterschiedlichen Notationen und teilweise anderen Zielsetzungen eingesetzt.
Funktioneller Ablauf
Die Klassen- und Objektmodellierung wird iterativ eingesetzt, wobei bei jedem Durchlauf detailliertere, verfeinerte oder auch neue bzw. geänderte Klassen und Objekte entstehen. Die Iterationen sind in die Vorgehensweisen der jeweils verwendeten komplexen objektorientierten Entwicklungsmethoden eingebettet. Grundsätzlich können folgende Schritte unterschieden werden:
3 Grenzen des Methodeneinsatzes
Die Klassen-/Objektmodellierung eignet sich nur für die Modellierung der statisch logischen Sicht auf das System. Für die statisch physische Sicht sind Moduldiagramme (Methode MODIAG ) und Prozeßdiagramme (Methode PRODIAG ) zu verwenden, für die dynamische Sicht die Zustandsmodellierung im objektorientierten Bereich (Methode ZUSTO ) und die Interaktionsmodellierung (Methode IAM ).
Bei komplexeren Systemen mit einer größeren Anzahl von Klassen und Objekten empfiehlt sich eine Zergliederung in Subsysteme (Methode SSM ) und die Anwendung der Klassenmodellierung auf diese Subsysteme.
4 Detaillierung der Methodenzuordnung
4.1 KOM in Aktivität SE 1.1 "Ist-Aufnahme/-Analyse durchführen"
Mit Hilfe der Methode kann der Ist-Zustand der statischen Struktur des Altsystems in Klassenmodellen und in für das Verständnis des Altsystems relevanten Objektmodellen erfaßt werden. Die Detaillierung ist dabei einzugrenzen, da nur die wesentliche, aus fachlicher, anwenderorientierter Sicht relevante Struktur darzustellen ist.
Die Methode deckt im Produkt "Anwenderforderungen" das Teilprodukt "Ist-Aufnahme und Ist-Analyse" aus Sicht der statischen Systemstruktur ab.
4.2 KOM in Aktivität SE 1.2 "Anwendungssystem beschreiben"
Mit Hilfe der Methode kann der Gesamthorizont des Systems in grundlegenden Klassen- und Objektstrukturen modelliert werden. Aus Sicht der statischen Systemstruktur ist festzulegen, was das neue System tun soll.
Die Methode deckt im Produkt "Anwenderforderungen" das Teilprodukt "Grobe Systembeschreibung" aus Sicht der statischen Systemstruktur ab.
4.3 KOM in Aktivität SE 1.4 "Randbedingungen definieren"
Mit Hilfe der Methode können die sich durch technische, organisatorische und weitere Randbedingungen ergebenden Anforderungen an die statische Klassen- und Objektstruktur spezifiziert werden. Pauschale Anforderungen an Schnittstellen können in grundlegenden statischen Schnittstellenmodellen modelliert werden.
Die Methode deckt im Produkt "Anwenderforderungen" das Teilprodukt "Randbedingungen" aus Sicht der statischen Systemstruktur ab.
4.4 KOM in Aktivität SE 1.5 "System fachlich strukturieren"
Mit Hilfe der Methode kann die statische Systemstruktur fachlich mittels Klassen- und Objektstrukturen bis auf Segmentebene modelliert werden. Systemexterne Schnittstellen können als statische Schnittstellenmodelle entworfen werden.
Die Methode deckt im Produkt "Anwenderforderungen" das Teilprodukt "Beschreibung der Funktionalität" aus Sicht der statischen Systemstruktur ab.
4.5 KOM in Aktivität SE 2.1 "System technisch entwerfen"
Mit Hilfe der Methode kann in kombinierter Anwendung mit der Methode "Subsystemmodellierung" (SSM) das System in Segmente und/oder in SW-/HW-Einheiten gegliedert werden. Für einen ausgewählten Lösungsvorschlag können die statischen Klassen- und Objektstrukturen verfeinert werden. Dabei sind technische Anforderungen zu berücksichtigen. Für die Schnittstellen zwischen den definierten Architekturelementen und für die systemexternen Schnittstellen können statische Schnittstellenmodelle spezifiziert bzw. verfeinert werden.
Die beiden Methoden decken im Produkt "Systemarchitektur" bezogen auf das System die Teilprodukte "Lösungsvorschläge" und "Darstellung der technischen Systemarchitektur" ab. Weiterhin werden im Produkt "Technische Anforderungen" bezogen auf das System die Teilprodukte "Gesamtfunktion des Elements" und "Technische Anforderungen an die Schnittstellen" aus Sicht der statischen Struktur abgedeckt, außerdem im Produkt "Schnittstellenübersicht" das Teilprodukt "Systemexterne Schnittstellen" und bezogen auf die definierten Architekturelemente das Teilprodukt "Systeminterne Schnittstellen" aus Sicht der statischen Struktur.
4.6 KOM in Aktivität SE 2.5 "Schnittstellen beschreiben"
Mit Hilfe der Methode können in kombinierter Anwendung mit der Methode "Subsystemmodellierung" (SSM) die Schnittstellen des Systems und der definierten Architekturelemente als statische Schnittstellenmodelle modelliert bzw. verfeinert werden.
Die beiden Methoden decken im Produkt "Schnittstellenbeschreibung" das Teilprodukt "Beschreibung der Schnittstellen" aus Sicht der statischen Struktur ab.
4.7 KOM in Aktivität SE 3.2 "Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren"
Mit Hilfe der Methode können Anforderungen an externe Schnittstellen der SW-Einheiten als statische Schnittstellenmodelle spezifiziert werden. Diese können modelliert bzw. verfeinert werden.
Die Methode deckt im Produkt "Technische Anforderungen" bezogen auf die SW-Einheit das Teilprodukt "Technische Anforderungen an die Schnittstellen" aus Sicht der statischen Struktur ab.
4.8 KOM in Aktivität SE 3.3 "Anforderungen an die Funktionalität definieren"
Um Anforderungen an die technische Funktionalität zu spezifizieren, können mit Hilfe der Methode die Klassen- und Objektstrukturen in bezug auf die SW-Einheit verfeinert und angepaßt werden.
Die Methode deckt im Produkt "Technische Anforderungen" bezogen auf die SW-Einheit das Teilprodukt "Gesamtfunktion des Elements" aus Sicht der statischen Struktur ab.
4.9 KOM in Aktivität SE 4.1-SW "SW-Architektur entwerfen"
Mit Hilfe der Methode kann in kombinierter Anwendung mit der Methode "Subsystemmodellierung" (SSM) die logische Gliederung der SW-Einheit in statische Architekturelemente vorgenommen und über die Methode "Moduldiagramme" (MODIAG ) mit einer physischen Gliederung abgestimmt werden. Für die Schnittstellen zwischen den definierten Architekturelementen können statische Schnittstellenmodelle spezifiziert werden.
Die beiden Methoden decken im Produkt "SW-Architektur" die Teilprodukte "Lösungsvorschläge", "Modularisierung/Datenbankentwurf" und "Schnittstellen" sowie im Produkt "Schnittstellenübersicht" bezogen auf die definierten Architekturelemente das Teilprodukt "Systeminterne Schnittstellen" aus Sicht der statischen Struktur ab.
4.10 KOM in Aktivität SE 4.2-SW "SW-interne und -externe Schnittstellen entwerfen"
Mit Hilfe der Methode können die SW-Schnittstellen als statische Schnittstellenmodelle modelliert und in dieser Aktivität verfeinert werden.
Die Methode deckt im Produkt "Schnittstellenbeschreibung" das Teilprodukt "Beschreibung der Schnittstellen" aus Sicht der statischen Struktur ab.
4.11 KOM in Aktivität SE 5.1-SW "SW-Komponente/-Modul/Datenbank beschreiben"
Mit Hilfe der Methode kann die statische Struktur von SW-Komponenten/SW-Modulen oder objektorientierten Datenbanken in detaillierten Klassen- und Objektstrukturen modelliert werden. Es ist eine Verfeinerung bzw. Erweiterung der in den vorangegangenen Aktivitäten erarbeiteten Strukturen vorzunehmen.
Die Methode deckt Im Produkt "SW-Entwurf" das Teilprodukt "SW-Komponenten-/SW-Modul-Beschreibung" bzw. bei objektorientierten Datenbanken das Teilprodukt "Datenbankbeschreibung" aus Sicht der statischen Struktur ab.
5 Schnittstellen
5.1 Schnittstelle KOM - CRC
Die Methode CRC kann innerhalb der Methode KOM zur Findung und Verfeinerung der Klassenstruktur verwendet werden.
5.2 Schnittstelle KOM - SSM
In kombinierter Anwendung der Methoden KOM und SSM ist das System entsprechend dem V-Modell in Segmente, SW-/HW-Einheiten, SW-Komponenten und SW-Module zu zerlegen. Die externen Schnittstellen der Architekturelemente sind festzulegen.
5.3 Schnittstelle KOM - MODIAG
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.4 Schnittstelle KOM - PRODIAG
Die bei der Methode KOM definierten aktiven Objekte, die einen eigenen Steuerfluß haben, können in der Methode PRODIAG als eigenständige Prozesse realisiert werden.
5.5 Schnittstelle KOM - UCM
Die mittels der Methode UCM definierten funktionalen Anforderungen sind in der Methode KOM bei der Definition der Klassen- und Objektstrukturen umzusetzen. Die definierten Anwendungsfälle stellen mit ihren funktionalen Anforderungen eine Basis für die Ermittlung der Klassen und Objekte, für die Zuordnung von Funktionalität zu Klassen und für den Entwurf von Schnittstellen dar.
5.6 Schnittstelle KOM - ZUSTO
In Ergänzung zu der in der Methode KOM definierten statischen Struktur von Klassen wird in der Methode ZUSTO das signifikante dynamische Verhalten von Klassen aktiver Objekte modelliert. Die Modellierung von Zuständen ist mit der Modellierung von Klassenattributen, die Modellierung von Ereignissen und Aktionen mit der Modellierung von Klassenoperationen abzustimmen.
Während mit der Methode KOM der statische Aufbau von Schnittstellen spezifiziert werden kann, sind mit der Methode ZUSTO zulässige Aufruffolgen von Funktionen der Schnittstelle darstellbar.
5.7 Schnittstelle KOM - IAM
Die Modellierung von Interaktionen (Methode IAM ) ist mit der Modellierung von Klassenoperationen in der Methode KOM abzustimmen. Werden in der Methode KOM komplexe Operationen definiert, können ihre dynamischen Abläufe in der Methode IAM modelliert werden. Die Modellierung von Objekten in der Methode KOM ist mit der Modellierung von Objekten in der Methode IAM abzustimmen.
Während mit der Methode KOM der statische Aufbau von Schnittstellen spezifiziert werden kann, sind mit der Methode IAM ablauforientierte Anforderungen an Kommunikationsprotokolle darstellbar.
6 Weiterführende Literatur
/
Booch,
94 /,
/
Coleman,
94 /,
/
Jacobson,
92 /,
/
Rumbaugh,
91 /,
/
Rumbaugh,
95a /,
/
Shlaer, Mellor, 92
/