2.2. OBJEKTORIENTIERTE SPEZIFIKATION 31

Metaklasse Eine Metaklasse bezeichnet die Klasse einer Klasse. Von einer Metaklasse dürfen keine Instanzen gebildet werden. Hauptsächlicher Verwendungszweck von Metaklassen: Zur Verfügung Stellen von Klasseninstanzvariablen (Dieses Konzept ist vergleichbar mit den statischen Elementen in C++).

Zivis Fuehrerschein

Rollstuhl

Behinderte

Hebebuehne

Fahrzeug

Transporter
transporter

Spezial-

Abbildung 2.12: Beispiel 1

In Beispiel 1 stehen die Klassen Zivis und Behinderte in Beziehung. Die Klassen Zivis und Führerschein bilden eine Aggregation, ebenso wie die Klassen Behinderte und Rollstuhl. Die Klasse Zivis verwendet die Klasse Spezialtransporter. Spezialtransporter erbt von den Klassen Transporter und Hebebühne, die Klasse Transporter erbt wiederum von der Klasse Fahrzeug.

Seite 31: vorherige Seite | nächste Seite | Übersicht

32 KAPITEL 2. SEMINARVORTRÄGE

Stunden

Stunden-

abrechnung

Abrech.-

art

Abrechnung

Zivi

Stunden

PersNr

Abbildung 2.13: Beispiel 2

In Beispiel 2 wird die Klasse Stundenabrechnung von der Klasse Abrechnung instantiiert, in dem sie die Klasse Stunden verwendet. Die Metaklasse der Klasse Zivi bietet die Klasseninstanzvariable PersNr. an, die im System nur einmalig vorkommen darf.

2.2.3.3 Klassen und Objekte in Analyse und Design

Für den Entwickler stellen sich während der Analyse und in der frühen Designphase zwei grundlegende Fragen:

- Finden der Klassen und Objekte, die das Vokabular des Problembereichs bilden. Die gefundenen Klassen und Objekte nennt man auch die Schlüsselabstraktionen des Systems.

- Gruppierung der einzelnen Objekte mit anschlieflendem Aufstellen einer Struktur, in der diese Objektgruppen zusammenarbeiten und so dem von den Problemanforderungen erwünschten Verhalten gerecht werden. In diesem Schritt werden also die Mechanismen gefunden, die zur Problemlösung beitragen.

2.2.4 Klassi?zierung

2.2.4.1 Probleme bei der Klassi?zierung

Welche Möglichkeiten gibt es, um die Schlüsselabstraktionen und die Mechanismen eines Problems zu ?nden? Oder einfacher ausgedrückt, wie ?ndet man die passenden Klassen bzw. Objekte, und wie arbeiten diese zusammen? Um diese Frage zu klären, sollte man sich zuerst Gedanken darüber machen, welche Probleme bei dem Finden von Klassen auftreten können. Unterhalten sich mehrere

Seite 32: vorherige Seite | nächste Seite | Übersicht

2.2. OBJEKTORIENTIERTE SPEZIFIKATION 33

Personen über ein Problem, von dem sie versuchen, dessen Schlüsselabstraktionen zu ?nden, wird jeder einzelne auf seine eigene Lösung kommen. Es müssen also Strategien angewendet werden, um das Finden der Schlüsselabstraktionen und Mechanismen im Entwicklungsteam zu steuern.

2.2.4.2 Analyseansätze

Bei der Analyse gibt es keine deterministische Vorgehensweise. Das Entdecken geeigneter Klassen und Objekte zur Modellierung des Problems während der Analysephase und das Finden geeigneter Abstraktionen und Mechanismen zur Realisierung des gewünschten Verhaltens hängen weitgehend von der Erfahrung der Entwickler ab. Die vorgestellten Analyseansätze sollen beispielhaft skizzieren, wie geeignete Klassen und Objekte gefunden werden können.

- klassischer Ansatz

- Verhaltensanalyse

- Bereichsanalyse

- Gebrauchsfall-Analyse

- informelle sprachliche Beschreibung

- CRC-Karten

- (Strukturanalyse)

Klassischer Ansatz Mit diesem Ansatz werden Klassen abgeleitet, indem die real existierenden Objekte und Verantwortlichkeiten des zu modellierenden Systems direkt übernommen werden.

- reale Dinge (z.B. Fahrzeuge, Touren : : : )

- Rollen (z.B PÄeger, Fahrer : : : )

- Ereignisse (z.B. Transport : : : )

- Interaktionen

- Organisatorische Einheiten

- : : :

Verhaltensanalyse Bei diesem Ansatz bildet man Klassen derart, dafl Objekte die ein ähnliches Verhalten aufzeigen, in einer Klasse zusammengefaflt werden. Es wird das dynamische Verhalten betrachtet, d.h. welchen Zweck erfüllen die Objekte innnerhalb des Systems? Durch diesen Ansatz könnte man auf folgende Klassenkandidaten kommen:

