Previous Next Methods Allocation  
4.22 Elementarmethode "Klassen-/Objektmodellierung" (KOM)  

  4.22 Elementary Method "Class/Object Modeling" (COM)

Inhalt  
  • 1 Identifikation/Definition der Methode
  • 2 Kurzcharakteristik der Methode
  • 3 Grenzen des Methodeneinsatzes
  • 4 Detaillierung der Methodenzuordnung
  • 5 Schnittstellen
  • 6 Weiterführende Literatur
  • 7 Funktionale Werkzeuganforderungen
  • 1 Identifikation/Definition der Methode

    /Booch, 1997/

    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, 1997/ 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, 1994/ und OMT /Rumbaugh, 1991/; /Rumbaugh, 1995b/ 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, 1997/ 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, 1994/; /Jacobson, 1992/; /Shlaer, Mellor, 1992/. Im Gegensatz zu /Booch, 1997/ 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

    Nr. Aktivität Beschreibung
    4.1 SE1.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 das Teilprodukt Anwenderforderungen.Ist-Aufnahme und Ist-Analyse aus Sicht der statischen Systemstruktur ab.

    4.2 SE1.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 das Teilprodukt Anwenderforderungen.Grobe Systembeschreibung aus Sicht der statischen Systemstruktur ab.

    4.3 SE1.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 das Teilprodukt Anwenderforderungen.Randbedingungen aus Sicht der statischen Systemstruktur ab.

    4.4 SE1.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 das Teilprodukt Anwenderforderungen.Beschreibung der Funktionalität aus Sicht der statischen Systemstruktur ab.

    4.5 SE2.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 Systemarchitektur.Lösungsvorschläge und Systemarchitektur.Darstellung der technischen Systemarchitektur ab. Weiterhin werden die Teilprodukte Technische Anforderungen.Gesamtfunktion des Elements und Technische Anforderungen.Technische Anforderungen an die Schnittstellen aus Sicht der statischen Struktur abgedeckt, außerdem das Teilprodukt Schnittstellenübersicht.Systemexterne Schnittstellen und bezogen auf die definierten Architekturelemente das Teilprodukt Schnittstellenübersicht.Systeminterne Schnittstellen aus Sicht der statischen Struktur.

    4.6 SE2.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 das Teilprodukt Schnittstellenbeschreibung.Beschreibung der Schnittstellen aus Sicht der statischen Struktur ab.

    4.7 SE3.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 das Teilprodukt A HREF="../d-treq.htm#tech_req_interface">Technische Anforderungen.Technische Anforderungen an die Schnittstellen aus Sicht der statischen Struktur ab.

    4.8 SE3.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 das Teilprodukt Technische Anforderungen.Gesamtfunktion des Elements aus Sicht der statischen Struktur ab.

    4.9 SE4.1 - 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 die Teilprodukte SW-Architektur.Lösungsvorschläge , SW-Architektur.Modularisierung/Datenbankentwurf und SW-Architektur.Schnittstellen sowie das Teilprodukt Schnittstellenübersicht.Systeminterne Schnittstellen bezogen auf die definierten Architekturelemente aus Sicht der statischen Struktur ab.

    4.10 SE4.2 - 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 das Teilprodukt Schnittstellenbeschreibung.Beschreibung der Schnittstellen aus Sicht der statischen Struktur ab.

    4.11 SE5.1 - 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 das Teilprodukt SW-Entwurf.SW-Komponenten-/SW-Modul-Beschreibung bzw. bei objektorientierten Datenbanken das Teilprodukt SW-Entwurf.Datenbankbeschreibung aus Sicht der statischen Struktur ab.

    5 Schnittstellen

    Nr. Schnittstellen Bemerkung Information (Anhang 1)
    5.1 KOM-CRC KOM - CRC Die Methode CRC kann innerhalb der Methode KOM zur Findung und Verfeinerung der Klassenstruktur verwendet werden.  
    5.2 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 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 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 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 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 KOM-IAM 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, 1994/ Object-Oriented Analysis and Design with Applications
    /Coleman, 1994/ Object-Oriented Development - The Fusion Method
    /Jacobson, 1992/ Object-Oriented Software Engineering - A Use Case Driven Approach
    /Rumbaugh, 1991/ Object-oriented Modeling and Design
    /Rumbaugh, 1995b/ OMT - The functional model
    /Shlaer, Mellor, 1992/ Object Lifecycles - Modeling the World in States

    7 Funktionale Werkzeuganforderungen

    LSE22 - Klassen-/Objektmodellierung unterstützen

    Links to the V-Model Mailinglist

    Mail 0200 - Re: Methodenzuordnung fuer UML (200)

    Previous Next This page online  •  GDPA Online  •  Last Updated 08.Oct.2002 by C. Freericks