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
44 5 Ein Referenzmodell für den objektorientierten Entwurf Abbildung 5-1: UML-Metamodell: Modellelemente (Ausschnitt) Die gemeinsame Oberklasse aller Modellelemente ist die Klasse ModelElement (vgl. Abbildung 5-1). NameSpace (Namensraum), eine Unterklasse von ModelElement, enthält eine beliebige Anzahl von Modellelementen und dient zur hierarchischen Strukturierung. Die Sichtbarkeit eines Modellelements innerhalb eines Namensraums wird durch die Assoziationsklasse ElementOwnership modelliert. Package (Paket) und Model (Modell) sind Unterklassen von NameSpace. Ein Modell ist ein spezielles Paket, das alles enthält, was zu einem UML-Modell gehört. In einem UML-Modell kann es daher immer nur eine Instanz von Model geben. Die Klasse Classifier (Klassifizierer) ist eine Unterklasse der abstrakten Klasse GeneralizableElement (generalisierbares Element), wodurch ausgedrückt wird, dass ein Klassifizierer Eigenschaften von anderen Klassifizierern erben kann. Class, Interface und DataType sind Unterklassen von Classifier. Klassifizierer können Features (Eigenschaften) enthalten; das ist hier durch eine Komposition modelliert. Attribute und Operation sind Unterklassen von Feature. Beziehungen zwischen Modellelementen wie z. B. Klassen und Interfaces werden ebenfalls als Klassen modelliert (siehe Abbildung 5-2). Die Klassen Association (Assoziation), Generalization (Generalisierung), Usage (Benutzung) und Abstraction (Abstraktion) sind Unterklassen der Klasse Relationship, die wiederum eine Unterklasse von ModelElement ist. Assoziationen werden mit Hilfe der zusätzlichen Klasse AssociationEnd modelliert, weil eine Assoziation mehr als zwei Modellelemente verbinden kann. Die übrigen Beziehungen verbinden genau zwei Modellelemente.
5.2 Umfang 45 Abbildung 5-2: UML-Metamodell: Beziehungen (Ausschnitt) 5.2 Umfang Abbildung 5-3 zeigt die konzeptionelle Struktur von ODEM. ODEM beruht auf dem UML-Metamodell. Für die Verwendung in ODEM wird das UML-Metamodell auf den tatsächlichen Bedarf reduziert. Zusätzlich werden nützliche, aus den Bestandteilen des UML-Metamodells abgeleitete Modellelemente eingeführt. Diese dienen vor allem dazu, als Abstraktionsschicht die Komplexität des UML-Metamodells nach außen zu verbergen. Außerdem sind sie praktisch bei der Definition von Metriken. Plattform zur Definition von Metriken Zusätzliche Modellelemente (Abstraktionsschicht) U M L - M e t a m o d e l l Abbildung 5-3: Konzeptionelle Struktur von ODEM 5.2.1 Einschränkungen ODEM schränkt das UML-Metamodell in bestimmten Bereichen ein, indem Elemente und Attribute von Elementen weggelassen werden. Dahinter stecken Überlegungen über die typische Verfügbarkeit bestimmter Entwurfsinformationen. Bei einer Darstellung des Entwurfs in UML sind häufig nur Klassen- und Paketdiagramme vorhanden und relativ vollständig. Diese beschreiben allerdings nur die statische Struktur des Entwurfs. Für die dynamische Struktur des Entwurfs werden vor allem Informationen über die Aufrufbeziehungen zwischen Methoden benötigt. Diese finden sich in den Sequenzund Zustandsdiagrammen. Typischerweise werden diese Diagramme aber nur für
- 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 und 26: Kapitel 3 Objektorientierung What i
- Seite 27 und 28: 3.1 Begriffe 17 Klasse Person mit A
- 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: Kapitel 5 Ein Referenzmodell für d
- 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
- Seite 77 und 78: 6.2 Qualitätsmodelle 67 IEEE Stand
- Seite 79 und 80: 6.3 Qualitätssicherung 69 6.2.4 Fa
- Seite 81 und 82: 6.3 Qualitätssicherung 71 rung und
- Seite 83 und 84: Kapitel 7 Entwurfsqualität Softwar
- Seite 85 und 86: 7.1 Ein Beispiel 75 scheidung nach
- Seite 87 und 88: 7.1 Ein Beispiel 77 WMC DIT NOC CBO
- Seite 89 und 90: 7.2 Perspektiven der Entwurfsqualit
- Seite 91 und 92: 7.2 Perspektiven der Entwurfsqualit
- Seite 93 und 94: 7.3 Entwurfsregeln 83 Produkt 1 Pro
- Seite 95 und 96: 7.3 Entwurfsregeln 85 Prinzip Besch
- Seite 97 und 98: 7.3 Entwurfsregeln 87 7.3.2 Heurist
- Seite 99 und 100: 7.4 Beispiele für OOD-Qualitätsmo
- Seite 101 und 102: 7.4 Beispiele für OOD-Qualitätsmo
- Seite 103 und 104: 7.4 Beispiele für OOD-Qualitätsmo
44 5 Ein Referenzmodell für den objektorientierten Entwurf<br />
Abbildung 5-1: UML-Metamodell: Modellelemente (Ausschnitt)<br />
Die gemeinsame Oberklasse aller Modellelemente ist die Klasse ModelElement (vgl.<br />
Abbildung 5-1). NameSpace (Namensraum), eine Unterklasse von ModelElement, enthält<br />
eine beliebige Anzahl von Modellelementen und dient zur hierarchischen Strukturierung.<br />
Die Sichtbarkeit eines Modellelements innerhalb eines Namensraums wird<br />
durch die Assoziationsklasse ElementOwnership modelliert. Package (Paket) und Model<br />
(Modell) sind Unterklassen von NameSpace. Ein Modell ist ein spezielles Paket, das<br />
alles enthält, was zu einem UML-Modell gehört. In einem UML-Modell kann es daher<br />
immer nur eine Instanz von Model geben.<br />
Die Klasse Classifier (Klassifizierer) ist eine Unterklasse <strong>der</strong> abstrakten Klasse GeneralizableElement<br />
(generalisierbares Element), wodurch ausgedrückt wird, dass ein Klassifizierer<br />
Eigenschaften von an<strong>der</strong>en Klassifizierern erben kann. Class, Interface und<br />
DataType sind Unterklassen von Classifier. Klassifizierer können Features (Eigenschaften)<br />
enthalten; das ist hier durch eine Komposition modelliert. Attribute und Operation<br />
sind Unterklassen von Feature.<br />
Beziehungen zwischen Modellelementen wie z. B. Klassen und Interfaces werden<br />
ebenfalls als Klassen modelliert (siehe Abbildung 5-2). Die Klassen Association (Assoziation),<br />
Generalization (Generalisierung), Usage (Benutzung) und Abstraction (Abstraktion)<br />
sind Unterklassen <strong>der</strong> Klasse Relationship, die wie<strong>der</strong>um eine Unterklasse<br />
von ModelElement ist. Assoziationen werden mit Hilfe <strong>der</strong> zusätzlichen Klasse AssociationEnd<br />
modelliert, weil eine Assoziation mehr als zwei Modellelemente verbinden<br />
kann. Die übrigen Beziehungen verbinden genau zwei Modellelemente.
Change language