- Zivis, die Schulfahrten erledigen

- Zivis, die Essen ausfahren

- Planer, die Touren zusammenstellen

- Fahrzeuge, die Rollstuhlfahrer transportieren

- : : :

Seite 33: vorherige Seite | nächste Seite | Übersicht

34 KAPITEL 2. SEMINARVORTRÄGE

Bereichsanalyse Die Bereichsanalyse bildet Klassen, deren Objekte sich einem gemeinsamen Bereich zuordnen lassen. Unter Bereich werden verwandte Bestandteile innerhalb des zu modellierenden Systems verstanden. Diese Methode eignet sich i.a. dazu, neue Schlüsselabstraktionen zu ?nden, wenn während der Analyse ein Stillstand auftritt, indem Bereichsexperten hinzugezogen werden, d.h. Fachleute, die mit dem zu modellierenden Problem tagtäglich zu tun haben. Durch die Bereichsanalyse könnten folgende Klassen gefunden werden:

- Dialysepatienten

- Schüler einer bestimmten Schule

- Schulwege zu einer bestimmten Schule

- Transporter für Rollstuhlfahrer

- Zivis mit spezieller Ausbildung im PÄegedienst

- : : :

Gebrauchsfall-Analyse Unter Gebrauchsfall versteht man ein Muster für die jeweilige Anwendung in Teilbereichen des Problems. Die Gebrauchsfälle müssen jedoch wieder durch die anderen Ansätze auf einzelne Klassenkandidaten untersucht werden. Ein Beispiel für einen Gebrauchsfall wäre z.B.: ?Ein Zivi startet morgens am DRK, holt unterwegs eine bestimmte Anzahl von Schülern ab, in dem er einer vorgegebenen Tour folgt, bringt diese zur Schule und fährt zurück zum DRK.?

Informelle sprachliche Beschreibung Bei dieser Analysemethode beschreibt man das Problem, indem ein in Umgangssprache verfaflter Text erstellt wird, der die Anforderungen genau beschreibt. Kandidaten für Klassen sind hierbei die Substantive innerhalb des Textes und die Verben könnten potentielle Methoden darstellen. Diese Methode ist mit Vorsicht zu genieflen, da umgangssprachliche Beschreibung ein höchst ungenaues Mittel zur Beschreibung eines Problems ist. Desweiteren mufl man auch darauf achten, dafl Verben substantiviert werden können. Ein Vorteil dieser Methode ist, dafl der Entwickler gezwungen wird, im Vokabular des Problembereichs zu denken.

CRC-Karten Diese Methode ist keine Analysemethode im eigentlichen Sinne. Sondern vielmehr eine Möglichkeit, die anderen Analyseansätze visuell zu unterstützen. CRC steht für Class >= Responsibilities >= Collaborators, also für Klasse >= Verantwortlichkeit >= Beteiligung. Wie kann man die anderen Ansätze damit unterstützen? CRC-Karten sind im Prinzip Karteikarten, bei denen oben der Klassenname steht, auf der linken Seite die Verantwortlichkeiten (was macht die Klasse?) und auf der rechten Seite die Beteiligungen (welche Klassen sind noch betroöen?). Zur besseren Übersicht können die Karten farblich unterschiedlich sein und an eine Pinnwand geheftet werden (zusätzlich können diejenigen Klassen mit Linien verbunden werden, die zusammenarbeiten).

Seite 34: vorherige Seite | nächste Seite | Übersicht

2.2. OBJEKTORIENTIERTE SPEZIFIKATION 35

Strukturanalyse Die Strukturanalyse ist nur bedingt für die objektorientierte Spezi?kation einsetzbar. Da sie ihre Ursprünge in der strukturierten Analyse bzw. strukturierten Programmierung hat. Hier wird das Modell des Systems mittels DatenÄufldiagrammen erstellt. Was könnte nun eine Klasse sein?

- externe Entitäten

- Datenelemente

- Steuerungselemente

- : : :

Abschlieflend läflt sich sagen, dafl keine dieser Analysemethoden für sich alleine ausreichen wird, um ein vollständiges Modell und die ersten Designansätze für ein System zu liefern. Eine Kombination sollte jedoch eine gute Grundlage liefern.

2.2.4.3 Zentrale Fragen der Analyse

Bevor man sich jedoch darauf stürzt, irgendwelche Klassen zu ?nden, die das System modellieren könnten, ist es nötig, sich zu überlegen, welche Ziele mit der Analyse verfolgt werden sollten. Es sind hierbei zwei wichtige Punkte zu nennen:

- Was ist das gewünschte Verhalten des Systems, d.h. was soll das System leisten, was wird von ihm erwartet?

