Home

Bewertung der Qualität objektorientierter Entwürfe

Contents

1. U integrity z access control access audit usability operability NN ZN SY Y Y nl product revision training maintainability communicativeness simplicity testability SEN conciseness instrumentation flexibility self descriptiveness product transition SA VY LY G gt expandability d ER LS portability aS generality a modularity P l reusability software system independence E machine independence interoperability amp communications commonality ee GE data commonality Abbildung 6 3 Qualit tsmodell von McCall et al 66 6 Softwarequalitat ISO IEC Standard 9126 Der ISO IEC Standard 9126 versteht sich vor allem als Richtlinie zur Qualit tsbewer tung anhand von Metriken Um die Zusammenstellung eines Metrikprogramms zu erleichtern wird ein Qualitatsmodell ohne Metriken vorgeschlagen Die Metriken sollen spezifisch fiir das konkrete Projekt erg nzt werden In den Erl uterungen zum Modell wird darauf hingewiesen dass Qualit t aus ver schiedenen Sichten beurteilt werden kann was eine unterschiedliche Gewichtung der Faktoren nach sich zieht Es wird die Sicht des Benutzers des Entwicklers und des Managers unterschieden Der Schwerpunkt im Modell liegt von der Anzahl der Fak toren her auf der Benut
2. getGraph getPasswordManager processMagr ProcessHandler DataManager Abbildung 10 5 Entkopplung durch Interface bei Gruppe 8 Zusammenhalt Ein Beispiel ftir schlechten Zusammenhalt findet sich bei Gruppe 6 Dort gibt es eine God Class Riel 1996 namens Scheduler vgl Abbildung 10 6 Eine God Class ist ein typischer Anf ngerfehler n mlich die gesamte Funktion des Systems in einer Klasse zu konzentrieren oder zumindest von dort aus zu steuern Dies l uft der objektorien tierten Vorgehensweise Funktion zu dezentralisieren diametral entgegen Die Klasse Scheduler verwaltet sowohl die Passwort Informationen aus Datei lesen zugreifen ndern in Datei schreiben als auch die Fahrplaninformation aus Datei lesen zugreifen ndern in Datei schreiben Au erdem enth lt die Klasse auch noch den Suchalgorithmus f r die Verbindungssuche Insgesamt kommt so die stolze Zahl von 35 Operationen zusammen 13 ffentlich 22 privat Dass hier unterschiedliche Aufgaben in einer Klasse realisiert werden ist den Entwer fern auch selbst aufgefallen Sie haben zwei Interfaces vorgesehen die zur Trennung der Aufgaben nach au en dienen sollen und von der Klasse implementiert werden Das Interface SearchFrameDataAdapter repr sentiert den Suchalgorithmus Das Inter face AdminDataAdapter allerdings steht f r Passwort Verwaltung und Fahr plandatenverwaltung also sind auch hier bereits Aufgaben verquickt Sofern ber di
3. Neu ist hier die explizite Hinzunahme des Kontextes der Architektur sowie der Leitli nien der Architektur und ihrer Weiterentwicklung also eine Art design rationale Dies erleichtert das Verstandnis und die Weiterentwicklung der Architektur 4 3 2 Muster Die Musteridee stammt interessanterweise aus dem Fachgebiet der Architektur Dort haben Alexander et al 1977 sie bereits in den 70er Jahren propagiert vgl Lea 1994 Muster sind erprobte L sungen f r immer wiederkehrende Entwurfsprobleme Die Beobachtung von Entwerfern hat ergeben dass sie dazu neigen eher eigene fr here L sungen f r neue Probleme zu adaptieren statt v llig neue L sungen zu erarbeiten Parnas 1994 Diese Wiederverwendung spart viel Aufwand und f hrt zu brauchba ren L sungen wenn die wiederverwendete L sung auf das neue Problem passt Doch es kommt durchaus vor dass alte L sungen f r das Problem zurechtgebogen wer den statt nach neuen besseren L sungen zu suchen Das f hrt dazu dass das Ergeb nis wenig brauchbar ist Bei den Mustern werden zum einen die essentiellen Eigenschaften herausgearbeitet indem vom konkreten Problem abstrahiert wird Zum anderen wird genau dokumen tiert wann das Muster anwendbar ist und wann nicht Auf diese Weise k nnen L sungen wie gewohnt wiederverwendet werden Durch die Dokumentation der Anwendungsbedingungen ist die Wahrscheinlichkeit einer falschen Verwendung eines Musters aber geringer Ein Nac
4. Schlie lich kann auch nach lokal definierten 1 local und geerbten i inherited Attributen unterschieden werden Geerbte Attribute tragen in der Regel insbeson dere bei eingeschr nkter Sichtbarkeit nicht soviel zur Komplexit t einer Klasse bei wie lokal definierte Attribute NAC number local attributes of a class NACi c ae A has c a NAC number of inherited attributes of a class NAC c NAC c NAC c ae A has c a A has c a Die Verfeinerungen lassen sich kombinieren so dass man z B die Metrik NAC als die Anzahl der ffentlich sichtbaren geerbten Klassenattribute einf hren kann Weitere Verfeinerungen aus semantischer Sicht sind ebenfalls denkbar z B eine Unterscheidung in fachliche und technische Klassen oder eine Zuordnung zu Schich ten oder Aufgabenbereichen wie z B Benutzungsoberfl che funktionaler Kern und Datenhaltung Da diese Verfeinerungen aber aufgrund der in ODEM vorliegenden Information nicht automatisch gebildet werden k nnen sind hier keine Metriken daf r definiert Entsprechende Metriken k nnten aber einem spezifischen Qualit ts modell hinzugef gt werden Metriken f r Beziehungen Zus tzlich sind die ausgehenden efferenten Beziehun gen der Klasse zu z hlen weil sie negative Auswirkungen auf die Knappheit haben A 1 Knappheit 191 Ihre Verwaltung muss in der Klasse implementiert werden so dass jede Beziehung die Knappheit verringert Die ents
5. NOC this Gibt es keine hnlichen Operationen in anderen 0 nein ee gt 0 Klassen Wird die Implementierung vermutlich 1 ja keinen redundanten Code enthalten NOC this Ben tigt jede Operationen alle ihre Parameter 0 nein oi gt 0 1 ja NEEC this F gt die Unterklasse neue Attribute oder Opera 0 nein v gt 0 tionen hinzu 1 ja thiseC A Hat die abstrakte Klasse mindestens eine Unter 0 nein Get v this isAbs klasse 1 ja tract thise Wird das Interface realisiert oder von anderen 0 nein BER Y Interfaces geerbt 1 ja Fragebogen B 1 Knappheit Klasse Interface B 2 Strukturiertheit 205 Paket Bedingung Fragetext Antwortskala Gewicht auto Enthalt das Paket mindestens eine Komponente 0 nein Cree Y 1 ja Ist das Vorhandensein des Paket notwendig 0 nein TER 1 ja Fragebogen B 2 Knappheit Paket System Bedingung Fragetext Antwortskala Gewicht auto Gibt es keine zwei oder mehr Klassen welche die 0 nein SRK gleiche Aufgabe haben also bis auf eine ber ja fl ssig sind Gibt es keine zwei oder mehr Pakete welche die 0 nein RER gleiche Aufgabe haben also bis auf eines ber 1 ja fl ssig sind Gibt keine zwei oder mehr Unterklassen einer 0 nein SER Klasse die hnliche oder gleiche Eigenschaften haben die in die Oberklasse verschoben werden sollten 1 ja Fragebogen B 3 Knappheit System B 2 Struk
6. Paket Bedingung Fragetext Antwortskala Gewicht auto Sind alle Dokumentationsstandards eingehalten 0 nein ZER worden 1 ja Ist der Name des Pakets geeignet 0 nein ER 1 ja Ist dokumentiert wozu das Paket und die enthal 0 nein RER tenen Klassen Interfaces dienen 1 ja Ist die Paketdokumentation strukturiert vollst n 0 nein ERS dig prazise konsistent und korrekt 1 ja Sind alle Namen im Paket so unterschiedlich 0 nein G t dass keine Verwechslungsgefahr besteht 1 ja Fragebogen B 16 Dokumentierung Paket B 7 Verfolgbarkeit 213 System Bedingung Fragetext Antwortskala Gewicht auto Sind alle Dokumentationsstandards eingehalten 0 nein KE worden 1 ja Stellt jedes Diagramm nur einen oder wenige 0 nein FAR Aspekt e des Entwurfs vollst ndig dar 1 ja Ist die Systemdokumentation insgesamt sinnvoll 0 nein Set aufgebaut und verstandlich 1 ja Ist die Form der Pr sentation annehmbar 0 nein Layout Typographie 1 ja Werden Begriffe aus der Anwendungswelt ange 0 nein ae messen verwendet 1 ja Sind alle Namen im System so unterschiedlich 0 nein ae dass keine Verwechslungsgefahr besteht 1 ja Fragebogen B 17 Dokumentierung System B 7 Verfolgbarkeit F r die Verfolgbarkeit ist es wichtig dass Entwurfsentscheidungen auf die Anforde rungen zur ckgef hrt werden k nnen Umgekehrt muss auch klar sein
7. 142 10 Ein spezifisches Qualitatsmodell 10 2 2 Bemerkungen zu den Entwurfen Vererbung Bei den Entwiirfen fallt auf dass Vererbung kaum verwendet wird Das deckt sich auch mit Beobachtungen von Cartwright 1998 aus studentischen Projekten Wenn Vererbung verwendet wurde beschrankt sie sich auf eine Stufe Anhand positiver und negativer Beispiele wird die Nutzung der Vererbung in den Entw rfen illustriert Gruppe 8 verwendet das Strategy Muster Gamma et al 1995 um den Algorithmus zur Verbindungssuche je nach Optimierungsziel zu parametrisieren Dazu dient die abstrakte Klasse Optimization mit ihren drei Unterklassen welche die verschiedenen Optimierungsziele repr sentieren vgl Abbildung 10 2 Wichtigste Operation ist dabei getWeight welche die Bewertung einer Verbindung gem dem Optimierungs ziel liefert Die Unterklassen implementieren die Operation aus der Oberklasse mit der korrekten Bewertungsmethode Optimization DEENEN getlveightic Connection int compareloT G2 Object ona LeastInterchangesOptimization LeastDurationOptimization EarliestArrivalOptimization ees es eee DEE getWeight c Connection int getWeight c Connection int getWeight c Connection int compare ol o2 Object compare ol o2 Object compare o1 o2 Object toString toString toString Abbildung 10 2 Strategy Muster bei Gruppe 8 Eine Alternative dazu ist die Verw
8. Das System wird im Geiste des Teile und herrsche Prinzips in sinnvolle Subsysteme und Module zerlegt Das Modul dient dabei als Beh lter f r Funktionen oder Zust ndigkeiten des Systems Trenne die Zust ndig keiten separation of con cerns Das System wird anhand von Zust ndigkeiten h ufig auch als Ver antwortlichkeiten bezeichnet in Komponenten aufgeteilt Kompo nenten die an der gleichen Aufgabe beteiligt sind werden gruppiert und von denen abgegrenzt die f r andere Aufgaben zust ndig sind Trenne Verhalten und Implementierung separation of policy and implementation Rum baugh et al 1993 Eine Komponente oder eine Methode soll entweder f r das Ver halten oder die Implementierung zust ndig sein nicht f r beides Eine Komponente f r das Verhalten trifft Entscheidungen anhand des Kontextes interpretiert Ergebnisse und koordiniert andere Komponenten Eine Komponente f r die Implementierung dagegen f hrt einen Algorithmus auf vorliegenden Daten aus Komponenten f r die Implementierung sind in der Regel stabil w hrend sich die Komponenten f r das Verhalten oft ndern daher gibt es Sinn sie zu trennen Kapsele Zusammen geh riges Zusammengeh rige Bestandteile einer Abstraktion werden zu einem Ganzen zusammengefasst und von anderen abgegrenzt Die Implementierung wird hinter einer Schnittstelle verborgen Bei der objektorientierten Sichtweise wird die Kapselung durch die Defini tion
9. Die Notation sollte allen Entwicklern vertraut und leicht erlernbar sein Au erdem sollte sich m glichst viel m glichst pr zise in ihr ausdr cken lassen Schlie lich sollte sie robust sein das hei t kleine nderungen der Syntax sollten nicht gro e nderun gen der Semantik verursachen Ansonsten k nnen kleine Fehler in der Dokumenta tion zu gro en Fehlern in der Implementierung f hren Die beste Notation ist aller dings ohne Nutzen wenn die darin erstellte Dokumentation nichts taugt 112 8 Das allgemeine Qualit tsmodell 8 3 7 Verfolgbarkeit Definition Verfolgbarkeit traceability ist die M glichkeit Entwurfsentscheidungen auf die Anforderungen zur ckzuf hren und umgekehrt Beispielsweise sollte zu einer Klasse angegeben werden f r welche Anwendungsf lle der Spezifikation sie ben tigt wird Diskussion Wenn sich Anforderungen ndern ist es durch Verfolgbarkeit leichter die betroffenen Stellen im Entwurf zu identifizieren Dadurch wird die Wartbarkeit verbessert Struk tur hnlichkeiten zwischen Problem und L sungsstruktur structural correspon dence vgl Abschnitt 7 3 1 erleichtern die Verfolgbarkeit ungemein ohne dass es dazu aufwendiger Dokumentation bedarf Diese Struktur hnlichkeit ist eine der ver sprochenen Vorteile der Objektorientierung weshalb eine entsprechende objektorien tierte Vorgehensweise f r gute Verfolgbarkeit sorgen kann Allerdings h lt Royce 2000 das Streben nach detail
10. Die statische Struktur wird in UML vor allem mit Klassendiagrammen beschrieben Bei einer objektorientierten Implementierung stimmt die Codestruktur in hohem Ma e mit der statischen Struktur berein da der objektorientierte Code ebenfalls klassenorientiert ist Dynamische Struktur Die dynamische Struktur entsteht beim Ablauf des Programms Sie wird vor allem durch die vorhandenen Objekte gepr gt die Instanzen der Klassen aus der statischen Struktur sind Die Objekte haben Beziehungen schicken einander Nachrichten ndern ihren Zustand erzeugen neue Objekte oder zerst ren vorhandene Die Vertei lung der Objekte auf unterschiedliche Rechnerknoten spielt f r die dynamische Struktur ebenfalls eine Rolle Jeder Zustand des Systems w hrend der Ausf hrung ist eine Auspr gung der statischen Struktur Im Gegensatz zur statischen Struktur ist die dynamische Struktur dem Code nur sehr schwer zu entnehmen Zum einen besteht sie aus einer Vielzahl von Objekten die untereinander in den unterschiedlichsten Beziehungen stehen Das Objekt Netzwerk ist sehr komplex und ver ndert sich laufend ber die Zeit so dass es nur in Aus schnitten verstanden werden kann Zum anderen ist die Funktion ber den Code ver streut Soloway et al 1988 nennen diese Verstreuung logisch zusammengeh riger Teile einer Funktion ber die Implementierung delocalized plans Die Delokalisie rung der Funktion macht das Verstehen eines objektorientierten Programm
11. EN Herrenberg Plochingen 04 47 05 17 05 47 06 17 17 11 47 12 17 12 47 13 17 47 18 17 18 47 19 17 00 09 04 39 05 09 05 39 12 9 7 17 07 47 08 17 08 47 09 17 09 47 10 17 10 47 11 TAS AT LAT VASAT PO Poe Ad TO Lose Vie 9 47 20 17 20 47 21 17 21 47 22 47 23 17 6 09 06 39 07 09 07 39 08 09 08 39 09 09 09 39 10 9 8 09 10 39 11 09 11 39 16 39 17 09 17 39 18 0 09 23 39 4 Nufringen 2 G rtringen 3 Ehningen 3 Hulb 2 B blingen 3 5 2 125395 13209 13239 12309 12 39 15209 15 39 16 09 39 19 09 20 09 20 39 21 09 21 39 22 09 22 39 23 Goldberg Rohr Vaihingen 2 sterfeld 2 Universit t 5 Schwabstra e 2 Feuersee 1 Stadtmitte 2 Hauptbahnhof 4 Bad Cannstatt 3 Neckarstadion 2 Untert rkheim 3 Oberttirkheim 2 2 2 Mettingen Esslingen Oberesslingen 224 C Dokumente zum Softwarepraktikum Ltbach lochingen Sigh 2 A EE C 2 7 Was das Programm nicht leisten soll e nderung der Fahrzeiten e Hinzuf gen neuer Haltestellen e alle Verbindungen in gew nschtem Zeitrahmen anzeigen e Unterscheidung von Wochenenden und Wochentagen C 2 8 Qualit tsanforderungen Portabilit t Die Software soll zum einen ger teunabh ngig sein d h keine Merkmale spezieller Ger te enthalten oder verwenden Weiterhin soll die Software abgeschlossen sein d h keine Schnittstellen zu anderen Programmen ent
12. Erfahrung und Intuition sind f r einen guten Entwerfer sehr wichtig Budgen 1994 Der Erwerb von Erfahrung ist aber langwierig und teuer Man muss viele Systeme entwerfen und aus den gemachten Fehlern lernen In der Regel werden aber die Sys teme f r reale Projekte entworfen und danach auch implementiert Das kann zu enor men Fehlerfolgekosten f hren wenn schlecht entworfene Systeme berarbeitet wer den m ssen F r den Erwerb der praktischen Erfahrung ist daher zu Beginn ihrer Berufspraxis die Besch ftigung als Lehrling bei einem guten erfahrenen Entwerfer sinnvoll McBreen 2001 Auf diese Weise wird das oben skizzierte Lernen durch Instruktion mit Lernen durch Imitation kombiniert 42 4 Objektorientierter Entwurf 43 Kapitel 5 Ein Referenzmodell fur den objektorientierten Entwurf Um einen objektorientierten Entwurf bewerten zu k nnen muss man zun chst festle gen was man genau darunter versteht Dazu dient das f r diese Arbeit neu entwi ckelte formale Modell das Object Oriented Design Model ODEM genannt wird ODEM enth lt die Teile des objektorientierten Entwurfs die als f r die Bewertung relevant erachtet werden Dabei wird von Entwurfsartefakten ausgegangen die typi scherweise vorhanden sind ODEM kann auch f r die formale Definition von Metri ken auf diesen Artefakten verwendet werden 5 1 Grundlagen Die in Kapitel 3 vorgestellte Entwurfsnotation UML ist der Standard f r die Darstel lung o
13. The Art of Human Computer Interface Design Addison Wesley Reading MA 1990 Nenonen et al 2000 Nenonen L Gustafsson J Paakki J Verkamo A 2000 Measuring Object Oriented Software Architectures from UML Diagrams Proceedings of the 4th International ECOOP Workshop on Quantitative Approaches in Object Ori ented Software Engineering Sophia Antipolis France 2000 87 100 Oestereich 1998 Oestereich B Objektorientierte Softwareentwicklung Analyse und Design mit der Unified Modeling Language 4 Auflage Oldenbourg Miinchen 1998 OMG 2000a Object Management Group OMG Unified Modeling Language Specifi cation Version 1 3 March 2000 OMG 2000b Object Management Group OMG XML Metadata Interchange XMI Specification Version 1 1 November 2000 Page Jones 1988 Page Jones M The Practical Guide to Structured Systems Design 2 Auflage Prentice Hall Englewood Cliffs New Jersey 1988 Page Jones 1995 Page Jones M What Every Programmer Should Know About Object Oriented Design Dorset House New York 1995 Pancake 1995 Pancake C The Promise and the Cost of Object Technology A Five Year Forecast Communications of the ACM 38 10 1995 32 49 182 Literatur Parnas 1972a Parnas D Information Distribution Aspects of Design Methodology In Freiman C Hrsg Information Processing 71 Volume I Foundations and Sys tems North Holland Publishing Company Amsterdam 1972 339 344
14. 4 2 Klassifikationen des Entwurfs In diesem Abschnitt werden verschiedene Aspekte betrachtet nach denen sich der Entwurf klassifizieren l sst Strategie Aktivit t Abstraktionsebene und Struktur 4 2 1 Strategien Die Strategie bestimmt auf welche Weise der Entwurf angegangen wird Hier wird die historische Entwicklung hin zur objektorientierten Strategie grob chronologisch dargestellt Der Stand der Praxis ist dem Stand der Wissenschaft in der Regel immer einige Jahre hinterher Eine bersicht von Entwurfstechniken findet sich bei Yau und Tsai 1986 Kein Entwurf Impliziter Entwurf Zu Anfang wurden nur kleine Programme in Maschinencode oder Assembler geschrieben Der Entwurf sofern vorhanden war im Wesentlichen das Programm in einem Pseudocode der einer h heren Programmiersprache entsprach Der Bedarf f r einen expliziten Entwurf auf einer h heren Abstraktionsebene war nicht vorhanden oder nicht klar Im Zusammenhang mit der Softwarekrise wurde deutlich dass ein expliziter Entwurf vorteilhaft ist wenn komplexere Programme erstellt werden Strukturierter Entwurf Die Aufteilung des Systems wird vorgenommen anhand von Funktionen funktions orientierter Entwurf Die Granularit t des Entwurfs ist die Prozedur Datenstruktu ren Records Listen etc dienen zur Modellierung der Daten Eingef hrt wurden 1 Opportunistisch bedeutet hier dass der Entwerfer beim Entwerfen als n chste Aktion diejenige mit der geringsten ko
15. Entwurf als Problem The fundamental problem is that designers are obliged to use current information to predict a future state that will not come about unless their predictions are correct The final outcome of designing has to be assumed before the means of achieving it can be explored the designers have to work backwards in time from an assumed effect upon the world to the beginning of a chain of events that will bring the effect about Jones 1992 S 9 Es ist ausgesprochen schwierig einen guten Entwurf zu schaffen Visser und Hoc 1990 stufen den Entwurf als schlecht definiertes Problem ill defined problem ein 40 4 Objektorientierter Entwurf Budgen 1994 bezeichnet den Entwurf sogar als ein b sartiges Problem wicked problem B sartige Probleme sind nach Rittel und Webber 1984 unter anderem durch folgende Eigenschaften gekennzeichnet e Es gibt keine endg ltige Formulierung des Problems Ein Grund daf r ist dass sich Spezifikation und Entwurf nicht klar trennen lassen Swartout Balzer 1982 e Es gibt keine Regel die angibt wann die optimale L sung gefunden wurde Das liegt daran dass die Bewertung einer L sung schwierig ist weil es meistens keine klare Festlegung aller gew nschten Eigenschaften gibt es fehlt also ein Qualit ts modell e L sungen f r b sartige Probleme sind nicht richtig oder falsch sondern gut oder schlecht Es gibt keine wirklich falsche L sung nur weniger oder besser brauch
16. Expert Software Design Strategies In Hoc J Green T Samurgai R Gilmore D Hrsg Psychology of Programming Academic Press London 1990 235 249 Vlissides et al 1996 Vlissides J Coplien J Kerth N Hrsg Pattern Languages of Program Design 2 Addison Wesley Reading MA 1996 185 Wand 1989 Wand Y A Proposal for a Formal Model of Objects In Kim W Locho vsky F Hrsg Objects Oriented Concepts Applications and Databases Addison Wesley Reading MA 1989 537 559 Warmer Kleppe 1999 Warmer J Kleppe A The Object Constraint Language Pre cise Modeling with UML Addison Wesley Boston 1999 Webster 1995 Webster B F Pitfalls of Object Oriented Development M amp T Books New York 1995 Wegner 1987 Wegner P Dimensions of Object Based Language Design Proceed ings of OOPSLA 87 ACM SIGPLAN Notices 22 12 1987 168 182 Wegner 1992 Wegner P Dimensions of Object Oriented Modeling IEEE Com puter 25 10 1992 12 19 Weinand et al 1989 Weinand A Gamma E Marty R Design and Implementa tion of ET a Seamless Object Oriented Application Framework Structured Pro gramming 10 2 1989 63 87 Weinand Gamma 1994 Weinand A Gamma E ET a Portable Homogenous Class Library and Application Framework In Bischofberger W Frei H Hrsg Computer Science Research at UBILAB Strategy and Projects Proceedings of the UBI LAB 94 Conference Zu
17. Faktor 1 Faktor 2 u Faktor k Kriterium 1 Kriterium 2 Kriterium 3 Kriterium n Metriken Abbildung 6 1 Aufbau eines Qualit tsmodells nach Balzert 1998 S 257 In der Software Engineering Literatur gibt es einige Vorschl ge f r Qualit tsmodelle vgl Roche Jackson 1994 Dabei gibt es im Wesentlichen zwei verschiedene Ans tze f r die Gewinnung von Qualit tsmodellen Der eine Ansatz stellt ein vollst ndiges generisches Qualit tsmodell zur Verf gung aus dem durch Streichungen und Verfei nerungen ein f r den eigenen Bedarf passendes Modell generiert werden kann vgl Abschnitt 6 2 2 Der andere Ansatz definiert lediglich ein Vorgehensmodell mit dem ein passendes Qualit tsmodell entwickelt werden kann vgl Abschnitt 6 2 3 6 2 2 Generische Qualit tsmodelle Die beiden ltesten generischen Qualit tsmodelle von Boehm et al 1978 und McCall et al 1977 stammen aus den sp ten 70er Jahren sp ter weiterentwickelt von Bowen et al 1984 Die Standardisierung begann erst Anfang der 90er Jahre mit dem ISO IEC Standard 9126 1991 und dem IEEE Standard 1061 1992 portability L device independence ra EE E completeness as is utility We Lee penas accuracy i e reliability consistency C efficiency device efficiency accessibility A Y Y hl human engineerg communicativeness testability s
18. NPP number of packages in a package NPP p qe P contains p q System NAS number of attributes in the system NAS S Al NOS number of operations in the system NOS S IO NCS number of classes in the system NCS S IC NIS number of interfaces in the system NIS S II NPS number of packages in the system NPS S P 1 daSinP enthalten ist ist 1 abzuziehen Verfeinerungen Als Beispiel einer Verfeinerung wird hier die Verfeinerung der Metrik NCP gezeigt die sich ergibt wenn abstrakte und konkrete Klassen unterschieden werden NCP number of abstract classes in a package NCP p ceC contains p c A c isAbstract NCP number of concrete classes in a package NCP p ceC contains p c A c isAbstract 9 2 4 Auswertung Aus den objektiven Metriken kann ein Bewertungsvorschlag f r die zugeh rige sub jektive Metrik gewonnen werden Dazu werden die Metriken eines Kriteriums einer Ebene z B Knappheit Paket aggregiert und das Ergebnis auf den Wertebereich der subjektiven Metriken abgebildet Verfahren Die Berechnung eines Bewertungsvorschlags verl uft in drei Schritten 1 Normierung der Metriken um aus den Messwerten Qualit tsaussagen abzuleiten 2 Gewichtung der normierten Metriken um die relative Bedeutung der Qualit ts aussagen zu ber cksichtigen und 3 Transformation des Resultats auf den Wertebereich der subjektiven Metriken 124 9 Quantifizier
19. Parnas 1972b Parnas D On the Criteria to be Used in Decomposing Systems into Modules Communications of the ACM 15 12 1972 1053 1058 Parnas 1974 Parnas D On a Buzzword Hierarchical Structure In Rosenfeld J Hrsg Information Processing 74 North Holland Publishing Company Amsterdam 1974 336 340 Parnas 1994 Parnas D Software Aging Proceedings of the 16th International Con ference on Software Engineering ICSE 16 Sorrento Italy IEEE Computer Society Press Los Alamitos CA 1994 279 287 Parnas Clements 1986 Parnas D Clements P A Rational Design Process How and Why to Fake It IEEE Transactions on Software Engineering 12 2 1986 251 257 Petroski 1992 Petroski H To Engineer is Human The Role of Failure in Successful Design Vintage Books New York 1992 Petroski 1994 Petroski H Design Paradigms Case Histories of Error and Judgment in Engineering Cambridge University Press Cambridge 1994 Pfleeger 2000 Pfleeger S Use Realistic Effective Software Measurement In Clem ents P Hrsg Constructing Superior Software MacMillan Indianapolis IN 2000 211 236 Pirsig 1981 Pirsig R Zen and the Art of Motorcycle Maintenance Bantam New York 1981 Pree 1995 Pree W Design Patterns for Object Oriented Software Development Addison Wesley 1995 Pressman 1994 Pressman R Software Engineering European Edition 3 Auflage McGraw Hill New York 199
20. Vererbung kann f r verschiedene Zwecke verwendet werden Budd 1991 Meyer 1996 1997 und Taivalsaari 1996 haben Klassifikationen f r Vererbung aufgestellt die zwar sehr detailliert sind aber in manchen Belangen fragw rdig erscheinen Die wichtigsten Arten sind Spezialisierung und Implementierungsvererbung Bei der Spezialisierung liegt der Schwerpunkt auf der Typ Subtyprelation von Ober und Unterklasse analog einer Spezialisierung in einer Taxonomie Die Vererbung der Implementierung ist nur ein willkommener Nebeneffekt Der Vorteil der Spezialisie rung liegt darin dass die Schnittstelle der Oberklasse auch von der Unterklasse ange boten wird mit der Garantie dass die Semantik der Schnittstelle erhalten bleibt gem dem Liskovschen Substitutionsprinzip vgl Abschnitt 7 3 1 Ein Spezialfall ist die reine Schnittstellenvererbung bei der gar keine Implementierung vererbt wird dies ist beim Erben von rein abstrakten Klassen oder Interfaces s u der Fall Im Gegensatz dazu steht die Implementierungsvererbung deren Schwerpunkt auf der Wiederverwendung von Code liegt Hier wird eine Klasse um ihrer Implementierung willen beerbt wobei die geerbte Implementierung mittels Redefinition Erweiterung und Weglassen so zurechtgebogen wird dass sie passt Der bei der Spezialisierung garantierte Erhalt der Semantik ist insbesondere durch das Weglassen nicht mehr gegeben Das kann zu schwer auffindbaren Fehlern f hren wenn Objekt
21. dem wird die Erhebung einer subjektiven Metrik durch die Verwendung des gerun deten Gesamtvorschlags ersetzt Auf diese Weise kann im Bewertungsverfahren auf den Bewerter verzichtet werden Allerdings gehen dadurch alle Aspekte verloren die der Bewerter bei der Erhebung der subjektiven Metrik zus tzlich hatte einflie en las sen Z B eigene Erfahrung Au erdem fallen durch den notwendigen Verzicht auf nicht automatisierbare Fragen Kriterien wie Einheitlichkeit und Dokumentierung g nzlich unter den Tisch weil es dort weder objektive Metriken noch automatisch beantwortbare Fragen gibt Bei anderen Kriterien wie Zusammenhalt gehen durch den Verzicht sehr viele Aspekte verloren Eine vollst ndige Automatisierung geht also auf Kosten der Vielfalt in der Bewertung 9 6 Ableitung spezifischer Modelle In diesem Abschnitt wird beschrieben wie aus QOOD ein spezifisches Qualit tsmo dell abgeleitet wird 9 6 1 Vorgehen Voraussetzung f r die Ableitung eines spezifischen Modells aus QOOD ist eine Anforderungsanalyse welche die gew nschten Qualit ten und ihre Gewichtung ermittelt Die Anforderungen stammen aus dem Kontext z B Firmen oder Projek trichtlinien den konkreten Qualit tsanforderungen f r das System und der einge nommenen Qualit tssicht Sie bestimmen die Auswahl der Modellbestandteile Schritte 1 3 5 und 7 und ihre Gewichtung Schritte 2 4 6 8 und 9 relevante Faktoren ausw hlen die Gewi
22. eren Bedarf haben das Modell einzusetzen weil es ihnen an Erfahrung fehlt und sie daher auch nicht ber Intuition im Bereich der Entwurfsqualit t verf gen Dieses Defizit kann teilweise durch das Bewertungsverfahren und daraus gewonnene Richtlinien ausgeglichen werden Einsatzgebiete Das Verfahren eignet sich e zur Feststellung der Qualit t eines Entwurfs e zur Entscheidung zwischen Entwurfsalternativen indem alle Alternativen bewer tet werden und diejenige mit der besten Bewertung ausgew hlt wird und e zur Untersuchung eines objektorientierten Entwurfs auf m gliche M ngel hinsicht lich verschiedener Eigenschaften z B Wartbarkeit Die M ngelanalyse liefert in der Regel nur Hinweise auf potentielle M ngel Sie erlaubt jedoch eine bessere Fokussierung analytischer Ma nahmen zur Qualit tssi cherung welche die tats chlichen M ngel identifizieren k nnen Die gefundenen M ngel k nnen dann behoben werden Die Entwurfsverbesserung wird erleichtert wenn die M ngelanalyse auch gleich Hinweise auf bessere alternative Strukturen lie fert Der Alternativenvergleich kann auch bei entwurfsverbessernden Restrukturie rungen zum Vorher Nachher Vergleich verwendet werden um eine tats chliche Ver besserung sicherzustellen Anforderungen Damit das Bewertungsverfahren praktisch anwendbar ist sollten die folgenden Anforderungen erf llt sein 1 Das Verfahren sollte so fr h wie m glich in der Entwurfsphase einsetzbar sei
23. rungen im Code weil eine geplante Struktur v llig fehlt nderungen sind schwierig umzusetzen da nicht klar ist welche Teile des Systems betroffen sind und welche Auswirkungen die nderungen auf andere Teile haben k nnen 4 1 2 Entwurfsprozess Design is fundamentally social and fundamentally creative Berg et al 1995 S 61 Die Anforderungsspezifikation ist nicht das Einzige was den Entwurfsprozess steu ert vgl Abbildung 4 2 Hinzu kommen noch Entwurfseinschr nkungen z B Man gel an Ressourcen oder an Erfahrung mit einer bestimmten Technologie und die Ent scheidungen des Entwerfers die durch sein Wissen und seine Erfahrung bestimmt sind Auch die vorhandene Infrastruktur hat Einfluss auf den Entwurfsprozess Bei spielsweise spiegelt die Struktur des Entwurfs oft die Struktur der entwickelnden Organisation wieder vgl Abschnitt 4 5 2 Anforderungs spezifikation Einschr nkungen Ressourcen Organisation Erfahrung Entscheidungen des Entwerfers Entwurfs prozess Entwurfs beschreibung Abbildung 4 2 Modell des Entwurfsprozesses nach Budgen 1994 S 27 Nach Jones 1992 zerf llt der Entwurfsprozess in drei Phasen 1 Divergenz Analyse Problemanalyse Suchraum definieren 2 Transformation Synthese Generieren von L sungsalternativen innerhalb des Suchraums 3 Konvergenz Evaluation Bewertung der L sungsalternativen und Auswahl einer L sung Diese Phasen we
24. setPriceCodetint lt lt Call gt gt statement Abbildung 7 1 Klassendiagramm fiir Entwurf A statement i ffor all rentals getMoviet getPriceCodef getDaysRented Abbildung 7 2 Sequenzdiagramm fiir Entwurf A Dieses Vorgehen ist ein Versto gegen das Demetergesetz Lieberherr Holland 1989 weil bei einem Objekt das von einer anderen Klasse Rental als Resultat eines Metho denaufrufs getMovie geliefert wurde eine Methode aufgerufen wird getPriceCode Dadurch entsteht eine unn tige Kopplung zwischen Customer und Movie die als Benutzungsbeziehung mit Stereotyp call im Klassendiagramm sichtbar ist Um diese zu vermeiden sollte stattdessen ber Rental delegiert werden Au erdem l sst sich feststellen dass die Preisberechnung f r einen einzelnen Ausleihvorgang logisch gesehen eigentlich zu Rental geh rt da dort bereits alle erforderlichen Informationen vorliegen In statement m ssten die einzelnen Betr ge dann nur noch aufsummiert werden Die Preisberechnung anhand des Preiscodes ist bei Movie am besten aufgeho ben da sich so neue Preiscodes besser kapseln lassen Verbergen einer Entwurfsent 7 1 Ein Beispiel 75 scheidung nach dem Geheimnisprinzip Parnas 1972b Die zur Berechnung ben tigte Leihdauer muss nun beim Aufruf als Parameter bergeben werden Werden die genannten Verbesserungen an Entwurf A umgesetzt entsteht Entwurf B vgl Abbil
25. 1998 in einer anderen war es umgekehrt Daly et al 1996 Dabei k nnen aber auch grunds tzliche Schwierigkeiten der Experimentteilnehmer mit Vererbung die Ursache gewesen sein El Eman und Melo 2001 geben eine bersicht ber die widerspr chlichen Ergebnisse der Experimente in diesem Bereich In ihrer Untersuchung kommen sie zu dem Schluss dass DITC ein guter Indikator f r die Fehleranf lligkeit einer Klasse ist aufgrund geringer Ver st ndlichkeit A 3 Entkopplung 193 Neben der Tiefe der Vererbungshierarchie kann noch ihre Verzweigung betrachtet werden Aus Sicht einer Klasse ist das zum einen die Anzahl der Unterklassen gemessen durch die Metrik NAEC number of local afferent extends relationships of a class definiert beim Kriterium Entkopplung Ein anderes Verzweigungsma ist die Anzahl der Oberklassen Die zugeh rige Metrik NEEG number of local efferent extends relationships of a class ist ebenfalls beim Kriterium Entkopplung definiert Hohe Verzweigung ist schlecht f r die Strukturiertheit Paket Schachtelung Auf Paketebene gibt es die Tiefe und den Verzweigungsgrad der Schachtelungshierar chie Die Metrik f r die Tiefe in der Schachtelungshierarchie ist DNHP depth in nesting hierarchy of a package DNHP p DNHP q contains q p 1 DNHP S 1 damit Pakete auf der obersten Ebene ein DNHP von 0 haben Der Verzweigungsgrad d h die Anzahl der eingeschachtelten Pakete wurde bereits bei der Knapphei
26. Chidamber Kemerer 1994 Briand et al 1997 Im Wesentlichen st tzen sich diese Metriken auf Gemeinsamkeiten zwischen den Methoden einer Klasse z B bei LCOM Chidamber Kemerer 1994 auf Zugriffe zweier Methoden auf die gleichen Attribute Solch detail lierte Entwurfsinformation ist aber im UML Modell und damit in ODEM nicht vor handen Ab Einheitlichkeit 197 Ein alternativer Vorschlag zur Messung des Zusammenhalts der auf der Basis von ODEM m glich ist stammt von Bansiya et al 1999 die dazu Parametertypen der Operationen der Klasse heranzuziehen Die Metrik CAMC Cohesion Among Meth ods in Class berechnet die durchschnittliche berschneidung der Parametertypen einer Methode mit der Gesamtmenge der Parametertypen Einen hnlichen Vorschlag gibt es auch von Chen und Lu 1993 Beide Vorschl ge beruhen allerdings auf der fragw rdigen Annahme dass Operationen mit gemeinsamen Parametertypen auf h heren Zusammenhalt hindeuten Die empirische Validierung der Vorschl ge ver mag jedenfalls nicht zu berzeugen Mangels geeigneter objektiver Metriken muss daher f r den Zusammenhalt auf eine subjektive Metrik zur ckgegriffen werden Paket Auf Paketebene wurde bisher nur ein Indikator f r den Zusammenhalt der Klassen und Interfaces in einem Paket vorgeschlagen Martin 1995 f hrte die Metrik relational cohesion ein welche die Anzahl der Beziehungen der Modellelemente untereinander ins Verh ltnis zur Gesamtzahl der
27. Ein Paket p h ngt von einem Paket q genau dann ab wenn es eine Klasse oder ein Interface c aus p gibt das von einer Klasse oder einem Interface d aus q abh ngt depends_on p q Ic deCuUlI c d A contains p c A contains q d A depends_on c d 5 4 Erweiterungen 53 5 4 2 Erweiterte Relationen Bisher wurden die Relationen associates has und uses definiert ohne Vererbung zu berticksichtigen Faktisch ist es aber so dass nicht nur Eigenschaften sondern auch Beziehungen vererbt werden Daher ist es sinnvoll weitere Relationen einzuf hren die auch vererbte Beziehungen umfassen Zun chst wird eine Relation extends ben tigt welche die transitive H lle von extends darstellt extends x y amp extends x y v Ize CUI extends x z a extends z y Nun k nnen die erw hnten erweiterten Relationen definiert werden die auch geerbte Beziehungen ber cksichtigen Die Definition wird hier am Beispiel von uses gezeigt associates depends_on und has sind analog definiert Man beachte dass es sich hier nicht um die transitive H lle handelt weil extends verwendet wird uses x y amp uses x y v Ize CL extends x z A uses z y Zum Schluss wird noch die erweiterte Version contains eingef hrt welche die transi tive H lle von contains ist contains x y lt contains x y v Ize C contains x z A contains z y Wegen der hierarchischen Strukturierung gilt contains S x f r alle Elemente x von PUCUI
28. Gestaltung oder Formgebung eines Gegenstands bei Soft ware entspricht das vor allem der Gestaltung der Benutzungsoberfl che user inter face design Diese T tigkeit ist Teil der Spezifikationsphase Winograd et al 1996 besch ftigen sich mit dieser Art des Entwurfs Hingegen versteht man bei der Software Entwicklung unter Entwurf vornehmlich die Phase in der aus der Problemstruktur die in der Anforderungsspezifikation beschrie ben ist eine L sungsstruktur abgeleitet wird Die T tigkeiten Spezifikation und Ent wurf lassen wie folgt voneinander abgrenzen Der Spezifikation liegt die Frage Was 24 4 Objektorientierter Entwurf soll das System leisten zugrunde w hrend der Entwurf die Frage Wie soll das Sys tem das tun was es leisten soll beantwortet Der IEEE Standard 610 12 1990 definiert den Begriff Entwurf wie folgt Definition 4 1 design Std TEEE 610 12 1990 1 The process of defining the architecture components interfaces and other characteristics of a system or component 2 The result of the process in 1 Die Definition weist auf die doppelte Belegung des Begriffs Entwurf hin Auch das Ergebnis der Entwurfsphase wird als Entwurf bezeichnet In der Regel handelt es sich dabei um ein Dokument die Entwurfsbeschreibung Dazu lautet die Definition des IEEE Standard 610 12 1990 Definition 4 2 design description IEEE Std 610 12 1990 A document that describes the design of a system or compo
29. Marchesi M OOA Metrics for the Unified Modeling Language Pro ceedings of the 2nd Euromicro Conference on Software Maintenance and Reengineer ing CSMR 98 Palazzo degli Affari Italy 1998 67 73 Martin 1995 Martin R Designing Object Oriented C Applications Using the Booch Method Prentice Hall Englewood Cliffs NJ 1995 Martin 1996a Martin R The Open Closed Principle C Report 8 1 1996 Martin 1996b Martin R The Liskov Substitution Principle C Report 8 3 1996 Martin 1996c Martin R The Dependency Inversion Principle C Report 86 1996 Martin 1996d Martin R The Interface Segregation Principle C Report 8 8 1996 Martin 1996e Martin R Granularity C Report 8 11 1996 Martin et al 1998 Martin R Riehle D Buschmann F Hrsg 1998 Pattern Lan guages of Program Design 3 Addison Wesley Reading MA Mattsson et al 1999 Mattsson M Bosch J Fayad M Framework Integration Problems Causes Solutions Communications of the ACM 42 10 81 87 1999 Mayrand et al 1996 Mayrand J Guay F Merlo E Inheritance Graph Assessment Using Metrics Proceedings of the 3rd International Software Metrics Symposium Ber lin 1996 IEEE Computer Society Press Los Alamitos CA 1996 54 63 McBreen 2000 McBreen P OO Design Inspection Checklist http www mcbreen ab ca papers QAOODesign html Version vom 25 04 2000 McBreen 2001 McBreen P Softwar
30. Ph D Thesis Uni versity of Nottingham Nottingham 1997 Gibbon Higgins 1996 Gibbon C Higgins C Teaching Object Oriented Design with Heuristics ACM SIGPLAN Notices 31 7 1996 12 16 Gilb 1988 Gilb T Principles of Software Engineering Management Addison Wesley Wokingham 1988 Gilmore 1974 Gilmore H Product Conformance Cost Quality Progress June 1974 Gillibrand Liu 1998 Gillibrand D Liu K Quality Metrics for Object Oriented Design Journal of Object Oriented Programming 10 8 1998 56 59 Gillies 1992 Gillies A Software Quality Theory and Management Chapman amp Hall London 1992 Glass 1998 Glass R Defining Quality Intuitively IEEE Software 15 3 1998 103 107 Glass 1999 Glass R On Design IEEE Software 16 2 1999 103 104 Gosling et al 1998 Gosling J Joy B Steele G The Java Language Specification Second Edition Addison Wesley Reading MA 1998 Grady 1997 Grady R Successful Software Process Improvement Prentice Hall Upper Saddle River NJ 1997 Grotehen Dittrich 1997 Grotehen T Dittrich K The MeTHOOD Approach Mea sures Transformation Rules and Heuristics for Object Oriented Design Technical Report ifi 97 09 Universit t Z rich 1997 177 Gursaran Roy 2002 Gursaran Roy G On the Applicability of Weyuker Property 9 to Object Oriented Structural Inheritance Complexity Metrics IEEE Transactions on Software Enginee
31. Schachtelungshierarchie der Pakete Die reine Anzahl an Bestandteilen der Hierar chien wird bei der Knappheit betrachtet die Verkn pfung der Bestandteile unterein ander bei der Entkopplung Als weitere Hierarchie k nnte noch die Aggregationsstruktur betrachtet werden Genero et al 2000 schlagen entsprechende Metriken vor Da es aber noch keine prak tischen Erfahrungen mit diesen Metriken gibt werden sie hier nicht ber cksichtigt Klasse Interface Vererbung Zur Strukturiertheit tragen bersichtliche Baumstrukturen bei der Vererbung bei F r Klassen kann die Tiefe in der Vererbungshierarchie nach Chidamber und Kemerer 1994 die L nge des l ngsten Pfads zur Wurzel der Hierarchie bestimmt werden Je gr er die Messwerte werden desto schlechter wird die Strukturiertheit Die Definition von DITC wie auch nachher von DNHP ist rekursiv weil sie sich auf grund der rekursiven Struktur der Hierarchie so am leichtesten ausdr cken l sst DITC depth of inheritance tree of a class DITC c 0 f r Wurzelklassen d h Klassen ohne Oberklasse NEEC c 0 sonst DITC c 1 max ge CUI extends c d DITC d 1 Der Zusammenhang zwischen DITC und der Strukturiertheit ist eigentlich intuitiv klar Empirische Untersuchungen kamen interessanterweise aber zu unterschiedlichen Resultaten So ergab sich in einer Untersuchung dass ein System mit Vererbung leichter zu warten ist als ein funktional gleiches ohne Vererbung Cartwright
32. The Software Maintenance Challenge Wiley New York 1988 Arthur 1993 Arthur L Improving Software Quality An Insider s Guide to TQM Wiley New York 1993 Balzert 1985a Balzert H Allgemeine Prinzipien des Software Engineering Angewandte Informatik 1 1985 1 8 Balzert 1985b Balzert H Phasenspezifische Prinzipien des Software Engineering Angewandte Informatik 3 1985 101 110 Balzert 1998 Balzert H Software Management Software Qualitatssicherung Unternehmensmodellierung Lehrbuch der Softwaretechnik Bd 2 Spektrum Heidel berg 1998 170 Literatur Balzert 1999 Balzert H Lehrbuch der Objektmodellierung Spektrum Heidelberg 1999 Bansiya Davis 1997 Bansiya J Davis C Automated Metrics for Object Oriented Development Using QMOOD for Object Oriented Metrics Dr Dobb s Journal December 1997 42 48 Bansiya Davis 2002 Bansiya J Davis C A Hierarchical Model for Object Oriented Design Quality Assessment IEEE Transactions on Software Engineering 28 1 2002 4 17 Bansiya et al 1999 Bansiya J Etzkorn L Davis C Li W A Class Cohesion Metric for Object Oriented Designs Journal of Object Oriented Programming 11 8 January 1999 47 52 Basili Rombach 1988 Basili V Rombach H The TAME Project Towards Improvement Oriented Software Environments IEEE Transactions on Software Engi neering 14 6 1988 758 773 Bass et al 1998 Bass L Clements
33. Verbindung bei der die Anzahl von Umsteigehaltestellen verglichen mit anderen Verbindungen zwischen Start und Zielhaltestelle am geringsten ist Gibt es mehrere M glichkeiten so wird die Verbindung gew hlt die die fr hestm gliche Ankunftszeit verspricht Der Start zeitpunkt darf in keinem Fall mehr als 60 Minuten nach dem fr hestm glichen Start zeitpunkt liegen Verbindung mit fr hestm glicher Ankunftszeit Eine Verbindung die zum fr hes tm glichen Zeitpunkt Ankunftszeit an der Zielhaltestelle ankommt und fr hestens zum gegebenen Startzeitpunkt startet Verbindung mit k rzester Fahrtzeit Eine Verbindung die die k rzeste Zeitspanne zwischen Abfahrtszeit an der Start und Ankunftszeit an der Zielhaltestelle erm g licht Der Startzeitpunkt darf dabei nicht mehr als eine Stunde vom eingegebenen fr hestm glichen Startzeitpunkt entfernt sein Gibt es in dieser Zeit keine Verbin dung so wird die Verbindung mit der fr hestm glichen Ankunftszeit gew hlt Verkehrsbetrieb Ein Verkehrsbetrieb ist eine Firma die Personentransporte organi siert und verkauft Zeitpunkt Eine Uhrzeit unter Angabe von Minuten und Stunden an einem beliebi gen Tag zwischen 00 00 Uhr und 23 59 Uhr Alle Tage werden gleich behandelt eine Unterscheidung zwischen Zeitpunkten an verschiedenen Tagen wird im Programm nicht vorgenommen Zielhaltestelle Die Zielhaltestelle ist eine spezielle Haltestelle an der der Fahrgast seine Fahrt beenden m
34. Wird die Komponente sp ter auf die vorgesehene Weise wiederverwendet hat sich die Investition gelohnt wenn nicht war sie unn ti ger Aufwand Allgemeinheit wirkt sich in der Regel negativ auf die Knappheit aus weil zur Realisierung mehr Entwurfsbestandteile ben tigt werden 8 6 Brauchbarkeit Definition Dieser Faktor umfasst Kriterien die sich auf die Brauchbarkeit des Entwurfs als Basis einer Realisierung der Anforderungen beziehen Ein Entwurf ist brauchbar wenn er eine tats chliche L sung f r das Problem darstellt d h die Anforderungen wieder spiegelt und realisierbar ist Diskussion F r die Brauchbarkeit sind Korrektheit des Entwurfs bez glich der Spezifikation und Realisierbarkeit wichtig vgl Abbildung 8 3 Brauchbarkeit Korrektheit Realisierbarkeit Abbildung 8 3 Kriterien des Faktors Brauchbarkeit 8 6 1 Korrektheit Looking honestly at the situation we are never looking for the best program seldom looking for a good one but always looking for one that meets the requirements Weinberg 1971 S 17 A good design is a design that conforms to specifications Martin 1995 S 189 Definition Ein Entwurf ist korrekt wenn er alle funktionalen Anforderungen erf llt Er muss eine vollst ndige L sung des Problems beschreiben Forderung nach Funktionsvoll st ndigkeit aber nicht mehr Die umgesetzte Funktionalit t muss der Spezifikation gerecht werden Forderung nach Funktionskorrektheit 8 6
35. bare Daher ist es schwierig den Suchraum wirksam einzugrenzen e Teilaspekte des Problems k nnen nicht unabh ngig voneinander gel st werden Die L sung f r einen Teilaspekt des Problems kann neue Probleme in anderen Teil aspekten verursachen oder deren L sung unm glich machen Beim Entwurf handelt es sich um ein Problem bei dem sowohl dialektische Barrieren als auch Interpolations und Synthesebarrieren vorliegen Der Entwurf geh rt also in die schlimmste Problemklasse Das Operatoreninventar ist hochgradig offen es sind also fast immer Synthesebarrieren vorhanden Selbst wenn irgendwann klar ist welche Operatoren zu verwenden sind ist ihre konkrete Verwendung immer noch ein Interpolationsproblem Welche Ans tze ein Entwerfer verfolgt h ngt so von seiner Intuition seinem Wissen und seiner Erfahrung ab Dabei kommen auch Gewohnhei ten und Denkbarrieren zum Tragen Ein Ansatz um das Syntheseproblem in ein Interpolationsproblem zu berf hren ist es ein m glichst gro es Operatoreninventar von Mustern Architekturmuster Entwurfsmuster etc anzulegen Die dialektische Barriere entsteht dadurch dass die Spezifikation zwar die Kriterien f r den Zielzustand vorgibt es aber immer noch beliebig viele geeignete Zielzust nde gibt Es gibt also eine gro e Anzahl von Wahlm glichkeiten die der Entwerfer beim Entwickeln einer L sung zu einer gegebenen Menge von Anforderungen hat Boehm 1976 Der Entwerfer ist daher gezwung
36. beschreibt die Grund idee von Rahmenwerken und die grunds tzliche Realisierung von hot spots anhand so genannter Metamuster metapatterns Fayad et al 1999 legen die Grundlagen f r objektorientierte Rahmenwerke ausf hrlich dar Ein bekanntes Beispiel f r ein Rahmenwerk ist ET Weinand et al 1989 Weinand Gamma 1994 ein in C implementiertes Rahmenwerk f r dokumentenzentrierte Anwendungen mit einer graphischen Benutzungsoberfl che Viele der Entwurfsmus ter von Gamma et al 1995 entstammen der Arbeit an ET Rahmenwerke und Ent wurfsmuster sind ungef hr zeitgleich mit der zunehmenden Verbreitung der objekt orientierten Entwicklung entstanden Sie sind daher vor allem f r diesen Ansatz entwickelt worden Grunds tzlich sind sie aber nicht auf die Objektorientierung beschr nkt Der Einsatz von Architekturstilen Rahmenwerken und Entwurfsmustern w hrend des Entwurfs kann den Aufwand der Erstellung reduzieren und gleichzeitig die Qua lit t verbessern da erprobte L sungen wiederverwendet werden Allerdings muss der Entwerfer die Muster bereits kennen und wissen wann ein Einsatz angebracht ist und wann nicht Der erh hten Produktivit t und Qualit t steht also ein betr chtlicher Initialaufwand gegen ber 4 4 Dokumentation des Entwurfs Die Entwurfsdokumentation spielt in Implementierung und Wartung eine bedeu tende Rolle Daher sind Vollst ndigkeit Konsistenz und Verst ndlichkeit wichtig F r die Dokumentation
37. ckgegeben wird doch das scheint eher willk rlich genauso gut k nnte das Minimum oder der Durchschnitt zur ckgegeben werden Eine Spezialisierungsbezie hung zwischen Trips und GenericTrip liegt jedenfalls nicht vor brigens kann auch dieses Problem durch eine entsprechende Frage im Fragebogen zur Entkopplung vgl Abschnitt B 3 aufgedeckt werden In der Implementierung zeigt sich dass GenericTrip nie als Typ z B einer Variablen oder eines Parameters verwendet wird Der durch die Vererbung erm glichte Poly 144 10 Ein spezifisches Qualit tsmodell morphismus wird also gar nicht genutzt Da von der Klasse auch keine Implementie rung vererbt wird ist sie also g nzlich berfl ssig Entkopplung durch Interfaces Ein Beispiel f r die Entkopplung durch Interfaces siehe auch Fowler 2001b findet sich im Entwurf von Gruppe 8 Dort gibt es zur zentralen Steuerung der Programmlo gik eine Klasse ProcessHandler die einige untergeordnete Kontrollklassen assoziiert z B DataManager Diese Klassen ben tigen aber Zugriff auf die bergeordnete Kon trollklasse wodurch ein unerw nschter Abh ngigkeitszyklus entsteht Dieser l sst sich aufbrechen indem ein Interface ProcessManager eingef hrt wird das von Pro cessHandler implementiert wird Die untergeordneten Kontrollklassen assoziieren statt ProcessHandler das Interface ProcessManager vgl Abbildung 10 5 lt lt nterface gt gt ProcessManager PC getDataManager
38. die strukturelle Organisation von Objekten die Nachrichten austauschen darstellt Kollaborations und Sequenzdiagramme sind inhaltlich quivalent und k nnen ineinander berf hrt werden betonen aber unterschiedliche Aspekte 6 Zustandsdiagramm state diagram zeigt einen endlichen Automaten state machine der das Verhalten einer Klasse oder eines Interfaces modelliert Der Automat reagiert auf Ereignisse durch entsprechende Zustands berg nge 7 Aktivit tsdiagramm activity diagram zeigt den Kontrollfluss zwischen Aktivit ten im System 8 Komponentendiagramm component diagram zeigt die Gliederung und die Beziehungen von Komponenten der Implementierung z B ausf hrbare Pro gramme Bibliotheken und Dateien 9 Verteilungsdiagramm deployment diagram zeigt die Verteilung von Komponen ten auf Rechnerknoten zur Laufzeit Jeder Diagrammtyp liefert eine spezielle Sicht auf das modellierte System die f r bestimmte Gesichtspunkte besonders gut geeignet ist Jede Sicht f r sich allein gen gt nicht um das System vollst ndig zu beschreiben Durch die Kombination aller Sich ten l sst sich das System jedoch ausreichend festlegen Man braucht um so mehr ver schiedene Sichten je komplexer das System ist Budgen 1994 Graphische Notationen k nnen in der Regel leichter erfasst werden als textuelle sind daf r aber h ufig nicht so exakt Das Layout spielt bei graphischen Notationen wie UML f r die Verst ndlichkeit ei
39. schaubarer zu gestalten siehe dazu auch Abschnitt 5 4 4 e Ebenfalls aus Gr nden der Uberschaubarkeit wird die M glichkeit in Klassen wei tere Klassen oder Interfaces einzuschachteln nicht ber cksichtigt Diese Form der Schachtelung sollte ohnehin nur selten verwendet werden da sie sich negativ auf die Verst ndlichkeit auswirkt Es gibt allerdings F lle wo sie sinnvoll ist Beispiels weise kann eine Iterator Klasse zur zugeh rigen Container Klasse lokal deklariert und damit der enge Zusammenhang deutlich gemacht werden e Methoden Implementierungen von Operationen und damit auch Redefinitionen von Methoden geh ren zum Feinentwurf und werden daher ausgeblendet Die durch Methodenaufrufe bedingte Benutzung von Klassen kann dennoch ber ck sichtigt werden Wenn eine Aufrufbeziehung einer Methode einer Klasse zu einer Operation einer anderen Klasse bestehen wird kann diese Beziehung als Benut zungsbeziehung dargestellt werden e Konstruktoren d h Operationen mit Stereotyp create OMG 2000a oder constructor Rumbaugh et al 1998 werden nicht ber cksichtigt da sie im Gegensatz zu den normalen Operationen nicht vererbt werden Die Konstruktoren tragen in der Regel wenig zur Komplexit t einer Klasse bei Daher ist es einfacher sie bei der Bewertung auszublenden als ihren Sonderstatus im Modell zu ber ck sichtigen e Die Abstraktheit von Operationen wird ignoriert Die Abstraktheit einer Operation ist lediglich ei
40. sehr schlecht 1 2 3 4 5 6 7 8 9 sehr gut 9 3 4 Auswertung Im Gegensatz zu den objektiven Metriken oder den Frageb gen machen die subjekti ven Metriken eine direkte Aussage zur Qualit t m ssen also nicht mehr auswertet werden Allerdings werden sie f r Bewertungsvorschl ge f r subjektive Metriken der bergeordneten Ebenen Paket und System der Faktoren und der Gesamtqualit t verwendet F r die Ebenen Paket bzw System liegen subjektive Metriken f r das jeweilige Krite rium der untergeordneten Ebene Klasse Interface bzw Paket vor Aus diesen kann ein Bewertungsvorschlag gewonnen werden indem ein auf eine Nachkommastelle gerundeter Durchschnitt der subjektiven Metriken der untergeordneten Ebene berechnet wird Beispielsweise kann ein Vorschlag f r SCCP p gewonnen werden indem der gerundete Durchschnitt von SCCC f r alle Klassen im Paket p gebildet wird Der Bewertungsvorschlag f r die subjektive Metrik eines Faktors wird aus den sub jektiven Metriken der Kriterien auf der gleichen Ebene gewonnen Die Kriterien wer den dazu mit Gewichten versehen um einen gewichteten Durchschnitt berechnen zu k nnen Beispielsweise kann f r die subjektive Metrik SMAC k f r den Faktor Wart barkeit einer Klasse k ein Bewertungsvorschlag aus den Metriken SCCC k SSTC k etc gebildet werden Die Gewichte werden analog zu denen der objektiven Metriken mit dem K rzel des Faktors bezeichnet und mit der Metrik indiziert z B MAs
41. so lange die ben tigten Informationen noch nicht vorliegen und auf Grund vorliegender Informationen zuk nftige Entwicklungen z B zu erwartende Erweiterungen vorwegzunehmen Leider haben aber nur wenige Entwickler das Potential gro artige Entwerfer zu wer den Brooks 1987 S 18 meint We can get good designs by following good prac tices also ist das wohl der Weg den gew hnliche Entwerfer einschlagen sollten In der Ausbildung sind die guten Praktiken zu lehren z B in Form von Entwurfsregeln Zus tzlich sollte vermittelt werden welche bew hrten L sungen es gibt und unter welchen Umst nden sie funktionieren z B in Form der bereits erw hnten Muster Aber auch L sungen die nicht funktionieren sollten dokumentiert und weitergege ben werden Petroski 1992 1994 z B in Form von Anti Mustern antipatterns Koe nig 1995 Brown et al 1998 Das Wissen ber m gliche L sungsans tze sollte einge bettet sein in einen Rahmen der angibt welche Eigenschaften ein guter Entwurf hat Dieser Rahmen der nichts anderes als ein Qualit tsmodell ist kann dann bei der Ent scheidung herangezogen werden wann eine der bew hrten L sungen angebracht ist und wann nicht Pancake 1995 S 42 schreibt Ihe difficulty in both teaching and learning OT object technology is that the quality of an OO design is difficult to evaluate Das Problem liegt also in der Bewertung Gerade der Bewertung nimmt sich diese Arbeit aber an
42. t insbesondere durch Entwurfs muster ist oft teuer und sollte daher nur eingebaut werden wenn sie ben tigt wird H ufig muss dazu auch der vorhandene Entwurf ge ndert werden Beispielsweise kann das State Muster auf Entwurf A nicht ohne vorhergehende nderungen ange wendet werden 78 7 Entwurfsqualitat Eine Entwurfsbewertung sollte nicht nur von den vorhandenen Strukturen und den aktuellen Anforderungen abh ngen sondern auch den Kontext einbeziehen Dieser besteht unter anderem aus e den impliziten Anforderungen und Rahmenbedingungen z B die Wahrschein lichkeit dass sich bestimmte Anforderungen ndern e bei den Entwicklern vorhandenes Wissen um Entwurfs und Implementierungs techniken e vorhandenen Software Bausteinen Komponenten e in der Entwicklung eingesetzten Werkzeugen und e wirtschaftlichen berlegungen z B Time to Market Besch ftigung von Mitarbei tern Schulungskosten Jeder am Entwurf Beteiligte oder von ihm unmittelbar Betroffene Entwerfer Imple mentierer Manager etc hat andere Anspr che an den Entwurf Nur mittelbar vom Entwurf Betroffene Kunde Anwender haben zwar keine Anspr che direkt an den Entwurf aber an die Implementierung die ja vom Entwurf ma geblich gepr gt wird So ist es nur nat rlich dass es unterschiedliche Auffassungen ber Entwurfsqualit t gibt Dies wird im folgenden Abschnitt vertieft 7 2 Perspektiven der Entwurfsqualit t Entwurfsqualit t ist durch
43. zwischen Klassen e das Vermeiden von Code Duplikation durch entsprechenden Entwurf z B Tem plate Methods Gamma et al 1995 108 8 Das allgemeine Qualit tsmodell Diskussion Knappheit verbessert die Verst ndlichkeit eines Entwurfs Au erdem ist er wegen des geringeren Umfangs leichter zu dokumentieren und schneller zu implementieren Schlie lich entsteht auch weniger Code der getestet und gewartet werden muss Durch einen geringeren Umfang nimmt auch der Aufwand f r Pr fung und berar beitung des Entwurfs ab Allerdings f hrt sehr hohe Knappheit z B nur sehr wenige daf r umfangreiche Klassen zu einer geringeren Verst ndlichkeit da dann Dinge zusammengefasst werden die eigentlich nichts miteinander zu tun haben f hrt zu einem geringen Zusammenhalt Im Extremfall besteht das System aus einer einzigen Klasse System mit einer einzigen Methode run in der s mtliche Funktionali t t implementiert ist f r die Wartung wohl der schlimmste Fall Die Knappheit steht in Konkurrenz zu Entkopplung und Zusammenhalt Beispiels weise kann man zur Entkopplung zweier Komponenten eine weitere Komponente einf hren wie das beim Mediator vgl Gamma et al 1995 der Fall ist Damit verrin gert sich zwar die Kopplung aber die Anzahl der Klassen steigt In der anderen Rich tung kann man zwar die Zahl der Klassen verringern indem man einige miteinander verschmilzt man erh lt dadurch aber meistens Klassen mit sehr geringem Z
44. 1 pr sentiert Inner halb eines Kriteriums sind sie nach Ebenen sortiert wobei mit der untersten Ebene Klassen Interfaces begonnen wird Wenn f r eine Ebene oder ein Kriterium keine objektive Metrik verf gbar ist wird eine Begr ndung daf r angegeben Im Anschluss an die Pr sentation der Metriken wird gezeigt wie die Metriken theoretisch validiert werden k nnen siehe Abschnitt A 9 A 1 Knappheit Knappheit bedeutet eine m glichst geringe Zahl an Modellelementen Daher z hlt die Quantifizierung zun chst diese Modellelemente Briand und W st 1999 haben fest gestellt dass solche einfachen Gr enmetriken die besten Indikatoren f r den sp te ren Implementierungsaufwand des Entwurfs darstellen Je niedriger die Werte der Z hlmetriken sind um so besser ist die Knappheit negative Korrelation Klasse Interface Metriken fur Eigenschaften Bei den Klassen zahlt man Attribute und Operationen Da geerbte Eigenschaften in der Klasse vorhanden sind und damit ihre Gr e mitbe stimmen z hlen sie mit Eine solche Vorgehensweise wird auch von den Untersu chungen von Beyer et al 2000 gest tzt denen zufolge Gr en Kopplungs und Zusammenhaltsmetriken bei der Ber cksichtigung geerbter Eigenschaften besser interpretierbare Werte liefern NAC number of attributes of a class NAC c ae A has c a Bei Interfaces ist gem der Definition im UML Metamodell NAC immer 0 weil Interfaces keine Attribute haben d
45. 1999 geben einige Hinweise f r effektive Entwurfsinspektionen Bewertung Die Bewertung ist hilfreich um den Entwurf mit m glichen Alternativen zu vergleichen und die beste M glichkeit auszuw hlen Eine Schwachstellenanalyse auf der Grundlage der Bewertung kann m gliche Probleme des Entwurfs aufzeigen Dann k nnen Refaktorisierungen und Transformationsmuster eingesetzt werden um diese Schwachstellen zu bereinigen Ans tze zur Entwurfsbewertung werden in Abschnitt 7 6 vorgestellt Prototyping Eine m gliche wenn auch in der Regel teurere Alternative zur Bewer tung ist das sofortige Ausprobieren durch eine Implementierung Diese Implementie rung kann prototypischen Charakter haben Coad Yourdon 1991 muss es aber nicht Beispielsweise wird bei der Vorgehensweise des extremen Programmierens Beck 1999a und 1999b empfohlen inkrementell zu entwerfen und jedes Entwurfs inkrement sofort zu implementieren Falls eine berarbeitung notwendig werden sollte soll auf Refaktorisierung Fowler et al 1999 zur ckgegriffen werden 76 Entwurfsbewertung By their very nature software products are not readily evaluated There are no visible charac teristics to give any clue to the quality of the product and the behaviour of software systems is often complex and non continuous Dick Hunter 1994 98 7 Entwurfsqualitat Entwurfsbewertung der Schwerpunkt dieser Arbeit ist eine analytische Qualit tssi cherungsma nahme In diesem
46. Abschnitt werden einige Alternativen von Bosch 2000 beschrieben wie die Bewertung durchgef hrt werden kann 7 6 1 Bewertungsverfahren Anforderungen Der ISO IEC Guide 25 ISO IEC 1990 beschreibt die ideale Bewertung als e wiederholbar d h wenn dasselbe Produkt nach derselben Prozedur von derselben Stelle evaluiert wird kommt dasselbe heraus e reproduzierbar d h wenn dasselbe Produkt nach derselben Prozedur von einer anderen Stelle evaluiert wird kommt dasselbe heraus e unparteiisch d h die Bewertung ist frei von Vorurteilen und e objektiv d h die Bewertung kommt m glichst ohne subjektive Urteile aus Ans tze Bosch 2000 S 34ff unterscheidet vier Ans tze zur Entwurfsbewertung 1 auf der Basis von Szenarien 2 durch Simulation 3 durch mathematische Modellierung und 4 auf der Basis bisheriger Erfahrungen Die ersten beiden bewerten durch Ausf hrung der dritte durch statische Analyse und der vierte durch Inspektion Diese Ans tze werden im Folgenden vorgestellt Evaluation mit Szenarien In diesem Ansatz der schon von Bass et al 1998 propa giert wurde werden Entwurfseigenschaften mit Hilfe von Szenarien bewertet in denen der Entwurf sich bew hren muss Beispielsweise kann die nderbarkeit bewertet werden indem einige Szenarien f r wahrscheinliche nderungen an den Anforderungen erstellt werden und dann versucht wird die Anforderungs nderun gen im Entwurf umzusetzen Die nderbarkeit
47. Daher gibt es auch einige codebasierte Ans tze zur Entwurfsbewertung Erni 1996 Das Werkzeug dient zur Bewertung der Wartbarkeit von Rahmenwerken mit Hilfe von Metriken Es arbeitet mit Schwellenwerten um Ausrei er bei den Mess werten zu identifizieren wobei auch statistische Schwellenwerte m glich sind z B Mittelwert Standardabweichung Besonders an diesem Ansatz ist die M glichkeit durch einen Filter dort Fokus genannt die Bewertung auf bestimmte Ausschnitte des Entwurfs zu beschr nken Dies kann entweder durch manuelle Auswahl geschehen oder durch Festlegung bestimmter Eigenschaften welche die zu selektierenden Ele mente haben sollen z B abstrakte Klassen Eine weitere Besonderheit ist die Unter st tzung von Trendanalysen bei denen die Messwerte ber verschiedene Versionen des Rahmenwerks betrachtet werden k nnen 3 FAMIX ist ein Metamodell f r Modelle objektorientierte Systeme das im FAMOOS Projekt als Aus tauschstandard entwickelt wurde siehe http www iam unibe ch famoos FAMIX 11 1 Werkzeuge aus anderen Arbeiten 153 Gibbon 1997 Das Werkzeug TOAD erhebt Code Metriken zur Uberpriifung von Heuristiken Da das Werkzeug f r die Ausbildung objektorientierter Entwickler gedacht ist Gibbon Higgins 1996 werden aber nicht nur Verst e identifiziert son dern auch erkl rende Texte angeboten die beschreiben warum die Verst e proble matisch sind und wie die Verst e behoben werden k nnen
48. Die Automatisierbar keit von Reviews ist allerdings begrenzt da sich viele M ngel gar nicht oder nur unzureichend automatisch erkennen lassen 6 3 3 Good Enough Quality We don t believe in striving for the ideal software architecture Instead the goal should be to design a good architecture one in which when the system is implemented according to the architecture it meets its requirements and resource budgets This means that is must be possi ble to implement the system according to the architecture So an architecture that isn t explicit comprehensive consistent and understandable is not good enough Hofmeister et al 2000 S 7 Qualit tssicherung verursacht Kosten Diese Kosten sind idealerweise aber geringer als die Fehlerfolgekosten der Qualit tsm ngel die dank der Qualit tssicherung vor der Auslieferung verhindert oder behoben wurden z B Kosten f r Fehlersuche und Fehlerbehebung Um eine kosteneffektive Qualit tssicherung durchzuf hren m s sen Qualit tssicherungskosten und Fehlerfolgekosten gegeneinander abgewogen werden Ludewig 1994 um ein Kostenoptimum zu erreichen vgl Abbildung 6 7 Kosten i Gesamtkosten OS Kosten Fehlerfolgekosten gt Kostenoptimum OS Aufwand Abbildung 6 7 Kostenoptimum bei der Qualit tssicherung Die Kosten sind aber nicht der einzige limitierende Faktor f r die Qualit t Das magische Dreieck sieht die Qualit t in Konkurrenz zu Kosten und L
49. Die Heuristiken konzen trieren sich auf den Bereich der Wartbarkeit B r 1998 Das Werkzeug berpr ft die Einhaltung von Heuristiken im Code und zeigt Verst e auf Die Pr fung der Heuristiken wird durch Anfragen an eine Wis sensbasis in Prolog realisiert die aus dem Code gewonnene Entwurfsinformation ent h lt Das Werkzeug ist integriert in das Visualisierungswerkzeug GOOSE das vor allem f r das Reverse Engineering objektorientierter Programme gedacht ist GOOSE verf gt auch ber eine Komponente zur Erhebung und Visualisierung von Metriken K hler et al 1998 Das Metrikenwerkzeug Crocodile das in die Entwicklungsum gebung SNiFF integriert ist greift auf das Code Repository von SNiFF zu um darauf Metriken zu erheben Die Metriken k nnen mit Schwellenwerten versehen werden so dass das Werkzeug Modellelemente identifizieren kann die besonders h ufig oder besonders schwerwiegend unerw nschte Messwerte aufweisen Auf diese Weise soll der Umfang an Klassen o eingeschr nkt werden die anschlie end einem Code Review unterzogen werden Together Inzwischen enthalten auch kommerzielle UML Werkzeuge automatisierte Hilfsmittel zur Qualit tssicherung Ein Beispiel ist Together bei dem es eine Funktion zur Durchf hrung von Audits gibt Dabei kann der Benutzer vordefinierte Regeln automatisch pr fen lassen Au erdem kann er vordefinierte Metriken ausw hlen optional Schwellenwerte angeben und sich dann die Metri
50. Die Pragmatik bestimmt unter anderem welche Attribute des Originals wegge lassen werden k nnen ohne die angestrebte Nutzung des Modells an Stelle des Origi nals zu gef hrden H ufig soll das Modell n mlich dazu dienen Erkenntnisse oder Fertigkeiten mittels des Modells zu gewinnen um diese dann auf das Original zu bertragen z B Simulationsmodelle Au erdem ist das Modell f r einen bestimmten Nutzerkreis gedacht z B dient der Entwurf f r ein Software System vor allem den Entwicklern und unter Umst nden auch nur f r einen bestimmten Zeitraum g ltig z B das Organigramm eines Unter nehmens 2 2 Metriken 9 2 1 2 Beispiele any program is a model of a model within a theory of a model of an abstraction of some portion of the real world or some universe of discourse Lehman 1980 S 1061 Modellbildung ist eine universelle Technik zum besseren Verst ndnis von realen oder gedachten Objekten oder Prozessen weshalb man quasi berall auf Modelle trifft In dieser Arbeit finden sich unter anderem die folgenden Beispiele f r Modelle e Metrik Modell von einen Messgegenstand z B von Software e Spezifikation Modell f r ein Programm e Entwurf Modell f r ein Programm e Code Modell f r ein Programm e UML Modell Modell f r ein Programm e UML Metamodell Modell f r UML Modelle e Qualit tsmodell Modell f r ein Programm o A das sich aus Qualit tsattributen zusammensetzt Die pr skrip
51. Entwicklung spielt der Entwurf eine zentrale Rolle Er beeinflusst die nachfolgenden Phasen Implementierung und Wartung nachhaltig Weil Implementie rung und Wartung zusammengenommen etwa zwei Drittel des Gesamtaufwands ausmachen ist es sinnvoll beim Entwurf eine hohe Qualit t anzustreben Da es schwierig ist auf Anhieb einen guten Entwurf zu erstellen ist eine Qualit tssicherung in Form einer Entwurfsbewertung n tig Die Bewertung dient dazu die Qualit t fest zustellen und Schwachstellen im Entwurf aufzudecken sie kann aber auch zum Ver gleich von Entwurfsalternativen verwendet werden Diese Arbeit besch ftigt sich mit der Bewertung des objektorientierten Entwurfs Die Basis f r die Entwurfsbewertung ist ein Qualit tsmodell Weil die Qualit tsanforde rungen von Projekt zu Projekt unterschiedlich sind sollte das Qualit tsmodell an den vorhandenen Kontext angepasst sein Daher wird ein allgemeines Qualit tsmodell namens Quality Model for Object Oriented Design QOOD eingef hrt aus dem sich spezifische Qualit tsmodelle ableiten lassen die an die konkreten Qualit tsanforde rungen angepasst sind Um die Kosten f r die Bewertung zu reduzieren ist eine weitgehende Automatisie rung n tzlich Dies macht aber eine formale Repr sentation des Entwurfs erforder lich Da die Unified Modeling Language UML der Standard f r die Notation objekt orientierter Entw rfe darstellt und ausreichend formal ist wurde ein Referenzmodell na
52. Erf llungsgrad in der Regel positiv f r die Qualit t ist Daher wird z B statt des gebr uchlichen Begriffs Kopplung der Begriff Entkopplung verwendet da geringe Kopplung also hohe Ent kopplung angestrebt wird 8 2 3 Metriken Bei den Metriken werden sowohl objektive als auch subjektive Metriken eingesetzt Die objektiven Metriken sind automatisch bestimmbar und lassen sich auf der Basis von ODEM formal definieren Leider k nnen mit den objektiven Metriken nicht alle Aspekte der Kriterien abgedeckt werden Daher werden zus tzlich subjektive Metri ken eingesetzt die von einem Bewerter nach seiner pers nlichen Einsch tzung bestimmt werden Dem Bewerter werden zus tzlich Frageb gen zur Verf gung gestellt die ihn bei der Meinungsbildung unterst tzen Dieses Kapitel besch ftigt sich nur mit den Faktoren und Kriterien des Modells Die Metriken und die Quantifizierung des Modells auf der Basis der Metriken sowie der Ablauf der Bewertung im Detail werden im folgenden Kapitel behandelt 8 3 Wartbarkeit Definition Die Wartbarkeit ist hoch wenn der Entwurf leicht korrigiert berarbeitet und erwei tert werden kann Die oft separat verwendeten Begriffe Anderbarkeit und Erweiter barkeit werden hier unter Wartbarkeit subsumiert Unter Wartung wird hier alles verstanden was mit nderungen des Produkts nach der ersten Version zu tun hat sei es nun in einem neuen Iterationszyklus w hrend der Entwicklung oder nach der Auslieferu
53. G deli sierung ausgeschlossen werden d P Q P Qa m P m Q Axiom W4 Es muss funktional quivalente Programme geben die unterschiedliche Komplexit t besitzen Damit soll sichergestellt werden dass die Komplexit t der Implementierung und nicht die der implementierten Funktion gemessen wird 4P Q P Qam P m Q Eist die funktionale Aquivalenz Axiom W5 Werden zwei Programme kombiniert muss die Komplexit t des Ganzen mindestens so gro sein wie die seiner Teile V P Q m P lt m P Q a m Q lt m P Q kombiniert zwei Programme Axiom W6 Wird ein Programm mit zwei verschiedenen Programmen gleicher Kom plexit t kombiniert k nnen die Komplexit ten der Resultate unterschiedlich sein Das Axiom soll sicherstellen dass es mindestens einen solchen Fall je Kombinations reihenfolge gibt a 3 P Q R m P m Q A m P R m Q R b 3 P Q R m P m Q a m R P m R Q Axiom W7 Werden die Anweisungen eines Programms permutiert kann sich die Komplexit t ndern sie muss aber nicht Daher wird gefordert dass es eine Permu tation eines Programms geben muss die eine andere Komplexit t hat als das Pro gramm selbst Damit wird aber von allen Komplexit tsmetriken verlangt dass sie 200 A Metriken fur QOOD sich mit den Details der Programme besch ftigen Die meisten blichen und sinnvol len Metriken z B McCabes zyklomatische Komplexit t sind aber nicht sensitiv gegen ber einer Permutation v
54. IS EE 204 Be STU TIO EE 205 Bide Entkopplune ui 206 PA ZisanmienNalt ee E Ee 209 BS APNG TCHR era cas ch oho ee e 210 BiG Dokumentierune una 211 B Z Nerktolebarkeit nen ia e ee 213 Be Warrbarkeit nun wenn een enden 214 C Dokumente zum Softwarepraktikum usssussussssnssussssnssnssssnnsnnsnsnnssnsnsnnssnsnnsansnnnnnen 215 El Aufgabenstellung EE 215 C2 Anforderungen neh 220 G3 Begriftslexi EE 224 Inhaltsverzeichnis Kapitel 1 Einf hrung Design is one of the most elusive yet fascinating topics in the software field It is elusive because no matter how thoroughly academics try to shape it into a teachable testable fact based topic it just doesn t fit It is fascinating because design holds the key to the success of most software projects Glass 1999 S 104 Diese Arbeit besch ftigt sich mit der Frage wie die Qualit t eines objektorientierten Entwurfs bewertet werden kann 1 1 Motivation The consequences of design quality or lack thereof propagate throughout the software life cycle Card Glass 1990 S ix Der Entwurf ist eine der wichtigsten Phasen in der Software Entwicklung Obwohl nur 5 10 des Gesamtaufwands ber den Software Lebenszyklus in den Entwurf selbst gehen flie t der meiste Aufwand in vom Entwurf ma geblich beeinflusste Pha sen Implementierung 15 20 und Wartung ber 50 Ein schlechter Entwurf kann teure Folgen haben Bis zu 80 des Gesamtaufwands m ssen f r die B
55. Implementierung abgegeben wurden Daher werden hier nur die nach der Implemen tierung berarbeiteten Entw rfe betrachtet Da die Entwurfsdokumentation trotz der geforderten berarbeitung nicht immer auf dem neuesten Stand war wurde sie vor der Bewertung mit der Implementierung abgeglichen Um die Entw rfe besser vergleichbar zu machen wurden die folgenden Konventio nen zur Messung eingef hrt e Wiederverwendete Klassen hier ausschlie lich Klassen aus der Standardbibliothek von Java werden bei den Knappheitsmetriken nicht mitgez hlt Realisierungs Benutzungs und Vererbungsbeziehungen zu solchen Klassen werden ebenfalls nicht ber cksichtigt Das bedeutet auch dass von wiederverwendeten Klassen geerbte Attribute und Operationen nicht mitgez hlt werden Assoziationen mit solchen Klassen werden als Attribut gez hlt Die Redefinition einer von einer sol chen Klasse geerbten Methode wird als neue Operation gez hlt e Exception Klassen werden als Implementierungsdetail aufgefasst und nicht mitge z hlt Einige Entw rfe definieren viele eigene Exceptions andere verwenden nur die Exceptions der Standardbibliothek W rden die eigenen Exception Klassen mitgez hlt w rden sonst diejenigen bestraft die sich um verst ndlichere Excep tions bem hen weil z B die Knappheitsmetriken schlechtere Werte liefern e Debug Infrastruktur Klassen Operationen Attribute etc wird nicht ber cksich tigt weil sie nicht in allen Entw rfen
56. Metric for Object Oriented Design Informa tion and Software Technology 35 4 1993 232 240 Chidamber Kemerer 1991 Chidamber S Kemerer C Towards a Metrics Suite for Object Oriented Design Proceedings of OOPSLA 91 ACM SIGPLAN Notices 26 11 1991 197 211 Chidamber Kemerer 1994 Chidamber S Kemerer C A Metrics Suite for Object Oriented Design IEEE Transactions on Software Engineering 20 6 1994 476 493 Chidamber Kemerer 1995 Chidamber S Kemerer C Authors Reply to Com ments on A Metrics Suite for Object Oriented Design IEEE Transactions on Software Engineering 21 3 1995 265 Chidamber et al 1998 Chidamber S Darcy D Kemerer C Managerial Use of Metrics for Object Oriented Software An Exploratory Analysis IEEE Transactions on Software Engineering 24 8 1998 629 639 Churcher Shepperd 1995a Churcher N Shepperd M Towards a Conceptual Framework for Object Oriented Software Metrics ACM SIGSOFT Software Engineer ing Notes 20 2 1995 69 76 Churcher Shepperd 1995b Churcher N Shepperd M Comments on A Metrics Suite for Object Oriented Design IEEE Transactions on Software Engineering 21 3 1995 263 265 Clements et al 2002 Clements P Kazman R Klein M Evaluating Software Architectures Methods and Case Studies Addison Wesley Boston 2002 Coad Yourdon 1991 Coad P Yourdon E Object Oriented Design Prentice Hall Englewood Cli
57. Metriken fiir die Kriterien der Wartbarkeit ausgewahlt und auf der Basis von ODEM formal definiert Wie in der Literatur blich erh lt jede Metrik ein drei oder vierstelliges Akronym z B NAC Number of Attributes of a Class Manche Metriken lassen sich verfeinern indem nach einem bestimmten Aspekt klassifiziert wird Beispielweise kann die Metrik NAC verfeinert werden indem die Sichtbarkeitsbereiche public protected und private unterschieden werden Der Name einer Verfeinerung ergibt sich aus dem Namen der Ursprungsmetrik und einem Index der die Art der Verfeinerung bezeichnet Verfeine rungen sind teilweise kombinierbar so dass es auch mehrfach indizierte Metriken geben kann Beispielsweise lassen sich die Verfeinerungen nach Sichtbarkeitsbereich noch einmal verfeinern nach dem Definitionsort geerbt oder lokal In Tabelle 9 1 sind die ausgew hlten Metriken aufgelistet sie sind in Anhang A im Detail beschrieben In der Tabelle sind zu den Metriken die Ebene Klasse Paket oder System und das Kriterium angegeben f r das die Metrik verwendet wird Hinter dem Kriterium wird durch angezeigt dass die Metrik negativ mit dem Kriterium korreliert ist bedeutet positive Korrelation Ist eine Metrik z B NEDC f r meh rere Kriterien relevant wird das Kriterium zuerst genannt f r das die Metrik am wichtigsten ist Alle Metriken haben eine Absolutskala mit Ausnahme von RTTR das eine Rationalskala hat Es f llt auf dass nic
58. Modellelemente setzt vgl Abschnitt 5 5 2 Die Metrik misst also eine normierte paketinterne Kopplung Eigene Erfahrungen beim Einsatz dieser Metrik in Fallstudien haben allerdings ergeben dass die Metrik kein geeigneter Indikator f r den Zusammenhalt der Modellelemente innerhalb eines Pakets ist Trotz hoher Werte kann es sein dass das Paket in mehrere nur schwach verbundene Teile zerf llt Daher kann bei hohen Werten nicht auf hohen Zusammenhalt geschlossen werden sondern nur bei sehr geringen Werten auf gerin gen Zusammenhalt Aus diesem Grund wird die Metrik hier nicht verwendet Man ist also auf subjektive Metriken angewiesen System Vorschl ge f r systemweite Zusammenhaltsmetriken gibt es bisher nicht Au erdem ist unklar was Zusammenhalt auf Systemebene eigentlich bedeutet Um keine L cke im Verfahren entstehen zu lassen wird hier der systemweite Zusammenhalt als Gesamteindruck auf der Basis des Zusammenhalts der enthaltenen Pakete Klassen und Interfaces interpretiert Auch hier ist eine subjektive Metrik am sinnvollsten A 5 Einheitlichkeit Die Einheitlichkeit ist eine berwiegend semantische Eigenschaft weshalb auch hier auf subjektive Metriken zur ckgegriffen werden muss Je nach den Vorgaben aus den Namenskonventionen lassen sich gewisse Minimalanforderungen automatisch pr fen z B eine minimale Bezeichnerl nge oder Lesbarkeitskriterien die Buchstaben Ziffern Gemische wie X22Z1I verbieten Solche Pr fungen lie
59. NOC this Enth lt die Klasse nur die n tigen Operationen 0 nein gt 0 z B keine nicht mehr verwendeten oder f r die 1 ja Verantwortlichkeiten der Klasse nicht relevanten NOC this Enth lt die Klasse keine berfl ssigen Opera 0 nein gt 0 tionen 1 ja z B berladene Operationen oder andere Komfort Operationen NOC this Gibt es keine hnlichen Operationen in anderen 0 nein gt 0 Klassen Wird die Implementierung vermutlich 1 ja Aus keinen redundanten Code enthalten sage trifft zu NOC this Ben tigt jede Operationen alle ihre Parameter 0 nein a gt 0 1 ja NEEC F gt die Unterklasse neue Attribute oder Opera 0 nein ar Y this gt 0 tionen hinzu 1 ja thiseC Hat die abstrakte Klasse mindestens eine Unter 0 nein Ren v this isAbs klasse 1 ja tract thise Wird das Interface realisiert oder von anderen 0 nein FER Y Interfaces geerbt 1 ja Abbildung 9 5 Fragebogen f r Kriterium Knappheit Ebene Klasse Interface 9 4 4 Auswertung Bei den Frageb gen l sst sich aus den Antworten ein Bewertungsvorschlag generie ren Das Verfahren dazu hnelt dem zur Berechnung eines Bewertungsvorschlags aus objektiven Metriken Eine Normierung ist hier allerdings nicht erforderlich weil die Fragen so formuliert sind dass eine Antwort mit ja oder eine hohe Zustimmung positiv f r die Qualit t ist und weil der Wertebereich f r die Antwort bereits 0 1 ist Ausgewertet werde
60. ODEM Als Alternative zu den zus tzlichen Modellelementen wurde erwogen die formale Definition von Metriken mit der Object Constraint Language OCL Warmer Kleppe 1999 durchzuf hren Die OCL ist eine formale Sprache zur Formulierung von Ein schr nkungen auf UML Modellen Erste Versuche mit OCL zeigten jedoch dass die Erstellung von Metrikdefinitionen schwierig ist Au erdem sind sie schlecht zu lesen und zu verstehen Darum wurde dieser Ansatz nicht weiterverfolgt Hingegen hat Abreu 2001 sp ter OCL erfolgreich eingesetzt um auf der Basis des Metamodells GOODLY Metriken zu definieren Es ist wahrscheinlich dass sich seine Ergebnisse auf das UML Metamodell bertragen lassen Allerdings sind die notwendigen kom plexen OCL Ausdr cke nicht besonders gut lesbar 48 5 Ein Referenzmodell fur den objektorientierten Entwurf 5 3 Kern Abbildung 5 4 zeigt die Kernelemente von ODEM mit ihren Attributen und Bezie hungen als UML Klassendiagramm Genauso gut w re eine Darstellung als Entity Relationship Diagramm m glich Die Elemente werden nun im Einzelnen vorge stellt Dabei wird die Ableitung der Mengen und Relationen der Abstraktionsschicht von den Bestandteilen des UML Metamodells erl utert Package contains name contains visibility ContainS uses visibility name visibility ownerScope Abbildung 5 4 Der Kern von ODEM 5 3 1 System Das entworfene System S besteht aus Paketen S selbst wird ebenfalls als
61. P Kazman R Software Architecture in Practice Addison Wesley Reading MA 1998 Baumann 1997 Baumann K Unterstiitzung der objektorientierten Systemanalyse durch Softwarema e Physica Verlag Heidelberg 1997 Baumert 1991 Baumert J New SEI Maturity Model Targets Key Practices IEEE Software 8 6 78 79 Beck 1996 Beck K Make it Run Make it Right Design Through Refactoring Small talk Report 6 4 1997 19 24 Beck 1999a Beck K Extreme Programming Explained Embrace Change Addison Wesley Reading MA 1999 Beck 1999b Beck K Embracing Change with Extreme Programming IEEE Com puter 32 10 1999 70 77 Beck Cunningham 1989 Beck K Cunningham W A Laboratory for Teaching Object Oriented Thinking Proceedings of OOPSLA 89 ACM SIGPLAN Notices 24 10 1989 1 6 Beck Gamma 1998 Beck K Gamma E Test infiziert Wie Programmierer das Tests Schreiben lieben lernen Java Spektrum 5 1998 22 32 Bell et al 1987 Bell G Morrey I Pugh J Software Engineering A Programming Approach Prentice Hall New York 1987 Berard 1993 Berard E Essays on Object Oriented Software Engineering Bd 1 Prentice Hall Englewood Cliffs NJ 1993 Berg et al 1995 Berg W Cline M Girou M Lessons Learned from the OS 400 OO Project Communications of the ACM 38 10 1995 54 64 Bersoff et al 1980 Bersoff E Henderson V Seigel S Software Configuration Management Prent
62. Preis berechnen kann vgl Abbildung 7 5 Die resultierende Kommunikation ist in Abbildung 7 6 dargestellt Der Vorteil dieser L sung ist dass getCharge in Movie leichter zu implementieren ist da die bisher explizit im Code zu formulierende Fallunterscheidung nach dem Preis code jetzt durch dynamisches Binden erledigt wird Die L sung kann daher einfacher um neue Preiscodes erweitert werden Au erdem ist die Preisberechnung f r einzelne 76 7 Entwurfsqualitat Movie daysRented int getChargei float Customer statement setPriceCode Price getChargefint float getCharge lint oat NewReleasePrice TTY getChargefint float ChildrensPrice ReqgularPrice H getCharge int float getCharge int float Abbildung 7 5 Klassendiagramm fiir Entwurf C statement ffor all rentals es getCharget getCharge days getCharge days Abbildung 7 6 Sequenzdiagramm fiir Entwurf C Preiscodes leichter zu ndern Die Trennung zwischen den Gesch ftsregeln und der restlichen Programmlogik Separation of Policy and Implementation Buschmann et al 1996 S 401 ist hier am besten umgesetzt Der Preis daf r ist allerdings hoch Vier neue Klassen so dass sich die Anzahl der Klassen im gezeigten Ausschnitt mehr als verdoppelt Die Verst ndlichkeit wird dadurch wieder verschlechtert Metriken F r die drei Entw rfe
63. STpits 2 STpnus 2 STuncs 1 STmnps 1 Entkopp Klasse Interface DCNEEC 1 DCnerc 1 DCNEAC 1 DCNEUC 1 lung Paket DCnecp 2 DCnacp 1 Tabelle 10 4 Gewichtung der objektiven Metriken 10 1 4 Fragebogen Die Frageb gen wurden vollst ndig in das spezifische Qualit tsmodell bernommen Gewichte Bei den Frageb gen wurde der in Abschnitt 9 6 2 vorgeschlagene Default f r die Gewichte verwendet 1 f r weniger wichtig 2 f r wichtig und 3 f r sehr wichtig 10 2 Anwendung des Qualit tsmodells Das spezifische Qualit tsmodell wurde auf die Entw rfe der zw lf Gruppen ange wendet Die Bewertung eines Entwurfs dauerte je nach Gr e zwischen zwei und vier Stunden was aber vor allem an der Metrikenerhebung von Hand lag Bei einer entsprechenden Werkzeugunterst tzung d rfte die Bewertungszeit f r die Entw rfe bei ein bis zwei Stunden liegen Weil begleitende Dokumentation in die Bewertung einbezogen wird ist deren Qualit t ein wichtiger Einflussfaktor auf die Dauer der Bewertung Von hoher Bedeutung ist z B die Verf gbarkeit einer Gesamtsicht des Entwurfs Im Folgenden werden die Ergebnisse der Bewertungen pr sentiert Bei der Bewer tung sind einige Entwurfsauschnitte positiv und negativ aufgefallen von denen eine Auswahl vorgestellt wird Abschlie end wird das Modell validiert 10 2 1 Ergebnisse Tabelle 10 5 und Tabelle 10 6 zeigen die Messwerte der objektiven und subjektiven System
64. Werkzeug unterst tzung 12 Zusammenfassung und Ausblick Abbildung 1 2 Struktur der Arbeit Kapitel 2 Modelle und Metriken In diesem Kapitel werden zwei grundlegende Begriffe eingef hrt die f r die Quali t tsmodellierung von Bedeutung sind Zun chst geht es um den Begriff Modell dann um die Metrik eine spezielle Form des Modells 2 1 Modelle Models of course are never true but fortunately it is only necessary that they be useful Box 1979 S 2 2 1 1 Definition Ein Modell ist ein Abbild deskriptives Modell oder ein Vorbild pr skriptives Modell eines Objekts Das Objekt auf das sich das Modell bezieht hei t Original Stachowiak 1973 formuliert in seiner Allgemeinen Modelltheorie drei Hauptmerk male eines Modells Abbildungsmerkmal Verk rzungsmerkmal und pragmatisches Merkmal Diese werden im Folgenden n her erl utert Abbildungsmerkmal Modelle sind stets Modelle von etwas n mlich Abbildungen Repr sentationen nat rlicher oder k nstlicher Originale die selbst wieder Modelle sein k nnen Stachowiak 1973 S 131 Ein Modell bildet Attribute Eigenschaften des Originals auf Modellattribute ab Dabei kann das Original bereits ein Modell sein Beispielsweise ist die Spezifikation ein Modell des Codes und der Code wiederum ein Modell des ausf hrbaren Pro gramms Ludewig 1998 8 2 Modelle und Metriken Verkurzungsmerkmal Modelle erfassen im allgemeinen nicht alle
65. all but the most trivial projects are subject to change for external reasons Parnas Clements 1986 S 251 36 4 Objektorientierter Entwurf Die Anforderungen umrei en das Problem fiir das eine L sung entworfen werden soll Je unklarer das Problem beschrieben wird desto schwieriger wird es eine brauchbare L sung anzugeben Wie eine Untersuchung der KPMG 1995 zeigt sind bei 51 aller gescheiterten Projekte Probleme mit den Anforderungen ein Grund f r das Scheitern es handelt damit sich um den am h ufigsten genannten Grund Die ideale Spezifikation ist vollst ndig konsistent verst ndlich und pr zise Lude wig 1998 Eine solche Spezifikation ist in der Praxis allerdings u erst selten was auch daran liegt dass ihre Erstellung sehr teuer ist Au erdem bringt jeder Anwen dungsbereich einige Grundannahmen mit die f r den Kunden selbstverst ndlich sind weshalb sie meistens in der Spezifikation fehlen Ist der Entwerfer mit dem Anwendungsbereich vertraut wird er diese impliziten Anforderungen oder Ent wurfseinschr nkungen aus seiner Sicht in den Entwurf einflie en lassen Verf gt der Entwickler hingegen nicht ber Wissen aus dem Anwendungsbereich ist es unwahrscheinlich dass sein Entwurf brauchbar sein wird Schlie lich kann erst durch die Implementierung wirklich festgestellt werden ob die Anforderungen auch reali sierbar sind Boehm 1976 In der Praxis hat der Entwerfer auch damit zu k mpfen dass die
66. and Artefacts in Social Science An Ephistemological and Methodological Analysis of Empirical Social Science Research Techniques McGraw Hill Hamburg 1988 Kruchten 1994 Kruchten P The 4 1 View Model of Architecture IEEE Software 11 6 1994 42 50 Laitenberger et al 2000 Laitenberger O Atkinson C Schlich M El Emam K An Experimental Comparison of Reading Techniques for Defect Detection in UML Design Documents Technical Report ISERN 00 01 2000 Lakos 1996 Lakos J Large Scale C Software Design Addison Wesley Reading MA 1996 Lea 1994 Lea D Christopher Alexander An Introduction for Object Oriented Designers ACM SIGSOFT Software Engineering Notes 19 1 1994 Lehman 1980 Lehman M Programs Life Cycles and Laws of Software Evolution Proceedings of the IEEE 68 9 1980 1060 1076 Lejter et al 1992 Lejter M Meyers S Reiss S Support for Maintaining Object Oriented Programs Transactions on Software Engineering 18 12 1992 1045 1052 Lewerentz et al 2000 Lewerentz C Rust H Simon F Quality Metrics Num bers Consequences Lessons Learned In Dumke R Lehner F Hrsg Software Metriken Gabler Wiesbaden 2000 51 70 Li 1992 Li W Applying Software Maintenance Metrics in the Object Oriented Soft ware Development Life Cycle Ph D Dissertation Virginia Polytechnic Institute and State University Blacksburg VA 1992 Li 1998 Li W Another Met
67. architecture IEEE Std 610 12 1990 The organizational structure of a system or component Definition 4 4 architectural design IEEE 610 12 1990 A collection of hardware and software components and their interfaces to establish the frame work for the development of a computer system Diese Definition f hrt den Begriff der Komponente ein es fehlt allerdings ein wichti ger Aspekt die Beziehungen zwischen den Komponenten Dieser Aspekt kommt bei der Definition von Bass et al 1998 S 23 hinzu Definition 4 5 architecture Bass et al 1998 The software architecture of a program or computing system is the structure or structures of the system which comprise software components the externally visible properties of those components and the relationships among them Die Architektur definiert also eine Struktur die aus Komponenten und ihren Bezie hungen Konnektoren besteht F r die Komponenten und Konnektoren werden die nach au en sichtbaren Eigenschaften z B Attribute und Operationen spezifiziert Sie bilden die Schnittstelle Die neueste Definition des Architekturbegriffs stammt aus dem IEEE Standard 1471 2000 zur Beschreibung von Software Architekturen Definition 4 6 architecture IEEE Std 1471 2000 The fundamental organization of a system embodied in its components their relationships to each other and to the environment and the principles guiding its design and evolution ER 4 Objektorientierter Entwurf
68. auch den Kunden zufrieden stellen also korrekt und vollst ndig sein soweit das dazu n tig ist e Projekteigent mer Der Projekteigent mer m chte mit m glichst geringen Kosten eine m glichst hohe Kundenzufriedenheit zu erreichen Allerdings kann er auch eine langfristige projekt bergreifende Position einnehmen und z B die Entwick lung wiederverwendbarer Komponenten im Projekt f rdern so dass die Wieder verwendbarkeit des Entwurfs oder von Teilen daraus eine Rolle spielt 7 2 3 Qualit tssicht Wie bei dem allgemeinen Qualit tsbegriff gibt es auch bei der Entwurfsqualit t ver schiedene M glichkeiten sich der Sache zu n hern Hier werden die f nf Qualit ts sichten aus Abschnitt 6 1 auf den Entwurf bertragen Die transzendente Sicht Eleganz und Sch nheit Beauty is more important in computing than anywhere else in technology Beauty is important in engineering terms because software is so complicated Complexity makes pro grams hard to build and potentially hard to use beauty is the ultimate defense against com plexity Gelernter 1998 S 22 Die Qualit t des Entwurfs wird hier mit der wahrgenommenen Sch nheit und Ele ganz gleichgesetzt Die Sch nheit eines technischen Gegenstandes einer Maschine wird nach Gelernter 1998 durch zwei Aspekte bestimmt Kraft power und Einfach heit simplicity Ein Gegenstand der Kraft besitzt l sst sich f r viele Zwecke einset zen und f r diese eignet er
69. bei der Wart barkeit vorkommen d rfte das relativ leicht m glich sein Dann ist zu berlegen ob es sinnvoll ist einige Einschr nkungen von ODEM aufzuheben z B das Weglassen geschachtelter Klassen oder der Multiplizit ten von Assoziationen Ein Problem des Ansatzes ist die eingeschr nkte Informationsbasis auf der die Bewertung durchgef hrt wird Hier ist es sinnvoll zus tzlich dynamische Entwurfs information zu ber cksichtigen so dass QOOD um weitere wichtige Faktoren erwei tert werden k nnte Wenn Code verf gbar ist sollte erg nzend zum UML Modell aus diesem detaillierte Entwurfsinformation z B Methodenaufrufe durch Methoden extrahiert werden Dazu muss ODEM entsprechend erweitert werden damit QOOD mit passenden Metriken angereichert werden kann 12 4 2 Vision Abschlie end wird eine Vision entwickelt wie eine umfassende Entwurfsunterst t zung auf der Basis von QOOD erreicht werden kann Die vorliegende Arbeit stellt nur einen kleinen Schritt in diese Richtung dar kann jedoch als Basis dienen QOOD wurde in dieser Arbeit f r die Entwurfsbewertung entwickelt kann aber auch noch anderweitig genutzt werden Zum einen k nnen aus QOOD Richtlinien abgelei tet werden welche die Entstehung eines guten Entwurfs beg nstigen Zum anderen k nnen Restrukturierungen abgeleitet werden die zu Entwurfsverbesserungen f h ren In Abbildung 12 1 sind diese drei Anwendungsm glichkeiten in einen iterativen Entwurfsprozess in
70. den Entwurf dienen indem z B Faktoren und Kriterien wiederverwendet werden 6 3 Qualit tssicherung 6 3 1 Qualit tssicherungsma nahmen In the recent struggle to deliver any software at all the first casualty has been consideration of the quality of the software delivered C A R Hoare 1981 S 80 You can sense it all around you a software crisis your bank statement s not right the PC soft ware has glitches and the software you ve written keeps you up all night Everyone an feel the problem but they can t define it Most software engineers believe there is a crisis but they haven t been able to figure out what to do to change it The problem is quality they cry Nonsense quality is the solution to your problem Arthur 1993 S xiv Qualitatssicherung quality assurance dient dazu die Ubereinstimmung eines herge stellten Produkts mit den Anforderungen zu gew hrleisten Definition 6 5 quality assurance IEEE Std 610 12 1990 A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements Zur Qualit tssicherung QS lassen sich verschiedene Ma nahmen ergreifen Im Soft warequalit tsmanagement zerfallen diese in drei Kategorien organisatorische kon struktive und analytische Fr hauf et al 2000 vgl Abbildung 6 6 70 6 Softwarequalitat Softwarequalitatsmanagement organisatorisc
71. der Fragestellung Antwortskala Die Skala der m glichen Antworten Im einfachsten Fall handelt es sich um eine Ordinalskala mit den Werten nein und ja bin re Frage Es gibt aber 9 4 Frageb gen 129 auch Fragen ftir die es schwierig ist eindeutige Ja Nein Antworten zu geben weil eine graduelle Aussage wie zu 70 ja zutreffender ist als ein absolutes Ja Daher ist es sinnvoll dem Bewerter Zwischenwerte zwischen ja und nein anzubieten Dazu wird hier die Rationalskala mit dem Wertebereich 0 1 verwendet Der Wert 0 wird mit nein assoziiert der Wert 1 mit ja Bei bin ren Fragen werden die Werte 0 und 1 vergeben bei graduellen Fragen k nnen auch Zwischenwerte aus 0 1 gew hlt wer den Die Fragen werden so formuliert dass ein Ja positiv fiir die Qualitat ist Daraus folgt dass h here Werte bei einer graduellen Frage eine h here Qualit t bedeuten Gewicht Gibt an wie wichtig die Frage f r die Bewertung ist Es wird hier mit den generischen Werten weniger wichtig wichtig und sehr wichtig gearbeitet die in einem spezifischen Modell durch konkrete Werte zu ersetzen sind Fragen die wich tige erw nschte Eigenschaften des Entwurfs sicherstellen oder gravierende Fehler aufdecken sollen erhalten das h chste Gewicht sehr wichtig darunter wird abge stuft zwischen normaler Wichtigkeit wichtig und nicht notwendigerweise erforder lichen Eigenschaften weniger wichtig Automatisierbarkeit Gibt an ob die Frage aut
72. der Aggregation Hier ist der Teil fest an das Ganze gebunden er darf daher auch nur an einer Komposition teilnehmen Gleichzei tig ist die Lebenszeit des Teils h chstens so lang wie die des Ganzen Die Komposition besteht w hrend der gesamten Lebenszeit des Teils Die UML Darstellung der Kom position ist wie die der Aggregation nur ist die Raute schwarz gef llt Aggregation ein Club kann worksfor 0 1 beliebig viele Personen Person I Company als Mitglieder Rolle mem ber haben eine Person 22 22 kann in vielen Clubs sein Ba Assoziation eine Person kann f r maximal eine Firma arbeiten Eine Firma hat beliebig viele Angestellte 3 Der Pfeil zeigt die Leserichtg SEE Komposition eine Firma besteht aus vielen Divisio nen diese wiederum aus vielen Abteilungen strikt hierarchisch ee een Department Abbildung 3 4 UML Darstellung von Assoziationen 3 2 Unified Modeling Language 21 3 1 3 Benutzung Neben den bereits vorgestellten Beziehungen Vererbung Assoziation und Realisie rung gibt es noch andere Arten die in UML unter dem Begriff Abh ngigkeit dependency subsumiert werden Eine spezielle Form der Abh ngigkeit ist die Benutzung usage Stereotyp use Die Darstellung einer Abh ngigkeit in UML ist ein gestrichelter Pfeil mit offener Spitze vgl Abbildung 3 5 Eine Differenzierung der Benutzung ist durch Vergabe von Stereotypen m
73. des Werkzeugs QMOOD Bansiya Davis 1997 Metriken erhoben Jede dieser Metriken ist genau einer Entwurfseigenschaft zugeordnet Die Entwurfseigen schaften beeinflussen die Qualit tsattribute positiv oder negativ F r die St rke des Einflusses geben die Autoren Gewichte an so dass sich aus den Metriken Qualit ts kennzahlen f r die Qualit tsattribute berechnen lassen Die Gesamtbewertung ergibt sich durch Aufsummieren der Qualit tskennzahlen quality attributes design properties metrics messaging a class interface size CIS design size design size in classes DSC reusability lt coupling direct class coupling DCC cohesion cohesion among methods in class CAM complexity number of methods NOM encapsulation data access metric DAM polymorphism lt number of polymorphic methods NOP extendibility amp composition _ measure of aggregation MOA De et es hierarchies _ number of hierarchies NOH abstraction average number of ancestors ANA inheritance _ measure of functional abstraction MFA Legende beeinflusst positiv lt beeinflusst negativ Abbildung 7 10 Qualit tsmodell von Bansiya und Davis 74 8 Kritische Bewertung Wie die vorgestellten Beispiele zeigen gibt es kein einheitliches Modell zur Bewer tung objektorientierter Entw rfe Es gibt zwar einige Kriter
74. die anderen Metriken bertra gen Ergebnis der Untersuchung ist dass die Axiome W1 W2 W3 W4 W6 und W8 f r alle Metriken gelten W5 gilt f r alle Metriken mit Ausnahme von DITC bei der es einen Spezialfall gibt der W5 nicht erf llt siehe DIT bei Chidamber Kemerer 1994 S 483f F r die Verfeinerungen gelten dieselben Axiome wie die urspr ngliche Metrik Alle Metriken mit einer leichten Einschr nkung bei DITC besitzen also theo retische Validit t als Komplexit tsmetriken 12 5 2 Kopplungsmetriken F r die theoretische Validierung objektorientierter Kopplungsmetriken k nnen auch die Axiome von Briand et al 1999 verwendet werden Axiom BDW1 Nichtnegativit t Kopplung ist nie negativ VP m P gt 0 Axiom BDW2 Nullwert Klassen ohne Beziehungen nach au en k nnen keine Kopplung haben also soll die Kopplung 0 sein V P m P 0 P hat keine Beziehungen nach au en Axiom BDW3 Monotonie F gt man einer Klasse weitere Beziehungen hinzu wird die Kopplung nicht kleiner sondern bleibt gleich oder steigt 3 Der Sonderfall durch Umbenennung zwei Attribute desselben Namens und desselben Typs zu erhalten ist m glich Es gibt aber eine Wohlgeformtheitsbedingung in der UML die eine solche Klasse f r ung ltig erkl rt so dass eine solche Klasse kein Messgegenstand sein kann 202 A Metriken fur QOOD V P Q Q amp P m P lt m Q amp erweitert P um weitere Beziehungen Axiom BDW4 Verschmel
75. dieses Ansatzes sind QFD Quality Function Deployment und GOM Goal Question Metric Quality Function Deployment OFD wurde erstmals 1972 bei Mitsubishi in der Fabrikation eingesetzt und sp ter von Kogure und Akao auf Software Produkte bertragen Der Ansatz ist haupts chlich in Japan verbreitet Kogure Akao 1983 und geh rt zum Bereich des Total Quality Man agement TQM Eine ausf hrliche Beschreibung von QFD gibt Akao 1990 Das Vorgehen bei QFD ist wie folgt Zun chst werden s mtliche Qualit tsanforderun gen des Kunden und der zuk nftigen Benutzer durch Befragung erhoben Anschlie end werden diese Anforderungen an das Endprodukt Benutzersicht in Anforde rungen an die Zwischenprodukte Entwicklersicht bersetzt Der Zusammenhang zwischen den beiden Sichten wird f r jede Anforderung klar dokumentiert z B in Form von Matrizen Auf diese Weise ist den Entwicklern immer klar was eine Anfor derung f r die beiden Sichten bedeutet In Zusammenhang mit Joint Application Development JAD Entwicklung unter Inte gration von Vertretern des Kunden hat sich diese Methode als sehr effektiv herausge stellt Fehler in der Spezifikationsphase zu vermeiden Jones 1997 S 266 Haag et al 1996 berichten ber die erfolgreiche Anwendung von QFD bei gro en Softwareher stellern Goal Question Metric GOM wurde Ende der 80er Jahre im Rahmen des TAME Projekts Tailoring a Mea surement Environment von Basili und Rombach 19
76. durch eine Assoziation der Klasse ModelEle ment mit sich selbst modelliert vgl Abbildung 5 1 Ein ModelElement kann eine Menge von Template Parametern haben Rolle templateParameter Hat ein ModelEle ment mindestens einen solchen Parameter ist es ein Template sonst nicht Die Tem plate Parameter sind formale Parameter und diirfen keine innere Struktur Attribute Operationen etc besitzen Nur ihr Name und ihr Typ sind relevant Die formalen Parameter k nnen Klassen sein aber auch Datentypen und Operationen sind m g lich Es k nnen zus tzliche Einschr nkungen f r den Typ der Parameterbelegung gemacht werden z B der Parameter muss ein Interface implementieren oder eine ganze Zahl sein Au erdem k nnen Beziehungen zwischen den Parametern unter einander und mit dem Template selbst formuliert werden z B Aggregation Verer bung etc Diese Beziehungen m ssen dann auch bei den korrespondierenden Ele menten der Parameterbelegungen vorhanden sein Das Template selbst kann zu anderen Modellelementen nur ausgehende Beziehungen haben diese werden auf die Instanzen bertragen Eine Instantiierung eines Templates wird durch die Dependency Unterklasse Binding modelliert Diese verbindet ber die von Dependency geerbten Assoziationen das Template Rolle supplier mit seiner Instanz Rolle client Die Parameterbelegung wird durch eine zus tzliche geordnete Aggregation modelliert die Rolle arguments enth lt dabei die aktuellen Par
77. e Werden ffentliche Methoden private Methoden oder beide gez hlt Das gleiche Problem hat brigens auch die hnliche Metrik WMC Weighted Methods per Class Chidamber Kemerer 1994 wie auch Churcher und Shepperd 1995b fest stellen Eine formale Definition der Metriken ist also unabdingbar Es bietet sich an als Basis der formalen Definition ODEM als Referenzmodell zu verwenden 5 5 2 Fallstudien Um die Eignung von ODEM zur formalen Definition von Metriken auf bereits in der Literatur definierte Metriken zu erproben werden in zwei Fallstudien die Paketmetri ken von Martin 1995 und die bekannte Metrikensuite von Chidamber und Kemerer 56 5 Ein Referenzmodell fur den objektorientierten Entwurf 1994 mit Hilfe von ODEM formalisiert soweit m glich Die formalen Definitionen verwenden zum Teil Metriken aus QOOD vgl Tabelle 9 1 Fallstudie 1 Martins Paketmetriken Martin definiert Kriterien f r die richtige Verteilung von Klassen auf Pakete Diese Kriterien basieren auf dem Begriff der Abh ngigkeit Ziel ist die Minimierung von Abh ngigkeiten insbesondere Abh ngigkeiten zu konkreten Klassen Leider definiert Martin nicht genau was eigentlich eine Abh ngigkeit ist Es sagt nur dass Abh ngig keiten durch Klassenbeziehungen wie Vererbung Aggregation und Benutzung ent stehen Hier wird f r die Formalisierung die depends_on Relation verwendet welche die genannten Beispiele einschlie t Relational cohesion H
78. effekt Au erdem ist die Wahrscheinlichkeit gering dass Fehler in anderen Kompo nenten Folgefehler in der Komponente selbst verursachen Schlie lich ergibt sich auch eine bessere Verst ndlichkeit da zum Verst ndnis einer Komponente weniger andere Komponenten verstanden werden m ssen Dass sich hohe Entkopplung positiv auf die Wartbarkeit auswirkt zeigen empirische Untersuchungen von Yin und Winchester 1978 Troy und Zweben 1981 sowie von Rombach 1990 f r den strukturierten Entwurf und von Binkley und Schach 1996 f r den objektorientierten Entwurf Die genannten Untersuchungen haben auch gezeigt dass Entkopplungsmetriken die st rksten Indikatoren f r die Wartbarkeit sind 8 3 4 Zusammenhalt Definition Zusammenhalt cohesion vgl Stevens et al 1974 ist ein Ma f r die St rke der semantischen Zusammengeh rigkeit von Bestandteilen einer Komponente Alles was zusammengeh rt sollte sich in einer Komponente befinden aber nicht mehr In der Objektorientierung lassen sich zwei Ebenen des Zusammenhalts unterscheiden die Zusammengeh rigkeit von Attributen und Operationen in einer Klasse und die Zusammengeh rigkeit von Klassen in einem Paket 8 3 Wartbarkeit 111 Diskussion Zusammenhalt verbessert die Verst ndlichkeit und damit die Wartbarkeit Durch hohen Zusammenhalt ist die Wahrscheinlichkeit hoch dass bei einer nderung in der Regel nur eine Komponente betroffen ist da alle Aspekte einer Abstraktion an
79. einem Entwicklungsprozess eingesetzt wird der dem Wasserfallmodell Royce 1970 ent spricht weil am Ende der Entwurfsphase der Entwurf vollst ndig vorliegt aber noch keine Realisierung vorgenommen wurde Ein solcher Entwicklungsprozess ist aber nur dann sinnvoll wenn die Anforderungen klar und stabil sind was selten gegeben ist Daher findet Software Entwicklung h ufig in einem iterativen evolution ren Pro zess statt Der Entwurf entsteht und w chst schrittweise und wird immer wieder berarbeitet Auf der einen Seite kann dieses Vorgehen zu einem besseren Entwurf f hren als beim Wasserfallmodell Auf der anderen Seite kann es schwieriger werden Fehlentwicklungen zu erkennen weil eine Bewertung des Gesamtbilds erst sp t im Entwicklungsprozess m glich ist Der vorgestellte Ansatz zur Bewertung kann jeder zeit durchgef hrt werden auch auf Zwischenversionen des Entwurfs Nur kann eben immer nur die bereits vorliegende Entwurfsinformation ber cksichtigt werden Eine v llig rationale objektive und gleichzeitig weitgehend zutreffende Bewertung des Entwurfs ist theoretisch denkbar Der dazu zu treibende Aufwand ist allerdings immens Der Entwurf muss hinreichend formalisiert werden es muss ein spezifisches Qualit tsmodell erstellt und validiert werden und f r jede Bewertung sind die erfor derlichen Daten zu erheben und zu verarbeiten Der Gesamtaufwand d rfte also so gro sein dass es auch in Zukunft schon aus konomischen Erw
80. es sich hier um studentische Projekte im Rahmen eines Praktikums handelt sind die Imple mentierungen allerdings Wegwerfprodukte Sie wurden nie gewartet so dass keine Wartungsdaten vorliegen Die Alternative die zw lf Implementierungen durch andere Entwickler warten zu lassen musste leider wegen des daf r notwendigen Aufwands verworfen werden Stattdessen wird hier eine Plausibilit tspr fung durchgef hrt F r die Entw rfe und ihre Implementierungen wird ermittelt welche Klassen Attribute und Operationen ge ndert bzw hinzugef gt werden m ssen um drei adaptive Wartungsaufgaben 1 Bei den ge nderten Operationen werden nicht nur diejenigen mitgez hlt deren Signatur sich ndert sondern auch die bei denen die Implementierung die Methode ge ndert werden muss 146 10 Ein spezifisches Qualitatsmodell durchzuf hren Die Aufgaben sind aus der Liste der wahrscheinlichen nderungen abgeleitet die Bestandteil der Spezifikation war vgl Abschnitt C 2 8 Dort sind f nf nderungen vorgesehen Da zwei dieser nderungen vor allem Auswirkungen auf die Benutzungsoberfl che haben f r die keine einheitlichen Anforderungen festge legt sind konzentriert sich die Untersuchung auf die ersten drei nderungen Die so ermittelten notwendigen nderungen am Entwurf k nnen zur Absch tzung des Wartungsaufwands verwendet werden Die Anzahl der Klassen wiegt dabei am schwersten weil vor der nderung einer Klasse diese zun chs
81. glich z B call oder create Ebenso wie bei der Assoziation sind Benutzungsbeziehungen Beziehungen zwischen Objekten die aber auf Klassenebene modelliert werden Die Klasse Company ver Company call Division wendet die Klasse Division l Factory Factory durch Aufruf einer Operation DivisionFactory ke create erzeugt Division Objekte Division Abbildung 3 5 UML Darstellung von Benutzungsbeziehungen 3 1 9 Paket Pakete werden zur Gruppierung von Klassen und Interfaces verwendet Logisch zusammengeh rige Elemente werden in einem Paket zusammengefasst Pakete k n nen auch Pakete enthalten so dass sich durch die Schachtelung von Paketen eine Baumstruktur ergibt Das Gesamtsystem ist implizit ebenfalls ein Paket das direkt oder indirekt alle Elemente enth lt In UML werden Pakete durch einen Kasten mit einem Reiter dargestellt Der Paket name wird entweder in den Reiter oder in den Kasten geschrieben Elemente die im Paket enthalten sind werden hineingezeichnet vgl Abbildung 3 6 Das Paket CompanyStruc CompanyStructure ture enth lt die Klassen Company Division und Wee Department sowie das Paket Company Division Deparment Employees i en eh Employees Abbildung 3 6 UML Darstellung von Paketen 3 2 Unified Modeling Language Die grammatischen Regeln einer Sprache die Regeln des Satzbaus z B sind auch Vorschrif ten f r die Beschr
82. gungen erforderlich sein wird die Bewertung im Wesentlichen mit Hilfe der Intuition und Erfahrung eines guten Entwerfers durchzuf hren Qualit tsmodelle mit objektiven Metriken und daraus abgeleitete automatisierte Entwurfsregeln sind dabei praktische Hilfsmit tel der Analyse die dem Bewerter die Arbeit erleichtern ihn aber nicht ersetzen 12 3 Vergleich mit anderen Arbeiten Grundlage der Entwurfsbewertung In dieser Arbeit ist die Grundlage der Entwurfsbewertung ein UML Modell Die meisten Arbeiten im Bereich der Entwurfsbewertung st tzen sich allerdings entweder 12 3 Vergleich mit anderen Arbeiten 165 auf eine nicht n her spezifizierte Architekturdokumentation z B Bass et al 1998 Clements et al 2002 oder auf Code z B Erni 1996 Bar 1998 F r die Bewertung auf der Basis einer Entwurfsdokumentation in UML gibt es bisher nur die Ans tze von Robbins Redmiles 1999 und Nenonen et al 2000 Bei Robbins und Redmiles werden weder Metriken erhoben noch wird eine Gesamtbewertung angestrebt der Schwerpunkt liegt im Aufzeigen von M ngeln auf der Basis von Entwurfsregeln Der Ansatz von Nenonen et al arbeitet mit Metriken und bezieht dabei auch UML Bestandteile zur Modellierung der dynamischen Struktur ein Die erhobenen Metri ken sollen zur Qualit tsbewertung dienen wie diese allerdings genau durchgef hrt werden soll sagen die Autoren nicht Qualit tsmodellierung In Abschnitt 7 4 wurden einige Qualit tsmod
83. her desto kritischer Auf die Wartbarkeit der Klasse selbst hat das zwar keinen gro en Einfluss die Metrik sollte aber zumindest bei der Gesamtbetrachtung des Systems ber cksichtigt werden Alle Verfeinerungen der efferenten Abh ngigkeiten lassen sich auch auf die afferenten Abh ngigkeiten anwenden Paket Bei Paketen gibt es bis auf die contains Relation keine direkten Abh ngigkeitsrelatio nen F r die Kopplung ist die contains Relation allerdings nicht relevant Die Abh n gigkeiten der Pakete sind daher aus den Abh ngigkeiten der enthaltenen Klassen abzuleiten Wenn eine enthaltene Klasse c eines Pakets p von einer Klasse d in einem anderen Paket q abh ngt so h ngt das Paket p von q ab vgl Definition von depends_on f r Pakete in Abschnitt 5 4 1 Die Kopplungsst rke ergibt sich dabei aus 196 A Metriken fur QOOD der Anzahl der Beziehungen Alle in diesem Abschnitt definierten Metriken sind zum Kriterium Entkopplung negativ korreliert NEDP number of efferent dependencies of a package NEDP p ge p p 4epends_on p q weight Zusatzlich kann noch gemessen werden wie stark andere Pakete an ein Paket gekop pelt sind also die Gegenrichtung zur bisher betrachteten NADP number of afferent dependencies of a package NADP p Xgep fp depends_on q p weight Diese Metriken ber cksichtigen alle Abh ngigkeiten auch geerbte Dadurch wird die tats chliche Vernetzung deutlicher als wenn nur die direkten Abh ngi
84. hlweise ist nun die richtige Bei beiden gibt es Argumente daf r und dagegen Wegen der genannten Schwierigkeiten und der zus tzlichen Komplexit t wurde ent schieden Templates vorl ufig nicht in ODEM aufzunehmen 5 5 Formale Definition von Metriken 5 5 1 Stand der Praxis Metriken f r objektorientierte Systeme gibt es inzwischen viele z B Chidamber Kemerer 1991 Chen Lu 1993 Kolewe 1993 Li Henry 1993 Abreu Carapuca 1994 Chidamber Kemerer 1994 Hopkins 1994 Lorenz Kidd 1994 Martin 1995 Tegarden et al 1995 Henderson Sellers 1996 Li 1998 Marchesi 1998 Genero et al 2000 Einen berblick ber die Literatur geben Archer Stinson 1995 und Fetcke 1995 Ein schwer wiegendes Problem vieler dieser Metriken ist deren unpr zise nat rlich sprachliche Spezifikation Dies tritt besonders bei der Frage zutage wie mit geerbten Eigenschaften umgegangen wird Churcher Shepperd 1995a Beispielsweise werden Begriffe wie local method oder method of a class Li Henry 1993 bei der Defini tion von Number of Methods NOM verwendet um eine Z hlmetrik von Methoden einer Klasse zu definieren Leider werden diese Begriffe aber nicht n her erl utert Es bleibt damit unklar was genau gez hlt wird e Werden geerbte Methoden mitgez hlt e Werden bei redefinierten Methoden sowohl die geerbte als auch die neu definierte Methode gez hlt e Werden Klassenmethoden Instanzmethoden oder beide gez hlt
85. intellektuelle Kontrolle Daher sollte sie so gering wie m glich sein Vermeide Redundanz Beck 1996 Hunt Tho mas 1999 Jede Form von Redundanz stellt ein Risiko dar da es bei nderun gen leicht zu Inkonsistenzen kommt Stattdessen sollte eine Funk tion an genau einer Stelle realisiert werden Tabelle 7 2 Strategische Prinzipien 7 3 Entwurfsregeln 85 Prinzip Benutze Abstraktion Beschreibung Abstraktion ist ein f r den Menschen nat rliches Verfahren mit komplexen Sachverhalten umzugehen Bei der Abstraktion werden irrelevante Details ausgeblendet Um einen Sachverhalt zu verste hen ist es dann nicht mehr notwendig alle Details auf einmal im Ged chtnis zu haben Es gen gt die an der aktuellen Aufgabenstel lung beteiligten Abstraktionen zu beherrschen Teile und herrsche Ein Problem wird in kleinere m glichst unabh ngige Teilprobleme zerlegt die gel st werden Aus den Einzell sungen wird dann die Gesamtl sung zusammengesetzt Das Verfahren l sst sich rekursiv anwenden bis man zu einfach l sbaren Teilproblemen gelangt Der Vorteil dieses Vorgehens besteht darin dass zu einem Zeitpunkt nur ein Problem relativ geringer Komplexit t gel st werden muss Strukturiere hierarchisch Simon 1962 Parnas 1972b Der Mensch kann nur dann mit komplexen Systemen umgehen wenn sie hierarchisch sind Daher sind hierarchische Strukturen im Entwurf vorteilhaft Modularisiere
86. ist um so h her je weniger Aufwand man daf r aufbringen muss Mit dem Verfahren kann auch die Umsetzung der Funk tionsanforderungen im Entwurf gepr ft werden indem die Anwendungsf lle aus der Spezifikation am Entwurf durchgespielt werden Der Bewertungsansatz mit Szenarien hat den Vorteil dass er mit jeder Form der Ent wurfsdokumentation zurecht kommt da ein Mensch die Bewertung durchf hrt Zugleich wird die Vollst ndigkeit des Entwurfs gepr ft da beim Durchspielen sehr viele Detailinformationen zu den Abl ufen gebraucht werden wodurch L cken in der Beschreibung aufgedeckt werden Der Nachteil des Ansatzes ist es dass er nicht automatisierbar ist weshalb bei der Bewertung ein hoher Aufwand entsteht Daher k nnen praktisch nur ausgew hlte Szenarien durchgespielt werden die Entwurfsbewertung bleibt also mehr oder weni ger stichprobenartig 7 6 Entwurfsbewertung 99 Evaluation durch Simulation Liegt der ganze Entwurf in einer hinreichend forma len Beschreibung vor kann das entworfene System auch von einer Maschine simuliert werden Die Beschreibung wird sich allerdings auf einem eher abstrakten Niveau befinden weil sonst der Aufwand fiir die Erstellung der Beschreibung zu hoch ist Alternativ kann man sich auch auf Ausschnitte aus dem Entwurf beschranken die potentiell kritisch sind Ein Beispiel sind Machbarkeitsstudien in Form von explorati ven Prototypen die speziell fiir bestimmte Qualitatsaspekte erstellt werden
87. kann 4 2 4 Strukturen An object oriented program s run time structure often bears little resemblance to its code structure The code structure is frozen at compile time it consists of classes in fixed inherit ance relationships A program s run time structure consists of rapidly changing networks of communicating objects In fact the two structures are largely independent Trying to under stand one from the other is like trying to understand the dynamism of living ecosystems from the static taxonomy of plants and animals and vice versa Gamma et al 1995 S 22 Beim objektorientierten Entwurf kann zwischen statischer und dynamischer Struktur unterschieden werden Die statische Struktur beschreibt den Aufbau des Programms zur Ubersetzungszeit wahrend die dynamische Struktur den Aufbau des Programms zur Laufzeit beschreibt Statische Struktur Die statische Struktur besteht aus Klassen Interfaces und Paketen sowie ihren Bezie hungen untereinander Zu jeder Klasse und zu jedem Interface werden Attribute und Operationen ggf auch Redefinitionen angegeben Zwischen Klassen und Interfaces k nnen verschiedene Beziehungen bestehen Es lassen sich Benutzungsbeziehung 30 4 Objektorientierter Entwurf Vererbungsbeziehung Realisierung und Assoziation mit ihren Spezialf llen Aggre gation und Komposition unterscheiden vgl Abschnitt 3 1 Die Pakete dienen vor allem der hierarchischen Strukturierung der Klassen und Interfaces
88. mit Ausnahme von S 5 4 3 Gewichte f r die Relationen Die bisher definierten Relationen ber cksichtigen nicht wie viele Beziehungen einer Art zwischen zwei Modellelementen bestehen Es k nnte allerdings einen Unter schied machen ob eine Klasse eine oder mehrere Beziehungen einer Art mit einer anderen Klasse hat Deshalb wird f r jede Relation ein Attribut namens weight einge f hrt Der Wert von weight ist f r die Relationen contains extends und realizes immer gleich 1 Bei der associates und der uses Relation ist es m glich dass eine Beziehung mehrfach besteht Dann ist der Wert von weight die Anzahl dieser Beziehungen Der Wert von weight bei der depends_on Relation ergibt sich als Summe der Werte von weight bei den ber cksichtigten Relationen f r das Gewicht nicht vorhandener Relati onen wird der Wert 0 angenommen depends_on x y weight extends x y weight realizes x y weight associates x y weight uses x y weight F r die Relationen bleibt bei contains der Wert von weight bei 1 Bei extends ent spricht der Wert von weight der Anzahl der Pfade ber die eine Klasse von einer anderen erbt extends x y weight extends x y weight Ze CUI extends x z Cxtends z y weight Bei den Relationen associates realizes uses und depends_on muss zur Berechnung des Gewichts die Vererbungshierarchie des ersten Modellelements nach oben hin durchsucht werden F r jede Beziehung der gesuchten Art zwischen der Kla
89. rfen 190 A Metriken fur QOOD NOC number of operations of a class NOC c oe O has c o Diese Z hlmetriken k nnen verfeinert werden um spezielle Charakteristika der Eigenschaften zu ber cksichtigen Das wird hier am Beispiel von NAC demonstriert bei NOC funktioniert es analog Die erste Verfeinerung ber cksichtigt den Sichtbar keitsbereich des Attributs 1 public 2 protected 3 private Diese Verfeinerung ist praktisch um die ffentliche Schnittstelle oder die Vererbungsschnittstelle einer Klasse beurteilen zu k nnen NAC number of public attributes of a class NAC ec ae A has c a A a visibility public NAC number of protected attributes of a class NAC c ae A has c a A a visibility protected NAC number of private attributes of a class NAC c ae A has c a A a visibility private Die zweite Verfeinerung betrachtet die Zugeh rigkeit des Attributs zur Klasse c ownerScope classifier oder zum Objekt o ownerScope instance Klassenattribute tra gen in der Regel nicht so viel zur Komplexit t der Methodenimplementierungen bei k nnen aber andererseits erh hte Kopplung mit sich bringen da sie wie globale Vari able verwendet werden k nnen NAC number of class attributes of a class NAC c ae A has c a A a ownerScope classifier NAC number of object attributes of a class NAC c ae A has c a A a ownerScope instance
90. schen liegenden Werte werden linear interpoliert vgl Abbildung 9 3 oben Fall a Ist die Toleranz T gleich 0 werden alle Werte kleiner oder gleich dem Schwellenwert S auf 1 alle Werte gr er S auf 0 normiert vgl Abbildung 9 3 oben Fall b Bei positiv korrelierten Metriken wird die Normierung entsprechend entgegengesetzt durchge f hrt vgl Abbildung 9 3 unten a T gt 0 b T 0 normierter Wert normierter Wert 8 1 negative Korrelation Tr trF gt ST S SaT Messwert s Messwert normierter Wert normierter Wert 1 positive Korrelation ST S S4T Messwert s Messwert Abbildung 9 3 Normierung einer objektiven Metrik 1 Durch die lineare Interpolation erh lt ein Messwert in H he des Schwellenwerts die Bewertung 0 5 Ist dies nicht erw nscht kann durch Verschieben des Schwellenwerts die Auswertung ver ndert werden Wenn beispielsweise erreicht werden soll dass kein Wert oberhalb von S eine positive Bewertung erh lt kann ein neuer Schwellenwert S S T vergeben werden 9 3 Subjektive Metriken 125 Gewichtung Die normierten Metriken werden mit Gewichten multipliziert und dann aufsummiert Die Summe wird anschlie end durch die Summe der Gewichte dividiert um so einen gewichteten Durchschnitt zu erhalten Die Gewichte werden mit dem zweistelligen K rzel f r das Kriterium das auch f r die subjektiven Metri ken verwendet wird benannt vgl Tabelle 9 2 und mit dem Namen der Metrik indi ziert beispiels
91. sich gut Einfachheit tr gt dazu bei dass der Umgang mit dem Gegenstand leicht erlernbar ist und oft auch als nat rlich empfunden wird Ein fachheit bedingt auch Eleganz da hier ein Zweck mit wenigen Mitteln erreicht wird 3 Eine nderung zieht in der Regel Folge nderungen nach sich diese wiederum Folge nderungen etc Der Name Welleneffekt ripple effect kommt daher dass sich die nderungen im System aus breiten wie die Wellen auf einer Wasseroberfl che nach dem Aufschlag eines Steins 7 2 Perspektiven der Entwurfsqualitat 81 Gelernter fordert auch bei Software Sch nheit anzustreben Dies bezieht sich sowohl auf die u ere Gestaltung die Benutzungsoberfl che als auch auf den inneren Auf bau den Entwurf Auch andere Autoren davon viele Anh nger der Entwurfsmus ter Bewegung sehen einen Zusammenhang zwischen Sch nheit und Qualit t Da die Idee der Entwurfsmuster aus der Architektur kam werden gerne Analogien zur Architektur bem ht z B Fujino 1999 Ein guter Entwurf gem der transzendenten Sicht besitzt Eleganz und Sch nheit Diese sind etwas f r den erfahrenen Entwerfer Wahrnehmbares was aber nicht fass bar oder gar quantifizierbar ist Darum sind diese Eigenschaften f r ein Qualit tsmo dell leider unbrauchbar Gelernter 1998 S 33 schreibt You know beauty when you feel it there is no way to demonstrate its presence What we can do though is point out some of the telltales of simplicity an
92. sind und diese Attribute und Metho den sollen zusammenh ngen In der Vererbungshierarchie schlie lich sollen nur echte Spezialisierungen vorkommen Wiederverwendung reuse Die Wiederverwendung vorhandener Artefakte z B Klassen Komponenten Bibliotheken Entw rfe kann die Kosten senken und die Qualit t erh hen Klarheit clarity Der Entwurf muss verst ndlich sein um seine Verwendung und Wiederverwendung zu f rdern Als Ma nahmen werden die Verwendung eines ein heitlichen Vokabulars eines einheitlichen Stils insbesondere bei Schnittstellen und die klare Zuordnung von Verantwortlichkeiten zu Klassen genannt Einfachheit simplicity Methoden Objekte und Klassen sollen so einfach wie m g lich sein Methoden sollten nur wenige Anweisungen umfassen Objekte sollten so wenig wie m glich andere Objekte kennen m ssen um ihren Zweck zu erf llen Klassen sollten m glichst wenig Attribute und eine kleine Schnittstelle haben sowie klare Verantwortlichkeiten besitzen Gr e system size Die Gr e des Gesamtsystems sollte m glichst klein sein um die Handhabbarkeit zu verbessern Je gr er das System wird desto gr er wird das Risiko dass das Entwurfsteam den Entwurf nicht mit einem wohlstrukturierten ele ganten Ergebnis abschlie en kann Coad und Yourdon geben daf r eine Obergrenze von etwa hundert Klassen an Eleganz elegance Die Autoren geben zu dass dieses Kriterium von allen am schlechtesten mes
93. sind diese dargestellt klassifiziert nach Klarheit der Zielkriterien und Bekanntheitsgrad der Operatoren Zielkriterien klar unklar Opera bekannt Interpolationsbarriere dialektische Barriere toren unbekannt Synthesebarriere dialektische Barriere und Synthesebarriere Abbildung 4 4 D rners Barrierekategorien nach D rner 1976 S 10 Abbildung 4 5 veranschaulicht die Unterschiede der verschiedenen Problemklassen und den Unterschied zwischen Problem und Aufgabe Interpolationsprobleme Bei Interpolationsproblemen sind Ausgangs und Zielzustand klar definiert und die zur Verf gung stehenden Operatoren sind bekannt Es besteht jedoch eine Interpola tionsbarriere d h es ist unklar wie die Operatoren verwendet und kombiniert wer den m ssen damit die gew nschte Transformation von a in o entsteht Beispiels weise sind bei der Wegesuche in einem rechtwinkligen Labyrinth Anfangs und Zielzustand festgelegt Au erdem sind die m glichen Bewegungen Operationen durch das Operatoreninventar links drehen rechts drehen und geradeaus 4 5 Probleme des Entwurfs 39 Aufgabe O 0 O2 On 07 5 04 03 Interpolationsproblem Syntheseproblem dialektisches Problem O 0 02 On O 04 O9 O 0 09 On o gt 0 een gt 0 o gt Abbildung 4 5 Aufgabe und Probleme gehen klar definiert Das Finden eines Wegs durch das Labyrinth die Transforma tion ist aber wege
94. sollten soweit m glich ein Standardaufbau und Standardnotati onen verwendet werden Dokumentiert werden soll vor allem das Ergebnis des Entwurfs nicht der Entwurfs prozess Der Prozess ist eher chaotisch als geordnet vgl Abschnitt 4 1 2 dennoch sollte die Dokumentation so aussehen als sei der Entwurf das Ergebnis einer wohl berlegten Vorgehensweise Parnas Clements 1986 Neben der ausgew hlten 4 5 Probleme des Entwurfs 35 L sung sollten allerdings auch die betrachteten Alternativen vorgestellt werden und es sollte begr ndet werden warum man sich f r die gew hlte Alternative entschie den hat Die Beschreibung der L sung muss ausf hrlich genug sein dass Arbeitspakete f r die Implementierung gebildet und Entwickler die L sung implementieren k nnen Beim objektorientierten Entwurf wird die Dokumentation eine Beschreibung der Architektur aus dem Architekturentwurf enthalten ebenso Beschreibungen der ein zelnen Klassen mit ihren Schnittstellen und Interaktionen Hinzu kommen die Imple mentierungsvorgaben aus dem Komponentenentwurf Der IEEE Standard 1471 2000 empfiehlt eine Software Architektur aus verschiedenen Sichten zu beschreiben Dies hat auch schon Kruchten 1994 mit seinem 4 1 Sichten Modell zur Architekturbeschreibung vorgeschlagen Dort unterscheidet er die logi sche Sicht Klassenstruktur Prozess Sicht kommunizierende Prozesse Entwick lungssicht Organisation in Softwaremodule und physische Sic
95. spezielles Paket aufgefasst Daher gelten die in Abschnitt 5 3 2 fiir Pakete definierten Eigen schaften auch fiir S Im UML Modell ist S die einzige Instanz der Klasse Model 5 3 2 Paket Pakete gruppieren Klassen Interfaces und eingeschachtelte Pakete P ist die Menge aller Pakete die im System vorkommen einschlie lich S Attribute e name Name Der Name des Pakets e visibility VisibilityKind Sichtbarkeit des Pakets in Bezug auf den umschlie enden NameSpace also Paket oder System kann die Werte public protected und private annehmen Der Wert dieses Attributs wird aus dem Wert des Attributs visibility der Instanz der Assoziationsklasse ElementOwnership abgeleitet die zur Assoziation des Pakets mit seinem umschlie enden NameSpace geh rt Beziehungen e contains P x PUC UT Ein Paket enthalt ein Element Paket Klasse oder Interface Jedes Element in P C 5 3 Kern 49 und I muss in genau einem Paket enthalten sein mit Ausnahme von S das in kei nem Paket enthalten ist Die Komposition im UML Metamodell von ModelElement in NameSpace l sst sich als Relation formulieren contains p q gilt genau dann wenn eine Komposition zwischen p in der Rolle namespace und q in der Rolle ownedElement existiert 5 3 3 Interface I ist die Menge aller Interfaces die im System vorkommen Attribute e name Name Der Name des Interfaces e isAbstract Boolean Interfaces sind immer abstrakt Wert true e visibility V
96. und Kriterien fehlen aber in der Beschreibung Gewichte werden auch nicht genannt Es gibt zwar eine Diskus sion welche Metriken Einfluss auf welche Faktoren haben wie diese Einfl sse mit den Kriterien zusammenh ngen bleibt aber unklar Es wird nur gesagt dass alle f nf Kriterien f r jeden Faktor relevant sind 5 Die Metrik SI specialization index stammt von Lorenz und Kidd 1994 die brigen Metriken von Chidamber und Kemerer 1994 94 7 Entwurfsqualitat 746 Erni Erni 1996 sa Erni und Lewerentz 1996 definiert ebenfalls ein Qualit tsmodell nach dem FCM Schema Da das Modell zur Bewertung von Rahmenwerken dienen soll ist es auf den Bereich der Wiederverwendbarkeit beschrankt Die Ebene der Kri terien wird in zwei Ebenen aufgeteilt Entwurfsprinzipien und Entwurfsregeln Auf diese Weise kann das Modell die zugrunde liegenden Prinzipien und Regeln reflektie ren so dass die Messungen auch gleich Verst e gegen die Regeln und Prinzipien aufzeigen Falls die Werte bestimmter Metriken nicht im gew nschten Bereich liegen wird es dadurch f r den Entwerfer einfacher festzustellen was das Problem ist und was ge ndert werden sollte Abbildung 7 9 zeigt das resultierende Qualit tsmodell Qualit tsziel Faktor Entwurfsprinzip Entwurfsregel Metrik ffentl PR Rigorose 4 Verst e Kapselung __ gegen Demeter gesetz Modularat a Schmale ffentl Schnittstellen h Methoden Entkopplung paramet
97. verst ndlich sein Die Metrik soll pr zise definiert sein Die Metrik soll wiederholbar sein Die Metrik soll eindeutig sein und Vergleiche erlauben Die Metrik soll soweit wie m glich objektiv sein Die Metrik soll einfach und kosteneffektiv erhebbar sein am besten automatisch Der Zweck der Messung soll klar sein CON ODO OF FP WN Mm Die Metrik soll ein Interpretationsmodell haben das Aussagen dar ber macht was ein bestimmter Wert bedeutet 9 Die Metrik soll informativ sein d h Anderungen des Messwerts k nnen sinnvoll interpretiert werden 2 2 3 Qualit tsmetriken F r diese Arbeit sind Qualit tsmetriken besonders wichtig denn eine Bewertung der Entwurfsqualit t ist eine Qualit tsmetrik ebenso wie die bei der Bewertung als Zwi schenergebnisse verwendeten Metriken 2 2 Metriken 13 Definition 2 2 quality metric IEEE Std 1061 1992 A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which software possesses a given attribute that affects its quality Nach DeMarco 1982 gibt es zwei Kategorien von Qualit tsmetriken Ergebnismetri ken result metrics und Vorhersagemetriken predictor metrics Beide messen etwas Vorhandenes z B die Anzahl der bisher gefundenen Fehler im Code oder die Anzahl der Klassen im System aber mit unterschiedlicher Intention Ergebnismetriken machen eine Aussage Ober das Vorhandene
98. von Klassen erreicht Trenne Schnittstelle und Implementierung Eine Komponente soll aus einer Schnittstelle und einer Implemen tierung bestehen Die Schnittstelle soll nicht von der Implementie rung abh ngen so dass der Verwender nicht durch nderungen von Implementierungsdetails betroffen sein kann Vermeide Abh ngigkei ten von Details Martin 1996c Komponenten sollten nicht von Details i d R Implementierungs details abh ngig sein sondern von abstrakten Schnittstellen In der Objektorientierung bedeutet das dass die wesentlichen Abstraktio nen in Form von Interfaces oder abstrakten Klassen formuliert sind Tabelle 7 3 Taktische Prinzipien Abschnitt 1 von 2 86 7 Entwurfsqualitat Prinzip Sorge f r schmale Schnittstellen Martin 1996d Beschreibung In der Basisklasse sollen nur die f r die eigentliche Abstraktion ben tigten Methoden definiert sein Andere Aspekte sollten durch separate Schnittstellen z B durch Interfaces definiert werden die bei Bedarf von Subklassen zur Schnittstelle hinzugef gt werden k nnen Sorge f r lose Kopplung Stevens et al 1974 Kopplung ist ein Ma f r die St rke der Verbindung und damit der Abh ngigkeit von Komponenten untereinander Angestrebt wird eine m glichst lose Kopplung von Komponenten Damit steigt die Wahrscheinlichkeit dass nderungen sich nur lokal auf eine Kom ponente auswirken und dadurch nicht auf andere
99. welche Anforderungen Einfluss auf welche Entwurfsbestandteile haben Klasse Interface Bedingung Fragetext Antwortskala Gewicht auto Ist f r die Klasse klar f r welche Anforderungen 0 nein Se Anwendungsf lle sie eine Rolle spielt 1 ja es kann allerdings Klassen geben die nur aus Entwurfsgr nden vorhanden sind z B Adapter Klassen dann sollte mit ja geantwortet werden Fragebogen B 18 Verfolgbarkeit Klasse Interface Paket Bedingung Fragetext Antwortskala Gewicht auto Ist fur das Paket klar fur welche Anforderungen Anwendungsf lle es eine Rolle spielt Dies ist vor allem f r Pakete wichtig die Subsys teme repr sentieren Viele Pakete werden aller dings nur aus Entwurfsgr nden vorhanden sein z B zur bersichtlichen Gliederung dann sollte mit ja geantwortet werden 0 nein 1 ja KEK Fragebogen B 19 Verfolgbarkeit Paket 214 B Frageb gen f r QOOD System Fragetext Antwortskala EE Ist fur alle Anforderungen dokumentiert wo im Entwurf sie umgesetzt sind Bedingung Fragebogen B 20 Verfolgbarkeit System B 8 Wartbarkeit Die meisten Aspekte der Wartbarkeit sind bereits durch die Frageb gen der Kriterien abgedeckt Daher wird hier nach der nderbarkeit in Hinblick auf wahrscheinliche nderungen gefragt Die Frage ob sich die wahrscheinlichsten zuk nftigen nde rungen der Anforderungen leicht umsetzen lassen l sst sich am bes
100. whatever I like Dar aus eine einheitliche objektive Definition abzuleiten ist unm glich Allenfalls sind Mehrheitsentscheidungen denkbar die einen bestimmten Geschmack festlegen an dem sich Produkte orientieren m ssen um marktf hig zu sein Herstellungsbezogene Sicht Die herstellungsbezogene Sicht definiert die Qualit t eines Produkts ausgehend von seinem Entwurfs und Herstellungsprozess Im Blickpunkt stehen die feststehenden Anforderungen an das Produkt Quality is the degree to which a specific product conforms to a design or specification Gilmore 1974 Ein Produkt hat dann eine hohe Qualit t wenn seine Eigenschaften in hoher bereinstimmung mit den Anfor derungen stehen Crosby 1979 Jede Abweichung bedeutet einen Qualit tsverlust es entsteht Ausschuss oder der Bedarf f r Nacharbeit Hier k nnen die blichen Quali t tssicherungsma nahmen eingesetzt werden die versuchen solche Abweichungen zu erkennen oder besser noch sie gleich zu vermeiden Null Fehler Ziel Diese Qua lit tssicht ist typisch f r die Herstellung materieller Gegenst nde insbesondere in der Massenfertigung Kostenbezogene Sicht Die kostenbezogene Sicht geht noch einen Schritt weiter als die anderen Sichten Qua lit t wird hier auf der Grundlagen von Kosten und Preisen definiert Ein Produkt ist dann von hoher Qualit t wenn es die gew nschte Leistung zu einem akzeptablen Preis oder die gew nschte bereinstimmung mit den An
101. zwischen der Schnittstelle und der Implementierung der Abstraktion trennen Booch et al 1998 Die Klasse soll verst ndlich und einfach sein aber trotzdem erweiterbar und anpassbar Booch et al 1998 Die ffentliche Schnittstelle einer Klasse soll nur aus Operationen bestehen Korson McGregor 1990 Jede Methode einer Klasse soll Attribute der Klasse verwenden lesend oder schreibend Kor son McGregor 1990 Tabelle 7 4 Heuristiken Abschnitt 1 von 2 88 7 Entwurfsqualitat Heuristiken f r Interfaces Das Interface soll einfach aber trotzdem vollst ndig sein Booch et al 1998 Das Interface soll alle n tigen aber nicht mehr Operationen f r einen einzigen Dienst zur Ver f gung stellen Booch et al 1998 Das Interface soll verst ndlich sein d h es stellt gen gend Information zur Verwendung und zur Implementierung zur Verf gung Booch et al 1998 Das Interface soll zug nglich sein d h sein Verwender kann die Haupteigenschaften verstehen ohne durch eine Vielzahl von Operationen berw ltigt zu werden Booch et al 1998 Heuristiken f r Pakete Das Paket soll einen hohen Zusammenhalt haben d h eine Menge zusammengeh riger Ele mente enthalten Booch et al 1998 Das Paket soll mit anderen Paketen lose gekoppelt d h nur die Elemente die andere Pakete wirklich sehen m ssen exportieren und nur wirklich ben tigte Elemente aus anderen Paketen impor
102. 1 1 2 2 2 JO JO J0 JO JO JO Jo JO 2 Price 0 S 1 0 S 3 0 RegularPrice 0 1 1 0 1 NewReleasePrice f dE 1 1 d 1 ChildrensPrice 0 1 1 0 1 Tabelle 10 11 Objektive Klassenmetriken der Entw rfe A B und C Metrik SCCC SSTC SDCC SCOC SCSC I SDOC ISTRC SMAC Customer 9 9 9 19 9 9 7 8 8 J9 9 9 19 9 9 Ja 14 a JO JO JO I6 17 7 Rental 8 9 9 19 9 9 8 8 8 J9 9 9 J9 9 191414 a JO JO JO 7 18 8 Movie 8 8 8 19 9 9 9 9 8 J9 19 9 19 19 9 Ja 4 1a JO 10 JO I7 7 16 Price 19 J 19 J 9 J J 9 I 9 J 4 Jo f 8 RegularPrice 9 I J 8 I J 8 J 9 J 9 I 4 J O0 17 NewReleasePrice j 9 I 8 I 8 f J 9 J 9 J J4 I 10 J 7 ChildrensPrice 9 I J 8 I J J8F 9 J 9 J 4 J JO 17 Metrik Entwurf A Entwurf B 2 4 3 0 Entwurf C 2 5 7 0 0 Entwurf A Entwurf B 8 9 9 4 0 7 Entwurf C 8 9 9 4 0 6 Entwurf C alt Tabelle 10 14 Subjektive Systemmetriken der Entw rfe A B und C erbungshierarchie verschlechtert sich auch die Strukturiertheit SSTS Insgesamt ver schlechtert sich damit die Wartbarkeit SMAS Im Vergleich zu Entwurf B schneidet Entwurf C damit schlechter ab 150 10 Ein spezifisches Qualit tsmodell Nur eine sehr muste
103. 10 8 Das allgemeine Qualit tsmodell e Methode Attribut Eine Methode greift lesend oder schreibend auf ein Attribut zu Durch den Zugriff ergibt sich implizit eine Kopplung zwischen den Klassen welche die Methode bzw das Attribut enthalten e Operation Klasse Eine Operation besitzt einen Parameter oder eine R ckgabe von einem Klassentyp Dadurch ergibt sich wiederum eine implizite Kopplung zwi schen der Klasse mit der Operation und der Klasse des Parameters bzw der R ck gabe e Klasse Klasse Vererbung Eine Klasse erbt von einer anderen Klasse Faktisch werden s mtliche Kopplungen der Oberklasse ebenfalls geerbt Durch Redefinition einer Methode k nnten zwar Kopplungen durch Methodenaufruf oder Attributzu griff wegfallen dies ist allerdings in der Praxis eher unwahrscheinlich e Klasse Klasse Assoziation Es gibt eine gerichtete Assoziation der Klasse mit der anderen Klasse e Paket Paket Die explizite oder implizite Kopplung von Klassen bertr gt sich als implizite Kopplung auf die Pakete in denen die Klassen liegen Diskussion Angestrebt wird eine hohe Entkopplung der Komponenten Das bedeutet zum einen eine m glichst geringe Anzahl von Verbindungen zwischen Komponenten zum anderen bei den vorhandenen Verbindungen eine m glichst schwache Kopplungsart Entkopplung erh ht die Wahrscheinlichkeit dass nderungen sich nur lokal auf eine Komponente auswirken und nicht auf andere Komponenten ausstrahlen Wellen
104. 2 Realisierbarkeit Definition Der Entwurf ist realisierbar wenn er vom vorgesehenen Personal in technischer und organisatorischer Hinsicht mit dem vorgesehenen Aufwand implementiert werden 8 7 Testbarkeit 115 kann Technische Aspekte sind z B die Zielplattformen die einzusetzenden Hilfsmit teln Werkzeuge Programmiersprachen etc und die zu verwendenden Komponen ten Hard und Software Wenn also zwei zu verwendende Komponenten unvertr g lich sind ist der Entwurf aus technischen Grtinden nicht realisierbar Der Entwurf muss auch auf die entwickelnde Organisation passen Diese muss tiber die Ressour cen verf gen um die L sung zu realisieren z B gen gend Entwickler mit dem not wendigen Wissen z B ber Methoden Programmiersprachen Werkzeuge und den Anwendungsbereich und die notwendigen Werkzeuge Rechner Entwicklungswerk zeuge Ansonsten ist der Entwurf aus organisatorischen Gr nden nicht realisierbar Diskussion Ein L sungsvorschlag ist v llig wertlos wenn er nicht realisiert werden kann Des halb muss die Realisierbarkeit vollst ndig sichergestellt sein Um realisierbar zu sein muss der Entwurf in sich widerspruchsfrei also konsistent sein Ein bereits genann tes Beispiel f r eine Inkonsistenz sind zwei miteinander unvertr gliche Komponen ten was sp testens bei der Integration zu Problemen f hren wird Ein anderes Bei spiel ist eine Schnittstelle einer Komponente die nicht m chtig genug ist u
105. 225 Die Bewertung zeigt Probleme auf l st sie aber nicht Card Glass 1990 H ufig ist jedoch die Problembehebung viel schwieriger als die Problementdeckung insbeson dere f r Entwurfsanf nger deren Wissen ber alternative L sungsans tze beschr nkt ist In der Literatur werden einige Verbesserungsmafsnahmen in Form von Transfor mationen vorgeschlagen z B unit operations f r die Architektur von Bass et al 1998 Problem L sungs Muster von Page Jones 1995 Transformationsmuster von Riel 1996 oder Refaktorisierungen von Fowler et al 1999 Diese k nnen dem Ent werfer in aufbereiteter Form zug nglich gemacht werden Schlie lich kann auch noch auf Entwurfsmuster hingewiesen werden deren Verwendung ebenfalls eine L sung sein kann Entwurfsbewertung und verbesserung sind eng miteinander verkn pft Wie schon in Abschnitt 11 2 2 angedeutet gibt es Sinn bereits bei der Identifikation von Problemen in der Bewertung auf geeignete Verbesserungsma nahmen hinzuweisen Unter Ver wendung von QOOD k nnen die Verbesserungsma nahmen nach ihren Auswirkun gen auf die einzelnen Kriterien und Ebenen klassifiziert werden so dass klar ist wel che Ma nahmen betrachtet werden sollten wenn z B die Entkopplung auf Paketebene niedrig ist Au erdem k nnen so positive und negative Auswirkungen der Ma nahmen auf andere Kriterien dokumentiert werden Hat sich der Entwerfer f r eine Verbesserungsma nahme oder ein B ndel von Ma
106. 4 Quibeldey Circel 1999 Quibeldey Circel K Entwurfsmuster Design Patterns in der objektorientierten Softwaretechnik Springer Berlin 1999 Rei ing 2001a Rei ing R Towards a Model for Object Oriented Design Measure ment Proceedings of the 5th International ECOOP Workshop on Quantitative Approaches in Object Oriented Software Engineering QAOOSE 2001 Budapest 2001 71 84 Rei ing 2001b Rei ing R The Impact of Pattern Use on Design Quality Position Paper Workshop Beyond Design Patterns mis used at OOPSLA 2001 Rei ing 2002 Rei ing R Entwurfsregeln f r den objektorientierten Entwurf http www informatik uni stuttgart de ifi se service design_rules index html Version vom 11 01 2002 Rentsch 1982 Rentsch T Object Oriented Programming ACM SIGPLAN Notices 17 9 1982 51 57 Riel 1996 Riel A Object Oriented Design Heuristics Addison Wesley Reading MA 1996 183 Rising 2000 Rising L The Pattern Almanac 2000 Addison Wesley Reading MA 2000 Rittel Webber 1984 Rittel H Webber M Planning Problems are Wicked Prob lems In Cross N Hrsg Developments in Design Methodology Wiley London 1984 143 159 Robbins 1998 Robbins J Design Critiquing Systems Technical Report UCI 98 41 University of California Irvine 1998 Robbins Redmiles 1999 Robbins J Redmiles D Cognitive Support UML Adher ence and XMI Interchange in Argo UML Proceedings o
107. 88 entwickelt Das Vorgehen nach GQM l sst ein spezifisches Qualit tsmodell entstehen das aus den Qualit tszie len des Unternehmens oder des Projekts abgeleitet ist Zuerst werden die Qualit ts ziele goals erhoben Anschlie end werden Fragestellungen questions formuliert die sich aus den Zielen ergeben Zum Schluss werden diejenigen Metriken metrics festgelegt welche die Frage beantworten sollen Das resultierende Qualit tsmodell besteht nicht aus Qualit tsattributen sondern aus der Hierarchie von Zielen Fragestellungen und Metriken Das GQM Modell kann besser zur Aufgabe passen da Qualit tsziele vielschichtiger sein k nnen als Quali t tsattribute Ein Ziel besteht n mlich aus drei Dimensionen dem Objekt dem Quali t tsattribut und dem Blickwinkel Rombach 1993 Die Vorgehensweise der Entwick lung eines Qualit tsmodells nach GOM ist aufgrund ihrer Offenheit allerdings sehr schwierig Um diesen gewichtigen Nachteil abzumildern werden f r jeden Schritt umfangreiche Hilfestellungen in Form von Schablonen Richtlinien und Prinzipien angeboten Daskalantonakis 1992 1994 stellt fest dass GOM erst ab den Stufen zwei oder drei des Capability Maturity Model funktioniert Da sich der Gro teil aller Orga nisationen noch auf Stufe eins befindet Baumert 1991 ist GQM folglich in vielen F llen nicht anwendbar 6 3 Qualitatssicherung 69 6 2 4 Fazit Die generischen Qualit tsmodelle geben ein unspezifisches Qualit
108. 95 W rthele V Checklisten f r die Software Bearbeitung Diplomar beit Nr 1299 Fakult t f r Informatik Universit t Stuttgart 1995 186 Literatur Yau Tsai 1986 Yau S Tsai J A Survey of Software Design Techniques IEEE Transactions on Software Engineering 12 6 1986 713 721 Yourdon 1995 Yourdon E When Good Enough Software is Best IEEE Software 12 3 1995 79 81 Yin Winchester 1978 Yin B Winchester J The Establishment and Use of Mea sures to Evaluate the Quality of Software Designs Proceedings of the Software Quality and Assurance Workshop Software Engineering Notes 3 5 1978 45 52 Zuse 1994 Zuse H Complexity Metrics In Marciniak J Hrsg Encyclopedia of Software Engineering Wiley New York 1994 131 165 Zweben et al 1995 Zweben S Edwards S Weide B Hollingsworth J The Effects of Layering and Encapsulation on Software Development Cost and Quality IEEE Transactions on Software Engineering 21 3 1995 200 208 187 Akronyme Allgemeine Akronyme CMM DGQ DIN FCM COM IEC IEEE ISO MOOSE OCL ODEM OMG OOA OOD QFD QOOD UML XMI XML Capability Maturity Model Deutsche Gesellschaft f r Qualit t Deutsches Institut f r Normung Factors Criteria Metrics Goal Question Metric International Electrotechnical Commision Institute of Electrical and Electronical Engineers International Organization for Standardization Metrikenwerkzeug f r den ob
109. 98 S 30 Definition Kopplung coupling vgl Stevens et al 1974 ist ein Ma f r die St rke der Verbin dung und damit der Abh ngigkeit von Komponenten untereinander Entkopplung ist das Gegenteil von Kopplung Obwohl Kopplung der in der Literatur normaler weise verwendete Begriff ist wurde hier der Begriff Entkopplung gew hlt damit ein hoher Erf llungsgrad hohe Qualit t impliziert In der Objektorientierung kann die Kopplung zun chst in drei verschiedene Arten unterschieden werden Li 1992 e Kopplung durch Vererbung Eine Unterklasse ist durch das Erben von Eigenschaf ten mit ihrer Oberklasse gekoppelt Jede Anderung der Oberklasse hat Auswirkun gen auf die Unterklasse e Kopplung durch Methodenaufruf Jeder Methodenaufruf durch andere Klassen und jeder Aufruf von Methoden anderer Klassen erh ht die Kopplung e Kopplung durch Datenabstraktion Die Verwendung anderer Klassen als Typ von Attributen erh ht die Kopplung Betrachtet man diese Arten genauer stellt man fest dass es insgesamt folgende Kopp lungsarten im objektorientierten Entwurf gibt e Methode Operation Eine Methode ruft eine Operation oder einen Konstruktor Destruktor auf Es ergibt sich eine Kopplung in Richtung des Aufrufs implizit ent steht auch eine Kopplung zwischen den Klassen welche die Methode bzw die Operation enthalten 1 Statt einer Klasse kann es auch ein Interface sein das gilt ebenso bei den anderen Kopplungsarten 1
110. 993 stellen ein Verfahren zur Entwicklung einer Metrik vor vgl Abbildung 2 3 Es besteht aus den folgenden Phasen 1 Problembestimmung Der Gegenstand das Original der Metrik sowie Zweck und Zielgruppe Pragmatik werden festgelegt Kapitel 1 2 Informales Modell Vorhandenes Wissen und Vermutungen aus dem Problembe reich werden gesammelt und daraus die relevanten Faktoren f r die Metrik abge leitet Kapitel 3 Kapitel 4 Kapitel 6 Kapitel 7 3 Formales Modell Die Abbildung der Eingabe auf die Ausgabe und die gew nschte Genauigkeit werden festgelegt Abbildungs und Verk rzungsmerkmal Au er dem werden Axiome aufgestellt die f r die Metrik gelten sollen Getroffene Annahmen werden dokumentiert Bei Bedarf wird die Metrik zur Verallgemeine rung um Modellparameter erweitert Kapitel 5 Kapitel 8 Kapitel 9 14 2 Modelle und Metriken Problembestimmung Informales Modell Formale Modelle und Axiome Le Theoretische Validierung ei Empirische Validierung ken Anwendung Neue Modelle Hypothesen Abbildung 2 3 Verfahren zur Entwicklung von Metriken nach Shepperd Ince 1993 S 79 4 Theoretische Validierung Es wird berpr ft ob die postulierten Axiome f r die Metrik gelten Anhang A 5 Empirische Validierung Es wird empirisch berpr ft ob die Metrik tats chlich die Anforderungen aus der Problembestimmung erf llt Kap
111. Anforderungen instabil sind Der h ufigste Fall ist dabei nicht die nderung einer bestehenden Anforderung sondern neu hinzukommende Anforderungen die sich nach und nach einschleichen creeping requirements Anderungen in den Anforderungen ziehen aber unter Umst nden tief greifende nderungen im Entwurf nach sich F r den Umgang mit unklaren Anforderungen empfiehlt sich die Erstellung von Pro totypen Bei besonders unklaren oder instabilen Anforderungen ist ein inkrementeller oder evolution rer Entwicklungsprozess am besten geeignet bei dem der Entwurf erst nach und nach entsteht und in der Regel mehrfach berarbeitet wird 4 5 2 konomische Zw nge Das Entwurfsproblem wird durch konomische Vorgaben noch versch rft Projekte verlaufen fast immer unter Zeitdruck der auch in der Entwurfsphase pr sent ist Da Nachdenken Zeit erfordert findet es deshalb oft nicht oder nur in geringem Ma e statt Was auch wegf llt ist die Dokumentation des Entwurfs und der berlegungen die hinter dem Entwurf stehen design rationale Fehlt die Dokumentation ist sie unvollst ndig oder veraltet wird sie aber in der Implementierung und Wartung nicht verwendet werden was schlie lich zu einer unverst ndlichen Struktur des Codes f hrt Neben dem Zeitdruck gibt es auch noch den Kostendruck weshalb die durch den Entwurf verursachten Kosten beachtet werden m ssen Dazu geh ren z B die Kosten f r ben tigte Hardware Software und Pers
112. Attribute des durch sie repr sentierten Originals sondern nur solche die den jeweiligen Modellerschaffern und oder Modellbenutzern relevant erscheinen Stachowiak 1973 S 132 Die Abbildung des Originals auf das Modell ist in der Regel kein Isomorphismus Es k nnen Attribute weggelassen werden Verk rzung Die weggelassenen Attribute hei en pr terierte Attribute vgl Abbildung 2 1 Andererseits k nnen auch Attribute dem Modell hinzugef gt werden die keine Entsprechung im Original haben abun dante Attribute Beispielsweise enth lt der Code als Modell des Entwurfs einige Attribute die nicht aus dem Entwurf abgeleitet wurden sondern durch die gew hlte Programmiersprache erforderlich wurden Abbildungs pr terierte abundante Abbildungs vorbereich Attribute Attribute nachbereich Attributen abbildung Original Modell Abbildung 2 1 Original Modell Abbildung nach Stachowiak 1973 S 157 Pragmatisches Merkmal Modelle sind ihren Originalen nicht per se eindeutig zugeordnet Sie erf llen ihre Ersetzungs funktion a f r bestimmte erkennende und oder handelnde modellbenutzende Subjekte b innerhalb bestimmter Zeitintervalle und c unter Einschr nkungen auf bestimmte gedankliche oder tats chliche Operationen Stachowiak 1973 S 132 Die Modellbildung ist kein zweckfreier Vorgang sondern es liegt immer eine Absicht zugrunde Die Modellbildung erfolgt also auf Grund von pragmatischen Erw gun gen
113. Bewertung der Qualitat objektorientierter Entwurfe Von der Fakult t Informatik der Universit t Stuttgart zur Erlangung der W rde eines Doktors der Naturwissenschaften Dr rer nat genehmigte Abhandlung Vorgelegt von Ralf Rei ing aus Waiblingen Hauptberichter Prof Dr rer nat J Ludewig Mitberichter Prof Dr Ing G Snelting Tag der m ndlichen Pr fung 15 08 2002 Institut f r Informatik der Universit t Stuttgart 2002 Danksagung An dieser Stelle m chte ich allen danken die zum Gelingen dieser Arbeit beigetragen haben Der gr te Dank geb hrt meinem Doktorvater Prof Jochen Ludewig dessen Anregungen und Kritik viel zur Arbeit beitragen haben Prof Gregor Snelting danke ich f r die bereitwillige bernahme des Zweitgutachtens Dank auch den Kollegen der Abteilung Software Engineering f r ein gutes Arbeits klima und er entmutigende Gespr che ber haltbare unhaltbare Zeitpl ne zur Pro motion Christoph Schmider danke ich f r die Implementierung des Werkzeugs MOOSE im Rahmen seiner Diplomarbeit Eckart Mayer Jan B hm und Phillip M ller sei gedankt f r ihre kritische Durchsicht der Rohfassung Zum Schluss ein Dank an alle die sich mehr oder weniger regelm ig nach dem Fort schritt der Arbeit erkundigt haben und immer dieselbe Auskunft bekamen Dass sie noch nicht fertig sei Diese Anteilnahme trug viel zur Motivation bei die Arbeit abzu schlie en Zusammenfassung In der Software
114. Diese Metrik soll den Zusammenhalt von Klassen inner halb eines Pakets erfassen Weil die Klassen innerhalb eines Pakets eng verwandt sein sollen soll der Zusammenhalt hoch sein H ist definiert als R 1 N wobei R die Anzahl der Beziehungen zwischen Klassen innerhalb des Pakets ist und N die Anzahl der Klassen Die folgende Definition z hlt gegenseitige Abh ngigkeiten zweimal je einmal f r jede Richtung Die Zahl der Interfaces Metrik NIP wird zur Zahl der Klassen Metrik NCP hinzugez hlt H p LU e CUI contains p c Xde CUI c contains p d depends_on c d weight 1 NCP p NIP p Afferent Coupling C Die Anzahl der Klassen aus anderen Paketen die von den Klassen im Paket abh ngen Die afferente Kopplung soll niedrig sein C p de CUI contains p d A Ace CUI contains p c A depends_on d c Efferent Coupling C Die Anzahl der Klassen aus anderen Paketen von denen Klassen im Paket abh ngen Die efferente Kopplung soll niedrig sein C p de CUI contains p d A Ace CUI contains p c A depends_on c d Abstractness A Die Abstraktheit eines Pakets ist definiert als das Verh ltnis von abstrakten Klassen Metrik NCP zu der Gesamtzahl der Klassen Martin erw hnt keine Interfaces sie werden hier zu den abstrakten Klassen dazugez hlt Der Spezial fall eines Pakets ohne Klassen von Martin nicht erw hnt soll eine Abstraktheit von 1 haben Solche leeren Pakete sind sinnvoll f r die S
115. FC und LCOM genau genommen eher um Code Metriken als um Entwurfsmetriken ODEM ist sehr gut zur Definition von Metriken f r den objektorientierten Entwurf geeignet sofern sich die ben tigte Information aus UML Modellen insbesondere aus Klassendiagrammen gewinnen l sst Das belegt auch die erfolgreiche Nutzung von ODEM in dieser Arbeit bei der Definition der Metriken von QOOD vgl Anhang A 59 Kapitel 6 Softwarequalitat Quality you know what it is yet you don t know what it is But that s self contradictory But some things are better than others that is they have more quality But when you try to say what the quality is apart from the things that have it it all goes poof There s nothing to talk about But if you can t say what Quality is how do you know what it is or how do you know that it even exists If no one knows what it is then for all practical purposes it doesn t exist at all But for all practical purposes it really does exist What else are the grades based on Why else would people pay fortunes for some things and throw others in the trash pile Obviously some things are better that others but what s the betterness So round and round you go spinning mental wheels and nowhere finding anyplace to get traction What the hell is Quality What is it Pirsig 1981 S 163f In diesem Kapitel wird der Qualit tsbegriff erst allgemein und dann spezifisch f r Software diskutiert Softwa
116. Fahrzeit ist die Zeit vom Einsteigen Losfahren an der einen Halte stelle bis zum Aussteigen Ankommen an der anderen Haltestelle fr hestm glicher Startzeitpunkt Der fr hestm gliche Startzeitpunkt ist der Start zeitpunkt den der Fahrgast bei einer Abfrage angibt Die Verbindung darf zu diesen oder einem sp teren Zeitpunkt starten Haltestelle Eine Haltestelle ist ein Ort den ein Zug einer Linie bei seiner Fahrt anf hrt Fahrg ste k nnen den Zug nur an Haltestellen betreten oder verlassen Hal testellen werden eindeutig durch ihren Namen gekennzeichnet Au er an Endhalte stellen sind Ankunftszeit und Abfahrtszeit eines Zuges an einer Haltestelle identisch Linie Eine Linie bestimmt sich durch ihren Namen die Liniennummer aus einer Menge von Haltestellen die von den Z gen der Linie angefahren werden sowie den Fahrzeiten zwischen den einzelnen Haltestellen und den Abfahrtszeiten an den bei den Endhaltestellen Die Haltestellen sowie die Fahrzeiten sind konstant Jede Linie hat f r jede ihrer Fahrten die gleichen Endhaltestellen Liniennummer Eindeutiger Name einer Linie z B S1 U14 Optimierungsziel Vorgabe f r die Auswahl einer m glichen Verbindung Es kann die Verbindung mit der fr hestm glichen Ankunftszeit mit der k rzesten Fahrtzeit oder mit den wenigsten Umsteigehaltestellen als Optimierungsziel gew hlt werden Servicetechniker Der Servicetechniker ist ein Mitarbeiter des Verkehrsbetriebs der die Fahrpl
117. Frage zu Beginn der Frageb gen 212 B Frageb gen f r QOOD Klasse Interface Bedingung Fragetext Antwortskala Gewicht auto Sind alle Dokumentationsstandards eingehalten 0 nein KE worden 1 ja Ist dokumentiert wie die Klasse das Interface ver 0 nein Zx wendet wird 1 ja Ist dokumentiert welche Bedingungen die Imple 0 nein BER mentierung erf llen muss 1 ja z B Beschreibung der Semantik durch Zust nde und Klasseninvarianten Beschreibung des Zusammenspiels von Operationen Ist die Klassen Interface Dokumentation struktu 0 nein ax riert vollst ndig pr zise konsistent und korrekt 1 ja Ist der Name der Klasse des Interfaces geeignet 0 nein ce 1 ja thiseC Sind die Attributnamen geeignet 0 nein Got 1 ja NOC this Ist f r jede Operation dokumentiert wie sie ver 0 nein FER gt 0 wendet wird 1 ja NOC this Ist f r jede Operation dokumentiert welche O nein BER gt 0 Bedingungen die Implementierung erf llen 1 ja muss z B Beschreibung der Semantik durch Vor und Nachbedingungen NOC this Sind die Operationennamen geeignet 0 nein eR gt 0 1 ja NOC this Sind die Parameternamen geeignet 0 nein W gt 0 1 ja Sind alle Namen in der Klasse im Interface so 0 nein unterschiedlich dass keine Verwechslungsgefahr 1 ja besteht Fragebogen B 15 Dokumentierung Klasse Interface
118. Fragen enthalten e selbsterkl rungsf hig um ohne zus tzliche Dokumentation verwendbar zu sein e neutral um eine Beeinflussung der Antwort durch die Fragestellung auszuschlie en sowie e verst ndlich und pr zise formuliert um Missverst ndnisse und Interpretations spielr ume zu vermeiden Spezielle Anforderungen an die Frageb gen sind hier e relevant d h es besteht ein positiver oder negativer Zusammenhang der Fragen mit dem Kriterium e entscheidbar d h die Fragen sind eindeutig zu beantworten optimal sind in die ser Hinsicht eindeutige Ja Nein Fragen e auswertbar d h aus den Antworten l sst sich eine Bewertung ableiten e hinreichend d h die Fragen liefern eine gr tm gliche Uberdeckung des Kriteri ums und e redundanzfrei d h die Fragen berlappen sich inhaltlich nicht 9 4 2 Beschreibung Ein Fragebogen besteht aus einer Liste von Fragen Jede Frage setzt sich hier aus f nf Teilen zusammen Bedingung Gibt an ob die Frage im aktuellen Kontext angewendet werden kann Die meisten Fragen sind zwar immer anwendbar es gibt aber z B auf der Ebene Klasse Interface Fragen die nur bei Interfaces sinnvoll sind Die Bedingung kann unter Verwendung der Elemente von ODEM und der objektiven Metriken als Pr di kat formuliert werden Auf diese Weise kann die Anwendbarkeit der Frage automa tisch entschieden werden Fragetext Die eigentliche Fragestellung ggf mit Kommentar zur Pr zisierung
119. Fragenlisten publiziert die den blichen Krite rien f r Checklisten nicht entsprechen z B k nnen nicht alle Fragen eindeutig mit ja oder nein beantwortet werden W rthele 1995 Als Beispiel folgt ein Auszug aus einer Fragenliste f r den objektorientierten Entwurf von Page Jones 1995 S 325 ff die vom Autor als Checkliste bezeichnet wird 7 Does the class rely on any assumptions in order to work correctly Do any other classes also rely on the same assumptions How likely are those assumptions to change Where are the assumptions documented 13 Is the class s invariant documented 15 Does each of the class s methods have a documented pre and postcondition 22 Do subclasses of a common superclass contain similar or identical features that should be moved to the superclass 40 Is the class too restrictive for its current purpose that is the applications in which it s likely to be used 41 Is the class too general or broad for its current purpose In other words does the class con tain a lot of unnecessary baggage based on fantasy rather than firm requirements 46 Does the design fulfill the spec the whole spec and nothing but the spec 48 What are the most likely changes that the user will make to the system requirements How much impact would each one make on the design Would it cost a great deal to carry out any of the more minor changes 51 Can the design actually be coded Will it work Abbild
120. IN 55350 Teil 12 Deutsches Institut f r Normung e V DIN 55350 Teil 12 Mrz 1989 Begriffe der Qualit tssicherung und Statistik Teil 12 Merkmalsbezogene Begriffe 1989 DIN EN ISO 8402 Deutsches Institut f r Normung e V DIN EN ISO 8402 1995 08 Qualit tsmanagement Begriffe 1995 175 Di mann 1990 Difsmann S Anforderungsfl sse in der Software Entwicklung als Grundlage f r die Qualit tssicherung Forschungsbericht Nr 362 1990 Fachbereich Informatik Universitat Dortmund 1990 Dorner 1976 Dorner P Probleml sen als Informationsverarbeitung Kohlhammer Stuttgart 1976 Dromey 1996 Dromey R Cornering the Chimera IEEE Software 13 1 1996 33 43 Dumke 2000 Dumke R Erfahrungen in der Anwendung eines allgemeinen objek torientierten Measurement Framework In Dumke R Lehner F Hrsg Software Metriken Gabler Wiesbaden 2000 71 93 Dunn 1984 Dunn R Software Defect Removal McGraw Hill New York 1984 Dunsmore et al 2000 Dunsmore A Roper M Wood M Object Oriented Inspec tion in the Face of Delocalisation Proceedings of the 22nd International Conference on Software Engineering Limerick ACM Press New York 2000 467 476 Dvorak Moher 1991 Dvorak J Moher T A Feasibility Study of Early Class Hier archy Construction in Object Oriented Development Empirical Studies of Program mers Fourth Workshop Ablex Norwood NJ 1991 23 35 El Emam Melo 2001 El Emam K
121. J Hrsg Quality Control Handbook 3 Auflage McGraw Hill New York 1974 Kafura 1998 Kafura D Object Oriented Software Design and Construction with C Prentice Hall Upper Saddle River NJ 1998 Kernighan Plauger 1974 Kernighan B Plauger P The Elements of Programming Style McGraw Hill New York 1974 Kitchenham 1990 Kitchenham B Software Metrics In Rook P Hrsg Software Reliability Handbook Elsevier London 1990 Kitchenham et al 1990 Kitchenham B Pickard L Linkman S An Evaluation of Some Design Metrics Software Engineering Journal 5 1 1990 50 58 179 Koenig 1995 Koenig A Patterns and Antipatterns Journal of Object Oriented Pro gramming 8 1 1995 46 48 Kogure Akao 1983 Kogure M Akao Y Quality Function Deployment and CWOC in Japan Quality Progress October 1983 Kohler et al 1998 Kohler G Rust H Simon F An Assessment of Large Object Oriented Software Systems Proceedings of the Object Oriented Product Metrics Workshop at ECOOP 98 Montreal 1998 36 41 Kolewe 1993 Kolewe R Metrics in Object Oriented Design and Programming Soft ware Development October 1993 53 62 Korson McGregor 1990 Korson T McGregor J Understanding Object Oriented A Unifying Paradigm Communications of the ACM 33 9 1990 40 60 KPMG 1995 KPMG Runaway Projects Causes and Effects Software World UK 26 3 1995 Kriz 1988 Kriz J Facts
122. Komponenten ausstrahlen Sorge f r hohen Zusammenhalt Stevens et al 1974 Zusammenhalt Koh sion ist ein Ma f r die St rke der Zusam mengeh rigkeit von Bestandteilen einer Komponente Angestrebt wird ein m glichst hoher Zusammenhalt der Bestandteile Damit steigt die Wahrscheinlichkeit dass bei einer nderung in der Regel nur eine Komponente betroffen ist da alle Aspekte einer Abstrak tion an einem Ort zusammengefasst sind Module sollen offen und geschlossen sein Open Closed Principle Meyer 1997 S 57 Martin 1996a Geschlossen bedeutet Das Modul kann gefahrlos verwendet wer den da seine Schnittstelle stabil ist d h sich nicht mehr ndert Offen dagegen bedeutet Das Modul kann problemlos erweitert werden Das scheint zun chst widerspr chlich zu sein ist aber reali sierbar Eine abstrakte Oberklasse oder ein Interface realisiert eine stabile geschlossene Schnittstelle Konkrete offene Unterklassen implementieren sie und k nnen sie bei Bedarf erweitern Sorge bei Redefinition f r den Erhalt der Semantik Liskov Substitution Prin ciple Liskov 1988 Martin 1996b Jede Unterklasse U einer Klasse K muss f r die durch K gegebene Schnittstelle dieselbe Semantik anbieten Nur dann kann man bei der Verwendung der Schnittstelle einer Klasse sichergehen dass sich das Programm gleich verh lt wenn an Stelle einer Instanz von K eine Instanz von U verwendet wird Minimiere die Anza
123. Melo W Machado J The Prediction of Faulty Classes Using Object Oriented Design Metrics Journal of Systems and Software 56 1 2001 63 75 Erni 1996 Erni K Anwendung multipler Metriken bei der Entwicklung objektori entierter Frameworks Krehl Verlag M nster 1996 Erni Lewerentz 1996 Erni K Lewerentz C Applying Design Metrics to Object Oriented Frameworks Proceedings of the 3rd International Software Metrics Sympo sium IEEE Computer Society Press Los Alamitos CA 1996 64 74 Evans Marciniak 1987 Evans M Marciniak J Software Quality Assurance and Management Wiley New York 1987 Fayad et al 1999 Fayad M Schmidt D Johnson R Hrsg Building Application Frameworks Object Oriented Foundations of Framework Design Wiley New York 1999 Fenton Pfleeger 1996 Fenton N Pfleeger S Software Metrics A Rigorous amp Prac tical Approach 2 Auflage Thomson Computer Press London 1996 Fetcke 1995 Fetcke T Softwaremetriken bei objektorientierter Programmierung GMD Studien Band 259 Gesellschaft f r Mathematik und Datenverarbeitung mbH GMD Sankt Augustin 1995 Fichman Kemerer 1992 Fichman R Kemerer C Object Oriented and Conven tional Analysis and Design Methodologies Comparison and Critique IEEE Computer 25 10 1992 22 39 Firesmith 1995 Firesmith D Inheritance Guidelines Journal of Object Oriented Programming 8 2 1995 67 72 Fowler 2001a Fo
124. Modelle Metamodelle Modelle Entwurf konkreter Entwurf Reduktion UML Metamodell UML Modell Reduktion w bau S ODEM reduziertes Modell gt Qualit tsattribute L und Metriken OOOD allgemeines Qualit tsprofil individuelle Qualit tssicht MyQOOD spezifisches Qualitatsprofil y Abbildung 1 1 Verfahren f r die Entwurfsbewertung Der konkrete Entwurf ist der eigentliche Gegenstand der Bewertung Er enth lt unter anderem UML Diagramme Die in den UML Diagrammen enthaltene Information das UML Modell ist eine Instanz des UML Metamodells Der konkrete Entwurf kann also auf ein UML Modell reduziert werden Die Reduktion stellt bereits eine Wertung dar da die weggelassenen Informationen keinen Einfluss mehr auf die Bewertung haben k nnen Aus der Entwurfsinformation im UML Modell wird der Teil ausgew hlt der f r die Entwurfsbewertung als relevant angesehen wird Durch diese Auswahl erh lt man das reduzierte Modell des Entwurfs Das zugrunde liegende Metamodell hei t Object Oriented Design Model ODEM ODEM beschr nkt sich auf statische Ent wurfsinformation die aus Klassendiagrammen gewonnen werden kann z B welche Klassen vorhanden sind und welche Beziehungen diese untereinander haben 1 4 Ubersicht 5 Das allgemeine Qualit tsmodell Quality Model for Object Oriented Design QOOD ordnet Entwur
125. Momentan ist in QOOD nur ein Faktor die Wartbarkeit quantifiziert daher ist die Auswahl und Gewichtung trivial Sind mehrere Faktoren vorhanden orientiert sich die Gewichtung an den konkreten Qualit tsanforderungen Aus diesem Grund ist es schwierig allgemein g ltige Regeln f r die Wahl der Gewichte anzugeben Kriterien Gleiches gilt f r die Wahl der Gewichte der Kriterien f r den Bewertungsvorschlag f r die subjektive Metrik eines Faktors da auch hier die konkreten Qualit tsanforde rungen die wichtigste Rolle spielen Aus der Erfahrung heraus lassen sich f r die Kri terien des Faktors Wartbarkeit allerdings Faustregeln angeben e Knappheit und Entkopplung werden allgemein als die wichtigsten Einflussfakto ren angesehen also sollten ihre Gewichte relativ hoch sein e Zusammenhalt ist das wichtigste semantische Kriterium im Vergleich zu Doku mentierung und Einheitlichkeit sollte also ein h heres Gewicht erhalten Objektive Metriken Schwellenwerte Der Schwellenwert ist eine gerade noch akzeptabler Grenzwert f r eine Metrik Bei positiv korrelierten Metriken ist er eine Untergrenze bei negativ kor relierten Metriken eine Obergrenze Vorschl ge f r allgemein g ltige Schwellenwerte sind in der Literatur u erst selten Meistens wird nur gesagt dass die Schwellen werte projektspezifisch festgelegt werden m ssen In Tabelle 9 3 sind die vorhande nen Vorschl ge bertragen auf die objektiven Metriken aus QOOD zus
126. Sorge f r intellektuelle Kontrolle Witt et al 1994 Sowohl die Entwickler als auch die Wartungsprogrammierer sollen in der Lage sein den Entwurf vollst ndig zu verstehen Dies wird durch hierarchische Strukturierung Abstraktion und Einfachheit der einzelnen Komponenten erleichtert Au erdem muss der Entwurf gut dokumentiert sein Minimiere den intellektu ellen Abstand Structural Correspon dence Jackson 1975 Der intellektuelle Abstand ist der Unterschied z B in der Struktur zwischen dem Problem und der Software L sung Um einen gerin gen intellektuellen Abstand zu erreichen sollten sich die relevanten Begriffe der Problemwelt in der Regel die reale Welt m glichst ori ginalgetreu in der L sung wiederfinden Stelle konzeptionelle Inte grit t her Witt et al 1994 Konzeptionelle Integrit t bedeutet dass der gesamte Entwurf einem einheitlichen Stil folgen soll Der Entwurf soll am Ende so aussehen als sei er von einer einzigen Person geschaffen worden Verberge Realisierungs entscheidungen Geheimnisprinzip Par nas 1972b Alle Realisierungsentscheidungen sollen in Module gekapselt und so vor dem Rest des Systems verborgen werden Die Modulschnitt stelle soll also ber die innere Struktur m glichst wenig Auskunft geben Gerade bei Entscheidungen die sich wahrscheinlich ndern ist das hilfreich Minimiere die Komplexi t t Komplexit t erschwert das Verst ndnis und damit die
127. T Eine Klasse kann mit einer Klasse oder einem Interface assoziiert sein gerichtet durch Navigierbarkeit Eine Klasse kann beliebig viele andere Klassen assoziieren auch keine Eine Klasse kann sich auch selbst assoziieren Geerbte Assoziationen zahlen nicht mit Im UML Metamodell steht die Klasse Association fiir eine Assoziation Association hat mindestens zwei AssociationEnds in denen die Eigenschaften der Assoziation abgelegt sind Navigierbarkeit isNavigable Art der Assoziation aggregation asso ciates k l gilt genau dann wenn es eine Instanz a von Association gibt die zwei Instanzen el und e2 von AssociationEnd hat und wenn die Rolle e1 type mit k die Rolle e2 type mit 1 belegt ist Au erdem muss e2 isNavigable gelten d h es muss m glich sein von k nach ber die Assoziation zu navigieren Das Attribut e1 aggregation gibt die Art der Assoziation an none aggregate com posite und wird auf die Relation selbst bertragen Auf diese Weise kann durch das Attribut aggregation der associates Relation bei Bedarf zwischen normaler Asso ziation Aggregation und Komposition unterschieden werden Sofern eine Association mehr als zwei AssociationEnds hat wird sie in bin re Assozi ationen zerlegt Eine n re Assoziation kann so je nach Navigierbarkeit der Associ ationEnds in bis zu n n 1 2 bin re Assoziationen zerlegt werden 5 3 Kern 51 uses C x C UT Eine Klasse benutzt eine Klasse oder ein Interface E
128. abei um einen Fahrgast oder einen Servicetechniker handeln C 3 Begriffslexikon 225 Endhaltestelle Eine Endhaltestelle ist eine spezielle Haltestelle an der ein Zug einer Linie jede seiner Fahrten beginnt oder beendet Fahrgast Ein Fahrgast ist eine Person die die Iransportm glichkeiten eines Ver kehrsbetriebs nutzen m chte und auch nutzt Er ist der Benutzer des Fahrplanaus kunftsystems Er kann das Fahrplanauskunftssystem ausschlie lich im Fahrgast Modus nutzen Fahrgast Modus Zustand des Fahrplaninformationssystems In diesem Zustand k nnen Fahrg ste Verbindungen erfragen Fahrplan synonym zu Fahrplandaten Fahrplandatei Die Fahrplandatei ist eine Datei die die Fahrplandaten enth lt Fahrplandaten Die Fahrplandaten enthalten Informationen ber die Linien des Ver kehrsbetriebs Zu jeder Linie werden alle Haltestellen inklusive der beiden Endhalte stellen die Fahrzeiten zwischen den Haltestellen sowie die Abfahrtszeiten an den bei den Endhaltestellen Fahrzeiten zwischen diesen Haltestellen gespeichert Weiterhin m ssen alle Abfahrtszeiten an beiden Endhaltestellen einer Linie und der Name der Linie die Liniennummer eingetragen sein Fahrplaninformationssystem Das zu realisierende Software System zur Ermittlung von Verbindungen Fahrzeit Unter der Fahrzeit versteht man die Zeitdauer die ein Fahrgast oder ein Zug f r die Fahrt zwischen zwei Haltestellen ben tigt ein Fahrgast kann dabei auch umsteigen Die
129. af r zust ndig ist sie in den Entwurf einzubauen F r seine eigene Arbeit ist nderbarkeit und Verst ndlichkeit besonders wichtig da es wahrscheinlich bereits in der Entwurfsphase zu berarbeitungen des Entwurfs kommen wird Vollst ndigkeit Konsistenz und Pr fbarkeit der Entwurfsdoku mentation ist f r ihn auch von Bedeutung e Implementierer Der Implementierer sieht nur den Ausschnitt des Entwurfs den er zu implementieren hat Dieser Ausschnitt muss f r ihn aber hinreichend ver st ndlich sein um eine Umsetzung in der gew nschten Programmiersprache mit den vorgesehenen Werkzeugen und Softwarekomponenten zu erlauben Die Implementierung wird erleichtert wenn sich die Komponenten des Entwurfs unabh ngig voneinander entwickeln lassen Entkopplung da dann weniger Absprachen mit anderen Implementierern notwendig sind e Tester Der Tester testet zun chst die einzelnen Komponenten des Entwurfs Auch hier ist Entkopplung wichtig da sonst zu viele Komponenten integriert werden m ssen um ein ausf hrbares Teilsystem zu erhalten F r die Fehlersu 2 Projektmanager und eigent mer k nnten bei reinen Entwicklungsauftr gen die kurzfristige Pers pektive einnehmen denn nur wenn auch die Wartung durch den Auftragnehmer erfolgt lohnt sich die langfristige Perspektive Das ist allerdings zu kurz gedacht denn man m chte in der Regel die Gesch ftsbeziehung mit dem Kunden aufrecht erhalten Stellt der Kunde aber fest dass da
130. agen werden hier wie folgt beantwortet 1 Kopplung entsteht durch Beziehungen zwischen den Einheiten des Entwurfs Je mehr Beziehungen es gibt desto geringer ist die Entkopplung Die geerbten Bezie hungen werden mitgez hlt 2 Mehrfache Beziehungen der gleichen Art zwischen zwei Einheiten werden auch mehrfach gez hlt Dadurch haben die Z hlmetriken bei derartiger Redundanz einen h heren Wert Dar ber hinaus werden keine Unterschiede in der Kopplungs st rke gemacht 3 Die Richtung der Kopplung spielt eine Rolle Die Richtung ist gegeben durch die Richtung der Abh ngigkeit z B wenn Klasse B von Klasse A erbt ist Ban A gekoppelt aber nicht umgekehrt 4 Es werden nur direkte Beziehungen betrachtet denn die zus tzliche Ber cksichti gung indirekter Beziehungen erbringt keinen Zusatznutzen Briand et al 1999 Klasse Interface Auf Klassenebene ergibt sich damit zun chst die folgende Z hlmetrik die alle von der Klasse ausgehenden efferenten Beziehungen ber cksichtigt NEDC number of efferent dependencies of a class NEDC c Zge cu depends_on c d weight F r diese wie f r alle folgenden Metriken zur Entkopplung gilt dass sie negativ mit der Entkopplung korreliert ist Eine Unterscheidung in lokal definierte und geerbte Beziehungen wie bei Attributen und Operationen ist m glich NEDC number of local efferent dependencies of a class NEDC c Zgecuy depends_on c d weight Beziehungen der Klasse mi
131. aintenance Implications of the Replication of Code Proceedings of the International Conference on Software Maintenance ICSM 97 Bari Italy IEEE Computer Society Press Los Alamitos CA 1997 322 329 Buschmann et al 1996 Buschmann F Meunier R Rohnert H Sommerlad P Stal M Pattern Oriented Software Architecture A System of Patterns Wiley Chich ester 1996 Canfora et al 1996 Canfora G Mancini L Tortorella M A Workbench for Pro gram Comprehension During Software Maintenance Fourth Workshop on Program Comprehension Berlin IEEE Computer Society Press Los Alamitos CA 1996 30 39 Card Glass 1990 Card D Glass R Measuring Software Design Quality Prentice Hall Englewood Cliffs NJ 1990 Cardelli Wegner 1985 Cardelli L Wegner P On Understanding Types Data Abstraction and Polymorphism Computing Surveys 17 4 1985 471 522 Cartwright 1998 Cartwright M An Empirical View of Inheritance Information and Software Technology 40 14 1998 795 799 173 Cavano McCall 1978 Cavano J McCall J A Framework for the Measurement of Software Quality Proceedings of the Software Quality and Assurance Workshop Soft ware Engineering Notes 3 5 1978 133 139 Cherniavsky Smith 1991 Cherniavsky J Smith C On Weyuker s Axioms for Soft ware Complexity Measures IEEE Transactions on Software Engineering 17 6 1991 636 638 Chen Lu 1993 Chen J Lu J A New
132. al Report ISERN 98 29 Version 2 1998 Briand et al 1999 Briand L Daly J W st J A Unified Framework for Coupling Measurement in Object Oriented Systems IEEE Transactions on Software Engineer ing 25 1 1999 91 121 Briand W st 1999 Briand L W st J The Impact of Design Properties on Develop ment Cost in Object Oriented Systems Technical Report ISERN 99 16 1999 Briand W st 2001 Briand L W st J Integrating Scenario Based and Measure ment Based Software Product Assessment Journal of Systems and Software 59 1 2001 3 22 Broh 1974 Broh R Managing Quality for Higher Profits McGraw Hill New York 1974 Brooks 1987 Brooks F No Silver Bullet Essence and Accidents of Software Engi neering IEEE Computer 20 4 1987 10 19 Brown et al 1998 Brown W Malveau R McCormick H Mowbray T AntiPat terns Refactoring Software Architectures and Projects in Crisis Wiley Chichester 1998 Budd 1991 Budd T An Introduction to Object Oriented Programming Addison Wesley Reading MA 1991 Budgen 1994 Budgen D Software Design Addison Wesley Reading MA 1994 Bunge 1977 Bunge M Ontology I The Furniture of the World Treatise on Basic Philosophy Bd 3 Reidel Dordrecht 1977 Bunge 1979 Bunge M Ontology II The World of Systems Treatise on Basic Philos ophy Bd 4 Reidel Dordrecht 1979 Burd Munro 1997 Burd E Munro M Investigating the M
133. alle Vererbungshierarchien h chstens 6 Stu 0 nein E v fen tief 1 ja Umfasst jede Vererbungshierarchie h chstens 50 0 nein aye v Klassen 1 ja Fragebogen B 6 Strukturiertheit System a Quelle des Schwellenwerts Mayrand et al 1996 B 3 Entkopplung Um die Entkopplung zu verbessern wird allgemein eine hohe Kapselung empfohlen da dadurch die Abh ngigkeiten zwischen den Entwurfseinheiten reduziert werden k nnen Beispielsweise sollten Attribute grunds tzlich nicht ffentlich sichtbar sein Die ffentliche Schnittstelle einer Klasse die demzufolge nur aus Operationen beste hen sollte sollte so klein wie m glich sein Kopplung zu abstrakten Klassen und Interfaces ist der Kopplung zu konkreten Klassen vorzuziehen da sich Abstraktes weniger h ufig ndert als Konkretes B 3 Entkopplung 207 Klasse Interface Bedingung Fragetext Antwortskala Gewicht auto Sind alle Entwurfsentscheidungen so weit wie 0 nein SE m glich verborgen 1 ja isAbs Sind von der konkreten Klasse mehr als 9 andere 0 nein X v tract this Klassen abh ngig 1 ja NEEC this Ist das Erben von mehreren Klassen hier n tig 0 nein x gt 1 1 ja Sind alle Assoziationen mit anderen Klassen 0 nein n tig 1 ja Sind mehrfache Assoziationen mit derselben 0 nein Klasse unn tig 1 ja n tig wenn sie unterschiedliche Bedeutung besitzen oder unterschiedliche M
134. ameter Template Klassen selbst sind keine echten Klassen aber ihre Instanzen sind es Daher geh ren Template Instanzen zu C Template Klassen aber nicht F r die Templates wird daher eine neue Menge T eingef hrt Formale Parameter von Templates m ssen aussortiert werden d rfen also keinesfalls zu C hinzugenommen werden Auf der Basis von Binding kann nun eine weitere Relation binds eingef hrt werden binds C x T Eine Klasse ist Instanz eines Templates binds c t gilt genau dann wenn es eine Instanz von Binding gibt bei der die Rollen client mit c und supplier mit t belegt sind 5 5 Formale Definition von Metriken 55 Eine Hinzunahme der Template Klassen zu ODEM ist also prinzipiell m glich Es gibt aber wichtige Grtinde es nicht zu tun Zum einen gibt es noch einige Unklarhei ten ber die tats chliche Darstellung im UML Metamodell Beispielweise fehlt in der Spezifikation die Information dar ber wie die Beziehungen von formalen Template Parametern in den Template Instanzen modelliert werden Zum anderen wird durch die Hinzunahme von Templates die Formulierung und Auswahl von Metriken erschwert Wenn z B die Anzahl der Klassen gez hlt werden soll kann man die ech ten Klassen und die Template Klassen z hlen weil das diejenigen sind die tats chlich implementiert werden m ssen Alternativ z hlt man die echten Klassen und die Tem plate Instanzen weil das die Anzahl der tats chlichen Klassen im Modell ist Welche Z
135. ameters der sich aus der gerichteten Assoziation von Parameter mit Classifier im UML Metamodell ableitet 5 4 Erweiterungen In diesem Abschnitt werden Erweiterungen von ODEM vorgestellt Zun chst werden Relationen eingef hrt die aus den bereits eingef hrten Relationen abgeleitet werden k nnen Diese Relationen vereinfachen die Definition von Metriken auf der Basis von ODEM Dann wird diskutiert wie Relationen gewichtet werden k nnen Abschlie end werden verschiedene Aspekte einer Erweiterung von ODEM um parametri sierte Klassen Templates betrachtet 5 4 1 Abgeleitete Relationen Die allgemeine Abh ngigkeitsbeziehung depends_on fasst alle Arten von Abh ngig keiten zwischen Modellelementen zusammen Sie setzt voraus dass tats chlich alle Arten von Benutzung zwischen Klassen z B Aufruf einer Methode Zugriff auf ein Attribut Benutzung als Attributtyp oder Parametertyp im UML Modell als Instan zen von Usage repr sentiert sind Nur im Falle der Benutzung als Typ bei Attributen oder Parametern k nnen uses Beziehungen aus der vorliegenden Information auto matisch abgeleitet werden F r die anderen genannten F lle z B Zugriff auf ein Attribut ist das nicht m glich daher ist es wichtig diese Arten von Benutzungsbe ziehungen explizit anzugeben depends_on x y amp extends x y v realizes x y v associates x y v uses x y Von dieser Relation kann eine Relation depends_on f r Paketabh ngigkeiten abgeleitet werden
136. ammenge tragen Die Schwellenwerte sind eigentlich f r Code gedacht weshalb die Programmiersprache angegeben wird f r die sie ausgelegt sind Wie man sieht decken die Vorschl ge nur einen kleinen Teil der Metriken ab so dass bei der Wahl der Schwellenwerte vor allem auf eigene Erfahrung zur ckgegriffen werden muss Ein alternativer Ansatz zur Festlegung von Schwellenwerten ist statistischer Natur er stammt urspr nglich aus dem Bereich der Ausrei eranalyse Zun chst wird die Metrik f r alle Elemente eines oder mehrerer Entw rfe erhoben Dann wird der Schwellenwert aufgrund der Verteilung der Messwerte festgelegt Bei Metriken auf einer Rationalskala w hlt man z B als Schwellenwert den Mittelwert plus die Stan dardabweichung Vorschlag von Erni 1996 Dieses Verfahren l sst sich leicht ange passt auch f r Metriken mit Absolutskala verwenden Bei Intervall oder Ordinalska len kann man Quantile verwenden z B 80 Quantil 3 Die Alternative w re eine Gewichtung mit 0 Allerdings w re dann unn tiger Aufwand f r die Datenerhebung zu leisten Eine Gewichtung mit 0 ist daher h chstens bei einem vollautomatisierten Verfahren sinnvoll um Aufwand f r die Anpassung des Bewertungswerkzeugs einzusparen 134 9 Quantifizierung des Qualit tsmodells Metrik Schwellenwert Quelle Programmiersprache Morschel 1994 Smalltalk 6 Johnson und Foote 1988 C NAC 3 9 f r GUI Klassen L
137. andaten verwaltet Er nimmt nderungen an den Fahrplandaten vor gibt neue Daten ein oder l scht vorhandene Angaben Er erledigt diese Aufgaben im Admin Modus des Fahrplanauskunftssystems 226 C Dokumente zum Softwarepraktikum Starthaltestelle Die Starthaltestelle ist eine spezielle Haltestelle an der der Fahrgast seine Fahrt beginnen m chte Startzeitpunkt Zeitpunkt an dem der Fahrgast die Fahrt von der Starthaltestelle aus beginnen m chte Umsteigehaltestelle Eine Umsteigehaltestelle ist eine spezielle Haltestelle die von den Z gen mehrerer Linien angefahren wird An dieser ist deshalb ein Wechsel vom Zug einer Linie in den Zug einer anderen Linie m glich Umsteigezeit Umsteigezeiten sind die Aufenthaltszeiten an einer Umsteigehalte stelle Die Umsteigezeiten d rfen bei einer g ltigen Verbindung maximal 60 Minuten und mindestens 5 Minuten betragen Verbindung Eine Verbindung zeigt an wie ein Fahrgast unter Benutzung von Z gen der vorhandenen Linien von einer Starthaltestelle zu einer gew nschten Zielhalte stelle gelangt Zu einer Verbindung z hlt die Angabe Liniennummer aller zu benut zenden Linien der Umsteigehaltestellen des Abfahrtszeitpunktes an der Starthalte stelle und an allen Umsteigehaltestellen und des Ankunftszeitpunkts an der Zielhaltestelle Umsteigezeiten von weniger als 5 oder mehr als 60 Minuten f hren dazu dass eine Verbindung ung ltig ist Verbindung mit den wenigsten Umsteigehaltestellen
138. andlichkeit Analysierbarkeit Boehm et al 1978 ISO IEC 9126 1991 Coad Yourdon Klarheit 1991 Erni 1996 Wartbarkeit McCall et al 1977 Boehm et al 1978 ISO IEC 9126 1991 IEEE 1061 1992 Zusammenhalt Booch 1994 Coad Yourdon 1991 Erni 1996 Tabelle 8 2 Kriterien zur Wartbarkeit aus der Literatur Gew hlte Kriterien Aus der Sammlung der Kriterien in Tabelle 8 2 werden Kriterien f r die Wartbarkeit ausgew hlt Aus Tabelle 8 2 direkt bernommen werden Knappheit Strukturiertheit Entkopplung und Zusammenhalt nderbarkeit Flexibilit t und Stabilit t werden unter Wartbarkeit subsumiert Selbsterkl rung Verst ndlichkeit Konsistenz und Les barkeit werden zu den Kriterien Einheitlichkeit und Dokumentierung zusammenge fasst Weggelassen wird Einfachheit weil Einfachheit etwas ist was sich genau so wie die in Abschnitt 7 2 3 angesprochene Eleganz nirgendwo festmachen l sst Ein fachheit zieht sich vielmehr durch alle Kriterien hindurch Am ehesten spiegelt sich die Einfachheit noch in der Knappheit der Strukturiertheit und der Entkopplung Die Allgemeinheit wird ebenfalls weggelassen und stattdessen dem Faktor Wiederver wendung zugeordnet da sich Allgemeinheit in der Regel negativ auf die Wartbarkeit 8 3 Wartbarkeit 107 auswirkt h here Komplexit t Neu hinzugenommen wird die Verfolgbarkeit die in keinem der untersuchten Modelle vorkommt Die resultierenden Kriterien des Faktors Wartbarkeit s
139. ann ASCII oder HTML Dabei werden die Messwerte strukturiert aufberei tet W rden s mtliche Verfeinerungen auf einen Schlag pr sentiert w re der Bewer ter sonst von der Menge der Messwerte berfordert Es ist sinnvoll zun chst nur die unverfeinerten Metriken darzustellen und die Verfeinerungen erst anschlie end als Untertabellen zu pr sentieren 5 Dieses Problem tritt auch noch in Version 5 5 auf Dem Support von Togethersoft waren die Fehler noch nicht bekannt was darauf schlie en l sst dass den XMI Export bisher kaum jemand benutzt 156 11 Werkzeugunterstutzung In der Tabellenkalkulation k nnen anhand der Messwerte z B statistische Auswer tungen oder Darstellungen in Diagrammen vorgenommen werden Auch das Bewer tungsverfahren kann innerhalb der Tabellenkalkulation durchgef hrt werden Dazu m ssen zus tzlich die Formeln f r die Bewertungsvorschl ge mit den Gewichten des spezifischen Qualit tsmodells eingegeben werden Der Bewerter muss au erdem noch die Messwerte der subjektiven Metriken eingeben damit sich die Qualit tskenn zahlen des spezifischen Modells berechnen lassen Die Frageb gen lassen sich bei die sem Ansatz allerdings nur schwer integrieren Review B gen Der Ansatz der Bewertung innerhalb einer Tabellenkalkulation hat den Nachteil dass die Formeln von Hand eingegeben oder angepasst werden m ssen Praktischer ist die Generierung eines Review Bogens in dem die Berechnung weitestgehend autom
140. ann F r diese Entwurfsinformation wurde ein formales Referenz modell entwickelt das Object Oriented Design Model ODEM ODEM definiert den Gegenstand des Bewertungsverfahrens und kann au erdem zur formalen Definition von Metriken eingesetzt werden Das allgemeine Qualit tsmodell Quality Model for Object Oriented Design QOOD definiert die Qualit tsfaktoren und kriterien f r die eine Bewertung auf der Basis von ODEM m glich ist Der Schwerpunkt von QOOD liegt auf dem Faktor Wartbar keit f r den auch eine Quantifizierung angegeben ist Diese Quantifizierung besteht nur zum Teil aus objektiven Metriken weil sich wesentliche Aspekte des Entwurfs vor allem semantische Aspekte nicht oder nur unzureichend durch objektive Metri ken erfassen lassen Daher wurden subjektive Metriken hinzugenommen deren Erhe bung durch Frageb gen erleichtert und gesteuert wird Bei der Auswahl der objektiven Metriken f r QOOD hat sich gezeigt dass sich f r viele Metriken Verfeinerungen angeben lassen mit denen differenziertere Aussagen m glich werden Andererseits erh hen die Verfeinerungen den Mess Kalibrierungs und Interpretationsaufwand Aus dem allgemeinen Qualit tsmodell QOOD lassen sich spezifische Qualit tsmo delle ableiten die den Kontext die konkreten Qualit tsanforderungen und die Quali t tssicht ber cksichtigen Bei der Ableitung des spezifischen Modells werden Fakto ren Kriterien Metriken und Fragen ausgew hlt sowie eine G
141. archiviert Die Messwerte werden in tabellarischer Form und in Diagrammen aufbereitet Der Export der Messwerte in externe Werkzeuge z B eine Tabellenkalkulation ist m glich Die Messwerte k nnen auf der Basis eines frei konfigurierbaren Schemas d h eines Qualit tsmodells aggregiert werden um Qualit tskennzahlen zu erhalten Ein Bewertungsbrowser erlaubt es das Entstehen der Endbewertung durch die Aggregationsschritte nachzuvollziehen Optional k nnen subjektive Metriken in das Bewertungsschema aufgenommen werden Dabei sind Bewertungsvorschl ge aus verschiedenen Quellen z B Metri ken Regeln Frageb gen verf gbar Ausgew hlte Entwurfsregeln k nnen auf der Basis der Metriken automatisch gepr ft werden Verst e werden aufgelistet Es k nnen Checklisten Frageb gen oder Review B gen generiert werden die an den Pr fling angepasst sind Es k nnen erkl rende Texte zu den Regeln Checklisten Frageb gen und Metriken abgerufen werden Es k nnen Texte mit Vorschl gen zur Problembehebung passend zum Problem abgerufen werden Es sind automatische Entwurfstransformationen verf gbar z B als Wizards Weitere Anforderungen sind im Bereich einer weitergehenden Visualisierung von Messwerten denkbar die dem Bewerter zus tzliche Erkenntnisse erm glichen Hier gibt es bereits erste Ans tze z B Simon et al 2001 160 11 Werkzeugunterst tzung Das skizzierte ideale Werkzeug kann modular aufge
142. artungsaufwand erwiesen Die Entw rfe der Fallstudie sind allerdings nicht besonders gro weshalb keine sichere Aussage dar ber gemacht werden kann wie gut das Verfahren auf gro e Ent w rfe skaliert Meiner Ansicht nach d rfte es aber keine gr eren Probleme geben da der Ansatz bottom up arbeitet und daher die Schwierigkeit der Durchf hrung nur schwach mit der Gr e des Entwurfs zunimmt Ein wichtiges Nebenprodukt der Bewertung ist eine Liste von entdeckten M ngeln die behoben werden sollten Diese M ngel werden vor allem bei der Beantwortung der Frageb gen identifiziert Zus tzlich k nnen auch Ausrei er bei den objektiven Metriken als Indikatoren f r potentielle Schwachstellen verwendet werden 12 2 3 Automatisierung Die Entwurfsinformation in ODEM kann in eine relationale Datenbank abgebildet werden Dazu wurde ein Werkzeug implementiert dass die n tige Information aus UML Modellen dargestellt in XMI extrahiert und in eine Datenbank schreibt vgl Abschnitt 11 2 1 Auf der Datenbank k nnen dann die Messungen vorgenommen werden Die formalen Definitionen der Metriken lassen sich leicht in entsprechende Datenbankabfragen umsetzen so dass sich die Erhebung der objektiven Metriken voll automatisieren l sst F r die Erhebung und Aufbereitung der Messwerte in Form von Reports ist ebenfalls ein Werkzeug verf gbar vgl Abschnitt 11 2 2 Umfang und Form der Reports sind frei w hlbar da sie anhand von Vorlagen generiert
143. as Quali t tsmodell auf Aspekte die sich auf der Basis von ODEM beurteilen lassen 8 1 5 Schwerpunkt Wartbarkeit I suspect that some programmers think that their program will be so good that it won t have to be changed This is foolish The only programs that don t get changed are those that are so bad that nobody wants to use them Designing for change is designing for success Parnas 1994 S 282 Der Schwerpunkt des Qualit tsmodells liegt auf der Wartbarkeit da die Wartung im Software Lebenszyklus den gr ten Kostenfaktor darstellt Mindestens die H lfte des Gesamtaufwands flie t in die Wartung Boehm 1976 Lientz Swanson 1980 Daher kann eine Kostenreduktion am ehesten dadurch erreicht werden dass man den Auf wand f r diese Phase reduziert Der Wartungsaufwand selbst zerf llt nach Sneed 1988 in vier Bereiche e Stabilisierung d h Fehlerkorrektur e Optimierung d h Verbesserungen der Effizienz und der Struktur e Anpassung d h durch die Umwelt erzwungene Modifikationen technische oder fachliche und e Erweiterung d h Hinzunahme weiterer Funktionen Tabelle 8 1 zeigt die Verteilung des Aufwands auf die vier Bereiche nach Lientz Swanson 1980 und Sneed 1988 Die Verteilung ist bei beiden hnlich Der Anteil der Fehlerkorrektur ist mit etwa 25 relativ gering die brigen Wartungst tigkeiten die meistens Entwurfsstrukturen beeinflussen berwiegen mit etwa 75 Daraus l sst sich schlie en
144. ate k n nen einen impliziten Parameter this verwenden der den aktuellen Bewertungsgegen stand bezeichnet Die Gewichte weniger wichtig wichtig und sehr wichtig werden durch Sternchen visualisiert f r weniger wichtig f r wichtig und f r sehr wichtig Ist eine Frage automatisch beantwortbar wird in der letzten Spalte ein H k chen gesetzt Bei manche Fragen geht es um das Fehlen bestimmter Eigenschaften z B dass keine zyklischen Abh ngigkeiten vorhanden sind Bei der Antwort soll entgegen dem Sprachgebrauch mit ja geantwortet werden wenn die Aussage zutrifft und mit nein wenn die Aussage nicht zutrifft B 1 Knappheit Da Knappheit geringe Gr e bedeutet enthalten die Frageb gen verschiedene Fragen nach unn tigen und redundanten Entwurfsteilen Klasse Interface Bedingung Fragetext Antwortskala Gewicht auto Ist das Vorhandensein der Klasse notwendig 0 nein ali 1 ja thise C Enth lt die Klasse nur die n tigen Attribute 0 nein es z B keine nicht mehr verwendeten oder f r die 1 ja Verantwortlichkeiten der Klasse nicht relevanten NOC this Enthalt die Klasse nur die n tigen Operationen 0 nein on gt 0 z B keine nicht mehr verwendeten oder f r die 1 ja Verantwortlichkeiten der Klasse nicht relevanten NOC this Enth lt die Klasse keine berfl ssigen Opera 0 nein gt 0 tionen 1 ja z B berladene Operationen oder andere Komfort Operationen
145. ati siert ist Ein m glicher Ansatz dazu sind HTML basierte Reports die e eine Zusammenfassung der Eigenschaften und Beziehungen einer Komponente e alle zugeh rigen objektiven Metriken z B geordnet nach Kriterien e die daraus abgeleiteten Bewertungsvorschl ge und e die Frageb gen enthalten Ein solcher Report kann ausgedruckt und als Review Bogen verwendet werden der von Hand ausgef llt wird Abbildung 11 3 zeigt den berblicksteil des HTML Reports f r eine Klasse Bewertungsbogen Klasse Point 4 berblick Knappheit Strukturiertheit Entkopplung Zusammenhalt Einheitlichkeit Dokumentierung Verfolgbarkeit 4 Wartbarkeit berblick enthalten in Paket System erbt von 1 Klassen Object realisiert 1 Interfaces 2DPoint assoziiert 0 Klassen Interfaces 3 benutzt 0 Klassen Interfaces A hat 2 Attribute 2 lokal 0 geerbt 0 public 0 protected 2 private 2 instance 0 classifier x int y int 4 hat2 Operationen 2 lokal D geerbt 2 public 0 protected 0 private 2 instance 0 classifier getx int get int TR Abbildung 11 3 berblick ber eine Klasse 11 2 Selbst realisierte Werkzeuge 157 Durch Verwendung von JavaScript kann die automatische Auswertung in den HTML Report integriert werden Man benutzt eine HTML Form um die Fragen der Frageb gen direkt im HTML Browser beantworten zu lassen Die Antworten werden durch JavaScript Funktionen ausgewertet Be
146. aufwand in der Summe ber alle drei nderungen Der am schlechtesten bewertete Entwurf hat mit 730 Minuten den h chsten der am besten bewertete Entwurf mit 490 Minuten den geringsten Wartungsaufwand Der mittlere Entwurf liegt mit 685 Minuten in der Mitte lassen _ Operationen Ze Aufwand Gruppe 1 730 Gruppe 3 o 685 Gruppe 7 490 Tabelle 10 10 Wartungsaufwand insgesamt Damit best tigt sich in der Gesamtbetrachtung die Rangordnung durch die urspr ng liche Bewertung obwohl es in den einzelnen Szenarien z T leichte Abweichungen davon gibt Die Bewertung durch das spezifische Modell kann also als plausibel ange sehen werden Leider enthalten die Entw rfe in dieser Fallstudie kaum Vererbung Daher ist es schwierig festzustellen ob die Entscheidung bei den Metriken f r Knappheit und Entkopplung geerbte Eigenschaften und Beziehungen grunds tzlich mitzuber cksichtigen tats chlich gerechtfertigt ist 10 3 Besonderheiten bei Mustern Vergleicht man zwei funktional gleichwertige Entwurfsalternativen von denen die eine Muster enth lt und die andere nicht stellt man h ufig fest dass die objektiven Metriken den Entwurf mit den Mustern schlechter bewerten Rei ing 2001b Das liegt vor allem daran dass die Musteranwendung mehr Entwurfselemente und Bezie hungen erfordert auch wenn gleichzeitig bestimmte Messwerte verbessert werden z B kann das Mediator Muster die Entkopplung verbessern s a Huston 2001 D
147. baut werden beispielsweise gem einem Vorschlag von Hitz und Neuhold 1998 f r Code basierte Werkzeuge vgl Abbildung 11 6 Im Zentrum der Architektur steht ein Repository das die not wendige Information als Instanz eines Metamodells z B ODEM enth lt Dieses Repository wird von Parsern f r UML Modelle oder f r Code gef llt Eine breite Palette von Analyse Werkzeugen kann dann Auswertungen auf dem Repository durchf hren Die Ergebnisse der Analysen k nnen ebenfalls in dem Repository gespeichert werden zur Weiterverarbeitung durch andere Werkzeuge und fiir Trend analysen XMI Parser Metriken Tool W I Regelpr fer Java Parser Abbildung 11 6 Architektur des idealen Werkzeugs Eine vollst ndige Implementierung des idealen Werkzeugs ist w nschenswert war im Rahmen dieser Arbeit allerdings nicht vorgesehen Die von Schmider 2002 reali sierten Werkzeuge bilden aber eine geeignete Basis f r ein umfassenderes Werkzeug denn die Werkzeuge Konverter und Reportgenerator sowie die ODEM Datenbank als Repository entsprechen der Architektur aus Abbildung 11 6 161 Kapitel 12 Zusammenfassung und Ausblick 12 1 Zusammenfassung Diese Arbeit hat sich mit der Frage besch ftigt wie die Qualit t eines objektorientier ten Entwurfs bewertet werden kann Dabei liegt der Schwerpunkt aus praktischen Erw gungen auf statischer Entwurfsinformation die aus UML Diagrammen gewon nen werden k
148. ber die Qualit t des Entwurfs zu bekommen Identifizierte M ngel im Entwurf und in seiner Dokumentation k nnen ausgebessert werden so dass Fehlerfolgekos ten in Implementierung und Wartung vermieden werden Da diese Folgekosten sehr hoch sein k nnen fallen die Qualit tssicherungskosten dagegen kaum ins Gewicht Es ist also mit einem positiven Nettonutzen zu rechnen Ein guter Entwurf garantiert allerdings noch keine gute Implementierung da bei der Implementierung immer noch z B Fehlentscheidungen des Managements oder Abweichungen vom Entwurf m glich sind Die Wahrscheinlichkeit f r eine gute Imp lementierung wird aber durch einen guten Entwurf deutlich erh ht 12 2 5 Einsatz in der Praxis F r den Einsatz in der Praxis z B in der Industrie ist der Ansatz grunds tzlich geeignet Allerdings sollte die Werkzeugunterst tzung noch ausgebaut werden Au erdem w re es hilfreich wenn das Bewertungsverfahren in UML Modellierungs werkzeuge integriert w re Ein Problem d rfte die bisher nur rudiment re Unterst t zung bei der Ableitung spezifischer Modelle sein Vorgefertigte spezifische Modelle die als Vorlagen dienen k nnen d rften die Ableitung erleichtern Eine wichtige psychologische Voraussetzung f r das Verfahren ist dass es nicht dazu eingesetzt wird den Entwerfer zu bewerten Ansonsten wird der Entwerfer seine Mit wirkung verweigern oder falls er das Verfahren selbst durchf hren soll gesch nte Ergebnisse vo
149. ber of efferent realization relationships of a class NERC c Zgecui realizes c d weight EAC number of efferent association relationships of a class EAC c Zge cu associates c d weight ZZ NEUC number of efferent uses relationships of a class NEUC c Zgecuy uses c d weight NERC und NEAC sind f r Interfaces immer 0 NEAC l sst sich noch anhand der Assoziationsart 1 normal 2 Aggregation und 3 Komposition verfeinern NEAC number of efferent normal association relationships of a class NEAC c Zge CUI c associates c d aggregation none associates c d weight NEAC number of efferent aggregation relationships of a class NEAC c Zge CUI c associates c d aggregation aggregate associates c d weight EAC number of efferent composition relationships of a class EAC3 c Zde CUN c associates c d aggregation composite associates c d weight Alle genannten Verfeinerungen lassen sich miteinander kombinieren was in diesem Fall eine sehr hohe Zahl von Kombinationsm glichkeiten mit sich bringt ZZ Bisher wurden nur von der Klasse ausgehende efferente Beziehungen betrachtet Es k nnen aber auch die zur Klasse hingehenden afferenten Beziehungen gez hlt wer den NADC number of afferent dependencies of a class NADC c Zae cur depends_on d c weight Diese Metrik gibt Hinweise auf Klassen deren Anderung weit reichende Konsequen zen auf den Rest des Entwurfs hat je h
150. bjektorientierter Entw rfe Daher baut ODEM auf den Informationen auf die sich aus einer Entwurfsdarstellung in UML d h einem UML Modell gewinnen las sen UML Modelle sind Auspr gungen des UML Metamodells hier wird das UML Metamodell aus der Version 1 3 des Standards der OMG OMG 2000a verwendet Das UML Metamodell dient zur formalen Definition der UML Interessanterweise ist das UML Metamodell wiederum mit UML definiert wir haben es also mit einer rekursiven Definition zu tun Weil UML eine Notation f r objektorientierte Analyse und Entwurf ist sind die Elemente des UML Metamodells als Klassen modelliert Die Namen der Klassen entsprechen dabei den UML Begriffen Abbildung 5 1 und Abbildung 5 2 zeigen die f r ODEM relevanten Ausschnitte aus dem UML Metamodell In Abbildung 5 1 liegt der Schwerpunkt auf den Modell elementen wie Klassen und Paketen w hrend in Abbildung 5 2 der Schwerpunkt auf den Beziehungen wie Vererbung oder Assoziation liegt 1 Odem ein gehobenes Wort f r Atem ist daf r ein passender Name Schlie lich ist ein formales Modell als Grundlage f r die Definition von Metriken genauso essenziell wie Atem f r das Leben 44 5 Ein Referenzmodell fur den objektorientierten Entwurf templateParameter ModelElement Ton dered SS ElementOwnership i A n 9 1 visibility VisibilityKind stereotype Stereotype extendedElement if namespace 0 1 Gi NameSpace Gensraizabiekiement visibility Vis
151. blierung einer Wiederverwendungskultur Geeignete Rahmenwerke Bibliothe ken und Muster sind bekannt und werden verwendet Dar ber hinaus kann auch durch Produktlinien product lines und den Aufbau eigener Bausteinbibliotheken ein Beitrag zur Wiederverwendung gemacht werden 7 6 Entwurfsbewertung 97 75 2 Konstruktive Ma nahmen Object oriented programming has shown that one way to attack complexity is to organize messes into smaller messes and repeat the process Meyer 2001 S 30 Die Vorgaben aus den organisatorischen Mafsnahmen schlagen sich in den konstrukti ven Ma nahmen nieder Wiederverwendung Man greift auf bew hrte Entw rfe in Form von Architektur mustern Entwurfsmuster Rahmenwerken und fertigen Komponenten z B aus Bibli otheken zur ck Code Generatoren k nnen ebenfalls zur Architektur Wiederverwen dung eingesetzt werden Entwurfsregeln Sie geben Hinweise auf welche Eigenschaften w hrend des Ent wurfs zu achten ist z B Modularisierung unter Beachtung von Kopplung und Zusammenhalt Notation Es wird eine geeignete Notation verwendet vgl auch Abschnitt 8 3 6 Werkzeuge Es werden geeignete Werkzeuge eingesetzt die den Entwerfer unterst t zen indem z B Konsistenz gew hrleistet wird 7 5 3 Analytische Ma nahmen Review Sobald der erste Entwurf vorhanden ist kann er einem Review unterzogen werden in der Regel wird es sich um eine Inspektion handeln Bass et al 1998 und Shull et al
152. bstraktion Hat der Name eine entsprechende Bedeutung in der Sprache der Experten des Anwendungsgebiets Dieser Test ist wie Cockburn zugibt subjektiv aber seiner Ansicht nach dennoch effektiv Verteilung der Verantwortlichkeiten responsibility alignment Passen der Name der Klasse sowie die Attribute und Methoden zu ihrer Hauptverantwortlichkeit Dies ist eine Frage die mit zunehmender Evolution des Entwurfs an Bedeutung gewinnt da Klassen dazu neigen sich im Laufe der Zeit immer weiter aufzubl hen d h um Funktionalit t erweitert zu werden wobei sie sich h ufig von der urspr nglichen Intention des Entwerfers entfernen Datenvariationen data variations Kann das System mit allen Varianten von Daten zurechtkommen mit denen es im Laufe seiner Ausf hrung konfrontiert werden kann Leider wird dieser Punkt nicht genauer ausgef hrt Man kann die Aussage aber so interpretieren dass sichergestellt sein sollte dass das System sowohl von den anfallenden Mengen als auch von der Strukturierung der Daten auf alle m glichen F lle vorbereitet sein soll Evolution evolution Welche nderungen in den Abl ufen des Anwendungsbe reichs der Technologie der angebotenen Dienste etc sind wahrscheinlich und wie lassen sich die daraus resultierenden neuen Anforderungen und nderungen im Ent wurf umsetzen Wie viele Entwurfskomponenten m ssen dazu ge ndert werden Kommunikationsmuster communication patterns Entstehen au ergew hnlich
153. bweichen Auf diese Weise wird die Reproduzierbarkeit der sub jektiven Bewertung verbessert ebenso die brigen Kriterien des ISO IEC Guide 25 vgl Abschnitt 7 6 1 9 1 4 Gesamtbewertung Als Gesamtbewertung wird f r jedes Kriterium f r jeden Faktor und f r den Entwurf insgesamt eine subjektive Metrik verwendet Diese st tzt sich auf die objektiven Metriken die Antworten zu den Frageb gen und die subjektiven Metriken unterge ordneter Elemente sofern verf gbar aus denen Bewertungsvorschl ge berechnet werden k nnen vgl Abbildung 9 1 Die objektiven Metriken allein sind zur Bewertung der Entwurfsqualit t nicht ausrei chend da sie im Wesentlichen auf syntaktische Aspekte des Entwurfs beschr nkt sind F r die semantische Beurteilung sind Frageb gen besser geeignet Die Frageb gen enthalten allerdings Fragen f r deren Beantwortung Messwerte der objektiven 9 1 Bewertungsverfahren 119 Bewertungsvorschlag fur die subjektive Metrik Bewertungsvorschlag Bewertungsvorschlag Bewertungsvorschlag aus den Messwerten der aus den Antworten des aus untergeordneten objektiven Metriken Fragebogens subjektiven Metriken Abbildung 9 1 Aggregation der Bewertungsvorschlage Metriken ben tigt werden Also f hrt erst die Kombination der beiden Ans tze zu einer gut funktionierenden L sung Die Bewertung l uft bottom up ab vgl Abbildung 9 2 Zun chst werden f r die unterste Ebene die Klassen und Interfaces f r jedes Kri
154. cCabe High levels of user satisfaction and low defect levels often associated with low complexity John Musa Low defect levels adherence of software functions to user needs and high reliability Bill Perry High levels of user satisfaction and adherence to requirements Tabelle 6 1 Verschiedene Definitionen von Softwarequalitat Verschiedene Organisationen haben den Begriff der Softwarequalit t standardisiert hier die Definitionen von IEEE und ISO IEC Definition 6 3 quality IEEE Std 610 12 1990 1 The degree to which a system component or process meets specified requirements 2 The degree to which a system component or process meets customer or user needs or expectations Definition 6 4 software quality ISO IEC 9126 1991 The totality of features and characteristics of a software product that bear on its ability to sat isfy stated or implied needs 6 2 Qualit tsmodelle 63 Die Definition des IEEE die auch den Entwicklungsprozess einschlie t spiegelt die herstellungsbezogene und die benutzerbezogene Sicht wieder Die Definition der ISO IEC l sst den Prozess weg ist ansonsten aber hnlich Es f llt auf dass beide Definitionen sehr abstrakt sind Eine universelle Qualit tsdefinition muss allerdings auch abstrakt sein da es keine detaillierte Produkt unabh ngige Definition von Qua lit t geben kann Glass 1998 Will man die Qualit t einer Software bewerten muss man deren spezifische Anforderungen be
155. ccc Der so entstehende Bezeichner ist eindeutig Auf die gleiche Weise wird der Bewertungsvorschlag f r die Gesamtqualit t aus den subjektiven Metriken der Faktoren der gleichen Ebene gewonnen indem ein gewich teter Durchschnitt gebildet wird Die Benennung der Gewichte ist ebenfalls analog als K rzel wird DQ f r design quality verwendet z B DOsyyas 9 4 Fragebogen 127 9 4 Fragebogen Checklists are the simplest and perhaps the most immediately useful aids to design thinking that have appeared so far Jones 1992 S 369 Frageb gen sind ein wertvolles Hilfsmittel bei Analyse und Bewertung von Produk ten und Prozessen Ein Fragebogen besteht aus einer Folge von Fragen die von einem Bewerter auszuf llen sind Frageb gen k nnen bei Entwurfsinspektionen eingesetzt werden um erw nschte Eigenschaften sicherzustellen oder um unerw nschte Eigen schaften festzustellen Hat der Entwerfer den Fragebogen im Kopf kann er dessen Inhalt auch bereits w hrend des Entwurfs ber cksichtigen Eine spezielle Form des Fragebogens ist die Checkliste eines der sieben Werkzeuge zur Qualit ts berwachung von Ishikawa 1989 Eine Checkliste besteht nur aus Fra gen die mit ja oder nein zu beantworten sind Bei klassischen Checklisten z B bei Flugzeugen vor dem Start m ssen alle Fragen mit ja beantwortet werden damit der Bewertungsgegenstand die Pr fung besteht In der Literatur werden unter der Bezeichnung Checklisten aber auch
156. chbaren Defi nitionen von Entwurfsqualit t auf Indikatoren Im Laufe der Zeit sind viele solcher Indikatoren in Form von erw nschten Eigen schaften vorgeschlagen worden z B Konsistenz Verfolgbarkeit traceability und Wiederverwendbarkeit Die Zusammenh nge zwischen Kosten und Indikatoren sind f r den objektorientierten Entwurf allerdings empirisch kaum belegt Manche sind immerhin f r den strukturierten Entwurf belegt von dem einige Kriterien wie z B Kopplung und Zusammenhalt bernommen wurden Diskussion Der transzendenten und der benutzerbezogenen Definition fehlt es an Eindeutigkeit und Objektivit t daher k nnen sie in diesem Zusammenhang ausgeschlossen wer den Die produktbezogene Sicht definiert eine allgemeine die herstellungsbezogene eine spezifische Qualit tssicht Sowohl die allgemeine als auch die spezifische Defini tion haben ihre Vorteile Der Vorteil eines allgemeinen Qualit tsmodells ist dass es in allen F llen ohne Anpassung verwendbar ist Allerdings m sste ein solches Modell um allgemein g l tig zu sein entweder s mtliche Qualit tsaspekte abdecken die jemals relevant sein k nnten der ganze Bereich in Abbildung 7 7 oder sich auf diejenigen Aspekte kon zentrieren die allen Entw rfen gemeinsam sind der dunkle Schnittbereich in Abbildung 7 7 Wie man sieht umfasst der gesamte Bereich viele Teile die f r ein zelne Produkte ohne Belang sind w hrend der gemeinsame Bereich viele Teile die
157. cht bewerten kann man entspre chende Faktoren hinzunehmen z B Benutzungsfreundlichkeit Je nach den konkre ten Qualit tsanforderungen des zu entwickelnden Systems k nnen noch spezielle Kriterien hinzukommen z B Verklemmungsfreiheit bei parallelen Systemen F r alle diese Faktoren wird zur Bewertung zus tzliche Entwurfsinformation ben tigt die in ODEM nicht verf gbar ist Deshalb werden sie hier nicht weiter in Betracht gezogen 117 Kapitel 9 Quantifizierung des Qualitatsmodells An important lesson learned from the application of software measurement is that it is better to start from a set of metrics addressing important improvement areas and evolve these metrics over time instead of debating forever trying to find perfect metrics Daskalantonakis 1992 S 1008 Im vorhergehenden Kapitel wurden die Faktoren und Kriterien angegeben die im Rahmen von QOOD als f r die Entwurfsqualit t wichtig angesehen werden Dieses Kapitel besch ftigt sich damit wie eine quantitative Bewertung der Entwurfsqualitat durchgef hrt werden kann Die Quantifizierung wird am Beispiel des wichtigsten Faktors der Wartbarkeit gezeigt Da viele Kriterien der Wartbarkeit auch den ande ren Faktoren zugeordnet sind mtissen ftir eine vollstandige Quantifizierung von QOOD nur noch wenige weitere Kriterien quantifiziert werden Zun chst wird das quantitative Bewertungsverfahren skizziert bevor auf die einzel nen Komponenten des Verfahr
158. chte
159. chtung der Faktoren festlegen f r jeden Faktor die relevanten Kriterien ausw hlen die Gewichtung der Kriterien festlegen f r jedes Kriterium die objektiven Metriken ausw hlen die Schwellenwerte Toleranzen und Gewichte f r die Metriken festlegen f r jedes Kriterium die Fragen aus den Frageb gen ausw hlen die Gewichte f r die Fragen festlegen oO CON BD 0 RA W N die Gewichte fiir die Ableitung des Gesamtvorschlags aus den einzelnen Bewer tungsvorschlagen festlegen Falls eine vollautomatische Bewertung angestrebt wird sollten nur Metriken und Fra gen aus QOOD bernommen werden deren Berechnung bzw Beantwortung auto matisch m glich ist vgl Abschnitt 9 5 2 Dadurch entfallen zwangsl ufig alle Krite rien und Faktoren f r die weder objektive Metriken noch automatisch beantwortbare Fragen verf gbar sind Das spezifische Modell kann bei Bedarf auch noch um zus tzliche Bestandteile Fak toren Kriterien Metriken und Fragen erweitert werden darauf wird hier aber nicht n her eingegangen 9 6 Ableitung spezifischer Modelle 133 9 6 2 Wahl der Modellparameter In diesem Abschnitt werden einige Hinweise gegeben wie die Modellparameter eines spezifischen Modells festgelegt werden k nnen Der Einfachheit halber wird davon ausgegangen dass die nicht ben tigten Faktoren Kriterien Metriken und Fragen von QOOD bei der Spezialisierung nicht in das spezifische Modell bernommen wurden Faktoren
160. chvollziehbar gemacht werden Die bereits vorstellten Prinzipien Abschnitt 7 3 1 und Heuristiken Abschnitt 7 3 2 des Entwurfs sind der Versuch das Expertenwissen von seinem Tr ger unabh ngig 100 7 Entwurfsqualitat und allen Entwerfern zug nglich zu machen ebenso wie z B die Entwurfsmuster Obwohl es zur Anwendung dieser Entwurfsregeln doch wieder einiger Erfahrung bedarf liegt damit die Schwelle zur qualifizierten Entwurfseinsch tzung insgesamt niedriger Der menschliche Experte ist teilweise auch durch Checklisten oder Frage b gen ersetzbar Diese enthalten bestimmte Pr fkriterien die dazu geeignet sind potentielle Probleme aufzudecken Die Entscheidung ob ein identifiziertes potentiel les Problem ein echtes Problem ist setzt aber h ufig wieder Expertenwissen voraus Diskussion Die Beschreibung der vier Verfahren macht deutlich dass jedes seine besonderen St rken und Schw chen hat Folglich sind f r jedes Qualit tsattribut bestimmte Bewertungsverfahren besser geeignet als andere Das Bewertungsverfahren sollte also je nach Attribut variieren zum Teil sind auch Kombinationen sinnvoll Laut Bosch ist die Evaluation mit Szenarien vor allem f r Aspekte der Entwicklungsqualit t wie Wartbarkeit und Flexibilit t geeignet w hrend Simulation und mathematische Modellierung f r Aspekte der Betriebsqualit t wie Robustheit und Leistung besser sind F r subjektive Qualit tsattribute wie Verst ndlichkeit bleibt letzt
161. cost of making the corrections is far less Inspections should be a required part of every well run software process and they should be used for every software design every pro gram implementation and every change made either during original development in test or in maintenance Humphrey 1990 S 187 Da es in dieser Arbeit um Entwurfsbewertung geht wird hier der Bereich der analyti schen Qualit tssicherung genauer betrachtet Analytische Ma nahmen nehmen mehr oder minder explizit eine Bewertung der Qualit t des Pr fgegenstands vor indem nach M ngeln also Abweichungen vom Soll gesucht wird F r den Entwurf hat dabei das Review die gr te Bedeutung Der IEEE Standard 1028 1997 unterscheidet verschiedene Review Arten Management Review Audit technisches Review Inspektion und Walkthrough f r die Produktbewertung sind aber nur die letzten drei relevant Diese Verfahren sind relativ hnlich die wesentlichen Unterschiede liegen in der Zielsetzung und der Art der Durchf hrung z B ob L sungen f r M ngel oder Alternativen diskutiert werden oder nicht F r alle drei Verfahren gilt dass eine ganze Gruppe von Menschen daran beteiligt ist so dass f r Vorbereitung Durchf h 6 3 Qualitatssicherung 71 rung und Nachbereitung viel Personal und Arbeitszeit ben tigt wird Daher ist eine weitgehende Werkzeugunterst tzung w nschenswert z B bei der Identifizierung von M ngeln um den erforderlichen Aufwand zu reduzieren
162. d Wegner 1985 3 1 Begriffe 19 3 1 5 Abstrakte Klasse Eine abstrakte Klasse ist eine Klasse die nicht instantiiert werden kann Das liegt daran dass es Operationen in der Klasse gibt f r die keine Implementierung angege ben wurde abstrakte Operationen Weil keine Objekte der Klasse erzeugt werden k nnen scheinen abstrakte Klassen berfl ssig zu sein Sie sind aber f r die Model lierung sinnvoll weil alle Unterklassen gezwungen sind die abstrakten Operationen zu implementieren wenn sie konkret d h instantiierbar sein wollen Damit legt die abstrakte Klasse fest ber welche Schnittstelle ihre Unterklassen mindestens verf gen sollen Das gibt Sinn wenn die abstrakte Klasse ein allgemeines Konzept repr sentiert f r das keine allgemeine Implementierung angegeben werden kann Die Deklaration einer abstrakten Klasse erzeugt auch einen neuen Typ so dass polymor phe Variablen von diesem Typ deklariert werden k nnen Instanzen konkreter Unter klassen k nnen einer solchen Variablen zugewiesen werden In der UML Darstellung werden die Namen von abstrakten Klassen und die Signatur abstrakter Operationen kursiv gesetzt um sie von konkreten Klassen und Operatio nen abzuheben Alternativ kann man auch das Stereotyp abstract verwenden 3 1 6 Interface Ein Interface ist eine spezielle Form der abstrakten Klasse Es ist v llig abstrakt d h es besitzt keine Attribute und ausschlie lich abstrakte Operationen Dam
163. d auf der Basis des formalen Modells ODEM definiert das in Kapitel 5 eingef hrt wurde 9 1 2 Subjektive Metriken Die Quantifizierung durch objektive Metriken ist nicht immer m glich wie Card und Glass 1990 S 116 best tigen The intellectual nature of the software design process means that important components of the design must be measured subjectively Die tats chliche Qualit t eines Entwurfs h ngt in hohem Ma e von seinem Kontext und von semantischen Fragen ab die durch objektive Metriken schwer zu erfassen sind Lewerentz et al 2000 S 68 empfehlen zum Einsatz von Metriken zur Quali t tsbewertung Use them but do not trust them The ultimate assessment has to be done by human inspection Auch Dick und Hunter 1994 S 321 betonen die Bedeu tung der zus tzlichen subjektiven Bewertung durch einen Experten software evalu ation is best seen as a symbiosis of human and machine each performing the tasks to which it is best suited Der Computer bernimmt die Erhebung der automa tisierbaren objektiven Metriken w hrend sich der Mensch um die nicht automatisier baren subjektiven Metriken und die Gesamtbewertung k mmert 9 1 3 Frageb gen Um die subjektive Bewertung zu erleichtern werden Frageb gen angegeben die zur Pr fung auf erw nschte und unerw nschte Eigenschaften dienen Au erdem sorgen die Frageb gen daf r dass die Bewertungen durch verschiedene Bewerter nicht zu stark voneinander a
164. d power Was also ben tigt wird sind messbare Eigenschaften aus denen heraus sich Eleganz und Sch nheit begr nden lassen Dies geht aber bereits in die Richtung der produktbezogenen Sicht Die produktbezogene Sicht Die Qualit t des Entwurfs wird eindeutig ber ausgew hlte messbare Eigenschaften seiner selbst und seiner Bestandteile definiert Im Gegensatz zur herstellungsbezoge nen Sicht siehe unten sind diese Eigenschaften aber nicht von der Spezifikation des Systems abh ngig sondern es handelt sich um allgemeine Eigenschaften die jeder Entwurf haben sollte Die benutzerbezogene Sicht Die benutzerbezogene Sicht wird durch die Zugeh rigkeit des Verwenders des Ent wurfs zu den bereits diskutierten Interessengruppen bestimmt Jede Interessengruppe hat ihre eigene Qualit tsdefinition die dar ber hinaus noch f r jeden Vertreter einer Gruppe variieren kann Die benutzerbezogene Sicht ist subjektiv Die herstellungsbezogene Sicht Die Beurteilung der Qualit t erfolgt anhand der Qualit tsanforderungen aus der Spe zifikation Damit ist der Qualit tsbegriff des Entwurfs spezifisch f r jede Spezifika tion Bosch 2000 nimmt diese herstellungsbezogene Sicht ein und beschreibt meh rere Verfahren um einen Soll Ist Vergleich des Entwurfs hinsichtlich der Qualit tsanforderungen durchzuf hren siehe Abschnitt 7 6 Die kostenbezogene Sicht The ultimate goal of Software Engineering like any engineering is to achieve high
165. dass die Entwurfsqualit t bei der Wartung eine wesentliche Rolle spielt Arthur 1988 betont dies mit der Aussage Maintenance productivity is a direct function of the quality of the existing system Dass Anpassung und Erweiterung unvermeidlich sind hat sich auch schon in Geset zen des Software Engineerings niedergeschlagen Lehmans First Law of Software Evolution Lehman 1980 sagt A program that is used and that as an implementa tion of its specification reflects some reality undergoes continual change or becomes progressively less useful Das bedeutet das System wird sich im Laufe der Zeit ndern oder als unbrauchbar weggeworfen Bersoffs First Law of System Engineer ing Bersoff et al 1980 verscharft diese Aussage noch No matter where you are in the system life cycle the system will change and the desire to change it will persist 104 8 Das allgemeine Qualit tsmodell Verteilung nach Lientz Verteilung nach Sneed Wartungsart Swanson 1980 1988 Stabilisierung Optimierung 9 5 15 Anpassung 23 6 20 Erweiterung 41 8 40 Sonstiges 3 4 Tabelle 8 1 Aufwandsverteilung in der Wartung throughout the life cycle Das System wird sich also schon w hrend der Entwicklung ndern z B weil neue Anforderungen hinzukommen oder vorhandene Anforderun gen sich ndern Das Problem laufender nderungen am Entwurf wird durch evolution re Entwick lungsprozesse z B ext
166. der Objektorientierung finden sich bei Bunge 1977 1979 Bunge entwickelt eine Ontologie nach der die Welt aus substantiellen Indivi duen besteht die eine Identit t und Eigenschaften aufweisen Objekte Wand 1989 nutzt Bunges Ontologie um daraus ein formales Modell f r die Objektorientierung zu gewinnen Beispielsweise entstehen Klassen indem Objekte anhand der hnlich keit ihrer Eigenschaften zusammengefasst werden Aus dieser Weltsicht heraus ergibt sich die popul re Schlussfolgerung dass ein objektorientiertes Programm besser ver st ndlich und besser nderbar ist als ein prozedurales da der kognitive Unterschied zwischen Konstrukten der Anwendungswelt und den Konstrukten der L sungswelt geringer ist Jacobson et al 1995 S 42ff bezeichnen den Unterschied zwischen Anwendungs und L sungswelt als semantic gap Dieser sei bei der Objektorientie rung geringer als bei der strukturierten Entwicklung F r Rumbaugh et al 1993 ist die Klasse eine nat rliche Einheit der Modularisierung weshalb durch die objektori entierte Vorgehensweise klare und verst ndliche Entw rfe entstehen Berard 1993 Kap 2 empfiehlt die Verwendung des objektorientierten Ansatzes wegen seiner Vorteile aus technischer Sicht die zunehmende Akzeptanz moderner Programmierpraktiken z B Datenabstraktion h here Wiederverwendung und bes sere Erweiterbarkeit im Vergleich zum strukturierten Ansatz Allerdings ist bei einem Wechsel von der struktu
167. die Zahl der sinnvollen Alternativen schnell eingeschr nkt wer den was die Suche beschleunigt Konvergenz Die L sungsalternativen der vorhergehenden Phase werden bewertet und die L sung mit der besten Bewertung wird ausgew hlt Durch Einsatz von Checklisten kann bei der Bewertung sichergestellt werden dass alle erforderlichen Kriterien erf llt sind Die Bewertung der Alternativen kann auch auf quantitativer Basis durchgef hrt wer den z B durch Vergabe von Nutzwerten f r Bewertungskriterien Nutzwertanalyse Ein solches Vorgehen ist allerdings nicht unproblematisch wie Jones 1992 S 381 verdeutlicht All one is doing in ranking or weighting a set of objectives that cannot be otherwise compared is to conceal information about each objective that may well be useful in reaching a decision Totals arrived at by ranking and weighting mislead because scraps of information are being abstracted from reality and fitted together into arithmetical relationships that are probably different from the relationships in practice Bei einer Nutzwertanalyse ist also sicherzustellen dass alle relevanten Aspekte ber cksichtigt und Aspekte korrekt gewichtet sind um keine irref hrenden Resultate zu erhalten lang System B mittel Antwortzeit kurz System A S x xe gt xe an Ne xO o oe wf ok or gen ow We Se gen Mechanismus zur Prozesssynchronisation A yor Abbildung 4 3 Beispiel fiir einen zweidimensional
168. dung 7 3 und Abbildung 7 4 Im Vergleich zu Entwurf A besteht zwischen den Klassen weniger Kopplung Customer wei nichts mehr von Movie Die Kapse lung von Movie und Rental wurde ebenfalls verbessert so dass nun auch die drei get Methoden die von statement vorher ben tigt wurden entfallen k nnen getPriceCode getDaysRented getMovie Die Berechnung des Rechnungsbetrags ist st rker dezentra lisiert so dass das Problem der God Class Riel 1996 die den Entwurf dominiert und alle Funktionalit t an sich zieht vermieden wird Auf der anderen Seite ist die Berechnung nun ber drei Klassen verschmiert so dass alle drei Klassen betrachtet werden m ssen um den Algorithmus nachvollziehen zu k nnen Bei Entwurf A gen gte im Wesentlichen die Betrachtung der Klasse Customer apeo ude mi movie daysRented int setPriceCodetint 1 i getCharge int float EE naat Abbildung 7 3 Klassendiagramm f r Entwurf B statement Customer Sees statement ffor all rentals e getCharget getCharge days Abbildung 7 4 Sequenzdiagramm f r Entwurf B Zweite Stufe State Muster f r Movie Entwurf C entsteht aus B durch die Anwendung des State Musters Gamma et al 1995 Die Preisberechnung f r einen Film wird in eine abstrakte Klasse Price ausgela gert Zu Price gibt es f r jeden Preiscode eine konkrete Unterklasse die in der Methode getCharge den spezifischen
169. e Kommunikationsmuster zwischen Objekten w hrend der Laufzeit des Systems Als Beispiel f r verd chtige Muster nennt Cockburn Zyklen Andere Muster werden nicht genannt hier ist wohl vor allem die Erfahrung des Pr fers gefragt Erfahrene Entwerfer richten nach Cockburn ihr Augenmerk vor allem auf die Pr fung der Abstraktionen und der Verteilung der Verantwortlichkeiten Cockburn u ert die Vermutung dass sofern ber die zuk nftigen Ver nderungen nichts Genaues bekannt ist das Bestehen der beiden Pr fungen ein Indikator f r die Robustheit des Entwurfs ist 7 4 4 Kafura Kafura 1998 S 389ff gibt in einer Einf hrung in C eine Art Checkliste zur Evalua tion des Entwurfs einer einzelnen Klasse an Die Checkliste umfasst f nf verschiedene Kriterien jeweils mit einer Reihe von Unterkriterien 92 7 Entwurfsqualitat Abstraktion abstraction Stellt die Klasse eine brauchbare Abstraktion dar e Identit t Man kann einen einfachen einleuchtenden Namen f r die Klasse finden Denselben Test kann man auch auf Methoden anwenden e Klarheit Man kann den Zweck der Klasse vollst ndig in zwei kurzen pr zisen S t zen zusammenfassen e Einheitlichkeit Alle Methoden der Klasse arbeiten auf demselben Abstraktionsni veau Verantwortlichkeiten responsibilities Hat die Klasse eine sinnvolle Menge von Verantwortlichkeiten e Es ist klar welche Verantwortlichkeiten eine Klasse hat und welche nicht e Die Ve
170. e Attribute Methoden und Beziehungen haben sowie Bezeichner eine endliche L nge haben Dann kann es nur endliche viele Klassen mit einer bestimmten Anzahl von Attributen geben so dass die Bedingung erf llt ist Axiom W3 Das Axiom gilt Man w hle eine Klasse P mit einem Attribut a und eine Klasse Q mit einem Attribut b Dann gilt P Q A NAC P NAC Q Axiom WA Das Axiom gilt Man w hle eine Klasse P mit einem Attribut und eine funktional quivalente Klasse Q mit zwei Attributen z B P mit einem weiteren unn tigen Attribut Dann gilt P Q ANAC P NAC Q Axiom W5 Das Axiom gilt Werden zwei Klassen P und Q miteinander verschmol zen gehen keine Attribute verloren Daher ist die Zahl der Attribute in der kombi nierten Klasse mindestens so hoch wie in den Ursprungsklassen Damit gilt NAC P lt NAC P Q A NAC Q lt NAC P Q Axiom W6 Das Axiom gilt Man w hle P und O so dass sie gleich viele Attribute haben aber Q mindestens ein Attribut besitzt das P nicht hat R w hlt man gleich P Bei der Verschmelzung von P und R kommt nichts dazu bei der Verschmelzung von R und Q schon Die Reihenfolge spielt bei der Verschmelzung keine Rolle daher l sst sich das Beispiel auf a und b anwenden Damit gilt NAC P NAC Q ANAC P R NAC Q R A NAC R P NAC R Q Axiom W8 Das Axiom gilt weil das Umbenennen von Bezeichnern keinen Einfluss auf die Anzahl der Attribute hat Die am Beispiel gezeigte Beweisf hrung l sst sich auf
171. e Ber cksichtigung der Muster in den subjektiven Metriken angewiesen 151 Kapitel 11 Werkzeugunterstutzung Human errors can only be avoided if one can avoid the use of humans Parnas Clements 1986 S 251 In diesem Kapitel werden Werkzeuge zur Entwurfsbewertung vorgestellt Zun chst wird auf Werkzeuge eingegangen die in anderen Arbeiten entstanden sind Dann werden die Werkzeuge pr sentiert die f r das vorgestellte Bewertungsverfahren ent wickelt wurden Abschlie end wird ein ideales Werkzeug zur Entwurfsbewertung skizziert 11 1 Werkzeuge aus anderen Arbeiten In diesem Abschnitt werden bestehende Ans tze und Werkzeuge zur Entwurfsbewer tung vorgestellt unterschieden nach den Artefakten auf denen die Bewertung durch gef hrt wird Entwurf und Code 11 1 1 Qualit tsbewertung auf Entwurfsbasis Baumann 1997 Paunlann beschreibt ein Verfahren zur Bewertung von objektorien tierten Analysemodellen auf der Basis von fest vorgegebenen Metriken mit variablen Schwellenwerten und lol Tanzen Das Werkzeug MEMOS eine Erweiterung des MAOOAM Werkzeugs erhebt die Metriken und teilt sie mittels Schwellenwert und Toleranz in die drei Kategorien gering mittel und hoch ein Die derart aufbereiteten Messwerte werden dann zu Teilbewertungen pro Analyse Element und Qualit tskri terium und schlie lich zu einer Gesamtbewertung verdichtet Das Verfahren zur Ver dichtung und die Form des Berichts lassen sich ber Steuerdateie
172. e Craftsmanship Addison Wesley Boston 2001 181 McCabe 1976 McCabe T A Complexity Measure IEEE Transactions on Software Engineering 2 4 1976 308 320 McCall et al 1977 McCall J Richards P Walters G Factors in Software Quality Volumes I II and IH US Rome Air Development Center Report NTIS AD A 049 014 NTIS AD A 049 015 and NTIS AD A 049 055 1977 Melton et al 1990 Melton A Gustafson D Bieman J Baker L A Mathematical Perspective for Software Measures Research Software Engineering Journal 5 5 1990 246 254 Meyer 1991 Meyer B Eiffel The Language Prentice Hall Upper Saddle River NJ 1991 Meyer 1996 Meyer B The Many Faces of Inheritance A Taxonomy of Taxonomy IEEE Computer 29 5 1996 105 108 Meyer 1997 Meyer B Object Oriented Software Construction 2 Auflage Prentice Hall Upper Saddle River NJ 1997 Meyer 2001 Meyer B Software Engineering in the Academy IEEE Computer 34 5 2001 28 35 Mills 1980 Mills H The Management of Software Engineering Part I Principles of Software Engineering IBM Systems Journal 19 4 1980 414 420 Morschel 1994 Morschel I Applying Object Oriented Metrics to Enhance Software Quality In Dumke R Zuse H Hrsg Theorie und Praxis der Softwaremessung Deutscher Universit ts Verlag Wiesbaden 1994 97 110 Nelson 1990 Nelson T The Right Way to Think About Software Design In Laurel B Hrsg
173. e Intensive Systems IEEE Std 1471 2000 Ishikawa 1989 Ishikawa K Guide to Quality Control Quality Resource White Plains NY 1989 ISO IEC 8652 1995 Intermetrics Inc Ada 95 Reference Manual The Language The Standard Libraries ANSI ISO IEC 8652 1995 ISO IEC 9126 1991 ISO IEC Information Technology Software Product Evaluation Quality Characteristics and Guidelines for Their Use ISO TEC 9126 1991 ISO IEC Guide 25 1990 ISO TEC General Requirements for the Competence of Cal ibration and Testing Laboratories ISO IEC Guide 25 1990 Jackson 1975 Jackson M Principles of Program Design Academic Press London 1975 Jacobson et al 1995 Jacobson I Christerson M Jonsson P vergaard G Object Oriented Software Engineering A Use Case Driven Approach Addison Wesley Reading MA 1995 Jacobson et al 1998 Jacobson I Booch G Rumbaugh J The Unified Software Development Process Addison Wesley Reading MA 1998 Johnson Foote 1988 Johnson R Foote B Designing Reusable Classes Journal of Object Oriented Programming 1 2 1988 22 35 Jones 1992 Jones J Design Methods 2 Auflage Van Nostrand Reinhold New York 1992 Jones 1996 Jones C Applied Software Measurement Assuring Productivity and Quality 2 Auflage McGraw Hill New York 1996 Jones 1997 Jones C Software Quality Analysis and Guidelines for Success Thom son London 1997 Juran 1974 Juran
174. e Interfaces auf die Klasse zugegriffen wird ist das Problem des gerin gen Zusammenhalts nach au en also etwas abgemildert Besser w re es allerdings gewesen die Klasse Scheduler wirklich in drei verschiedene Klassen oder mehr auf zuspalten ndert sich n mlich bei einer der drei Aufgaben etwas muss jedes Mal die 10 2 Anwendung des Qualitatsmodells 145 lt lt interface gt gt Scheduler AdminDataAdapter currentPassword String addLine Line boolean numberOfPhysicalStations int changeLine Line boolean unseen int delLine String boolean getCurrentPassword String addLine Vector boolean loadPasswordFromFileQ String hke changeLine Line boolean retrieveLine String Line checkStation String boolean retrieveLines Enumeration delLine String boolean savePasswordToFile boolean getCurrentPassword String saveToFileAndUpdate String boolean IoadPasswordFromfFile String setPassword String retrieveConnection ConnectionBase Vector retrieveLine String Line retrievelines Enumeration retrieveStationsByPrefix String Enumeration savePasswordToFileQ boolean saveToFileAndUpdate String boolean SearchFrameDataAdapter setPassword String checkStation String boolean addFoundConnections Yector boolean retrieveConnection ConnectionBase Vector calcOneConnection ConnectionBase Station retrieveStationsByPr
175. e Praxis Focus on a few key quality characteristics rather than attempt to measure everything Au erdem empfehlen sie rely on simple measures extractable from common design products blicherweise vorliegende Entwurfsartefakte sind relativ vollst ndige Klassendiagramme sowie vereinzelte Sequenz und Zustandsdia gramme Eine Quantifizierung muss dies ber cksichtigen da man nur das messen kann was auch vorhanden ist Verwendet werden daher nur Metriken die sich auf UML Klassendiagrammen gem dem Referenzmodell ODEM erheben lassen 8 1 3 M gliche Qualit tsattribute Dennoch ist es interessant sich zun chst zu berlegen was denn potentiell bei der Entwurfsbewertung ber cksichtigt werden k nnte um dann aus dem Angebot aus zuw hlen Die folgende Liste m glicher Qualit tsattribute wurde auf der Basis der berlegungen des vorhergehenden Kapitels zusammengestellt e Qualit t der Entwurfsdokumentation z B Vollst ndigkeit Verst ndlichkeit ber sichtlichkeit und Nachvollziehbarkeit von Entwurfsentscheidungen e Brauchbarkeit des resultierenden Systems z B Abdeckung der Anforderungen in Hinblick auf Funktion und Qualit t z B Effizienz Benutzerfreundlichkeit e Implementierbarkeit Realisierbarkeit in Hinblick auf Technologie Organisation und Wissen bzw Erfahrung Wissenstr ger ist vor allem das Personal e Kosten der Realisierung z B f r Bausteine Soft und Hardwarekomponenten Werkzeuge Sch
176. e der Klasse und ihrer Oberklasse gleichzeitig verwendet werden Es gibt daher Empfehlungen nur Spezialisierungsvererbung am besten in Form von Schnittstellenvererbung zu verwenden 3 1 4 Polymorphismus und dynamisches Binden Polymorphismus ist die F higkeit eines Dinges verschiedene Gestalt anzunehmen In der Objektorientierung gibt es zwei Formen des Polymorphismus Datenpolymor phismus und Funktionspolymorphismus Datenpolymorphismus ist die F higkeit einer Variablen Objekte verschiedener Klas sen aufzunehmen In ungetypten Sprachen wie Smalltalk ist dies allgemein m glich d h es k nnen beliebige Objekte abgelegt werden In getypten Sprachen wird der Datenpolymorphismus auf Objekte des Iyps der Variablen und dessen Untertypen eingeschr nkt d h Variablen von einem Klassentyp k nnen nur Objekte von ihrem Typ oder eines Untertyps aufnehmen Funktionspolymorphismus bedeutet dass verschiedene Operationen denselben Namen tragen z B berladen von Operationen Nur anhand des Zielobjekts des Aufrufs und der Parameter kann entschieden werden welche Methode aufgerufen wird Ist gleichzeitig Datenpolymorphismus erlaubt kann wegen m glicher Redefini tionen erst zur Laufzeit entschieden werden welche Methode aufgerufen wird Man spricht dann von dynamischer Bindung Eine detailliertere Betrachtung des Polymorphismus Begriffs und eine feinere Unter scheidung der verschiedenen Arten von Polymorphismus findet sich bei Cardelli un
177. e zu benutzenden Linien angegeben sowie die Umsteigehaltestellen die Abfahrtszeitpunkte an der Starthaltestelle und allen Umsteigehaltestellen und der Ankunftszeitpunkt an der Zielhaltestelle Umsteigezeiten Aufenthaltszeiten an der Umsteigehaltestelle von mehr als 60 Minuten f hren dazu dass eine Verbindung ung ltig ist Solche Verbindungen werden grunds tzlich nicht betrachtet Findet das System mehr als eine Verbindung die das gew nschte Optimierungsziel erf llt so werden alle m glichen Verbindungen angezeigt Wurde eine Verbindung gefunden und angezeigt so muss der Benutzer die M glich keit haben sich die n chste Verbindung anzeigen zu lassen Das System soll dann eine Verbindung anzeigen die mindestens eine Minute sp ter startet aber dieselben Optimierungsziele verfolgt Wurde eine Verbindung gefunden und angezeigt so muss der Benutzer die M glich keit haben die Verbindung auszudrucken Es wird eine HTML Datei mit einem generierten aber beliebigen Namen in das Verzeichnis geschrieben in dem das Pro gramm gestartet wurde Diese Datei enth lt eine HTML Seite auf der die entspre chende Verbindung beschrieben ist Das Programm berschreibt niemals existierende Dateien sondern generiert einen eindeutigen Dateinamen Dieser Dateiname wird dem Benutzer angezeigt Es obliegt nun dem Benutzer die Datei weiterzubearbeiten das Programm fasst diese Datei nicht mehr an Es ist insbesondere nicht f r das Anzeigen in eine
178. ecture Perspectives on an Emerging Discipline Prentice Hall Upper Saddle River NJ 1996 Shepperd Ince 1993 Shepperd M Ince D Derivation and Validation of Software Metrics Clarendon Press Oxford 1993 Shull et al 1999 Shull F Travassos G Basili V Towards Techniques for Improved Design Inspections Proceedings of the 3rd Workshop on Quantitative Approaches in Object Oriented Software Engineering QAOOSE 1999 Lisbon 1999 Simon 1962 Simon H The Architecture of Complexity Proceedings of the Ameri can Philosophical Society 106 6 1962 467 482 184 Literatur Simon et al 2001 Simon F Steinbriickner F Lewerentz C Anpassbare explorier bare virtuelle Informationsr ume zur Qualit tsbewertung gro er Software Systeme Erste Erfahrungen Proceedings of the Third Workshop on Reengineering Bad Hon nef 2001 Slaughter Banker 1996 Slaughter S Banker R A Study of the Effects of Software Development Practices on Software Maintenance Effort Proceedings of the Interna tional Conference on Software Maintenance ICSM 96 Monterey CA IEEE Computer Society Press Los Alamitos 1996 197 205 Smith Robson 1990 Smith M Robson D Object Oriented Programming Pro ceedings of the Conference on Software Maintenance San Diego CA IEEE Computer Society Press Los Alamitos CA 1990 272 281 Sneed 1988 Sneed H Einleitung zu Wix B Balzert H Hrsg Softwarewartung BI Wis
179. eduction Top 10 List IEEE Computer 34 1 2001 135 137 Boehm In 1996 Boehm B In H Identifying Quality Requirement Conflicts IEEE Software 13 2 1996 25 35 Boehm et al 1978 Boehm B Brown J Kaspar H Lipow M MacLeod G Mer ritt M Characteristics of Software Quality North Holland Amsterdam 1978 Booch 1987 Booch G Software Engineering with Ada 2 Auflage Benjamin Cummings Menlo Park CA 1987 Booch 1994 Booch G Object Oriented Analysis and Design with Applications 2 Auflage Benjamin Cummings Redwood City CA 1994 Booch et al 1998 Booch G Rumbaugh J Jacobson I The Unified Modeling Lan guage User Guide Addison Wesley Reading MA 1998 Bosch 2000 Bosch J Design and Use of Software Architectures Addison Wesley Harlow 2000 Bowen et al 1984 Bowen T Wigle G Tsai J Specification of Software Quality Attributes Volumes I II and III Boeing Report D182 11678 1 D182 11678 2 and D182 11678 3 1984 Box 1979 Box G Some Problems of Statistics and Everyday Life Journal of the American Statistical Association 74 365 1979 1 4 Briand et al 1997 Briand L Daly J W st J A Unified Framework for Cohesion Measurement in Object Oriented Systems ESE Report 040 97 E 1997 172 Literatur Briand et al 1998 Briand L W st J Lounis H Investigating Quality Factors in Object Oriented Design An Industrial Case Study Technic
180. efix String Enumeration eanUpConnection Vector Vector reateConnectionBlock String Connection jGetDad Station Station jGetYalfstation Time jlnitPriorityQueue Heap Time jkstra Heap String Optimization dijSetDad Station ijSet al Station Time ijUpdateQueue Station Priority AdjStation Time Optimization Heap getStationByName String Station getStationByNameAndLine String Line Station initStationHashTable isinTimeRange Time boolean IoadScheduleFromFile boolean notinAlreadyStartedStations Station boolean removeDuplicatesAndAdd Station retOTTConnection ConnectionBase Station Vector search Within24Hours ConnectionBase Vector Station boolean setAllDadStations Station switchToOTA Vector ConnectionBase Abbildung 10 6 God Class bei Gruppe 6 lt lt interface gt gt t tt tt tt tt 3 CH 22229 a a Klasse ge ndert werden was potentiell alle Benutzer der Klasse betreffen kann Weil Scheduler quasi die gesamte Funktionalit t des Programms realisiert oder steuert sind das fast alle Klassen im System 10 2 3 Modellvalidierung Zur Validierung des Modells wird die Bewertung der Wartbarkeit mit tats chlichen Wartungsaufw nden der Implementierung verglichen um die Vorhersagef higkeit des Modells zu berpr fen Idealerweise f llt der Wartungsaufwand um so niedriger aus je besser die Bewertung der Wartbarkeit aufgrund des Entwurfs ist Da
181. egr ndung daf r angegeben Quellen F r die Frageb gen f r den Faktor Wartbarkeit wurde unter anderem Material aus den folgenden Quellen verwendet e Balzert 1999 gibt mehrere Checklisten f r objektorientierte Analysemodelle an die sich auf den Entwurf bertragen lassen e Booch et al 1998 geben in ihrem UML Handbuch Listen mit erw nschten Eigen schaften f r die Bestandteile des UML Modells an e Page Jones 1995 enth lt eine Checkliste f r Klassen e McBreen 2000 gibt eine Checkliste f r den objektorientierten Entwurf an e Riel 1996 gibt viele Heuristiken an die gute und schlechte Entwurfseigenschaften beschreiben Daraus lassen sich leicht Fragen f r einen Fragebogen generieren e Die Qualit tsmodelle aus Abschnitt 7 4 liefern weitere Fragen Zwischen diesen Quellen gibt es gro e inhaltliche berlappungen so dass zun chst ein Abgleich stattfand Da hier davon ausgegangen wird dass die UML Modelle wohlgeformt sind wurde auf Fragen verzichtet welche die Wohlgeformtheit ber pr fen Eine solche Pr fung kann ein UML Werkzeug automatisch durchf hren Kann eine Frage nicht vollkommen positiv beantwortet werden sollte zus tzlich notiert werden was der Grund f r die Abwertung ist Die so entstehende Mangelliste ist f r eine sp tere berarbeitung des Entwurfs sehr n tzlich 204 B Frageb gen f r QOOD Darstellung Die Bedingungen der Fragen werden durch Pr dikate formalisiert Die Pr dik
182. eibung von Situationen Jemand der gelernt hat Situationen nach bestimm ten Regeln zu beschreiben wird auch dazu neigen Situationen gem diesen Regeln wahrzu nehmen und zu speichern Dorner 1976 S 53 22 3 Objektorientierung Bei der Einf hrung der Begriffe im vorhergehenden Abschnitt wurde bereits die UML Notation verwendet Hier soll nun ein kleiner berblick dar ber gegeben wer den was UML ausmacht Rumbaugh et al 1998 S 3 umrei en die Aufgabe der UML wie folgt The Unified Modeling Language UML is a general purpose visual modeling language that is used to specify visualize construct and document the arti facts of a software system Booch et al 1998 und Oestereich 1998 geben eine aus f hrliche Einf hrung in UML Als Referenz f r die bersetzung von UML Begriffen ins Deutsche wurde das Glossar von Oestereich 1998 verwendet In UML gibt es verschiedene Diagrammtypen Booch et al 1998 S 24ff 1 Klassendiagramm class diagram zeigt Klassen Interfaces Pakete und ihre Bezie hungen 2 Objektdiagramm object diagram zeigt Objekte und ihre Beziehungen 3 Anwendungsfalldiagramm use case diagram zeigt Anwendungsf lle Aktoren und ihre Beziehungen 4 Sequenzdiagramm sequence diagram ein Interaktionsdiagramm das die zeitli che Ordnung des Austauschs von Nachrichten zwischen Objekten darstellt 5 Kollaborationsdiagramm collaboration diagram ein Interaktionsdiagramm das
183. eichert Es wird ebenso kein Unterschied zwischen Ankunfts und Abfahrtszeiten an Zwischenhalte stellen gemacht d h die Z ge haben an Zwischenhaltestellen keinen Aufenthalt die Ankunfts und die Abfahrtszeit ergibt sich durch die Startzeit an der Endhaltestelle und die Addition der Fahrzeiten Es soll keine Unterscheidung zwischen Wochentagen und Wochenende gemacht wer den Alle Linien fahren an allen Tagen zu den gleichen Zeitpunkten Aufbau der Fahrplandatei Die Fahrplandatei ist eine reine Textdatei die aber auch Umlaute enthalten kann Die Zeichen sind nach ISO 8859 1 kodiert landl ufig als Latin 1 Zeichensatz bezeichnet dies ist der Standardzeichensatz unter Solaris Linux Die Fahrplandatei besteht aus einzelnen Abschnitten die jeweils genau eine Linie beschreiben Die einzelnen Abschnitte sind durch eine Leerzeile voneinander getrennt Au er dem Zeilentrenner steht kein Zeichen in diesen Zeilen Nach dem letzten Abschnitt endet die Datei unter Umst nden ohne eine zus tzliche Leerzeile Die Abschnitte sind nach folgendem Muster aufgebaut 1 Zeile Name der Linie Bsp S1 2 Zeile Name der ersten Endhaltestelle Bsp Herrenberg 3 Zeile Name der anderen Endhaltestelle Bsp Plochingen 4 Zeile Abfahrzeiten an der ersten Endhaltestelle 5 Zeile Abfahrzeiten an der anderen Endhaltestelle C 2 Anforderungen 223 alle weiteren Zeilen Haltestellen zwischen erster und zweiter Endhaltestelle Diese Darstellung imp
184. ein die Anzahl der Attribute einer Klasse sowohl mit als auch ohne geerbte Attribute zu z hlen Das eine ist ein Ma f r die tats chliche Gr e das andere ein Ma f r die Gr e der Klassendefinition in einer Programmiersprache Daher werden zu den Z hlmetriken Verfeinerungen angeboten z B bei der Anzahl der Attribute eine Unterscheidung in geerbte und nicht geerbte Diese Verfeinerungen brauchen nur bei Bedarf betrachtet werden und erh hen daher die Komplexit t des Modells nur unwesentlich Andererseits erlauben sie eine differenziertere Betrachtung Es sollen m glichst einfache Metriken verwendet werden Komplexe zusammenge setzte Metriken sind schwieriger zu verstehen zu erheben und zu validieren als einfa che Metriken Kitchenham et al 1990 schreiben dazu It would therefore seem pref erable to use design metrics based on primitive counts rather than synthetics unless it is very clear how the values obtained from the synthetics may be interpreted Im Zuge der Erstellung spezifischer Qualit tsmodelle k nnen immer noch komplexe Metriken auf der Basis der einfachen Metriken eingef hrt und validiert werden Die ausgew hlten Metriken sollen m glichst viele Aspekte des Kriteriums abdecken Gleichzeitig sollen sie aber auch m glichst voneinander unabh ngig sein Das bedeu tet dass derselbe Sachverhalt nicht mehrfach gemessen werden soll weil er sonst unbeabsichtigt ein zu hohes Gewicht bekommt Beispielsweise sind d
185. eine Suite von objektorien tierten Metriken publiziert haben Wohl auch deshalb hat die Suite eine hohe Popula rit t Hier wird die zweite Version von 1994 zur Formalisierung verwendet Weighted Methods per Class WMC WMC ist die Summe der Komplexit ten der Methoden einer Klasse Je geringer WMC desto besser Die Definition der Komplexi t t ist absichtlich offen gelassen WMC wird meistens mit einer Standardkomplexit t von 1 verwendet auch von den Autoren selbst vgl Chidamber Kemerer 1998 Lei der haben die Autoren erst sp ter genauere Aussagen dar ber gemacht welche Methoden gez hlt werden sollen Chidamber Kemerer 1995 Die Hauptinterpreta tion vom WMC in der Literatur ist es nur lokal definierte Methoden zu z hlen ein schlie lich Redefinitionen Da ODEM nur Operationen und keine Methoden betrach tet kommen Redefinitionen allerdings nicht vor Es werden sowohl Klassen als auch Instanzmethoden gez hlt WMC c o O has c o Depth of Inheritance Tree DIT DIT ist die maximale Lange aller Vererbungspfade von der Klasse zu den Wurzelklassen der Vererbungshierarchie Je geringer DIT desto besser Hier wird eine rekursive Definition angegeben DIT c if dde CUI extends c d then 1 maxgec extends c d DIT d else 0 Number of Children NOC NOC ist die Anzahl der direkten Unterklassen einer Klasse Ein hoher Wert deutet sowohl auf bessere Wiederverwendung als auch auf den Missbrauch von Vererbung u
186. eine gerin gere Anderungswahrscheinlichkeit NCP number of abstract classes in a package NCP p ceC contains p c A c isAbstract NCP number of concrete classes in a package NCP p ceC contains p c A c isAbstract Die beiden Verfeinerungen von NCP lassen sich auch kombinieren System Auf Systemebene z hlt man alle Attribute Operationen Klassen Interfaces und Pakete NAS number of attributes in the system NAS S A NOS number of operations in the system NOS S IO 192 A Metriken fur QOOD NCS number of classes in the system NCS S IC NIS number of interfaces in the system NIS S II NPS number of packages in the system NPS S P 1 daSinP enthalten ist ist 1 abzuziehen Jede Eigenschaft ob vererbt oder nicht wird bei den Metriken NAS und NOS grund s tzlich nur einmal gez hlt Deshalb kann man hier nur nach Sichtbarkeitsbereich und nach Zugeh rigkeit zu Klasse oder Objekt verfeinern analog zu NAC und NOC NCS NIS und NPS k nnen nach Sichtbarkeitsbereich verfeinert werden ana log zu NCP NIP und NPP Bei der Metrik NCS kann man auch nach abstrakten und konkreten Klassen verfeinern analog zu NCP diese Verfeinerung ist mit der nach Sichtbarkeitsbereich kombinierbar A 2 Strukturiertheit Die Messung der Strukturiertheit konzentriert sich hier auf die Form der hierarchi schen Strukturen d h der Vererbungshierarchie der Klassen Interfaces und der
187. einem Ort zusammengefasst sind Welleneffekte treten daher in geringerem Ma e auf 8 3 5 Einheitlichkeit Definition Ein Entwurf ist einheitlich wenn er einem einheitlichen Stil folgt auch bekannt als konzeptionelle Integrit t siehe Abschnitt 7 3 1 Der Entwurf soll auch wenn er von verschiedenen Personen und in mehreren Iterationen bearbeitet wurde so aussehen als sei er von einer Person in einem Guss erzeugt worden Diskussion Einheitlichkeit erh ht die Verst ndlichkeit des Entwurfs Sie kann mit einfachen Mit teln wie Namenskonventionen erreicht werden Auch die Einhaltung von Standards auf die in der Entwurfsdokumentation hingewiesen werden muss ist hilfreich Die Konventionen und Standards sollten so gew hlt sein dass alle Entwickler die den Entwurf bearbeiten oder als Vorlage f r die Implementierung verwenden sollen mit ihnen vertraut sind 8 3 6 Dokumentierung Definition Dokumentierung ist die G te der Darstellung des Entwurfs in der Entwurfsdoku mentation Sie wird beeinflusst durch die Wahl und Nutzung der Notation die Struk turierung der Dokumentation und deren Vollst ndigkeit Diskussion Die Dokumentation ist f r die Verst ndlichkeit wichtig weil sie Bedeutung und Zweck der Entwurfsbestandteile sowie ihr Zusammenspiel festh lt Sie sollte gut strukturiert sein d h sich durch ihren Aufbau dem Leser leicht erschlie en Au er dem sollte sie vollst ndig konsistent pr zise und korrekt sein
188. elle f r den objektorientierten Entwurf vorgestellt Die wenigsten sehen eine quantitative Bewertung vor Diese Modelle eig nen sich daher besser f r eine qualitative Bewertung bzw f r eine M ngelanalyse auf der Basis von Frageb gen und Checklisten Ein quantitatives validiertes Qualit ts modell findet sich bei Erni 1996 es ist jedoch nur f r die Bewertung der Wartbarkeit von Rahmenwerken gedacht Auch dieses Qualit tsmodell dient vor allem der M n gelanalyse auf eine Gesamtbewertung wird verzichtet Nur bei Bansiya und Davis 2002 gibt es eine Gesamtbewertung die durch teilweise gewichtete Aggregation von Metriken entsteht Eine Gesamtbewertung ist Voraussetzung f r den Vergleich von Entwurfsalternativen die auch durch spezifische Modelle auf der Basis von QOOD erm glicht wird Bewertungstechniken Wie in Abschnitt 7 6 gezeigt gibt es verschiedene Techniken zur Bewertung von Ent w rfen Szenarien Simulation Metriken Frageb gen und Checklisten Metriken wer den h ufig zur Bewertung verwendet z B arbeiten fast alle der in Abschnitt 11 1 vor gestellten Arbeiten mit Metriken Allerdings werden die Metriken nie exakt definiert ein Mangel der in dieser Arbeit durch die Einf hrung des Referenzmodells ODEM vermieden wird Au erdem werden hier die objektiven Metriken mit Frageb gen und subjektiven Metriken kombiniert Dies hat sich als vorteilhaft erwiesen weil die Frageb gen die Unzul nglichkeiten der objektiven M
189. ellen Als Folge ergeben sich unn tige Redundanz und hohe wechselsei tige Abh ngigkeiten zwischen den Teilsystemen Dies bedingt eine hohe Kommuni kation zwischen den Entwicklergruppen da h ufig ber Schnittstellen neu verhan delt werden muss Auf diese Weise nimmt nicht nur Implementierungsaufwand zu sondern auch der Wartungsaufwand Die empfohlene Vorgehensweise ist deshalb dass zun chst ein kleines Architektur team etwa drei bis f nf Entwickler in Ruhe einen Architekturentwurf ausarbeitet Es kann auch sinnvoll sein einen Chefarchitekten zu bestimmen der in Zweifelsf llen die letzte Entscheidung trifft und einen einheitlichen Stil durchsetzt Wenn der Archi tekturentwurf fertig ist k nnen Untergruppen gebildet werden welche die Teilsys teme und Komponenten unter der Aufsicht der Architekturteams fertig entwerfen und dann implementieren Die Personalausstattung eines Projekts sollte entspre chend angepasst werden Zu Beginn des Entwurfs wird nur wenig Personal einge setzt In der Implementierungsphase wird dann das Personal aufgestockt weil sich die Arbeit besser verteilen l sst Notfalls k nnen berfl ssige Teammitglieder w h rend des Architekturentwurfs auch mit der Ausarbeitung von Testfallen und des Benutzerhandbuchs auf der Basis der Spezifikation besch ftigt werden 4 5 3 Technologie Even if we knew the requirements there are many other facts that we need to know to design the software Many of the detai
190. en Attribute e name Name Der Name der Klasse 50 5 Ein Referenzmodell fur den objektorientierten Entwurf e isAbstract Boolean Klassen k nnen abstrakt Wert true oder konkret Wert false sein e visibility VisibilityKind Bedeutung und Herleitung analog zu der bei den Paketen Beziehungen e extends C x C Eine Klasse erweitert eine Oberklasse d h sie erbt von ihr Eine Klasse kann belie big viele Oberklassen erweitern auch keine Die Ableitung vom UML Metamodell ist analog zur extends Relation bei Interfaces e realizes C xI Eine Klasse realisiert ein Interface Eine Klasse kann beliebig viele Interfaces reali sieren auch keine Im UML Metamodell steht die Klasse Abstraction eine Unterklasse von Dependency f r diese Beziehung realizes k i gilt genau dann wenn es eine Instanz a von Abstraction mit Stereotyp realize gibt bei der die Rolle a supplier mit i und die Rolle a client mit k belegt ist e has CxO Eine Klasse besitzt eine Operation Eine Klasse kann beliebig viele Operationen haben auch keine Geerbte Operationen z hlen nicht mit Die Ableitung vom UML Metamodell ist analog zur has Relation bei den Interfaces e has Cx A Eine Klasse besitzt ein Attribut Eine Klasse kann beliebig viele Attribute haben auch keine Geerbte Attribute z hlen nicht mit Die Ableitung vom UML Meta modell ist analog zur obigen has Relation da Feature auch Oberklasse von Attribute ist e associates C x C U
191. en unter denen man den Begriff Qualit t in Bezug auf ein Produkt definieren kann e transzendent transcendent e produktbezogen product based e benutzerbezogen user based e herstellungsbezogen manufacturing based e kostenbezogen value based Transzendente Sicht Die transzendente Sicht besagt dass Qualit t etwas Absolutes und universell Erkenn bares ist eine Art innewohnende Vortrefflichkeit Jeder kann lernen sie zu erkennen aber nur durch Erfahrung nicht durch Analyse Qualit t entzieht sich jeder Analyse sie kann nicht pr zise definiert werden Anhand von Beispielen die Qualit t besitzen kann man aber lernen Qualit t zu erkennen Hier gibt es deutliche Parallelen zum Begriff der Sch nheit der nach Platon ebenfalls nicht definiert sondern nur erfahren werden kann Pirsig 1981 S 185 formuliert das wie folgt But even though Quality cannot be defined you know what Quality is Das d rfte auch der Grund sein warum der Architekt Christopher Alexander der Qualit t die er bei seiner Architektur anstrebt den Namen quality without a name gegeben hat Alexander 1977 1979 Diese Qualit t ist etwas Reales und Objektives das jedoch nicht in Worte gefasst werden kann There is a central quality which is the root criterion of life and spirit in a man a town a building or a wilderness This qual ity is objective and precise but it cannot be named Alexander 1979 S ix Produktbezogene Sich
192. en verschiedene Alternativen auszuarbeiten Unter den so entstehenden alternativen L sungsans tzen ist es schwer zu w hlen An die Frage Welches ist die beste Alternative schlie t sich gleich die Frage an Wie k n nen die Alternativen bewertet werden um statt einer gef hlsm igen eine m glichst objektive Antwort zu erhalten Ein Ansatz dazu ist die Verwendung eines Qualit ts modells das die Zielkriterien die der Entwurf zu erf llen hat klar definiert Dadurch wird das dialektische Problem n her an ein Interpolationsproblem herangebracht Entwurfsausbildung Eine einfache L sung f r den Umgang mit der fundamentalen Komplexit t des Ent wurfs gibt es nicht Man kann allerdings bei der Ausbildung der Entwerfer ansetzen um diese so gut wie m glich auf ihre Aufgabe vorzubereiten Brooks 1987 S 18 stellt fest Great designs come from great designers Nach Brooks w re es am bes ten gro artige Entwerfer auszubilden und nur diese einzusetzen Einen solchen Ent werfer zeichnen aus Curtis et al 1988 Visser Hoc 1990 4 5 Probleme des Entwurfs 41 e die Vertrautheit mit dem Anwendungsbereich siehe auch Adelson Soloway 1985 Dvorak Moher 1991 e die F higkeit die technische Vision den anderen Projektmitgliedern mitzuteilen da der Entwurf oft durch Kommunikation mit anderen entsteht e die Identifikation mit dem Projekterfolg und e eine opportunistische Vorgehensweise d h Entscheidungen zu vertagen
193. en Endes wohl eine Begutachtung durch den Menschen erforderlich auch wenn es automatisch messbare Indikatoren daf r gibt In dieser Arbeit wird daher ein Bewertungsverfah ren verwendet das eine Kombination aus Expertensch tzung und mathematischer Modellierung mit Entwurfsmetriken ist Da es bei der Entwurfsbewertung vor allem darum geht zuk nftige Kosten vorherzu sagen bleibt es zum Zeitpunkt der Bewertung ungewiss ob die gemessene Qualit t des Entwurfs zutreffend ist Wie jede Vorhersage der Zukunft kann die Bewertung mehr oder weniger falsch sein Durch geeignete Validierung des Bewertungsverfah rens l sst sich zwar die statistische Sicherheit des Eintreffens der Vorhersage erh hen absolute Sicherheit gibt es aber nicht 76 2 Quantitative Bewertung Die Bewertung ist grunds tzlich in qualitativer und quantitativer Form m glich Die qualitative Bewertung erlaubt nur relative Aussagen in Bezug auf ein einzelnes Quali t tsattribut z B dass eine Entwurfsalternative portabler ist als eine andere F r einen Alternativenvergleich ist die qualitative Bewertung ausreichend sofern nur ein Attri but betrachtet wird und es unwichtig ist um wie viel besser die eine Alternative als die andere ist Wenn mehrere Qualit tsattribute in die Bewertung einflie en sollen k nnen nur bei einer quantitativen Bewertung fundierte relative Entwurf A ist besser als B und absolute Aussagen Entwurf A ist gut Entwurf B ist befriedigend gemacht
194. en Entwurfsraum Abbildung 4 3 zeigt einen zweidimensionalen Entwurfsraum der zwei Dimensionen hat Mechanismus zur Prozesssynchronisation und Antwortzeit Der Mechanismus repr sentiert eine Entwurfsentscheidung die Antwortzeit ein Bewertungskriterium 4 2 Klassifikationen des Entwurfs 27 In diesem Entwurfsraum sind zwei Systeme A und B positioniert worden Man sieht anhand der L cken in der Darstellung dass einige Entwurfsalternativen bisher nicht betrachtet und eingeordnet wurden Au erdem ist sofort ersichtlich welches das bes sere System hinsichtlich der Antwortzeit ist Bemerkungen Der tats chliche Entwurfsprozess ist nicht so geradlinig wie gerade dargestellt Der Entwurf verl uft eher ungeordnet Zum einen muss das Wissen ber Anforderungen und Entwurfskontext z B Technologien vom Entwerfer erst einmal aufgenommen werden Zum anderen sind viele Entwurfsziele gegeneinander abzuw gen so dass man leicht etwas bersieht und berarbeitungen notwendig werden Der Entwurfs prozess verl uft daher in der Praxis iterativ und opportunistisch Robbins 1998 Eine Automatisierung des Entwurfsprozesses ist im Allgemeinen unm glich Einzig bei der Konvergenzphase ist die Automatisierung mit Hilfe eines Computers ber haupt denkbar denn die ersten beiden Phasen des Entwurfsprozesses sind hochgra dig kreativ Brooks 1987 Damit sind aber gerade die schwierigsten Phasen des Ent wurfs nicht automatisierbar Glass 1999
195. en an die bei einer Entwurfsbe wertung angewendet werden sollen Ihrer Meinung nach werden Entwurfskriterien ben tigt um das Entwickeln eines schlechten Entwurfs zu verhindern Guter Entwurf bedeutet f r sie eher schlechte Eigenschaften zu vermeiden als aus dem Stand einen perfekten Entwurf abzuliefern Letzteres sei n mlich v llig unrealistisch Kopplung coupling Wie Booch 1994 unterscheiden Coad und Yourdon zwei Arten der Kopplung durch Interaktion entspricht der Kopplung durch Verwen dung und durch Vererbung Um eine geringe Interaktionskopplung zu erreichen wird vorgeschlagen die Anzahl der versendeten und empfangenen Nachrichten zu 90 7 Entwurfsqualitat minimieren und die Anzahl der Parameter einer Nachricht auf drei zu limitieren Die Delegation von Nachrichten an andere Objekte wird als Ursache f r unn tige Interak tionskopplung angesehen Die Vererbungskopplung soll hingegen hoch sein Die Vererbung spiegelt vornehm lich Generalisierungs Spezialisierungsbeziehungen Das Uberschreiben von geerb ten Attributen oder ein Erben ohne Erweiterung sind Indikatoren fiir eine geringe Vererbungskopplung da keine wirkliche Spezialisierung vorliegt Zusammenhalt cohesion Drei Ebenen des Zusammenhalts werden unterschie den Methode Klasse und Vererbungshierarchie Methoden sollten nur genau eine Funktion haben Klassen sollten nur Attribute und Methoden haben die aufgrund der Verantwortlichkeiten der Klasse notwendig
196. en ein Aus zug aus dem Fahrplan des Verkehrsverbunds Stuttgart VVS zur Verf gung In Tabelle 10 1 sind einige Kennzahlen der zw lf Projekte angegeben graphisch auf bereitet in Abbildung 10 1 e Java Dateien Anzahl der Java Dateien der Implementierung Die Anzahl der Java Dateien dient zur Absch tzung der Anzahl der implementierten Klassen und Inter faces e Codezeilen Anzahl der Java Codezeilen der Implementierung Die Codezeilen enthalten auch Leerzeilen und Kommentare Da die Gruppen unterschiedlich viel Kommentare im Code haben kommt es hier zu einer gro en Varianz e Projektaufwand in Personenstunden der gesamte Aufwand des Teams f r die Durchf hrung des Projekts Beim Projektaufwand ist ein gr erer Messfehler m g lich da die Zahlen auf den Angaben der Teilnehmer beruhen und diese teilweise erst nach Ende des Projekts ihren Aufwand gesch tzt haben Gruppe 1 OI OI NI Oo oa BR WwW Nh CH 11 12 Durchschnitt Minimum Median Maximum Tabelle 10 1 Projektkennzahlen der Gruppen 10 1 2 Faktoren und Kriterien Java Dateien 21 21 25 26 27 34 38 39 42 43 47 56 35 21 36 56 Codezeilen 6795 4029 5671 4661 8488 7450 5458 7826 8946 6907 9734 8804 7064 4029 7178 9734 Projektaufwand h 486 331 577 455 693 498 333 510 485 610 447 581 501 331 492 693 Um die zw lf Entwurfsalternativen vergleichen zu k nnen ist es am praktischsten mittels des s
197. en m ssen aber speziell f r jedes spezifische Quali t tsmodell entwickelt werden A 9 Theoretische Validierung 199 A 9 Theoretische Validierung Bevor die objektiven Metriken angewendet werden sollten sie theoretisch validiert sein Die Metriken zu Knappheit Strukturiertheit und Entkopplung in QOOD lassen sich als Komplexitatsmetriken auffassen weshalb sich das Axiomensystem von Wey uker 1988 f r Komplexit tsmetriken auf sie anwenden l sst Zus tzlich gibt es noch ein Axiomensystem vom Briand et al 1999 fiir Kopplungsmetriken die spezifisch f r die Metriken der Entkopplung betrachtet werden k nnen 12 5 1 Komplexit tsmetriken Weyuker 1988 hat eine Liste von neun Axiomen publiziert die f r Komplexit tsme triken die Programme auf syntaktischer Basis bewerten gelten sollten Sei m eine Komplexit tsmetrik und P Q R seien Programme Dann muss gelten Axiom W1 Es muss Programme geben die unterschiedliche Komplexit t besitzen Damit sollen Metriken ausgeschlossen werden die allen Programmen die gleiche Komplexit t zuweisen J P Q m P m Q Axiom W2 Die Anzahl der Programme welche die gleiche Komplexit t besitzen muss endlich sein Damit wird eine feinere Unterscheidung in Komplexitatsklassen gefordert als bei Axiom W1 Vc20 P m P cl ze Axiom W3 Es muss Programme geben welche die gleiche Komplexit t besitzen Damit soll als Gegenpol zu Axiom W2 eine zu feine Klassifikation z B eine
198. en zwischen Modellelementen wie z B Klassen und Interfaces werden ebenfalls als Klassen modelliert siehe Abbildung 5 2 Die Klassen Association Asso ziation Generalization Generalisierung Usage Benutzung und Abstraction Abs traktion sind Unterklassen der Klasse Relationship die wiederum eine Unterklasse von ModelElement ist Assoziationen werden mit Hilfe der zus tzlichen Klasse Associ ationEnd modelliert weil eine Assoziation mehr als zwei Modellelemente verbinden kann Die brigen Beziehungen verbinden genau zwei Modellelemente 5 2 Umfang 45 1 n argument ModelElement 1 n client ordered 1 n supplier name Name Relationship tclientDependency supplierDependency bid O n O n 2 t D d GeneralizableElement 1 Un eee ppencency isAbstract Boolean parent _ specialization I Ber Nee 1 1 Dn 0 1 Abstraction GE isNavigable Boolean e aggregation AggregationKind connection 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 Fiir die Verwendung in ODEM wird das UML Metamodell auf den tats chlichen Bedarf reduziert Zus tzlich werden n tzliche aus den Bestandtei len des UML Metamodells abgeleitete Modellelemente eingef hrt Diese dienen vor allem dazu als Abstraktionsschicht die Komplexi
199. endung des Template Method Musters Gamma et al 1995 wie sie Gruppe 4 vorgenommen hat Die Bewertung wird der Verbindung selbst zugeordnet Die abstrakte Klasse Connection besitzt eine Operation getDistance welche die Bewertung liefert Diese wird von den konkreten Unterklassen je nach Optimierungsziel implementiert vgl Abbildung 10 3 Die Operation processNode implementiert in Connection verwendet dann getDistance bei der Verbindungssuche Gruppe 12 hingegen benutzt Vererbung eher problematisch Von einer Klasse TwoDig itNumber die eine zweistellige Zahl repr sentiert werden zwei Unterklassen Hour und Minute abgeleitet ohne dabei Erweiterungen oder Redefinitionen vorzunehmen vgl Abbildung 10 4 linke Seite Das deutet darauf hin dass die Klassen abgesehen viel leicht von einem semantischen Unterschied durch den Namen berfl ssig sind Hour und Minute sind eigentlich Instanzen und keine Spezialisierungen von TwoDigitNum ber und sollten daher nicht als Klassen modelliert werden Der Fragebogen zur Struk turiertheit vgl Abschnitt B 2 enth lt eine entsprechende Frage die das Problem auf deckt 10 2 Anwendung des Qualitatsmodells 143 Connechion processNodef getdistancel inf MinLineChangeConnection getDistancef int Abbildung 10 3 Template Method Muster bei Gruppe 4 Fe gelStart Fiime Time Gel Time Time geffravelTimef Time gerStanstahlont Station gerBestStahon Salo
200. engestellt Bezeichner Bedeutung Das System enth lt alle Modellelemente A Menge aller Attribute in S C Menge aller Klassen in S Menge aller Interfaces in S M Menge aller Parameter in S O Menge aller Operationen in S P Menge aller Pakete in S einschlie lich S associates Relation fur Assoziationsbeziehungen zwischen Klassen Interfaces associates Erweiterte associates Relation umfasst auch geerbte Assoziationen contains Relation die aussagt dass ein Paket ein Modellelement enthalt contains Erweiterte contains Relation transitive H lle depends_on jAggregierte Relation f r Beziehungen zwischen Klassen Interfaces die eine Abhangigkeit verursachen depends_on Erweiterte depends_on Relation umfasst auch geerbte Abh ngigkeiten extends Relation f r das Erben von Eigenschaften extends Erweiterte extends Relation transitive H lle has Relation f r das Enthaltensein von Eigenschaften in Klassen Interfaces bzw Klassen Interfaces in Paketen has Erweiterte has Relation umfasst auch geerbte Eigenschaften realizes Relation f r die Realisierung eines Interfaces durch eine Klasse realizes Erweiterte realizes Relation umfasst auch geerbte Realisierungen uses Relation f r die Benutzung einer Klasse eines Interfaces uses Erweiterte uses Relation umfasst auch geerbte Benutzungen Tabelle 5 1 berblick ber die formalen Bezeichner in
201. ens und ihre Auswertung eingegangen wird Dann wird beschrieben wie die verschiedenen Komponenten kombiniert werden um eine Gesamtbewertung zu erhalten und welche Bewertungsschritte automatisiert werden k nnen Abschlie end wird diskutiert wie spezifische Modelle aus QOOD abgeleitet werden 9 1 Bewertungsverfahren Das Bewertungsverfahren beruht auf drei Komponenten objektiven Metriken sub jektiven Metriken und Frageb gen Diese bilden zusammen die Basis der Bewertung Durch Aggregation von Einzelbewertungen ber Kriterien und Faktoren erh lt man eine Gesamtbewertung Die Metriken und Frageb gen sind klassifiziert nach dem Kriterium zu dem sie geh ren Zus tzlich gibt es eine Unterklassifikation nach der Ebene oder Granularit t der Bewertung Im Metrikenrahmenwerk von Henderson Sellers et al 1993 werden die 118 9 Quantifizierung des Qualit tsmodells Ebenen Methode Dienst Klasse Subsystem und Gesamt System unterschieden Da hier kein Feinentwurf oder Code betrachtet wird werden nur die Ebenen Klasse Interface Paket anstelle von Subsystem und System verwendet 9 1 1 Objektive Metriken Zur Quantifizierung werden soweit wie m glich objektive automatisch bestimmbare Metriken eingesetzt um den Bewertungsprozess durch Werkzeugunterst tzung erleichtern zu k nnen Die Metriken messen Eigenschaften der Entwurfsartefakte hier also Eigenschaften des in UML Diagrammen beschriebenen UML Modells Die Metriken sin
202. enschaften einer Abstraktion umfasst so dass eine sinnvolle und effiziente Ver wendung der Komponente m glich ist In der Regel wird dabei eine minimale Schnittstelle angestrebt die dennoch sicherstellt dass die Klasse im System verwend bar ist Vollst ndigkeit completeness Eine Klasse ist vollst ndig wenn sie alle relevanten Eigenschaften einer Abstraktion umfasst Das bedeutet dass eine allgemeine Schnitt stelle erw nscht ist welche die Wiederverwendung der Klasse in anderen Systemen erlaubt Eine vollst ndige Schnittstelle ist angemessen aber nicht minimal Beim Klas senentwurf muss daher h ufig ein Kompromiss zwischen Angemessenheit und Voll st ndigkeit eingegangen werden zumal Booch davor warnt Vollst ndigkeit zu bertreiben Primitivit t primitiveness Eine Methode einer Klasse ist primitiv wenn sie nur mit direktem Zugriff auf die interne Repr sentation die Attribute effizient implemen tiert werden kann Die Schnittstelle einer Klasse sollte m glichst nur aus primitiven Methoden bestehen Eine Methode die sich ausschlie lich durch Aufruf primitiver Methoden realisieren l sst sollte nur dann in die Klassenschnittstelle aufgenommen werden wenn eine solche Implementierung nicht effizient genug ist Ansonsten sollte sie in eine Service Klasse ausgelagert werden Dies tr gt dazu bei die Klassenschnitt stelle schlank zu halten 7 4 2 Coad und Yourdon Coad und Yourdon 1991 Kap 8 geben einige Kriteri
203. enth lt die drei Faktoren Zuverl ssigkeit Komplexit t und Wieder verwendbarkeit Zu diesen Faktoren werden Kriterien angegeben f r die wiederum eine Reihe von Metriken angegeben wird Abbildung 7 8 zeigt den Aufbau des Modells Der Begriff Zuverl ssigkeit wird hier in einem v llig anderen Sinne verwen det Er bezeichnet die Korrektheit des Entwurfs in Bezug auf die Spezifikation F r die anderen beiden Faktoren wird keine Definition angegeben da wohl irgendeine bliche Definition angenommen wird brigens bedeutet eine h here Zuverl ssigkeit oder Wiederverwendbarkeit eine h here Qualit t w hrend eine h here Komplexit t eine niedrigere Qualit t bedeutet Eine solche Gegenl ufigkeit der Faktoren ist schon aus psychologischen Gr nden keine gute Idee Statt Komplexit t w re wohl Einfachheit die bessere Wahl gewesen Zuverl ssigkeit Komplexit t Wiederverwendbarkeit EN Klassen Klassen Klassenhierar Klassen Klassen gr e komplexit t chiestruktur kommunikation kapselung ALA LN WMC LCOM Abbildung 7 8 eer von Gillibrand und Liu Die Kriterien werden nicht n her erl utert daf r die Metriken ausf hrlich Die Bewertung eines Kriteriums ergibt sich aus den Werten seiner Metriken die gewichtet werden sollen Konkrete Gewichte geben die Autoren aber nicht an Eine Gewichtung soll ebenfalls erfolgen um aus den Werten der Kriterien Werte f r die Faktoren zu erhalten Explizite Zusammenh nge zwischen Faktoren
204. entierung 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 Attribu Person ten name birthday und Ope rationen setName getAge name String Attribute Parameter und birthday Date Ruckgabe haben einen Typ setName n String getAge int Ein Objekt namens HAL der Klasse Person mit der Werte HAL Person belegung der Attribute Der Objektstatus wird durch die name HAL 9000 Unterstreichung angezeigt birthday 12 1 1997 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 Eigen schaften Attribute und Methoden einer anderen Klasse erben d h als Kopie ber nehmen Es d rfen au erdem weitere Eigenschaften hinzugef gt werden Erweite rung 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
205. enwerte aus der Literatur verwendet wobei diese zum Teil etwas verringert wurden um durch Toleranzen eine differenziertere Bewertung zu errei chen F r die brigen Schwellenwerte wurden zun chst die Metriken f r alle Ent w rfe erhoben und dann auf der Basis der Ergebnisse geeignete Schwellenwerte und Toleranzen festgelegt Kriterium Ebene Metriken Knappheit Klasse lnterface NAC 4 2 NOC 20 10 Paket NCP 9 3 NIP 9 3 NPP 6 3 System NAS 100 50 NOS 150 60 NCS 20 10 NIS 20 10 NPS 10 5 Struktu Klasse Interface DITC 6 1 NEEC 1 0 riertheit paket DNHP 6 1 NPP 6 3 System DITS 4 2 DNHS 4 2 MNCS 6 3 MNPS 6 3 Entkopp IKlasse lnterface NEEC 6 1 NERC 6 2 NEAC 7 4 NEUC 7 4 ung Paket NECP 4 1 NACP 4 1 Tabelle 10 3 Verwendete objektive Metriken Gewichte Die Gewichte fiir die objektiven Metriken sind in Tabelle 10 4 dargestellt Als Default wurde 1 verwendet Haben die durch die Metrik gemessenen Entwurfseigenschaften einen gr eren Einfluss auf die Qualit t wurde ein h heres Gewicht gew hlt 140 10 Ein spezifisches Qualitatsmodell Kriterium Ebene Gewichte Knappheit Klasse Interface CCnac 1 CCnoc 2 Paket COM sh E E System CCyas 1 CCnos 2 CCncs 3 CCnis 3 CCyps 4 Struktu Klasse Interface STpitc 2 STneec 1 HERE Paket EE DEER System
206. er Za Flexibilitat bidirektionale Methoden Referenzen komplexitat Referenzen Wiederver wendbarkeit Einfachheit Klassenkom Methoden mit plexitat mehr als x LOC WMC 1 Klasse Methoden Verst ndlichkeit 1 Abstraktion Schnittstellen Abstrakte gr e Schnittstellen ana Abstraktion auf abstrakte Maximaler Klassen Zusammenhalt w LCOM Abbildung 7 9 Qualit tsmodell von Erni Anzahl Zu den Metriken werden Schwellenwerte angegeben die aus der Literatur oder aus Erfahrung stammen F r manche Metriken ist es allerdings sinnvoller eine erw nschte Richtung z B so gro wie m glich anzugeben als einen oberen oder unteren Schwellenwert Dann werden Schwellenwerte gew hlt die sich aus dem Mit tel und der Standardabweichung der Messwerte berechnen im Beispiel die Summe aus Mittel und Standardabweichung Mit Hilfe der Schwellenwerte k nnen die Messwerte in gut schlecht oder akzeptabel inakzeptabel unterteilt werden 7 4 Beispiele fur OOD Qualitatsmodelle 95 7 4 7 Bansiya und Davis Bansiya und Davis 2002 haben ein hierarchisches Qualit tsmodell f r den objekt orientierten Entwurf namens QMOOD Quality Model of Object Oriented Design entwickelt Das Modell besteht aus drei Ebenen Qualit tsattribute Entwurfseigen schaften und Metriken vgl Abbildung 7 10 Basis der Bewertung ist ein in C dokumentierter Entwurf in Form von Header Dateien Auf diesen Dateien werden mit Hilfe
207. er cksichtigt werden welche die Kosten stark beeinflussen 7 3 Entwurfsregeln Software design is hard and we need all the help we can get Bjarne Stroustrup Um die gew nschten Eigenschaften des Entwurfs in hohem Ma e zu erreichen wur den Unmengen von Ratschl gen publiziert Methoden Prinzipien Heuristiken Ent wurfsmuster und vieles andere mehr In diesem Abschnitt sollen die Prinzipien und Heuristiken genauer betrachtet werden da sie so etwas wie den Erfahrungsschatz des objektorientierten Entwurfs darstellen Daher k nnen aus ihnen Kriterien f r einen guten Entwurf gewonnen werden 7 3 1 Prinzipien Neither SA nor SD as currently practiced have proved to be very good routes to actually deriv ing a sound OO design but nearly all of the basic principles still apply problem partitioning component integrity cohesion independence coupling etc All science and engineering builds on what has gone before Constantine 1991 Balzert 1985a S 2 umrei t Prinzipien wie folgt Prinzipien sind Grunds tze die man seinem Handeln zugrundelegt Sie sind allgemeing ltig abstrakt allgemeinster Art Prinzipien bilden eine theoretische Grundlage Sie werden aus der Erfahrung und Erkenntnis hergeleitet und durch sie best tigt Das Sammeln von Prinzipien des Software Engineering begann schon fr h z B Ross et al 1975 Balzert 1985a 1985b Davis 1995 und Buschmann et al 1996 Kap 6 3 haben weitere Sammlun ge
208. er Unix testen z B im Pool Geben Sie immer mit Ihrem Quellcode auch eine compilierte ausf hrbare Version Ihres Programmes ab Diesem Programm muss eine Testdatei README beiliegen aus der hervorgeht wie das Programm gestartet werden kann Nicht ausf hrbare Programme gelten als nicht abgegeben F r die Programmierung in Java m ssen Sie sich an die Programmierrichtlinie von Sun halten Diese ist weit verbreitet und wurde auch schon f r die Scheinaufgabe zur Vorlesung Programmentwicklung gefordert Sie finden Sie im Web unter http java sun com docs codeconv index html Eine Kopie der Richtlinie ist auch im Semesterapparat zur Vorlesung Programmentwicklung einzusehen Beachten Sie diese Richtlinie schon beim Entwurf da sie zum Beispiel auch Aussagen ber die konforme Wahl von Bezeichnern macht F r die Spezifikation und den Entwurf m ssen Sie das CASE Werkzeug Innovator ver wenden Die Spezifikation wird mit diesem Werkzeug als Use Case Spezifikation erstellt f r den Entwurf sind UML Diagramme anzufertigen Vergessen Sie dabei nicht die Diagramme und die entsprechenden Elemente ausreichend zu beschriften und zu kommentieren F r Spezifikation wie f r den Entwurf sind weitere Dokumen tenteile notwendig die nur Texte enthalten in der Spezifikation zum Beispiel die nicht funktionalen Anforderungen Diese Texte k nnen ebenfalls mit Innovator im selben Dokument erstellt werden Dies ist aber nicht sehr komfortabel Sie d rfen die
209. er neuen Unterklasse die Funktion eines bisher korrekten Systems untergraben wenn auf einmal die Methoden der neuen Unterklasse aufgeru fen werden statt wie bisher die Methoden der Oberklasse 8 8 Pr fbarkeit Definition Ein Entwurf ist pr fbar wenn mit geringem Aufwand Pr fungen z B Inspektionen auf ihm durchgef hrt werden k nnen Diskussion Zum einen muss gepr ft werden k nnen ob der Entwurf eine L sung des Problems ist d h ob er korrekt ist Daf r ist Verfolgbarkeit wichtig Zum anderen sollte der Entwurf zur Pr fung so aufgeteilt werden k nnen dass der Einsatz mehrerer Gutach ter m glich ist Dies wird durch hohe Knappheit und Entkopplung erleichtert hohe Knappheit sorgt auch daf r dass weniger zu pr fen ist Dunsmore et al 2000 stellen allerdings fest dass eine sinnvolle Aufteilung zur Inspektion bei objektorientierten Systemen im Vergleich zu strukturierten Systemen grunds tzlich schwieriger ist da mehr Abh ngigkeiten der Komponenten untereinander vorhanden sind Pr fbarkeit Knappheit Entkopplung Verfolgbarkeit Abbildung 8 5 Kriterien des Faktors Pr fbarkeit 8 9 Weitere m gliche Faktoren Die bisher vorgestellten Faktoren decken bei weitem nicht alle m glichen ab Kandi daten f r weitere Faktoren sind Portabilit t Effizienz Performance Robustheit Interoperabilit t Sicherheit Verf gbarkeit Zuverl ssigkeit und Skalierbarkeit Will man auch die Benutzungsoberfl che aus Benutzersi
210. ereinigung falscher Entwurfsentscheidungen aufgewendet werden Bell et al 1987 Das liegt an der Fehlerfortpflanzung Wird ein Entwurfsfehler erst nach der Implementierung behoben ist das etwa zehnmal teurer als wenn der Fehler in der Entwurfsphase behoben worden w re Boehm 1983 Dunn 1984 Neuen Sch tzungen von Boehm und Basili 2001 zufolge kann der Faktor auch h her ausfal len zwischen 5 und 100 Deshalb lohnt es sich einen guten Entwurf zu erstellen Obwohl der Entwurfsauf wand dabei durch sorgf ltiges Arbeiten in der Regel zunimmt ist der Gesamtauf wand geringer da hohe Fehlerfolgekosten vermieden werden Um eine hohe Ent wurfsqualit t zu garantieren sollte der Entwurf bereits in der Entwurfsphase gepr ft werden Die tats chliche Entwurfsqualit t offenbart sich zwar erst in Implementie 2 1 Einf hrung rung und Wartung doch gibt es einige ntitzliche Indikatoren die Hinweise auf die tats chliche Entwurfsqualit t geben Die am h ufigsten verwendeten Indikatoren f r Entwurfsqualit t sind Entwurfsmetriken Rombach 1990 tritt sehr f r die Erhebung von Metriken in den fr hen Phasen der Software Entwicklung ein Er untermauert das durch die Feststellung einer hohen Korrelation zwischen Entwurfsmetriken z B zur Modularit t und der Wartbarkeit des Systems 1 2 Zielsetzung In dieser Arbeit wird ein Bewertungsverfahren f r objektorientierte Entw rfe entwi ckelt Dass die Messung der Entwurfsqualit t nic
211. erent dependencies of a class number of afferent dependencies of a package number of attributes in the system number of classes in a package number of classes in the system number of efferent association relationships of a class number of efferently coupled packages of a package number of efferent dependencies of a class number of efferent dependencies of a package number of extends relationships of a class number of efferent realization relationships of a class number of efferent uses relationships of a class number of interfaces in a package number of interfaces in the system number of operations of a class number of operations in the system number of packages in a package number of packages in the system ratio of traceable to total requirements subjective conciseness of a Class a Package a System subjective cohesion of a Class a Package a System subjective consistency of a Class a Package a System subjective decoupling of a Class a Package a System subjective documentation of a Class a Package a System subjective maintainability of a Class a Package a System subjective structuredness of a Class a Package a System subjective traceability of a Class a Package a System 189 AnhangA Metriken fur QOOD Dieser Anhang stellt die objektiven Metriken fiir QOOD Ubersicht siehe Tabelle 9 1 im Detail vor und begr ndet ihre Auswahl Die Metriken werden geordnet nach den Entwurfskriterien des Faktors Wartbarkeit siehe Abbildung 8
212. erience Within Motorola IEEE Transactions on Soft ware Engineering 18 11 1992 998 1010 Daskalantonakis 1994 Daskalantonakis M Achieving Higher SEI Levels IEEE Software 11 7 1994 17 24 Davis 1995 Davis A 201 Principles of Software Engineering McGraw Hill New York 1995 DeMarco 1982 DeMarco T Controlling Software Projects Management Measure ment and Estimation Prentice Hall Englewood Cliffs NJ 1982 DeMarco 1998 DeMarco T Der Termin Ein Roman tiber Projektmanagement Hanser M nchen 1998 DGQ 1995 Deutsche Gesellschaft f r Qualit t e V Begriffe zum Qualit tsmanage ment DGQ Schrift Nr 11 04 6 Auflage Frankfurt 1995 Dick Hunter 1994 Dick R Hunter R Subjective Software Evaluation In Ross M Brebbia C Staples G Stapleton J Hrsg Software Quality Management II Vol 2 Building Quality into Software Proceedings of the Second International Conference on Software Quality Management SQM 94 Computational Mechanics Publications Southampton 1994 321 334 Dijsktra 1968 Dijkstra E The Structure of the THE Multiprogramming System Communications of the ACM 11 5 1968 341 346 Dijkstra 1972 Dijkstra E The Humble Programmer Communications of the ACM 15 10 1972 859 866 DIN 55350 Teil 11 Deutsches Institut fiir Normung e V DIN 55350 11 1987 05 Qualit tsmanagement und Statistik Teil 11 Begriffe des Qualitatsmanagements 1987 D
213. ert Daher sind hier mehr nderungen n tig als bei den anderen Entw rfen bei denen lediglich der Suchalgorithmus leicht modifiziert werden muss Tabelle 10 7 zeigt den Wartungsaufwand f r diese nderung bei den drei Entw rfen Operationen Attribute Aufwand Gruppe 1 Gruppe 3 o 1 1 0 45 Gruppe 7 1 1 0 45 Tabelle 10 7 Wartungsaufwand f r nderung 1 nderung 2 Verbindungsanfrage mit gew nschter Umsteigehaltestelle Zus tzlich zu Start und Zielbahnhof soll es m glich sein bei der Verbindungsanfrage noch eine zus tzliche Umsteigehaltestelle anzugeben ber die alle gefundenen Ver bindungen gehen m ssen Von dieser nderung sind potentiell betroffen 10 2 Anwendung des Qualitatsmodells 147 e die Benutzungsoberfl che zur Verbindungsanfrage sowie e die Verbindungssuche und deren Aufrufparameter z B Suchdatensatz Klasse Hier schneiden alle Entw rfe etwa gleich gut ab Der Entwurf von Gruppe 3 besitzt eine Klasse zur Speicherung der Verbindungsanfrage die auch betroffen ist weshalb hier eine Klasse mehr ge ndert werden muss Die nderungen sind nicht schwer bis auf die nderung der einen Operation zur Ermittlung der Verbindungen Tabelle 10 8 zeigt den Wartungsaufwand f r diese nderung bei den drei Entw rfen Operationen Attribute Aufwand Gruppe 1 Gruppe 3 0 3 3 3 150 Gruppe 7 2 2 4 110 Tabelle 10 8 Wartungsaufwand fiir Ander
214. ertes Abgabedatum und die abzugebenden Dokumente eintragen Alle Meilensteindoku mente Abgaben werden durch Ihren Betreuer gepr ft und abgenommen Die Pr fung der Dokumente durch den Betreuer erfolgt allerdings nicht im Sinne einer Quali t tssicherung daf r sind Sie selbst verantwortlich und Sie sollten sie vor der Abgabe durchf hren Sie d rfen Ihr Projekt im brigen auch durch weitere Meilensteine untergliedern Planen Sie auch Aufwand f r die berarbeitung der Dokumente ein Erfahrungsgem werden nach der Durchsicht durch den Betreuer gr ere nderun gen notwendig Die Analyse wird in Form einer Kundenbefragung stattfinden Jeder Betreuer trifft sich mit seinen Gruppen zu einer gemeinsamen Sitzung Sie haben dann Zeit Ihre Fragen an den Kunden repr sentiert durch Ihren Betreuer zu stellen Sie sollten zu diesem Termin unbedingt vorbereitet erscheinen also vorbereitete Fragen haben Auf der Grundlage Ihrer Problemanalyse erstellen Sie dann einen Projektplan Dieser muss Ihrem Betreuer zur Genehmigung vorgelegt werden Nach jeder Uberarbeitung C 1 Aufgabenstellung 217 muss der Plan dem Betreuer zur Genehmigung vorgelegt werden Dieser Projektplan regelt die weiteren Termine Planen Sie auch Pufferzeiten ein und vergessen Sie die Zeiten nicht die Sie eventuell f r das Projekt nicht zur Verf gung stehen insbeson dere in der vorlesungsfreien Zeit z B durch Pr fungsvorbereitung Urlaub usw Es kommt darau
215. est benefits at lowest cost Software quality is desirable exactly to the degree it contributes to that goal Ludewig 1994 5 15 A good design is one that balances trade offs to minimize the total cost of the system over its entire lifetime Coad Yourdon 1991 S 128 Die kostenbezogene Qualit tssicht nimmt bei der Qualit tsbewertung die Kosten f r das Erreichen eines bestimmten Qualit tsniveaus z B in Bezug auf die herstellungs bezogene Sicht hinzu Wenn beispielsweise die Qualit t des Entwurfs mit einer m g lichst geringen Zahl von Fehlern gleichsetzt wird besitzt der Entwurf ohne Fehler die 82 7 Entwurfsqualitat h chste Qualit t Erfahrungsgem nehmen aber die Qualit tssicherungskosten exponentiell zu wenn eine sehr geringe Fehlerrate angestrebt wird Also ist die Quali t t mit den Kosten in Beziehung zu setzen vgl Abschnitt 6 3 3 Die Einbeziehung der Kosten in die Qualit tsbetrachtung kann so weit getrieben werden dass die Qua lit t mit den Kosten ber die gesamte Lebenszeit der Software gleichgesetzt wird Die Ermittlung der Gesamtkosten ist aber w hrend der Erstellung des Entwurfs nicht m glich weil die vom Entwurf bestimmten Kosten haupts chlich erst in sp teren Phasen anfallen Da die Kosten nicht direkt gemessen werden k nnen werden tradi tionell Kriterien gemessen von denen angenommen wird dass sie mit den Kosten korreliert sind also Indikatoren darstellen Daher st tzen sich alle brau
216. etriken bei der Bewertung aus gleichen k nnen Diese Kombination ist in dieser Form bei der Entwurfsbewertung bisher einzigartig Neu ist ebenfalls das Konzept der Verfeinerung von Metriken Eine m gliche Alternative zu den Frageb gen ist die Kombination von Metriken mit Szenarien wie sie Briand und W st 2001 in einer Fallstudie zur Bewertung der Wartbarkeit vorgenommen haben Das Ergebnis dieser Fallstudie deutet darauf hin dass sich die beiden Bewertungstechniken ebenfalls gut erg nzen In eine hnliche Richtung gehen die Erkenntnisse von Laitenberger et al 2000 die durch ein Experi ment festgestellt haben dass bei der Inspektion von UML Dokumenten ein Szenario basierter Pr fansatz einem Checklisten basierten berlegen ist was Effektivit t und Kosten angeht Abowd et al 1996 und Bosch 2000 raten bei der Bewertung von Software Architek turen von der Verwendung von Metriken eher ab und empfehlen stattdessen Szena rien Frageb gen Checklisten und Simulationen Das k nnte allerdings daran liegen dass Architekturbeschreibungen h ufig nicht formal genug sind oder dass Metriken 166 12 Zusammenfassung und Ausblick in der Praxis oft ohne vorhergehende Validierung eingesetzt werden und daher die Resultate unbefriedigend sind 12 4 Ausblick 12 4 1 Erweiterungen Als erster Schritt der Weiterentwicklung des Ansatzes sollten die brigen Faktoren von QOOD ebenfalls quantifiziert werden Da viele ihrer Kriterien auch
217. ewichtung festgelegt 162 12 Zusammenfassung und Ausblick 12 2 Bewertung des Ansatzes Die in Abschnitt 1 2 formulierten Anforderungen konnten mit dem Ansatz insgesamt erf llt werden Hier werden nun verschiedene Aspekte des Ansatzes betrachtet 12 2 1 ODEM ODEM eignet sich f r die formale Definition von Entwurfsmetriken wie sich in Fall studien vgl Abschnitt 5 5 2 und bei der Definition der Metriken f r QOOD vgl Anhang A gezeigt hat Die Abstraktionsschicht ber dem UML Metamodell erh ht dabei die Verst ndlichkeit der formalen Definitionen Allerdings deckt ODEM in sei ner jetzigen Form keine parametrisierten Elemente Templates ab Au erdem sind keine Informationen ber die Implementierung der Operationen die Methoden ver f gbar so dass gewisse Entwurfsmetriken aus der Literatur mit ODEM nicht formali siert werden k nnen 12 2 2 QOOD In einer Fallstudie vgl Kapitel 10 wurde gezeigt wie einfach die Ableitung eines spezifischen Modells von QOOD ist Die Durchf hrung der Bewertung ist ebenfalls einfach insbesondere wenn entsprechende Werkzeugunterst tzung verf gbar ist Die Dauer der Bewertung ist dabei vor allem von der Gr e des Entwurfs und der Quali t t der Dokumentation abh ngig z B erleichtert das Vorhandensein einer brauchba ren Entwurfs bersicht den Einstieg Die Resultate der Bewertung haben sich beim Vergleich von Entwurfsalternativen als zuverl ssige Indikatoren f r den relativen W
218. exit t nicht dasselbe da bei der psychologischen Komplexit t der Leser eine wesentliche Rolle spielt d h sie ist individuell verschieden Die strukturelle Komplexit t ist aller dings ein guter Indikator f r die psychologische Komplexit t 8 3 Wartbarkeit 109 Diskussion F r den Menschen scheinen hierarchische Strukturen besonders verst ndlich zu sein Simon 1962 Hierarchische Strukturen erlauben den Umgang mit einer gro en Anzahl von Teilen weil zu einem Zeitpunkt immer nur ein Ausschnitt betrachtet wer den muss Durch die Hierarchie besteht die M glichkeit zur Abstraktion z B die Bil dung von Schichten da Verfeinerungen bei Bedarf ausgeblendet werden k nnen Parnas 1974 stellt fest dass man bei dem Begriff hierarchisch aufpassen muss da es verschiedene Hierarchien gibt In der Objektorientierung gibt es z B bei den Paketen eine hierarchische Struktur durch Schachtelung bei den Klassen durch Vererbung Hierarchien sind zyklenfrei daher ist die Vermeidung von Zyklen ein wichtiges Ziel Weitere Kriterien f r die Strukturiertheit einer Hierarchie sind ihre Tiefe und der Ver zweigungsgrad innerhalb der Hierarchie 8 3 3 Entkopplung the best programs are designed in terms of loosely coupled functions that each does a sim ple task Kernighan Plauger 1974 If one intends to build quality models of OO design coupling will very likely be an important structural dimension to consider Briand et al 19
219. f r die Produkte relevant sind nicht enth lt Also muss f r ein brauchbares allgemei nes Modell ein Kompromiss zwischen den beiden Extremen gesucht werden Der Vorteil eines spezifischen Modells liegt darin dass es an das Produkt angepasst ist also alle relevanten Aspekte abdeckt und keine irrelevanten Aspekte enth lt Allerdings ist zun chst einmal f r jedes Produkt ein solches Modell zu erstellen Daher sollte es zumindest eine Art Schablone geben aus der sich ein produktspezifi sches Modell ableiten l sst oder ein Vorgehensmodell mit dem mit m glichst gerin gem Aufwand ein spezifisches Modell erzeugt werden kann Am sinnvollsten ist die Kombination der beiden Ans tze Ein Vorgabemodell das ein allgemeines Modell ist wird durch Adaptionsschritte nach einem definierten Vorge 4 Beim Vergleich der Gesamtkosten von Entwurfsalternativen sollte eine unterschiedliche Nutzungs dauer ber cksichtigt werden Das kann geschehen indem die Kosten f r ein Nachfolgesystem in die Kostenbetrachtung mit einbezogen werden oder indem die Kosten auf die Nutzungsdauer umgelegt werden 7 3 Entwurfsregeln 83 Produkt 3 Produkt 1 Produkt 2 Abbildung 7 7 G ltigkeitsbereiche f r allgemeine Modelle hen an das konkrete Produkt angepasst und so in ein spezifisches Modell berf hrt Die produktbezogene Sicht kann dabei um eine kostenbezogene erweitert werden indem diejenigen Aspekte besonders b
220. f an dass Sie einen Plan erstellen dem Sie auch tats chlich folgen k nnen Sie brauchen keinen Scheinplan aufzustellen der uns dauernde Aktivit t vorgaukelt Wichtig ist dass Sie zu den Meilensteinterminen die geforderten Doku mente in guter Qualit t abgeben Dazu ben tigen Sie sicher die anvisierte Stunden zahl s u Sie m ssen diese Stunden aber so einplanen dass Sie diese auch zu gege bener Zeit leisten k nnen Bedenken Sie das bei der Aufstellung des Projektplans Ob Sie noch im Plan sind k nnen Sie dann jederzeit leicht durch einen Vergleich mit den Stundenzetteln und den erbrachten Ergebnissen feststellen F hren Sie daher den Stundenzettel gewissenhaft und verschieben Sie das Aufschreiben der Arbeitszeiten nicht ans Projektende C 1 3 Projektrahmen Sie und Ihre beiden Mitstreiter stellen ein Entwicklungsteam dar Sie bekommen von einem kleinen Verkehrsbetrieb einen Software Entwicklungsauftrag f r ein kleines ma geschneidertes Auskunftssystem Damit m chte Ihr Auftraggeber seinen Fahr g sten eine attraktive M glichkeit zur Fahrtenplanung bieten Normalerweise berechnen Sie einen Stundensatz von 200 DM pro Entwicklerarbeits stunde der Kunde m chte aber ein Festpreisprojekt und ist bereit daf r 96 000 DM zu bezahlen Das haben Sie dem Verkehrsbetrieb auch zugesagt Nat rlich ist Ihr Chef sehr daran interessiert dass Sie diesen Kosten und in diesem Falle auch Zeitrahmen genau einhalten da Ihre Firma so
221. f the First International Sym posium on the Construction of Software Engineering Tools CoSET 99 Los Angeles May 1999 Roche Jackson 1994 Roche J Jackson M Software Measurement Methods Recipes for Success Information and Software Technology 36 3 1994 173 189 Rombach 1990 Rombach H Design Measurement Some Lessons Learned IEEE Software 7 2 1990 17 25 Rombach 1993 Rombach H Software Qualit t und Qualit tssicherung Informa tik Spektrum 16 5 1993 267 272 Ross et al 1975 Ross D Goodenough J Irvine C Software Engineering Process Principles and Goals IEEE Computer 14 5 1975 17 27 Royce 1970 Royce W Managing the Development of Large Software Systems Con cepts and Techniques Proceedings of the IEEE WESCON Los Angeles 1970 1 9 Royce 2000 Royce W Software Management Renaissance IEEE Software 17 4 2000 116 121 Rumbaugh et al 1993 Rumbaugh J Blaha M Premerlani W Eddy F Lorensen W Objektorientiertes Modellieren und Entwerfen Hanser M nchen 1993 Rumbaugh et al 1998 Rumbaugh J Jacobson I Booch G The Unified Modeling Language Reference Manual Addison Wesley Reading MA 1998 Schmider 2002 Schmider C Konzeption und Realisierung eines Metriken werkzeugs fiir die Unified Modeling Language Diplomarbeit Nr 1952 Institut fiir Informatik Universitat Stuttgart 2002 Shaw Garlan 1996 Shaw M Garlan D Software Archit
222. fern aber nur ein syntak tisches Bild Der wichtigere semantische Aspekt kann nicht erfasst werden Au er dem h ngen die zu pr fenden Kriterien von den konkreten Richtlinien ab Will man sie erfassen ist das spezifische Modell um weitere objektive Metriken und Fragen zu den Frageb gen zu erweitern 198 A Metriken fur QOOD A 6 Dokumentierung Auch f r die Dokumentierung ist eine subjektive Bewertung n tig Zwar kann bei entsprechenden Dokumentierungskonventionen automatisch gepr ft werden ob Kommentare im geforderten Umfang vorhanden sind doch ist es sehr schwer auto matisch zu pr fen ob die Kommentare sinnvoll und hilfreich sind A 7 Verfolgbarkeit Die Verfolgbarkeit l sst sich nicht direkt aus dem UML Modell ermitteln da es f r die Verkn pfung von UML Artefakten mit den Anforderungen kein standardisiertes Ver fahren gibt F r Klassen und Pakete kann man nur beurteilen wie gut dokumentiert ist auf wel che Anforderungen ihr Vorhandensein zur ckzuf hren ist Eine sinnvolle objektive Metrik daf r l sst sich leider nicht angeben Auf der Systemebene kann man eine objektive Metrik angeben die sich allerdings nicht auf der Basis von ODEM ermitteln l sst Die Metrik RITR ratio of traceable to total requirements ist das Verh ltnis der Anzahl der im Entwurf verfolgbaren Anforderungen zur Gesamtzahl der Anforde rungen Je gr er der Wert desto besser Neben der reinen Anzahl verfolgbarer Anforderungen k nn
223. ffs NJ 1991 Cockburn 1998 Cockburn A Object Oriented Analysis and Design Part 2 C C Users Journal 16 6 1998 Constantine 1965 Constantine L Towards a Theory of Program Design Data Pro cessing Magazine 7 12 1965 18 21 Constantine 1991 Constantine L Larry Constantine on Structured Methods and Object Orientation UNIX Review 9 2 1991 409 Conway 1968 Conway M How Do Committees Invent Datamation 14 4 1968 28 31 Coplien 1999 Coplien J Reevaluating the Architectural Metaphor Toward Piece meal Growth IEEE Software 16 5 1999 40 44 Coplien Schmidt 1995 Coplien J Schmidt D Hrsg Pattern Languages of Pro gram Design Addison Wesley Reading MA 1995 174 Literatur Corbi 1989 Corbi T Program Understanding Challenge for the 1990s IBM Systems Journal 28 2 1989 294 306 Crosby 1979 Crosby P Quality Is Free The Art of Making Quality Certain McGraw Hill New York 1979 Curtis et al 1988 Curtis B Krasner H Iscoe N A Field Study of the Software Design Process for Large Systems Communications of the ACM 31 11 1988 1268 1287 Daly et al 1996 Daly J Brooks A Miller J Roper M Wood M Evaluating Inheritance Depth on the Maintainability of Object Oriented Software Empirical Soft ware Engineering 1 2 1996 109 132 Daskalantonakis 1992 Daskalantonakis M A Practical View of Software Measure ment and Implementation Exp
224. forderungen zu akzeptablen Kosten bietet Broh 1974 Die inh rente Qualit t wird so mit den Kosten f r Anschaf fung und Betrieb in Beziehung gesetzt Entscheidend f r Qualit t ist somit das Preis Leistungsverh ltnis Unter Umst nden kann auch die Zeit zu der ein Produkt zur Verf gung steht Einfluss auf dessen Qualit t haben Time to Market Je fr her das Produkt beim Kunden einsetzbar ist desto h her wird die von ihm wahrgenom mene Qualit t des Produkts falls die Bereitstellungszeit f r ihn eine Rolle spielt Konsequenzen Die Existenz der f nf unterschiedlichen Sichten f hrt h ufig zu Verwirrungen wenn ber Qualit t gesprochen wird Beispielsweise kommt es regelm ig zu Missver st ndnissen wenn die Marketing Abteilung die eher der benutzerbezogenen Sicht zuneigt sich mit der Produktionsabteilung die eher die herstellungsbezogene Sicht einnimmt ber die gew nschte Qualit t eines Produkts einigen soll Trotzdem ist es wichtig verschiedene Sichten bei der Entwicklung und Herstellung eines Produkts einzubeziehen Am Anfang des Entstehungsprozesses eines neuen Produkts steht eine Marktanalyse liefert benutzerbezogene Qualit ten Daraus werden die Eigen schaften des Produkts abgeleitet produktbezogene Qualit t Schlie lich muss das 62 6 Softwarequalitat Produkt nach den Anforderungen hergestellt werden herstellungsbezogenen Quali t t Der Kunde schlie lich wird bei der Entscheidung f r ein Produk
225. fragung in der Analyse und Abschnitt C 3 das Begriffslexikon C 1 Aufgabenstellung C 1 1 Organisation In diesem Praktikum m ssen Sie gruppenweise ein kleines Software Projekt durch f hren und damit Ihr Wissen aus der Vorlesung Einf hrung in die Softwaretechnik I umsetzen Sie planen das Projekt selbst und besprechen die Ergebnisse jeweils mit Ihrem Betreuer Dieser ist auch gleichzeitig der Kunde also der Abnehmer f r Ihre Ergebnisse Die Kenntnisse aus den Vorlesungen Einf hrung in die Softwaretechnik I inklusive bungen Einf hrung in die Informatik I amp II sowie Programmentwicklung werden vor ausgesetzt Sie bilden eine wichtige Grundlage f r Ihre Arbeit Alle Gruppen sind jeweils einem Betreuer zugeordnet Diesen Betreuer k nnen Sie nach Terminabsprache aufsuchen und ihn bei allen auftretenden Problemen zu Rate zie hen Zu den von Ihnen geplanten Meilensteinterminen m ssen Sie Ihren Betreuer auf suchen die entsprechenden Unterlagen abgeben und mit ihm durchsprechen In einem ersten Schritt m ssen Sie Ihr Projekt selbst planen Weiter unten sind aller dings einige Rahmenbedingungen f r diese Planung von unserer Seite angegeben Diese m ssen Sie unbedingt beachten Der Plan wird dann von Ihrem Betreuer geneh migt Sie sind dann an Ihren Plan gebunden d h die darin genannten Termine sind 216 C Dokumente zum Softwarepraktikum unbedingt einzuhalten Sollten Sie feststellen dass Sie Ihren Plan ndern m ssen s
226. fseigenschaften aus dem reduzierten Modell Qualit tsattributen zu und gibt objektive und subjektive Metriken zur Messung der Eigenschaften an Die objektiven Metriken werden auf der Basis von ODEM formal definiert Als Hilfsmittel f r die Erhebung der subjektiven Metriken werden Frageb gen eingesetzt Durch Ein satz von QOOD kann aus dem reduzierten Modell ein allgemeines Qualit tsprofil berechnet werden Von QOOD wird anhand der gew hlten Qualit tssicht ein spezifisches Modell abge leitet hier als MyQOOD bezeichnet Dazu werden aus den vorhandenen Qualit ts attributen und Metriken von QOOD die relevanten ausgew hlt und gewichtet Das spezifische Modell erlaubt die Berechnung eines spezifischen Qualit tsprofils aus dem allgemeinen Qualit tsprofil Die Qualit tsattribute in QOOD sind hierarchisch geordnet so dass man durch Aggregation der Messwerte untergeordneter Attribute Messwerte f r bergeordnete Attribute erh lt Die Aggregation wird dabei von der Gewichtung im spezifischen Qualit tsmodell bestimmt Durch schrittweise Aggrega tion kann man so eine einzige Qualit tskennzahl f r den Entwurf bestimmen Ein spezifisches Qualit tsmodell k nnte aber auch mehrere Kennzahlen liefern Die Trennung zwischen einem allgemeinen und einem spezifischen Qualit tsmodell erlaubt die Ber cksichtigung individueller Sichten auf Entwurfsqualit t gem Anforderung 4 aus Abschnitt 1 2 Da es sehr viele unterschiedliche Sichten gibt ist ei
227. gen 8 1 1 Ideales Modell QOOD hat nicht den Anspruch die endg ltige Antwort auf die Frage nach Entwurfs qualit t zu geben Diese Antwort wird es niemals geben ebenso wenig wie die end g ltige Antwort auf die Frage nach Sch nheit Trotzdem kann man die Eigenschaften eines idealen allgemeinen Qualit tsmodells angeben e eindeutig und widerspruchsfrei e deckt alle Sichten z B der verschiedenen Interessengruppen ab e vollst ndig in Hinsicht auf die Aspekte der einzelnen Sichten vollst ndig quantifiziert d h alle Aspekte sind messbar unterst tzt Bewertungsverfahren welche die Kriterien des ISO IEC Guide 25 vgl Abschnitt 7 6 1 erf llen und 102 8 Das allgemeine Qualit tsmodell e anpassbar d h es k nnen Aspekte ausgeblendet oder Bewertungsschwerpunkte gebildet werden Man kann sich leicht vorstellen dass ein Modell mit diesen Eigenschaften sehr gro ist und die Verflechtungen innerhalb des Modells sehr kompliziert sind Also ist die Erstellung eines solches Modells sehr aufwendig Selbst wenn es verf gbar w re w re der Umgang damit nicht einfach weil es vermutlich eine nicht mehr handhab bare Komplexit t hat 8 1 2 Pragmatischer Ansatz Aus diesem Grund ist der hier verfolgte Ansatz ein pragmatischer Ziel ist nicht das ideale Modell sondern ein Qualit tsmodell mit dessen Hilfe der Stand der Praxis der Entwurfsbewertung verbessert werden kann Card und Glass 1990 S 20 empfehlen f r di
228. 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 Eigen schaften werden in der Darstellung der Unterklasse nicht wiederholt Die Klasse OO_Designer Person OO_Designer erbt von Person und f gt dabei experience int gt name String neue Eigenschaften likesUML boolean birthday Date Die getExperience int setName n String getAge int Abbildung 3 2 UML Darstellung der Vererbung Vererbung ist ein m chtiges Konzept durch sie kann viel redundante Implementie rung eingespart werden Durch Erben kann aber die Kapselung durchbrochen wer den weil eine Unterklasse Zugriff auf die Implementierung der Oberklasse erh lt Snyder 1986 Au erdem ist die Unterklasse durch das Erben stark an ihre Ober klasse gekoppelt Jede nderung der Oberklasse betrifft auch die Unterklasse 18 3 Objektorientierung Zus tzlich wirkt sich Vererbung tendenziell negativ auf Verst ndlichkeit Wartbarkeit und Pr fbarkeit aus Wilde Huitt 1992 Lejter et al 1992 Wilde et al 1993 Harrison et al 2000b
229. gkeiten betrachtet werden Eine m gliche Verfeinerung betrachtet nur die direkten Abh ngig keiten hier gezeigt am Beispiel von NEDP NEDP number of local efferent dependencies of a package NEDP p Ze Pie 4epends_on p q weight Ist man nur an der Anzahl der Pakete interessiert an die ein Paket gekoppelt ist so kann man alternativ zu NEDP und NADP auch die folgenden Metriken verwenden NECP number of efferently coupled packages of a package NECP p qe P p depends_on p q NACP number of afferently coupled packages of a package NACP p qe P p depends_on q p Auch f r diese Metriken l sst sich die oben gezeigte Verfeinerung mit der Beschr n kung auf direkte Abh ngigkeiten anwenden System Auf Systemebene lassen sich keine Metriken angeben die eine wirklich neue Sicht zur Kopplung erm glichen Denkbar sind zwar Durchschnitte o A der Kopplungsmetri ken auf Klassen und Paketebene doch kann diese Form der Aggregation genauso gut auf der Ebene der subjektiven Metriken vorgenommen werden vgl Abschnitt 9 3 4 Daher wird darauf verzichtet objektive Metriken anzugeben A 4 Zusammenhalt Zusammenhalt ist in hohem Ma e eine semantische Eigenschaft die sich schlecht automatisch d h auf syntaktischer Ebene erfassen l sst Klasse Interface In der Literatur vorgeschlagene Zusammenhaltsmetriken f r Klassen ben tigen detaillierte Entwurfsinformation vgl z B Bieman Kang 1995 1998
230. gnitiven Schwierigkeit ausw hlt Die Schwierigkeit h ngt vom Hintergrundwis sen des Entwerfers der verf gbaren Information und der Komplexit t der Aufgabe ab 28 4 Objektorientierter Entwurf auch die Ideen der Abstraktion der Hierarchie und der Schichten z B Constantine 1965 Dijkstra 1968 Modulorientierter Objektbasierter Entwurf Das System wird in Module aufteilt Unter einem Modul verstand man urspriinglich beim strukturierten Entwurf eine Prozedur Beim modulorientierten Entwurf fasst man beeinflusst durch das Geheimnisprinzip und die Theorie der abstrakten Daten typen Prozeduren und Datenstrukturen zu gr eren Einheiten Modulen zusam men Module die Datenstrukturen mit den notwendigen Funktionen auf diesen Datenstrukturen zusammenfassen und kapseln werden auch als Objekte bezeichnet man spricht dann von objektbasiertem Entwurf z B Booch 1987 Objektorientierter Entwurf Der objektorientierte Entwurf nimmt zum objektbasierten Entwurf noch das Konzept von Vererbung und den damit zusammenh ngenden Polymorphismus hinzu Damit kann der objektorientierte Entwurf als eine Weiterentwicklung der bisher verfolgten Entwurfsstrategien angesehen werden Allerdings scheint dennoch ein Umdenken beim Entwerfen erforderlich zu sein weshalb auch h ufig von einem Paradigmen wechsel die Rede ist 4 2 2 Aktivit ten As systems become more complex the design problem goes beyond the algorithms and data structures of t
231. halten Bedienbarkeit Der Benutzer soll rasch verstehen k nnen wie er mit der Software umgehen muss Wartbarkeit Beachten Sie die folgenden m glichen Erweiterungen e bei der Verbindungssuche nicht nur die beste sondern auch weitere m gliche Ver bindungen ausgeben e Verbindungsanfrage um gew nschte Umsteigehaltestellen erweitern e Unterscheidung von Wochentagen und Wochenende im Fahrplan e im Administratormodus k nnen auch die Fahrzeiten zwischen den Haltestellen ge ndert werden e im Administratormodus k nnen auch neue Haltestellen aufgenommen werden Alle weiteren Qualit ten spielen keine entscheidende Rolle sie sind daher nicht wei ter zu beachten C 3 Begriffslexikon Abfahrtszeit Zeitpunkt zu dem der Zug einer Linie eine Haltestelle verl sst Admin Modus Zustand des Fahrplaninformationssystems In diesem Zustand kann ein Servicetechniker die Fahrplandaten des Systems ndern Ankunftszeit Zeitpunkt zu dem der Zug einer Linie eine Haltestelle erreicht Au er an Endhaltestellen verl sst der Zug eine Haltestelle zum selben Zeitpunkt d h Ankunftszeit und Abfahrtszeit sind identisch Auftraggeber Der Auftraggeber ist eine Firma die bei den Software Entwicklern das Fahrplaninformationssystem in Auftrag gibt und die Software abnimmt und bezahlt Der Auftraggeber ist in diesem Projekt der Verkehrsbetrieb VVS Benutzer Ein Benutzer ist eine Person die das Fahrplaninformationssystem benutzt Es kann sich d
232. he computation designing and specifying the overall system structure emerges as a new kind of problem Jacobson et al 1998 S 62 Wie bereits in Abbildung 4 1 gezeigt k nnen in der Entwurfsphase zwei verschiedene Aktivit ten unterschieden werden Architekturentwurf und Komponentenentwurf Architekturentwurf Der Architekturentwurf entwickelt die grobe Struktur der L sung die Architektur zum Begriff Architektur siehe Abschnitt 4 3 1 Die wesentlichen Komponenten sind dabei in der Regel der funktionale Kern die Benutzungsoberfl che und die Datenhal tung Au erdem wird die Verteilung der Komponenten auf Rechnerknoten festgelegt Das Vorgehen beim Architekturentwurf ist wie folgt Das System wird zun chst hier archisch in Subsysteme zerlegt die verschiedene Aufgaben innerhalb des Systems wahrnehmen Diese Subsysteme werden verfeinert bis man zu den Atomen des Architekturentwurfs den Komponenten gelangt Die Beziehungen zwischen den Komponenten die Konnektoren werden identifiziert Dokumentiert werden schlie lich die Subsysteme die Komponenten die Konnektoren und ihre Interaktion zur Laufzeit Komponentenentwurf Der Komponentenentwurf legt zun chst die Schnittstellen der Komponenten nach au en fest Au erdem werden wichtige Details f r die Implementierung bestimmt vor allem die zu verwendenden Algorithmen und Datenstrukturen Feinentwurf 4 2 Klassifikationen des Entwurfs 29 In der Praxis entstehen Architek
233. he konstruktive analytische MaRnahmen Ma nahmen Ma nahmen Verantwortung Modularisierung Reviews Fr Richtlinien r Datenkapselung Tests Audits Hochsprachen Metriken Kontrolle organisieren Fehler vermeiden Fehler entdecken Abbildung 6 6 Qualit tssicherungsma nahmen Die organisatorischen Ma nahmen bilden dabei die Grundlage auf der die anderen Ma nahmen aufbauen Es wird ein Qualit tssicherungsprozess etabliert der festlegt welche konstruktiven und analytischen Ma nahmen wann von wem durchzuf hren sind und welche Richtlinien gelten Der Prozess selbst wird durch Audits gepr ft Konstruktive Ma nahmen sollen daf r sorgen dass das Produkt von Anfang an eine hohe Qualit t hat Qualit t also quasi mit eingebaut wird Dazu werden bestimmte Techniken und Werkzeuge verwendet die in der Regel zu hoher Qualit t f hren z B Datenkapselung Hochsprachen Die analytischen Ma nahmen dienen zur Aufdeckung von Qualit tsm ngeln die sich trotz der organisatorischen und konstruktiven Ma nahmen im Produkt befinden Sie greifen im Gegensatz zu den anderen Ma nahmen erst wenn das Problem schon besteht Zu den analytischen Ma nahmen geh ren z B Reviews Tests und die Erhe bung von Metriken 6 3 2 Reviews Clearly inspections are an important way to find errors Not only are they more effective than testing for finding many types of problems but they also find them earlier in the program when the
234. hi tecture Addison Wesley Reading MA 2000 Hopkins 1994 Hopkins T Complexity Metrics for Quality Assessment of Object Oriented Designs In Ross M Brebbia C Staples G Stapleton J Hrsg Software Quality Management II Vol 2 Building Quality into Software Proceedings of the Sec ond International Conference on Software Quality Management SQM 94 Computa tional Mechanics Publications Southampton 1994 467 481 Humphrey 1988 Humphrey W Characterizing the Software Process A Maturity Framework IEEE Software 5 3 1988 73 79 Humphrey 1990 Humphrey W Managing the Software Process Addison Wesley Reading MA 1990 Hunt Thomas 1999 Hunt A Thomas D The Pragmatic Programmer From Jour neyman to Master Addison Wesley Reading MA 1999 Huston 2001 Huston B The Effects of Design Pattern Application on Metric Scores Journal of Systems and Software 58 3 2001 261 269 IEEE Std 610 12 1990 IEEE IEEE Standard Glossary of Software Engineering Termi nology IEEE Std 610 12 1990 IEEE Std 1028 1997 IEEE IEEE Standard for Software Reviews IEEE Std 1028 1997 178 Literatur IEEE Std 1044 1993 IEEE IEEE Standard for Classification of Software Anomalies IEEE Std 1044 1993 IEEE Std 1061 1992 IEEE IEEE Standard for a Software Quality Metrics Methodol ogy IEEE Std 1061 1992 IEEE Std 1471 2000 IEEE IEEE Recommended Practice for Architectural Description of Softwar
235. hl der Objekte mit denen ein Objekt interagiert Law of Demeter Lieber herr et al 1988 1989 In den Methoden einer Klasse d rfen nur Methoden der Klasse selbst der Argumentobjekte oder der Attributwerte der Klasse auf rufen werden Dahinter steht die berlegung dass sich die meisten Abh ngigkeiten zwischen Klassen durch Methodenaufrufe manifes tieren eine Beschr nkung also zu weniger Abh ngigkeiten f hrt Tabelle 7 3 Taktische Prinzipien Abschnitt 2 von 2 Leider gibt es f r die meisten dieser Prinzipien wenig empirische Untersuchungen ber ihre Wirksamkeit und ihre Relevanz Sie stellen eher eine Art Tradition im Soft ware Engineering dar die durch berwiegend positive Erfahrungen aufrechterhalten wird Obwohl der empirische Nachweis der Brauchbarkeit fehlt werden in vielen wissenschaftlichen Arbeiten diese Prinzipien herangezogen um aus ihnen Entwurfs ziele zu extrahieren Aus diesen werden dann Qualit tsattribute abgeleitet die zur Entwurfsbewertung verwendet werden 7 3 Entwurfsregeln 87 7 3 2 Heuristiken Useful suggestions about quality when they are brought to our attention usually strike us at once as familiar and revelatory We see them as sensible reflecting what we have felt but per haps not expressed Dromey 1996 S 43 Eine Heuristik ist eine Daumenregel die meistens funktioniert aber nicht immer opti male Ergebnisse liefert Daher ist eine Heuristik im Gegensatz zum Prinzip nich
236. ht Verteilung Die f nfte Sicht wird durch Szenarios gebildet mit deren Hilfe das Zusammenspiel der anderen vier Sichten berpr ft werden kann Alle Sichten lassen sich mit UML modellieren Werden in der Entwicklung Muster verwendet sollte das dokumentiert werden Die Dokumentation enth lt einen berblick welche Muster ausgepr gt wurden und wel che Klassen welche Rollen in den Musterauspr gungen einnehmen Auf diese Weise kann sich jemand der mit den Mustern vertraut ist schneller mit den grundlegenden Ideen und Strukturen des Entwurfs vertraut machen Ein gutes Beispiel f r eine Ent wurfsdokumentation durch Muster ist die des Test Rahmenwerks JUnit Beck Gamma 1998 Quibeldey Circel 1999 f hrt den Gedanken der Dokumentation mit Mustern weiter zum Literate Designing das die Architektur unter Verwendung von Mustern in Hypertext Form dokumentiert 4 5 Probleme des Entwurfs The best way to learn to live with our limitations is to know them Dijkstra 1972 Einen guten Entwurf zu schaffen ist schwierig da der Entwerfer dabei mit vielen Pro blemen konfrontiert wird Dazu geh ren e unvollst ndige und instabile Anforderungen e konomische Zw nge e Probleme bei der Beherrschung der Technologie und schlie lich e die fundamentale Komplexit t des Entwurfs Diese Probleme werden im Folgenden vertieft dargestellt 4 5 1 Unvollst ndige und instabile Anforderungen Even if we could master all of the detail needed
237. ht einfach ist beschreibt William Agresti eindr cklich in seinem Vorwort zu dem Buch von Card und Glass 1990 zu diesem Thema Measurement of physical reality we learned involved three elements an object an observable characteristic and an apparatus for performing the measurement The measurement examples giving instances of object observable apparatus table length yardstick were clear enough Well it s a long way from table length yardstick to software design quality design quality analyzer In each of the three elements of measurement we have major problems Our object software is invisible and intangible Our observable design quality raises the issue What is quality What is the relative importance of simplicity maintainability effi ciency and other characteristics that contribute to design quality Our apparatus is often a tool that processes the source code for what it reveals of design because earlier design descrip tions are seldom complete or formally represented Die wichtigsten Fragen die ein Bewertungsverfahren fiir den Entwurf zu beantwor ten hat sind also 1 Messgegenstand Was ist Entwurf Welche Entwurfsbestandteile sind relevant 2 Messziel Was ist Entwurfsqualitat 3 Messverfahren Wie wird die Entwurfsqualitat gemessen Messgegenstand Diese Arbeit konzentriert sich auf den Bereich des objektorientier ten Entwurfs da sich dieser in den letzten zehn Jahren
238. ht f r alle Kriterien und Ebenen objektive Metriken angegeben werden k nnen sondern sich die Metriken vor allem auf die Kriterien Knappheit Strukturiertheit und Entkopplung beschr nken Das liegt daran dass diese Kriterien sich gut an syntaktischen Aspekten der Entwurfsbeschreibung festmachen lassen Bei den anderen Kriterien berwiegen die semantischen Aspekte die sich schlecht durch objektive Metriken erfassen lassen 9 2 3 Beispiel Als Beispiel werden hier die wichtigsten objektiven Metriken f r das Kriterium Knappheit und ihre formale Definition gezeigt Eine ausf hrlichere Darstellung findet sich in Abschnitt A 1 Da Knappheit unter anderem eine geringe Gr e bedeutet wer den vor allem die Bestandteile der Entwurfselemente gez hlt Diese Z hlmetriken sind negativ mit der Knappheit korreliert Klasse Interface Bei Klassen und Interfaces werden geerbte Bestandteile mitgez hlt da geerbte Eigen schaften in der Klasse vorhanden sind und damit ihre Gr e mitbestimmen siehe dazu auch Abschnitt A 1 NAC number of attributes of a class NAC c ae A has c a NOC number of operations of a class NOC c oe O has c o NEDC number of efferent dependencies of a class NEDC c Zge cu depends_on c d weight 9 2 Objektive Metriken 123 Paket NCP number of classes in a package NCP p ce C contains p c NIP number of interfaces in a package NIP p fiel contains p i
239. hteil ist allerdings dass die Muster wegen ihrer Abstraktheit erst noch f r das konkrete Problem ausgepr gt werden m ssen Gute Musterdokumentation gibt aber auch dazu Hinweise 4 3 3 Architekturstile und Architekturmuster Bei der Entwicklung einer Architektur kann man sich an Architekturstilen Shaw Garlan 1996 orientieren Ein Architekturstil architectural style kann als Architek turphilosophie aufgefasst werden er ist so etwas wie eine Meta Architektur Shaw und Garlan unterscheiden Architekturmuster z B Model View Controller die all gemeiner Natur sind und Referenzmodelle z B ISO OSI 7 Schichtenmodell die in der Regel f r bestimmte Anwendungsfelder gedacht sind Architekturstile treten h u fig kombiniert auf z B auf verschiedenen Abstraktionsebenen der Architektur Tabelle 4 1 zeigt eine bersicht ber verschiedene Architekturstile Die Wahl eines Architekturstils legt den Entwerfer auf eine bestimmte Sichtweise fest mit der die Probleml sung angegangen wird Es werden Komponenten und Konnek torentypen sowie ihre Kombinationsregeln vorgegeben Innerhalb der Sichtweise kre iert der Entwerfer seine Architektur anhand der vorgegebenen Spielregeln Das hat den Vorteil dass dem Entwerfer ein Rahmen zu Verf gung gestellt wird an dem er sich orientieren kann Allerdings ist jetzt die Auswahl eines passenden Architek turstils entscheidend Der Stil muss sich f r das Problem eignen Ansonsten entsteht zus tzl
240. ibilityKind isAbstract Boolean kind ParameterDirectionKind ownerScope ScopeKind A Dn D n parameter feature ownedElement fordered owner BehavioralFeature Attribute Class Interface DataType Abbildung 5 1 UML Metamodell Modellelemente Ausschnitt StructuralFeature ordered Die gemeinsame Oberklasse aller Modellelemente ist die Klasse ModelElement vgl Abbildung 5 1 NameSpace Namensraum eine Unterklasse von ModelElement ent h lt eine beliebige Anzahl von Modellelementen und dient zur hierarchischen Struk turierung 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 General izableElement generalisierbares Element wodurch ausgedr ckt wird dass ein Klassi fizierer Eigenschaften von anderen Klassifizierern erben kann Class Interface und DataType sind Unterklassen von Classifier Klassifizierer k nnen Features Eigenschaf ten enthalten das ist hier durch eine Komposition modelliert Attribute und Operation sind Unterklassen von Feature Beziehung
241. ice Hall 1980 171 Beyer et al 2000 Beyer D Lewerentz C Simon F Impact of Inheritance on Met rics for Size Coupling and Cohesion in Object Oriented Systems In Dumke R Abran A Hrsg New Approaches in Software Measurement Proceedings of the 10th International Workshop on Software Measurement IWSM 2000 Lecture Notes on Computer Science 2006 Springer Berlin 2000 1 17 Bieman 1992 Bieman J Deriving Measures of Software Reuse in Object Oriented Systems In Denvir T Herman R Whitty R Hrsg Formal Aspects of Measure ment Proceedings of the BCS FACS Workshop on Formal Aspects of Measurement London Springer London 1992 63 83 Bieman Kang 1995 Bieman J Kang B Cohesion and Reuse in an Object Oriented System Proceedings of the ACM Symposium on Software Reusability SSR 95 1995 259 262 Bieman Kang 1998 Bieman J Kang B Measuring Design Level Cohesion IEEE Transactions on Software Engineering 24 2 1998 111 124 Binkley Schach 1996 Binkley A Schach S A Comparison of Sixteen Quality Met rics for Object Oriented Design Information Processing Letters 58 6 1996 271 275 Boehm 1976 Boehm B Software Engineering IEEE Transactions on Computers 25 12 1976 1226 1241 Boehm 1983 Boehm B Seven Basic Principles of Software Engineering Journal of Systems and Software 5 3 1983 3 24 Boehm Basili 2001 Boehm B Basili V Software Defect R
242. iche Ankunftszeit e k rzeste Fahrtzeit e wenigste Umsteigehaltestellen Die Ergebnisse werden dem Fahrgast angezeigt Er kann sie sich aber auch in eine Datei im HTML Format drucken lassen Das System entnimmt die Fahrpl ne der Linien einer Fahrplandatei Diese Datei kann nur ver ndert werden wenn das Fahrplaninformationssystem nicht von Fahrg sten benutzt wird Dies geschieht durch einen Servicetechniker der hierzu einen nur ihm zug nglichen Programmteil verwendet Hiermit lassen sich Fahrplandaten ver n dern l schen oder neu eingeben Das Programm muss unter Unix laufen und eine graphische Benutzungsoberfl che besitzen C 1 5 Entwicklungsumgebung Werkzeuge und Richtlinien Wie bereits angesprochen muss das gesamte Programm in Java Version 2 geschrie ben werden Das Java 2 Software Development Kit kurz JDK in der Version 1 2 steht Ihnen auf den Rechnern des ehemaligen Grundstudium Pools sowie auf den Linux Rechnern des Pools zur Verf gung Das JDK in den Versionen 1 2 oder 1 3 gibt es auch kostenlos f r eine ganze Reihe von Rechnerplattformen insbesondere Linux und Windows Sie k nnen diese Versionen gerne verwenden wir k nnen aber keine Hilfe stellung daf r bieten Bei der Abgabe muss das Programm auf unseren Maschinen Sun Solaris mit instal liertem JDK 1 2 2 ausf hrbar sein Bitte achten Sie darauf Insbesondere wenn Sie unter Windows entwickelt haben sollten Sie auf jeden Fall Ihr Programm vor der Abgabe unt
243. icher Aufwand um das Problem dem Stil anzupassen Bass et al 1998 Kap 5 geben einige Hinweise welcher Stil sich f r welche Probleme eignet 4 3 Muster und Rahmenwerke 33 Kategorie Datenflusssysteme Sequentielle Batch Dateien Pipes und Filter Aufruf und R ckkehr Systeme Hauptprogramm und Unterprogramme Objektorientiertes System Hierarchische Schichten Unabh ngige Komponenten Kommunizierende Prozesse Verteilte Systeme z B Client Server Multi Tier Ereignisgesteuertes System Virtuelle Maschinen Interpreter Regelbasiertes System Datenzentriertes System Repository Datenbank Hypertext System Schwarzes Brett Blackboard Tabelle 4 1 Beispiele f r Architekturstile nach Shaw und Garlan 1996 S 20 4 3 4 Entwurfsmuster Entwurfsmuster design patterns definieren Mikro Architekturen d h kleinere Ein heiten innerhalb einer Architektur Sie bieten abstrakte L sungen f r das Zusammen spiel weniger Komponenten an H ufig geht es um die Entkopplung einzelner Kom ponenten um eine bessere nderbarkeit zu erreichen Tabelle 4 2 zeigt eine bersicht ber die Muster des ersten und bekanntesten Buchs ber Entwurfsmuster von Gamma et al 1995 Objekterzeugung Klasse Factory Method Strukturmodellierung Adapter class Verhaltensmodellierung Interpreter Template Method Objekt Abstract Factory Builder Prototype Singleton Adapte
244. ichkeiten vollstandig 0 nein 1 ja O nein 1 ja KEK KEK Hat die Klasse mindestens eine Operation ein schlie lich der geerbten 0 nein 1 ja Hat die Klasse nicht nur get set Operationen 0 nein 1 ja KEK Verf gt die Klasse h chstens ber wenige get set Operationen viele get set Operationen deuten auf eine schlechte Aufteilung hin da sich offensichtlich Funktionalit t au erhalb der Klasse befindet O nein 1 ja thise Stellt das Interface alle n tigen Operationen f r einen einzigen Dienst zur Verf gung O nein 1 ja KEK thise Enth lt das Interface ausschlie lich die f r seinen Dienst notwendige Operationen O nein 1 ja KEK Realisiert jede Operation eine einzige Funktion 0 nein 1 ja Fragebogen B 10 Zusammenhalt Klasse Interface Abschnitt 1 von 2 210 B Frageb gen fur QOOD Bedingung Fragetext Antwortskala Gewicht auto Realisiert jede Operation ihre Funktion auf einer 0 nein x gewissen Abstraktionsebene vollst ndig 1 ja Wird jedes Attribut von mindestens einer Opera 0 nein tion mit Ausnahme der get set Operationen der 1 ja Klasse ben tigt Ben tigt jede Operation mindestens ein Attribut 0 nein ae der Klasse 1 ja Fragebogen B 10 Zusammenhalt Klasse Interface Abschnitt 2 von 2 Paket Bedingung Fragetext Antwortskala Gewicht auto Bi
245. ie Gesamtzahl der Attribute einer Klasse und die Anzahl der privaten Attribute so stark korreliert dass nur eines von beiden verwendet werden sollte H ufig kann eine Metrik auch zur Messung verschiedener Kriterien herangezogen werden z B ist die Anzahl der Vererbungsbeziehungen sowohl eine Entkopplungs als auch eine Strukturiertheits metrik hier ist also Vorsicht geboten vgl Abschnitt 9 6 2 Weitere Hinweise 9 2 Objektive Metriken 121 Akronym Bedeutung Ebene Kriterium NADC number of afferent dependencies of a class Klasse Entkopplung NEDC number of efferent dependencies of a class Klasse Entkopplung Knappheit NEEC number of efferent extends relationships of a class Klasse Entkopplung Knappheit NERC number of efferent realization relationships of a class Klasse Entkopplung Knappheit NEUC number of efferent uses relationships of a class Klasse Entkopplung Knappheit NEAC number of efferent association relationships of a class Klasse Entkopplung Knappheit NACP number of afferently coupled packages of a package Paket Entkopplung NADP number of afferent dependencies of a package Paket Entkopplung NECP number of efferently coupled packages of a package Paket Entkopplung NEDP number of efferent dependencies of a package Paket Entkopplung NAC number of attributes of a class Klasse Knappheit NOC
246. ie Zunahme bei CBO und RFC f r Movie deutlich Betrachtet man die Durchschnitte der Metriken ber die drei Entw rfe zeigt sich bei WMC CBO und RFC ein Trend zugunsten von Entwurf C der aber auch durch die deutlich h here Anzahl von Klassen im Vergleich zu A und B bedingt ist Bei DIT und NOC jedoch verl uft der Trend zu Ungunsten von Entwurf C Schlussfolgerungen Die nderungen von Entwurf A nach B und von B nach C dienen der Entkopplung und damit der nderbarkeit Bei Entwurf C nimmt die Zahl der Klassen aber stark zu und verschlechtert so die durch die Entkopplung verbesserte Verst ndlichkeit wieder Es wird Flexibilit t eingebaut die aber nur dann wirklich sinnvoll ist wenn sich die Preiscodes tats chlich ndern werden Die G te des Entwurfs h ngt also auch vom Kontext der Software ab Mit Hilfe der erhobenen Metriken lassen sich bei C nur Nachteile aber keine Vorteile feststellen au er bei einer fragw rdigen Durchschnitts bildung Das zeigt auch dass sich nicht alle Qualit tsattribute gleich gut quantifizie ren lassen Eine vollst ndig automatisierte Entwurfsbewertung d rfte damit schwie rig wenn nicht gar unm glich sein Das Beispiel verdeutlicht dass es Grunds tze gibt die fast immer sinnvoll sind z B Entkopplung sowie Kapselung von Details und von sich wahrscheinlich ndernden Entwurfsentscheidungen Diese Grunds tze sollten immer beachtet werden wenn dabei nur geringe Mehrkosten entstehen Flexibilit
247. iefer Zeit das magische Viereck nimmt noch den Funktions Umfang als Optimierungsgr e hinzu vgl Abbildung 6 8 Wird hier eine Gr e z B Qualit t optimiert geht das immer zu Lasten der anderen Gr en Daher muss ein optimaler Kompromiss gefun den werden 72 6 Softwarequalitat Zeit Zeit Umfang Qualitat Kosten Qualitat Kosten Abbildung 6 8 Magisches Dreieck und Viereck Die Idee der Good Enough Quality ist es bei der Qualit t nicht die gr tm gliche anzustreben sondern nur die notwendige Dazu wird mit dem Kunden tiber den gew nschten Kompromiss zwischen den konkurrierenden Zielen des magischen Drei oder Vierecks verhandelt Yourdon 1995 Entscheidend ist dabei dass der Kunde die Entscheidung f llt nicht die Entwickler wie wichtig welches Ziel ist Die Entwickler sagen dem Kunden nur was machbar ist und was nicht Auch innerhalb der Qualit t gilt es abzuw gen denn Qualit t ist multidimensional Bosch 2000 Bass et al 1998 S 75 stellen dazu fest No quality can be maximized in a system without sacrificing some other quality or qualities Das erfordert einen Kompromiss zwischen den verschiedenen Qualit ten Der optimale Kompromiss kann leichter ermittelt werden wenn klar ist welche Qualit ten in welchem Umfang gefordert sind Ein projektspezifisches Qualit tsmodell implementiert dann diesen Kompromiss z B in Form einer Gewichtung 73 Kapitel 7 Entwurfs
248. ien die fter auftreten z B Kopplung und Zusammenhalt diese unterscheiden sich aber jeweils in ihren Definitionen In der Struktur der Modelle ist keine klare Trennung der Detaillierungs ebenen Methode Klasse etc erkennbar Au erdem werden die Systemebene kaum 96 7 Entwurfsqualitat und die Paketebene gar nicht betrachtet Stattdessen ist die Sichtweise meist auf Klas sen und ihre Bestandteile fokussiert Die Beziehungen zwischen Klassen Vererbung Assoziation werden selten explizit und oder gar detailliert betrachtet Nur die letzten drei Modelle enthalten eine Quantifizierung Die Quantifizierung bei Gillibrand und Liu ist allerdings nur fragmentarisch dokumentiert und daher unbrauchbar Au erdem deckt das Modell nur einen kleinen Teil der relevanten Qua lit tsattribute ab Bei Erni findet sich eine brauchbare Quantifizierung die allerdings auf die unterste Ebene die Metrikenebene beschr nkt ist Nur bei Bansiya und Davis gibt es eine Quantifizierung f r alle Ebenen Interessanterweise geben manche Autoren von Metrikensammlungen f r den objekt orientierten Entwurf z B Whitmire 1997 zwar Metriken und damit zusammenh n gende Entwurfskriterien an legen sich aber nicht auf den gew nschten Erf llungs grad der Kriterien oder gar auf Schwellenwerte f r Metriken fest Eine lobenswerte Ausnahme ist das Buch von Lorenz und Kidd 1994 das eine Sammlung von einfa chen objektorientierten Metriken auf Code Ebene e
249. ierte Beziehungen lt gt lt gt lt gt lt gt z x Interpretation Unterschei Unterschei Differenzen Verhaltnisse der hinzukom dung gleich dung kleiner haben empiri haben empiri menden Bezie ungleich m g gr er m g schen Sinn schen Sinn hungen lich lich Zugelassene umkehrbar monoton lineare hnlichkeits Identit t Transformatio eindeutige steigende y ax b a gt 0 transform y x nen bijektive isotone y ax a gt 0 Beispiele f r Postleitzahlen Schulnoten Celsius Kelvin Teamgr e Merkmale Autokenn Milit rische Temperatur Temperatur Fehlerzahl zeichen Dienstgrade Kalender Einkommen Lines of Code Artikel Mercallische datum Richtersche nummern Erdbeben zyklomatische Erdbeben Symbole skala Komplexit t skala Fehlerursa Windst rke McCabe 1976 Windgeschw chen IEEE Beaufort m s Std 1044 Prozessreife Projektdauer 1993 S 9 grad CMM Beispiele fur Modalwert Quantile arithmeti geometri wie Rational statistische Haufigkeiten Median scher Mittel scher Mittel skala wenn Kennwerte Quartile wert wert der Wertebe Standard Variations reich in die abweichung koeffizient rationalen Zahlen einge bettet wird Statistische Verfahren nichtparametrische parametrische unter Beachtung der Modellvoraussetzungen Informations inhalt gering hoch Empfindlich keit gegen ber gering hoch Ergebni
250. ieses Ph nomen wird hier an einem Beispiel demonstriert Das spezifische Quali t tsmodell wird auf das Beispiel aus Abschnitt 7 1 angewendet Dort wurden drei Entwurfsalternativen f r ein Videoverleihsystem vorgestellt Tabelle 10 11 und Tabelle 10 13 zeigen die Messwerte f r die wichtigsten Klassen und Systemmetriken der Entw rfe A bis C Die Paketmetriken werden weggelassen da es nur ein Paket das System gibt Tabelle 10 12 und Tabelle 10 14 enthalten die subjektiven Metriken f r die Kriterien des Faktors Wartbarkeit Entwurf A geht aus Entwurf B hervor indem unn tige Kopplung und dadurch unn tige Operationen entfernt werden Dies schl gt sich in einem R ckgang der Metriken NOC bei Rental und NEDC bei Customer nieder Dadurch verbessern sich die Bewertungen bei der Knappheit SCCC SCCS und der Entkopplung SDCC SDCS wodurch die Wartbarkeit besser bewertet wird SMAC SMAS Entwurf C geht aus Entwurf B hervor indem das State Muster auf die Klasse Movie angewendet wird f r die Preiscodes Dadurch kommen die abstrakte Klasse Price und ihre drei Unterklassen hinzu Die Anzahl der Klassen NCS nimmt stark zu wodurch sich die Knappheit SCCS verschlechtert Durch die hinzukommende Ver 10 3 Besonderheiten bei Mustern 149 Metrik Cc Cc Cc Customer o O O p 1 1 o jo O JO JO o J2 1 1 Rental 1 1 1 2 J1 1 o jo jo Jo jo jo p 1 1 Movie 1
251. ifiziert der Einsatz der Technologie aber notwendig k nnen die Teile die bei einer abzusehenden Portierung ge ndert werden m ssen im Entwurf flexibel genug gestaltet werden 4 5 4 Komplexit t des Entwerfens Consciousness about design does not imply the application of a formal consistent or compre hensive theory of design or of a universal methodology Systematic principles and methods at times may be applicable to the process of design but there is no effective equivalent to the ratio nalized generative theories applied in mathematics and traditional engineering Design con sciousness is still pervaded by intuition tacit knowledge and gut reaction Winograd et al 1996 Problemklassen nach D rner Ein Problem ist nach D rner 1976 durch drei Merkmale gekennzeichnet Es gibt einen unerw nschten Ausgangszustand a einen erw nschten Zielzustand und eine Barriere welche die Transformation von o in o verhindert Fehlt die Barriere d h ist die Transformation bekannt spricht Dorner von einer Aufgabe F r die Trans formation steht eine Menge von Operatoren 04 09 On das so genannte Operato reninventar O zur Verf gung Eine Transformation ist eine Folge von Operationen d h von konkreten Anwendungen der Operatoren D rner unterscheidet drei Klas sen von Problemen Syntheseprobleme Interpolationsprobleme und dialektische Pro bleme Diese unterscheiden sich vor allem durch die Art der Barrieren In Abbildung 4 4
252. ifizierung des wichtigsten Faktors von QOOD der Wartbarkeit auf der Basis von Metriken und Frageb gen Au erdem wird beschrieben wie aus den Messwerten eine Bewertung gewonnen wird 6 1 Einf hrung In Kapitel 10 wird ein spezifisches Qualit tsmodell f r eine Fallstudie entwickelt angewendet und validiert In Kapitel 11 wird beschrieben wie das Verfahren durch Werkzeuge unterst tzt werden kann Kapitel 12 schlie lich fasst die Arbeit zusammen und bewertet sie Der vorgestellte Ansatz zur Entwurfsbewertung wird mit anderen Arbeiten verglichen Den Abschluss der Arbeit bildet ein Ausblick Informationsfl sse 1 Einf hrung a Modellbegriffe b Metrikenbegriffe c OO Begriffe d UML 2 Modelle und e Entwurfsbegriffe Metriken f ODEM 8 g Qualit tsbegriffe a b a h Qualit tsmodellbegriffe i Entwurfsqualit t DR S j Prinzipien 3 Objektorientierung 6 Qualitat k Heuristiken Faktoren und Kriterien c d g h l m Metriken n Frageb gen 4 Objektorientierter d Ge 7 Entwurfsqualitat o Anforderungen Entwurf Softwarepraktikum e i j k 5 Ein Referenzmodell e 8 Das allgemeine f r den OO Entwurf Qualit tsmodell f y m Anhang A Metriken 9 Quantifizierung des la f r QOOD Qualit tsmodells heal Anhang B Frageb gen EE f r QOOD 10 Ein spezifisches o Anhang C Dokumente Qualit tsmodell zum Softwarepraktikum 11
253. igen Bildschirm mit graphischer Benutzungsoberfl che besitzt Daran sollte auch auf keinen Fall etwas ge ndert werden Das Endprodukt muss demzu folge auf einer UNIX Maschine lauff hig sein und mit einer graphischen Benutzungs oberfl che ausgestattet werden F r die Programmierung der Benutzungsoberfl che muss Java Swing verwendet werden dies gibt der Verkehrsbetrieb im Sinne einer ein heitlichen Benutzungsoberfl che f r all seine Applikationen so vor Die Ausgaben des Programmes erfolgen auf dem Bildschirm oder in eine Datei im Falle der HIML Ausgabe die Eingabe ber Maus und Tastatur Des Weiteren liest das Programm Daten aus einer Fahrplandatei bzw greift schreibend auf diese Datei zu Eine solche Datei stellt der Verkehrsbetrieb als Beispiel zur Verf gung Zu bezie hen ist diese Datei von unseren Web Seiten Adresse siehe Aufgabenblatt Die Hard ware verf gt ber eine Festplatte von mindestens 10 MByte Kapazit t zum Speichern der Programmdaten Der Auftraggeber hat keinerlei weitere Peripherieger te In der jetzigen Version ist es vorgesehen dass max ein Benutzer das Programm gleichzeitig ausf hren kann Es m ssen also keine Konflikte beachtet werden die auf treten k nnen wenn mehrere Personen gleichzeitig mit den gleichen Daten umgehen C 2 3 Modi des Fahrplanauskunftssystems Das Fahrplanauskunftssystem kann in zwei Modi arbeiten dem Fahrgast Modus in dem ein potentieller Fahrgast Verbindungsanfragen stellen ka
254. ilfe sehr schlecht sehr gut b 0123456789 Hee Abbildung 11 4 Der Bewertungsbereich Knappheit Um dem Bewerter beim Ausf llen des Review Bogens zu helfen kann der Bogen durch Links mit Hilfe Seiten verkn pft werden Diese enthalten e Erl uterungen zu den Metriken Kommentare zu den Fragen der Frageb gen e Verbesserungsvorschl ge zu durch Fragen aufgedeckten Problemen und 158 11 Werkzeugunterstutzung e Hinweise zur Abw gung verschiedener Aspekte bei der subjektiven Bewertung Die Hilfe Seiten bilden zusammen eine Art Handbuch zur Entwurfsbewertung Abbildung 11 5 zeigt ein Beispiel f r eine Hilfe Seite passend zum in Abbildung 11 4 dargestellten Ausschnitt des Review Bogens ERHEBEN Knappheit einer Klasse Metriken 3 NAC number of attributes of a class Die Gesamtzahl der Attribute einer Klasse einschlie lich der geerbten Attribute NAC1 number of public attributes of a class 4 Die Gesamtzahl der Attribute einer Klasse mit Sichtbarkeit public einschlie lich der geerbten Attribute 4 NAC2 number of protected attributes of a class Die Gesamtzahl der Attribute einer Klasse mit Sichtbarkeit protected einschlie lich der geerbten Attribute f NAC3 number of private attributes of a class 3 Die Gesamtzahl der Attribute einer Klasse mit Sichtbarkeit private einschlie lich der geerbten Attribute Fragen 4 Enth lt die Klasse nur die n tigen Attribute q z B keine nicht mehr verwe
255. ind in Abbildung 8 1 darge stellt Ein Pfeil bedeutet dass das Kriterium den Faktor positiv beeinflusst Im Folgen den werden die einzelnen Kriterien von links nach rechts diskutiert Wartbarkeit coor oe Knappheit Strukturiertheit Entkopplung Zusammenhalt Einheitlichkeit Dokumentierung Verfolgbarkeit Abbildung 8 1 Kriterien des Faktors Wartbarkeit 8 3 1 Knappheit Weniger ist mehr Mies van der Rohe Vollkommenheit entsteht offensichtlich nicht dann wenn man nichts mehr hinzuzuf gen hat sondern wenn man nichts mehr wegnehmen kann Antoine de Saint Exupery Wind Sand und Sterne Inside every large program there is a small program trying to get out C A R Hoare Ultimately the best software design assimilates all its functions to a few clear and simple prin ciples Nelson 1990 S 236 Definition Knappheit bedeutet im Entwurf mit wenig Konstrukten in einer geringen Anzahl von Auspr gungen auszukommen Schon die gro e Zahl an Zitaten aus verschiede nen Bereichen Architektur Flugzeugbau und Software Entwicklung deutet auf die gro e Bedeutung der Knappheit hin Beispiele f r Knappheit beim objektorientierten Entwurf sind e eine minimale Anzahl von Klassen e eine minimale ffentliche Schnittstelle einer Klasse e eine minimale Anzahl von Attributen und Methoden in einer Klasse e eine minimale Anzahl von Parametern bei Methoden e eine minimale Anzahl von Beziehungen Assoziationen Vererbung etc
256. ine 5 Modelle und Mie tri ken sun nein 7 SE We ee E TEE 7 E EE 9 Objektorientierung norii a a a 15 3 1 Begriffe E 16 3 2 Unified Modeling E EE 21 Objektorientierter Entwurf anne Rn aan 23 41 WAS TSE EMT ES EE 23 4 2 Klassifikationen des Entwur 2u l a8 n Bea 27 4 3 Muster und Rahmenwerke nu nie 30 4 4 Dokumentation des Entwurfs ccsscsccsscscssscscsssescsssescsssescssseccssseccsssecessceees 34 4 57 Probleme deS EE 35 Ein Referenzmodell f r den objektorientierten Entwurf esesesesesesrsrerereseresesesee 43 5 1 Grundlag EE 43 9 2 RT 45 553 E 48 5 4 Erweiterungen engine 52 5 5 Formale Definition von Metriken 0 0 cceeeececscecececsssssnssssensssssnsssnssssensnsnsssneeaes 55 viii Inhaltsverzeichnis 6 SOL W ave Ua E 59 6 1 WPT EE 59 6 2 Q alitatsmodele nisani anene aug titel vas tease nl 63 Drees 69 7 Entw rfsauaht t u Eege 73 7 1 Ein BOIS Piel ann ee ea ale 73 7 2 Perspektiven der Entwurfsqualt t an Seege dreEu 78 7 323 Entw urlsresena ne een aaa 83 7 4 Beispiele f r OOD Qualitatsmodelle anziehen ea 88 7 5 Qualit tssicherung beim Entwurf nen 96 7 6 e EE EE 97 8 Das allgemeine Qualit tsmodell csscssssssssssossussssnenussesnesussnsnssnessennsnnsnennsnnsnenns 101 8 1 el ER EE 101 ER td E Ee EE 104 g WHALE AL REM GE 105 9 4 WHER GIy CRW CI LID E 112 8 5 RTE EE lee EEN 113 8 6 Drauchbarkeit EEN 114 KEE 115 E et E EE 116 8 9 Weitere m gliche Fakt
257. ine Klasse kann beliebig viele andere Klassen benutzen auch keine F r die Benutzung gibt es unterschiedliche Zwecke z B die Instantiierung den Aufruf einer Operation die Verwendung als Parametertyp in einer Operation oder als Typ eines Attributs Eine Klasse benutzt sich in der Regel selbst diese implizite Benutzung wird aber traditionell nicht ber cksichtigt Die Ableitung vom UML Metamodell ist analog zur uses Relation bei den Interfaces 5 3 5 Attribut A ist die Menge aller Attribute die im System vorkommen Attribute name Name Der Name des Attributs type Classifier Typ des Attributs der sich aus der gerichteten Assoziation von StructuralFeature mit Classifier im UML Metamodell ergibt visibility VisibilityKind Sichtbarkeit des Attributs kann die Werte public pro tected und private annehmen owner Scope ScopeKind Gibt an ob es sich um eine Klasseneigenschaft Wert classi fier oder eine Objekteigenschaft Wert instance handelt 5 3 6 Operation O ist die Menge aller Operationen die im System vorkommen Attribute name Name Der Name der Operation visibility VisibilityKind Sichtbarkeit des Attributs kann die Werte public pro tected und private annehmen ownerScope ScopeKind Gibt an ob es sich um eine Klasseneigenschaft Wert classi fier oder eine Objekteigenschaft Wert instance handelt Beziehungen has O x M Eine Operation besitzt einen Parameter Eine Operation kann beliebig
258. initionen und Erweiterungen in der Unterklasse Diskussion Interne Wiederverwendung kann zu geringerer Redundanz f hren weil die Entwer fer sich darum bem hen m ssen Gemeinsamkeiten herauszul sen und an einer Stelle zusammenzufassen Dies f hrt in der Regel zu h herer Knappheit Externe Wie 8 5 Wiederverwendbarkeit 113 derverwendung hingegen kann sich negativ auf die Knappheit auswirken da die wiederverwendete Komponente m glicherweise mehr Funktion bietet als ben tigt wird Es ist allerdings selten wirtschaftlich sienur darum zu modifizieren Der Faktor Wiederverwendung l sst sich nicht in sinnvolle Kriterien zergliedern 8 5 Wiederverwendbarkeit Definition Wiederverwendbarkeit bezieht sich auf die M glichkeit das entworfene System als Ganzes leicht modifiziert in einem anderen Kontext wiederzuverwenden oder Teil systeme und einzelne Komponenten unver ndert oder leicht modifiziert in anderen Systemen wiederzuverwenden Je einfacher das ist desto h her ist die Wiederver wendbarkeit Diskussion F r die Wiederverwendbarkeit spielt die Allgemeinheit des Entwurfs eine wichtige Rolle da sich allgemeine Bausteine leichter an neue Kontexte anpassen lassen Au er dem hilft Verst ndlichkeit bei der Wiederverwendung da man kaum etwas wieder verwenden m chte was man nicht versteht Daher sind die Kriterien Knappheit Strukturiertheit Entkopplung Zusammenhalt Einheitlichkeit und Dokumentation aus der Wartbarke
259. ir den objektorien tierten Systementwurf fiir die Erhebung von Metriken auf UML Modellen erstellt Dabei war zun chst festzulegen wie die Metrikenerhebung realisiert wird Liegt das UML Modell in einem UML Werkzeug vor gibt es drei M glichkeiten 1 Das UML Werkzeug erzeugt eine Repr sentation des UML Modells im standardi sierten Austauschformat XMI XML Metadata Interchange OMG 2000b Die XMI Datei wird anschlie end geparst um die Metriken zu erheben 2 Besitzt das UML Werkzeug eine Skriptsprache oder eine geeignete API mit der auf die Modellinformation zugegriffen werden kann wie z B bei Rational Rose k n nen die Metriken durch Skripte o A erhoben werden 3 Die Funktionalit t zur Metrikenerhebung wird direkt in den Code des Werkzeugs eingebaut M glichkeit 2 und 3 haben den Nachteil dass sie spezifisch f r ein bestimmtes UML Werkzeug sind Dagegen kann bei M glichkeit 1 jedes UML Werkzeug verwendet werden das standardkonformes XMI erzeugt Daher wurde f r die Realisierung die XMI Variante gew hlt Das Werkzeug MOOSE besteht aus zwei Teilwerkzeugen Konverter und Reportgene rator Der Konverter berf hrt ein UML Modell im XMI Format in ein ODEM Modell Der Reportgenerator erzeugt anhand einer Vorlage Berichte ber den Ent wurf in die Modellinformationen und Messwerte der Metriken aus QOOD eingebet tet sind 11 2 1 Der Konverter Der Konverter zieht aus UML Modellen die in einer XMI Datei gespeiche
260. isibilityKind Bedeutung und Herleitung analog zu der bei den Paketen Beziehungen e extends IxI Ein Interface erweitert ein anderes Interface d h es erbt von ihm Ein Interface kann beliebig viele Interfaces erweitern auch keine Im UML Metamodell wird diese Beziehung durch die Klasse Generalization repr sentiert extends i j gilt genau dann wenn es eine Instanz g von Generalization gibt bei der die Rolle g parent mit j und die Rolle g child mit i belegt ist e has 1xO Ein Interface besitzt eine Operation Ein Interface kann beliebig viele Operationen haben auch keine Geerbte Operationen z hlen nicht mit Im UML Metamodell wird das Besitzen einer Operation durch die Komposition zwischen Classifier und Feature einer Oberklasse von Operation modelliert has i o gilt genau dann wenn es eine Instanz der Komposition gibt bei der die Rolle owner mit i und die Rolle feature mit o besetzt ist e uses 1x CUT Ein Interface benutzt eine Klasse oder ein Interface Ein Interface kann beliebig viele andere Klassen Interfaces benutzen auch keine Fiir die Benutzung gibt es unterschiedliche Grtinde z B die Verwendung als Parametertyp in einer Opera tion Im UML Metamodell steht die Klasse Usage fiir Benutzungsbeziehungen uses i j gilt genau dann wenn es eine Instanz u von Usage gibt bei der die Rolle u client mit iund die Rolle u supplier mit j belegt ist 5 3 4 Klasse C ist die Menge aller Klassen die im System vorkomm
261. it einer Default Gewichtung von 1 f r jeden Vorschlag gearbeitet werden Wird ein Vor schlag als wichtiger als die anderen angesehen sollte sein Gewicht entsprechend erh ht werden Soll ein Vorschlag ignoriert werden vergibt man das Gewicht 0 Weitere Hinweise Es kann vorkommen dass Metriken f r die Berechnung von Bewertungsvorschl gen f r mehrere Kriterien verwendet werden Bei der Verrechnung der Bewertung von Kriterien miteinander geht dieselbe Metrik dann mehrfach ein erh lt also implizit ein h heres Gewicht Es sollte daher darauf geachtet werden dass nicht unabsichtlich sol che Metriken die Bewertung dominieren Analoges gilt auch dann wenn Kriterien in mehrere Faktoren und damit mehrfach in die Bewertung eingehen 135 Kapitel 10 Ein spezifisches Qualitatsmodell For an actual design task the designer s choices and decisions will need to be resolved solely on the basis of the needs of the particular problem that requires to be solved Budgen 1994 S 151 In diesem Kapitel wird anhand eines Beispiels gezeigt wie aus dem allgemeinen Qua litatsmodell QOOD ein spezifisches Qualit tsmodell abgeleitet wird Dieses Quali t tsmodell wird in einer Fallstudie auf zw lf alternative Entw rfe angewendet und validiert W hrend der Bewertung aufgefallene Details der Entw rfe werden eben falls diskutiert Abschlie end wird die Problematik der Ber cksichtigung von Ent wurfsmustern bei der Bewertung anhand des Beispie
262. it auch f r die Wiederverwendbarkeit wichtig Schwach gekoppelte Komponenten k nnen besser wiederverwendet werden da weniger andere Kompo nenten mittransferiert werden m ssen vgl z B Page Jones 1988 Knappheit kann allerdings auch negativen Einfluss auf die Wiederverwendbarkeit haben n mlich dann wenn Klassen so speziell f r den Anwendungszweck entworfen werden dass sie sich in einem anderen Kontext nicht wiederverwenden lassen Vergleicht man die Kriterien der Wiederverwendbarkeit und der Wartbarkeit stellt man fest dass sie nahezu deckungsgleich sind in Abbildung 8 2 sind die importier ten Kriterien kursiv gesetzt es fehlt nur die Verfolgbarkeit Wiederverwendbarkeit HANSE Allgemeinheit Knappheit Strukturiertheit Entkopplung Zusammenhalt Einheitlichkeit Dokumentierung Abbildung 8 2 Kriterien des Faktors Wiederverwendbarkeit 8 5 1 Allgemeinheit Definition Da man nicht alle M glichkeiten der Wiederverwendung voraussehen kann muss eine Komponente oft vor der Wiederverwendung angepasst werden Dies ist leichter m glich wenn sie Allgemeinheit auch Flexibilit t genannt besitzt Allgemeinheit bedeutet auch Vollst ndigkeit der Abstraktion d h eine Komponente deckt einen m glichst gro en Anwendungsbereich ab vgl Abschnitt 7 4 1 114 8 Das allgemeine Qualit tsmodell Diskussion Eine Komponente allgemein zu machen ist eine Investition in die Zukunft von der oft nicht klar ist ob sie sich lohnt
263. it besteht sein Zweck ausschlie lich in der Definition des zugeh rigen Typs Dies wird vor allem eingesetzt um bestimmte Eigenschaften zu definieren Beispielsweise wird in der Standardbibliothek der Programmiersprache Java das Interface Comparable dekla riert Dieses hat eine abstrakte Operation compareTo die das Objekt mit einem ande ren Objekt vergleicht Eine Klasse die dieses Interface realisiert d h alle Operationen implementiert besitzt dann die vom Interface definierte Eigenschaft dass sie ber die Vergleichsoperation verf gt In UML werden Interfaces wie konkrete Klassen dargestellt nur dass man zur Unter scheidung das Stereotyp interface verwendet Die Realisierung eines Interfaces durch eine Klasse wird durch einen gestrichelten Vererbungspfeil dargestellt vgl Abbildung 3 3 Soll nur der Name des Interfaces angegeben werden kann es auch durch einen Kreis dargestellt werden Lollipop Notation der durch eine durchge zogene Linie mit der realisierenden Klasse verbunden ist 3 1 7 Assoziation Aggregation und Komposition One of the distinguishing features of object design is that no object is an island All objects stand in relationship to others on whom they rely for services and control Beck Cunningham 1989 S 2 Die Assoziation ist nach der Vererbung die wichtigste Beziehungsart zwischen Klas sen In ihrer allgemeinsten Form dr ckt sie aus dass zwei Klassen genauer Instan zen der Klassen eine Ve
264. iteinander verschmolzen ent fallen alle Beziehungen zwischen den beiden Klassen werden also von NEDC nicht mehr mitgez hlt Neue Beziehungen k nnen dagegen durch das Verschmelzen nicht hinzukommen Damit ist die Ungleichung erf llt Axiom BDW5 Das Axiom gilt Werden zwei Klassen miteinander verschmolzen die keine Beziehungen untereinander haben gehen durch das Verschmelzen keine Bezie hungen verloren es kommen aber auch keine dazu Damit ist die Gleichung erf llt Die am Beispiel gezeigte Beweisf hrung l sst sich auf die anderen Entkopplungsmet riken bertragen Ergebnis der Untersuchung ist dass alle f nf Axiome f r alle Metri ken gelten Daher besitzen die Entkopplungsmetriken theoretische Validit t im Sinne von Briand et al 1999 4 Ein Sonderfall ist das Verschmelzen zweier Klassen welche Beziehungen zur selben Klasse haben Entstehen in der Resultatklasse zwei Beziehungen desselben Typs zur selben Klasse handelt es sich dennoch um zwei verschiedene Beziehungen die nicht zusammenfallen 203 Anhang B Fragebogen fur QOOD Dieser Anhang stellt die Frageb gen f r QOOD im Detail vor Die Frageb gen wer den geordnet nach den Entwurfskriterien des Faktors Wartbarkeit siehe Abbildung 8 1 pr sentiert Innerhalb eines Kriteriums sind sie nach Ebenen sortiert wobei mit der untersten Ebene Klassen Interfaces begonnen wird Wenn f r eine Ebene oder ein Kriterium kein Fragebogen verf gbar ist wird eine B
265. itel 10 Dabei gemachte Erfahrungen k nnen neue Modelle oder Hypothesen liefern und zu einer erneuten Iteration des Vorgehens f hren um die Metrik und ihre Grundla gen zu verbessern 6 Anwendung Einsatz der Metrik Kapitel 10 Ein Qualit tsmodell f r den objektorientierten Entwurf ist letztlich eine sehr kom plexe Metrik also l sst sich das Verfahren von Shepperd und Ince zu seiner Entwick lung verwenden Bei der obigen Beschreibung der Phasen des Verfahrens ist in Klam mern angegeben in welchen Kapiteln dieser Arbeit die jeweiligen Aspekte behandelt werden F r die Metriken die f r das Qualit tsmodell ben tigt werden kann das Ver fahren ebenfalls angewendet werden Kapitel 3 Objektorientierung What is object oriented programming My guess is that object oriented programming will be in the 1980 s what structured programming was in the 1970 s Everyone will be in favor of it Every manufacturer will promote his products as supporting it Every manager will pay lip service to it Every programmer will practice it differently And no one will know just what it is Rentsch 1982 S 51 Dieses Kapitel f hrt die wesentlichen Begriffe der Objektorientierung ein und zeigt ihre Darstellung in der Unified Modeling Language UML Eine ausf hrlichere Ein f hrung in die Objektorientierung die objektorientierte Analyse und den objektorien tierten Entwurf findet sich z B bei Booch 1994 Philosophische Grundlagen
266. ittelbare Effizienz eine mittelbare Qualit t In dieser Arbeit interessiert eigentlich die mittel bare Qualit t des Entwurfs also die Eigenschaften des Endprodukts die durch den Entwurf bestimmt sind Da diese Eigenschaften aber nicht gemessen werden k nnen bevor eine Implementierung vorliegt misst man stattdessen Eigenschaften des Ent wurfs und verwendet sie zur Vorhersage der Eigenschaften des Endprodukts Des halb spielen in der Arbeit beide Kategorien eine Rolle 6 2 Qualit tsmodelle The quality of software is measured by a number of totally incompatible criteria which must be carefully balanced in the design and implementation of every program Hoare 1981 S 80 6 2 1 Definition Ein Qualit tsmodell bestimmt den allgemeinen Qualit tsbegriff genauer indem Unterbegriffe Qualit tsattribute angegeben werden aus denen sich die Qualit t zusammensetzt Qualit tsmodelle dienen zur Definition von Qualit t als Qualit ts vorgabe und zur Qualit tsbewertung Di mann 1990 In der Regel werden die Qua lit tsattribute hierarchisch angeordnet vgl Abbildung 6 1 Die Qualit tsattribute der obersten Stufe werden als Faktoren factors bezeichnet die untergeordneten 64 6 Softwarequalitat Attribute heifsen Kriterien criteria Die unterste Stufe bilden die Metriken metrics Ein solches Modell wird als FCM Modell fiir factors criteria metrics bezeichnet Softwarequalitat
267. jektorientierten Systementwurf Object Constraint Language Object Oriented Design Model Object Management Group Object Oriented Analysis Object Oriented Design Quality Function Deployment Quality Model for Object Oriented Design Unified Modeling Language XML Metadata Interchange Extended Markup Language Metrikakronyme Literatur ANA CAM CBO CIS DAM DCC DIT DSC LCOM MFA MOA NOC NOH Average Number of Ancestors Cohesion among Methods in Class Coupling between Object Classes Class Interface Size Data Access Metric Direct Class Coupling Depth of Inheritance Tree Design Size in Classes Lack of Cohesion in Methods Measure of Functional Abstraction Measure of Aggregation Number of Children Number of Hierarchies 188 Akronyme NOM RFC SI WMC Number of Methods Response for a Class Specialization Index Weighted Methods per Class Metrikakronyme QOOD DITC DITS DNHP DNHS MNCS MNPS NAC NACP NADC NADP NAS NCP NCS NEAC NECP NEDC NEDP NEEC NERC NEUC NIP NIS NOC NOS NPP NPS RTTR SCCx SCOx SCSx SDCx SDOx SMAx SSTx STRx depth of inheritance tree of a class depth of inheritance tree of the system depth in nesting hierarchy of a package depth of nesting hierarchy of the system maximum number of child classes in the system maximum number of subpackages in the system number of attributes of a class number of afferently coupled packages of a package number of aff
268. k nnen nun die bei Empirikern beliebten Klassenmetriken von Chidamber und Kemerer 1994 erhoben werden zur Beschreibung der Metriken siehe Abschnitt 5 5 2 F r die Erhebung der Metriken muss f r jede Methode bekannt sein auf welche Attribute sie zugreift und welche Methoden sie aufruft Die Metho denaufrufe k nnen hier aus dem Sequenzdiagramm entnommen werden Dagegen k nnen die Zugriffe auf Attribute aus den UML Diagrammen nicht abgelesen wer den Daher wird mit Vermutungen ber den Zugriff auf die gezeigten privaten Attri bute und zus tzliche angenommene Attribute gearbeitet um die LCOM Metrik berechnen zu k nnen Tabelle 7 1 zeigt die Messwerte 1 Es wird angenommen dass zur Implementierung der Assoziationen in der Klasse von der die Assoziation ausgeht jeweils ein Attribut vorhanden ist 7 1 Ein Beispiel 77 Klasse Movie Rental Customer Price RegularPrice NewReleasePrice ChildrensPrice Durchschnitt Tabelle 7 1 Messwerte der Chidamber Kemerer Metriken OO OO OO OO Oto Da die Metriken Komplexit tsma e sind bedeutet ein geringerer Wert eine bessere Bewertung DIT und NOC zeigen deutlich dass hier sehr wenig mit Vererbung gear beitet wird Das gilt allerdings fast immer f r solche kleinen Beispiele WMC CBO und RFC spiegeln die Verbesserung von A nach B am besten wieder LCOM teilweise Der Preis der Flexibilisierung in C wird durch d
269. ken berechnen lassen Der Ansatz von Together ist allerdings sehr stark Code zentriert z B entsprechen die gepr ften Regeln vor allem Programmierrichtlinien 11 1 3 Bewertung Die vorgestellten Werkzeuge besitzen viele n tzlichen Funktionen die zur Entwurfs bewertung und teilweise auch zur Entwurfsverbesserung genutzt werden k nnen F r den Bewertungsansatz in dieser Arbeit lassen sie sich leider jedoch nicht verwen den Die Code basierten Werkzeuge k nnen von vornherein ausgeschlossen werden da der Ansatz in dieser Arbeit auf UML aufbaut Ebenso scheidet das Werkzeug MEMOS von Baumann aus da es auf einem propriet ren Modellierungsansatz basiert Argo UML von Robbins und Redmiles bietet keine M glichkeit zur Erhe bung von Metriken kann also ebenfalls nicht verwendet werden MAISA von Neno nen et al unterst tzt zwar Metriken kann aber nicht mit den Metriken von QOOD konfiguriert werden Dazu w ren Eingriffe in den Quellcode notwendig der aber nicht zur Verf gung steht Au erdem w ren die Frageb gen sowie die Auswertungs funktion zu erg nzen Deshalb wurde entschieden Werkzeuge zu entwickeln die das Bewertungsverfahren optimal unterst tzen Diese Werkzeuge werden im folgenden Abschnitt vorgestellt 4 GOOSE Graphs on Object Oriented Systems siehe http www fzi de prost tools goose 154 11 Werkzeugunterst tzung 11 2 Selbst realisierte Werkzeuge Schmider 2002 hat das Werkzeug MOOSE Metrikenwerkzeug fi
270. lasse auf die beide zugreifen LCOM ist definiert als die Anzahl von Methodenpaaren mit hnlichkeit 0 keine gemeinsamen Attribute minus die Anzahl der Paare mit einer hnlichkeit gr er 0 Falls das Ergebnis kleiner als 0 ist wird LCOM zu 0 gesetzt Je geringer LCOM desto besser Wie bei CBO scheitert die Formalisierung daran dass Informa tion ber die Zugriffe von Methoden auf Attribute ben tigt wird Fazit DIT und NOC k nnen leicht formalisiert werden weil sie sich auf die Verer bungshierarchie beziehen die Teil des Architekturentwurfs ist Die Metriken CBO RFC und LCOM ben tigen mehr detaillierte Information zur Messung als ODEM bieten kann WMC kann in seiner Standardform formalisiert werden allerdings ist die urspr ngliche Definition zu ungenau um eine eindeutige Formalisierung zu erlauben Zusammenfassung Die Paketmetriken von Martin 1995 lassen sich problemlos formalisieren gleichzei tig wurden bei der Formalisierung L cken in der Definition aufgedeckt Von den Klassenmetriken von Chidamber und Kemerer 1994 l sst sich hingegen nur ein Teil formalisieren F r die brigen Metriken ist eine Formalisierung auf der Basis von ODEM nicht m glich weil daf r detaillierte Informationen ber die Aufrufbeziehun gen von Methoden und den Zugriff von Methoden auf Attribute vorausgesetzt wer den Diese Informationen sind in UML Modellen aber selten verf gbar und daher in ODEM nicht vorhanden Es handelt sich bei CBO R
271. ldet das Paket eine abgeschlossene Einheit 0 nein SE Kriterien eigenstandiger Themenbereich ein 1 ja heitliche Abstraktionsebene enthaltene Kompo nenten geh ren zusammen Liegen Vererbungsstrukturen vollstandig im 0 nein ZS Y Paket eine Ausdehnung der Vererbungsstruktur auf Unterpakete ist unter Umst nden akzeptabel Fragebogen B 11 Zusammenhalt Paket System F r den Zusammenhalt des Systems gibt es keinen Fragebogen Wie bereits in Abschnitt A 4 ausgef hrt gibt es auf Systemebene keine neuen Aspekte nach denen man im Zusammenhang mit dem Zusammenhalt fragen k nnte B 5 Einheitlichkeit Die Frageb gen sollen sicherstellen dass die Standards und Konventionen eingehal ten werden und der Entwurf einem einheitlichen Stil folgt In spezifischen Modellen sollten diese Fragen noch durch Kriterien aus den Namenskonventionen Entwurfs standards etc erweitert werden hier repr sentiert durch entsprechende generische Fragen B 6 Dokumentierung 211 Klasse Interface Bedingung Fragetext Antwortskala Gewicht auto Ist die Namenskonvention f r Klassen Interfaces 0 nein KE Attribute und Operationen eingehalten worden 1 ja Sind alle Entwurfsstandards eingehalten wor 0 nein axe den 1 ja z B Parameterreihenfolge bei Operationen Deklarationsreihenfolge von Klasseneigenschaf ten Mindestumfang der Klassenschnittstelle Is
272. lierter Verfolgbarkeit f r berholt da es h ufig dazu f hrt dass der Entwurf auf dieselbe Weise strukturiert wird wie die Anforderungsdokumentation Das erweist sich als hinderlich wenn viele Bestand teile aus anderen Quellen wiederverwendet werden sollen weil diese oft ganz andere Strukturanforderungen mit sich bringen Daher ergibt sich bei hoher Wiederverwen dung eine Entwurfsstruktur die mit der Struktur der Anforderungen nicht mehr viel gemein hat Hohe Verfolgbarkeit herzustellen ist dann mit hohem Aufwand verbun den sie steht also im Widerspruch zur Wiederverwendung 8 4 Wiederverwendung Definition Es gibt zwei Arten von Wiederverwendung die mehrfache Nutzung neu erstellter Komponenten innerhalb desselben Projekts oder die Wiederverwendung fr her erstellter Komponenten in anderen Projekten Rumbaugh et al 1993 Biemann 1992 nennt diese Arten interne und externe Wiederverwendung Interne Wiederverwen dung verringert die Redundanz Externe Wiederverwendung hat den Vorteil dass bew hrte Komponenten erneut verwendet werden Zweben et al 1995 Im Optimal fall der unver nderten Wiederverwendung entstehen gar keine Entwicklungskos ten aber auch bei einer modifizierenden Wiederverwendung sind die Kosten meis tens geringer als bei einer Neuentwicklung In der Objektorientierung ist zus tzlich eine Zwischenform m glich Eine Klasse wird durch Vererbung unver ndert wieder verwendet und trotzdem modifiziert durch Redef
273. liziert eine Vorzugsrichtung n mlich von der ersten Endhalte stelle zur anderen Endhaltestelle In Wirklichkeit hat eine Linie keine solche Richtung sie hat nur zwei Endhaltestellen Diese implizite Richtung ist nur f r die Interpreta tion der Daten notwendig und der Darstellung des Fahrplans im Programm sie wirkt sich aber ansonsten nicht auf den Programmablauf aus Die Abfahrtszeiten sind die Abfahrtszeiten an einem Kalendertag von 0 00 Uhr bis 23 59 Uhr nicht die blicherweise in Fahrpl nen abgedruckte Reihenfolge von Betriebsbeginn am fr hen Morgen bis Betriebsende Die einzelnen Uhrzeiten werden im Format SS MM Stunde Minute eingetragen und durch Kommata getrennt Die Liste der Zwischenhaltestellen wird nach folgendem Schema erstellt In jeder Zeile steht eine Zwischenhaltestelle Dabei wird zun chst die Fahrzeit zwischen der vorherigen Haltestelle und der in dieser Zeile beschriebenen Haltestelle in Minuten angegeben durch ein Komma getrennt folgt der Name der Haltestelle Die erste End haltestelle also gewisserma en die Starthaltestelle wird in dieser Liste nicht aufge f hrt Der erste Eintrag enth lt also die Fahrzeit zwischen Endhaltestelle und der dort beschriebenen zweiten Haltestelle Die zweite Endhaltestelle wird hingegen in der letzten Zeile aufgef hrt dort muss schlie lich auch die Fahrzeit zwischen vorletzter und Endhaltestelle vermerkt werden Beispiel Linie S1 von Herrenberg nach Plochingen und zur ck
274. ls aus Kapitel 7 behandelt 10 1 Ableitung des Qualit tsmodells 10 1 1 Bewertungsgegenstand Bewertungsgegenstand ist ein Fahrplanauskunftssystem das im Sommersemester 2001 im Rahmen eines Softwarepraktikums im Studiengang Softwaretechnik an der Universit t Stuttgart entwickelt wurde Zw lf Gruppen mit jeweils drei Studierenden Grundstudium 4 Semester lieferten u a je eine Spezifikation einen objektorientier ten Entwurf und eine Implementierung in Java ab Da die zugrunde liegenden Anfor derungen dieselben waren sind die zw lf Entw rfe gut vergleichbar bis auf Abwei chungen in der Gestaltung der Benutzungsoberfl che die nicht vorgegeben war Die Aufgabenstellung eine Aufstellung der Anforderungen und das Begriffslexikon sind in Anhang C abgedruckt Das Fahrplaninformationssystem setzt auf einer Datenbasis auf die Linien Haltestel len Abfahrtszeiten an den Endhaltestellen und Fahrzeiten zwischen den Haltestellen umfasst Das System besitzt zwei Modi den Fahrgastmodus und den Administrator modus Im Fahrgastmodus kann der Benutzer Verbindungen suchen und ausdru 136 10 Ein spezifisches Qualit tsmodell cken Bei der Verbindungssuche k nnen verschiedene Optimierungsziele angegeben werden z B k rzeste Fahrtzeit oder m glichst wenige Umsteigehaltestellen Im Administratormodus k nnen die Fahrplandaten ver ndert werden z B k nnen neue Linien hinzugef gt werden Als Beispielsdatenbasis stand den Studierend
275. ls only become known to us as we progress in the implementa tion Some of the things we learn invalidate our design and we must backtrack Parnas Clements 1986 S 251 Nach der bereits angesprochenen Studie der KPMG 1995 ist neu eingef hrte Techno logie mit 45 ein weiterer h ufig genannter Grund f r das Scheitern von Software projekten Technology is developing faster than the skills of the developers Die Entwickler m ssen sich zun chst in die Technologie einarbeiten und machen anfangs viele Fehler bei der Anwendung der Technologie Au erdem sind neue Technologien in der Regel noch nicht ausgereift das gilt insbesondere f r Software basierte Techno logien Schlie lich kann die Technologie auch f r das Problem unangemessen oder unbrauchbar sein was h ufig vorher nicht abzusehen ist Daher stellt der Einsatz einer neuen Technologie beim Entwurf ein nicht zu vernachl ssigendes Risiko dar Aber auch mit vorhandener Technologie gibt es Schwierigkeiten Zun chst muss der Entwerfer Wissen ber verf gbare Technologien haben die er einsetzen kann z B Middleware Standardsoftware Komponenten Bibliotheken Rahmenwerke Er 38 4 Objektorientierter Entwurf muss aber auch absch tzen k nnen ob sich der Einsatz einer bestimmten Technologie lohnt Daf r muss die Zukunftssicherheit der Technologien abgesch tzt werden Im Angesicht raschen Wandels kann es sich dabei nur um Monate handeln Ist ein sol ches Risiko ident
276. m HTML Browser und das Ausdrucken selbst zust ndig Es muss m glich sein das Programm zu beenden C 2 5 Admin Modus Das System muss es einem Benutzer erm glichen in den Admin Modus zu wechseln Um den Admin Modus zu betreten fragt das System ein Passwort ab danach ist der Benutzer im Admin Modus und kann die folgenden Aktionen durchf hren 222 C Dokumente zum Softwarepraktikum e neue Linie einf gen dazu geh ren alle Haltestellen und die Fahrzeiten zwischen den Haltestellen e neue Abfahrtszeit eingeben an den beiden Endhaltestellen e Abfahrtszeit l schen e Linie l schen e Admin Modus verlassen e Passwort ndern e Anzeigen aller Linien nur Name und die beiden Endhaltestellen e Anzeigen einer Linie mit allen Informationen die zu dieser Linie geh ren Halte stellen Fahrzeiten zwischen den Haltestellen Abfahrtszeiten an den beiden End haltestellen C 2 6 Fahrplandatei Eine Beispielfahrplandatei mit den notwendigen Informationen wird auf den Web Seiten angeboten Diese Datei enth lt die Linien S1 bis S6 sowie U1 U6 und U14 Diese Datei soll direkt verwendet werden das heifst das Programm soll diese Datei lesen k nnen und auch eigene Informationen in diesem Format speichern Der Einfachheit halber fahren alle Bahnen immer an den Endhaltestellen los Es gibt also keine Bahnen die an Zwischenhaltestellen starten oder enden Deshalb werden in der Datei nur die Abfahrtszeiten an den Endhaltestellen gesp
277. m den tats chlichen Bedarf einer anderen Komponente gerecht zu werden Ein solches Pro blem stellt man h ufig erst in der Implementierung fest 8 7 Testbarkeit Definition Die Testbarkeit eines Entwurfs ist hoch wenn Komponenten und Integrationstests der implementierten L sung leicht m glich sind Diskussion Zun chst bestimmt die Knappheit den Testaufwand bei Komponententests Je weni ger zu testen ist desto schneller kann es gehen Au erdem wird die Testbarkeit durch Entkopplung verbessert Bei hoher Entkopplung werden f r den Test einer einzelnen Komponente nicht so viele andere Komponenten ben tigt Dadurch kann auch fr her mit dem Test begonnen werden und die Fehlersuche wird einfacher F r den Integrationstest ist es hilfreich wenn der Entwurf es gestattet bottom up ein zelne Komponenten und Teilsysteme zu integrieren und nach jedem Integrations schritt einen Test auszuf hren bis schlie lich das vollst ndige System entstanden ist und einem Systemtest unterzogen werden kann Auch hier spielt die Entkopplung die wichtigste Rolle Testbarkeit Knappheit Entkopplung Abbildung 8 4 Kriterien des Faktors Testbarkeit 116 8 Das allgemeine Qualit tsmodell Die Testbarkeit von objektorientierten Programmen hat ihre fundamentalen Pro bleme Smith und Robson 1990 nennen als Ursache unter anderem Vererbung und Polymorphismus sowie berladen und Redefinition von Methoden Beispielsweise kann das Hinzuf gen ein
278. mens Object Oriented Design Model ODEM entwickelt das auf dem UML Meta modell aufsetzt Da UML Modelle typischerweise nur bei der statischen Beschrei bung des Entwurfs f r eine Bewertung hinreichend vollst ndig sind deckt ODEM nur den statischen Entwurf ab ODEM dient gleichzeitig als Grundlage f r die for male Definition von Metriken es hat sich in Fallstudien mit Metriken aus der Litera tur und bei der Definition der Metriken f r QOOD bew hrt Bei der Quantifizierung des Qualit tsmodells reichen automatisierbare objektive Metriken nicht aus weil sich wichtige semantische Entwurfseigenschaften z B Zusammenhalt damit unzureichend erfassen lassen Daher werden zus tzlich sub jektive Metriken eingesetzt die von einem Entwickler aufgrund seines Eindrucks erhoben werden Er wird dabei durch Frageb gen unterst tzt damit er nichts Wesentliches bersieht Durch die Verwendung subjektiver Metriken kann die Bewer tung nicht vollst ndig automatisiert werden sie kann aber durch ein Werkzeug in gro em Umfang unterst tzt werden F r die Bewertung des wichtigsten Qualit tsfaktors Wartbarkeit hat sich die Ein schr nkung des Verfahrens auf statische Entwurfsinformation als unproblematisch erwiesen In einer Fallstudie konnte nachgewiesen werden dass die relative Wartbar keit von Entwurfsalternativen mit Hilfe des Qualit tsmodells zutreffend vorhergesagt werden kann Der erforderliche Zeitaufwand f r eine Entwurfsbewertung ist ver
279. metriken f r die Entw rfe der zw lf Gruppen Die Bewertungen die subjekti ven Metriken bewegen sich gr tenteils im akzeptablen Bereich Gerade bei der abschlie enden Bewertung der Wartbarkeit SMAS ist die Streubreite eher gering 5 bis 8 Das liegt auch daran dass die Gruppen ihre Entw rfe dem Betreuer vorle gen mussten und dieser die schlimmsten Fehler und M ngel auch in der Dokumen tation beseitigen lie Au erdem wurden die Entw rfe implementiert und aufgrund der Erfahrungen bei der Implementierung berarbeitet so dass zumindest die Reali sierbarkeit sichergestellt ist 10 2 Anwendung des Qualitatsmodells 141 Gruppe NOS NCS NIS NPS RTTR 1 165 20 0 0 0 2 97 21 0 5 0 3 217 24 1 7 0 4 124 21 0 3 0 5 140 19 0 3 0 6 168 25 2 5 0 7 172 25 0 5 0 8 237 31 3 5 0 9 259 28 1 4 0 10 193 32 0 8 0 11 289 34 1 6 0 12 323 36 1 6 0 Minimum 79 97 19 0 0 0 Median 141 183 25 0 5 5 0 Maximum 323 323 36 3 8 0 Gruppe SDCS SCOS SCSS SDOS STRS SMAS 1 6 9 5 5 7 7 0 5 2 7 8 6 7 8 7 0 6 3 6 8 6 7 8 8 0 6 4 7 9 7 7 8 9 0 7 5 7 9 5 7 9 8 0 6 6 5 8 6 7 9 8 0 6 7 6 9 7 8 9 8 0 8 8 6 8 8 8 9 9 0 8 9 5 9 7 7 9 8 0 6 10 6 8 7 8 9 9 0 7 11 4 8 7 8 9 8 0 7 12 5 7 6 8 9 5 0 5 Minimum 4 7 5 5 7 5 0 5 Median 6 8 6 5 7 9 8 0 6 Maximum 7 9 8 8 9 9 0 8 Tabelle 10 6 Subjektive Systemmetriken der Entw rfe
280. models typically are sufficiently com plete for assessment only in respect to static design information ODEM is restricted to static design ODEM is also used as a basis for the formal definition of metrics it has proved effective in case studies with metrics from the literature as well as in defin ing metrics for QOOD When quantifying the quality model automatable objective metrics are not sufficient because they do not cover semantic aspects like cohesion well Therefore also subjec tive metrics are used that are measured by a developer according to his impression He is assisted by questionnaires so as not to overlook important aspects Because of the use of subjective measures the assessment cannot be automated completely but it can be supported by a tool to a large extent The restriction of the assessment to static design information does not impede the assessment of the most important quality factor maintainability In a case study it was proved that the relative maintainability of design alternatives can be predicted cor rectly by the quality model The effort necessary for design assessment is acceptable and can be reduced heavily by tool support vii Inhaltsverzeichnis EE NEE iii Ka essiens sinesine erei risen euere eurer ehe v paN oT E a TE A A E OEA A E T SETOR ER vi Inh ltsyerzeichn15 u EE ee vii Einfuhruno eegene 1 1 1 VAC TAY e e RE 1 12 Zekezun se ee ed naires ta ties oc eas 2 13 Eeer 4 TA Versichern w
281. n EarliestArrivalConnection EEE eee getDistanced int ShortestRideConnection E SE getDistanced int TwoDigitNumber getYaluef String setValue s String isYalid s String boolean TripBlock Ein weiteres Beispiel f r fragw rdige Vererbung stammt von derselben Gruppe vgl Abbildung 10 4 rechte Seite Von einer abstrakten Klasse GenericTrip die f r allge meine Verbindungen steht werden drei konkrete Unterklassen abgeleitet TripBlock ein Abschnitt einer Verbindung Trip eine vollst ndige Verbindung und Trips eine Menge von Verbindungen Alle implementieren die Operationen der Oberklasse und f gen weitere Operationen hinzu Au erdem gibt es Aggregationsbeziehungen Trips aggregiert Trip Trip wiederum TripBlock Abbildung 10 4 Fragw rdige Vererbung bei Gruppe 12 Betrachtet man die Vererbungsbeziehungen kann man nur bei Trip von einer Speziali sierung sprechen Fasst man GenericTrip als Interface auf kann man auch noch begr nden warum TripBlock dieses Interface implementiert da auch Verbindungsab schnitte die Attribute einer Verbindung im Sinne von GenericTrip aufweisen Proble matisch wird es allerdings bei Trips weil dort selbst das Interface nicht passt Was ist denn z B die Startzeit einer Menge von Verbindungen Ein Blick in die Implementie rung verr t dass immer der Wert f r die erste Verbindung in der Verbindungsmenge zur
282. n Daraus folgt dass es auch mit unvollst ndigen und wenig detaillierten Entwurfs beschreibungen zurechtkommen sollte 2 Das Verfahren sollte nur wenige in der Regel gegebene Voraussetzungen f r den erfolgreichen Einsatz haben Ist die Einstiegsh rde zu hoch wird es sonst von den meisten Entwicklern ignoriert oder schnell aufgegeben 3 Das Qualit tsmodell sollte klein und berschaubar sein Bewertungsverfahren mit Metriken werden in der Praxis nur dann wirklich eingesetzt wenn sie wenige rela tiv simple Metriken umfassen Card Glass 1990 4 Das Qualit tsmodell sollte an konkrete Anforderungen anpassbar sein Wenn bestimmte Qualit tsattribute eine gro e eine geringe oder auch gar keine Rolle spielen sollte das Modell so konfiguriert werden k nnen dass sich dies in der Bewertung entsprechend niederschl gt durch Umfang des Modells und Gewich tung innerhalb des Modells 4 1 Einf hrung 5 Zusammen mit dem Verfahren sollten Hilfsmittel zur Verfiigung gestellt werden die es erlauben einen Entwurf mit m glichst geringem Aufwand d h weitgehend automatisiert zu bewerten Eine Pr fung des Entwurfs durch Experten ist zwar blich Haynes 1996 aber teuer Au erdem sind Experten schwer zu bekommen Grotehen Dittrich 1997 1 3 L sungsansatz Der Ablauf des Bewertungsverfahrens f r objektorientierte Entw rfe ist in Abbildung 1 1 dargestellt Die Metamodelle beschreiben jeweils die rechts daneben stehenden
283. n Forschung 4 3 Muster und Rahmenwerke 31 und Praxis erhalten Ein Ergebnis war der Gedanke der Muster patterns der sowohl auf Architekturebene Architekturmuster als auch auf Klassenebene Entwurfsmus ter angewendet werden kann Au erdem kamen wiederverwendbare halbfertige Architekturen in Form von Rahmenwerken frameworks auf Diese Begriffe werden im Folgenden n her betrachtet 4 3 1 Software Architektur A software architecture is the development product that gives the highest return on investment with respect to quality schedule and cost This is because an architecture appears early in a product s lifetime Getting it right sets the stage for everything to come in the system s life development integration testing and modification Getting it wrong means that the fabric of the system is wrong and it cannot be fixed by weaving in a few new threads or pulling out a few existing ones which often causes the entire fabric to unravel Bass et al 1998 S x Die Verwendung des Begriffs Architektur als Metapher f r die Struktur eines Soft ware Systems begann in den fr hen 60er Jahren durch Weinberg Coplien 1999 Zusammen mit dem Begriff wurde auch anderes Gedankengut bernommen z B das Leitbild der guten Architektur von Vitruv mit den Eigenschaften Sch nheit Brauchbarkeit und Dauerhaftigkeit Der IEEE Standard 610 12 1990 definiert die Begriffe Architektur und Architekturent wurf wie folgt Definition 4 3
284. n allgemein g ltiges Qualit tsmodell kaum sinnvoll Stattdessen verwendet man spezifische Qualit tsmodelle die dem Bedarf angepasst sind 1 4 bersicht Die Struktur der Arbeit ist in Abbildung 1 2 dargestellt Die Abbildung zeigt die Kapitel und die wichtigsten Abh ngigkeiten zwischen den Kapiteln dargestellt durch Pfeile mit Informationen aus dem Kapitel die in einem anderen Kapitel ver wendet werden Kapitel 2 beschreibt die wichtigen Basisbegriffe Modell und Metrik Kapitel 3 f hrt in die Objektorientierung und die Standardnotation UML ein Kapitel 4 besch ftigt sich mit dem objektorientierten Entwurf und seinen Problemen Kapitel 5 stellt ODEM vor ein Referenzmodell f r den objektorientierten Entwurf auf der Basis des UML Metamodells Nachdem damit der Messgegenstand definiert ist werden die Grundlagen f r das Messverfahren gelegt Zun chst wird auf das Messziel und bisherige Messverfahren eingegangen Kapitel 6 besch ftigt sich mit Softwarequalit t und Qualit tsmodellen im Allgemeinen w hrend Kapitel 7 die entwurfsspezifischen Aspekte der Software qualit t beleuchtet und bisherige Ans tze zur Entwurfsbewertung vorstellt Auf dieser Grundlage wird das Messverfahren entwickelt Kapitel 8 f hrt QOOD das allgemeine Qualit tsmodell f r den objektorientierten Entwurf ein Der Aufbau sowie die Qualit tsattribute von QOOD unterschieden in Faktoren und Kriterien werden beschrieben Kapitel 9 befasst sich mit der Quant
285. n der vielen M glichkeiten trotzdem aufwendig Syntheseprobleme Syntheseprobleme unterscheiden sich von Interpolationsproblemen dadurch dass das Operatoreninventar nicht abgeschlossen ist d h es kann neben den bekannten Operatoren weitere geben Wenn die bekannten Operatoren f r die L sung nicht aus reichen m ssen zun chst neue Operatoren gefunden oder erfunden synthetisiert werden Synthesebarrieren sind auch deshalb so schwer zu berwinden weil sie oft einen Wechsel der Blickrichtung auf ein Problem erfordern was durch individuelle Einstellungen und Denkgewohnheiten erschwert wird Beispielsweise ist es bei Laby rinthen in Adventure Spielen oft so dass man mit den oben genannten Operationen nicht weiterkommt so lange man nicht eine unerwartete Operation durchf hrt wie z B br chige Wand durchbrechen Dialektische Probleme Bei den dialektischen Problemen schlie lich ist der Zielzustand unklar Meistens k n nen zwar Anforderungen an diesen Zustand formuliert werden doch sind diese oft widerspr chlich Es werden daher mehr oder minder systematisch verschiedene Transformationen ausprobiert bis ein Zustand erreicht wird der den Anforderungen entspricht W hrenddessen entwickelt sich auch eine genauere Vorstellung vom ange strebten Zielzustand weil widerspr chliche Anforderungen gegeneinander abgewo gen werden Ein Beispiel f r ein dialektisches Problem ist der Wunsch Unser Dorf soll sch ner werden
286. n konfigurieren Zu den Bewertungen der Kriterien sind im Werkzeug allgemeine Ratschl ge zur Verbes serung abrufbar f r die Metriken sind Beschreibungen verf gbar 1 Der Begriff Analyse schlie t bei diesem Ansatz den Entwurf ein 2 MAOOAM Tool ist ein Werkzeug f r die objektorientierte Systemanalyse inkl Entwurf MAOOAM Mannheimer objektorientiertes Analysemodell ist ein propriet res Metamodell f r objektorientierte Analyse und Entwurfsmodelle 152 11 Werkzeugunterst tzung Robbins Redmiles 1999 Das UML Werkzeug Argo UML verfiigt tiber eine einge baute Kritikkomponente sog design critics Robbins 1998 Diese pr ft im Hinter grund laufend das UML Modell auf die Einhaltung bestimmter Regeln Bei einem Regelversto wird das entsprechende Modellelement mit einer Markierung versehen ber die Informationen ber den Regelversto abgerufen werden k nnen Es ist auch eine Liste von Regelverst en f r das ganze Modell verf gbar Zu jedem Befund k n nen Vorschl ge zur Verbesserung abgerufen werden Teilweise werden auch automa tische Korrekturen gesteuert durch Wizards angeboten Zus tzlich bietet Argo UML auch Checklisten an die typische Probleme aufdecken sollen Das Besondere dabei ist dass die Fragen der Checkliste personalisiert werden k nnen d h zum einen werden f r den Pr fling irrelevante Fragen weggelassen und zum anderen des sen konkrete Eigenschaften z B Klassennamen oder A
287. n nur anwendbare Fragen d h Fragen deren Bedingung erf llt ist Nicht anwendbare Fragen wirken sich somit nicht auf den Bewertungsvorschlag aus Zur Auswertung wird die Antwort auf jede anwendbare Frage mit dem Gewicht multipliziert und das Resultat f r alle Fragen aufsummiert Dann wird durch Summe 9 5 Gesamtbewertung 131 der Gewichte aller anwendbaren Fragen geteilt Zur Umrechnung auf den Wertebe reich der subjektiven Metriken wird dann mit 9 multipliziert und das Ergebnis wie bei den objektiven Metriken auf eine Nachkommastelle gerundet 9 5 Gesamtbewertung 9 5 1 Gesamtvorschlag Pro Kriterium und Ebene k nnen f r die zugeh rige subjektive Metrik bis zu drei ver schiedene Bewertungsvorschl ge berechnet werden 1 aus den objektiven Metriken vgl Abschnitt 9 2 4 2 aus untergeordneten subjektiven Metriken vgl Abschnitt 9 3 4 und 3 aus dem Fragebogen vgl Abschnitt 9 4 4 Je nach Kriterium und Ebene liegen dann ein bis drei Vorschl ge vor Aus diesen Bewertungsvorschl gen kann ein Gesamtvorschlag berechnet werden indem die Vor schl ge mit Gewichten versehen werden und dann ein gewichteter Durchschnitt gebildet wird auf eine Nachkommastelle gerundet Der Bewerter kann nun auf der Basis der einzelnen Bewertungsvorschl ge und des Gesamtbewertungsvorschlags einen eigenen Wert f r die subjektive Metrik festlegen Dabei wird er seine eigene Einsch tzung mit einbringen weshalb er von dem Vor schlag nach obe
288. n oder unten abweichen kann 9 5 2 Automatisierung Das vorgestellte Bewertungsverfahren ist weitgehend automatisierbar Dazu kann an den folgenden Stellen angesetzt werden 1 Die Erhebung der objektiven Metriken kann der Rechner bernehmen ebenso ihre Auswertung d h die Berechnung der Bewertungsvorschl ge 2 Wenn die vergebenen Werte f r die subjektiven Metriken erfasst werden k nnen die Bewertungsvorschl ge f r die bergeordneten subjektiven Metriken automa tisch berechnet werden 3 Bei den Frageb gen k nnen automatisch die Fragen aussortiert werden deren Bedingungen nicht erf llt sind so dass dem Bewerter nur anwendbare Fragen pr sentiert werden Wenn die Antworten des Bewerters erfasst werden k nnen die Frageb gen anschlie end automatisch ausgewertet werden Einige Fragen lassen sich sogar automatisch beantworten so dass diese vom Bewerter nicht selbst beant wortet werden m ssen 4 Liegen alle Bewertungsvorschl ge vor z B wenn sie automatisch berechnet wur den kann auch der Gesamtbewertungsvorschlag automatisch berechnet werden Wird das gesamte aufgezeigte Automatisierungspotential genutzt kann der Auf wand f r den Bewerter auf ein unbedingt erforderliches Ma reduziert werden Um die Bewertung vollautomatisch durchf hren zu k nnen muss bei den Frageb gen auf alle Fragen verzichtet die nicht automatisch beantwortet werden k nnen Au er 132 9 Quantifizierung des Qualit tsmodells
289. n von Prinzipien ver ffentlicht 84 7 Entwurfsqualitat Hier werden einige Prinzipien fiir den objektorientierten Entwurf von denen viele aus dem strukturierten Entwurf tibernommen wurden kurz vorgestellt Dabei wer den strategische Tabelle 7 2 und taktische Prinzipien Tabelle 7 3 unterschieden Strategische Entwurfsprinzipien sind fundamentaler Art sie geben eine Art Ent wurfstheorie vor Die taktischen Prinzipien sind technischer Art sie schlagen die Anwendung bestimmter Techniken vor Eine ausf hrliche Erl uterung der Prinzipien findet sich bei Rei ing 2002 Prinzip F hre den Entwurf auf die Anforderungen zur ck Beschreibung Jede Entwurfsentscheidung muss auf ihre zugeh rigen Anforderun gen zur ckgef hrt werden k nnen und umgekehrt Diese Eigen schaft wird als Verfolgbarkeit traceability bezeichnet Erfinde nicht das Rad neu Falls immer es m glich ist sollte f r eine vorgesehene Komponente des Entwurfs eine bereits vorhandene Komponente wiederverwen det werden statt eine neue zu schaffen Kenne den Anwendungs bereich Der Entwerfer sollte die Begriffswelt und typische Abl ufe der Anwendung kennen aber auch mit ihrer Arbeitsumgebung vertraut sein Dazu geh rt die technische Umgebung genauso wie die sozi ale Umgebung die aus den Benutzern und den geltenden Gesetzen und Standards besteht Nur dann k nnen die optimale Architektur und geeignete Algorithmen gew hlt werden
290. nahmen entschieden kann er durch eine erneute Entwurfsbewertung nach Durchf hrung der Verbesse rungsma nahme berpr fen ob tats chlich eine Verbesserung eingetreten ist 168 12 Zusammenfassung und Ausblick 12 5 Schlussbemerkung Sollte ich zuf llig irgendetwas mehr oder weniger hierher Geh rendes oder Notwendiges aus gelassen haben so bitte ich um Nachsicht da es niemanden gibt der in allen Dingen frei von Tadel ist und an alles im Voraus denken kann Leonardo Fibonacci Liber Abaci Das Gebiet der Qualit t ist ein weites Feld in dem umfassende und gleichzeitig objek tiv richtige d h wissenschaftlich haltbare Erkenntnisse nur schwer zu erlangen sind Ursache daf r ist zum einen die Definitionsproblematik Die Frage Was ist Quali t t wird von jedem Entwerfer unterschiedlich beantwortet Weil es keinen Standard gibt muss eine eigene Definition eingef hrt werden Zum anderen ist es auch n tig die Brauchbarkeit dieser Definition zu zeigen wozu umfassende empirische Studien erforderlich sind Diese Arbeit hat vorhandene Ansichten zur Entwurfsqualit t zusammengetragen und einen Vorschlag gemacht wie Entwurfsqualit t definiert und gemessen werden kann Auch wenn nicht alle Fragen zur Brauchbarkeit des Ansatzes gekl rt werden konn ten halte ich meinen Beitrag f r geeignet als Diskussionsgrundlage f r die weitere Erforschung des objektorientierten Entwurfs und seiner Qualit t zu dienen 169 Literatu
291. nd das fer tige Programm vorf hren k nnen 220 C Dokumente zum Softwarepraktikum Bitte beachten Sie dass diese Abgabe vollst ndig und rechtzeitig erfolgen muss Dies ist eine wichtige Bedingung f r den Erhalt des Scheins C 2 Anforderungen C 2 1 bersicht Das System ein Fahrplanauskunftssystem sollte einfach zu bedienen sein und es einem potentiellen Fahrgast erm glichen eine Verbindung zwischen zwei Haltestel len zu finden Der Fahrgast gibt hierzu den gew nschten Startzeitpunkt die Start und Zielhaltestelle und seinen Optimierungswunsch ein Daraufhin errechnet das System eine g nstige Verbindung und gibt diese inklusive der Namen Liniennummer der zu benutzenden Linien und die Umsteigehaltestellen aus Das System entnimmt die Fahrpl ne der Linien einer Fahrplandatei Diese Datei kann nur ver ndert werden wenn das Fahrplaninformationssystem nicht von Fahrg sten benutzt wird Dies geschieht durch einen Servicetechniker der hierzu einen nur ihm zug nglichen Programmteil verwendet Hiermit lassen sich Fahrplandaten ver n dern l schen oder neu eingeben Die Implementierung soll in Java durchgef hrt werden Das Programm soll unter Unix Solaris Linux laufen und mit einer graphischen Benutzungsschnittstelle aus gestattet sein Java Swing Das System soll nur f r einen Benutzer ausgelegt sein C 2 2 Systemumgebung Die Systemumgebung des Verkehrsbetriebs besteht aus einer Unix Workstation die nur einen einz
292. nd h heren Testaufwand hin so dass es keine klare Aussage gibt welche Werte besser sind NOC c de CUI extends d c Coupling between Object Classes CBO CBO ist die Anzahl der Klassen an die eine Klasse gekoppelt ist Eine Klasse A ist an eine Klasse B gekoppelt wenn eine Methode von A eine Methode oder ein Attribut von B verwendet Je geringer CBO desto besser Diese Metrik ben tigt genaue Information ber die Methoden es wird also ein sehr detaillierter Entwurf oder der Code der Klasse f r die Messung voraus gesetzt Derart detaillierte Information ist in ODEM aber nicht vorhanden weshalb diese Metrik nicht formalisiert werden kann Response for a Class RFC Die Gr e der Response Menge einer Klasse d h die Anzahl der Methoden einer Klasse plus die Anzahl der Methoden anderer Klassen die von den Methoden der Klasse benutzt werden jede Methode z hlt nur einmal Je geringer RFC desto besser Auch diese Metrik ben tigt genaue Informationen ber die Methoden weshalb das gleiche Problem bei der Formalisierung auftritt wie bei 58 5 Ein Referenzmodell f r den objektorientierten Entwurf CBO Au erdem wird wie bei WMC keine Aussage dar ber gemacht welche Methoden eigentlich mitz hlen Lack of Cohesion in Methods LCOM Diese Metrik soll den Zusammenhalt der Methoden einer Klasse erfassen indem deren hnlichkeit betrachtet wird Die hn lichkeit zweier Methoden ist hier die Anzahl der Attribute der K
293. ndeten oder f r die Verantwortlichkeiten der Klasse nicht relevanten 4 Kommentar Unn tige Attribute sind zus tzlicher Ballast in Implementierung und Wartung Zum einen braucht die 4 Implementierung l nger weil mehr implementiert werden muss Zum anderen verz gern sich Wartungsarbeiten weil auch 4 die unn tigen Attibute erst verstanden werden m ssen bevor nderungen durchgef hrt werden k nnen Empfehlungen Alle unn tigen Attribute entfernen Falls sie anderweitig ben tigt werden zu der Klasse verschieben wo 4 das Attribut hingeh rt Falls es eine derartige Klasse noch nicht gibt diese anlegen 4 Falls das Attribut geerbt wurde liegt offensichtlich keine echte Spezialisierung vor Dann den Entwurf refaktorisieren Eine d neue Oberklasse einf hren die nur die ben tigten Attribute vererbt und diese zur neuen Oberklasse machen Die d ehemalige Oberklasse wird ebenfalls zur Unterklasse der neuen Oberklasse also dort bereits in der neuen Oberklasse definierte Eigenschaften entfernen 4 Enth lt die Klasse nur die n tigen Operationen z B keine nicht mehr verwendeten oder f r die Verantwortlichkeiten der Klasse nicht relevanten H Kommentar Unn tige Operationen sind zus tzlicher Ballast in Implementierung und Wartung Zum einen braucht die A Implementierung l nger weil mehr implementiert werden muss Zum anderen verz gern sich Wartungsarbeiten weil auch A die unn tigen Operationen erst verstanden werden m ssen bev
294. ne Aussage dar ber ob eine Implementierung d h eine Methode existiert oder nicht Methoden werden aber in ODEM gar nicht betrachtet W rde die Abstraktheit ber cksichtigt m sste die Redefinition von abstrakten Operatio nen durch nicht abstrakte Operationen speziell modelliert werden e Es wird nicht zwischen Konstanten und normalen Attributen unterschieden da der Unterschied relativ unbedeutend ist Konstanten werden in UML durch Attri bute mit dem Constraint frozen dargestellt im UML Metamodell hat die Klasse Attribute ein Attribut changeability das bei Konstanten den Wert frozen hat e Die Multiplizit t von Attributen und Assoziationen wird nicht ber cksichtigt weil sie relativ unwichtig ist e Datentypen Instanzen von DataType im UML Metamodell stehen f r die vordefi nierten primitiven Datentypen der Implementierungssprache Daher werden sie als Implementierungsdetail betrachtet und weggelassen Sie tauchen nur als Typ eines Attributs oder Parameters auf e Assoziationsklassen eine Mischung aus Assoziation und Klasse zur Modellierung von Attributen von Beziehungen werden weggelassen Ebenso entfallen Subsys teme eine Mischung aus Paket und Klasse 5 2 Umfang 47 5 2 2 Erweiterungen Neben diesen Einschr nkungen gibt es auch noch Erweiterungen um zus tzliche Modellelemente Diese bestehen aus Mengen von Entit ten und aus Relationen Die neu eingef hrten formalen Bezeichner sind in Tabelle 5 1 zusamm
295. ne wesentliche Rolle das Layout ist fast so wichtig wie der Inhalt 23 Kapitel 4 Objektorientierter Entwurf In design object orientation is both a boon and a bane Object orientation is a boon because it allows a designer to hide behind the scenic walls of encapsulation such software eyesores as convoluted data structures complex combinatorical logic elaborate relationships between pro cedures and data sophisticated algorithms and ugly device drivers Object orientation is also a bane because the structures that it employs such as encapsulation and inheritance may themselves become complex In object orientation it s all too easy to cre ate a Gordian hammock of inextricable interconnections that either is unbuildable or will result in a system that runs like a horse in a sack race Page Jones 1995 S 61 Dieses Kapitel besch ftigt sich mit verschiedenen Aspekten des objektorientierten Entwurfs object oriented design OOD Es wird definiert was Entwurf ist und wel che Arten von Entwurf es gibt F r den Entwurf wichtige Techniken wie Muster und Rahmenwerke werden vorgestellt und es wird kurz auf die wesentlichen Eigenschaf ten der Entwurfsdokumentation eingegangen Abschlie end werden verschiedene Probleme diskutiert die das Entwerfen schwer machen 4 1 Was ist Entwurf 4 1 1 Definition und Abgrenzung Der Begriff Entwurf oder Design hat zwei verschiedene Bedeutungen Zum einen bezeichnet er die u ere
296. nent Typical contents include sys tem or component architecture control logic data structures input output formats interface descriptions and algorithms Abbildung 4 1 zeigt die Einbettung des Entwurfs in die Software Entwicklung Der Entwurf transformiert die Anforderungsspezifikation in eine Entwurfsbeschreibung die in der Implementierungsphase in Code f r ein ausf hrbares Programm umgesetzt wird der danach getestet und gewartet wird e Architektur Feedback 4 entwurf WS x Analyse und Komponenten Spezifikation x Arner entwurf Z Be ag Pt ag ag Entwurf GE Anforderungs wien spezifikation Implementierung gt Entwurfs Test und Wartung beschreibung Abbildung 4 1 Einbettung des Entwurfs in die Software Entwicklung Die Entwurfsbeschreibung ist ein wichtiges Dokument f r alle anderen nachfolgen den Phasen In der Implementierungsphase dient der Entwurf als Vorgabe in der Wartung wird er f r das Verstehen der Implementierung ben tigt Innerhalb des Ent wurfs k nnen die Aktivit ten Architekturentwurf und Komponentenentwurf unter schieden werden vgl dazu Abschnitt 4 2 2 Fehlt der Entwurf nimmt der Aufwand in der Implementierungs und Testphase zu weil bei der Implementierung implizit doch ein ad hoc Entwurf stattfindet dessen Ergebnis dauernd berarbeitet werden muss Die Wartung f hrt zu wilden Wuche 4 1 Was ist Entwurf 25
297. nftigere 7 2 Perspektiven der Entwurfsqualitat 79 7 2 2 Interessengruppe What drives the end user and as a result determines his or her view of the software develop ment differs substantially from the view of the system or software organizations Evans Marciniak 1987 S 45 Die Qualit tsdefinition h ngt stark von der Interessengruppe ab Boehm In 1996 Bei der Betrachtung der G te eines Entwurfs gibt es verschiedene Interessengruppen f r die jeweils unterschiedliche Aspekte des Entwurfs relevant sind Die folgenden Gruppen lassen sich identifizieren e Kunde Der Kunde gibt das Produkt in Auftrag und bezahlt es Er hat ein Interesse daran f r m glichst wenig Geld ein Produkt zu erhalten das seinen Anforderun gen entspricht Das bedeutet f r den Entwurf dass er vollst ndig und korrekt im Sinne der Spezifikation sein soll Au erdem soll er auch eine gewisse Zukunftssi cherheit aufweisen weshalb Wartbarkeit vor allem f r korrektive und adaptive Wartung wichtig ist e Anwender Der Anwender verwendet das Produkt F r ihn ist ebenfalls Vollst n digkeit und Korrektheit des Systems relevant Benutzerfreundlichkeit ist f r ihn besonders wichtig e Entwickler Die Entwickler sind f r die Herstellung des Produkts zust ndig Hier gibt es verschiedene Untergruppen die unterschiedliche Anforderungen an den Entwurf haben e Entwerfer Der Entwerfer muss sich um alle Eigenschaften des Entwurfs k m mern da er d
298. ng Testbarkeit wird h ufig als zur Wartung geh rig angesehen z B Boehm et al 1978 hier wird sie aber als eigenst ndiger Fak tor betrachtet Wie sich zeigen wird sind die Kriterien der Testbarkeit eine Teilmenge 106 8 Das allgemeine Qualit tsmodell der Kriterien der Wartbarkeit weshalb bei der Bewertung der Wartbarkeit nicht wirk lich etwas fehlt Kriterien bisheriger Qualit tsmodelle Um die Auswahl der Kriterien f r die Wartbarkeit zu erleichtern werden hier zun chst die Kriterien der Qualit tsmodelle aus Kapitel 6 und Abschnitt 7 4 zusam mengetragen welche die Wartbarkeit betreffen siehe Tabelle 8 2 Zusammen mit jedem Kriterium f r das unter Umst nden in der Literatur mehrere Bezeichnungen verwendet werden ist die Quelle des Modells angegeben in dem es vorkommt Kriterium Nennungen Allgemeinheit McCall et al 1977 Anderbarkeit Erweiterbarkeit McCall et al 1977 Boehm et al 1978 ISO IEC 9126 1991 IEEE 1061 1992 Einfachheit McCall et al 1977 Coad Yourdon 1991 Erni 1996 Flexibilitat McCall et al 1977 Erni 1996 Knappheit Gr e McCall et al 1977 Coad Yourdon 1991 Konsistenz Boehm et al 1978 Kopplung Entkopplung Booch 1994 Coad Yourdon 1991 Erni 1996 Lesbarkeit Boehm et al 1978 Modularitat McCall et al 1977 Erni 1996 Selbsterklarung McCall et al 1977 Boehm et al 1978 Stabilitat ISO IEC 9126 1991 Strukturiertheit Boehm et al 1978 Verst
299. nn und in dem Admin Modus in dem neue Linien und Abfahrtszeiten eingegeben werden k nnen C 2 Anforderungen 221 C 2 4 Fahrgast Modus Der Benutzer muss unter Eingabe der Start und Zielhaltestelle sowie des fr hest m glichen Startzeitpunkts eine m gliche Verbindung erfragen k nnen Der Benutzer gibt zus tzlich an unter welchem Aspekt die Verbindung optimiert werden soll Das System berechnet dann die beste Verbindung Es gibt folgende Optimierungsziele e fr hestm gliche Ankunftszeit d h die Verbindung die zum fr hestm glichen Zeit punkt an der Zielhaltestelle ankommt und fr hestens zum gegebenen Startzeit punkt startet e k rzeste Fahrtzeit d h die Verbindung die die k rzeste Zeitspanne zwischen Ein steigen an der Start und Aussteigen an der Zielhaltestelle erm glicht Der Start zeitpunkt sollte dabei nicht mehr als eine Stunde vom eingegebenen fr hestm gli chen Startzeitpunkt entfernt sein Es wird also die Verbindung mit der k rzesten Fahrtzeit gew hlt deren Startzeitpunkt nicht l nger als eine Stunde vom fr hest m glichen Startzeitpunkt entfernt liegt Gibt es in dieser Zeit keine Verbindung so wird die Verbindung mit der fr hestm glichen Ankunftszeit ausgegeben Sol e wenigste Umsteigehaltestellen d h die Verbindung die am wenigsten Umsteige punkte enth lt Gibt es mehrere M glichkeiten so wird die Verbindung angezeigt die die fr hestm gliche Ankunftszeit verspricht Es werden all
300. nst bei diesem Auftrag keinen Gewinn machen kann Ihr Chef m chte daher eine Abrechnung der Stunden die Ihre Entwickler gruppe f r dieses Projekt aufgebracht hat Der Verkehrsbetrieb Ihr Kunde verwendet f r all seine Projekte die Programmier sprache Java Damit soll unter anderem sichergestellt werden dass das Programm auf verschiedenen Rechnern und unter verschiedenen Betriebssystemen gleicherma en zum Einsatz kommen kann Ihr Chef konnte f r Sie diesen Auftrag nur abschlie en weil er Ihre Kompetenz in Java besonders herausgestellt hat Ihre Aufgabe ist es dem Kunden ein qualitativ hochwertiges genau auf seine Bed rf nisse zugeschnittenes Programm zu erstellen Auf dar ber hinausgehende Leistun gen die Ihnen Ihr Kunde nicht honoriert m ssen Sie dabei aber verzichten C 1 4 Aufgabenstellung Es ist ein kleines nur f r einen Benutzer ausgelegtes Fahrplaninformationssystem zu entwickeln Das System sollte einfach zu bedienen sein und es einem potentiellen Fahrgast erm glichen eine Verkehrsverbindung zwischen zwei Haltestellen zu fin den Der Fahrgast gibt hierzu den gew nschten Startzeitpunkt und die Start und Zielhaltestelle ein Daraufhin errechnet das System eine g nstige Verbindung und gibt diese inklusive Liniennummer und Umsteigehaltestellen aus Das System optimiert die Verbindung nach Wahl des Fahrgasts Es bietet die folgen den Optimierungsziele an 218 C Dokumente zum Softwarepraktikum e fr hestm gl
301. nth lt f r die Schwellenwerte aus der Erfahrung der Autoren angegeben sind 75 Qualitatssicherung beim Entwurf Quality must be built into designs and cannot be inspected in or tested in Nevertheless any prudent development process verifies quality through inspection and testing The very fact that designs face inspections motivates even the most conscientious designers to greater care deeper simplicities and more precision in their work Mills 1980 S 418 Bisher wurden berlegungen zur Definition der Entwurfsqualit t angestellt In die sem Abschnitt wird gezeigt mit welchen Ma nahmen die Entwurfsqualit t berpr ft und verbessert werden kann 7 5 1 Organisatorische Ma nahmen Entwicklungsprozess Der Entwurf muss geeignet eingebettet sein und den erfor derlichen Stellenwert haben selbst wenn evolution r entwickelt wird Standards und Richtlinien Es werden Vorgaben sowohl f r den Entwurf selbst z B Namenskonventionen Qualit tskriterien als auch f r die Entwurfsdokumenta tion z B Aufbau Umfang und Aktualit t gemacht Ausbildung der Entwerfer Die Entwerfer erarbeiten sich durch Schulung und Pro jektarbeit das notwendige Wissen und die n tige Erfahrung f r die Erstellung guter Entw rfe Dabei ist der Einsatz von Experten als Berater oder Mentoren in der Ent wurfsphase sinnvoll Alternativ kann auch ein Architekturteam gebildet werden dem ein erfahrener Experte als Chefarchitekt vorsteht Eta
302. ntierten Entwurfsmetriken untersucht welche Axiome von Weyuker gelten Dabei stellten sie fest dass die Axi ome W7 und W9 f r keine der Metriken gelten Daraus folgern sie dass diese Axiome vermutlich f r objektorientierte Metriken allgemein nicht anwendbar sind F r Axiom W7 ist der Grund offensichtlich bertr gt man die Axiome von Programmen auf Entw rfe in UML gibt es keine sinnvolle Interpretation f r eine Permutation von Entwurfselementen da hier im Gegensatz zu Programmen keine Reihenfolge der Ele mente vorhanden ist Bei Axiom W9 ist es wohl so dass bei der Kombination objekt orientierter Entw rfe keine Effekte auftreten die zu einer h heren Komplexit t als der Summe der Teile f hren Gursaran und Roy 2002 kommen f r W9 zu dem Ergebnis dass das Axiom zumindest f r Vererbungsmetriken grunds tzlich nicht anwendbar ist Daher werden die Axiome W7 und W9 nicht weiter betrachtet Untersuchung der Metriken Die Metriken f r Knappheit Strukturiertheit und Entkopplung sind Komplexit tsme triken Daher wird untersucht welche der Axiome f r die Metriken gelten Das wird hier am Beispiel der Metrik NAC Number of Attributes of a Class demonstriert Axiom W1 Das Axiom gilt Man w hle eine Klasse P mit einem Attribut und eine Klasse Q mit zwei Attributen Dann gilt NAC P NAC Q A 9 Theoretische Validierung 201 Axiom W2 Das Axiom gilt sofern man von der vern nftigen Annahme ausgeht dass Klassen endlich viel
303. number of operations of a class Klasse Knappheit NCP number of classes in a package Paket Knappheit NIP number of interfaces in a package Paket Knappheit NPP number of packages in a package Paket Knappheit Strukturiertheit NAS number of attributes in the system System Knappheit NCS number of classes in the system System Knappheit NIS number of interfaces in the system System Knappheit NOS number of operations in the system System Knappheit NPS number of packages in the system System Knappheit DITC depth of inheritance tree of a class Klasse Strukturiertheit NAEC number of local afferent extends relationships of a class Klasse Strukturiertheit Entkopplung NEEC number of local efferent extends relationships of a class Klasse Strukturiertheit Entkopplung DNHP depth in nesting hierarchy of a package Paket Strukturiertheit DITS depth of inheritance tree ofthe system System Strukturiertheit DNHS depth of nesting hierarchy of the system System Strukturiertheit MNCS maximum number of child classes in the system System Strukturiertheit MNPS maximum number of subpackages in the system System Strukturiertheit RTTR ratio of traceable to total requirements System Verfolgbarkeit Tabelle 9 1 Ubersicht der objektiven Metriken 122 9 Quantifizierung des Qualit tsmodells 9 2 2 Beschreibung Auf der Basis der obigen Anforderungen wurden objektive
304. o tun Sie das bitte und legen diesen ver nderten Plan wieder Ihrem Betreuer vor Es gilt immer der letzte von Ihrem Betreuer genehmigte Plan Achtung Sehr kurzfristige nderungen am Projektplan sind in der Regel nicht m g lich nur langfristige Anpassungen werden akzeptiert also mindestens eine Woche vor dem n chsten Meilensteintermin Das Vers umen der im Projektplan genannten Termine f hrt beim zweiten Mal zum Scheinverlust Planen Sie alle Abgaben Kundenbefragungen und Besprechungstermine mit Ihrem Betreuer und sprechen Sie diese vorher mit ihm ab Sie sollten nur in Ausnahmef llen ohne vorherige Absprache bei Ihrem Betreuer aufkreuzen Scheuen Sie sich jedoch nicht Probleme rechtzeitig anzusprechen Das gilt insbesondere f r Probleme bei der Zusammenarbeit der Gruppen und dem Aussteigen einzelner Gruppenmitglieder F hren Sie w hrend des Software Praktikums einen Stundenzettel in dem Sie alle Arbeitsstunden verzeichnen Eine Kopie der Stundenzettel ist am Ende dem Betreuer abzugeben Der Inhalt der Stundenzettel hat keinen Einfluss auf die Bewertung C 1 2 Projektdurchf hrung Ihr Projekt soll mindestens die folgenden Meilensteine enthalten Analyse Projektplanung Spezifikation inklusive Begriffslexikon Review und berarbeitung der Spezifikation Entwurf Implementierung N OA OI VG QU N e Benutzerhandbuch 8 Test Zu jedem Meilenstein m ssen Sie in Ihrem Projektplan mindestens ein defini
305. olgbarkeit von Anforderungen vor handen Allenfalls durch die Benennung der Klassen gibt es implizite Hinweise auf die Anforderungen Weil die Verfolgbarkeit damit einheitlich mit 0 sehr schlecht bewertet werden muss wird sie bei der weiteren Bewertung ausgeblendet 138 10 Ein spezifisches Qualit tsmodell Gewichte Die Gewichte f r die Kriterien wurden gem den in Abschnitt 9 6 2 aufgestellten Faustregeln gew hlt und dann durch die Verwendung in ausgew hlten Szenarien fein abgestimmt Die Gewichtung ist in Tabelle 10 2 dargestellt Struktu Entkopp Zusam Einheit Dokumen Verfolg Kriterium Knappheit riertheit lung menhalt lichkeit tierung barkeit Gewicht MAsccx 4 MAsstx 2 MAspcx 4 MAscox 4 MAscsx 1 MAspox 1 MAstrx 0 Tabelle 10 2 Gewichtung der Kriterien Da es nur einen Faktor gibt kann seine Bewertung direkt als Qualit tskennzahl inter pretiert werden weshalb der letzte Aggregationsschritt entfallen kann Daher werden keine Gewichte f r die Faktoren ben tigt Die Gewichte f r die Berechnung eines Gesamtvorschlags aus den Bewertungsvor schl gen f r subjektive Metriken auf der Basis von objektiven Metriken subjektiven Metriken und Frageb gen wurden alle gleich 1 gew hlt 10 1 3 Metriken Messgegenstand Da die Entw rfe von unterschiedlichen Gruppen kamen unterscheiden sie sich in Detaillierung und Vollst ndigkeit Das gilt insbesondere f r die Entw rfe die vor der
306. olgenden nur Produktmetriken betrachtet 10 2 Modelle und Metriken Eine Produktmetrik ist ein spezielles Modell fiir Software Das Abbild ist meistens ein einzelner Wert in der Regel eine Zahl Es findet also eine sehr starke Verkiirzung statt Durch die Reduktion auf einen Wert d h Abstraktion sind Eigenschaften einer Soft ware leichter zu erkennen Die Pragmatik einer Metrik ist unterschiedlich Haufig will man durch Erheben einer Metrik bestimmte Eigenschaften feststellen Misst man mehrfach tiber die Zeit kann man auch Trends erkennen Beispielsweise ist es sinn voll w hrend der Software Entwicklung regelm ig den Umfang des entstehenden Produkts zu messen um Verz gerungen gegen ber dem Plan erkennen zu k nnen Eine Metrik ist formal gesehen eine Abbildung Homomorphismus eines empiri schen Relationensystems auf ein formales Relationensystem in der Regel ein numeri sches System Kriz 1988 verdeutlicht den Zweck der Metrik Durch die Abstraktion der Metrik kann man zu Erkenntnissen gelangen die wegen der Beschr nktheit des menschlichen Denkverm gens Verst ndnisbarriere am Original nur schwer oder gar nicht zu finden sind siehe Abbildung 2 2 Empirisches Messung Formales Relationen gt Relationen system system Verst ndnis Statistik barriere Mathematik Ergebnis Interpretation empirisch relevant Ergebnis numerisch A Abbildung 2 2 Mes
307. omatisch beantwortet werden kann d h ob unter Verwendung der Elemente von ODEM und der objektiven Metriken ein Pr dikat formuliert werden kann das der Fragestellung entspricht Wird eine Frage negativ beantwortet sollte vom Bewerter zus tzlich notiert werden was der Grund f r die negative Antwort war Die so entstehende M ngelliste ist f r eine anschlie ende berarbeitung des Entwurfs aufgrund der Bewertung sehr n tz lich M gliche Erweiterungen Manche Fragen bed rfen eigentlich eines ausf hrlichen Kommentars insbesondere f r Entwurfsanf nger Diese Kommentare geben Erl uterungen zu den Fragen und deuten auf m gliche Sonderf lle hin Aus Platzgr nden ist es nicht sinnvoll diese Kommentare auf dem Fragebogen abzudrucken Allerdings kann ein zus tzliches Dokument angeboten werden das diese Kommentare enth lt Bei einer Bewertung die der Schwachstellenanalyse dient ist es au erdem hilfreich wenn die Fragen die Probleme aufdecken sollen mit Empfehlungen versehen sind wie die Probleme behoben werden k nnen Da es meistens mehrere M glichkeiten gibt ist es ebenfalls nicht sinnvoll diese Empfehlungen auf dem Fragebogen abzu drucken Stattdessen k nnen sie in das Kommentardokument aufgenommen werden Sofern der Fragebogen in Form eines Hypertext Dokuments vorliegt k nnen Kom mentare und Empfehlungen zur Problembehebung durch Hyperlinks mit den einzel nen Fragen verkn pft werden siehe auch Abschnitt 11 2 2 Re
308. on Anweisungen weshalb dieses Axiom eher frag w rdig ist q P Q Q n P am P m Q m permutiert die Anweisungen von P Axiom W8 Werden nur Bezeichner umbenannt darf sich die Komplexit t nicht ndern Da hier nur strukturelle Komplexit t nicht psychologische Komplexit t betrachtet wird gibt diese Forderung Sinn V P Q Q p P m P m Q p benennt Bezeichner in P um Axiom W9 Es kann F lle geben bei denen die Komplexit t einer Kombination zweier Programme echt gr er ist als die Summe der Komplexit ten der beiden Pro gramme durch zus tzliche Interaktion der Teile Hier wird verlangt dass es mindes tens einen solchen Fall geben muss 3 P Q m P m Q lt m P Q Diskussion Diese Axiome bedeuten zum Teil sehr starke Einschr nkungen Shepperd Ince 1993 Die von Weyuker betrachteten Beispiele wie Lines of Code oder McCabes zyklomati sche Komplexit t erf llen h chstens sieben der neun Axiome scheinen aber trotzdem n tzliche Komplexit tsmetriken zu sein Daher scheint es fragw rdig ob eine Kom plexit tsmetrik wirklich alle neun Axiome erf llen muss Andererseits sind die Axi ome von Weyuker trotz ihrer Restriktivit t nur notwendige Bedingungen f r Komple xit tsmetriken keine hinreichenden Beispielsweise geben Cherniavsky und Smith 1991 eine Metrik an f r die alle Axiome gelten die aber keine sinnvolle Komplexi t tsmetrik ist Chidamber und Kemerer 1994 haben f r ihre objektorie
309. onal bei der Implementierung des Ent wurfs Aber auch die Betriebskosten f r das System sind zu ber cksichtigen z B die Kosten f r Anschaffung Betrieb und Wartung neuer Hardware Software Lizenzen Software Updates und Patent Lizenzen oder Folgekosten bei Systemausf llen Zur Kostend mpfung wird oft Wiederverwendung empfohlen Allerdings muss der Entwerfer entscheiden k nnen wann es sich lohnt eine bestimmte Komponente wie derzuverwenden Das ist vor allem dann fraglich wenn der brige Entwurf an die 4 5 Probleme des Entwurfs 37 Komponente angepasst werden muss oder die Komponente an den Entwurf sofern das berhaupt geht was man meist erst wei wenn man es versucht hat Entwerfen ist eine T tigkeit die am effektivsten von einer kleinen Gruppe durchge f hrt wird Auf der anderen Seite muss der Projektleiter aus Effizienzgr nden alle Mitarbeiter im Team besch ftigen Das f hrt oft dazu dass statt eines richtigen Ent wurfs ad hoc eine Aufteilung in Teilsysteme vorgenommen wird die dann von klei neren Gruppen implementiert werden DeMarco 1998 Kap 19 Der Entwurf ent steht so mehr oder weniger implizit was auch dazu f hrt dass die Entwurfsstruktur und die Organisationsstruktur sich sehr hnlich sind dieses Ph nomen ist bekannt als Conway s Law Conway 1968 Durch ein solches Vorgehen wird aber die Chance verschenkt einen guten Entwurf insbesondere mit minimalen Schnittstellen Parnas 1972a zu erst
310. or nderungen durchgef hrt werden k nnen 4 Empfehlungen lle unn tigen Operationen entfernen Falls sie anderweitig ben tigt werden zu der Klasse verschieben 4 wo die Operation hingeh rt Falls es eine derartige Klasse noch nicht gibt diese anlegen 4 Falls die Operation geerbt wurde liegt offensichtlich keine echte Spezialisierung vor Dann den Entwurf refaktorisieren Eine neue Oberklasse einf hren die nur die ben tigten Operationen vererbt und diese zur neuen Oberklasse machen Die alte 3 Oberklasse wird ebenfalls zur Unterklasse der neuen Oberklasse also dort bereits in der neuen Oberklasse definierte 4 Eigenschaften entfernen Hinweise zur Bewertung Eine Eigenschaft sollte schlechter bewertet werden wenn die Sichtbarkeit zu wenig eingeschr nkt ist insb bei Attributen weil dadurch ein h heres Export Kopplungspotential entsteht Klasseneigenschaften sollten schlechter bewertet werden als Instanzeigenschaften weil sie als globale Variable Funktionen verwendet werden k nnen und damit zu h herer Export Kopplung f hren Eine Operation ist gewichtiger als ein Attribut weil die Implementierung und Wartung aufwendiger ist Get Set Operationen sollten weniger schlecht bewertet werden als normale Methoden weil ihre Implementierung und Wartung in der Regel einfacher ist Rei der ewi i Abbildung 11 5 Hilfeseite zur Bewertung der Knappheit gekiirzt Einige der Fragen in den Frageb gen lassen sich automatisch beantw
311. oren use 116 9 Quantifizierung des Qualit tsmodells essesssssssssnssssnssnssnsnnsnssnsnnsnnsnnsansennnnen 117 9 1 Ne EE 117 92 E EE 120 9 3 Subjektive Metriken u este 125 94 Te ernennen 127 9 8 NGesamibewerline an eis 131 9 6 Ableitung spezifischer Modelle esse 132 10 Ein spezifisches Qualit tsmodell zeussessssnssssnssnssesnssnssnsnnsnssnsnnsnnsnsnnssnsnnsansnsnnnn 135 10 1 Ableitung des Dushasmedels una ae 135 102 Anwendung des Qualitatsmodells arena ea u 140 10 3 Besonderheiten bei Meter eege ea ana u 148 RE 151 11 1 Werkzeuge aus anderen EE 151 11 2 Selbst realisierte Werkzeuse ausser 154 11 3 Ausblick Ein ideales Werkzeus u u u un0e Re 159 12 Zusammenfassung und Ausblick uussssssssssnssnssssnssnssssnssnssnsnnsnssnsnnsnnsnsnnssnsnssunsnnnnnen 161 12 1 Zusammenlassung ala 161 12 2 Bewertung des Ansatzes in weise re vate 162 12 3 Vergleich mit anderen Arbeiter ann sa dantsaiwisunndaieds 164 leegen ege Eege ee eegen 166 12 5 Schlussbemerkung sus sicnisessiadaieaniocssucsesdevesneaedvessacteierssetGacsbeasengsaaehdsvsansteviueaasisacien 168 Literatur engen dee 169 ker 187 A Metriken f r QOOD wecvvcssccsscssisiccsicasccevass eege EVERE NEEN 189 Ad GINA EE 189 dE 192 A Dr EHEKOPPlUNne sa een ordnen 193 e E Een E EE 196 AD Einheitlichkeil esse iRsechlenllsal 197 A 6 Dokumentierung au heul 198 Pa Mettolebarkei eer ee 198 end E 198 E Wa EE ENEE 199 E Fragebogen f r QOOD sissies eech 203 B1
312. orenz und Kidd 1994 C Smalltalk NAC 3 Lorenz und Kidd 1994 C Smalitalk NOC 30 Morschel 1994 Smalltalk 50 Johnson und Foote 1988 C NOC 20 40 f r GUI Klassen Lorenz und Kidd 1994 C Smalltalk NOC 4 Lorenz und Kidd 1994 C Smalltalk DITC 5bis 6 Rumbaugh et al 1993 6 Lorenz und Kidd 1994 C Smalltalk NEEC 1 Lorenz und Kidd 1994 C Smalltalk Tabelle 9 3 Schwellenwerte aus der Literatur Toleranzen Bei einigen Metriken ist klar dass die Toleranz 0 sein sollte z B bei der Anzahl der lokalen Vererbungsbeziehungen NEEC die zur Vermeidung von Mehr fachvererbung den Schwellenwert 1 mit Toleranz 0 erh lt Ansonsten kann mit einer Default Toleranz von 0 oder aber von einem Prozentsatz des Schwellenwerts z B 20 gearbeitet werden Gewichte Sofern nicht klar ist dass bestimmte Metriken eine deutlich h here Aussa gekraft besitzen als andere kann mit einem Default Gewicht von 1 gearbeitet werden Ansonsten k nnen z B analog zu den Frageb gen drei Wichtigkeitsklassen mit ent sprechenden Gewichten verwendet werden Frageb gen Bei den Frageb gen ist zur Gewichtung nur festzulegen welche Gewichte f r die Kategorien weniger wichtig wichtig und sehr wichtig vergeben werden M gliche Default Werte f r diese Gewichte sind 1 f r weniger wichtig 2 f r wichtig und 3 f r sehr wichtig Gesamtbewertung Bei der Gewichtung der Bewertungsvorschl ge f r den Gesamtvorschlag kann m
313. orten z B in Abbildung 11 4 die Frage ob es Assoziationen der Klasse gibt die in keiner Richtung navigierbar ist Der Reportgenerator kann so erweitert werden dass er solche Fragen beantwortet die Antwort in den Bogen ausgibt und ggf die belt ter hinter der 11 3 Ausblick Ein ideales Werkzeug 159 Frage auflistet Dazu mtissen nur entsprechende SQL Anfragen in der Datenbank hinterlegt werden die der Evaluator des Reportgenerators nutzen kann 11 3 Ausblick Ein ideales Werkzeug Betrachtet man die in diesem Kapitel vorgestellten Werkzeuge und ihre Konzepte las sen sich m gliche Anforderungen an ein ideales Werkzeug zur Entwurfsbewertung Die folgende Funktionalit t scheint mir sinnvoll zu sein Die Bewertungsfunktion ist integriert in ein UML Werkzeug Es k nnen Metriken erhoben werden Dabei kann ausgew hlt werden welche Metriken f r welche Teile des Entwurfs Filterung erhoben werden sollen Den Metriken k nnen Schwellenwerte zugeordnet werden obere oder untere Schwellenwerte die absolut oder statistisch z B 80 Quantil festgelegt werden Dabei k nnen auch mehrere Schwellenwerte angegeben werden so dass mehr als zwei quivalenzklassen unterschieden werden k nnen Anhand der Messwerte und der Schwellenwerte kann eine Ausrei eranalyse durchgef hrt werden Es k nnen Trendanalysen durchgef hrt werden d h Messwerte werden ber die Zeit verglichen dazu werden die Messwerte nach jeder Bewertung
314. peziellen Qualit tsmodells eine einzige Qualit tskennzahl zu berechnen anhand der eine Rangfolge der Alternativen bestimmt werden kann 10 1 Ableitung des Qualitatsmodells 137 60 10000 55 9000 a 8000 5 a 2 7000 g 35 2 6000 Q 30 N 5000 ES 25 8 4000 amp 20 O 3000 5 46 2000 5 1000 0 T T T T T T T T T T T 0 T T T T T T T T T T T 1 2 3 45 6 7 8 9 10 11 12 123456 7 8 9 10 11 12 Gruppe Gruppe 700 600 500 kel T E 400 sg 300 po ZS 200 100 0 T j j j j T j T T j T 1 2 38 4 5 6 7 8 9 10 11 12 Gruppe Abbildung 10 1 Projektkennzahlen nach Gruppen Bei den Qualit tsanforderungen in Abschnitt C 2 8 werden genannt Bedienbarkeit Portabilit t und Wartbarkeit Bedienbarkeit geh rt nicht zu dem von QOOD betrach teten Qualit tsbereich daher kann sie hier nicht bewertet werden Die Portabilit t ist bei allen Entw rfen gleich gut da die Implementierungssprache Java so verwendet wurde dass keine Abh ngigkeiten zur Plattform oder zu anderen Systemen bestehen Daher konzentriert sich das spezifische Qualit tsmodell auf den Faktor Wartbarkeit Innerhalb der Wartbarkeit werden bei den Anforderungen keine Schwerpunkte gesetzt Daher werden alle Kriterien des allgemeinen Modells zur Wartbarkeit unver ndert bernommen Als Perspektive wird die des Entwicklers gew hlt Bei keinem der Entw rfe ist Information zur Verf
315. prechende Metrik NEDC und ihre Verfeinerungen sind allerdings bei der Entkopplung siehe Abschnitt A 3 definiert da die Beziehun gen dort eine wichtigere Rolle spielen Paket Auf Paketebene zahlt man die direkt in einem Paket enthaltenen Klassen Interfaces und Pakete NCP number of classes in a package NCP p ce C contains p c NIP number of interfaces in a package NIP p fiel contains p i NPP number of packages in a package NPP p qe P contains p q Die drei Metriken lassen sich verfeinern indem der Sichtbarkeitsbereich public pro tected private betrachtet wird Die Sichtbarkeit eines Elements in einem Paket sollte immer so eingeschr nkt wie m glich gew hlt werden daher gibt diese Verfeinerung Sinn Sie wird hier am Beispiel von NCP demonstriert NCP number of public classes in a package NCP p ceC contains p c A c visibility public NCP number of protected classes in a package NCP p ceC contains p c A c visibility protected NCP number of private classes in a package NCP3 p ceC contains p c A c visibility private Die Metrik NCP kann auch verfeinert werden indem abstrakte und konkrete Klassen unterschieden werden Abstrakte Klassen dienen wie Interfaces vornehmlich der Modellierung von Schnittstellen haben also einen geringeren Implementierungsauf wand als konkrete Klassen und sind in der Regel stabiler d h sie haben
316. qualitat Software design is not easy not easy to do teach or evaluate Much of software education these days is about products and APIs yet much of these are transient whereas good design is eternal if only we could figure out what good design is Fowler 2001a S 97 In diesem Kapitel wird die Frage was eigentlich ein guter Entwurf ist aus verschie denen Perspektiven beleuchtet Zun chst wird ein kleines Beispiel vorgestellt in dem drei Entwurfsalternativen f r die gleiche Aufgabenstellung miteinander verglichen werden wobei der Entwurf auf intuitiver Basis unterst tzt durch Entwurfsregeln bewertet wird Analog zu den in Kapitel 6 vorgestellten Qualit tssichten werden dann die verschiedenen Sichten bei der Entwurfsqualit t herausgearbeitet Anschlie end wird auf Entwurfsregeln Prinzipien und Heuristiken des objektorientierten Entwurfs eingegangen Diese enthalten Erfahrungswissen wie man zu einem guten bzw besseren Entwurf kommt sofern die Anwendung einer Regel im aktuellen Kontext sinnvoll ist Schlie lich wird auf die Frage eingegangen wie Qualit tssiche rung und Entwurfsbewertung durchgef hrt werden k nnen wenn erst einmal klar ist welche Kriterien relevant sind 7 1 Ein Beispiel A good design provides a solution that is no more complex than the problem it solves A good design is based on deep simplicities not on simple mindedness Linger et al 1979 Auf der Suche nach einem guten Entw
317. r Abowd et al 1996 Abowd G Bass L Clements P Northrop L Zaremski A Recommended Best Industrial Practice for Software Architecture Evaluation Techni cal Report CMU SEI 96 TR 025 1996 Abreu 2001 Abreu F Using OCL to Formalize Object Oriented Metrics Definitions Proceedings of the 5th International ECOOP Workshop on Quantitative Approaches in Object Oriented Software Engineering QAOOSE 2001 Budapest 2001 99 134 Abreu Carapuca 1994 Abreu F Carapuca R Candidate Metrics for Object Ori ented Software within a Taxonomy Framework Journal of Systems and Software 26 1 1994 87 96 Adelson Soloway 1985 Adelson B Soloway E The Role of Domain Experience in Software Design IEEE Transactions on Software Engineering 11 11 1985 1351 1360 Akao 1990 Akao Y Quality Function Deployment Integrating Customer Require ments into Product Design Productivity Press Cambridge 1990 Alexander et al 1977 Alexander C Ishikawa S Silverstein M A Pattern Lan guage Oxford University Press Oxford 1977 Alexander 1979 Alexander C The Timeless Way of Building Oxford University Press Oxford 1979 Alexander 2001 Alexander R Improving the Quality of Object Oriented Programs IEEE Software 18 5 2001 90 91 Archer Stinson 1995 Archer C Stinson M Object Oriented Software Measures Technical Report CMU SEI 95 TR 002 1995 Arthur 1988 Arthur L Software Evolution
318. r dem gibt es einen Standardfilter der offensichtlich unsinnige Eingaben entfernt Der Parser filtert bereits alles heraus was f r die Konvertierung nach ODEM keine Rolle spielt 11 2 2 Der Reportgenerator Der Reportgenerator liest die Datenbank aus und erhebt die gew nschten Metriken Aus den Modellinformationen und den Messwerten generiert er dann anhand einer Vorlage einen Report Abbildung 11 2 zeigt die Architektur des Reportgenerators Der Generator liest die Vorlage ein in der Platzhalter f r Metriken stehen Er l sst den Evaluator die ben tigten Metriken in der Datenbank erheben und f gt die Messwerte anstelle der Platzhalter in die Vorlage ein Den Report gibt der Generator dann aus Vor gt lage ae 2 Generator 4 gt Evaluator 3 m Report a QO Abbildung 11 2 Architektur des Reportgenerators Die Definitionen der Metriken als SQL Anfragen oder Skripte findet der Evaluator in einer speziellen Tabelle in der Datenbank was eine flexible Auswahl und Erweite rung der Metriken erlaubt Durch die Verwendung von Vorlagen k nnen Reports f r die verschiedensten Zwecke generiert werden Hier werden zwei Beispiele vorge stellt die realisiert wurden Dateien f r den Import von Messwerten in eine Tabellen kalkulation und Review B gen in HTML Export in Tabellenkalkulation Der Reportgenerator erzeugt eine Datei die in eine Tabellenkalkulation importiert werden k
319. r cksichtigen Klassifikationen der Softwarequalit t Produkt vs Prozess Produktqualit t ist die G te des Produkts Prozessqualit t die G te des Entwicklungsprozesses des Produkts Beispielweise baut Ludewig 1998 seine Taxonomie der Qualit t auf dieser Klassifikation auf Die Prozessqualit t beein flusst die Produktqualit t in der Regel positiv z B die Wartbarkeit Slaughter Ban ker 1996 Diese Arbeit besch ftigt sich ausschlie lich mit der Produktqualit t Intern vs extern Die interne Qualit t oder Wartungsqualit t bezieht sich auf den Entwicklungsprozess und die dabei entstandenen internen Dokumente z B Ent wurfsdokumentation Sie entspricht der Entwicklersicht Die externe Qualit t oder Gebrauchsqualit t entspricht der Sicht des Benutzers des Programms Die geforderte externe Qualit t ist in den Anforderungen festgehalten w hrend die geforderte interne Qualit t wenn berhaupt berwiegend in Richtlinien und Verfahrensweisen der Entwicklungsorganisation dokumentiert ist Die interne Qualit t beeinflusst die externe positiv In dieser Arbeit liegt der Schwerpunkt auf der internen Qualit t Mittelbar vs unmittelbar Wenn Zwischenprodukte in das Endprodukt einflie en wie das beim Entwurf der Fall ist kann man zwischen der unmittelbaren Qualit t des Zwischenprodukts und der durch das Zwischenprodukt beeinflussten Qualit t des Endprodukts unterscheiden Beim Entwurf ist z B Strukturiertheit eine unm
320. r object Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor Tabelle 4 2 Entwurfsmuster von Gamma et al 1995 S 10 34 4 Objektorientierter Entwurf Es gibt inzwischen umfangreiche Literatur zum Thema Entwurfsmuster Sammlun gen von Entwurfsmustern finden sich bei Gamma et al 1995 Buschmann et al 1996 Coplien und Schmidt 1995 Vlissides et al 1996 Martin et al 1998 und Harrison et al 2000a Eine Musterbibliographie stammt von Rising 2000 4 3 5 Rahmenwerke Ein Architekturstil oder eine Kombination von Architekturstilen liefert noch keine vollst ndige Architektur sondern nur ein abstraktes Architekturger st das vom Ent werfer zu konkretisieren ist Einen Schritt weiter gehen die Rahmenwerke Ein Rah menwerk ist ein unvollst ndiges konkretes Software System oder Subsystem das die Architektur gr tenteils vorgibt Es kann zur Erstellung einer Familie von Syste men verwendet werden definiert damit also eine Art Makro Architektur Rahmen werke lassen sich h ufig nur schwer kombinieren da sie in der Regel nicht darauf ausgelegt sind Mattsson et al 1999 Ein Rahmenwerk hat Stellen an denen Anpassungen f r das konkrete System gemacht werden sollen so genannte hot spots oder hooks Hier wird der anwen dungsspezifische Teil des Systems angekoppelt Pree 1995
321. rantwortlichkeiten sind auf diejenigen begrenzt die durch die zugrunde lie gende Abstraktion erforderlich sind e Die Verantwortlichkeiten sind zusammenh ngend d h sie geh ren alle zu einer einzigen Abstraktion und geben als Ganzes Sinn e Die Verantwortlichkeiten sind vollst ndig d h es sind alle durch die zugrunde lie gende Abstraktion erforderlichen Verantwortlichkeiten vorhanden Schnittstelle interface Ist die Schnittstelle klar und einfach e Benennung Die Methodennamen geben die beabsichtigte Wirkung auf Objekte der Klasse wieder Zwei Methoden mit unterschiedlichen Absichten sollten auch unter schiedlich hei en e Symmetrie zueinander komplement re Methoden z B Abfrage und Setzen Methode sollen als solche erkennbar sein z B durch die Benennung Falls zu einer Methode erkennbar eine komplement re Methode fehlt sollte daf r ein Grund vorhanden sein e Flexibilit t Falls es sinnvoll ist sollte ein Klasse mehrere Varianten zum Aufruf einer Methode zur Verf gung stellen Dies kann durch Uberladen overloading einer Methode mit unterschiedlichen Parameterlisten erreicht werden e Bequemlichkeit Aus Gr nden der Bequemlichkeit sollten m glichst viele Default Parameter Parameter mit Wertevorbelegung angeboten werden Meiner Meinung nach sind die letzten beiden Punkte fraglich Sie leiten sich wohl vor allem aus der C und C Tradition her so viel wie m glich mit so wenig wie m g lich Zeichen zu
322. rbindung haben Diese Verbindung kann unidirektional oder bidirektional sein In UML wird die Assoziation durch eine durchgezogene Linie dar gestellt vgl Abbildung 3 4 Durch eine einfache Pfeilspitze am Ende der Verbin dungslinie kann zus tzlich die Navigierbarkeit angezeigt werden Au erdem kann ein Verbindungsende mit Rollenname und Multiplizit t versehen werden Die Multi 20 3 Objektorientierung interface Person Comparable z apa name String compareTo o Object int birthday Date setName n String getAge int compareTo o Object int Die Klasse Person realisiert ee das Interface Comparable das eine Operation compa Comparable reTo anbietet volle Darstel O Person lung oben und Kurzform Abbildung 3 3 UML Darstellung von Interfaces plizitat sagt aus wie viele Instanzen der Klasse an Assoziationen mit einer bestimm ten Instanz der anderen Klasse beteiligt sein k nnen Die Aggregation ist eine spezielle Form der Assoziation Sie zeigt an dass es sich um eine Beziehung zwischen einem Ganzen und einem Teil davon handelt Dabei ist nicht verboten dass ein Teil gleichzeitig an gar keiner oder an mehreren Aggregatio nen beteiligt ist Allerdings d rfen Aggregationen nicht zyklisch sein auch nicht indi rekt In UML wird die Aggregation wie eine Assoziation dargestellt nur dass beim Ganzen eine leere Raute angebracht ist Die Komposition ist ein Spezialfall
323. rden Diese widerstrebenden Kr fte sind bei einer einzelnen Zahl nicht mehr sichtbar Daher sollten nach der Bewertung nicht nur das Endergebnis sondern auch die Zwischenergebnisse ausgewiesen werden 120 9 Quantifizierung des Qualit tsmodells 9 2 Objektive Metriken Objektive Metriken sind vom Bewerter unabh ngig und lassen sich automatisch erhe ben Sie messen Eigenschaften des Entwurfs auf der Basis seines ODEM Modells 9 2 1 Anforderungen In diesem Abschnitt werden die Anforderungen an die objektiven Metriken formu liert Neben den allgemeinen Anforderungen an Metriken aus Abschnitt 2 2 2 gibt es hier weitere spezifische Anforderungen Die wichtigste Anforderung ist dass die Metriken mit dem zugeordneten Kriterium auf der zugeordneten Ebene korreliert sind Die Metriken sollen sich auf UML Diagrammen die typisch in einem objektorientier ten Entwurf verwendet werden erheben lassen Die Erhebung der Metriken soll nicht voraussetzen dass der Entwurf detailliert ausgearbeitet wurde Da gleichzeitig eine pr zise und eindeutige Definition der Metriken erw nscht ist werden die Metriken mit Hilfe von ODEM formal definiert und lassen sich dann auf ODEM Instanzen automatisch erheben Es sollen so wenig Metriken wie m glich verwendet werden Dadurch kann das Modell einfacher angewendet werden Allerdings k nnen durch zu starke Reduktion der Anzahl der Metriken interessante Aspekte verloren gehen Beispielsweise kann es sinnvoll s
324. rden im Folgenden genauer beschrieben Divergenz Das Problem wird analysiert und in seine Bestandteile zerlegt Anschlie end wird ein Suchraum f r die m glichen L sungen aufgespannt Dies geschieht in der Regel imp lizit im Kopf des Entwerfers Der Suchraum kann aber auch explizit dargestellt wer den Shaw und Garlan 1996 S 97ff beschreiben dazu das Konzept des Entwurfs raums design space Er enth lt die Menge aller Entwurfsm glichkeiten zu einer Menge gegebener Anforderungen Die Dimensionen des Entwurfsraums reflektieren alternative Anforderungen Entwurfsentscheidungen z B bestimmte Architektur 26 4 Objektorientierter Entwurf muster und Bewertungskriterien z B hinsichtlich Funktion oder Leistung sie sind in der Regel nicht voneinander unabh ngig Ein konkreter Entwurf wird durch einen Punkt im Entwurfsraum repr sentiert Transformation Innerhalb des in der ersten Phase generierten Suchraums wird nach L sungsm glich keiten gesucht die den Anforderungen entsprechen Im Entwurfsraum werden die Entwurfsm glichkeiten in der Regel nur die sinnvollen Alternativen durch Ein ordnung auf den einzelnen Dimensionen positioniert Indem bisher unbesetzte Berei che im Entwurfsraum betrachtet werden k nnen h ufig weitere Alternativen gefun den werden die bisher bersehen wurden Untersucht man die Korrelationen zwischen den Dimensionen insbesondere zwischen Entwurfsentscheidungen und Bewertungen kann
325. rechnung des Bewertungsvorschlags Auch die subjektiven Metriken k nnen eingegeben werden um daraus Bewertungs vorschl ge berechnen zu k nnen Abbildung 11 4 zeigt den Bereich zur Bewertung des Kriteriums Knappheit einer Klasse mit Metriken Fragebogen und subjektiver Metrik 4 Knappheit 3 Metriken l Klasse alle lokal geerbt NAC NAC1 NAC2 NAC3 NACI NACc NACIi NACIc NAC2i NAC2c NAC3I NAC3c 2 2 0 2 2 0 O 0 0 O 0 0 2 2 0 0 0 0 2 2 0 O 0 0 O 0 0 O 0 0 O 0 0 O 0 0 NOC NOC NOC2 NOC3 NOCi NOCe HOCH NOCic NOC2i NOC2c NOC3i NOC3c 2 2 0 2 2 0 0 0 0 0 0 0 2 2 0 O 0 0 2 2 0 0 0 0 O 0 0 0 0 0 O 0 0 0 0 0 3 Fragebogen Enth lt die Klasse nur die n tigen Attribute z B keine nicht mehr verwendete oder f r die Verantwortlichkeiten der Klasse nicht relevante Enth lt die Klasse nur die n tigen Operationen z2 B keine nicht mehr verwendete oder f r die Verantwortlichkeiten der Klasse nicht relevante Enth lt die Klasse keine berfl ssigen Operationen keine ja sonst nein z B Uberladene Operationen oder andere Komfort Operationen Gibt es keine hnlichen Operationen in anderen Klassen Wird die Implementierung vermutlich keinen redundanten Code enthalten keine ja sonst nein Ben tigt jede Operationen alle ihre Parameter A Ihre Bewertung 3 Bewertungsvorschlag aufgrund der objektiven Metriken 9 l Bewertungsvorschlag aufgrund des Fragebogens 4 Bewerten Sie bitte die Knappheit der Klasse H
326. reme Programmierung noch verschlimmert Bei dieser Vorge hensweise wird das System Schritt f r Schritt entworfen und implementiert so dass Entwurfserweiterungen und restrukturierungen an der Tagesordnung sind Bei extremer Programmierung wird das nderungsproblem noch versch rft da dort vor ausschauendes Entwerfen z B in Hinblick auf zuk nftige nderungen explizit untersagt ist es darf nur f r die momentan zu bearbeitenden Anforderungen entwor fen werden Kommen dann sp ter neue Anforderungen hinzu muss notfalls der Ent wurf durch Refaktorisierung berarbeitet werden Innerhalb der Wartung spielt die Verst ndlichkeit eine gro e Rolle Nach Grady 1997 Kap 4 entfallen momentan 28 der Kosten bei der Software Entwicklung ein schlie lich Wartung auf das Programmverstandnis knowledge recovery Wenn man nur die Wartung betrachtet sind es sogar 50 Corbi 1989 bis 60 Canfora et al 1996 Demzufolge k nnen Einsparungen erzielt werden wenn das Programmver st ndnis z B durch bessere Dokumentation erleichtert wird Grady rechnet mit Netto Einsparungen von 3 bis 7 falls solche Ma nahmen ergriffen werden Daher liegt innerhalb der Wartbarkeit im Qualit tsmodell ein Schwerpunkt auf Kriterien die die Verst ndlichkeit beeinflussen 8 2 Aufbau des Modells Das allgemeine Qualit tsmodell wird gem dem Factors Criteria Metrics Schema vgl Abschnitt 6 2 1 aufgebaut Die oberste Ebene bilden die Faktoren Diese se
327. requalit t wird h ufig durch Qualit tsmodelle definiert daher werden Ans tze und Beispiele f r solche Modelle vorgestellt Den Abschluss bildet eine kurze Diskussion zur Qualit tssicherung 6 1 Qualit t 6 1 1 Definition Das Wort Qualit t kommt vom lateinischen Wort qualitas Beschaffenheit und beschreibt die G te oder den Wert eines Objekts DIN 55350 definiert den Begriff Qua lit t hnlich aber nicht gleich wie die Deutsche Gesellschaft f r Qualit t DGQ Definition 6 1 Qualit t DIN 55350 11 1987 05 Die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer T tigkeit die sich auf die Eignung zur Erf llung gegebener Erfordernisse bezieht Definition 6 2 Qualit t DGQ 1995 Die Gesamtheit von Merkmalen und Merkmalswerten einer Einheit bez glich ihrer Eig nung festgelegte und vorausgesetzte Erfordernisse zu erf llen 60 6 Softwarequalitat Beide Definitionen liefern eine klare und eindeutige abstrakte Definition der Qualitat Inhaltlich sind sie hnlich aber unterschiedlich Die DIN Definition beschr nkt sich auf die explizit festgelegten Eigenschaften w hrend die DGQ Definition auch vor ausgesetzte d h implizite Erfordernisse zul sst Wie bei den Standards gibt es auch in der Praxis keine wirkliche bereinkunft ber die Bedeutung des Begriffs Qualit t Man kann Qualit t aus verschiedenen Perspektiven sehen und beurteilen Garvin 1984 1988 unterscheidet f nf Sicht
328. rfreundliche Bewertung letzte Zeile in Tabelle 10 14 kann das verhindern Die durch den Mustereinsatz hinzukommenden Elemente werden nicht so stark gewichtet da ihre negative Auswirkung auf die Verst ndlichkeit durch die Zugeh rigkeit zum Muster geringer ist als die Hinzunahme beliebiger Elemente Dadurch lassen sich bessere Bewertungen bei der Knappheit SCCS und der Struktu riertheit SSTS rechtfertigen Schlie lich l sst sich argumentieren dass die Wartbar keit insgesamt verbessert wird weil die wahrscheinlichste nderung das Hinzuf gen von Preiscodes und ge nderte Berechnungsformeln f r die Ausleihgeb hren sind Diese nderungen sind durch den Mustereinsatz leichter durchzuf hren weil nur noch die Preiscode Klassen direkt betroffen sind Durch dieses Beispiel wird deutlich dass bei der Bewertung die Verwendung von Mustern speziell ber cksichtigt werden muss um die in der Regel schlechteren Werte der vorhandenen objektiven Metriken zu kompensieren Daher w re eine Erweite rung um spezielle objektive Metriken denkbar welche die Verwendung von Mustern messen Beispielsweise k nnte als Systemmetrik die Anzahl der Musteranwendungen im Entwurf verwendet werden Eine solche Metrik w re allerdings ein schlechter Qualit tsindikator da gerade Entwurfsanf nger dazu neigen Muster im berma oder falsch zu verwenden was zu einer hohen Anzahl von Musteranwendungen f hrt Mangels geeigneter objektiver Metriken ist man daher auf di
329. ric Suite for Object Oriented Programming Journal of Systems and Software 44 2 1998 155 162 Li Henry 1993 Li W Henry S Object Oriented Metrics that Predict Maintainabil ity Journal of Systems and Software 23 2 1993 111 122 180 Literatur Lieberherr et al 1988 Lieberherr K Holland I Riel A Object Oriented Program ming An Objective Sense of Style Proceedings of OOPSLA 88 ACM SIGPLAN Notices 23 11 1988 323 334 Lieberherr Holland 1989 Lieberherr K Holland I Assuring Good Style for Object Oriented Programs IEEE Software 6 5 1989 38 48 Lientz Swanson 1980 Lientz B Swanson E Software Maintenance Management Addison Wesley Reading MA 1980 Linger et al 1979 Linger R Mills H Witt B Structured Programming Theory and Practice Addison Wesley Reading MA 1979 Liskov 1988 Liskov B Data Abstraction and Hierarchy ACM SIGPLAN Notices 23 5 1988 17 34 Lorenz Kidd 1994 Lorenz M Kidd J Object Oriented Software Metrics A Practi cal Guide Prentice Hall Englewood Cliffs NJ 1994 Ludewig 1994 Ludewig J People Make Quality Happen or Don t Proceedings of the 4th European Conference on Software Quality vdf Z rich 1994 11 21 Ludewig 1998 Ludewig J Software Engineering Vorl ufiges unvollst ndiges Skript zur Vorlesung Software Engineering an der Fakult t Informatik der Universit t Stuttgart Dezember 1998 Marchesi 1998
330. rich Universitatsverlag Konstanz Konstanz 1994 66 92 Weinberg 1971 Weinberg G The Psychology of Computer Programming Van Nostrand Reinhold New York 1971 Weinberg 1991 Weinberg G First Order Measurement Quality Software Manage ment Bd 2 Dorset House New York 1991 Weiss Basili 1985 Weiss D Basili V Evaluating Software Development by Anal ysis of Changes IEEE Transactions on Sofware Engineering 2 2 1985 157 168 Weyuker 1988 Weyuker E Evaluating Software Complexity Measures EEE Transactions on Software Engineering 14 9 1988 1357 1365 Whitmire 1994 Whitmire S Object Oriented Measurement of Software In Marcin iak J Hrsg Encyclopedia of Software Engineering Wiley New York 1994 737 739 Whitmire 1997 Whitmire S Object Oriented Design Measurement Wiley New York 1997 Wilde Huitt 1992 Wilde N Huitt R Maintenance Support for Object Oriented Programs Transactions on Software Engineering 18 12 1992 1038 1044 Wilde et al 1993 Wilde N Matthews P Huitt R Maintaining Object Oriented Software IEEE Software 10 1 1993 75 80 Winograd et al 1996 Winograd T Bennett J De Young L Hartfield B Hrsg Bringing Design to Software Addison Wesley Reading MA 1996 Witt et al 1994 Witt B Baker F Merritt E Software Architecture and Design Principles Models and Methods Van Nostrand Reinhold New York 1994 W rthele 19
331. rierten Entwicklung zur Objektorientierung ein Paradigmen wechsel n tig Fichman Kemerer 1992 Diesen Wechsel schafft nicht jeder Entwick 16 3 Objektorientierung ler Berg et al 1995 kommen in einer Untersuchung zu dem Ergebnis dass 80 der neu ausgebildeten Entwickler die Grundztige der objektorientierten Entwicklung ver standen 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 Vor gehensweise 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 zen tralen Begriffe angegeben wie sie in dieser Arbeit verwendet werden Die verwende ten 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 Sicht weise aus Objekte Klassen und Vererbung Viele Autoren nehmen noch Polymor phismus und das damit zusammenh ngende dynamische Binden als wichtige Eigen schaften hinzu Daher werden die
332. ring 27 4 2001 381 384 Haag et al 1996 Haag S Raja M Schkade L Quality Function Deployment Usage in Software Development Communications of the ACM 39 1 41 49 1996 Harrison et al 2000a Harrison N Foote B Rohnert H Hrsg Pattern Languages of Program Design 4 Addison Wesley Reading MA 2000 Harrison et al 2000b Harrison R Counsell S Nithi R Experimental Assessment of the Effect of Inheritance on the Maintainability of Object Oriented Systems Journal of Systems and Software 52 2 3 2000 173 179 Haynes 1996 Haynes P Detection and Prevention of Software Cancer in OO Sys tems OOPSLA 96 Workshop on Software Metrics San Jose CA 1996 Henderson Sellers 1996 Henderson Sellers B Object Oriented Metrics Prentice Hall Englewood Cliffs NJ 1996 Henderson Sellers et al 1993 Henderson Sellers B Moser S Seehusen D Weinelt B A Proposed Multi Dimensional Framework for Object Oriented Metrics Proceedings of the First Australian Software Metrics Conference Sydney November 1993 24 30 Hitz Neuhold 1998 Hitz M Neuhold K A Framework for Product Analysis Pro ceedings of the OOPSLA 1998 Workshop on Model Engineering Methods and Tool Interaction with CDIF Vancouver 1998 Hoare 1981 Hoare C A R The Emperor s Old Clothes Communications of the ACM 24 2 1981 75 83 Hofmeister et al 2000 Hofmeister C Nord R Soni D Applied Software Arc
333. rlegen Es wird allerdings ohnehin empfohlen Entw rfe nur von erfah renen Entwerfern bewerten zu lassen die nicht Mitglieder des Entwicklungsteams sind Abowd et al 1996 164 12 Zusammenfassung und Ausblick 12 2 6 Grenzen des Ansatzes Die wichtigste Einschr nkung des Ansatzes ist dass s mtliche dynamischen Ent wurfseigenschaften unber cksichtigt bleiben Das f hrt dazu dass wichtige Qualit ten wie Effizienz oder Zuverl ssigkeit nicht bewertet werden k nnen Ursache f r die Beschr nkung ist die Beobachtung dass dynamische Entwurfsinformation in UML zwar ausgedr ckt werden kann dies in der Praxis aber nur bruchst ckhaft getan wird Soll auch dynamische Entwurfsinformation bei der Bewertung ber cksichtigt werden m ssen entsprechende Anforderungen an Umfang und Detaillierungsgrad der UML Dokumentation gestellt werden Es hat sich gezeigt dass die UML Dokumentation eines Entwurfs nicht ausreicht um den Entwurf vollst ndig zu beschreiben Zus tzlich ist weitere erl uternde Dokumen tation notwendig Diese lie e sich zwar theoretisch in Form von Notizen auch in UML darstellen doch ist ein beschreibendes Entwurfsdokument in das UML Diagramme eingebettet sind bersichtlicher und leichter verst ndlich Diese ber die UML Dia gramme hinausgehende Information wird bei der Bewertung genutzt ist aber nicht im Referenzmodell ODEM repr sentiert Eine Entwurfsbewertung ist am effektivsten wenn sie in Zusammenhang mit
334. rt sind die f r ODEM erforderliche Information heraus und legt sie in einer relationalen Daten bank ab vgl Abbildung 11 1 Dies ist problemlos m glich weil beim Entwurf von ODEM die Speicherung der Modellinformation in Datenbank Relationen bereits vor gesehen wurde Die Verwendung einer Datenbank als Zwischenspeicher hat den Vor teil dass die Konvertierung nur einmal vorgenommen werden muss Au erdem k n nen auf der gespeicherten Information beliebige Anfragen in SQL formuliert werden Man ist also nicht auf fest in das Werkzeug hineincodierte Metriken beschr nkt son dern kann z B auch statistische Auswertungen durchf hren Filter UML XMI y Parser DB Adapter Abbildung 11 1 Architektur des Konverters 11 2 Selbst realisierte Werkzeuge 155 Bei der Implementierung des Konverters hat sich herausgestellt dass die Hersteller verschiedener UML Werkzeuge unterschiedliche Interpretationen des XMI Standards haben und entsprechend unterschiedliches XMI erzeugen Erprobt wurden in diesem Zusammenhang Argo UML 0 8 Poseidon 1 0 und Together 5 02 Together erzeugt zum Teil sogar inhaltlich falsches XMI z B falscher ownerScope bei Attributen und Operationen Um die Unterschiede und Fehler auszugleichen wurde der Konverter um ein Filterkonzept erweitert das die Verarbeitung werkzeugspezifischer Eigenhei ten erlaubt Es k nnen beliebig viele Filter hintereinander geschaltet werden Au e
335. s ausge sprochen schwierig da zu einem Zeitpunkt ein Leser des Codes immer nur einen Teil des Gesamtbildes berblicken kann Ursache f r die Delokalisierung ist dass die L sung datenorientiert erstellt wird Dies ist sinnvoll um eine bessere Abstraktion im Sinne abstrakter Datentypen zu errei chen Durch die Fokussierung auf die Daten wird aber die Funktion in kleine Teile zerlegt die sich den jeweiligen Daten zuordnen lassen Die Verteilung der Funktion wird durch Vererbung noch verst rkt weil man die Methoden zu den Operationen einer Klasse nicht an einem Ort findet sondern sich diese aus der gesamten Verer bungshierarchie zusammensuchen muss Dynamisches Binden erschwert zus tzlich eine statische Analyse des Codes da oft nicht klar ist welche Methode tats chlich aufgerufen wird Gerade weil die dynamische Struktur im Code schlecht dokumentiert ist muss sie im Entwurf hinreichend beschrieben werden denn sie wird sp ter zum Verst ndnis des Codes ben tigt werden Die Dokumentation kann z B in Form von Szenarien mit einigen Objekten und Aufrufsequenzen ihrer Methoden erfolgen In UML dienen zur Beschreibung der dynamischen Struktur vor allem Objektdiagramme Sequenzdia gramme Kollaborationsdiagramme Zustandsdiagramme und Aktivit tsdiagramme 4 3 Muster und Rahmenwerke Das erste Ergebnis des Entwurfs ist die Software Architektur In den letzten zehn Jah ren hat der Bereich der Software Architektur viel Aufmerksamkeit vo
336. s ihm gelieferte Produkt zwar alle gew nschten Funktionen aufweist sich aber allen sp teren nde rungsversuchen widersetzt wird er keine Folgeauftr gen vergeben Daher ist die Ersparnis durch den kurzfristig ausgelegten Entwurf mit den ausbleibenden Gewinnen aus Folgeauftr gen zu ver rechnen was in der Regel insgesamt zu einem Verlust f hren wird 80 7 Entwurfsqualitat che nach dem Systemtest ist es praktisch wenn der Entwurf M glichkeiten zur Diagnose z B Debug Ausgaben vorsieht Dann k nnen Fehlerursachen leich ter eingegrenzt werden e Wartungsentwickler Der Wartungsentwickler interessiert sich vor allem f r die Verst ndlichkeit und die nderbarkeit des Systems Kleine nderungen insbe sondere vorhersehbare nderungen sollten mit geringem Aufwand vorgenom men werden k nnen Au erdem sollte eine solche nderung m glichst nur Auswirkungen auf eine Komponente haben Der gef rchtete Welleneffekt sollte h chstens lokal d h innerhalb einer Komponente auftreten e Projektmanager Der Projektmanager m chte dass zur Realisierung des Entwurfs m glichst geringe Ressourcen notwendig sind Der Entwurf und die Realisierung sollen m glichst schnell gehen damit der knappe Terminplan eingehalten werden kann es sollen alle im Team verf gbaren Kr fte aber nicht mehr eingesetzt wer den und die Ausgaben f r Werkzeuge Softwarekomponenten Schulung etc sol len gering sein Nat rlich soll das entworfene System
337. sab weichungen Tabelle 2 1 bersicht ber die Skalentypen nach DIN 55350 Teil 12 S 11 erweitert um die Absolutskala 12 2 Modelle und Metriken Anwendungsbereiche Metriken lassen sich fiir unterschiedliche Zwecke einsetzen Whitmire 1994 unter scheidet die folgenden Anwendungsbereiche von Metriken e Sch tzung auf der Basis anderer Produkte historische Daten z B den zu erwar tenden Entwicklungsaufwand aus Daten fr herer Projekte ableiten e Vorhersage auf der Basis von Messwerten des Produkts andere Eigenschaften des Produkts vorhersagen z B Verl sslichkeit aufgrund von Testergebnissen e Bewertung Vergleich von Messwerten mit Sollwerten die z B von einem Stan dard festgelegt sind Anwendung z B f r die Pr fung von Qualit tszielen durch Schwellenwerte oder zur Auswahl von vermutlich fehlertr chtigen Klassen f r Reviews e Vergleich Vergleich der Messwerte von Alternativen zur Entscheidungsunterst t zung z B zur Auswahl einer Entwurfsalternative e Untersuchung Messung zur St tzung oder Widerlegung einer Hypothese In dieser Arbeit werden Metriken vor allem zur Vorhersage Bewertung und zum Ver gleich verwendet Anforderungen Um eingesetzt werden zu k nnen sollten Metriken bestimmte Anforderungen erf l len Basili und Rombach 1988 Daskalantonakis 1992 und Gillies 1992 haben sol che Anforderungen formuliert die hier zusammengefasst sind Die Metrik soll leicht
338. sagen Deshalb m ssen auch Methodenaufrufe so kurz wie m glich sein Allerdings bl ht das berladen die Klassenschnittstelle oft unn tig auf vor allem wenn es aus Bequemlichkeit geschieht Default Parameter erschweren es sp ter im Code herauszufinden welche Methode aufgerufen wird da beim Aufruf Para meter weggelassen werden k nnen Daher wirken sich beide Punkte in der Regel negativ auf die Verst ndlichkeit aus Verwendung usage Stimmt der Entwurf der Klasse mit der tats chlichen Verwen dung berein Dazu werden die tats chlich vorkommenden Verwendungen der Klasse untersucht und daraufhin berpr ft ob die Schnittstelle der Klasse f r diese Verwendungen geeignet ist Dabei kann man fehlende Methoden identifizieren und auch falsche d h ungeeignete Verwendungen 7 4 Beispiele f r OOD Qualitatsmodelle 93 Implementierung implementation Gibt es eine vern nftige Implementierung f r die Klasse Falls die Implementierung sehr gro oder komplex ist sollte berpr ft werden ob die Klasse zu viele Verantwortlichkeiten hat oder eine ungeeignete Abs traktion gew hlt wurde Bei Bedarf kann die Klasse in neue Klassen zerschlagen wer den oder die Implementierung durch Hilfsklassen besser strukturiert werden 7 4 5 Gillibrand und Liu Gillibrand und Liu 1998 geben ein rudiment res Qualit tsmodell f r den objekt orientierten Entwurf an das nach dem FCM Schema vgl Abschnitt 6 2 1 aufgebaut ist Das Modell
339. sbar ist Weil der Begriff der Eleganz in der Praxis immer wieder auftauche m sse er aber von Bedeutung sein Sie geben zwei Beispiele f r Eleganz an wiederkehrende Muster im Entwurf und hnlichkeit der Entwurfsstruktur zur Struktur der Realit t Zur Entwurfsbewertung schlagen Coad und Yourdon Reviews vor Zum einen sollen sich diese an Szenarien orientieren die mit den Klassen durchgespielt werden Au er dem sollten kritische Erfolgsfaktoren wie Wiederverwendbarkeit Effizienz und Imp lementierbarkeit gepr ft werden 7 4 3 Cockburn Cockburn 1998 geht von der folgenden Annahme an Discussing the quality of an OO design is discussing the futures it naturally supports Es geht ihm also vor allem um Faktoren wie Anderbarkeit und Erweiterbarkeit Cockburn gibt ein Bewertungs 7 4 Beispiele fur OOD Qualitatsmodelle 91 schema ftir objektorientierte Entwtirfe an das aus den folgenden sechs Kriterien besteht Verbundenheit der Daten data connectedness Reicht das von einer Klasse aus gehende Beziehungsnetzwerk aus um ihr die Ausf hrung der von ihr verlangten Dienste zu erlauben Oder anders ausgedr ckt Verf gt die Klasse ber die n tigen Kontakte um ihre Aufgabe zu erf llen Hier k nnte m E noch zus tzlich gepr ft werden ob es berfl ssige Kontakte gibt die f r die Erf llung der Aufgabe nicht notwendig sind Abstraktion abstraction Entspricht der Name der Klasse der durch sie dargestell ten A
340. se 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 n dern 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 Attri bute 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 Implem
341. se Interface Abschnitt 1 von 2 208 B Frageb gen fur QOOD Bedingung Fragetext Antwortskala Gewicht auto Handelt es sich bei einer Komposition um eine 0 nein TER echte Komposition 1 ja Kriterien Teil Ganzes Beziehung Multiplizit t der Aggregatklasse ist 0 1 oder 1 Lebensdauer der Teile ist an das Ganze gebunden Funktionen des Ganzen werden automatisch auf die Teile angewendet Ist jede Vererbungsbeziehung eine Spezialisie 0 nein Son rungsbeziehung 1 ja Gibt es keine Benutzungsbeziehung die eine 0 nein ex strukturelle Beziehung z B Assoziation model 1 ja liert Gibt es keine lokalen Attribute Operationen oder 0 nein W Beziehungen die weiter oben in der Vererbungs 1 ja hierarchie definiert sein sollten NEEC this Ben tigt jede Unterklasse alle geerbten Attribute 0 nein SZ gt 0 Operationen und Beziehungen 1 ja thise C Ist der Sichtbarkeitsbereich jedes Attributs so O nein ER gering wie m glich 1 ja thise C Gibt es keine ffentlich sichtbaren public Attri 0 nein SS bute 1 ja Ist der Sichtbarkeitsbereich jeder Operation so 0 nein FAR gering wie m glich 1 ja Ist jede ffentlich sichtbare public Operation O nein ZS wirklich n tig 1 ja Hat keine der Operationen mehr als 6 Parameter 0 nein v 1 ja Fragebogen B 7 Entkopplung Klasse Interface Abschnitt 2 von 2 Paket Bedingung Fragetext Antwort
342. se Texte daher auch als ein separates Dokument erstellen Dieses Dokument ist C 1 Aufgabenstellung 219 dann Ihr Hauptdokument Sehen sie darin an geeigneter Stelle Kapitel f r die Innova tor Dokumentation vor Schreiben Sie in diesem Kapitel dann nur einen Verweis auf das entsprechende Innovator Dokument Innovator ist wie das JDK auf den Rechnern des Grundstudiumpools installiert Die Version dort enth lt im Gegensatz zur kostenlos erh ltlichen PC Demo Version keine Beschr nkungen Sie k nnen damit auch parallel am gleichen Dokument Reposi tory arbeiten Um allen Problemen aus dem Weg zu gehen verwenden Sie diese unbeschr nkte Version L sungen die auf Grund der Demo Beschr nkungen etwas zu einfach geraten sind werden nicht akzeptiert Sollte es im Grundstudiumspool zu gr eren Engp ssen und Problemen kommen informieren Sie uns ber die Bedienung und den Aufruf von Innovator informiert Sie eine kurze Anlei tung und die Online Dokumentation Konsultieren Sie diese beiden Hilfestellungen bevor Sie mit Fragen zu Ihrem Betreuer gehen Verwenden Sie in der Anleitung nicht beschriebene M glichkeiten von Innovator nur dann wenn Sie sicher wissen was Sie tun Wir k nnen hierf r keine Hilfestellungen geben Insbesondere ist es nicht vorge sehen dass Sie den in Innovator eingebauten Code Generator f r Java verwenden C 1 6 Abgaben Wie bereits erw hnt m ssen Sie zu allen Meilensteinterminen die entsprechenden Dokumen
343. senschaftsverlag Mannheim 1988 11 19 Snyder 1986 Snyder A Encapsulation and Inheritance in Object Oriented Pro gramming Languages Proceedings of OOPSLA 86 ACM SIGPLAN Notices 21 11 1986 38 45 Snyder 1993 Snyder A The Essence of Objects Concepts and Terms IEEE Soft ware 10 1 1993 31 42 Soloway et al 1988 Soloway E Pinto J Letovsky S Littman D Lampert R Designing Documentation to Compensate for Delocalized Plans Communications of the ACM 31 11 1988 1259 1267 Stachowiak 1973 Stachowiak H Allgemeine Modelltheorie Springer Wien 1973 Stevens et al 1974 Stevens W Myers G Constantine L Structured Design IBM Systems Journal 13 2 1974 115 139 Stroustrup 1997 Stroustrup B The C Programming Language 3 Auflage Addison Wesley Reading MA 1997 Swartout Balzer 1982 Swartout W Balzer R On the Inevitable Intertwining of Specification and Implementation Communications of the ACM 25 7 1982 438 440 Taivalsaari 1996 Taivalsaari A On the Notion of Inheritance ACM Computing Surveys 28 3 1996 438 479 Tegarden et al 1995 Tegarden D Sheetz S Monarchi D A Software Complexity Model of Object Oriented Systems Decision Support Systems 13 3 4 1995 241 262 Troy Zweben 1981 Troy D Zweben S Measuring the Quality of Structured Designs Journal of Systems and Software 2 1981 113 120 Visser Hoc 1990 Visser W Hoc J
344. skala Gewicht auto Sind alle Entwurfsentscheidungen so weit wie 0 nein ZS m glich verborgen 1 ja Gibt es keine unn tige Abh ngigkeiten zu ande 0 nein EN ren Paketen 1 ja durch Abh ngigkeiten zu Klassen Interfaces aus diesen Paketen Gibt es keine zyklische Abh ngigkeiten mit ande 0 nein ZS Y ren Paketen 1 ja Fragebogen B 8 Entkopplung Paket B 4 Zusammenhalt 209 System Bedingung Fragetext Antwortskala Gewicht auto Sind alle Entwurfsentscheidungen so weit wie 0 nein Cree m glich verborgen 1 ja Gibt es weder globale Variablen noch werden 0 nein eRe Offentliche Klassenattribute als solche verwen det 1 ja Fragebogen B 9 Entkopplung System B 4 Zusammenhalt Wesentliche Prinzipien f r die Erh hung des Zusammenhalts sind die Trennung der Zust ndigkeiten separation of concerns und die Trennung von Verhalten und Imple mentierung separation of policy and implementation Klassen mit hohem Zusam menhalt realisieren eine abgegrenzte Aufgabe vollst ndig Klasse Interface Bedingung Fragetext Ist die Klasse eine abgegrenzte Abstraktion eines Begriffs aus dem Problem oder L sungsbereich Antwortskala 0 nein 1 ja Gewicht KEK auto Realisiert die Klasse nur eine Verantwortlichkeit oder sehr wenige wenn viele Operationen vorhanden sind deutet das auf das Gegenteil hin Realisiert die Klasse ihre Verantwortl
345. sprozess nach Kriz Abbildung nach Zuse 1994 S 137 Das formale Relationensystem hat eine wichtige Eigenschaft die Zul ssigkeit bestimmter mathematischer Operationen Diese werden durch den Skalentyp des Systems charakterisiert Fenton und Pfleeger 1996 unterscheiden die folgenden Ska lentypen Nominalskala Ordinalskala Intervallskala Rationalskala und Absolut skala Tabelle 2 1 zeigt die Eigenschaften der Skalen und die Unterschiede Z hlmetriken die in dieser Arbeit eine wichtige Rolle spielen sind Metriken mit Absolutskala Da sich ihr Wertebereich auf die nat rlichen Zahlen beschr nkt sind einige Operationen wie z B die Bildung von Durchschnitten eigentlich nicht mehr m glich Daher bettet man den Wertebereich sinnvollerweise in die rationalen Zahlen ein um besser rechnen zu k nnen 2 2 2 Verwendung Using some metrics is better than using no metrics Pfleeger 2000 S 225 Wie wichtig Metriken f r die qualitativ hochwertige Software Entwicklung sind zeigt die Tatsache dass im Capability Maturity Model CMM Humphrey 1988 bereits ab Stufe 2 repeatable der Einsatz von Metriken verlangt wird 2 2 Metriken Merkmalsart Qualitative Merkmale Quantitative Merkmale kontinuierliche oder diskrete Nominal Ordinal merkmal merkmal Skalentyp Topologische Skalen Kardinalskalen Metrische Skalen Nominalskala Ordinalskala Intervallskala Rationalskala Absolutskala Defin
346. sse selbst oder einer ihrer Oberklassen mit der anderen Klasse ist der Wert von weight dieser 3 Bei associates ist noch das Attribut aggregation zu beachten Dieses wird mit der st rksten Assoziati onsart der beteiligten Assoziationen belegt wie bei associates vgl Abschnitt 5 3 4 54 5 Ein Referenzmodell fur den objektorientierten Entwurf Relation zur Gesamtsumme hinzuzuz hlen Hier wird die Formalisierung am Bei spiel von uses gezeigt uses x y weight uses x y weight Zze CUI extends x z USes z y weight Bei realizes sollte das Gewicht immer maximal 1 sein da faktisch eine Klasse ein Interface nicht mehrfach realisieren kann Es kann h chstens eine bereits vorhandene Realisierung durch Redefinition der geerbten Realisierung ge ndert werden Ein Gewicht gr er 1 d rfte immer auf einen Entwurfsfehler hinweisen 5 4 4 berlegungen zu Templates Die M glichkeit zur Bildung von parametrisierten Modellelementen ist in UML nicht auf Klassen beschr nkt Beispielsweise lassen sich Entwurfsmuster als parametrisierte Kollaborationen modellieren Die hier betrachtete Erweiterung von ODEM beschr nkt sich aber auf Template Klassen da diese den blichen Gebrauch von Tem plates darstellen z B in C oder Eiffel Es werden auch nur vollst ndige Instantiie rungen von Templates betrachtet au erdem wird die M glichkeit zur Default Bele gung von Parametern au er Acht gelassen Im UML Metamodell werden Templates
347. stiken Abschnitt 2 von 2 7 4 Beispiele f r OOD Qualitatsmodelle Die Fragestellung Was macht einen guten objektorientierten Entwurf aus hat schon viele Autoren besch ftigt Aus der Literatur soll hier eine kleine Zusammen stellung der Meinung verschiedener Autoren gegeben werden die sich mit dieser Frage besch ftigt haben Alle Autoren geben Kriterien bzw Fragestellungen an mit denen die Qualit t eines Entwurfs bewertet werden soll Viele der oben bereits beschriebenen berlegungen haben Eingang in die Qualit tsmodelle gefunden 7 4 Beispiele fur OOD Qualitatsmodelle 89 7 4 1 Booch Booch 1994 S 136ff gibt fiinf wichtige Eigenschaften einer Abstraktion d h einer Klasse an Leider fehlen Messvorschriften f r diese Eigenschaften obwohl er sie als Metriken bezeichnet Kopplung coupling Geringe Kopplung wird wie beim strukturierten Entwurf auch beim objektorientierten Entwurf angestrebt die Module sind hier die Klassen Es gibt zwei verschiedene Arten der Kopplung durch Verwendung und durch Verer bung W hrend die Kopplung durch Verwendung so gering wie m glich sein sollte ist Vererbung an sich erw nscht Die dadurch erzeugte Kopplung wird in Kauf genommen Zusammenhalt cohesion Hoher Zusammenhalt ist ebenfalls erw nscht es geht vor allem um den Zusammenhalt der Bestandteile Attribute und Methoden von Klassen Angemessenheit sufficiency Eine Klasse ist angemessen wenn sie gen gend Eig
348. t Die produktbezogene Sicht hingegen sieht Qualit t als pr zise und messbar an Unterschiede in der Qualit t reflektieren Unterschiede in den Bestandteilen oder den Attributen eines Produkts Die Qualit t wird also auf messbare Eigenschaften eines Produkts zur ckgef hrt was es erlaubt eine Rangfolge von Produkten zu erstellen Auf diese Weise ist Qualit t eine inh rente Eigenschaft eines Produkts die objektiv bestimmt werden kann Diese Qualit tssicht wird typischerweise bei Produktverglei chen z B denen der Stiftung Warentest eingenommen 1 In der Nachfolgenorm der DIN 55350 DIN EN ISO 8402 sind die impliziten Anforderungen aufge nommen worden Qualit t ist die Gesamtheit von Merkmalen einer Einheit bez glich ihrer Eig nung festgelegte oder vorausgesetze Erfordernisse zu erf llen 6 1 Qualitat 61 Benutzerbezogene Sicht Die benutzerbezogene Sicht definiert Qualit t aus der Sicht des Benutzers eines Pro dukts Er wird dasjenige Produkt als hochwertig ansehen das seine Bed rfnisse opti mal befriedigt Juran 1974 z B definiert quality is fitness for use Die Bestimmung der Qualit t durch den Benutzer ist aber subjektiv Quality is the degree to which a specific product satisfies the wants of a specific customer Gilmore 1974 Weinberg 1991 macht die Subjektivit t von Qualit t besonders deutlich Offensichtlich haben alle dieselbe Definition f r Qualit t und die lautet Quality is
349. t 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 UIM L Metamodel 1 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 Dar stellung des Entwurfs in UML sind h ufig nur Klassen und Paketdiagramme vorhan den 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 Sequenz und Zustandsdiagrammen Typischerweise werden diese Diagramme aber nur f r 46 5 Ein Referenzmodell fur den objektorientierten Entwurf ausgewahlte Szenarien erstellt beschreiben also nur Ausschnitte aus der dynami schen Struktur F r eine Bewertung w re aber eine vollst ndige Beschreibung n tig Daher werden alle dynamischen Informationen die im UML Metamodell vorgesehen sind ausgeblendet Weitere Einschr nkungen von ODEM gegen ber dem UML Metamodell sind e Parametrisierte Klassen Templates werden nicht betrachtet um das Modell ber
350. t all gemein g ltig sondern es muss anhand des Kontextes entschieden werden ob ihr Einsatz an einer bestimmten Stelle im Entwurf sinnvoll ist Eine der ersten Sammlungen von Heuristiken stammt von Korson und McGregor 1990 S 54 Riel 1996 ver ffentlichte die bisher umfangreichste Sammlung aber auch Booch et al 1998 f hren in ihrem UML Handbuch viele Heuristiken auf Wei tere Heuristiken finden sich z B bei Firesmith 1995 Lakos 1996 und Johnson und Foote 1988 Die Heuristiken lassen sich in f nf Bereiche einteilen Heuristiken f r Klassen Inter faces Pakete Vererbungsbeziehungen und sonstige Beziehungen Tabelle 7 4 zeigt einige Beispiele fiir jede Kategorie siehe auch Reifsing 2002 Heuristiken f r Klassen Die Klasse soll eine abgegrenzte Abstraktion eines Begriffs aus dem Problem oder L sungsbe reich sein Booch et al 1998 Die Klasse soll eine kleine wohldefinierte Menge von Verantwortlichkeiten enthalten und diese alle gut ausf hren Booch et al 1998 Die Attribute und Operationen der Klassen sollen wirklich notwendig sein um die Verantwort lichkeiten der Klasse zu realisieren Booch et al 1998 Enth lt eine Klasse zu viele Verantwortlichkeiten sollen diese auf neue Klassen verteilt werden Booch et al 1998 Enth lt eine Klasse zu wenig Verantwortlichkeiten soll sie mit anderen Klassen zusammenge fasst werden Booch et al 1998 Die Klasse soll eindeutig
351. t als NPP number of packages in a package definiert System Auf Systemebene werden die Vererbungs und die Schachtelungshierarchie als Gan zes betrachtet Dazu verwendet man die maximale Tiefe und den maximalen Ver zweigungsgrad DITS depth of inheritance tree of the system DITS S max cecuy DITC c MNCS maximum number of child classes in the system MNCS S max ce cur NEEC c DNHS depth of nesting hierarchy of the system DNHS S max ep DNHP p MNPS maximum number of subpackages in the system MNPS S max ep NPP c A 3 Entkopplung Wie bereits im Abschnitt 8 3 3 ausgeftihrt stellt die Entkopplung einen der wichtigs ten Indikatoren ftir die Wartbarkeit dar Daher ist es nicht erstaunlich dass schon viele Kopplungsmetriken vorgeschlagen wurden Briand et al 1999 geben einen Uberblick iiber die Literatur Sie stellen auch wesentliche Fragestellungen zusammen die bei der Wahl von Kopplungsmetriken zu beantworten sind 1 Welche Kopplungsarten werden betrachtet 2 Wie wird die St rke einer Kopplung bewertet Kopplungsart und h ufigkeit 3 Wird die Richtung der Kopplung betrachtet Import Export Kopplung 2 F r eine echte Hierarchie sollte diese Zahl eigentlich immer 1 oder 0 f r die Wurzel sein Aller dings k nnte es Mehrfachvererbung geben was zu einer h heren Komplexit t f hrt 194 A Metriken fur QOOD 4 Wird nur direkte oder auch indirekte Kopplung betrachtet Diese Fr
352. t auch die kos tenbezogene Sicht einnehmen Nur im Zusammenspiel der Sichten wird am Schluss ein hochwertiges und erfolgreiches Produkt entstehen 6 1 2 Softwarequalit t Definition Auch in der Welt der Software herrscht keine Einigkeit ber den Begriff der Qualit t Jones 1996 demonstriert dies indem er diverse Gr en des Software Engineering mit ihrer Definition von Softwarequalit t zitiert vgl Tabelle 6 1 Jede dieser Definiti onen hat ihre Berechtigung zusammengenommen sind sie aber widerspr chlich Jones fordert f r eine praxisrelevante Definition von Softwarequalit t dass Qualit t messbar nach der Fertigstellung der Software und vorhersagbar vor der Fertigstel lung der Software sein sollte Definition von Softwarequalit t Barry Boehm Achieving high levels of user satisfaction portability maintainability robustness and fitness for use Phil Crosby Conformance to user requirements W Edwards Striving for excellence in reliability and functions by continuous improve Deming ment in the process of development supported by statistical analysis of the causes of failure Watts Humphrey Achieving excellent levels of fitness for use conformance to require ments reliability and maintainability Capers Jones The absence of defects that would make software either stop completely or produce unacceptable results James Martin Being on time within budget and meeting user needs Thomas M
353. t die Namensgebung f r Attribute Operationen 0 nein a und Parameter einheitlich 1 ja z B gleiche Namen f r Operationen mit dem gleichen Zweck Fragebogen B 12 Einheitlichkeit Klasse Interface Paket Bedingung Fragetext Antwortskala Gewicht auto Ist beim Paketnamen die Namenskonvention f r 0 nein RER Pakete eingehalten worden 1 ja NPP this Ist die Namensgebung f r die enthaltenen Pakete 0 nein TS gt 0 einheitlich 1 ja NCP this Ist die Namensgebung f r die enthaltenen Klas 0 nein Ge NIP this gt 0 sen Interfaces einheitlich 1 ja Fragebogen B 13 Einheitlichkeit Paket System Bedingung Fragetext Antwortskala Gewicht auto Ist die Namensgebung f r Pakete insgesamt ein 0 nein ER heitlich 1 ja Ist die Namensgebung f r Klassen Interfaces ins 0 nein RR gesamt einheitlich 1 ja Ist die Namensgebung f r Attribute Operationen 0 nein en und Parameter insgesamt einheitlich 1 ja Folgt der Entwurf insgesamt einem einheitlichen 0 nein RER Stil Fragebogen B 14 Einheitlichkeit System B 6 Dokumentierung Die Frageb gen konzentrieren sich vor allem auf die semantischen Aspekte der Namensgebung und die Qualit t der begleitenden Dokumentation z B Kommentare oder separate Entwurfsdokumentation In spezifischen Modellen sollten diese Fra gen noch durch Kriterien aus den Dokumentationsstandards erweitert werden hier repr sentiert durch eine generische
354. t einmal ausreichend verstanden werden muss was einen hohen Einarbeitungsaufwand erfordert Die Anzahl der Operationen wiegt mehr als die Anzahl der Attribute weil eine nderung in der Regel aufwendiger ist Um zu einer quantitativen Sch tzung des Wartungsauf wands zu gelangen wird pro Klasse von 30 Minuten pro Operation von 15 Minuten und pro Attribut von 5 Minuten Gesamtaufwand ausgegangen Anhand der Bewertung der Wartbarkeit wurden der beste der schlechteste und ein mittlerer 0 Entwurf ausgew hlt Diese Entw rfe stammen von den Gruppen 7 1 und 3 die vom selben Betreuer betreut wurden Die drei Entw rfe wurden daraufhin untersucht welche nderungen f r die drei nderungsszenarien notwendig sind nderung 1 Die vier besten Verbindungen ausgeben Bisher soll das System nur die beste Verbindung ausgeben und alle weiteren Verbin dungen die das Optimierungskriterium gleich gut erf llen Diese nderung ver langt nun dass stattdessen immer die besten vier Verbindungen ausgegeben werden wie es auch bei der elektronischen Fahrplanauskunft z B bei www vvs de blich ist Von dieser nderung sind potentiell betroffen e die Verbindungssuche deren Datenhaltung und R ckgabe sowie e die Verbindungsausgabe auf dem Bildschirm und in die HTML Datei Hier hat der schlecht bewertete Entwurf echte Schw chen weil er entgegen der urspr nglichen Anforderungen immer nur eine Verbindung als Resultat der Suchan frage lief
355. t sich selbst stellen einen Sonderfall dar weil die Abhan gigkeit lokal beschr nkt ist Dadurch ist diese Kopplung weniger schlecht ftir die Wartbarkeit als eine Kopplung nach aufsen Deshalb ist es sinnvoll mit reflexiven Beziehungen zu verfeinern NEDC number of reflexive efferent dependencies of a class NEDC c depends_on c c weight Eine weitere Verfeinerung unterscheidet zwischen Abh ngigkeiten von abstrakten Klassen Interfaces und konkreten Klassen Abstrakte Klassen und Interfaces sind in der Regel stabiler d h ihre Schnittstelle ndert sich nicht so h ufig Deshalb k nnten solche Abh ngigkeiten geringer gewichtet werden als Abh ngigkeiten von konkreten Klassen NEDC number of abstract efferent dependencies of a class NEDC c Zde CUE d isAbstracr depends_on c d weight Au erdem k nnen Beziehungen zu Modellelementen im gleichen Paket von Bezie hungen zu Modellelementen in anderen Paketen unterschieden werden A 3 Entkopplung 195 NEDC number of package internal efferent dependencies of a class NEDC c Ipe P contains p c Idecul contains p d dep ends_on c d weig ht Schlie lich kann noch nach der Art der Beziehung verfeinert werden Vererbung Rea lisierung Assoziation und Benutzung Wegen der gro en Bedeutung dieser Verfeine rung werden statt Indizes neue Akronyme verwendet NEEC number of efferent extends relationships of a class NEEC c Zac cu extends c d weight NERC num
356. te auch zus tzlich eine Gewichtung der Anforderungen vorgenommen werden so dass die Verfolgbarkeit wichtiger oder instabiler Anforderungen st rker ber cksichtigt wird als die Verfolg barkeit unwichtiger oder stabiler Anforderungen Eine solche Verfeinerung ist aller dings Aufgabe des spezifischen Qualit tsmodells Sofern ein bestimmtes Verfahren zur Verkn pfung von UML Artefakten mit den Anforderungen existiert kann diese Metrik auch automatisiert erhoben werden nachdem ODEM um die entsprechenden Konstrukte erweitert wurde In UML ist ein spezielles Stereotyp trace f r Abstraktionsbeziehungen zwischen UML Modellele menten definiert im UML Metamodell repr sentiert durch die Klasse Abstraction vgl Abbildung 5 2 Mit Hilfe einer solchen Beziehung l sst sich Tracing in UML realisie ren Es kann aber wohl nicht davon ausgegangen werden dass sich alle Anforderun gen in UML sinnvoll darstellen lassen z B als Anwendungsf lle und dass alle trace Beziehungen vorhanden sind AS Wartbarkeit Die wesentlichen Metriken zur Wartbarkeit stecken bereits in den Kriterien Neu hin zugenommen werden k nnen nur noch Metriken die ber das UML Modell hinaus gehen Beispielsweise kann auf der Basis eines Szenario basierten Bewertungsansat zes die adaptive Wartbarkeit gemessen werden indem f r jedes nderungsszenario die Schwierigkeit der nderung bewertet und eine Gesamtbewertung ermittelt wird vgl Abschnitt B 8 Solche Metrik
357. te bei Ihrem Betreuer abgeben Was Sie wann abzugeben haben muss Ihrem Projektplan entnommen werden k nnen Die entsprechenden Dokumente m ssen genau am geplanten Tag abgegeben werden d h sie m ssen sp testens am Morgen des folgenden Tages 8 00 Uhr beim Betreuer angekommen sein Beim Stand der heutigen Technik sollte es Ihnen m glich sein Abgaben sauber zu gestalten d h ein Textverarbeitungsprogramm zu verwenden Welches Programm Sie verwenden bleibt Ihnen berlassen Am Ende des Praktikums Abgabetermin genau beachten geben Sie ein elektroni sches Archiv durch Verzeichnisse gegliedert mit tar und gzip zusammengepackt und per Mail an den Betreuer versandt ab das den folgenden Inhalt haben muss e das ausf hrbare Programm lauff hig auf unseren Rechnern mit JDK 1 2 und alle f r die Ausf hrung notwendigen Dateien e den Quelltext des Programms e evtl erstellte Testrahmen Testprogramme oder Testdaten e eine Textdatei README die den bersetzungsvorgang den Programmstart die Abweichungen des fertigen Programms von der Spezifikation Fehler und Ein schr nkungen beschreibt e alle Meilensteindokumente und den Projektplan im Postscript Format e sowie all diese Dokumente in ihrem Originalformat also im entsprechenden For mat der verwendeten Textverarbeitung Alle Dokumente in diesem Archiv m ssen auf dem aktuellsten Stand sein Au erdem m ssen Sie zu diesem Termin eine Kopie Ihres Stundenzettels abgeben u
358. tegriert entwerfen Richtlinien Restrukturie rungen Kriterien verbessern bewerten Abbildung 12 1 Entwurfsunterst tzung durch QOOD 12 4 Ausblick 167 Entwerfen QOOD kann den Entwurfsprozess durch abgeleitete Richtlinien und Empfehlungen unterst tzen Die erl uternden Texte zu den Kriterien k nnen Hilfestellungen zur L sung von auftretenden Entwurfsproblemen geben Au erdem kann mit Hilfe von QOOD bereits in der Analysephase gepr ft werden ob alle erforderlichen Qualit ten in der Anforderungsspezifikation definiert sind Bewerten Die Entwurfsbewertung ist das eigentliche Thema dieser Arbeit Die Verwendung der Bewertung zum Vergleich von Alternativen und zur Schwachstellenanalyse wurde bereits angesprochen Allerdings sind noch einige Erweiterungen bei der Auswertung der Metriken denkbar Neben einer statistischen Auswertung die Durchschnitte Standardabweichungen Maxima etc liefert ist auch eine Visualisierung der Mess werte sinnvoll Eine weitere sinnvolle Erg nzung sind Trendanalysen Dazu werden die Messwerte und Bewertungen eines Entwurfs ber seine Entstehungsgeschichte hinweg gesam melt Dadurch k nnen insbesondere ungewollte Verschlechterungen erkannt werden die sonst bei einer einzelnen Bewertung nicht aufgefallen w ren Verbessern Add quality to every design and piece of code touched Maintainers cannot become more pro ductive without quality improvements Arthur 1988 S
359. ten durch eine Szenario basierte Bewertung beantworten vgl Abschnitt 7 6 1 Klasse Interface Bedingung Fragetext Antwortskala Gewicht auto Sind die wahrscheinlichsten zuk nftigen nde 0 nein ER rungen der Anforderungen leicht umzusetzen 1 ja Sind die Entwurfsentscheidungen die sich O nein ndern k nnen vor dem Rest des Systems 1 ja gem dem Geheimnisprinzip verborgen Fragebogen B 21 Wartbarkeit Klasse Interface Paket Fragetext Antwortskala Erry Sind die Entwurfsentscheidungen die sich ndern k nnen vor dem Rest des Systems gem dem Geheimnisprinzip verborgen Fragebogen B 22 Wartbarkeit Paket Bedingung System Bedingung Fragetext Antwortskala Gewicht auto Sind die wahrscheinlichsten zuk nftigen nde 0 nein ER rungen der Anforderungen leicht im Entwurf 1 ja umzusetzen Sind die Entwurfsentscheidungen die sich 0 nein K ndern k nnen vor dem Rest des Systems 1 ja gem dem Geheimnisprinzip verborgen Fragebogen B 23 Wartbarkeit System 215 Anhang C Dokumente zum Softwarepraktikum Dieser Anhang umfasst Dokumente zum Softwarepraktikum das die Abteilung Soft ware Engineering im Sommersemester 2001 im Studiengang Softwaretechnik durch gef hrt hat Abschnitt C 1 enth lt die Aufgabenstellung Abschnitt C 2 eine Aufstel lung der Anforderungen als Grundlage des Kunden Betreuers f r die Kundenbe
360. terium die Metriken und Fra geb gen erhoben und aus diesen f r jedes Kriterium Bewertungsvorschl ge f r die subjektive Metrik abgeleitet Der Bewerter bestimmt dann die Werte f r die subjekti ven Metriken Aus den subjektiven Metriken der Kriterien werden dann die subjekti ven Metriken f r die Faktoren bestimmt und aus diesen wiederum die subjektive Metrik f r die Gesamtqualit t Anschlie end wird f r die n chsth here Ebene die Pakete das Verfahren wiederholt wobei in die subjektiven Metriken auch die jeweili gen Bewertungen der im Paket enthaltenen Klassen und Interfaces einflie en Schlie lich wird das Verfahren auf der obersten Ebene System wiederholt wobei die sub jektiven Metriken auch die subjektiven Bewertungen der Pakete ber cksichtigen So entsteht schlie lich eine Bewertung der Gesamtqualit t des Systems Qualit tsattribut A Gesamtqualitat WW gt gt A A A Faktor R gt gt A A Kriterium gt gt z Klasse Interface Paket System Ebene Abbildung 9 2 Aggregation bei der Bewertung Eine einzelne Qualitatskennzahl als Ergebnis des gezeigten Aggregationsprozesses ist allerdings mit Vorsicht zu genie en da zwischen den Qualit tskriterien h ufig Abw gungen notwendig sind Boehm et al 1978 So kann z B die Knappheit h ufig nur auf Kosten anderer Kriterien gesteigert we
361. tieren Booch et al 1998 Pakete sollen nicht zu tief verschachtelt sein Booch et al 1998 Die Anzahl der in einem Paket enthaltenen Elemente soll im Vergleich zu den anderen Paketen im System weder zu gro noch zu klein sein Booch et al 1998 Zwischen Paketen soll es keine zyklischen Abhangigkeiten geben Treten diese auf soll eines der Pakete zerschlagen werden um den Zyklus aufzul sen Martin 1996e Heuristiken fir Vererbungsbeziehungen Vererbungshierarchien sollen balanciert sein nicht tiefer als etwa funf Stufen und nicht zu breit Um die Breite zu reduzieren k nnen zur Gruppierung abstrakte Zwischenklassen in die Vererbungshierarchie eingef gt werden Booch et al 1998 Vererbung soll nur verwendet werden um eine Spezialisierungshierarchie zu modellieren Riel 1996 Basisklassen sollen abstrakt sein Riel 1996 Mehrfachvererbung soll zun chst als Entwurfsfehler angesehen werden bis das Gegenteil bewiesen ist Riel 1996 Heuristiken f r sonstige Beziehungen Benutzungsbeziehungen sollen nur verwendet werden wenn es sich nicht um eine strukturelle Beziehung handelt Ansonsten soll mit Assoziationen gearbeitet werden Booch et al 1998 Bei Aggregation soll eine Klasse wissen was sie enth lt aber sie soll nie wissen wer sie ent h lt Riel 1996 Eine Klasse soll von m glichst wenigen anderen Klassen abh ngen Korson McGregor 1990 Tabelle 7 4 Heuri
362. tiven Modelle sind dabei klar in der berzahl ein typisches Ph nomen in der Software Entwicklung 2 2 Metriken I often say that when you can measure what you are speaking about and express it in num bers you know something about it but when you cannot measure it when you cannot express it in numbers your knowledge is of a meagre and unsatisfactory kind it may be the beginning of knowledge but you have scarcely in your thoughts advanced to the stage of science what ever the matter may be William Thomson Lord Kelvin Lecture to the Institution of Civil Engineers 03 05 1883 2 2 1 Definition In der Mathematik ist eine Metrik ein Abstandsma Im Software Engineering wurde der Begriff Metrik metric verallgemeinert auf beliebige Ma e der Software Entwick lung Die Definition des IEEE lautet die Definition im ISO Standard 9126 ist hnlich Definition 2 1 metric IEEE Std 610 12 1990 A quantitative measure of the degree to which a system component or process possesses a given attribute Fenton Pfleeger 1996 und Dumke 2000 unterscheiden drei Arten von Metriken e Metriken f r Produkte z B Gr e der Spezifikation und Korrektheit des Codes e Metriken f r den Entwicklungsprozess z B Aufwand und Dauer und e Metriken f r eingesetzte Ressourcen z B Gr e des Entwicklungsteams Da es in dieser Arbeit um die Entwurfsbewertung geht und der Entwurf ein Produkt der Software Entwicklung ist werden im F
363. tret bar und kann durch Werkzeugunterst tzung stark reduziert werden vi Abstract Abstract Design plays a pivotal role in software development It strongly influences the subse quent implementation and maintenance phases Implementation and maintenance taken together take more than two thirds of the entire effort therefore it makes good sense to strive for high design quality As it is difficult to create a good design straight away quality assurance in the form of design assessment is needed The assessment serves to determine the design quality and to uncover weaknesses in the design it may also be used for comparing design alternatives This thesis focuses on object oriented design The foundation of the design assess ment is a quality model As quality requirements differ for different projects the qual ity model should be adapted to the actual context Therefore a general quality model called Quality Model for Object Oriented Design QOOD is introduced from which specific quality models can be derived that are adapted to the concrete quality requirements In order to reduce assessment cost extensive automation is useful That however requires a formal representation of the design As the Unified Modeling Language UML is the standard for notating object oriented designs and as it is sufficiently for mal a reference model called Object Oriented Design Model ODEM was developed that is based on the UML metamodel As UML
364. tructuredness self descriptiveness conciseness understandability Lean legibility modifiability Lt EE augmentability Abbildung 6 2 Qualitatsmodell von Boehm et al U YA 6 2 Qualit tsmodelle 65 Boehm et al Das Qualit tsmodell von Boehm et al 1978 ist in Abbildung 6 2 dargestellt Die Fak toren sind in drei Kategorien eingeteilt Portabilit t Brauchbarkeit und Wartbarkeit Die Portabilit t enth lt nur sich selbst als Faktor die beiden anderen Kategorien haben jeweils drei Faktoren Jedem Kriterium sind Code Metriken f r Fortran zuge ordnet die vor allem Anomalien aufdecken sollen Der Schwerpunkt liegt auf der Entwicklersicht nur die Kategorie Brauchbarkeit geh rt zur Benutzersicht McCall et al McCall et al 1977 Cavano McCall 1978 unterscheiden wie Boehm et al 1978 drei Kategorien Anwendung nderung und Portierung Die Kategorien korrespondieren mit den typischen Arbeiten mit und an Software Die Faktoren werden jeweils einer dieser drei Kategorien zugeordnet vgl Abbildung 6 3 Die Kategorie Anwendung entspricht der Benutzersicht w hrend die anderen beiden Kategorien zur Entwickler sicht geh ren product operations ee traceability f correctness G d completeness Ne NE consistency reliability Ge accuracy error tolerance efficiency aay 4 execution efficiency storage efficiency
365. trukturierung anderer Pakete A p if NCP p NIP p gt 0 then NCP p NIP p NCP p NIP p else 1 Instability I Die Instabilit t eines Pakets ist definiert als das Verh ltnis efferenter Kopplung zur gesamten Kopplung Der Spezialfall eines Pakets ohne Kopplung nach au en von Martin nicht erw hnt soll eine Instabilit t von 0 haben Ip if C p Celp gt 0 then Celp C p Ce p else 0 Distance from the Main Sequence D Die Hauptlinie main sequence ist Teil einer Theorie von Martin dass die Abstraktheit A und die Instabilit t I eines Pakets ungef hr gleich sein sollten d h reine Abstraktionen sollten sehr stabil sein w h rend sich konkrete Implementierungen ndern d rfen Je weiter ein Paket von der Hauptlinie ausgedr ckt durch die Gleichung A I 1 entfernt ist desto schlechter Es gibt auch eine normalisierte Variante D die im Intervall 0 1 liegt 5 5 Formale Definition von Metriken 57 D p A p I p 11 2 D p A p I p 1 2 D p Fazit Martins Metriken konzentrieren sich auf Elemente des Architekturentwurfs weshalb sie mit ODEM leicht formalisiert werden k nnen Es gibt ein paar L cken und Unklarheiten in den urspr nglichen nat rlichsprachlichen Definitionen die bei der Formalisierung durch sinngem e Erg nzungen berwunden werden k nnen Fallstudie 2 Chidamber und Kemerers Metrikensuite Chidamber und Kemerer waren 1991 eine der ersten die
366. tsmodell vor Nach Auffassung von Rombach 1993 sind generische Modelle zu allgemein als dass sie wirklich verwendet werden k nnten Auf jeden Fall muss eine Anpassung an den konkreten Bedarf erfolgen Diese Anpassung wird dadurch erschwert dass ein gene risches Modell das alle m glichen Anwendungen abzudecken soll gro und un ber sichtlich wird Das Modell muss vor einer Anpassung zun chst verstanden werden wobei durch die Gr e die Aufmerksamkeit vom Wesentlichen ablenkt werden kann Die gro e Breite der generischen Modelle hat allerdings den Vorteil dass auf alle Aspekte aufmerksam gemacht wird die ber cksichtigt werden k nnten Dagegen haben Vorgehensmodelle den Vorteil dass direkt ein f r den eigenen Bedarf passendes Qualit tsmodell entsteht w hrend bei generischen Modellen zun chst eine Anpassung vorzunehmen ist Allerdings ist es in der Regel einfacher etwas Vor handenes anzupassen als etwas v llig Neues zu schaffen Das Ergebnis der Anpas sung ist zwar meistens nicht so vollkommen wie eine Spezialanfertigung doch ist der Aufwand bei der Anpassung geringer Daher wird in dieser Arbeit der Ansatz des generischen Qualit tsmodells verfolgt vgl Abschnitt 7 2 3 Die in Abschnitt 6 2 2 gezeigten Qualit tsmodelle sind Modelle f r Softwarequalit t im Allgemeinen k n nen also nicht direkt zur Entwurfsbewertung verwendet werden Allerdings k nnen sie als Ausgangspunkt f r die Entwicklung eines Qualit tsmodells f r
367. ttributnamen in die Check liste eingesetzt Durch die Checklisten sollen Bereiche abgedeckt werden die nicht automatisch mit design critics gepr ft werden k nnen Nenonen et al 2000 Das Werkzeug MAISA arbeitet auf UML Modellen Dabei werden sowohl Klassendiagramme als auch Kollaborations Sequenz Zustands und Aktivit tsdiagramme verarbeitet d h es werden statische und dynamische Eigenschaften ausgewertet Das Werkzeug kann fest eingebaute Metriken erheben geplant ist auch die Erkennung von Entwurfsmustern und Anti Mustern Die Ana lyse arbeitet dabei auf einem FAMIX Modell und einer Prolog Wissensbasis die durch externe Werkzeuge aus einem UML Modell generiert wurden Aus dem Ange bot vordefinierter Metriken k nnen die gew nschten ausgew hlt sowie obere und untere Schwellenwerte f r sie angegeben werden Messwerte au erhalb der Schwel lenwerte werden dann bei der Ausgabe speziell gekennzeichnet 11 1 2 Qualit tsbewertung auf Codebasis Ein gro er Teil des Entwurfs kann aus dem Code extrahiert werden Einiges an Ent wurfsinformation ist zwar verloren gegangen z B ist die Unterscheidung zwischen Assoziation Aggregation und Komposition nicht mehr aus dem Code ersichtlich aber andererseits ist mehr detaillierte Information verf gbar z B Methoden ihre Aufrufbeziehungen und Zugriffe auf Attribute Beim Reengineering ist Code h ufig das einzig verf gbare Dokument aus dem Entwurfsinformation gewonnen werden kann
368. tur und Komponentenentwurf eher parallel als sequentiell da beim Komponentenentwurf haufig Fehler oder Schwachen im Archi tekturentwurf identifiziert werden insbesondere m ssen h ufig andere Komponen ten angepasst werden mit denen die Komponente interagieren soll 4 2 3 Abstraktionsebenen Anhand des Abstraktionsgrads des Entwurfs kann zwischen logischem und physi schem Entwurf unterscheiden werden Logischer Entwurf Der logische Entwurf abstrahiert vom konkreten Kontext der geplanten Implementie rung z B der Plattform Rechner Betriebssystem Netzwerke und anderen Syste men mit denen das System interagieren soll z B Datenbank Middleware Auf diese Weise entsteht ein implementierungsneutraler Entwurf der in dieser Form nicht direkt implementierbar ist Physischer Entwurf Die Br cke vom logischen Entwurf zur Implementierung schl gt der physische Ent wurf Die im logischen Entwurf offen gelassenen Realisierungsentscheidungen wer den auf der Basis von Anforderungen durch Kunden und Management Kostenaspek ten z B Anschaffungs und Betriebskosten Einarbeitungszeit der Entwickler und Benutzer und Effizienz berlegungen Laufzeit und Speicherbedarf gef llt Der Vorteil der Irennung zwischen logischem und physischem Entwurf ist dass sich der Entwerfer zun chst keine Gedanken um Implementierungsprobleme und Effizi enz machen muss sondern sich auf die Aufteilung der Funktionalit t auf Komponen ten konzentrieren
369. turiertheit Die Fragen besch ftigen sich mit der Pakethierarchie und der Vererbungshierarchie Klasse Interface Bedingung Fragetext Antwortskala Gewicht auto Ist die Klasse in der Vererbungshierarchie h chs 0 nein ex v tens 6 Stufen tief 1 ja Hat die Klasse h chstens 9 Unterklassen 0 nein ee v 1 ja NAEC this Hat die Klasse nur eine Unterklasse aber es gibt 0 nein S 1 keinen Sinn die beiden zu verschmelzen 1 ja Hat die Klasse keine Unterklassen die eigentlich 0 nein A Instanzen der Klasse sein sollten 1 ja Fragebogen B 4 Strukturiertheit Klasse Interface 206 B Frageb gen f r QOOD Paket Bedingung Fragetext Antwortskala Gewicht auto DNHPi this Ist das Paket h chstens 6 Stufen tief eingeschach 0 nein S v gt 0 telt 1 ja Ist das Paket weder leer noch enth lt es nur sehr 0 nein Zx v wenige ein oder zwei Elemente 1 ja Enth lt das Paket h chstens 30 Elemente 0 nein FR v 1 ja Enth lt das Paket h chstens 9 Pakete 0 nein am v 1 ja Fragebogen B 5 Strukturiertheit Paket System Bedingung Fragetext Antwortskala Gewicht auto Ist die Schachtelungshierarchie der Pakete h chs 0 nein er v tens 6 Stufen tief 1 ja Sind die Abstraktionen hoch in der Vererbungs 0 nein Eur hierarchie stabil d h sie werden sich wahr 1 ja scheinlich nicht ndern Sind
370. tzen sich aus Kriterien zusammen die wiederum auf Metriken aufbauen 8 2 1 Faktoren Faktoren stehen f r die Eigenschaften des Systems die vorhergesagt werden sollen Der wichtigste Faktor des Modells ist die Wartbarkeit vgl Abschnitt 8 1 5 Dar ber hinaus gibt es die Faktoren Wiederverwendbarkeit Wiederverwendung Brauchbar keit Testbarkeit und Pr fbarkeit vgl Abschnitt 8 3 und die folgenden Weitere Fak toren sind denkbar wurden jedoch nicht aufgenommen weil ihre Bewertung auf der Basis von ODEM schwierig ist vgl Abschnitt 8 9 Die Faktoren repr sentieren relativ 8 3 Wartbarkeit 105 unabh ngige Module des Modells Dies erleichtert die Anpassung des Modells bei der Ableitung eines spezifischen Qualit tsmodells 8 2 2 Kriterien Die Kriterien stehen f r Entwurfseigenschaften Bei der Auswahl der Kriterien eines Faktors sind die folgenden Anforderungen ausschlaggebend e Relevanz Alle Kriterien sollen f r den Faktor von hoher Bedeutung sein e Verst ndlichkeit Es sollen m glichst wenige Kriterien verwendet werden Au er dem soll die Zahl der Hierarchiestufen gering sein um berschaubarkeit zu gew hrleisten e berdeckung Die Kriterien sollen m glichst viele Aspekte des Faktors abdecken e Unabh ngigkeit Die Kriterien sollen sich so wenig wie m glich berlappen e Bewertbarkeit Die Kriterien sollen m glichst objektiv bewertbar sein Die Faktoren und Kriterien wurden so gew hlt dass ein hoher
371. uch wenn Bosch darauf nicht eingeht sind auch Ent wurfsmetriken oft vergleichsweise primitive mathematische Modelle eines Ent wurfs Die Vor und Nachteile dieses Ansatzes sind hnlich wie bei der Simulation Evaluation aufgrund von Erfahrung Dieser ganzheitliche Ansatz baut vor allem auf der Erfahrung von Entwurfsexperten auf Diese haben schon viele gute und schlechte Erfahrungen gemacht die sie auch in Form von Intuition in die Entwurfsbewer tung einbringen k nnen Ergebnis einer solchen Bewertung sind vor allem Hinweise auf m gliche M ngel im Entwurf und daraus abgeleitete Verbesserungsvorschl ge Werden diese Ergebnisse genauer untersucht l sst sich meist durch logische Beweis f hrung nachvollziehbar machen warum die Hinweise auf M ngel tats chlich gerechtfertigt sind Alternativ k nnen auch die drei anderen Bewertungsans tze ver wendet werden um das identifizierte potentielle Problem zu untersuchen Der Vorteil dieses Verfahrens besteht in der ganzheitlichen Betrachtungsweise und in der Nutzung der Erfahrung langj hriger Entwerfer Letzteres setzt aber voraus dass ein solcher Entwerfer verf gbar ist und seine Erfahrung etwas taugt Fehlt der Experte besteht die Gefahr dass der Ansatz wenig effektiv ist Das gilt auch dann wenn der Entwerfer seinen Entwurf selbst pr ft wegen kognitiver Dissonanz Die Expertenbewertung ist subjektiv und kaum nachvollziehbar die Ergebnisse k nnen allerdings nachtr glich na
372. ultiplizit ten Gibt es nur n tige Benutzungsbeziehungen 0 nein SS Kriterium z B Law of Demeter Lieberherr etal 1 ja 1988 1989 Realisiert die Klasse kein Interface das bereits 0 nein ae Y von einer Oberklasse realisiert wird 1 ja Gibt es keine Abh ngigkeit zu konkreten Klassen 0 nein v 1 ja Gibt es keine Abh ngigkeit zu einer direkten oder 0 nein ne Y indirekten Unterklasse 1 ja Gibt es keine Assoziation mit einer anderen 0 nein ee v Klasse welche die betrachtete Klasse enth lt 1 ja durch Aggregation oder Komposition Gibt es keine Assoziation der Klasse zu einer 0 nein 8 v anderen Klasse A wobei beide Klassen von einer 1 ja Klasse B aggregiert komponiert werden Gibt es keine zyklischen Abhangigkeiten mit 0 nein er Y anderen Klassen 1 ja Ist bei einer bidirektionalen Assoziation die Navi 0 nein gierbarkeit in beide Richtungen n tig 1 ja Liegt bei einer bidirektionalen 1 1 Assoziation 0 nein BER eine echte Assoziation vor 1 ja Kriterien Verbindung ist in eine oder beide Rich tungen optional oder kann sich ndern es han delt sich um zwei umfangreiche Klassen oder sie besitzen eine unterschiedliche Semantik Handelt es sich bei einer Aggregation um eine 0 nein SER echte Aggregation 1 ja Kriterien Teil Ganzes Beziehung aber der Teil kann mehrere Besitzer gleichzeitig haben oder den Besitzer wechseln Fragebogen B 7 Entkopplung Klas
373. ulung und Personaleinsatz einschlie lich externe Kr fte e Wartbarkeit des Entwurfs seiner Dokumentation und des resultierenden Systems vor allem Anderbarkeit und Erweiterbarkeit im Hinblick auf zu erwartende Ande rungen der Anforderungen und der Implementierungstechnologie e Wiederverwendung vorhandener Entw rfe und Komponenten e potentielle Wiederverwendbarkeit und tats chliche Wiederverwendung des Ent wurfs und des resultierenden Systems in anderen Systemen e weitgehende bereinstimmung mit Entwurfsregeln Prinzipien und Heuristiken e Einhaltung von Standards z B Standardnotationen Namenskonventionen Doku mentenvorlagen und Technologievorgaben 8 1 Vor berlegungen 103 8 1 4 Indikatoren We cannot build high level quality attributes like reliability or maintainability into software What we can do is identify and build in a consistent harmonious and complete set of product properties such as modules without side effects that result in manifestations of reliability and maintainability We must also link these tangible product properties to high level quality attributes Dromey 1996 S 33 Die eigentlich interessanten Eigenschaften des entworfenen Systems z B Effizienz oder Wartbarkeit lassen sich erst aus der Realisierung heraus zuverl ssig bewerten In der Entwurfsphase ist man daher auf Indikatoren angewiesen die sich aus dem Entwurf heraus erheben lassen z B Kopplung Deshalb konzentriert sich d
374. ung 2 nderung 3 Unterschiedliche Fahrpl ne f r Werktage und Wochenende Bisher ist der Fahrplan f r alle Tage gleich Soll aber zwischen Werktagen und Wochenende unterschieden werden sind jeweils zwei Datens tze f r die Anfahrtszei ten an den Endhaltestellen notwendig Die Fahrplandatei wird dazu entsprechend erweitert Au erdem muss die Verbindungsanfrage auch das Datum der gesuchten Verbindung abfragen um feststellen zu k nnen welcher Fahrplan gilt Von dieser nderung sind potentiell betroffen e das Einlesen und Speichern der Fahrplandatei e die internen Datenstrukturen zur Repr sentation des Fahrplans e die Verbindungssuche und ihre Datenstrukturen e die Benutzungsoberfl che zur Verbindungsanfrage e die Benutzungsoberfl che zur Anzeige der Fahrplandaten sowie e die Benutzungsoberfl che zum Neuanlegen einer Linie und zur nderung der Abfahrtszeiten Die meisten Klassen m ssen beim schlechtesten Entwurf ge ndert werden Beim bes ten und beim mittleren Entwurf sind es gleich viele Klassen doch sind es beim besten Entwurf weniger Attribute und Operationen die zu ndern sind Dies liegt vor allem an der Realisierung der Benutzungsoberfl che Tabelle 10 9 zeigt den Wartungsauf wand f r diese nderung bei den drei Entw rfen Gruppe 1 Gruppe 3 o Gruppe 7 Tabelle 10 9 Wartungsaufwand fiir Anderung 3 148 10 Ein spezifisches Qualit tsmodell Ergebnis Tabelle 10 10 zeigt den Wartungs
375. ung 9 4 Checkliste von Page Jones Ausschnitt Die Fragen k nnen fast alle mit ja oder nein beantwortet werden doch bis man zu einer Antwort gelangt kann wenig Aufwand z B Frage 13 oder viel Aufwand z B Frage 46 notwendig sein Die Antwort auf Frage 51 schlie lich kann letztendlich nur eine Implementierung liefern Bei dem gezeigten Beispiel handelt es sich nicht um eine klassische Checkliste denn die Punkte 7 und 48 enthalten Fragen die nicht mit ja oder nein beantwortbar sind Dennoch k nnen diese Fragen wertvolle Hinweise auf m gliche Probleme im Ent wurf liefern z B weist die Frage nach den wahrscheinlichsten nderungen und 128 9 Quantifizierung des Qualit tsmodells ihren Konsequenzen im Entwurf auf Probleme bei der adaptiven Wartung hin Aller dings ist gerade diese Frage kaum auswertbar weil kein Hinweis darauf gegeben wird wie die Antwort als Aussage zur Qualit t zu interpretieren ist In dieser Arbeit wird zur besseren Unterscheidung anstelle des Begriffs Checkliste der allgemeinere Begriff Fragebogen verwendet wenn es sich nicht um eine klassische Checkliste handelt 9 4 1 Anforderungen Nach W rthele 1995 S 60ff soll eine gute Checkliste und damit auch ein Fragebo gen die folgenden Eigenschaften besitzen e kurz um nicht von der Verwendung abzuschrecken Gilb 1988 empfiehlt auf grund praktischer Erfahrung nur Checklisten zu verwenden die auf eine Seite passen also maximal 25
376. ung des Gesamtbildes f hren 9 3 2 Beschreibung Das Akronym einer subjektiven Metrik setzt sich aus einem S f r subjective und einem zweistelligen K rzel f r das Kriterium zusammen vgl Tabelle 9 2 Am Schluss steht ein C f r class P f r package oder S f r system analog zu den objekti ven Metriken Beispielsweise steht SSTC f r subjective structuredness of a class F r die Erhebung der Metriken wird eine Intervallskala mit zehn Werten eingesetzt die einen Bereich von 0 sehr schlecht bis 9 sehr gut abdecken Die Wahl des Werte bereichs ist ein Kompromiss zwischen den Anforderungen einer m glichst gro en M glichkeit zur Differenzierung und einer trotzdem noch berschaubaren Anzahl an Skalenpunkten Bewertungsskalen mit 10 Punkten sind au erdem relativ h ufig Bewerter sind also gewohnt damit umzugehen 126 9 Quantifizierung des Qualit tsmodells Kurzel Kriterium CC conciseness Knappheit CO cohesion Zusammenhalt CS consistency Einheitlichkeit DC decoupling Entkopplung DO documentation Dokumentierung MA maintainability Wartbarkeit ST structuredness Strukturiertheit TR traceability Verfolgbarkeit Tabelle 9 2 K rzel f r die Kriterien und Faktoren 9 3 3 Beispiel Die vollst ndige Definition von SSTC sieht wie folgt aus SSTC subjective structuredness of a class SSTC c Beurteilen Sie die Strukturiertheit der Klasse c auf der folgenden Skala 0
377. ung des Qualit tsmodells Normierung Jede Metrik wird auf den Wertebereich 0 1 normiert Ein hoherer nor mierter Wert steht dabei fiir eine h here Qualit t Daher ist bei der Normierung dar auf zu achten ob die Metrik positiv oder negativ mit dem Kriterium korreliert ist Die Normierung beruht auf einem Schwellenwert S mit einer Toleranz T Die Auswertung von Metriken durch Schwellenwerte ist die einfachste Art einer Wer tung daher wird in der Literatur davon in hohem Ma e Gebrauch gemacht z B bei der Ausrei eranalyse Eine h ufige Kritik bei Schwellenwerten ist aber dass man oft Argumentationsschwierigkeiten bekommt warum ein Wert gleich dem Schwellen wert gut ein Wert leicht ber dem Schwellenwert aber schlecht sein soll Daher wurde hier zus tzlich eine Toleranz eingef hrt mit welcher der abrupte bergang abgemildert wird also die eigentlich vorhandene Unsch rfe in der Bewertung besser repr sentiert werden kann Durch die Wahl einer Toleranz von 0 kann allerdings explizit auf diese Erweiterung verzichtet werden Bei negativ korrelierten Metriken sollen Werte unterhalb des Schwellenwerts einen hohen normierten Wert ergeben Werte oberhalb des Schwellenwerts einen niedrigen Die Toleranz legt die Art des bergangs zwischen der bestm glichen und der schlechtestm glichen Bewertung fest Ist die Toleranz T gr er 0 werden alle Werte kleiner oder gleich S T auf 1 normiert alle Werte gr er S T auf 0 und die dazwi
378. urf st t man h ufig auf mehrere Alternativen unter denen auszuw hlen ist Das folgende Beispiel basierend auf einem Beispiel von Fowler et al 1999 zeigt dass es bei der Entscheidung welcher Entwurf f r ein gege benes Problem der beste ist viele Kriterien zu ber cksichtigen gibt und dass diese Kriterien im Widerstreit zueinander stehen k nnen Ein Videoverleih soll ein System zur Rechnungsstellung erhalten Kunden Ausleihen und Filme werden durch Klassen modelliert Customer Rental Movie Der Kunde hat 74 7 Entwurfsqualitat Ausleihen w hrend die Ausleihe Informationen ber den ausgeliehenen Film und die Leihdauer in Tagen hat Ein Film hat einen Preiscode der zusammen mit der Leihdauer den Preis bestimmt Es gibt Preiscodes fiir normale Filme regular Kinder filme children s und Neuerscheinungen new release Der Preiscode eines Films kann sich ndern z B von new release nach regular daher gibt es in Movie eine Operation setPriceCode Erste Stufe Entkopplung und Kapselung Entwurf A vgl Abbildung 7 1 sieht vor den Rechnungsbetrag in der Klasse Cus tomer zu berechnen und dazu die erforderliche Information bei Rental und Movie ein zuholen Customer holt sich in der Methode statement von Rental die Ausleihdauer und den Film von diesem wiederum den Preiscode vgl Abbildung 7 2 priceCode int daysRented int getPriceCodeg int getDaysRented int 7 getMovied Movie
379. usam menhalt Ein guter Entwurf sucht also nach der richtigen Balance zwischen Knapp heit auf der einen Seite Entkopplung und Zusammenhalt auf der anderen Seite Reduktion also eine Vereinfachung ohne Verlust an anderen Qualit ten ist immer erstrebenswert h ufig f hrt sie auch zu mehr Eleganz Allerdings ist die Reduktion oft teuer da sie viel Kreativit t und Arbeit erfordert Mies van der Rohes Wahlspruch So einfach wie m glich koste es was es wolle ist daher nur dann sinnvoll wenn die Kosten keine Rolle spielen Andernfalls ist absolute Knappheit unwirtschaftlich Die Vermeidung von Redundanz ist ein spezieller Aspekt der Knappheit Redundanz freiheit ist besonders wichtig f r die Wartbarkeit da bei vorhandener Redundanz z B durch Copy and Paste Programming Brown et al 1998 immer alle Kopien ge ndert werden m ssen Burd Munro 1997 Dazu m ssen diese Kopien erst einmal gefunden und dann konsistent ge ndert werden Das ist viel fehleranf lliger als wenn die nderung auf eine Stelle beschr nkt w re 8 3 2 Strukturiertheit The only problems we can really solve in a satisfactory manner are those that finally admit a nicely factored solution Dijkstra 1972 Definition Die Strukturiertheit ist hoch wenn die Struktur des Entwurfs von einem Menschen leicht berblickt und erfasst werden kann Laut Melton et al 1990 sind die psycholo gische d h die wahrgenommene Komplexit t und die strukturelle Kompl
380. verschiedene Perspektiven gepr gt 1 Zeitliche Perspektive kurz oder langfristig 2 Interessengruppe Kunde Anwender Entwickler Projektmanager oder Projekt eigent mer 3 Qualit tssicht transzendent produktbezogen benutzerbezogen herstellungsbezo gen oder kostenbezogen Es ist praktisch nicht m glich f r jede dieser Perspektiven alle M glichkeiten in einem einzigen allgemeinen Modell zusammenzubringen Stattdessen ist es sinnvol ler eine Menge spezifischer Qualit tsmodelle zu erstellen Di mann 1990 7 2 1 Zeitliche Perspektive A sign that the Software Engineering profession has matured will be that we lose our preoccu pation with the first release and focus on the long term health of our products Parnas 1994 S 279 Die Kriterien nach denen ein Entwurf bewertet wird hangen davon ab ob eine kurz oder eine langfristige Perspektive eingenommen wird Die kurzfristige Perspektive betrachtet wie schwierig es ist den Entwurf gemafs den Anforderungen zu erstellen und zu realisieren Die langfristige Perspektive hingegen betrachtet die Entwurfsqua lit t ber die gesamte Lebenszeit der Software hinweg Der Entwurf wird zwar am Ende der Lebenszeit nicht mehr derselbe sein da er oft berarbeitet werden wird Doch wird bei einem guten Entwurf viel von der urspr nglichen Struktur erhalten bleiben In der Regel ist die langfristige Perspektive auch aus konomischer Sicht f r alle Interessengruppen die vern
381. viele Para meter haben auch keine Sofern eine Operation eine R ckgabe hat wird diese durch einen Pseudoparameter in der Parameterliste repr sentiert der speziell gekennzeichnet ist siehe Abschnitt 5 3 7 Falls es zwischen zwei Modellelementen Assoziationen verschiedener Art gibt wird das Attribut aggregation mit der st rksten Assoziationsart belegt d h composite vor aggregate vor none Die Alternative w re die Einf hrung drei verschiedener Relationen und einer zusammenfassenden Relation Dies erscheint hier allerdings berdimensioniert weshalb die Ungenauigkeit im oben genannten Spezialfall in Kauf genommen wird 52 5 Ein Referenzmodell fur den objektorientierten Entwurf Die Komposition von Parameter in BehavioralFeature der Oberklassen von Opera tion kann als Relation ausgedr ckt werden has o p gilt genau dann wenn es eine Instanz der Komposition gibt bei der die Rolle type mit o und die Rolle parameter mit p belegt ist 5 3 7 Parameter M ist die Menge aller Parameter von Operationen Attribute e name Name Der Name des Parameters e kind ParameterDirectionKind Die Art des Parameters in out inout return in out und inout stehen f r die Richtung der Parameter bergabe beim Aufruf analog zur Programmiersprache Ada vgl ISO IEC 8652 1995 S 123ff return kennzeich net den Pseudoparameter f r die R ckgabe mit dessen Hilfe der R ckgabetyp modelliert wird e type Classifier Typ des Par
382. view B gen 9 4 3 Beispiel Die Gesamtheit der Frageb gen wird in Anhang B vorgestellt Das Aussehen eines Fragebogens wird hier am Beispiel des Kriteriums Knappheit auf der Ebene Klasse 2 Graduelle Antworten erlauben es zutreffendere Antworten zu geben f hren auf der anderen Seite aber auch zu einer geringeren Reproduzierbarkeit der Bewertung Daher kann man in einem spezi fischen Modell f r graduelle Fragen den Wertebereich der Skala einschr nken im Extremfall sogar eine bin re Antwort erzwingen 130 9 Quantifizierung des Qualit tsmodells Interface verdeutlicht vgl Abbildung 9 5 Da Knappheit geringe Gr e bedeutet enth lt der Fragebogen Fragen nach unn tigen und redundanten Entwurfsteilen Die Bedingungen der Fragen werden durch Pr dikate formalisiert Die Pr dikate k n nen einen impliziten Parameter this verwenden der den aktuellen Bewertungsgegen stand bezeichnet Die Gewichte weniger wichtig wichtig und sehr wichtig werden durch Sternchen visualisiert f r weniger wichtig f r wichtig und f r sehr wichtig Ist eine Frage automatisch beantwortbar wird in der letzten Spalte ein H k chen gesetzt Bedingung Fragetext Antwortskala Gewicht auto Ist das Vorhandensein der Klasse notwendig 0 nein Kee 1 ja thise C Enth lt die Klasse nur die n tigen Attribute 0 nein bie z B keine nicht mehr verwendeten oder f r die 1 ja Verantwortlichkeiten der Klasse nicht relevanten
383. vorkommt also sonst die Ergebnisse ver f lscht w rden 10 1 Ableitung des Qualitatsmodells 139 e H ufig sind in den Entw rfen Assoziationen nicht explizit angegeben Daher wer den diese Assoziationen aus den Attributen der Implementierung anhand der Attributtypen abgeleitet Die zur Implementierung von Assoziationen verwende ten Attribute werden nicht als echte Attribute gez hlt e Benutzungsbeziehungen sind in den Entw rfen kaum explizit angegeben Daher werden sie nur in den wichtigsten F llen anhand der Entwurfsdokumentation und der Implementierung wiederhergestellt e Die Namenskonvention f r Bezeichner des Entwurfs entspricht der aus den Java Code Conventions von Sun die f r die Implementierung vorgegeben waren vgl Abschnitt C 1 5 Auswahl der Metriken Da das in Kapitel 11 beschriebene Werkzeug zum Zeitpunkt der Erhebung noch nicht fertig war und auch die oben beschriebenen Z hlregeln nicht so leicht automatisch umzusetzen sind wurden die Daten von Hand erhoben Um den dadurch hohen Auf wand zu reduzieren wurden nur wenige Verfeinerungen der Metriken explizit erho ben Bei der Messung der Entkopplung von Paketen wurde die einfachere Alternative gew hlt nur die gekoppelten Pakete zu z hlen also die Kopplungsst rke in Form der Anzahl der Beziehungen nicht zu ber cksichtigen Tabelle 10 3 zeigt die tats chlich eingesetzten Metriken zusammen mit Schwellenwert und Toleranz Sofern verf gbar wurden die Schwell
384. w hrend Vorhersagemetriken eine Vor hersage f r eine andere Gr e z B die Wartbarkeit ableiten Die Zusammenh nge zwischen der vorhergesagten und der tats chlichen Gr e sind empirisch zu zeigen Kitchenham 1990 formuliert diese Anforderung an eine Vorhersagemetrik wie folgt 1 Die Eigenschaft die als Basis der Vorhersage dienen soll ist genau messbar 2 es gibt einen Zusammenhang zwischen dieser Eigenschaft und der vorherzusagen den Eigenschaft und 3 dieser Zusammenhang ist klar validiert und kann als Formel oder anderes Modell formuliert werden Gerade Anforderung 3 insbesondere die Validierung wird laut Kitchenham h ufig vergessen wenn Vorhersagemetriken vorgeschlagen werden Wendet man Anforderung 2 und 3 auf Qualit tsmetriken an muss also der Zusam menhang zwischen der Metrik und dem Qualit tsattribut vorhanden und nachweis bar sein Au erdem muss die Metrik die verschiedenen Grade des Attributs unter scheiden k nnen und auf eine geeignete Skala abbilden Gillies 1992 Bei der Auswahl von Qualit tsmetriken muss auch die Qualit tssicht desjenigen f r den die Qualit t gemessen werden soll ber cksichtigt werden Au erdem gilt f r die meisten Qualit tsattribute dass sie zu komplex sind um durch eine einzige Metrik erfasst werden zu k nnen Basili Rombach 1988 so dass mehrere Qualit tsmetriken f r ein Attribut verwendet werden sollten 2 2 4 Entwicklung von Metriken Shepperd und Ince 1
385. weise ist CCnac das Gewicht f r die Metrik NAC beim Kriterium Knappheit Der so entstehende Bezeichner ist eindeutig Transformation Der gewichtete Durchschnitt wird nun auf den Wertebereich der subjektiven Metrik 0 1 9 vgl Abschnitt 9 3 2 transformiert indem er mit 9 mul tipliziert wird Sinnvollerweise wird das Resultat nicht auf ganze Zahlen gerundet sondern auf die erste Nachkommastelle damit der Bewerter besser erkennen kann welche Tendenz der Vorschlag hat also z B 8 4 oder 7 6 statt 8 9 3 Subjektive Metriken Subjektive Metriken spiegeln die Einsch tzung eines Qualit tsattributs auf einer Ebene durch einen Bewerter wieder Die Erhebung der subjektiven Metriken kann nicht automatisch sondern nur von einem Bewerter vorgenommen werden Bei der Bewertung kann er sich auf die objektiven Metriken die Frageb gen und die subjekti ven Metriken untergeordneter Ebenen st tzen vgl Abschnitt 9 5 9 3 1 Anforderungen Der Wertebereich der Metrik soll eine m glichst hohe Differenzierung der Bewertung erlauben Gleichzeitig soll aber die Anzahl der Skalenpunkte m glichst gering sein um die Skala berschaubar zu halten Die Anzahl der Skalenpunkte sollte gerade sein um einen neutralen Mittelwert zu vermeiden Dieser wird erfahrungsgem besonders dann gew hlt wenn sich der Bewerter nicht entscheiden kann oder will ob die Bewertung eher positiv oder nega tiv ausfallen soll Dies kann aber zu einer Verf lsch
386. werden 12 2 Bewertung des Ansatzes 163 Die Beantwortung der Fragen der Frageb gen kann auch automatisiert werden sofern sich die Fragen formalisieren und auf der Basis von ODEM beantworten las sen Dies gilt aber nur f r einen Teil der Fragen denn vor allem semantische Fragen z B nach Zusammenhalt nach aussagekr ftigen Bezeichnern oder nach funktionaler Redundanz entziehen sich der Automatisierung Sofern auf alle Aspekte verzichtet wird die sich nicht automatisieren lassen kann aus QOOD ein spezifisches Modell entwickelt werden das sich f r eine vollautomatische Bewertung eignet Dieses wird sich allerdings vor allem auf die Bereiche Knappheit Strukturierung und Entkopplung beschr nken m ssen Damit sind zwar einige der wichtigsten Kriterien der Wartbarkeit abgedeckt doch fallen andere wichtige Krite rien wie Zusammenhalt oder Dokumentierung faktisch weg 12 2 4 Kosten und Nutzen Qualit tssicherung beim Entwurf verursacht Kosten Wird der vorgestellte Ansatz zur Entwurfsbewertung verwendet muss zun chst ein spezifisches Qualit tsmodell abgeleitet werden Dann ist die Bewertung durchzuf hren Der Zeitaufwand f r die Ableitung des spezifischen Qualit tsmodells ist nur einmal zu leisten w hrend der Aufwand f r die Bewertung f r jede Bewertung erneut anf llt Deshalb ist Werkzeug unterst tzung bei der Bewertung wichtig Der Nutzen des Ansatzes besteht darin bereits fr h in der Entwicklung R ckkopp lung
387. werden Daher ist eine Quantifizierung des Qualit tsmodells anzustreben Abw gungen zwi schen verschiedenen Attributen k nnen in Form von Gewichten dargestellt werden mit denen die einzelnen Bewertungen zu einer Gesamtbewertung verrechnet werden Zur Quantifizierung werden Metriken eingesetzt Die schwierige Frage ist wie sich die Qualit tsattribute mittels Metriken messen lassen Es m ssen f r jedes Attribut eine oder mehrere Metriken gefunden werden die mit dem Attribut korreliert sind Au erdem ist zu entscheiden was genau gemessen wird beispielsweise ob man geerbte Eigenschaften mitz hlt oder nicht 101 Kapitel 8 Das allgemeine Qualitatsmodell Im diesem und im folgenden Kapitel wird ein allgemeines Qualit tsmodell f r den objektorientierten Entwurf namens QOOD Quality Model for Object Oriented Design vorgestellt Der Name QOOD auszusprechen wie could hat absichtlich einen Anklang an das Wort good Das Modell soll n mlich dazu geeignet sein einen Entwurf zu bewerten d h seine G te festzustellen Es kann eine Antwort auf die Frage liefern ob ein gegebener Entwurf gut ist absolute Aussage bzw ob er bes ser ist als ein anderer Entwurf relative Aussage Dieses Kapitel f hrt die Qualit tsattribute Faktoren und Kriterien ein die in QOOD betrachtet werden sollen Au erdem werden die Beziehungen zwischen den Quali t tsattributen z B Korrelation Widerspruch diskutiert 8 1 Vor berlegun
388. wler M Avoiding Repetition IEEE Software 18 1 2001 97 99 Fowler 2001b Fowler M Reducing Coupling IEEE Software 18 4 2001 102 104 176 Literatur Fowler Scott 1997 Fowler M Kendall S UML Distilled Applying the Standard Object Modeling Language Addison Wesley Reading MA 1997 Fowler et al 1999 Fowler M Beck K Brant J Opdyke W Roberts D Refactor ing Improving the Design of Existing Code Addison Wesley Reading MA 1999 Fr hauf et al 2000 Fr hauf K Ludewig J Sandmayr H Software Projektman agement und Qualit tssicherung 3 Auflage vdf Z rich 2000 Fujino 1999 Fujino T Traditional Japanese Architecture Blends Beauty and Ratio nale IEEE Software 16 6 1999 101 103 Gamma et al 1995 Gamma E Helm R Johnson R Vlissides J Design Patterns Elements of Reusable Object Oriented Software Addison Wesley Reading MA 1995 Garvin 1984 Garvin D What Does Product Quality Really Mean Sloan Manage ment Review 25 3 1984 25 43 Garvin 1988 Garvin D Managing Quality The Strategic and Competitive Edge Free Press New York 1988 Gelernter 1998 Gelernter D Machine Beauty Elegance and the Heart of Technol ogy BasicBooks New York 1998 Genero et al 2000 Genero M Piattini M Calero C Early Measures for UML Class Diagrams L Objet 6 4 2000 489 515 Gibbon 1997 Gibbon C Heuristics for Object Oriented Design
389. y C error tolerance availibility understandability NF AIAZ ANA ON NN ease of learning AN usability operability communicativeness D en Bon resource economy correctability maintainability E expandability D TEE testability hardware independence D software independence C installability D reusability Abbildung 6 5 Qualit tsmodell im IEEE Standard 1061 1992 portability Zusammenfassung Die beiden ltesten Modelle sind nicht strikt hierarchisch weil es Kriterien gibt die in mehrere Faktoren eingehen Die neueren Modelle sind dagegen strikt hierarchisch weil sie so leichter zu verstehen und zu modifizieren sind Des Weiteren ist eine Ver schiebung des Schwerpunkts der Qualit tsmodelle was die Anzahl der Faktoren angeht hin zu Faktoren der Benutzersicht zu beobachten Leider gibt es bei den gene rischen Modellen immer noch kein allgemein akzeptiertes Modell Wie man bei den Modellen der ISO IEC und des IEEE sieht bewegt man sich aufeinander zu doch bleiben die Faktoren und Kriterien in ihren konkreten Definitionen umstritten 68 6 Softwarequalitat 6 2 3 Vorgehensmodelle Beim Ansatz der Vorgehensmodelle wird kein Qualit tsmodell vorgegeben Stattdes sen wird eine Vorgehensweise angegeben mit der systematisch ein passendes Quali t tsmodell entwickelt wird Beispiele
390. z B zur Ermittlung der Leistung eines Transaktionsmonitors in einem Datenbanksystem Der Vorteil des Simulationsansatzes ist es dass handfestere Aussagen entstehen als beim Szenario Ansatz weil mehr und vor allem pr zisere Information hineingesteckt werden muss Au erdem kann die Simulation im g nstigsten Fall vollautomatisch durchgef hrt werden Dem steht allerdings der gravierende Nachteil gegen ber dass die Formalisierung des Entwurfs erzwungen wird was einen hohen Aufwand bedeu ten kann und Expertenwissen voraussetzt Die Formalisierung wiederum hat aller dings den Vorteil dass auf diese Weise L cken und unpr zise Beschreibungen im Entwurf viel eher auffallen Ein exploratives Prototyping gibt auch Hinweise zur Implementierbarkeit da die f r die Implementierung ben tigte Technologie in Form von Werkzeugen Middleware etc quasi mitgepr ft wird Evaluation durch mathematische Modellierung Wie die Simulation setzt die mathematische Modellierung auf die Formalisierung des Entwurfs oder eines Aus schnitts des Entwurfs Die mathematischen Modelle dienen aber mehr der statischen Analyse des Entwurfs Ein bekanntes Beispiel f r mathematische Modelle sind die Leistungsmodelle zur Absch tzung des Zeit und Platzbedarfs eines Algorithmus und die Einteilung in Leistungsklassen mit der O Notation Ein weiteres Beispiel ist die Analyse eines nebenl ufigen oder parallelen Systems auf Verklemmungsfreiheit ein Aspekt der Robustheit A
391. zen von Klassen Werden zwei Klassen miteinander ver schmolzen wird die Kopplung des Resultats h chstens so gro sein wie die Summe der Kopplungen der beiden Klassen Das liegt daran dass Beziehungen der beiden Klassen untereinander durch die Verschmelzung entfallen Interessanterweise ist die Aussage dieses Axioms die entgegengesetzte von W9 V P Q m P m Q 2 m P Q Axiom BDW5 Verschmelzen unverbundener Klassen Ein Spezialfall bei der Ver schmelzung von Klassen sind Klassen die keine Beziehungen untereinander haben Dann ist die Kopplung des Resultats gleich der Summe der Kopplungen der beiden Klassen V P Q P und Q haben keine Beziehungen miteinander gt m P m Q m P Q Untersuchung der Metriken Die Metriken fiir Entkopplung sind Kopplungsmetriken daher k nnen sie zus tzlich im Hinblick auf diese Axiome untersucht werden Das wird hier am Beispiel der Metrik NEDC Number of Efferent Dependencies of a Class demonstriert Axiom BDW 1 Das Axiom gilt denn der kleinstm gliche Wert einer Z hlmetrik ist 0 Axiom BDW2 Das Axiom gilt Wenn eine Klasse keine Beziehungen nach au en hat liefert NEDC den Wert 0 Hat sie hingegen Beziehungen nach au en liefert NEDC die Anzahl dieser Beziehungen also einen Wert gr er 0 Axiom BDW3 Das Axiom gilt F gt man einer Klasse eine Beziehung nach au en hinzu erh ht sich NEDC um 1 Damit ist die Ungleichung erf llt Axiom BDW4 Das Axiom gilt Werden zwei Klassen m
392. zersicht denn die ersten vier Faktoren lassen sich dieser zuordnen w hrend die letzten beiden Faktoren der Entwicklersicht zuzuordnen sind suitability A accuracy interoperability functionality compliance security Br maturity P Se e reliability KI C fault tolerance o recoverability LEE understandability e usability E amp learnability Mer operability a Sa te time behaviour D d efficiency en resource behaviour analysability nr changeability maintainability ES stability FL testability ee adaptability D S portability DG C installability ct conformance replaceability Abbildung 6 4 Qualitatsmodell in ISO IEC 9126 1991 6 2 Qualit tsmodelle 67 IEEE Standard 1061 Der Schwerpunkt dieses Standards liegt auf der Umsetzung eines Qualit tsmodells in ein Metrikenprogramm metrics framework Im Anhang wird ein Qualit tsmodell vorgeschlagen das starke hnlichkeit mit dem ISO IEC 9126 Modell hat Die Fakto ren sind dieselben lediglich in den Kriterien gibt es Unterschiede vgl Abbildung 6 5 completeness correctness functionality Secunia compatibility interoperability nondeficiency reliabilit
393. zum dominanten Entwurfsan satz entwickelt hat Die Unified Modeling Language UML hat sich seit ihrer Einf h rung 1996 und ihrer Standardisierung 1997 durch die OMG als die Standardnotation f r den objektorientierten Entwurf etabliert weshalb es nahe liegt als Messgegen stand UML Entwurfsdokumentation zu verwenden UML ist au erdem hinreichend formal um aus UML Modellen Entwurfsinformation automatisch extrahieren zu k nnen Weil sich ein Entwurf zwar weitgehend aber nicht auf sinnvolle Weise voll st ndig mit UML dokumentieren l sst wird zus tzlich zum UML Modell auch begleitende Entwurfsdokumentation in die Bewertung einbezogen Messziel F r die Entwurfsqualit t gibt es keine einheitliche Definition oder gar einen Standard Das gilt besonders f r den objektorientierten Entwurf Allerdings gibt es einiges an dokumentiertem Erfahrungswissen z B als Ratschl ge in Form von Entwurfsregeln und Mustern Aus diesem Wissen l sst sich ein Qualit tsmodell ablei ten indem man die jeweiligen Ziele der Ratschl ge z B verringerte Kopplung betrachtet Da Entwurfsqualit t multidimensional ist Bosch 2000 wird auch das Qualit tsmodell multidimensional sein m ssen 1 2 Zielsetzung 3 Messverfahren Das Messverfahren ist eine Metrik die durch das Qualit tsmodell fundiert ist Zielgruppen Das Bewertungsverfahren richtet sich sowohl an Neulinge als auch an fortgeschrit tene Entwerfer Neulinge d rften allerdings einen gr

Download Pdf Manuals

Related Search

Related Contents

Samsung RA19AHTS1/CTL User Manual(COOLWELL ELECTRIX)  Rexel PP Dividers, grey, plain  DeLonghi PAC N130HPE Air Conditioner User Manual  User Manual    Raiponce Disney Rapunzel Digitalkamera Rapunzel Rapunzel  Lennox Hearth 90UGF User's Manual  MT9083 Series ACCESS Master  Sangean H-201  NovitaTech Engineering  

Copyright © All rights reserved. Failed to retrieve file