Bewertung der Qualität objektorientierter Entwürfe - Worte-Projekt
Bewertung der Qualität objektorientierter Entwürfe - Worte-Projekt Bewertung der Qualität objektorientierter Entwürfe - Worte-Projekt
16 3 Objektorientierung ler: Berg et al. (1995) kommen in einer Untersuchung zu dem Ergebnis, dass 80% der neu ausgebildeten Entwickler die Grundzüge der objektorientierten Entwicklung verstanden haben und sie anwenden können. Von diesen 80% entwickelten sich 5% zu sehr guten Entwicklern (top performers), 15% waren immerhin gut (journeyman level). Die große Mehrheit blieb allerdings Mittelmaß. Dass die objektorientierte Vorgehensweise nicht ohne Schwierigkeiten gemeistert werden kann, zeigen auch die Sammlungen typischer Fehler von Webster (1995) und Alexander (2001). 3.1 Begriffe Die Begriffe in der Objektorientierung werden häufig unterschiedlich definiert, oder es werden für dasselbe Konzept unterschiedliche Begriffe verwendet. Das führt zu einem großen Begriffschaos (Snyder, 1993). Daher werden die Definitionen der zentralen Begriffe angegeben, wie sie in dieser Arbeit verwendet werden. Die verwendeten Definitionen stützen sich vor allem auf die Begriffsbildung im Zusammenhang mit UML gemäß Rumbaugh et al. (1998). Drei Eigenschaften zeichnen nach Wegner (1987, 1992) die objektorientierte Sichtweise aus: Objekte, Klassen und Vererbung. Viele Autoren nehmen noch Polymorphismus und das damit zusammenhängende dynamische Binden als wichtige Eigenschaften hinzu. Daher werden diese Begriffe zuerst eingeführt. 3.1.1 Objekt Die zentrale Rolle spielt der Begriff des Objekts. Ein Objekt besteht aus Datenfeldern, den so genannten Attributen, und aus Funktionen auf diesen Daten, den so genannten Methoden. Methoden dienen zur Reaktion auf Nachrichten, die ein Objekt versteht. Methoden können z. B. den Zustand des Objekts (die Werte seiner Attribute) verändern oder neue Nachrichten verschicken. Die Schnittstelle einer Methode wird als Operation bezeichnet; eine Methode ist also die Implementierung einer Operation. 3.1.2 Klasse Die Objekte eines Systems werden nicht individuell beschrieben, sondern anhand ihrer Gemeinsamkeiten in Klassen zusammengefasst. Eine Klasse definiert die Attribute und Methoden ihrer Objekte. Die Klasse dient als Schablone zur Instantiierung (Erzeugung) von Objekten (Instanzen). Bei der Instantiierung müssen nur die Werte für die Attribute angegeben werden, die Methoden übernimmt das Objekt von seiner Klasse. Bei getypten objektorientierten Programmiersprachen wie C++ (Stroustrup, 1997), Java (Gosling et al., 1998) oder Eiffel (Meyer, 1991) ist das Typkonzept mit dem Klassenkonzept verknüpft: Bei der Deklaration einer Klasse wird automatisch auch ein gleichnamiger Typ deklariert. Dieser Typ verfügt über einen Wertebereich, der sich aus den Wertebereichen der Attribute zusammensetzt, und über Operationen, die den Methoden entsprechen. Daher definiert Meyer (1997) eine Klasse auch als die Implementierung eines abstrakten Datentyps. Ein Objekt ist vom Typ seiner Klasse. Abbildung 3-1 zeigt die UML-Darstellung einer Klasse und eines Objekts dieser Klasse. Der Name des Objekts wird zur besseren Unterscheidung unterstrichen.
3.1 Begriffe 17 Klasse Person mit Attributen name, birthday und Operationen setName, getAge. Attribute, Parameter und Rückgabe haben einen Typ. Ein Objekt namens HAL der Klasse Person mit der Wertebelegung der Attribute. Der Objektstatus wird durch die Unterstreichung angezeigt. Abbildung 3-1: UML-Darstellung von Klasse und Objekt Kommentare werden in UML durch einen Kasten mit Eselsohr dargestellt, der mit dem Modellelement, auf das sich der Kommentar bezieht, durch eine gestrichelte Linie verbunden ist. 3.1.3 Vererbung Vererbung ist eine Beziehung zwischen Klassen. Eine Klasse kann sämtliche Eigenschaften (Attribute und Methoden) einer anderen Klasse erben, d. h. als Kopie übernehmen. Es dürfen außerdem weitere Eigenschaften hinzugefügt werden (Erweiterung) und geerbte Methoden modifiziert werden (Redefinition). Bei Einfachvererbung erbt eine Klasse von genau einer anderen Klasse, bei Mehrfachvererbung von mehreren Klassen. Die vererbende Klasse heißt Oberklasse, die erbende Unterklasse. Bei getypten objektorientierten Programmiersprachen wird die Vererbungsrelation auf die korrespondierenden Typen übertragen: Eine erbende Klasse definiert einen Subtyp des durch die vererbende Klasse definierten Typs. Dadurch entsteht eine zur Vererbungsstruktur der Klassen isomorphe Typstruktur. In UML wird die Vererbung durch einen Pfeil mit einer dreieckigen Spitze angezeigt, der von der Unterklasse zur Oberklasse geht (vgl. Abbildung 3-2). Geerbte Eigenschaften werden in der Darstellung der Unterklasse nicht wiederholt. Die Klasse OO_Designer erbt von Person und fügt dabei neue Eigenschaften hinzu. OO_Designer experience: int likesUML: boolean getExperience(): int Abbildung 3-2: UML-Darstellung der Vererbung Person name: String birthday: Date setName(n: String) getAge(): int HAL: Person name = "HAL 9000" birthday = 12.1.1997 Person name: String birthday: Date setName(n: String) getAge(): int Vererbung ist ein mächtiges Konzept; durch sie kann viel redundante Implementierung eingespart werden. Durch Erben kann aber die Kapselung durchbrochen werden, weil eine Unterklasse Zugriff auf die Implementierung der Oberklasse erhält (Snyder, 1986). Außerdem ist die Unterklasse durch das Erben stark an ihre Oberklasse gekoppelt: Jede Änderung der Oberklasse betrifft auch die Unterklasse.
- Seite 1: Bewertung der Qualität objektorien
- Seite 5 und 6: Zusammenfassung In der Software-Ent
- Seite 7 und 8: Inhaltsverzeichnis 1 Danksagung....
- Seite 9 und 10: 12 Zusammenfassung und Ausblick....
- Seite 11 und 12: Kapitel 1 Einführung Design is one
- Seite 13 und 14: 1.2 Zielsetzung 3 Messverfahren. Da
- Seite 15 und 16: 1.4 Übersicht 5 Das allgemeine Qua
- Seite 17 und 18: Kapitel 2 Modelle und Metriken In d
- Seite 19 und 20: 2.2 Metriken 9 2.1.2 Beispiele […
- Seite 21 und 22: 2.2 Metriken 11 Merkmalsart Qualita
- Seite 23 und 24: 2.2 Metriken 13 Definition 2-2 (qua
- Seite 25: Kapitel 3 Objektorientierung What i
- Seite 29 und 30: 3.1 Begriffe 19 3.1.5 Abstrakte Kla
- Seite 31 und 32: 3.2 Unified Modeling Language 21 3.
- Seite 33 und 34: Kapitel 4 Objektorientierter Entwur
- Seite 35 und 36: 4.1 Was ist Entwurf? 25 rungen im C
- Seite 37 und 38: 4.2 Klassifikationen des Entwurfs 2
- Seite 39 und 40: 4.2 Klassifikationen des Entwurfs 2
- Seite 41 und 42: 4.3 Muster und Rahmenwerke 31 und P
- Seite 43 und 44: 4.3 Muster und Rahmenwerke 33 Kateg
- Seite 45 und 46: 4.5 Probleme des Entwurfs 35 Lösun
- Seite 47 und 48: 4.5 Probleme des Entwurfs 37 Kompon
- Seite 49 und 50: 4.5 Probleme des Entwurfs 39 Aufgab
- Seite 51 und 52: 4.5 Probleme des Entwurfs 41 • di
- Seite 53 und 54: Kapitel 5 Ein Referenzmodell für d
- Seite 55 und 56: 5.2 Umfang 45 Abbildung 5-2: UML-Me
- Seite 57 und 58: 5.2 Umfang 47 5.2.2 Erweiterungen N
- Seite 59 und 60: 5.3 Kern 49 und I muss in genau ein
- Seite 61 und 62: 5.3 Kern 51 • uses: C × (C ∪ I
- Seite 63 und 64: 5.4 Erweiterungen 53 5.4.2 Erweiter
- Seite 65 und 66: 5.5 Formale Definition von Metriken
- Seite 67 und 68: 5.5 Formale Definition von Metriken
- Seite 69 und 70: Kapitel 6 Softwarequalität Quality
- Seite 71 und 72: 6.1 Qualität 61 Benutzerbezogene S
- Seite 73 und 74: 6.2 Qualitätsmodelle 63 Die Defini
- Seite 75 und 76: 6.2 Qualitätsmodelle 65 Boehm et a
16 3 Objektorientierung<br />
ler: Berg et al. (1995) kommen in einer Untersuchung zu dem Ergebnis, dass 80% <strong>der</strong><br />
neu ausgebildeten Entwickler die Grundzüge <strong>der</strong> objektorientierten Entwicklung verstanden<br />
haben und sie anwenden können. Von diesen 80% entwickelten sich 5% zu<br />
sehr guten Entwicklern (top performers), 15% waren immerhin gut (journeyman<br />
level). Die große Mehrheit blieb allerdings Mittelmaß. Dass die objektorientierte Vorgehensweise<br />
nicht ohne Schwierigkeiten gemeistert werden kann, zeigen auch die<br />
Sammlungen typischer Fehler von Webster (1995) und Alexan<strong>der</strong> (2001).<br />
3.1 Begriffe<br />
Die Begriffe in <strong>der</strong> Objektorientierung werden häufig unterschiedlich definiert, o<strong>der</strong><br />
es werden für dasselbe Konzept unterschiedliche Begriffe verwendet. Das führt zu<br />
einem großen Begriffschaos (Sny<strong>der</strong>, 1993). Daher werden die Definitionen <strong>der</strong> zentralen<br />
Begriffe angegeben, wie sie in dieser Arbeit verwendet werden. Die verwendeten<br />
Definitionen stützen sich vor allem auf die Begriffsbildung im Zusammenhang<br />
mit UML gemäß Rumbaugh et al. (1998).<br />
Drei Eigenschaften zeichnen nach Wegner (1987, 1992) die objektorientierte Sichtweise<br />
aus: Objekte, Klassen und Vererbung. Viele Autoren nehmen noch Polymorphismus<br />
und das damit zusammenhängende dynamische Binden als wichtige Eigenschaften<br />
hinzu. Daher werden diese Begriffe zuerst eingeführt.<br />
3.1.1 Objekt<br />
Die zentrale Rolle spielt <strong>der</strong> Begriff des Objekts. Ein Objekt besteht aus Datenfel<strong>der</strong>n,<br />
den so genannten Attributen, und aus Funktionen auf diesen Daten, den so genannten<br />
Methoden. Methoden dienen zur Reaktion auf Nachrichten, die ein Objekt versteht.<br />
Methoden können z. B. den Zustand des Objekts (die Werte seiner Attribute) verän<strong>der</strong>n<br />
o<strong>der</strong> neue Nachrichten verschicken. Die Schnittstelle einer Methode wird als<br />
Operation bezeichnet; eine Methode ist also die Implementierung einer Operation.<br />
3.1.2 Klasse<br />
Die Objekte eines Systems werden nicht individuell beschrieben, son<strong>der</strong>n anhand<br />
ihrer Gemeinsamkeiten in Klassen zusammengefasst. Eine Klasse definiert die Attribute<br />
und Methoden ihrer Objekte. Die Klasse dient als Schablone zur Instantiierung<br />
(Erzeugung) von Objekten (Instanzen). Bei <strong>der</strong> Instantiierung müssen nur die Werte<br />
für die Attribute angegeben werden, die Methoden übernimmt das Objekt von seiner<br />
Klasse. Bei getypten objektorientierten Programmiersprachen wie C++ (Stroustrup,<br />
1997), Java (Gosling et al., 1998) o<strong>der</strong> Eiffel (Meyer, 1991) ist das Typkonzept mit dem<br />
Klassenkonzept verknüpft: Bei <strong>der</strong> Deklaration einer Klasse wird automatisch auch<br />
ein gleichnamiger Typ deklariert. Dieser Typ verfügt über einen Wertebereich, <strong>der</strong><br />
sich aus den Wertebereichen <strong>der</strong> Attribute zusammensetzt, und über Operationen, die<br />
den Methoden entsprechen. Daher definiert Meyer (1997) eine Klasse auch als die<br />
Implementierung eines abstrakten Datentyps. Ein Objekt ist vom Typ seiner Klasse.<br />
Abbildung 3-1 zeigt die UML-Darstellung einer Klasse und eines Objekts dieser<br />
Klasse. Der Name des Objekts wird zur besseren Unterscheidung unterstrichen.