- Was sind die Rollen und Verantwortlichkeiten der Objekte, die dieses Verhalten realisieren? Diese Frage erfordert natürlich, dafl schon eine gewisse Vorstellung der Objekte vorhanden ist.

2.2.4.4 Zentrale Fragen des Designs

Die Aufgabe des Designs besteht darin, die in der Analyse gefundenen Schlüsselabstraktionen und Klassen sinnvoll im System unterzubringen und gegebenenfalls zu erweitern. Dabei sollte zuerst überlegt werden, wie das Design auszusehen hat und was damit bezweckt werden soll.

- Welche Klassen existieren und in welcher Beziehung stehen diese Klassen? Diese Frage läflt sich nicht eindeutig dem Design zurechnen, da auch schon während der Analyse Klassen entdeckt bzw. erfunden werden. Dieses Problem, dafl Analyse und Design nicht sauber zu trennen sind, wird jedoch noch häu?ger auftreten.

- Welche Mechanismen werden verwendet, um die Zusammenarbeit der Objekte zu steuern?

- Wo sollen die einzelnen Klassen und Objekte deklariert werden?

- Welchem Prozessor sollte ein Prozefl zugeordnet werden, und wie sollte für einen bestimmten Prozessor die zeitliche Reihenfolge der verschiedenen Prozesse festgelegt werden?

Seite 35: vorherige Seite | nächste Seite | Übersicht

36 KAPITEL 2. SEMINARVORTRÄGE

2.2.5 Notation

2.2.5.1 Klassendiagramme

Wozu dienen die Klassendiagramme? Sie dienen der Darstellung der Existenzen von Klassen und deren Beziehungen miteinander. Das Klassendiagramm erzeugt eine logische Sicht des zu entwickelnden Systems. In der Analysephase hilft das Klassendiagramm, die Klassen und deren Verantwortlichkeiten darzustellen. Während des Designs zeigt das Klassendiagramm die Struktur des Systems.

Klassenname

form. Arg.

Name der param.

Klasse

akt. Arg.

Name der instant.

Klasse

Klassenkategorie

Name

Klassen

Name der Metaklasse

Klassen-Utility-Name

Abbildung 2.14: Klassen-Icons

Klassen-Icons Bis auf Klassenkategorien und Klassenutilities sind die Bedeutungen der einzelnen Icons bereits bei der Zusammenarbeit von Klassen erklärt worden. Ein Klassenutility bietet globale Attribute und Methoden an, auf die alle Klassen zugreifen können. Die Klassenkategorien helfen bei der Strukturierung der Klassendiagramme. In einer Klassenkategorie werden diejenigen Klassen zusammen gefaflt, die im Klassendiagramm eine funktionale Einheit bilden, d.h. Klassenkategorien bilden Klassenbibliotheken. Im Bsp. verwendet die Klassenbiblithek ?Fahrdienste des DRK? zum Beispiel die GUI-Bibliothek, um die graphische OberÄäche darzustellen.

Seite 36: vorherige Seite | nächste Seite | Übersicht

2.2. OBJEKTORIENTIERTE SPEZIFIKATION 37

Fahrdienste

des DRK

Essen auf

Rädern
Schulfahrten

Touren

zus.stellen

GUI-

Bibliothek

Abbildung 2.15: Beispiel für ein Klassenkategorie-Diagramm

Klassenbeziehungen Arten von Klassenbeziehungen :

- Assoziation:
Einfache Beziehungen zwischen Klassen untereinander. Eine Klasse kann auch eine Assotiation zu sich selbst besitzen (= reÄexive Assoziation).

- Vererbung ("is-a"-Beziehung):
Der Pfeil zeigt auf die Oberklasse. Vererbungsbeziehungen dürfen keine Zyklen enthalten.

- Eigentum (Aggregation oder ?has?-Beziehung):
Der ausgefüllte Kreis am Ende der Assoziation gibt das Aggregat an. Die Klasse am anderen Ende gibt den Teil an, dessen Instanzen im Aggregat- Objekt enthalten sind.

- Verwendung (Client-/Supplier-Beziehung):
Der Kreis am Ende der Assoziation gibt den Client an, der auf irgendeine Art und Weise vom Supplier abhängig ist, um bestimmte Dienstleistungen zu realisieren (z.B. Operationen der Clientklasse rufen Operationen der Supplierklasse auf).

- Instantiierung:
Die instantiierte Klasse (mit aktuellem Parameter) zeigt auf die parametrisierte Klasse (mit formalem Parameter).

- Metaklasse (Klasse einer Klasse):
Metaklassen werden verwendet, um Klasseninstanzvariablen und -

Seite 37: vorherige Seite | nächste Seite | Übersicht

38 KAPITEL 2. SEMINARVORTRÄGE

operationen zur Verfügung zu stellen, können also selbst keine Instanzen besitzen. Metaklassen können aber von anderen Klassen erben.

Vererbung
Assoziation

"Eigentum"-Beziehung "Verwendung"-Beziehung

Instantiierung Metaklasse

Abbildung 2.16: Klassenbeziehungen

Kennzeichnungen der Beziehungen Beziehungen können beschrieben werden, um die Zusammenarbeit der Klassen deutlich zu machen:

- Rolle:
Sie gibt den Zweck oder den Umfang der Beziehung einer Klasse zu einer anderen an. (z.B. Fahrer, Mitarbeiter, Planer, : : : )

- Schlüssel:
Ein Attribut, dessen Wert ein einzelnes Zielobjekt eindeutig identi?ziert. (z.B. Fahrzeugnummer, Mitarbeitername, Kunden-ID, : : : )

- Einschränkung:
Durch die Einschränkung wird eine sematische Bedingung einer Klasse oder einer Beziehung beschrieben, die erfüllt sein mufl, solange sich das System in einem stabilen Zustand be?nden soll (z.B. TÜV am Fahrzeug darf nicht abgelaufen sein).

- Kardinalität:
Sie gibt an, wieviele Instanzen der einen Klasse in der Instanz der jeweils anderen Klasse vorhanden sein dürfen.

- Attributklasse:
Die Attributklassen beschreiben die Eigenschaften der Assoziationen. D.h. jede Assoziation mufl eine Instanz der Attributklasse sein.

Beschriftung

Rolle

[Schlüssel]

{Einschränkung}

Kardinalität

Attributklasse

Abbildung 2.17: Kennzeichnungen der Beziehungen

Seite 38: vorherige Seite | nächste Seite | Übersicht

2.2. OBJEKTORIENTIERTE SPEZIFIKATION 39

Kennzeichnungen für das Enthaltensein Das (physikalische) Enthaltensein wird dargestellt als Anmerkung am Ende einer ?Eigentum?-Beziehung. Es können zwei Arten unterschieden werden:

- über den Wert:
Gibt das (physikalische) Beinhalten des Wertes des Bestandteils an.

- über eine Referenz:
Gibt das (physikalische) Beinhalten über einen Zeiger oder eine Referenz auf den Bestandteil an.

Wert

Referenz

Abbildung 2.18: Kennzeichnungen für das Enthaltensein

Eigenschaften In einigen objektorientierten Sprachen sind die Beziehungen von ihrer Sematik her gesehen fundamental verschieden, so dafl spezielle Symbole eingeführt werden müssen:

- abstrakte Klasse:
Von abstrakten Klassen können keine Instanzen erzeugt werden, sie dienen in der Regel dazu, ein Klassengerüst zur Verfügung zu stellen. D.h. die abstrakte Klasse gibt die Schnittstellen der Methoden vor, deren Implementierung in der Verantwortung der Unterklasse liegt.

- static:
Die Bezeichnung eines Klassenelementobjekts oder einer -funktion (statische Klassen ?nden z.B. in der Programmiersparche C++ Verwendung; Smalltalk oder CLOS verwenden dagegen Metaklassen).

- virtual:
Diese Eigenschaft wird benutzt, um eine gemeinsam verwendete Basisklasse oder eine polymorphe Operation zu bezeichnen.

- friend:
Eine friend-Klasse erhält von einer anderen Klasse Rechte, um auf deren nicht- public-Teile zugreifen zu dürfen.

Exportsteuerung Die meisten OO-Sprachen bieten eine klare Trennung zwischen Schnittstelle und Implementierung einer Klasse. Mit Hilfe der Exportsteuerung kann der Zugriö auf die Schnittstelle genau spezi?ziert werden.

- public:
Die Schnittstelle ist für alle Clients erreichbar.

- protected:
Nur Unterklassen, Friend und die Klasse selbst dürfen auf die Schnittstelle zugreifen.

Seite 39: vorherige Seite | nächste Seite | Übersicht

40 KAPITEL 2. SEMINARVORTRÄGE

A abstrakte Klasse

S static

F friend

V virtual

Abbildung 2.19: Eigenschaften

- private:
Auf die Schnittstelle dürfen nur die Klasse selbst oder ein Friend zugreifen.

- implementation:
Nur die Implementierung hat Zugriö (siehe abstrakte Klassen).

public

protected

private

implementation

Abbildung 2.20: Exportsteuerung

Klassenname

verschachtelte

Klasse

Abbildung 2.21: geschachtelte Klassen

Geschachtelte Klassen Klassen können ineinander geschachtelt werden. Dies soll bei der Kontrolle über den Namensraum helfen, da Instanzen von eingeschlossenen Klassen nur in der umgebenden Klasse existieren können.

Seite 40: vorherige Seite | nächste Seite | Übersicht