Home

Volltext - Stefan Jungmayr

1. number suktypes n_suktyp number of dependencies rooted in class cd free metric for dependent component fre_dprit number of hard wired dependencies rooted nc cd bh free metric for dependee componert done total number of transitive outgoing component cd 1 normalized level of dependent component lev_dpnt number of transitive hard wired component dep cd_h_tr normalized level of dependee component lev_dpne number of transitive static component depende Cd Ir coupling of dependent component cho dort reduction of average component dependency if coupling of dependee component cho_dpne reduction of average component dependency if rACD_out indirect coupling of dependent component chi_dprit indirect coupling of dependee component chi_dpne type of dependency el 1 Select all Unselect Ai SetDefauts save setas Lost zt cd_h Number Of Hardwired Component Dependencies Represents the number of hard wired dependencies to other classes Hard wired dependencies reduce the ability to test a class in isolation Abbildung 1 Testability Metrics Dialog Im linken oberen Teil des Dialogs erhalten Sie eine Auflistung der verf gbaren Abh ngigkeitsmetriken im rechten oberen Teil eine Auflistung de
2. 2 2 en en 2 0 1 0 12 6 5 7 9 0 static access Abbildung 32 Abh ngigkeitsmetriken SeminarisK SeminarisDatenbank 55 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Abbildung 33 Komponentenmetriken SeminarisK A und SeminarisDatenbank Erl uterungen zu den Abh ngigkeitsmetriken Die Abh ngigkeit ist Teil eines Zyklus dep_comp und verl uft ber Paketgrenzen hinweg is_intpk Der im Vergleich zum rACD Wert doppelt so hohe rACDh Wert f llt auf Das Entfernen der Abh ngigkeit w rde die Anzahl der Zyklen von 5 auf 7 erh hen rNDC Dies geschieht infolge der Zersplittung eines gr eren Zyklus in zwei kleinere da derzeit durch die Abh ngigkeiten von SeminarisDatenbank zu einzelnen Dom nenklassen Belegung Leitungsauftrag Geschaeftspartner eigentlich disjunkte Zyklen in der Datenhaltungsschicht zu einem einzigen gr eren Zyklus verschmelzen SeminarisDatenbank Abbildung 34 Zyklen in Datenhaltungsschicht Die Anzahl der Zyklenkomponenten bleibt mit 105 nahezu unver ndert rNCDC wodurch die durchschnittliche Zyklengr e von ca 21 auf ca 15 Komponenten verringert wird Aus Abbildung 34 ergibt sich ferner eine Erkl rung f r den hohen rACD Wert Es handelt sich hier um eine sogenannte Aub Abh ngigkeit Es wird von einer gro en Anzahl von Klassen komplette Kontrollschicht und einzelne Datenhaltungsklassen ber SeminarisK auf die Klasse Se
3. ACDh 60 35496 NFD 81 0 NSBC 39 0 NCDC 106 0 5 0 Project Metri _ _ ACD 85 33579 ACDh 54 954197 NFD 80 0 370 NCDC 102 0 5 0 Abbildung 112 Projektmetriken nach Entfernen des externen Zugriffs auf Kontrollschicht Die Anzahl der Klassen von denen eine Klasse im Durchschnitt direkt oder indirekt abh ngig ist ist um 4 2 Prozent gesunken beschr nkt auf fest verdrahtete Abh ngigkeiten um 8 9 Prozent Die Anzahl der zyklischen abh ngigen Komponenten hat sich geringf gig verringert Ein Blick auf die Abh ngigkeitsmetriken zeigt dass die betroffenen Abh ngigkeiten weggefallen sind und die Werte der Abh ngigkeit vonSeminarisK zur Datenbank gesunken sind Funktionalit t Typ der bereitstellende Klasse Abh ngigkeit Abh ngige Klasse Dozentenv ereinbarung DVKostenBerechnenK 1 0 1 8 2 9 0 1 9 create and access SVAendernErfassenAA Seminarty pAusw aehlenAA 0 0 1 2 3 3 6 1 2 create and access SeminarisK SeminarisDatenbank 1 0 122 48 1 5 static access SVAendernErfassenAA LeitungsauftragAusw aehlenAA 1 0 1 1 9 3 3 1 create and access Seminarty pAendernErfassenAA Dozentenv ereinbarungAusw aehlenAA 0 0 25 1 create and access LeitungsauftragAendernErfassenAA SVAusw aehlenAA 1 1 11 7 2 8 1 2 create and access SeminarbelegungAA SVAusw aehlenAA 0 0 116 2 7 2 create and access DVKostenBerechnenK Dozentenv ereinbarungLoeschenK 1 1 0 16 1 8 1 1
4. P SeminarisK GI 0 0 8 PlDozentenvereinkarungAnfragen DP mO mioo 8 P DozentenvereinbarungTripel P u 00 Abbildung 38 Entfernung der Abh ngigkeiten aus der Datenhaltung in die Kontrollschicht Die Entfernung der Abh ngigkeiten f hrt zu folgenden Projektmetriken Project Metrics without Excluded umber of components NaN Zerowalue 273 0 Improvement NaN 79 60516 89 11439 10 670807 39 0 39 0 0 0 70 103 0 76 0 5 0 106 0 81 0 262 0 60 35496 40 0 2 8301926 6 172544 Mei Abbildung 39 Projektmetriken ohne Abh ngigkeiten aus Datenhaltung in Kontrollschicht Auch hier kommt es zu einer deutlichen Verringerung des ACD Wertes 11 3Prozent F hrt man beide Refaktorisierungsschritte zusammen durch entfernt also die Abh ngigkeiten aus SeminarisDatenbank in die Datenhaltung und aus der Datenhaltung in die Kontrollschicht so erh lt man sogar folgende Verbesserung der Projektmetriken Project Metrics without Excluded EN umber of components NaN ZeroYyalue 273 0 Improvement 67 860443 8911439 23 91304 35 0 39 0 10 256409 800 5 8603775 160 35496 Abbildung 40 Projektmetriken ohne zyklische Abh ngigkeiten zwischen Datenhaltung und Anwendungslo
5. Dozentenvereinbarung SeminarveranstaltungOrdner Firma GeschaeftspartnerOrdner ErmeltertPersistent rdner AnfrageOrdner gt SeminartypOrdner AnfrageSpalte AnfrageParameter AnfrageParameter Anfrage Anfrage AnfrageSpalte Abbildung 99 Paketdiagramm Datenhaltungsschicht Das Paket SseminarisP umfasst die Dom nenklassen und die Assoziationsklassen die bereits aus dem Klassenmodell der Anforderungsspezifikation abgeleitet werden konnten Im Paket TransformationenP sind die Relationen Paar und Tripelklassen enthalten die sich aus der Transformation der Assoziationen des Klassenmodells im Rahmen des Feinentwurfs ergaben Im PaketOrdnerP sind die Ordnerklassen abgelegt die den Zugriff auf die Instanzen der Echte Ganzes Klassen bereitstellen SWEI99 Die in den Ordnerklassen enthaltene Funktionalit t beschr nkt sich dabei ausschlie lich auf den Datenbank Zugriff ber die SQL Abfrage Schnittstelle des Persistenz Rahmenwerks Weitergehende Funktionalit t f r die Entit ten ist in den Dom nenklassen realisiert 87 Kapitel 10 Entwurfsprobleme und Testbarkeit Von den Klassen IErweitertPersistent und ErweitertPersistent sind alle persistenten Dom nen und Paarklassen abgeleitet Sie erweitern die Klasse IPersistent des Persistenz Rahmenwerkes um zus tzliche Funktionalit t f r den Umgang mit dem Persistenz Rahmenwerk und beinhalten ferner eine Methode f r den Zugriff zur Datenbank
6. public void setEqual IFirma eineFirma super setEqual eineFirma 3 diesen F llen kann bereits im Rahmen der Kompilierung ermittelt werden welche Methode aufgerufen wird die berschriebene Methode der Superklasse die in der Hierarchie am n chsten liegt Somit kann der Methodenaufruf vom Compiler statisch gebunden werden Dies kann ferner unabh ngig vom Typ der aufgerufenen Methode statisch oder nicht statisch erfolgen Folglich liegt eine Abh ngigkeit D_CALL_ST vor B 17 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen obigem Beispiel wird zwar eine nicht statische Methode aufgerufen der Eintrag in den Abh ngigkeitsgraphen erfolgt dennoch mit Typ D_CALL_ST Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D Firma T_CLASS Geschaeftspartner T_CLASS Class D_CALL_ST Firma T_CLASS Geschaeftspartner T_CLASS Member D_CALL_ST setEqual METHOD setEquall T_METHOD 151 Anhang B Aufruf einer Interface Methode B 18 Aufruf einer Interface Methode B 18 1 Erl uterung und Beispiel Wird eine in einem Schnittstellentyp Interface definierte Methode aufgerufen so wird hierdurch eine Abh ngigkeit vom Typ D_CALL_IF definiert abstract public class Geschaeftspartner implements IGeschaeftspartner public static Collection getAlleSchluessel throws DatenbankAusnahnme while iter hasNext ergebnisMenge
7. 152 20 KLASSENINTERNER AUFRUF EINER STATISCHEN 152 B 21 INSTANZIERUNG MITTELS NEW OPERATOR 222200000 00 00 0 153 22 INITIALISIERUNG EINES EINDIMENSIONALEN 5 2 0 0 01 00000 154 B 23 INITIALISIERUNG EINES MEHRDIMENSIONALEN 5 154 B 24 VERWENDUNG DES TYPE CAST OPERATORS 2 4 8 000000 154 B 25 VERWENDUNG DES INSTANCEOR ODERATORS 00000 155 JAVA ABH NGIGKEITEN IN BESONDEREM KONTEXT 156 B 26 LOKALE INNERE KLASSEN STATISCH UND 156 B 27 ANONYME INNERE KLASSEN 156 28 STATISCHER KONSTRUKTOR INITIALISIERER 157 B 29 INSTANZ INTHI LISIERER AE A AEAEE 158 30 ABH NGIGKEITEN ZU VERERBTEN METHODEN UND ATTRIBUTEN 0 2 0 0 0 159 B 31 MANUELLE TOGETHER ABHANGIOGKEITEN nn nenn 159 EINSCHRANKUNGEN sense elite 161 ZUSAMMENFASSUNG nee 162 140 Anhang Einleitung Einleitung F r die Erstellung dieses Dokuments wurden die Syntax und die Struktur von Java Programmen analysiert um Aufschluss ber die Abh ngigkeiten zu erhalten die in Java Programmen auftreten k nnen Die Ergebnisse dieser Analyse werden in den nachfolgenden Abschnitten in Form der gefundenen Abh ngigkeiten aufgelistet Das Konzept der Together Erweiterung zur Testbarkeitsa
8. B 3 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Die Grapheintr ge bei expliziter Implementierung eines Interfaces lauten wie folgt Ebene Abh ngigkeitstyp Knotentyp Nach Knotentyp Summary D_DEP Firma T_ABSTR IFirma T_INTERF Class D_IMPLEM Firma T_ABSTR IFirma T_INTERF Member Bei anonymen Klassen verl uft die Abh ngigkeit auf Klassenebene von der anonymen Klasse zur Superklasse Auf Summary Klassenebene hingegen geht die Abh ngigkeit von der Klasse aus in der die anonyme Klasse definiert wird Ebene Abh ngigkeitstypp Knotentyp Nach Knotentyp Summary D_DEP Firma T_CLASS ActionListener T_CLASS Class D_IMPLEM anonym_class T_INRCL ActionListener T_CLASS Abstrakte Klassen innere und anonyme Klassen werden durch eigene Typen T_ABSTR T_INCRL repr sentiert 144 Anhang Typ eines Methoden Parameters B 4 eines Methoden Parameters B 4 1 Erl uterung und Beispiel Besitzt eine Methode als Typ eines ihrer Parameter einen Objekttyp so wird eine Abh ngigkeit vom Typ D_PARAM definiert Zu den Objekttypen z hlen beispielsweise auch die mit der 2 Platform Standard Edition 725 ausgelieferten Wrapper Klassen Integer Boolean oder die Klasse string Die Java Basisdatentypen int boolean bleiben hingegen unber cksichtigt public class Person extends Geschaeftspartner implemen
9. 15 3 E N 2 2 8 2 lt lt lt lt lt lt D 1 19 2 6 15 6 5 11 11 1 0 Abbildung 50 Komponentenmetriken LeitungsauftragAendernErfassenAA A und SV AuswaehlenAA Auff lligkeiten bei den berechneten Werten Auffallend ist die sehr hohe Zahl von ausgehenden Abh ngigkeiten cd bei der Klasse LeitungsauftragAendernErfassenAA Auch die hohen rACD Werte der Klasse SVAuswaehlenAA sind bemerkenswert Die extrem hohe Anzahl der direkten und indirekten Abh ngigkeiten cd_tr beider Klassen resultiert unter anderem aus der Beteiligung an verschiedenen Zyklen Die Anzahl statischer Abh ngigkeiten liegt in beiden Klassen sehr hoch cd_h 9 2 7 2 Bewertung In der Anforderungsspezifikation hei t es im main flow zum Anwendungsfall Leitungsauftrag erfassen Der Seminarsachbearbeiter w hlt eine Person und eine Seminarveranstaltung aus und erfasst die Angaben zum Leitungsauftrag Die in der Anforderungsspezifikation vorgeschriebene Auswahl einer Seminarveranstaltung wurde beim Entwurf von sSeminarlS derart realisiert dass hierdurch eine Abh ngigkeit dieses Anwendungsfalles mit den Anwendungsf llen zur Bearbeitung einer Seminarveranstaltung entstand siehe Abschnitt 10 8 Dies f hrt zur Abh ngigkeit der zu den Anwendungsf llen implementierten Schnittstellenklassen und den damit verbundenen Testproblemen Da in diesem Fall da
10. 5 2 222 0000000000 0 144 4 EINES METHODEN PARAMETERS 145 5 DES R CKGABEWERTS EINER METHODEN 145 B 6 TYPSPEZIFIKATION IN DER THROWS KLAUSEL EINER METHODEN 146 B 7 TYP EINES PARAMETERS IN EINEM 00 146 B 8 TYP EINES ATTRIBUTS EINER 55 20 00 0000 0 0000000000000000 146 B 9 TYP EINER LOKALEN 147 B 10 LESENDER ZUGRIFF AUF NICHT STATISCHES 55 2 2 000 148 11 LESENDER ZUGRIFF STATISCHES 5 148 B 12 SCHREIBENDER ZUGRIFF NICHT STATISCHES 149 B 13 SCHREIBENDER ZUGRIFF STATISCHES cerre 149 B 14 AUFRUF EINER KLASSENFREMDEN STATISCHEN 1 150 B 15 AUFRUF EINER KLASSENFREMDEN NICHT STATISCHEN METHODE 150 B 16 AUFRUF DES SUPERKLASSENKONSTRUKTORS RSPLIZIT 150 B 17 AUFRUF VON BERSCHRIEBENEN ODER VERDECKTEN 151 B 18 AUFRUF EINER 152 19 KLASSENINTERNER AUFRUF EINER NICHT STATISCHEN METHODE
11. FirmenverwaltungP FirmaAuswaehlenK PersonenverwaltungP PersonErfassenK SeminartypP SYKalkulierenK SeminarveranstaltungP OeSVErfassenK 5 a I 1 l 1 A DatenhaltungP SeminarisP Seminameranstaltung FirmenSeminamveranstaltung Seminartyp OeffentlicheSeminarveranstaltu FirmenSeminarveranstaltung DatenhaltungP OrdnerP S5eminarypOrdner 5YSeminartyprRelation ErweitertPersistentOrdner _ DozentenvereinbarungRelation AnfrageOrdner FirmenAnsprechpannerfaar DozentenvereinbarungTripel FirmenAnsprechpartnerPaar 5SeminarveranstaltungOrdner Geschaeftspartner rdner Abbildung 107 Zugriff auf Datenhaltung mit Fassadenmuster Der obigen Architektur und der daraus resultierenden Effekte liegt folgende Design Entscheidung zugrunde e Auf die Datenhaltungsschicht sollte exklusiv ber die origin ren Entit tsklassen Dom nenklassen zugegriffen werden Die Dom nenklassen Seminartyp Firma beinhalten also zu einem gewissen Teil die Aufgaben einer nach dem Entwurfsmuster Fassade realisierten Klasse neben Ihrer eigentlichen fachlichen Funktionalit t 98 Kapitel 10 Entwurfsprobleme und Testbarkeit e Wird demzufolge in der Anwendungslogik oder in anderen Datenhaltungsklassen Funktionalit t aus den Ordner oder Rela
12. AuswaehlenListeAA interface seminartypAuswaehlenAA JAAKlassenFahrik SeminarisFrame i AuswaehienListe AA rr Abbildung 125 Verwendung der Schnittstellen Fabrik in SVAendernErfassenK zur Erzeugung der Auswahlklasse SeminartypAuswaehlenAA S mtliche Schnittstellenklassen greifen auf das statische Attribut MainwWwindow der Hauptschnittstellenklasse SeminarisH zu um in diesem Hauptfenster eine Instanz der Klasse SachbearbeiterA Hinweise und Fehlermeldungen anzuzeigen Dadurch wird die komplette Schnittstellenschicht zyklisch verbunden Diese zyklische Verbindung war vor der Refaktorisierung deshalb nicht erkennbar weil durch die Reflection Mechanismen in der Klasse SachbearbeiterA zur Erzeugung der Auswahlschnittstellen der Zyklus durchbrochen war Die Erzeugung einer Instanz der AAKlassenFabrik in der Hauptschnittstellenklasse schlie t nun den Zyklus durch die dadurch entstehende Abh ngigkeit von SseminarisH zu den Auswahlschnittstellen Dies wird durch die ermittelten Abh ngigkeitsmetriken und insbesondere durch die Komponentenmetriken deutlich 122 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung Dependent class Dependee class 8 amp 8 9 2 d pe a o 8 SZ Dozentenvereinbarung DVKostenBerechnenK 1 45 3 48 13 35 8 50 11 and static access SeminarisH AbstractAAKlassenFabrik 1 36 8 61 9 7 8 10 36 3 50 33 create and static access
13. Da die Berechnung der Metriken nur f r eine bestimmte Ebene eines Abh ngigkeitsgraphen erfolgt muss im Graph die zu analysierende Ebene vor dem Starten der Berechnung explizit gesetzt werden Jede zu berechnende Metrik wird durch die Instanz einer Klasse repr sentiert Die verf gbaren Metrikklassen f r Abh ngigkeiten sind im Paketmetrics die verf gbaren Komponentenmetriken im Paket nodemetrics angesiedelt Die Metrikinstanzen werden vor dem Start einer Metrikberechnung erzeugt und ber die Methode void addMetric MetricSet metric den Analyseklassen hinzugef gt Dort werden sie w hrend der ganzen Laufzeit des Programmes in einer Datenstruktur vorgehalten Wurden die beiden Berechnungsklassen mit dem zu analysierenden Graphen und den zu berechnenden Metriken siehe Abschnitt 0 Konfiguriert so kann die Analyse des Graphen und die Berechnung der Metriken gestartet werden Zum Start der Berechnung dienen die beiden analyze Methoden void analyzeVersions void analyzeNodes 20 Kapitel 5 Analyse 5 8 Anzeige der Testbarkeitsmetriken 5 Nach Abschluss der Metrikberechnung sollen die mproveT Ergebnisse in Together abgerufen werden k nnen Dieser Abschnitt beschreibt die von den beiden zu integrierenden Systemen hierzu angebotenen Ausgabeschnittstellen Dies wird Grundlage f r den Entwurf der Ausgabekomponenten in Abschnitt 6 7 sein 5 8 1 Ausgabeschnittstelle von mproveT Die ermitt
14. Durch die Aufgabenstellung war bereits vorgegeben dass die Einbindung des Moduls in die Men struktur erfolgen sollte Somit ergibt sich die Realisierung nach der oben beschriebenen ersten Variante Hierzu schreibt das Together Open API die Implementierung der Hauptmodulklasse nach dem Interface IdeStartup vor interface com togethersoft openapi ide ideStartup autorun void Design2Test autorun void Abbildung 13 Integration als Together Modul Die Implementierung der autorun Methode wird die Erzeugung der Men eintr ge mit entsprechenden Ereignis Listenern zum Start des Testbarkeitsmoduls vorsehen Aus dem abgebildeten Klassendiagramm l sst sich im brigen eine weitere Entwurfsentscheidung ablesen Der Name der realisierten Together Erweiterung wird Design2Test lauten 6 3 Komponente Abh ngiskeitssuche package search Beim Entwurf der Suchkomponente liegt der Fokus auf der Wiederverwendbarkeit des Moduls Zur Ablaufsteuerung und f r den externen Zugriff auf das Analyse Paket dient die Klasse DependencySearcher Die Konfigurierbarkeit und damit Wiederverwendbarkeit dieser Klasse auch in anderen Anwendungsszenarien gew hrleisten die Interfaces DependencySearchListener undSearchScope 25 Kapitel 6 Entwurf DependencySearcher dependencySearchListener Depe searchScope SearchScope progress ldeProgress numberOfPackagesiint packageCounter int isCancelled boolean interface Depen
15. T_METHOD getEinzigelnstanz T_METHOD B 15 Aufruf einer klassenfremden nicht statischen Methode B 15 1 Erl uterung und Beispiel Wird eine nicht statische Methode einer fremden Klasse aufgerufen so wird hierdurch eine Abh ngigkeit vom Typ D_CALL_VI definiert abstract public class Seminarveranstaltung 1 public static Iterator getAlle throws DatenbankAusnahme return SeminarveranstaltungOrdner getEinzigelnstanz getSVs Als fremde Klasse gelten auch alle u eren Klassen einer inneren Klasse Der Aufruf einer klasseneigenen nicht statischen Methode wird als Abh ngigkeit D_CALL_TI gespeichert B 15 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP Seminarveranstaltung _ABSTR _ Seminarveranstaltung Ordner T_CLASS Class D_CALL_VI Seminarveranstaltung _ABSTR Seminarveranstaltung Ordner T_CLASS Member 10 getAlle T_METHOD getSVs T_METHOD B 16 Aufruf des Superklassenkonstruktors explizit B 16 1 Erl uterung und Beispiel Ruft ein Konstruktor einen der Konstruktoren der Superklasse mit der Anweisung super auf so wird eine Abh ngigkeit D_CALL_SU definiert Wird in abgeleiteten Klassen auf den Aufruf des Konstruktors der Superklasse verzichtet so f gt der Compiler w hrend des bersetzungsvorgangs als 150 Anhang Aufruf von berschriebene
16. e Project Metrics ffnet ein kleines Fenster in dem die Metrikwerte des Gesamtprojektes angezeigt werden gt 4 4 1 Projektmetriken f r das Gesamtprojekt 187 Anhang Kontextmen s e Project Metrics without ffnet ein kleines Fenster dem die Metrikwerte ohne die in der Spalte exclude abgew hlten Abh ngigkeiten angezeigt werden gt 4 4 2 Projektmetriken nach Beseitigung von Abh ngigkeiten Format Absolute Values Stellt die Werte einer nummerischen Metrik in absoluten Werten dar e Format Values as Percentage Stellt die Werte einer nummerischen Metrik in Prozentform dar Hierbei handelt es sich um den Grad der Verringerung des korrespondierenden Metrikwertes des Gesamtprojektes nach Entfernung der Abh ngigkeit e Sort Ascending Descending Sortiert nach der jeweiligen Spalte in der angegebenen Ordnung Eine detaillierte Beschreibung der einzelnen Funktionen finden Sie in Abschnitt 4 3 Funktionen in den Metrikanzeigen A 2 Komponententabellen Klicken Sie mit der rechten Maustaste in eine der beiden bersichten ber verbundene Komponenten im rechten Teil des Panels Component Metrics so steht Ihnen folgendes Kontextmen zur Verf gung Select Component Metrics Dependency Metrics Edit Select on Diagram Abbildung 23 Kontextmen bei der Anzeige verbundener Komponenten Die einzelnen Men punkte bieten Ihnen folgende M glichkeiten e Select Component Metrics Wechselt in der Metr
17. nextInheritance getReferencedElement break if the reference points out of classpath if referencedElement null break generally isImplementation works as desired but for anonymous classes isImplementation is always false if nextInheritance isImplementation sciClass hasProperty SciProperty UNNAMED amp amp referencedElement hasProperty SciProperty INTERFACE add a new Dependency object notifyListenerDependencyFound sciClass nextInheritance getReferencedElement D_IMPLEM deleteNewLinesAndSpaces sciClass getDeclarationText nextInheritance getPositions Erw hnenswert sind die durch Fettdruck hervorgehobenen Textstellen Als Die in der Aufgabenstellung vorgesehene Konfiguration der Suche wird durch bergabe und Auswertung einer Instanz vom SearchScope gel st W hrend der Implementierungsphase wurde Anforderungsspezifikation dahingehend pr zisiert bzw erweitert dass auch Klassen die nicht an Abh ngigkeiten beteiligt sind in den Abh ngigkeitsgraphen eingef gt werden Der Umgang mit anonymen Klassen ist von diversen Schwierigkeiten durch diesbez gliche Unzul nglichkeiten des Open API gepr gt Die Ber cksichtigung anonymer Klassen f hrt meist zur Notwendigkeit einer Sonder bzw Fehlerbehandlung workaround n chstes Beispiel wird ein Codeausschnitt aus der Visitor Klasse myNewExpressionReferenceVisitor angef hrt Diese Klasse wurde speziell zur A
18. repaintGraph void graphClosed void edgeChanged void SelectMetricsDialog nodeChanged void 71 72775 Del Abbildung 23 Umsetzung des Entwurfsmusters Mediator Die Verwendung des Entwurfsmusters Mediator bringt folgende Vorteile e Logik zur Programmablaufsteuerung wird zentral an einer Stelle gehalten e Dadurch geringere Komplexit t und besseres Verst ndnis Ferner erleichterte Wartbarkeit und Erweiterbarkeit der Anwendung e Vermeidung von Zyklenbildung durch wechselseitige Abh ngigkeiten und insbesondere des rekursiven Aufrufs der Metrikanalyse 35 Kapitel 6 Entwurf 6 8 1 Beispiel f r verworfene Entwurfsalternative Alternativ kam die Einf hrung einer zentralen Synchronisationskomponente in Betracht bei der die Registrierung aller betroffenen Komponenten erfolgen h tte m ssen Jede nderung in der Anzeige w re dann ber den Synchronisationsmanager an alle bei ihm registrierten Komponenten gemeldet worden Dieser Entwurf stellte sich leider erst in der Implementierungsphase als nicht zielf hrend heraus so dass ein Redesign des Entwurfs erforderlich wurde Die Probleme die dies notwendig machten waren bei diesem Entwurf insbesondere e Durch die Integration der Anzeigemodule in Together war es dem Anwender m glich die Anzeigemodulle wie jede andere origin re Together Schnittstellenkomponente zu schlie en Dieses Schlie en der Komponenten konnte jedoch leider nicht im Rah
19. A 2 9 Anwendungsfall Abh ngigkeitsgraph anzeigen use case Abh ngigkeitsgraph anzeigen actors Together Benutzer precondition Die Berechnung der Testbarkeitsmetriken wurde erfolgreich ausgef hrt main flow Der Benutzer l sst sich die Komponenten des analysierten Projektes und die zwischen ihnen ermittelten Abh ngigkeiten in graphischer Form darstellen Die ermittelten Abh ngigkeiten werden als gerichtete Kanten eines geometrischen Graphen die abh ngigen Komponenten als dessen Knoten angezeigt Die Knoten k nnen gemeinsam mit ihren Kanten durch Verschieben beliebig angeordnet werden Einzelne Knoten und ihre ein und ausgehenden Kanten k nnen ausgeblendet werden alternate flow Anzeige aktualisieren Alle Elemente des Graphen werden unter Ber cksichtigung der aktuellen Gr e des Anzeigefensters automatisch neu angeordnet alternate flow Farbschema ver ndern Um bestimmte Aspekte wie Zyklen oder die Art der Abh ngigkeit graphisch hervorzuheben k nnen die Elemente des Graphen in verschiedenartigen F rbungen ausgegeben werden alternate flow Speichern des Graphen Der angezeigte Graph kann in einem Grafikformat JPEG gespeichert werden F r die zugrunde liegende Struktur ist die Speicherung in Textform XML m glich extension point Graph speichern alternate flow Ausdruck des Graphen Der Benutzer startet den Ausdruck der aktuellen Anzeige des Graphen extension point Graph drucken postcondition end Abh
20. AbstractAAKlassenFabrik AAKlassenFabrik 1 36 4 61 9 6 5 10 35 8 50 100 create dependency AAKlassenFabrik BelegungAuswaehlenAA 1 10 5 12 6 5 2 5 11 9 0 100 create and static access SeminarisK SeminarisDatenbank 1 5 45 14 8 1 3 15 2 07 50 20 static access AAKlassenFabrik DozentenvereinbarungAuswaehlenAA 1 5 4 5 39 22 23 0 52 50 100 create and static access AAKlassenFabrik SeminartypAuswaehlenAA 1 4 6 5 55 21 20 5 18 0 100 create and static access AAKlassenFabrik LeitungsauftragAuswaehlenAA 1 4 6 6 05 21 20 5 18 0 100 create and static access Druck Dokument Dk SeminarisK 1 2 41 3 53 1 3 2 5 1 04 0 100 static access BelegungAuswaehlenAA BelegungStornierenAA 1 2 31 2 53 1 3 0 2 59 0 33 and static access BelegungAuswaehlenAA TeilnehmerAnmeldenAA 1 2 31 2 53 1 3 2 5 2 59 0 33 and static access TeilnehmerAnmeldenAA TeilnehmerAnmeldenK 1 1 85 2 03 1 3 2 5 2 07 0 25 and static access BelegungStornierenAA BelegungStornierenK 1 1 85 2 03 1 3 0 2 07 0 50 and static access SVAuswaehlenAA FSVErfassenAA 1 1 85 2 02 7 8 0 2 07 0 33 and static access BelegungAuswaehlenAA BelegungAendernAA 1 1 85 2 02 1 3 2 5 2 07 0 50 and static access Abbildung 126 Abh ngigkeitsmetriken nach Einf hrung der Schnittstellenfabrik W hrend in den Abh ngigkeitsmetriken noch kein Hinweis auf die aus der Schnittstellenschicht zu SeminarisH f hrenden Abh ngigkeiten zu finden ist liefern die
21. Das Refactoring f hrt also zu einer Verringerung der Anzahl der Klassen von denen eine Klasse im Durchschnitt direkt oder indirekt abh ngig ist um 42 6 Prozent Bezogen auf ausschlie lich fest verdrahtete Abh ngigkeiten betr gt der R ckgang 41 0 Prozent Die Anzahl der in Zyklen involvierten Komponenten nimmt um 34 0 Prozent ab Die Erh hung der Abh ngigkeitszyklen von 5 auf 9 l sst sich als Aufl sung eines allumfassenden Zyklus in der Datenhaltung in mehrere kleinere Zyklen interpretieren Durch das Refactoring ergibt sich auch bei den Abh ngigkeiten mit dem h chsten rACD Wert eine Verschiebung hin zu den Abh ngigkeiten in der Schnittstellenschicht 117 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung Message Pane is i i rACDh dprit done PErweitertPersistent PSeminarisDatenbank 21917572 5 lt 3 5499 5 P _ 5 lt 5 lt 3 3470 4 998121 sale m PlDozentenyereinbarung PDozentenvereinbarung 2 8761 A m PSeminarisK 5 2 _ 5 lt AA Ei PDo
22. Dies kann nur ber das Ver ndern des zu testenden Codes oder das Ersetzen der Klassen Seminarisk ErweitertPersistent oder SeminarisDatenbank durch eine ge nderte Implementierung erreicht werden 97 Kapitel 10 Entwurfsprobleme und Testbarkeit Grunds tzlich stellt sich dasselbe Problem auch f r die anderen Basiskomponenten dar Auch der Zugriff auf die Konfigurations und Protokollkomponente ist nach dem Entwurfsmuster Singleton realisiert so dass auch hier keine Konfigurierbarkeit der Anwendung f r Testzwecke m glich ist Im brigen dr ngt sich der Verdacht auf dass allgemein bei der Entscheidung f r den Einsatz dieses Entwurfsmusters die M glichkeit des globalen Zugriffs ber die statische getInstance Methode wom glich h ufig die bedeutendere Rolle spielt als die Absicht zur Beschr nkung der erzeugbaren Instanzen 10 7 Realisierung der Dom nenklassen als Fassaden 10 7 1 Entwurfsproblem Einen berblick ber den Zugriff aus der Kontrollschicht auf die Datenhaltung gibt das nachfolgende Paketdiagramm Auf den ersten Blick wird die Fassadenfunktion der Dom nenklassen deutlich Paket Datenhaltung SeminarisP Im Diagramm sind alle Abh ngigkeiten ausgeblendet die eine Verletzung der Mehrschichtarchitektur und des Fassadenmusters darstellen LeitungsauftragP LeitungsauftragLoeschenK a SeminarbelegungP DozentenvereinbarungP DozentenvereinbarungK 2
23. Dort wird auf der Basis des Abh ngigkeitsgraphen die Metrikberechnung gestartet Die zu berechnenden Metriken sollen im Vorfeld vom Anwender ausgew hlt werden k nnen Im n chsten Abschnitt werden die Schnittstellen von mproveT zur Erledigung dieser Aufgaben beschrieben Darauf aufbauend erfolgt der Entwurf der Teilkomponente zum Start der Metrikberechnung siehe Abschnitt 6 5 5 7 1 Analyseschnittstelle von mproveT Auf Basis des im Abschnitt 5 6 beschriebenen Abh ngigkeitsgraphen erfolgt die Berechnung der in Abschnitt 1 3 vorgestellten Testbarkeits und Reduktionsmetriken Diese werden um zus tzliche Informationen erg nzt die eine bessere Einordnung der Metriken im Hinblick auf die Testbarkeit des Systems erm glichen F r die tats chliche Berechnung von Abh ngigskeits und Komponentenmetriken sind die beiden Klassen VersionAnalysis und NodeAnalysis verantwortlich Beide Klassen sind von der Java Swing Klasse AbstractTableModel abgeleitet Als Ergebnis der Berechnung erh lt man folglich ein Tabellenmodell das zur Anzeige gebracht werden kann Der Programmablauf zum Start der Berechnung ist in beiden Klassen identisch e Erzeugung einer Instanz der Berechnungsklasse e Setzen des zu analysierenden Abh ngigkeitsgraphen Definition der zu berechnenden Metriken e Starten der Analyse Die Zuweisung des zu analysierenden Abh ngigkeitsgraphen erfolgt jeweils mittels der Methode void setGraph ExtendedGraph g
24. Kapitel 12 Zusammenfassung zwar die syntaktische aber nicht die semantische Abh ngigkeit verhindert so sind 225 der insgesamt 278 SeminarlS Klassen in einem einzigen Zyklus voneinander abh ngig Alle Verletzungen der Schichtenhierarchien Konnten als unn tig und weitestgehend durch Implementierungsfehler bedingt nachgewiesen werden e Die Realisierung des Zugriffs auf globale Basiskomponenten insbesondere der Zugriff auf die Datenbank f hrte in SeminarIS zu massiven Testproblemen So kann bei der vorhandenen Implementierung beispielsweise nicht verhindert werden dass auch beim Test der meisten Benutzerschnittstellenklassen stets die Datenbank gestartet bereits abgefragt und unter Umst nden durch das verwendete Persistenz Rahmenwerk zus tzlich ben tigter Code Proxyklassen generiert und kompiliert wird e Die meisten der als testkritisch analysierten Abh ngigkeiten wiesen auf ein Entwurfsproblem in der Datenhaltungsschicht von SeminarlS hin Dort wurden die Dom nenklassen als Fassadenklassen f r den Zugriff auf die komplette Datenhaltungsschicht realisiert Dies f hrte bereits bei der Implementierung des Systems zu Problemen und zum erforderlichen Einsatz eines workarounds also zus tzlichem Code zur Umgehung eines sonst nicht vermeidbaren Fehlers Unter dem Gesichtspunkt der Testbarkeit konnte dieser Entwurfsfehler als besonders problematisch dargestellt werden Der ohnehin schon zus tzliche Implementierungsaufwand aufgrund d
25. die an die abgeleiteten Klassen ber Vererbung bereit gestellt wird Dieser Zugriffsmechanismus auf die Datenbank ist v llig analog in den Klassen ErweitertPersistentOrdner von der alle Ordnerklassen abgeleitet sind und ErweitertPersistentRelation von der alle Relationenklassen erben implementiert Obwohl der Namensbestandteil Persistent eine Verbindung zum Persistenz Rahmenwerk vermuten l sst insbesondere die Implementierung des Interfaces IPersistent sind die letzten beiden ErweitertPersistent Klassen v llig unabh ngig von der Persistenzthematik Das weitgehend eigenst ndige Paket AnfragenP realisiert Funktionalit ten f r einen in der Anwendung integrierten Abfragegenerator 88 Kapitel 10 Entwurfsprobleme und Testbarkeit Die Struktur der Anwendungslogik ergibt sich aus folgendem Klassendiagramm 0eSYRechnungDK AnmeldebestaetigungDK SeminarbelegungK BelegungBearbeitenK TeilnehmerAnmeldenK MitteilungErsatzseminarDK GutschriftStornierungDK BelegungAuswaehlenK BelegungLoeschenK MitteilungBelegungsaenderungDK BelegungAendernK BelegungStornierenk GeschaeftspartnerAuswaehlenK BelegungsbestaetigungDK MitteilungStornierungDK MitteilungStornierungTeilnehmerDK 0 DozentenvereinbarungLoeschenK Dozentenvereinbarung amp endernK DozentenvereinbarungK Zeitpunkt DozentenvereinbarungErfassenK Dozentenvereinbarung amp
26. dpunkt Verlag Heidelberg 2001 130 Literaturverzeichnis LoSh98 OUMLO0 Snwio1 SWEII99 705702 100602 Wint00 Wulff02 Lo B W N SHI H A preliminary testability model for object oriented software Proceedings of the 1998 International Conference Software Engineering Education and Practice Dunedin New Zealand M Purvis ed pp 330 337 1998 OBJECT MANAGEMENT GROUP OMG Unified Modeling Language Specification Version 1 3 Object Management Group Inc 2000 SNEED Harry M WINTER Mario Testen objektorientierter Software Das Praxishandbuch f r den Test objektorientierter Client Server Systeme Carl Hanser Verlag M nchen 2001 SIS Hans Werner WINTER Mario et al Software Engineering Objektorientierte Softwareentwicklung Kurs 1794 FernUniversit t Hagen Gesamthochschule in Hagen Fachbereich Informatik 1999 TOGETHERSOFT GMBH Softwareentwicklung in einer neuen Zeit Unternehmensportr t TogetherSoft GmbH URL http www Togethersoft de html press Corporate_Backgrounder_Final doc 2002 07 05 TogetherSOFT CORPORATION UserGuide Together ControlCenter Version 6 0 TogetherSoft 2001 Anwenderhandbuch zum TogetherSoft ControlCenter Version 6 0 in der Fassung vom 11 April 2002 WINTER M Ein interaktionsbasiertes Modell f r den objektorientierten Integrations und regressionstest Informatik Forschung und Entwicklung Vol 15 Nr 3 pp 121 132 2
27. durch Aufruf einer anwendungsfallspezifischen Auswahlsmaske die es gestattet bereits gespeicherte Instanzen zur Bearbeitung auszuw hlen oder alternativ auch Neuerfassungen vorzunehmen 27 Pi ausw hlen Berufsbildungswerk 1 ndern L schen Schlie en Abbildung 108 Obligatorische Auswahlmaske f r alle Firmen Anwendungsf lle 102 Kapitel 10 Entwurfsprobleme und Testbarkeit Beim Aufruf ber das Hauptmen erfolgt die Erzeugung der Schnittstellenklassen ber Reflection Mechanismen siehe auch Abschnitt 10 3 Der Grund f r die Verwendung von Java Reflection war unabh ngig von der Fertigstellung der Anwendungsf lle durch die einzelnen Gruppenmitglieder zu jedem Zeitpunkt die Kompilierf higkeit des Systems auf jedem der verteilten Entwickler Arbeitspl tze zu gew hrleisten Obwohl die Verwendung des Reflection Mechanismus zu keinerlei Problemen f hrte handelt es sich um eine nicht gerechtfertigte Entwurfsvariante da die Verwendung von Reflection Mechanismen grunds tzlich auch Nachteile mit sich bringt z B Verringerung der Typsicherheit Korrekterweise h tte als L sung die Implementierung von Stellvertretern f r noch nicht fertige Klassen erfolgen m ssen auch wenn damit ein etwas h herer Aufwand verbunden gewesen w re Die Testbarkeit des Systems wurde durch diese Entscheidung jedoch nicht beeintr chtigt Ohne Reflectionmechanismen werden die Auswahlschnittstellenklassen
28. in jeder der drei Architekturschichten Teilkomponenten zu realisieren e Die Projektplanung sah Meilensteine entlang den Schichten des Systems vor Als Basis f r die weitere Implementierung erfolgte nach dem Entwurf zun chst die Realisierung der au erhalb der Drei Schicht Architektur ben tigten Basiskomponenten Anbindung Persistenzrahmenwerk Protokollierung Synchronisation Meldungswesen und der Entwurf von Templateklassen f r die zu realisierenden Komponenten der Drei Schicht Architektur Als erste Schicht der Anwendung wurde darauf aufbauend die Datenhaltungsschicht implementiert Der n chste Meilenstein sah die Entwicklung der Anwendungslogik vor und der letzte Projektschritt umfasste die Realisierung der Benutzerschnittstellen Alle Projektmitglieder arbeiteten folglich parallel der Implementierung derselben Architekturschicht Die Zwischenergebnisse aller Beteiligten standen ber ein System zur Versionsverwaltung CVS allen Entwicklern permanent zur Verf gung Als verbindliche projektinterne Richtlinie wurde vereinbart dass der im CVS verf gbare Stand in jeder Phase der Entwicklung kompilierf hig sein musste Da wie eingangs beschrieben die Entwicklung und Durchf hrung von Teststrategien kein expliziter Bestandteil des Praktikums war wurde ohne n here Planung durch diese Vorgehensweise parallel zur Implementierung implizit sofort mit dem Integrationstest begonnen Ein isolierter Test von kleineren Teileinheiten des Sys
29. sungsvorschl ge zur Vermeidung der erkannten Probleme zu geben Die Umsetzung eines Teils der L sungsvorschl ge erfolgt w hrend der Refaktorisierung von SeminarlS siehe Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung 10 2 Entwurfs berblick SeminarlS Als Einstieg f r die Auseinandersetzung mit der Architektur und dem Entwurf von SeminarlS dient das in der Entwurfsphase geplante aber durch verschiedene Entwurfsfehler in dieser Form nicht verwirklichte Klassendiagramm der Anwendung Die vorgesehenen Abh ngigkeiten zwischen den einzelnen Komponenten sind durch Pfeile dargestellt SchnittstelleP Firmenerwatung PersonenverwaltungP SeminarbelegungP ExceptionP MeldungP SynchronisationP eminarverwaltungP AnwendungslogikP FirmenverwaltungP PersonenverwaltungP S SeminarbelegungP eminarverwaltungP ExterneSysterneP DruckerP JavaDocP KonfigurationP OrdnerP TransformationenP PersistenzP ProtokollP ErweitertPersistent ErweitertPersistent Abbildung 98 Paketdiagramm SeminarlS Entwurfsphase In der Abbildung fehlen demzufolge alle w hrend der Implementierungsphase eingef gten zus tzlichen Abh ngigkeiten zwischen den dargestellten Paketen Diese im Entwurf nicht vorgesehenen Abh ngigkeiten werden beinahe ausnahmslos im Rahmen der Di
30. tsklassen auch umfangreiche Gesch ftslogik implementiert war die sinnvollerweise in die Kontrollschicht geh rt h tte Bei der Refaktorisierung wurden demzufolge gro e Teile der vorhandenen Logik in die Kontrollschicht verlagert in die N he der aufrufenden Methoden der Rest der Logik wanderte in die Ordner und Relationenklassen zu den aufgerufenen Methoden Alle Aufrufe der Fassadenmethoden aus der Kontrollschicht konnten anschlie end auch hier in direkte Aufrufe der eingebetteten Methoden der Ordner und Relationenklassen umgewandelt werden Der Aufwand f r diesen Teil der Umgestaltung betrug etwa 9 gt Stunden Eine Zuordnung des Aufwands auf einzelne Klassen ergibt sich aus folgender bersicht Refaktorierte Klasse jeweils einschlie lich implementiertes Interface Belegung FimenSemmameranstaltung Geschaettspanner SE OeffentlicheSeminarveranstaltung Seminarveranstaltung a Dozentenvereinbarung 65 I Gesamt Abbildung 120 Aufwand f r Entfernung von Methoden mit Logik Aufwand in Minuten 11 6 3 Ergebnisse Nach der Entfernung s mtlicher Fassaden und Gesch ftslogik aus der Datenhaltung ergibt sich folgendes Bild f r die Projektmetriken Project Metrics Zeroalue 60 35496 81 0 39 0 NCDC 106 0 5 0 35 351147 36 0 NSBC 25 0 NCDC 70 0 9 0 Abbildung 121 Projektmetriken vor und nach Entfernung der Fassaden und Gesch ftslogik aus Datenhaltung
31. 0 1 to class AnfrageStellenAA AnfrageStellenK 1 0 1 0 1 8 12 create and access DruckDokumentDK SeminarisK 1 0 1 2 5 2 9100 4 static access SachbearbeiterA SVVorbereitenAA 1 0 11 9 0 1 to class BelegungAusw aehlenAA BelegungStornierenAA 1 0 0 19 0 0 33 3 create and access Erw eitertPersistent SeminarisDatenbank 1 0 1 1 7 4 4100 1 static access SVVorbereitenAA SVVorbereitenK 1 0 1 1 6 0 0 10 10 create and access TeilnehmerAnmeldenAA TeilnehmerAnmeldenK 1 0 116 0 1 25 4 create and access BelegungStornierenAA BelegungStornierenK 1 0 1 16 0 1 50 2 create and access SVAusw aehlenAA FSVErfassenAA 1 0 0 16 0 5 33 create and access BelegungAusw aehlenAA BelegungAendernAA 1 0 0 16 0 0 50 2 create and access SachbearbeiterA SVDurchfuehrenAA 1 0 1 1 6 1 to class SVKurzS Seminarv eranstaltung 1 0 1 8 to abstract class FSVErfassenAA FSVErfassenK 1 0 1 12 0 4 33 3 create and access BelegungAendernAA BelegungAendernK 1 01 12 0 41 50 2 create and access Abbildung 103 Abh ngigkeitsmetriken ohne Reflection Aufrufe der Schnittstellenklassen 10 3 2 Auswirkungen auf die Testbarkeit Im Modultest m chte man eine Komponente m glichst isoliert von allen anderen Komponenten des Systems testen H ngt wie in SeminarlS eine Klasse im Durchschnitt von knapp 90 anderen Klassen ab Metrik ACD so f hrt dies zu folgenden Problemen e Ohne den Einsatz von Stellvertretern m ssen f r den Modultest alle abh ngigen Klassen kompili
32. 30 testkritischen Abh ngigkeiten f r eine Untersuchung und Bewertung ausgew hlt deren Entfernung den gr ten Beitrag zur Verbesserung der Unabh ngigkeit der Komponenten leistet Zur Bestimmung des Grads der Unabh ngigkeit der Komponenten wurde die Metrik ACD verwendet die die Anzahl der Klassen angibt mit denen jede Klasse des Systems im Durchschnitt direkt oder indirekt ber Abh ngigkeiten verbunden ist Mit Hilfe der Reduktionsmetrik rACD konnte dann die Identifizierung der 30 zu untersuchenden testkritischen Abh ngigkeiten erfolgen Die Analyse dieser testkritischen Abh ngigkeiten zeigte dass SeminarlS unter einigen massiven Testproblemen litt Beinahe alle untersuchten Abh ngigkeiten wiesen auf eines oder auch mehrere dieser Probleme hin Die aufgedeckten Testprobleme waren bedingt durch ung nstige Entwurfsentscheidungen oder Implementierungsfehler bei der Umsetzung des Entwurfs Dies wurde zum Anlass genommen eine n here Untersuchung der Entwurfsprobleme vorzunehmen Daraus resultierte eine eingehende Beschreibung der Probleme und ihrer konkreten Auswirkungen auf die Testbarkeit von SeminarlS e Die Verletzung von Hierarchien in Schichtenstrukturen f hrt ber das Entstehen von Abh ngigkeitszyklen zu einem immensen Anstieg der Abh ngigkeiten SeminarlS ist hiervon besonders stark und in verschiedensten Varianten betroffen L sst man einen ohne Not an einer Stelle eingef gten Reflection Mechanismus au er Betracht der 126
33. 92 Bewertung In der Anforderungsspezifikation hei t es im main flow zum Anwendungsfall Teilnehmer anmelden Eine Person meldet sich telefonisch oder schriftlich f r eine ffentliche Seminarveranstaltung an Der Kundensachbearbeiter pr ft ob die gew nschte Seminarveranstaltung existiert Die Seminargeb hr wird vereinbart und eine entsprechende Belegung erzeugt Die in der Anforderungsspezifikation vorgeschriebene Auswahl einer Seminarveranstaltung wurde beim Entwurf von sSeminarlS derart realisiert dass hierdurch eine Abh ngigkeit dieses Anwendungsfalles mit den Anwendungsf llen zur Bearbeitung einer Seminarveranstaltung entstand siehe Abschnitt 10 8 Dies f hrt zur Abh ngigkeit der zu den Anwendungsf llen implementierten Schnittstellenklassen und den damit verbundenen Testproblemen 9 2 10 SeminarisH Sachbearbeiter A 9 2 10 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken Abbildung 55 Abh ngigkeitsmetriken SeminarisH SachbearbeiterA 67 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 2 04 2 0 2 0 0 2 5 0 of 5 0 z Al 89 65 Abbildung 56 Komponentenmetriken SeminarisH A und Sachbearbeiter A Auff lligkeiten bei den berechneten Werten Die Klasse SeminarisH besitzt als Hauptschnittstellenklasse nur eine geringe Zahl von Abh ngigkeiten zu anderen Klassen cd Beide Abh ngigkeiten sind
34. Abh ngigkeit die errechneten Werte der Metriken angezeigt die von Ihnen im Startdialog ausgew hlt wurden Auff llige Metrikwerte sind in der Tabelle farbig hinterlegt Im rechten Teil der Anzeige werden Ihnen zu der auf der linken Seite ausgew hlten Abh ngigkeit die Stellen des Sourcecodes angezeigt die Ausl ser f r die Abh ngigkeit zwischen den Komponenten sind Die Anzeige erfolgt ebenfalls in Tabellenform Zu jeder ausl senden Abh ngigkeit wird der Typ der Abh ngigkeit und der zugeh rige Ausschnitt aus dem Sourcecode angezeigt Sobald Sie im linken Teil der Anzeige eine andere Abh ngigkeit selektieren wird die Anzeige im rechten Teil automatisch aktualisiert Zwischen den beiden Unterfenstern Metriktabelle und Tabelle der Einzelabh ngigkeiten k nnen Sie zwei kleine Pfeile erkennen Mit Hilfe dieser beiden Pfeile k nnen Sie wahlweise eines der beiden Fenster ausblenden und das jeweils andere Fenster auf die komplette Breite des Panels Dependency Metrics vergr ern Um ein Kontextmen angezeigt zu bekommen das Ihnen die Funktionalit t anbietet die in der jeweiligen Anzeige zur Verf gung steht klicken Sie mit der rechten Maustaste in eine der beiden Tabellen Eine detaillierte Beschreibung der Ihnen zur Verf gung stehenden Funktionen finden Sie in Abschnitt 4 3 Funktionen Eine bersicht und Kurzbeschreibung des Kontextmen s erhalten Sie in Anhang Kontextmen s Kurz bersichten 169 Anhang Anzeige der Metrik
35. Die Navigation aus der Anzeige der Abh ngigkeitsmetriken in die Anzeige der Komponentenmetriken und umgekehrt soll m glich sein W hlt der Anwender ausschlie lich aus einem der beiden Bereiche Metriken zur Berechnung aus so soll auch nur eines der beiden Anzeigefenster existieren e Die graphische Darstellung der Abh ngigkeiten ist optional aus den Metrikanzeigen aufrufbar Sobald sie zum Aufruf kommt sollen die in den Metriktabellen angezeigten Abh ngigkeiten und Komponenten mit den in der Graphanzeige selektierten Graphelementen bereinstimmen Aus allen Anzeigekomponenten soll auf der Basis der aktuell selektierten Elemente die Navigation in den Texteditor oder den Diagrammmanager von Together m glich sein Aus der Anzeige der Testbarkeitsmetriken soll der erneute Start der Metrikanalyse m glich sein Dies soll entweder auf Basis der zuletzt vom Anwender getroffenen Auswahlen oder durch eine erneute Abfrage der zu berechnenden Metriken und Analyseoptionen m glich sein e Die Anzeige muss um weitere Komponenten f r die Anzeige der Metriken auf Paketebene erweiterbar sein Ein erster Entwurf hierzu wurde aufgrund offener Fragen bei der Berechnung der Metriken wieder verworfen Um dieses Zusammenspiel der genannten Teilkomponenten sicher zu stellen mussten mehrere Entwurfsvarianten siehe Beispiel 6 8 1 wieder verworfen werden nachdem zu erkennen war dass sie zu einem un bersichtlichen fehleranf lligen und wartungsunfreundl
36. Durchreichen des Methodenaufrufes selbst als Parameter bergeben muss Beispiel Dom nenklasse Firma public Iterator getAlleAnsprechpartner throws DatenbankAusnahme return naive Implementierung f hrt zu Programmfehler FirmenAnsprechpartnerRelation getEinzigelnstanz getPersonen this Laut Signatur erwartet die aufgerufene getPersonen Methode der Assoziationsklasse FirmenAnsprechpartnerRelation als Parameter ein beliebiges Objekt vom Typ IFirma Die obige th i s Instanz erf llt diese Vorgabe Firma implements IFirma ber einen weiteren Zwischenschritt wird letztlich folgende Methode aufgerufen 100 Kapitel 10 Entwurfsprobleme und Testbarkeit private Iterator getFirmenAnsprechpartnerPaar IFirma f throws DatenbankAusnahme try Abfrage abfrage new Abfrage FirmenAnsprechpartnerPaar class StringBuffer sb new StringBuffer sb append SELECT FirmenAnsprechpartnerPaar ID FROM sb append FirmenAnsprechpartnerPaar sb append WHERE sb append firma Tupel tupel new Tupel tupel setze firma f abfrage setzeAnweisung sb toString abfrage setzeTupel tupel Iterator iter getDb abfrageAusfuehren abfrage Bei der beschriebenen Implementierung handelt es sich beim Methodenparameter um ein Objekt vom Typ Firma Dies f hrt an der gekennzeichneten Stelle zu einer vom Persistenz Rahmenwerk geworfenen Ausnahme Der Grund hier
37. Fassade den Methodenaufruf an die Ordnerklasse durchreicht Nachfolgend ein Beispiel f r diese Art der Methode public static Iterator getAlle throws DatenbankAusnahnme return SeminarveranstaltungOrdner getEinzigelnstanz getOeSVs Um die Ergebnismenge aus der Datenbank zu lesen erfolgt in der aufgerufenen Methode der Ordnerklasse unter Verwendung des Persistenz Rahmenwerks eine entsprechende Abfrage auf die Datenbank f r die als Muster die KlasseOeffentlicheSeminarveranstaltung verwendet werden muss public Iterator getOeSVs throws DatenbankAusnahme try Abfrage abfrage new Abfrage OeffentlicheSeminarveranstaltung class Iterator iter getDb abfrageAusfuehren abfrage Man sieht wie auf diese Weise eine zyklische Abh ngigkeit zwischen Ordner und Dom nenklasse entsteht die bei Beibehaltung der Fassadenfunktion der Dom nenklasse kaum vermieden werden kann Aus Sicht der Testbarkeit f hrt dies zu einer unn tigen Verschmelzung der Dom nen mit den Ordnerklassen die einen isolierten Test der Dom nenklassen unm glich macht 9 2 28 DozentenvereinbarungLoeschenK IDozentenvereinbarungK 9 2 28 1 Ergebnisse der Metrikberechnung pk 2 0 olis_int Isubedges 2 8 1 0 0 0 0 0 0 static access Abbildung 91 Abh ngigkeitsmetriken DozentenvereinbarungLoeschenK IDozentenvereinbarungK 81 Kapitel 9 Testbarkeitsanalyse ausgew hlter Ab
38. Klassentyp werden nicht als Abh ngigkeit erkannt B 9 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Knotentyp Nach Knotentyp Summary D_DEP FirmaLoeschenK T_CLASS IFirma T_INTERF Class D_V_TYPE FirmaLoeschenK T_CLASS IFirma T_INTERF Member Um den Bezug zur abh ngigkeitsverursachenden Methode nicht zu verlieren wird bei der auf Klassenebene eingef gten Abh ngigkeit eine Referenz auf den Methodenknoten gespeichert 147 Anhang Lesender Zugriff auf nicht statisches Klassenattribut B 10 Lesender Zugriff auf nicht statisches Klassenattribut B 10 1 Wird lesend auf den Wert eines Attributes einer Klasse zugegriffen so wird hierdurch eine Erl uterung und Beispiel Abh ngigkeit vom Typ D_USES definiert protected Firma transienteFirma abstract public class FirmaAendernErfassenK public Firma getObjektFirma return transienteFirma public class FirmaErfassenK extends FirmaAendernErfassenK B 10 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP FirmaErfassenK T_CLASS FirmaAendernErfassenK T_ABSTR Class D_USES FirmaErfassenK T_CLASS FirmaAendernErfassenK T_ABSTR Member D_USES getObjektFirma T_METHOD transienteFirma T_FIELD Wird auf ein Attribut innerhalb der eigenen Klasse
39. Komponentenmetriken einen eindeutigen Anhaltspunkt in Gestalt der Metrik rACD_in N 8 Component 5 8 5 SeminarisH 5 4 213 194 53 76 53 71 Dozentenvereinbarung 14 7 213 194 45 52 45 46 DVKostenBerechnenK 6 5 213 194 45 32 45 07 AbstractAAKlassenFabrik 2 1 213 194 36 75 36 7 AAKlassenFabrik 14 8 213 194 36 44 36 39 Seminaris Datenbank 12 7 213 194 16 95 16 6 SVAuswaehlenAA 13 12 213 194 11 88 11 83 BelegungAuswaehlenAA 13 11 213 194 10 54 10 49 SeminarisK 6 6 213 194 6 555 6 505 DozentenvereinbarungAuswaehlenAA 7 2 213 194 5 4 5 349 SeminartypAuswaehlenAA 11 10 213 194 4 603 4 553 LeitungsauftragAuswaehlenAA 13 10 213 194 4 603 4 553 DVAktionenAA 16 9 213 194 3 224 3 174 TeilnehmerAnmeldenAA 9 7 213 194 2 307 2 257 BelegungStornierenAA 8 3 213 194 2 307 2 257 Abbildung 127 Komponentenmetriken nach Einf hrung der Schnittstellenfabrik 11 7 4 Nachbesserung Letztlich resultiert die L sung des Problems wieder im Schaffen eines globalen abh ngigkeitsreduzierten Zugriffs auf das Hauptfenster der Anwendung Wir orientieren uns zun chst am Vorgehen aus Abschnitt 11 2 und verwalten das Hauptfenster in der im ersten Durchgang eingef hrten zentralen Klasse SseminarisSystem 123 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung public class SeminarisSystem private static IAAKlassenFabrik aaKlassenFabrik null private static JFrame hauptFenster null public static IAAKlass
40. Project Hetrics ZeroYyalue 11439 EN 44964 ACDh 60 35496 ACDh 51 44944 NFD 810 NFD 65 0 NSBC 39 0 NSBC 34 0 NCDC 106 0 840 50 30 Abbildung 128 Projektmetriken vor und nach abschlie ender Realisierung der AAKlassenFabrik Die Anzahl der Klassen von denen eine Klasse im Durchschnitt direkt oder indirekt abh ngig ist ist um 8 2 Prozent gesunken beschr nkt auf fest verdrahtete Abh ngigkeiten um immerhin 14 2 Prozent 124 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung Die Zahl der Abh ngigkeitszyklen hat sich echt von f nf auf drei reduziert keine Verschmelzung die Anzahl der zyklischen abh ngigen Komponenten hat sich dadurch um 20 8 Prozent verringert Ein Blick auf die Abh ngigkeits und Komponentenmetriken l sst erkennen dass insbesondere an den ersten 50 Abh ngigkeiten mit dem h chsten rACD Wert gt 0 48 Prozent keine Auswahlklassen mehr beteiligt sind 125 Kapitel 12 Zusammenfassung Teil IV Res mee Der letzten Teil dieser Arbeit umfasst eine Zusammenfassung und Bewertung der wichtigsten Ergebnisse der Arbeit Daran schlie t sich ein Ausblick auf notwendige und w nschenswerte Arbeiten im Rahmen der Weiterf hrung des Themas an 12 Zusammenfassung Mit Design2Test steht als Ergebnis des ersten Teils dieser Arbeit Softwareentwicklern k nftig ein Werkzeug zur Testbarkeitsanalyse als integrierter Bestandteil ei
41. Sie w hrend der Metrikauswahl die Schaltfl che Load Set un dtype Select All Unselect All set Defaults save Set As d Load Set Abbildung 14 Optionen Leiste im Metrikdialog Der dort angezeigte Dialog gleicht dem Dialog zum Speichern der Metriken gt Abbildung 13 6 1 4 Optionen f r die Metrikberechnung Standardm ig werden alle Komponenten des aktiven Projektes nach Abh ngigkeiten durchsucht und e als Ziel von Abh ngigkeiten nur die Komponenten des aktiven Projektes ber cksichtigt W hrend der Metrikauswahl gt 3 Metrikauswahl besitzen Sie die M glichkeit bestimmte Pakete oder Klassen von der Analyse auszuschlie en z B Testklassen Ferner k nnen Sie auf diesem Wege 180 Anhang Erweiterte Funktionen und Einstellungen Pakete und Klassen au erhalb des Projekts importierte Klassen als Ziel von Abh ngigkeiten zulassen Um die Standard Einstellungen zu ver ndern bet tigen Sie die Schaltfl che Options im linken unteren Teil des Metrik Dialogs Es ffnet sich folgender Auswahldialog Analyze Options ot Analyzed Components a Additional Target Components Abbildung 15 Analyze Options Dialog 6 1 4 1 Komponenten von der Analyse ausschlie en Sie haben im oberen Teil des Dialogs gt Abbildung 15 Analyze Options Dialog die M glichkeit bestimmte Klassen und Pakete von der Analyse auszuschlie en Die ausgeschlossenen K
42. allerdings statischer Natur cd_h 9 2 10 2 Bewertung In der Hauptschnittstellenklasse SeminarisH existiert die statische Variable MainWindow die bei der Erzeugung von SeminarisH mit der einzigen Instanz des Hauptanwendungsfensters initialisiert wird Auch hier wird in problematischer Weise die Absicht verfolgt einen globalen Zugriff auf diese Komponente zur Verf gung zu stellen siehe Diskussion in Abschnitt 10 6 Versch rft wird dieses Problem erneut dadurch dass auch aus der tiefer liegenden Kontrollschicht auf diese statische Variable zugegriffen wird und damit die Drei Schicht Architektur verletzt wird Lediglich der in der Klasse SachbearbeiterA realisierte Reflection Aufruf der initialen Schnittstellenklassen verhindert die zyklische Abh ngigkeit nahezu aller Systemkomponenten siehe Abschnitt 10 3 9 2 11 ErweitertPersistent SeminarisDatenbank 9 2 11 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken lis_feedb A 2 1 0 2 2 1 89 65 62 2 0 1 4 12 5 4 0 E EEEE 5 89 65 62 17 7 16 8 Abbildung 58 Komponentenmetriken ErweitertPersistent A und SeminarisDatenbank Auff lligkeiten bei den berechneten Werten Die Wert der Metriken rACD und rACDh ist stark beeinflusst vom Zugriff der Klasse SeminarisDatenbank auf die Datenhaltungsschicht siehe Abh ngigkeit 9 2 2 und Abschnitt 68 Kapitel 9 Testbarkeitsanalyse ausgew h
43. angef hrten Arten der Realisierung des Zugriffs die Gefahr in sich zu bergen durch versehentliche fehlerhafte und unkoordinierte Zugriffe hierarchische Strukturen von Anwendungssystemen zu beeintr chtigen wenn nicht sogar zu verhindern Dar ber hinaus f hrt die zentrale B ndelung dieser Basiskomponenten innerhalb einer Klasse Seminari sK dazu dass jede Komponente die auch nur von einer einzigen Basiskomponente abh ngig ist Abh ngigkeiten von allen weiteren 96 Kapitel 10 Entwurfsprobleme und Testbarkeit Basiskomponenten erf hrt In Abschnitt 11 2 erfolgt eine detaillierte Beschreibung m glicher alternativer Zugriffsstrategien und deren Diskussion und Bewertung aus Sicht der Testbarkeit Exkurs Nur am Rande erw hnt aber in diesem Zusammenhang sicherlich hochinteressant ist das technische Konzept der Firma Sun Microsystems mit ihrer Java 2 Enterprise Edition J2EE als umfangreicher Baukasten auf den bei der Realisierung von Anwendungssystemen zur ckgegriffen werden kann Die Grafik stellt das Architekturmodell der J2EE dar J2EE Application Server D DD Browser une Web Container 000 SSL Serverseitige Pr sentationslogik 7 LDAP Server KE Active Directory J2EE Server CORBA Server Java Client RDBMS EJB Container Gesch ftslogik Meurer oe og x KS MOM Mail ERP Systeme Abbildung 106 berblick J2EE Architektur Quelle www movingobje
44. auch f r die m glichen Komponenten des Abh ngigkeitsgraphen Elemente des Abh ngigkeitsgraphen summary level M gliche Abh ngigkeiten M gliche Komponenten D_DEP Klassen D SE Finale Klassen Abstrakte Klassen Interfaces class level M gliche Abh ngigkeiten M gliche Komponenten D_EXTEND D_THROW Klassen DIMPLEM D_NEW 222 2 Finale Klassen Abstrakte Klassen mn Interfaces D_CAST Innere Klassen D_INSTANC Anonyme Klassen CATCH MANU member level M gliche Abh ngigkeiten M gliche Komponenten D_USES Konstruktoren 777777 DUBAS SI Methoden Finale Method D DER P ee 9 inale Methoden Attribute z D CALL en u 22 57 0077 Deal 77 D_CALLIF CALL TI D CALL TS Die kursiv gedruckten Abh ngigkeiten existieren auch auf Klassenebene Abbildung 2 Zusammenfassender berblick ber Abh ngigkeiten und Komponenten im Graph 162 Anhang Benutzerhandbuch Design2ZTest Benutzerhandbuch Version 1 0 16 03 2003 163 Anhang Inhaltsverzeichnis Inhaltsverzeichnis 1 INSTALLATION E 165 2 SCHNELESTART OUICK TOUR este 166 3 55 167 d ANZEIGE DER 255
45. den Zugriff auf die verf gbaren Informationen und Programmkomponenten eines in Together verwalteten Softwaresystems Together Projekt In den tieferen Schichten ist auch der ndernde Zugriff auf das Modell m glich 10 Kapitel 5 Analyse IDE Diese Schicht stellt die Ausgabeschnittstelle dar Sie bietet den Zugriff auf alle Ausgabekomponenten der Entwicklungsumgebung Hier ber l sst sich die Interaktion mit dem Benutzer und die Pr sentation von Informationen steuern Diese Schicht enth lt keine Zugriffsmethoden auf die Modellelemente oder den Programmcode eines Together Projekts RWI Diese Schicht bietet den Zugriff auf alle in einem Together Projekt enthaltenen Modellelemente Bei den Modellelementen handelt es sich beispielsweise um die in Diagrammen angezeigten Pakete Klassen Attribute und Methoden Auch der Zugriff auf die darstellenden UML Elemente wie Klassen oder Interaktionsdiagramme ist in dieser Schicht m glich Die Informationen der Modellelemente k nnen abgerufen aber auch adaptiert werden Ferner k nnen dem Modell neue Elemente hinzugef gt werden e SCI Bei dieser Schicht handelt es sich um die am feinsten granulierte Ebene der internen Repr sentation eines Projekts durch Together ber diesen Weg ist der lesende und schreibende Zugriff auf den Sourcecode eines Together Projekts m glich Durch das Konzept der permanenten Synchronisation von Programmcode und Modellierung siehe Abschnitt 5 3 wird ber d
46. der ermittelten Abh ngigkeiten und der f r sie berechneten Metriken innerhalb der Entwicklungsumgebung Die schrittweise Verfeinerung und Ausarbeitung der Aufgabenstellung erfolgt zu Beginn des Entwicklungsteils dieser Arbeit Kapitel 4 Das zweite Teilziel dieser Arbeit sieht die Verwendung des entwickelten Werkzeugs vor Mit seiner Hilfe soll f r ein existierendes Softwaresystem der tats chliche Einfluss testkritischer Abh ngigkeiten untersucht und m glichst exakt bestimmt werden Hierbei sind im Wesentlichen folgende Aufgaben zu erf llen e Bewertung der als testkritisch identifizierten Abh ngigkeiten hinsichtlich ihrer Entstehung und Interpretation der Metriken e Erarbeiten von L sungsvorschl gen zur Beseitigung der Abh ngigkeiten beispielhafte Entfernung der Abh ngigkeiten und Einsch tzung des hierf r zu leistenden Aufwandes e Bestimmung und Vergleich des zu leistenden Testaufwandes vor und nach der Beseitigung testkritischer Abh ngigkeiten Die schrittweise Verfeinerung und Ausarbeitung der Aufgabenstellung erfolgt zu Beginn des Analyseteils dieser Arbeit Kapitel 8 Kapitel 3 Aufbau der Arbeit 3 Aufbau der Arbeit Teil Werkzeugerstellung f r Abh ngigkeitsanalyse dieser Arbeit beschreibt den bei der Werkzeugerstellung durchlaufenen Entwicklungsprozess beginnend mit der Anforderungsermittlung in Kapitel 4 Erg nzend zur Verfeinerung und Pr zisierung der Aufgabenstellung aus Kapitel 2 werden UML
47. des Together ControlCenters Nachdem sich schon bald zeigte dass einige Fehler in der Programmierschnittstelle direkten Einfluss auf den Realisierungsaufwand der Integration hatten wurde bald nach Ver ffentlichung des neuesten Releases auf die Version 6 0 gewechselt Bei der aktuellsten Version von Together handelt es sich augenblicklich um die Version 6 01 Leider ist die Programmierschnittstelle trotz einiger Verbesserungen und Erleichterungen auch in diesen Versionen weiterhin an einzelnen Stellen fehlerbehaftet Dazu mehr in den folgenden Abschnitten die sich der Implementierung der im Entwurf konzipierten Teilkomponenten widmen Ferner zeigte sich dass die Erweiterung von Together ber das Open eine u erst zeitaufw ndige und umst ndliche Angelegenheit darstellen kann Auf diese grunds tzlichen Probleme w hrend der Implementierung wird in einem abschlie enden Abschnitt n her eingegangen 7 2 Erweiterung von Together class Design2Test Um ein Modul ausf hren zu k nnen m ssen die class Dateien unter dem Modulpfad von Together STGH modules com togethersoft modules abgelegt sein TGHS bezeichnet hierbei das Installationsverzeichnis des ControlCenters Together durchsucht s mtliche in diesem Modulpfad abgelegten Verzeichnisse auf das Vorhandensein einer Manifest Datei die das Modul und dessen Eigenschaften deklariert Nachstehend die Manifest Datei des ausgelieferten Moduls Design2Test Name D
48. die SeminarlS vor der Refaktorisierung vorhandenen Testprobleme zu einem au erordentlich hohen Aufwand bei der Erledigung der Testaufgaben gef hrt h tten 48 Kapitel 8 Einf hrung 8 2 Beschreibung des zu analysierenden Softwaresystems Als Fallbeispiel bot sich die Analyse eines Projekts an an dessen Erstellung der Verfasser dieser Arbeit im Rahmen eines Software Praktikums am Lehrgebiet Praktische Informatik der FernUniversit t Hagen im Sommersemester 2001 beteiligt war Bei diesem Software Projekt handelt es sich um ein Seminar Informationssystem SeminarlS das eine fiktive Schulungsfirma bei der Planung und Durchf hrung von Seminaren sowie der Verwaltung ihrer Kundendaten unterst tzen soll An der Entwicklung des Projekts waren insgesamt acht Studenten der FernUniversit t beteiligt Der gesamte Entwicklungsaufwand d rfte grob gesch tzt bei etwa 9 Personenmonaten gelegen haben Die Realisierung erfolgte auf Basis des Kurses Software Engineering II Objektorientierte Softwareentwicklung der FernUniversit t Hagen SWEII99 Als Programmiersprache war Java f r die Implementierung vorgegeben Die Realisierung erfolgte entsprechend der Vorgabe in einer Drei Schicht Architektur bestehend aus den Schichten Benutzerschnittstelle Anwendungslogik und Datenhaltung Als Datenbanksystem fand die zum damaligen Zeitpunkt als Open Source verf gbare relationale Datenbank nstantDB http instantdb tripod co
49. die Refaktorisierung blieb an dieser Stelle jedoch leider keine Zeit mehr 7 5 Komponente Analysesteuerung package analysis Eine der Aufgaben der Komponente zur Analysesteuerung umfasst auch den Start der Abh ngigkeitssuche Aus folgendem Programmfragment der Klasse ComputeMetrics wird nochmals die Vorgehensweise bei der Benutzung der Suchkomponente deutlich recurse through the model and searches for dependencies DependencySearcher dependencySearcher new DependencySearcher dependencySearcher setDependencySearchListener DependencyGraph getInstance dependencySearcher setSearchScope new ConfigSearchScope dependencySearcher search Nach der Erzeugung der Suchkomponente wird zun chst der erzeugte Abh ngigkeitsgraph zur Benachrichtigung ber die gefundenen Abh ngigkeiten angemeldet Nachdem die vom Anwender eingegebenen Suchoptionen gesetzt wurden wird die Suche nach Abh ngigkeiten gestartet 42 Kapitel 7 Implementierung 7 6 Komponente Metrikauswahl package selection Um das Modul unabh ngig von nderungen hinsichtlich der in ImproveT verf gbaren Metriken zu halten wurde f r den Zugriff auf die implementierten Testbarkeitsmetriken der Reflection Mechanismus von Java verwendet Als Basis f r den Zugriff dienen Konfigurationsdateien in denen jene Metriken eingetragen werden die f r die Testbarkeitsanalyse verf gbar sein sollen Damit ist beispielsweise beim Hinzukommen neuer Metrike
50. die Untersuchung dieser Frage auch ein Softwaresystem besser geeignet das unter weniger gravierenden Entwurfsm ngeln leidet um in diesem Zusammenhang den Einfluss von allgemeinen Entwurfsproblemen auf die Testbarkeit gering zu halten In der aktuell verf gbaren Version wurde mproveT um die F higkeit erweitert aus den Daten des Abh ngigkeitsgraphen Informationen ber polymorphe Abh ngigkeiten zu ermitteln Diese Information wurde bei der Erstellung der vorliegenden Arbeit noch nicht ber cksichtigt Polymorphie und dynamische Bindung erschweren den Test objektorientierter Programme da sie zu einer Vermehrung der potenziellen Ablaufpfade f hren und damit zu einer Vermehrung der potenziellen Fehler SnWi01 Die Anzeige der polymorphen Abh ngigkeiten kann eine Einsch tzung dieses Problems f r ein Konkretes System erm glichen Im Rahmen dieser Arbeit war urspr nglich geplant ber Design2Test die Metrikberechnung auch f r Abh ngigkeiten auf Paketebene anbieten zu k nnen mproveT stellt hierf r bereits grunds tzliche Funktionalit t zur Verf gung Allerdings ist hier noch die Frage der genauen Zuordnung von Klassen zu Paketstrukturen zu kl ren Dies war auch der Grund daf r dass die Umsetzung in Design2Test nach einer bereits vorhandenen ersten prototypischen Realisierung wieder zur ckgestellt wurde 129 Literaturverzeichnis Literaturverzeichnis Beck00 Beiz94 Bind94 Bind99 Coop98 DoFr94
51. einer bereits vorhandenen Metrikanzeige Die Analyse erfolgt auf Basis der zuletzt ausgew hlten Metriken und der aktuell eingestellten Suchoptionen Die ermittelten Abh ngigkeiten und alle Komponenten des Projekts werden gemeinsam mit den berechneten Testbarkeitsmetriken in Tabellenform angezeigt In der Anzeige der Abh ngigkeitsmetriken werden zu jeder auf Klassenebene existierenden Abh ngigkeit die berechneten Abh ngigkeitsmetriken angezeigt Selektiertt der Benutzer eine der Abh ngigkeiten so werden die Stellen des Sourcecodes angezeigt die Ausl ser der Abh ngigkeit sind In der Anzeige der Komponentenmetriken werden zu jeder im Projekt existierenden Komponente Klasse die berechneten Komponentenmetriken angezeigt Selektiert der Benutzer eine der Komponenten so werden die Komponenten angezeigt mit denen die Komponente in Abh ngigkeit steht Dabei wird unterschieden nach Klassen die von der ausgew hlten Komponente abh ngig sind und Klassen von denen die Komponente selbst wiederum abh ngig ist alternate flow Metriken ausw hlen Der Benutzer m chte die zu berechnenden Testbarkeitsmetriken ver ndern Er erh lt die f r die Analyse verf gbaren Testbarkeitsmetriken erneut zur Auswahl angeboten und kann eine neue Metrikmenge zusammenstellen extension point Metriken ausw hlen alternate flow Suchoptionen einstellen Der Benutzer ver ndert die Einstellung der Programmkomponenten Pakete Klassen die bei der Suche nach Abh n
52. erfassen besteht f hrt dies sogar zu einer zyklischen Abh ngigkeit der Schnittstellenklassen beider Anwendungsf lle Die umgekehrte den Zyklus schlie ende Verkn pfung erfolgt durch Abh ngigkeit 9 2 7 LeitungsauftragAendernErfassenAA SVAuswaehlenAA 9 2 6 SeminartypAendernErfassenAA DozentenvereinbarungAuswaehlenAA 9 2 6 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken gen La gt Is Is 1 5 d_type e le lu 5 A lt lt lt lt lt lt D 0 0 0 1 3 Abbildung 47 Abh ngigkeitsmetriken SeminartypAendernErfassenAA DozentenvereinbarungAuswaehlenAA 63 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 7 0 6 0 3 3 2 1 ER 4 4 106 80 77 1 7 2 0 Abbildung 48 Komponentenmetriken SeminartypAendernErfassenAA A und DozentenvereinbarungAuswaehlenAA B Erl uterungen zu den Abh ngigkeitsmetriken Diese Abh ngigkeit wiederum ist kein Teil eines Zyklus dep_comp Sie verl uft jedoch ebenfalls ber Paketgrenzen hinweg is_intpk Der rACD Wert liegt etwa in H he des rACDh Wertes Das Entfernen der Abh ngigkeit hat keine Auswirkungen auf Zyklen Die Abh ngigkeit wird durch Erzeugung eines Objekts ausgel st auf das dann mehrfach zugegriffen wird d_type sub_hw und subedges Erl uterungen zu den Komponentenmetriken Beid
53. es prinzipiell m glich bei Vorliegen eines Zyklus zwischen zwei Klassen zu entscheiden ob der Test der Methoden durch eine geeignete serialisierbare Testreihenfolge ohne Implementierung von Teststellvertretern durchgef hrt werden kann Wint00 Die Informationen ber diese Abh ngigkeiten werden derzeit noch nicht ausgewertet Together bietet dem Anwender ferner die M glichkeit in Klassendiagrammen manuelle Abh ngigkeiten zwischen Programmkomponenten zu definieren Diese Abh ngigkeiten werden bei der Analyse ebenfalls erkannt Eine vollst ndige bersicht ber alle in einem Java Programm m glichen Abh ngigkeiten findet sich in Anhang B Diese Beschreibung ist bereits um die Modellierungsaspekte der Abh ngigkeiten in dem f r den Export nach mproveT zu erzeugenden Abh ngigkeitsgraphen erweitert siehe auch Abschnitt 5 6 3 5 5 2 Lokalisierung der Abh ngigkeiten Together Nach der Aufgabenstellung m ssen bei der Feststellung der Abh ngigkeiten sowohl Abh ngigkeiten aufgrund der in Together m glichen Entwurfsmodellierung als auch der darauf aufbauenden Implementierung des Programms erkannt werden Wie bereits bei der einleitenden Charakterisierung von Together beschrieben siehe Abschnitt 5 3 besitzt Together die in diesem Zusammenhang vorteilhafte Eigenschaft dass Modell und Implementierung zu jedem Zeitpunkt des Entwicklungsprozesses konsistent gehalten werden Wird beispielsweise in einem Klassendiagramm eine neue Kla
54. getEdgeMetricsTableModel TableModel nodeMetricsTable MetricsTable getNodeMetricsTableModel TableModel analyzeOptions AnalyzeOptions getSelectedEdgeMetricClassNames Yector btnSelectAllJButton getSelectedNodeMetricClassNames Vector btnUnselectAll JButton getEdgeMetricSelectionPattern Yector binSetDefaults JButton getNodeMetricSelectionPattern Vector btnSave JButton setEdgeMetricSelectionPattern void btnLoad JButton setNodeMetricSelectionPattern void panDescription JEditorPane setAllMetricsSelected void btnOptions JButton setAllMetricsNotSelected void btnStart JButton isMetricSelected boolean btnCancel JButton setDefaultMetrics void startWVasPressed boolean SelectMetrics edgeMetricsTableModel EdgeMetricsTableModel nodeMetricsTableModel NodeMetricsTableModel tables MetricsTable EdgeMetricsTableModel AbstrachWetricsTableModel NodeMetricsTableModel SelectMetricsDialog createDialog void createRootPane void AnalyzeOptionsDialog showDialog void LoadMetricsFromfFileDialog endswithStart boolean analyzeOptions AnalyzeOptions getEdgeMetricsClassNames Vector dialog JDialog edgeSelections Vector getNodeMetricsClassNames Vector dlyBounds Rectangle nodeSelections Vector repaintTables void rootPane JPanel closeDialog void biilgnoreComponents JTextField LoadMetricsFromFileDialog btAddTargetComponents JTextField getEdgeSelections Vector Metric
55. hingegen im Rahmen der Bearbeitung und Erfassung von Datens tzen aufgerufen um eine ber eine Assoziation verbundene Entit tsinstanz auszuw hlen Durch diesen Aufruf der Auswahlmasken aus anderen Anwendungsf llen entstanden die eingangs beschriebenen Abh ngigkeiten Grunds tzlich f hrt somit jeder Anwendungsfall der ber einen exceptional oder alternative flow in einen anderen Anwendungsfall verzweigt zur Abh ngigkeit der jeweiligen Schnittstellenklassen Verlaufen die flows wechselseitig in beide Richtungen so entstehen zudem zyklische Abh ngigkeiten 10 8 2 Auswirkungen auf die Testbarkeit Die beschriebenen Querverbindungen der Anwendungsf lle sind im Programmcode ber statische Methodenaufrufe fest verdrahtet Nachstehend ein Ausschnitt aus dem Anwendungscode der beispielsweise zur Entstehung der Abh ngigkeit 9 2 3 f hrt abstract public class SVAendernErfassenAA extends SeminarisFrame public void seminartypZuordnen boolean go true if go SeminartypAuswaehlenAA seminartypAuswaehlenAA SeminartypAuswaehlenAA erzeuge this String stSchluessel seminartypAuswaehlenAA oeffnenAuswahl Man erkennt dass die Objekterzeugung mit Hilfe der statischen erzeuge Methode der Klasse SeminartypAuswaehlenAA erfolgt Dies f hrt an dieser Stelle wiederum zu den bereits mehrfach beschriebenen Problemen bei der Durchf hrung von Unit Tests Ohne nderung der Implementierung der zu testenden Klasse kann ein E
56. hlt Eine umfassende Beschreibung von ImproveT und Together erfolgt im Rahmen der Analyse der zu integrierenden Werkzeuge und ihrer Schnittstellen in Kapitel 5 Zur Erf llung der ersten Teilaufgabe dieser Diplomarbeit war die Integration von mproveT in Together vorgesehen Im Rahmen der Integration sollte im Einzelnen folgende Funktionalit t realisiert werden e Ansto en der Testbarkeitsanalyse ber die Men struktur von Together mit der M glichkeit zur Auswahl der zu berechnenden Testbarkeitsmetriken e Analyse der in Together verwalteten Modellelemente Diagramme Sourcecode in bezug auf Abh ngigkeiten zwischen einzelnen Programmkomponenten e Ermittlung dieser Abh ngigkeiten und Export nach mproveT e Starten der Abh ngigkeitsanalyse durch mproveT e Darstellung der von mproveT berechneten Testbarkeitsmetriken f r die im Abh ngigkeitsgraphen gespeicherten Abh ngigkeiten und Programmkomponenten in Listenform mit Sortierm glichkeit e Graphische Darstellung der Abh ngigkeiten und der beteiligten Programmkomponenten mit der M glichkeit zur Kennzeichnung der Graphelemente nach Ihrem Einfluss auf die Testbarkeit des Systems e M glichkeit der wechselseitigen Navigation zwischen der Listendarstellung von Abh ngigkeiten und Komponenten deren graphischer Darstellung und den in Kapitel 4 Anforderungsermittlung Together vorhandenen Modellelementen sowie dem Sourcecode der analysierten Software ber beispielsweise Konte
57. ngigkeiten E D lt 2 89 65 6218 8 8 2 89 65 6211 0 0 4 Abbildung 74 Komponentenmetriken SeminarisK A und DebugProtokollDateiA Auff lligkeiten bei den berechneten Werten Die rACD Werte der Klasse SseminariskK liegen massiv h her als der rACD Wert der Abh ngigkeit S mtliche von SeminarisK ausgehenden Abh ngigkeiten sind im Sourcecode fest verdrahtet 9 2 19 2 Bewertung Bei der Klasse DebugProtokollDateiA handelt es sich um die Implementierung des internen Fehlerprotokolls von Seminarl S Zur Verwendung des Fehlerprotokolls wurden allerdings keine Richtlinien festgelegt so dass die Verwendung nur sporadisch von einigen Entwicklern erfolgte Die Implementierung der Klasse DebugProtokollDateiA erfolgte v llig analog zur Klasse LogProtokollDateiA Bez glich der Einordnung der Abh ngigkeit siehe demzufolge vorstehenden Abschnitt 9 2 18 9 2 20 AnstellungRelation AnstellungPaar 9 2 20 1 Ergebnisse der Metrikberechnung o lis_feedb pk create and access Abbildung 76 Komponentenmetriken AnstellungRelation A und AnstellungPaar B Auff lligkeiten bei den berechneten Werten Die rACD Werte der Klasse AnstellungRelation liegen deutlich ber dem rACD Wert der Abh ngigkeit 9 2 20 2 Bewertung Die beiden beteiligten Klassen resultieren aus der transformierten Assoziation zwischen einer Firma und einer bei ihr angestellten Person Die Bewertung der Abh ngigkeiten zwischen
58. ngigkeitsgraph anzeigen A 2 10 Anwendungsfall Graph speichern use case Graph speichern actors Together Benutzer precondition Die Anzeige des Abh ngiskeitsgraphen ist sichtbar main flow Der Benutzer speichert die aktuelle Anzeige des Abh ngigkeitsgraphen in einem Grafikormat JPEG Alternativ kann auch die Struktur des Abh ngigkeitsgraphen in Textform XML Format gespeichert werden Der Speicherort ist vom Benutzer jeweils frei w hlbar postcondition Der angezeigte Graph wurde im gew nschten Format gespeichert end Graph speichern 138 Anhang Textuelle Anwendungsfallspezifikationen A 2 11 Anwendungsfall Graph drucken use case Graph drucken actors Together Benutzer Drucker precondition Die Anzeige des Abh ngigkeitsgraphen ist sichtbar main flow Der Benutzer w hlt die Druckeinstellungen und druckt den aktuell angezeigten Graph aus postcondition Die aktuelle Anzeige wurde ausgedruckt end Graph drucken 139 Anhang Inhaltsverzeichnis Anhang B bersicht m glicher syntaktischer Abh ngigkeiten in Java Programmen EINLEITUNG nase es a 141 JAVA ABH NGIGKEITEN eeessssssssssnsnsnsnsenenenennenenensnsnnnnenenenenennenenennsnensnenennenensnenennenensnsnensnsenenenen 143 BI VERERBUNG SUBCLASSING 0000 143 B 2 ERWEITERUNG EINES 5 5 00000000000000000 143 B 3 IMPLEMENTIERUNG EINES
59. on Diagram im Kontextmen der jeweiligen Komponentenspalte Es ffnet sich die Designer Pane von Together und die betreffende Komponente erscheint innerhalb des Diagramms selektiert 171 Anhang Anzeige der Metriken 4 3 5 Neuberechnung der Metriken Sie k nnen die erneute Berechnung der Metriken ber das Kontextmen der Metriktabellen ansto en Es stehen Ihnen hierf r zwei Varianten zur Verf gung e W hlen Sie den Men punkt Refresh um f r sowohl Abh ngigkeits als auch Komponentenmetriken eine neue Metrikberechnung zu starten Diese Neuberechnung erfolgt auf Basis der zuletzt ausgew hlten Metriken und der zuletzt eingestellten Rahmenbedingungen f r die Analyse des Sourcecodes e W hlen Sie den Men punkt Restart um den Auswahldialog f r Metriken komplett neu zu starten Sie k nnen so die Auswahl der Abh ngigkeits und Komponentenmetriken neu vornehmen und die Analyse Optionen ver ndern 4 3 6 Beschreibung von Metriken Sie k nnen zu jeder Metrik eine kurze Beschreibung erhalten Klicken Sie hierzu mit der rechten Maustaste in eine der Metrikspalten und w hlen Sie aus dem angezeigten Kontextmen den Men punkt Show Description Es wird ein Dialogfenster ge ffnet dem Sie die gew nschten Informationen entnehmen k nnen Metric Description x cd_h Number Of Hard Wired Component Dependencies Represents the number of hard wired dependencies to other classes Hard wired dependencies reduce the ability
60. so wird hierdurch eine Abh ngigkeit vom Typ D_CALL_TS definiert Der Aufruf einer statischen Methode einer u eren Klasse aus einer inneren oder anonymen Klasse wird nicht als klasseninterner Aufruf betrachtet sondern als Abh ngigkeit D_CALL_ST gespeichert 152 Anhang Instanzierung mittels new Operator public class Firma public static String getClassName return Firma public void protocol String meldung return getClassName meldung Ruft ein Konstruktor mittels der this Anweisung einen anderen Konstruktor derselben Klasse auf so wird dies ebenfalls als klasseninterne Abh ngigkeit zu einer statischen Methode Typ T_CONSTR gespeichert B 20 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary Class Member DALL 5 protocol T_METHOD getClassName T_METHOD Klasseninterne Abh ngigkeiten werden nur auf Memberebene gespeichert B 21 Instanzierung mittels new Operator B 21 1 Erl uterung und Beispiel Beim Erzeugen einer neuen Instanz einer Klasse mit dem Operator new wird eine Abh ngigkeit D_NEW festgestellt abstract public class FirmaAendernErfassenAA extends SeminarisFrame protected FirmaGesamtS firmaGesamtS new FirmaGesamtS B 21 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Handelt es sich bei dem
61. to test a class in isolation Abbildung 4 Hilfetext zu einer Metrik 4 3 7 Graphische Anzeige Wollen Sie eine graphische Darstellung des Abh ngigkeitsgraphen unter Ber cksichtigung der Metrikergebnisse erhalten so w hlen Sie aus dem Kontextmen der Metriktabellen den Men punkt Graph Eine detaillierte Beschreibung des daraufhin erscheinenden Anzeigefensters finden Sie in Abschnitt 5 Graphische Anzeige der Abh ngigkeiten 4 3 8 Anzeige der Projektmetriken Bei den Projektmetriken handelt es sich um Abh ngigkeitsmetriken Die M glichkeit der Anzeige steht Ihnen deshalb auch nur im Panel Dependency Metrics zur Verf gung W hlen Sie hierzu im Kontextmen der Metriktabelle den Men punkt Project Metrics Daraufhin wird ein kleines Fenster ge ffnet in dem Sie die entsprechenden Daten angezeigt bekommen 4 4 1 Projektmetriken f r das Gesamtprojekt In der Spalte exclude der Metriktabelle steht Ihnen der zus tzliche Men punkt Project Metrics without zur Verf gung W hlen Sie die Abh ngigkeiten die Sie entfernt sehen m chten und klicken Sie den Men punkt an um ein kleines Fenster zu erhalten in dem die Metrikwerte ohne die in der 172 Anhang Anzeige der Metriken Spalte exclude abgew hlten Abh ngigkeiten angezeigt werden gt 4 4 2 Projektmetriken nach Beseitigung von Abh ngigkeiten 4 3 9 Ausgabeformat nummerischer Metriken F r einige der Metriken k nnen Sie zwischen der Anzeige der absolute
62. void addEdgeSelection bserver o MyObserver void delete bservers void setGraphigraph ExtendedGraph void MouseListener MouselMotionListener GraphViewMouseHandler GraphviewMouseHandler graphYview TopologicalGraphview mouseQlicked e MouseEvent void mouseDraggedie MouseEvent woid mouseEntered e MouseEvent void mouseEkitedfe MouseEvent void mouseMoved e MouseEvent void mousePressed e MouseEvent void mouseReleased e MouseEvent void myShow void setSelectedNodein Node void setSelectedEdgefe Edge void getSelectedNode Node getSelectedEdge Edge entwuchten void paintig Graphics void getNearestElementgtint yiint Object selectNearestElement cint y int void mainfargs String void MarkNodesvYisitor Abbildung 10 ImproveT Schnittstelle zur Anzeige des Abh ngigkeitsgraphen Nach der Erzeugung einer Instanz von TopologicalGraphView wird dieser Instanz ein Abh ngigkeitsgraph zur Anzeige bergeben void setGraph ExtendedGraph graph ber die Methoden myShow und startSort l sst sich die Darstellung des Graphen ansto en Die Anzeige des in der Darstellung aktiven Graphelements l sst sich ebenfalls ber die ffentliche Schnittstelle der Klasse TopologicalGraphView steuern Dar ber hinaus stehen verschiedene Farbschemata f r die Kolorierung des Graphen zur Verf gung Jedes dieser Schemata hebt farblich bestimmte Testbarkeitsaspekte des Graphen hervor vo
63. wurde ist die Realisierung eines Zugriffs auf einzelne systemweit ben tigte Komponenten F r einen globalen Zugriff vorgesehen sind in SeminarlS u a folgende Komponenten e Datenbank inklusive Transaktionen Klasse SseminarisDatenbank Protokollierung Paket ProtokollP e Synchronisation Paket SynchronisationP Konfiguration Paket KonfigurationP e Hauptanwendungsfenster Klasse SachbearbeiterA Der Zugriff auf diese Komponenten erfolgte auf unterschiedliche Weise beispielsweise durch Verwendung von statischen Variablen in den Hauptklassen der Anwendungsschichten SeminarisK Database SeminarisK Protocol SeminarisK Sync SeminarisK Config und SeminarisH MainWindow Anders als in der Kontrollschicht wurde der Zugriff auf die Datenbankinstanz in der Datenhaltung ber die Implementierung der Methode getDb den Klassen ErweitertPersistent realisiert ber Vererbung wird die Funktionalit t dort an die Datenhaltungsklassen weitergegeben Dar ber hinaus werden an weiteren Stellen der Anwendung redundant lokale Variablen f r die Datenbank definiert oder es erfolgt der direkte Zugriff auf die Singleton Instanz der Datenbankklasse Schon die Tatsache dass in den Anwendungsschichten unterschiedliche Konzepte zur Bereitstellung der Datenbank implementiert sind zeigt die Unsicherheit wie der Zugriff auf globale Ressourcen am g nstigsten erfolgen sollte Wie sich in den Abschnitten 10 3 bis 10 5 gezeigt hat scheinen die
64. zur Erzeugung genutzten Konstruktor um den nicht implementierten Default Konstruktor einer Klasse so wird die Abh ngigkeit zur Klasse der neuen Instanz modelliert Um nicht den Bezug zu dem Attribut oder der Methode aus der der Aufruf erfolgt zu verlieren wird bei der auf Klassenebene eingef gten Abh ngigkeit eine Referenz auf den die Abh ngigkeit ausl senden Elementknoten gespeichert Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP FirmaAendernErfassenAA__ ABSTR FirmaGesamtS CLASS Class D_NEW FirmaAendernErfassenAA__ FirmaGesamtS CLASS Member Ist der Konstruktor implementiert der zur Erzeugung der neuen Instanz verwendet wird so f hrt die Abh ngigkeit auf Memberebene zu diesem Konstruktor Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary FirmaAendernErfassenAA_ FirmaGesamtS 55 55 D_NEW FirmaAendernErfassenAA_ FirmaGesamtS 1 55 Member D_NEW firmaGesamtS T_FIELD FirmaGesamts T_CONSTR 153 Anhang Initialisierung eines eindimensionalen Arrays B 22 Initialisierung eines eindimensionalen Arrays B 22 1 Erl uterung und Beispiel Bei der Initialisierung eines eindimensionalen Arrays mit dem new Operator wird eine Abh ngigkeit D_NEW_AR definiert public class InitArrayExample p
65. 0 0 0 dep to interface Abbildung 95 Abh ngigkeitsmetriken ParameterEingabeModel IAnfrageParameter Klasse cd_t ac _h_is cd_s_cu oh _ Jed_im cd_im_h cd_tr jed_h_tr Str rACD out _ _ jed_t_if hl 5 IC 5 _ Abbildung 96 Komponentenmetriken ParameterEingabeModel und IAnfrageParameter Auff lligkeiten bei den berechneten Werten Bei dieser Abh ngigkeit handelt es sich um die idealtypische Abh ngigkeit einer konkreten Klasse zu einem abstrakten Interface d_type Die Abh ngigkeit ist frei von statischen Zugriffen sub_hw subedges 9 2 30 2 Bewertung Diese Abh ngigkeit ist aus Sicht der Testbarkeit nicht zu beanstanden Der hohe rACD Wert f r diese Abh ngigkeit resultiert aus der Erweiterung des Interfaces IErweitertPersistent durch das Interface IAnfrageParameter In der Folge entsteht ber die Abh ngigkeit von IErweitertPersistent zu ErweitertPersistent die Abh ngigkeit von der Datenbank und Datenhaltung siehe Abschnitt 10 6 Zugriff auf globale Basiskomponenten 83 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 9 3 Adaption der Testbarkeitsmetriken Die n here Besch ftigung mit den Ursachen einzelner Abh ngigkeiten hat gezeigt dass die Metriken in manchen F llen zu granular angelegt sind siehe Abh ngigkeit 9 2 2 SeminarisK SeminarisDatenbank Hierdurc
66. 0 39 0 10 256409 9 0 5 0 80 0 102 0 106 0 3 7735825 74 0 81 0 8 641975 262 0 60 35496 Abbildung 97 Entfernung der Abh ngigkeiten von der Datenbank zur Datenhaltung Bemerkenswert ist hierbei dass nur eine der 12 ausgehenden Abh ngigkeiten von SeminarisDatenbank berhaupt einen von 0 verschiedenen rACD Wert besitzt wobei selbst dieser f r sich alleine v llig unkritisch ist 0 6 Und doch ergibt sich f r den aggregierten rACD_out Wert der Komponente ein extrem hoher Wert von 16 8 Diese Metrik kann zwar keine treffsichere Angabe zu den tats chlich ACD kritischen Abh ngigkeiten machen bietet aber einen guten Anhaltspunkt f r das Aufsp ren verdeckter Abh ngigkeiten 84 Kapitel 10 Entwurfsprobleme und Testbarkeit 10 Entwurfsprobleme und Testbarkeit 10 1 Einleitung Die Bewertung testkritischer Abh ngigkeiten im letzten Kapitel und erste Versuche zur Erstellung von Testf llen f r SeminarlS zeigten sehr schnell dass bei der Durchf hrung von Klassentests Unit Tests die Idealvorstellung des isolierten Tests einer Klasse nicht einmal ansatzweise realisiert werden konnte Zur Ergr ndung der Ursache muss die tats chliche Vorgehensweise bei der Erstellung des Projekts noch einmal r ckschauend beleuchtet werden e Die Verteilung der Teilaufgaben innerhalb der achtk pfigen Gruppe erfolgte in vertikaler Struktur Jedes der Projektmitglieder hatte in der Regel an den Anwendungsf llen orientiert
67. 000 WULFF Nikolaus Wer misst misst Mist Metriken zur Steigerung der Softwarequalit t JavaMagazin Ausgabe 04 2002 pp 17 23 April 2002 131 Anhang Inhaltsverzeichnis Anhang A Anwendungsf lle Testbarkeitsanalyse Inhalt ANWENDUNGSFALLDIAGRAMM 00 006 133 2 TEXTUELLE ANWENDUNGSFALLSPEZIFIKATIONEN 1 0 134 2 1 ANWENDUNGSFALL TESTBARKEITSMETRIKEN BERECHNEN 00 440 00 001 134 2 2 ANWENDUNGSFALL TESTBARKEITSMETRIKEN ERSTMALIG BERECHNEN 135 A 2 3 ANWENDUNGSFALL METRIKEN AUSW HLEN 0 4000 0 0 0 136 A 2 4 ANWENDUNGSFALL SUCHOPTIONEN 136 2 5 ANWENDUNGSFALL NAVIGATION ZUM SOURCECODE 8 136 2 6 ANWENDUNGSFALL NAVIGATION ZU KLASSENDLAGRAMNMT 137 A 2 7 ANWENDUNGSFALL METRIKEN SPEICHERN 20220 0 0 0000 137 A 2 8 ANWENDUNGSFALL METRIKEN DRUCKEN 2 4 40000000000 137 A 2 9 ANWENDUNGSFALL ABH NGIGKEITSGRAPH ANZEIGEN 138 A 2 10 ANWENDUNGSFALL GRAPH SPEICHERN 2200 2 4 0 4 400 00 138 A 2 11 ANWENDUNGSFALL GRAPH DRUCKEN 2 020 4 4 0 00000000 139 132 Anhang Anwendungsfalldiagramm Anwendungsfalldiagramm Die nachstehende Abbildung zeigt das Anwendungsfalldiagramm f r die To
68. 10 1 2 3 create and access Dozentenv ereinbarungRelation Dozentenv ereinbarungAnfragen 1 0 010 1 2 6 7 static access Dozentenv ereinbarungTripel DVSchluessel 1 0 01 0 0 8 5 7 create and access Seminarv eranstaltungOrdner OeffentlicheSeminarv eranstaltung 1 1 108 1 1 1 1 static access Dozentenv ereinbarungLoeschenK Dozenten ereinbarungK 0 0 008 1 0 1 1 static access Seminarty p Seminarty pOrdner 1 0 108 1 0 2 4 static access Abbildung 27 SeminarlS Abh ngigkeiten mit dem h chsten FACD Wert ber die ImproveT ist in der Lage in Abschnitt 1 3 vorgestellten Testbarkeits und Reduktionsmetriken hinaus zur genaueren Einordnung der Ergebnisse eine Vielzahl weiterer Informationen zu Abh ngigkeiten und Komponenten zu liefern Im Rahmen dieser Arbeit erfolgt eine Beschr nkung auf einige wenige dieser Kennziffern In den Darstellungen der Abh ngigkeitsmetriken sind dies Informationen e ob die betreffende Abh ngigkeit in einem Zyklus enthalten ist dep_comp e es sich um eine Kante handelt die einen Beitrag zur Aufl sung eines Zyklus leisten kann is_feedb e ob die Abh ngigkeit innerhalb desselben Paketes verl uft is_intpk e wie vielen Stellen im Sourcecode die Abh ngigkeit ausgel st wird subedges e wie viele dieser ausl senden Codefragmente statischer Natur sind bw und e welcher Abh ngigkeitstyp aus der Gesamtmenge der Abh ngigkeiten die konkrete Ausl ser einer Abh ngigkeit zwischen Klassen sind aus Testb
69. 10 3 Verletzung der Drei Schicht Architektur Vermutlich resultiert dies aus einem anderen Entwurfsproblem von SeminarlS der Realisierung der Dom nenklassen als Fassadenklassen die einen Teil der von Ihnen zu leistenden Aufgaben an andere Klassen delegieren siehe Abschnitt 10 7 Realisierung der Dom nenklassen als Fassaden Die Fassadenfunktionalit t der Klasse Dozentenvereinbarung verf hrte m glicherweise in diesem Fall dazu eine Delegation der Aufgabe an die Kontrollschicht vorzunehmen Die fachliche Anforderung des Anwendungsfalles Seminarveranstaltung kalkulieren konnte ohne die Funktionalit t der Klasse DVKostenBerechnenk realisiert werden Ein weiterer Zugriff auf die Klasse erfolgt lediglich aus einem deaktivierten Programmteil Somit kann die Klasse DVKostenBerechnenK und damit die hier diskutierte Abh ngigkeit ersatzlos entfallen Der Aufwand hierf r ist sehr gering siehe Abschnitt 11 2 Realisierung einer strikten Drei Schichten Architektur Nach der Refaktorisierung kann in der Klasse Dozentenvereinbarung der Test der abh ngigkeitsausl senden und entfernten Methode gibKosten entfallen Durch den Wegfall der Klasse DVKostenBerechnenK und der ausschlie lich von ihr genutzten Klasse Zeitpunkt ergibt sich eine weitere Reduzierung des Testaufwandes 9 2 2 SeminarisK SeminarisDatenbank 9 2 2 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken 40 0
70. 2 Ver ndern der Farbeinstellungen Um einen besseren berblick ber verschiedene Aspekte des Abh ngigkeitsgraphen und der errechneten Metriken zu gewinnen k nnen Sie den Graphen mit unterschiedlichen Farbschemata betrachten W hlen Sie hierzu im Kontextmen das Untermen Set Color Schema und einen der dort befindlichen Men punkte Normal Show Component Show Dependency Type Haben Sie im Modus Normal eine Komponente durch Anklicken ausgew hlt so wird die aktivierte Komponente rot und alle unmittelbar ber Abh ngigkeit verbundenen Komponenten orange angezeigt Klicken Sie auf eine durch eine der Kanten repr sentierte Abh ngigkeit so wird diese Abh ngigkeit rot und alle ber Abh ngigkeiten erreichbaren Komponenten des Abh ngigkeitsgraphen grau hinterlegt angezeigt Ferner sind in diesem Modus alle Feedback Kanten orange gekennzeichnet gt Abbildung 7 M chten Sie einen berblick ber alle Zyklen des Abh ngigkeitsgraphen gewinnen so w hlen Sie im Untermen den Men punkt Show Component Die existierenden Zyklen werden daraufhin verschiedenfarbig hervorgehoben Alle an einem Zyklus beteiligten Abh ngigkeiten und Komponenten werden in derselben Farbe dargestellt Dependency Graph x 51 ShowEdg ricsPane ShownNodffpetricsraxe Abbildung 8 Graphanzeige im Farbschema Show Component 176 Anhang Graphische Anzeige der Abh ngigkeiten Um sich einen berblick ber die Typen der Abh ngigkeiten
71. 5 65 169 41 222 22 252 nn 169 4 2 170 4 3 FUNKTIONEN IN DEN MGTRIKANZEIOEN 3 171 4 3 1 Navigation zum 171 4 3 2 Sortieren der Ergebnisse ss 171 4 3 3 Verkn pfungen von Abh ngigkeits und 171 4 3 4 Anzeige im seen ne 171 4 3 5 Neuberechnung der 172 4 3 6 Beschreibung von Aetriken sn enennenenenenne nennen 172 4 3 7 172 4 3 8 Anzeige der 172 4 3 9 Ausgabeformat nummerischer 173 4 3 10 Export der Meritergebuieee nennen 173 4 3 11 Druck der AMeirikergebuiege nennen ne 173 4 4 PROJEKTMETRIKEN 22 23 EE dee Ae 174 4 4 1 Projektmetriken f r das Gesoammmproiebt nennen 174 4 4 2 Projektmetriken nach Beseitigung von Jbb nugieketten nen 174 5 GRAPHISCHE ANZEIGE DER ABHANGIGKEITEN eneen 175 DARSTELEUNG E 175 5 2 FUNKTIONEN IN DER GRAPHANZEI
72. Abschluss der Arbeit bildet Teil IV Res mee Hier werden in Kapitel 12 noch einmal die wichtigsten Ergebnisse dieser Arbeit zusammengefasst und in Kapitel 13 ein Ausblick auf eine m gliche Fortf hrung der Arbeit zu diesem Thema gegeben Kapitel 4 Anforderungsermittlung Teil Werkzeugerstellung f r Abh ngiskeitsanalyse Im zweiten Teil dieser Arbeit wird die Entwicklung des integrierten Werkzeugs zur Abh ngigkeitsanalyse beschrieben Die Beschreibung orientiert sich an den verschiedenen Stufen des Entwicklungsprozesses und umfasst jeweils ein Kapitel f r die Anforderungsermittlung die Analyse den Entwurf und die Implementierung der zu entwickelnden Softwarekomponente 4 Anforderungsermittlung 4 1 Pr zisierung der Aufgabenstellung Erstes Ziel der vorliegenden Arbeit ist den Nutzern einer integrierten Entwicklungsumgebung innerhalb dieser Entwicklungsumgebung Funktionalit t zur Identifizierung testkritischer Bereiche in ihrem System zur Verf gung zu stellen siehe Aufgabenstellung in Kapitel 2 Zur Umsetzung des in Abschnitt 1 3 vorgestellten Konzeptes zur Identifizierung von testkritischen Abh ngigkeiten existierte bereits ein von Stefan Jungmayr implementiertes Metrikwerkzeug mit dem Namen mproveT Als Entwicklungsumgebung die um die Funktionalit t von mproveT erweitert werden sollte wurde das Together ControlCenter kurz Together der zwischenzeitlich von der Firma Borland bernommenen Firma Togethersoft ausgew
73. Anwendungsf lle verwendet um die funktionalen Anforderungen der zu realisierenden Software festzuhalten Um die Komplexit t in der Entwurfsphase zu reduzieren erfolgt die Zerlegung der Gesamtaufgabe in verschiedene Teilaufgaben Da die Realisierung der Teilaufgaben ganz entscheidend von den Eigenschaften und Schnittstellen der beiden beteiligten Systeme bestimmt ist erfolgt in Kapitel 5 zun chst eine Analyse der zu integrierenden Systeme und ihrer Schnittstellen Im Mittelpunkt des Interesses steht hierbei die von den Systemen gebotene Unterst tzung bei der Realisierung der Teilaufgaben Ausgehend von den identifizierten Teilaufgaben und auf Basis der vorgeschalteten Analyse erfolgt in Kapitel 6 der Entwurf der einzelnen Teilkomponenten Es werden Komponenten f r die Suche nach Abh ngigkeiten und die Erstellung eines Abh ngigkeitsgraphen entworfen eine Schnittstellenkomponente zur Steuerung der Metrikberechnung eine Komponente zur Auswahl der zu berechnenden Metriken und mehrere Ausgabekomponenten Zur Steuerung des Zusammenspiels aller Komponenten wird eine Koordinationskomponente eingef hrt Aufbauend auf den Entwurf erfolgt die Beschreibung ausgew hlter Teile der Implementierung in Kapitel 7 Dem erforderlichen Implementierungsaufwand entsprechend nimmt die Realisierung der Suchkomponente hier den gr ten Raum ein Den Abschluss des Kapitels bildet eine Beschreibung verschiedener Probleme bei der Implementierung Teil II Fallbeis
74. Anzeige der ausgew hlten Testbarkeitsmetriken Um eine Berechnung durchzuf hren gehen Sie wie folgt vor 1 2 3 ffnen Sie das Projekt das Sie analysieren m chten W hlen Sie im Hauptmen den Men punkt Tools Testability Metrics Aktivieren Sie in dem angezeigten Dialog die Metriken die Sie berechnen lassen m chten Zu jeder Metrik wird Ihnen im unteren Teil des Dialogs eine kurze Erl uterung angezeigt Sie k nnen auch eine Standard V orbelegung oder eine von Ihnen fr her gespeicherte Kombination w hlen gt 3 Metrikauswahl M chten Sie Pakete oder Klassen von der Analyse ausschlie en so k nnen Sie dies in einem weiteren Dialog vornehmen den Sie durch Bet tigen der Schaltfl che Options erreichen Wollen Sie Pakete und Klassen au erhalb des Projekts als Ziel von Abh ngigkeiten zulassen so k nnen Sie dies ebenfalls in diesem Dialog tun 6 1 4 Optionen f r die Metrikberechnung Nachdem Sie Ihre Auswahl getroffen haben bet tigen Sie die Schaltfl che Start Haben Sie Metriken aus der Kategorie Abh ngigkeitsmetriken ausgew hlt so werden Ihnen die Ergebnisse der Berechnung in einem Unterpanel Dependency Metrics der Message Pane von Together angezeigt Im rechten Teil des Anzeige Panels werden Ihnen zu einer Abh ngigkeit die Einzelabh ngigkeiten angezeigt ber ein Kontextmen stehen Ihnen weitere Aktionen zur Verf gung 4 1 Abh ngigkeitsmetriken Haben Sie Metriken aus der Kategorie Komponenten
75. Beispiel Wird innerhalb eines berwachten Programmteiles durch Verwendung einer catch Klausel ein Fehler abgefangen und behandelt so wird eine Abh ngigkeit vom Typ D_CATCH zur behandelten Ausnahme definiert public class SeminarisDatenbank extends Datenbank public static SeminarisDatenbank getEinzigelnstanz 1 try catch KonfigurationException ke B 7 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Knotentyp Nach Knotentyp Summary D_DEP SeminarisDatenbank T_CLASS KonfigurationException T_CLASS Class D_CATCH SeminarisDatenbank T_CLASS KonfiqurationException T_CLASS Member Um den Bezug zur abh ngigkeitsverursachenden Methode nicht zu verlieren wird bei der auf Klassenebene eingef gten Abh ngigkeit eine Referenz auf den Methodenknoten gespeichert B 8 eines Attributs einer Klasse B 8 1 Erl uterung und Beispiel Definiert eine Klasse ein Attribut vom Typ eines Objektes so wird eine Abh ngigkeit vom Typ D_F_TYPE definiert Zu den Objekttypen z hlen beispielsweise auch die mit der J 2 Platform 146 Anhang Typ einer lokalen Variablen Standard Edition J2SE ausgelieferten Wrapper Klassen Integer Boolean oder die Klasse String Die Java Basisdatentypen int boolean bleiben hingegen unber cksichtigt public class SeminarisDatenbank extends Datenbank privat
76. Dozentenvereinbarung besitzt immerhin zur H lfte Typabh ngigkeiten 1 die zu einem Gro teil zu Interfaces f hren 19 Welche Auswirkung eine hohe Anzahl von direkten und indirekten statischen Abh ngigkeiten Metrik cd_h_tr auf den Test einer Klasse haben kann soll beispielhaft f r alle untersuchten Abh ngigkeiten nachfolgend an der Klasse Dozentenvereinbarung veranschaulicht werden Der Metrik cd_h_tr zufolge ben tigt der Modultest von Dozentenvereinbarung ohne nderungen an der Implementierung statischen Zugriff auf wenigstens 65 andere Klassen bei der Durchf hrung von Testf llen Um die Auswirkung auf die Testdurchf hrung auf einfache Weise zu illustrieren wurde in der Klasse Dozentenvereinbarung ein Testtreiber zum Erzeugen einer Dozentenvereinbarung implementiert Dies bedeutet den Test einer einzigen vergleichsweise einfachen Methode Nachfolgende Abbildung veranschaulicht die in Seminar S vorhandenen Abh ngigkeiten durch Auflistung der beim Test geladenen Klassen Es handelt sich um die mit der Option verbose von der virtuellen Javamaschine gewonnene Information die um alle Eintr ge von Klassen bereinigt wurde die nicht zum Paket SeminarlS geh ren 53 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Loaded DatenhaltungP IErweitertPersistent Loaded DatenhaltungP ErweitertPersistent Loaded DatenhaltungP SeminarisP IDozentenvereinbarung Loaded DatenhaltungP SeminarisP Dozentenverein
77. GE 176 5 2 1 Aktualisierung der Anzeige 176 3 2 2 Ver ndern der Farbeinstellungen nennen 176 5 2 3 Navigation zum Sourcecode 177 5 2 4 Anzeige Kiloseen Diegramm 177 2223 Anzeige des qualifizierten 178 5 2 6 178 2 27 Druck der Goropbonuzeige E 178 6 ERWEITERTE FUNKTIONEN UND 4 8 0 0 179 6 1 D EE 179 6 1 1 Setzen der Metrrikouewsah 179 6 1 2 Speichern einer Metrrikougwah 179 6 1 3 Einlesen einer gespeicherten Merikouewab 180 6 1 4 Optionen f r die Met Eberecbuung nennen 180 6 2 METRIKANZEIGE 2 A 183 6 2 1 Speichern der 183 6 2 2 Druck der 184 6 3 EEN 185 6 3 1 Speichern des Abh ngigkeitsgraphen KMI Format 185 6 3 2 Speichern des Abh ngigkeitsgraphen 1 nennen 185 6 3 3 Druck der CGranboanzeige 186 ANHANG KONTEXTMEN S 2 8 187 164 Anha
78. Gamm94 5 01 90 1509126 7001002 Lako96 Link01 BECK Kent Extreme Programming Explained Embrace Changed Addison Wesley 2000 BEIZER Boris Testing Technology The Growing Gap American Programmer Jahrgang 7 Nr 4 1994 BINDER R V Design for Testability in Object Oriented Systems Communications of the ACM vol 37 pp 87 101 Sept 1994 BINDER Robert Testing Object Oriented Systems Addison Wesley 1999 COOPER James W The DesignPatterns Java Companion Addison Wesley Design Pattern Series 1998 DOONG FRANKL G The ASTOOT Approach to Testing Object Oriented Programs ACM Transactions on Software Engineering and Methodologie pp 101 130 1994 GAMMA Erich HELM Richard JOHNSON Ralph VLISSIDES John Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1994 MCGREGOR John D SYKES David A A Practical Guide to Testing Object Oriented Software Addison Wesley 2001 IEEE STD 610 12 1990 IEEE Standard Glossary of Software Engineering Terminology 1990 ISO IEC 9126 Software Engineering Product quality JUNGMAYR Stefan Testability measurement and software dependencies In Proceedings of the 12th International Workshop on Software Measurement Magdeburg Germany 179 202 October 7 9 2002 LAKOS J Large scale C software design Addison Wesley 1996 LINK Johannes Unit Tests mit Java Der Test first Ansatz
79. IT FirmaloeschenK T_CONSTR instance_init_1 T_INIT Da es sich um eine klasseninterne Abh ngigkeit handelt wird die Abh ngigkeit nur auf Member Ebene gespeichert B 30 Abh ngigkeiten zu vererbten Methoden und Attributen B 30 1 Erl uterung und Beispiel Beim Zugriff auf ein vererbtes Attribut bzw eine vererbte Methode wird von Together eine Referenz auf die Klasse geliefert in der die Komponente definiert wurde public class HinweisNachricht extends SeminarisMeldung static field ERROR is defined in superclass SeminarisMeldung public class FirmaloeschenkK public SeminarisMeldung pruefeloeschen SeminarisMeldung meldung meldung HinweisNachricht erzeuge Die Firma kann leider nicht gel scht werden n da sie noch Seminarveranstaltung en gebucht hat HinweisNachricht ERROR B 30 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary 0 T_CLASS SeminarisMeldung T_CLASS Class D_USES_ST FirmaLoeschenK T_CLASS SeminarisMeldung T_CLASS Member D_USES_ST pruefeLoeschen T_METHOD ERROR T_FIELD B 31 Manuelle Together Abh ngigkeiten B 31 1 Erl uterung und Beispiel Together bietet die M glichkeit manuelle Abh ngigkeiten zwischen zwei Diagrammelementen Pakete Klassen durch Einf gen einer gerichteten Kante zu modellier
80. Klasse dieser Teilkomponente ist die als Einzelst ck modellierte Klasse DependencyGraph Sie h lt als Attribut eine Instanz des zu exportierenden Abh ngigkeitsgraphen vom importierten ImproveT Iyp ExtendedGraph Ferner implementiert sie das Interface DependencySearchListener der oben entworfenen Suchkomponente siehe Abschnitt 6 3 Durch die Anmeldung als Listener beim DependencySearcher wird die Klasse ber alle existierenden Abh ngigkeiten Klassen und Operationen des zu analysierenden Softwareprojekts durch Aufruf der zu implementierenden Listener Methoden dependencyFound classFound undoperationFound informiert Dependency dependent SciElement dependee SciElement sourceCodeDetails SourceCodeReference Wpe short DependencySearchlistener DependencyGraph instance DependencyGraph depGraph ExtendedGraph analyzeOptions AnalyzeOptions logging Logging MEMBER int CLASS int 5UMMARYCLASS int Dependency getDependent SciElement getDependee SciElement getSourceCodeDetails SourceCodeReference getType short getMemberLevelName String getClassLevelName String getSummaryClassLevelName String getPackageLevelName String getinstance DependencyGraph DependencyGraph resetvoid getGraph ExtendedGraph dependencyFound void classFound void operationFound void createGraphEntryvoid createGraphEntry yoid createGraphEntry void doPostAnalysis void SourceCodeReference textPassage S
81. Member D_CALL_ST instance_init_1 T_INIT erzeuge T_METHOD Initialisierer sind in Together namenlos Initialisierer derselben Klasse sind also durch ihren Namen nicht unterscheidbar Die Benennung eines Instanz Initialisierers erfolgt durch Generierung eines Namens der Art instance_init_ wobei das Prozentzeichen f r eine fortlaufende Nummerierung der Initialisierer einer Klasse steht Abh ngigkeit en auf Klassenebene F hrt die Abh ngigkeit zu einer Klasse so wird die Abh ngigkeit nur auf Klassen und Summary Ebene gespeichert Ebene Abh ngigkeitstyp Knotentyp Nach Knotentyp Summary D_DEP FirmaLoeschenK T_CLASS Firma T_CLASS Class D_CAST FirmaLoeschenK T_CLASS IFirma T_CLASS Member Bei der auf Klassenebene eingef gten Abh ngigkeit wird eine Referenz zum Knoten des Instanz Initialisierers gespeichert Abh ngigkeit en zu allen implementierten Konstruktoren 158 Anhang Abh ngigkeiten zu vererbten Methoden und Attributen Der Code eines Instanz Initialisierers wird implizit beim Erzeugen einer Instanz vor dem Code jedes anderen Konstruktors der Klasse ausgef hrt Man kann sich das als impliziten Aufruf des Initialisierers zu Beginn des Konstruktor Codes vorstellen Hierf r ist eine Abh ngigkeit D_INIT vorgesehen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary Class Member D_IN
82. Methode 15 Kapitel 5 Analyse des public Object visitOperation SciOperation sciOperation Interfaces SciElementVisitor beispielsweise Abh ngigkeiten zu anderen Programmkomponenten aufgrund des R ckgabewerts der Methode der bergebenen Parameter und der von der Methode geworfenen Ausnahmen bereits erkannt werden Um auch den Methodenrumpf nach Abh ngigkeiten untersuchen zu k nnen stellt das Interface SciFunction diesen als R ckgabewert der Methode public SciCodeBlock getBody in einem Objekt vom Typ SciCodeBlock zur Verf gung Dieser Instanz k nnen weitere vom Together Open API vorgesehene Visitoren zugewiesen werden um die Suche nach Abh ngigkeiten innerhalb des Methodenrumpfes fortsetzen zu k nnen interface interface SciExpressionVisitor SciStatementvisitor interface SciReferenceVisitor visitExpression Object visit ssignmentExpression Objec visitTypecastExpression Object visitflemnber ccessexpression Of visitFunchoncallExpression Objeg visitlonstantExpression Object visitNewExpression Object visitReferenceExpression Object visitTypeExpression Object visitDirectnitExpression Object visitStatement bject visitDeclarationststement Object visitCompoundStatement bject visiffiiyStatementObject visitSwiichStatement bject visitcatchBlockStatement bject visitExpressionstatement bject visitReturmnStstement bject visitThrowStateme
83. Metrics start now show the results edgeMetricsMouseListener new EdgeMetricsMouseListener D2TMediatorImpl this edgeMetricsPane new ShowEdgeMetricsPane D2TMediatorImpl this computeMetrics getVersionAnalysis edgeMetricsMouseListener edgeMetricsPane openPane nodeMetricsMouseListener new NodeMetricsMouseListener D2TMediatorImpl this nodeMetricsPane new ShowNodeMetricsPane D2TMediatorImpl this computeMetrics getNodeAnalysis nodeMetricsMouseListener nodeMetricsPane openPane if graphDialog null graphDialog closeDialog showGraph Man sieht wie zun chst die Abh ngigkeitssuche und Metrikberechnung gestartet wird und im Anschluss daran die Anzeigekomponenten bei ihrer Erzeugung mit den Ergebnissen versorgt und zur Anzeige gebracht werden Die Kontrolle ber alle Komponenten kann so beim Mediator verbleiben 7 9 Probleme der Implementierungsphase Bei der Entwicklung von Together Modulen zeigen sich einige grunds tzliche Erschwernisse Die einzige M glichkeit ein Modul zu debuggen besteht darin eine zweite Instanz des ControlCenters im Debugger der ersten Instanz zu starten Ein System mit 512 MB Arbeitsspeicher und 800 MHz Prozessor ben tigt f r den Start dieser zweiten Instanz ca 4 Minuten e Die komplexeste Teilkomponente das Durchlaufen des Sourcecodes und das Erkennen der Abh ngigkeiten kann nur sinnvoll auf Grundlage eines real verf gbaren Together Projekts u
84. Modellelemente und des Sourcecodes nach Abh ngigkeiten zwischen Programmkomponenten T3 Aufbau eines Abh ngigkeitsgraphen nach der von mproveT vorgegebenen Schnittstellenspezifikation auf Grundlage der ermittelten Abh ngigkeiten 4 Export des Abh ngigkeitsgraphen nach mproveT M glichkeit zur Auswahl der zu ber cksichtigenden Metriken durch den Anwender und Starten der Metrikberechnung in ImproveT 5 Anzeige der ermittelten Testbarkeitsmetriken in Together graphische Darstellung der Abh ngigkeiten wechselseitige Navigationsm glichkeiten in den Anzeigekomponenten Diese Teilaufgaben bilden die Basis f r die im n chsten Kapitel durchgef hrte Analyse Diese Analyse bereitet den Entwurf und die Implementierung der Together Erweiterung in Kapitel 6 und 7 vor Zentrales Thema der Analyse wird die Beschreibung der f r die Teilaufgaben jeweils ben tigten Schnittstellen von mproveT und Together sein Kapitel 5 Analyse 5 Analyse 5 1 Einleitung In diesem Kapitel werden die Vorarbeiten f r den Entwurf und die Implementierung der Together Erweiterung um mproveT geleistet Nach einer kurzen einf hrenden Charakterisierung der beiden an der Integration beteiligten Softwarekomponenten erfolgt die Analyse dieser Komponenten im Hinblick auf die im Rahmen der Integration zu leistenden Teilaufgaben aus Abschnitt 4 3 Bei der Durchf hrung der Analyse steht die Beschreibung der von den beteiligten Komponenten zur Verf gung ge
85. Relationen und Paarklassen wurde bereits bei Abh ngigkeit 9 2 14 vorgenommen 75 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 9 2 21 BelegungRelation BelegungTripel 9 2 21 1 Ergebnisse der Metrikberechnung 9 5 z 9 3 d_type 1 2 2 8 D lt lt Z lt 2 D 0 0 0 0 0 2 2 create and access 1 2 2 4 89 6212 9 2 3 0 1 0 89 65 6211 0 0 4 Abbildung 78 Komponentenmetriken BelegungRelation A und BelegungTripel E D lt Auff lligkeiten bei den berechneten Werten Die rACD Werte der Klasse BelegungRelation liegen deutlich ber dem rACD Wert der Abh ngigkeit 9 2 21 2 Bewertung Die beiden beteiligten Klassen resultieren aus der transformierten Assoziation zwischen einer ffentlichen Seminarveranstaltung einer daran teilnehmenden Person und der Assoziationsklasse Belegung Die Bewertung der Abh ngigkeiten zwischen Relationen und Paarklassen wurde bereits bei Abh ngigkeit 9 2 14 vorgenommen Die Abh ngigkeiten zwischen Relationen und Tripelklassen sind v llig analog zu sehen 9 2 22 BuchtRelation BuchtPaar 9 2 22 1 Ergebnisse der Metrikberechnung x 5 3 9 d_type 2 70 2 2 2 2 lt lt 0 0 10 12 00 00 0 9 0 0 2 2 create and access Abbildung 79 Abh ngigkeitsmetriken BuchtRelatio
86. SVAendernErfassenAA SeminartypAuswaehlenAA 9 2 3 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken 2 x 9 5 z aaao 5 13 d_type 1 2 s 2 lt lt lt lt lt lt 2 0 0 0 0 0 1 2 create and access rACD_in Abbildung 42 Komponentenmetriken SV AendernErfassenAA A und SeminartypAuswaehlenAA B Erl uterungen zu den Abh ngigkeitsmetriken Hier handelt es sich um eine Abh ngigkeit die nicht Teil eines Zyklus dep_comp ist Das Entfernen der Abh ngigkeit h tte folglich keinerlei Auswirkungen auf Zyklen Erl uterungen zu den Komponentenmetriken Beide Klassen besitzen eine verh ltnism ig hohe Zahl von ausgehenden Abh ngigkeiten auch wenn der h chste cd Wert aller Komponenten sogar bei 26 liegt Der rACD_out Wert von SVAendernErfassenAA liegt doppelt so hoch als der rACD Wert der Abh ngigkeit Dies ergibt sich durch die zwei Abschnitte tiefer noch zu betrachtende testkritische Abh ngigkeit der Klasse zu LeitungsauftragAuswaehlenAA Die extrem hohe Anzahl der direkten und indirekten Abh ngigkeiten der Klasse SVAendernErfassenAA resultiert daraus dass die Klasse an mehreren Zyklen beteiligt ist Die Anzahl statischer Abh ngigkeiten liegt in beiden Klassen verh ltnism ig hoch der systemweit h chste Wert f r die Metrik cd_h betr gt 15 60 Kapitel 9 Testb
87. Testbarkeitsanalyse von Abh ngigkeiten in objektorientierter Software Diplomarbeit von Edgar Merl April 2003 Betreuer Prof Dr Hans Werner Six Lehrgebiet Praktische Informatik Fachbereich Informatik FernUniversit t Hagen Erkl rung Hiermit versichere ich die vorliegende Arbeit selbst ndig und nur unter Nutzung der angegebenen Literatur und Hilfsmittel angefertigt zu haben W rtlich bernommene S tze und Satzteile sind als Zitate belegt andere Anlehnungen hinsichtlich Aussage und Umfang unter den Quellenangaben kenntlich gemacht Die Arbeit hat in gleicher oder hnlicher Form noch keiner Pr fungsbeh rde vorgelegen N rnberg 11 April 2003 Edgar Merl Matr Nr 4181824 Danksagung An dieser Stelle m chte ich mich bei allen bedanken die mich bei der Erstellung der Diplomarbeit in vielf ltiger Weise unterst tzt haben Ein besonderes Dankesch n geb hrt Stefan Jungmayr Er hat mir nicht nur ein Verst ndnis von wissenschaftlicher Arbeitsweise und umfangreiches Fachwissen vermittelt er stand mir auch jederzeit bei allen Fragen und Problemen geduldig und ersch pfend mit Rat und Tat zur Seite Ich kann jedem Diplomanden nur w nschen jemanden wie ihn bei der Erstellung einer Diplomarbeit an der Seite zu wissen All meinen Freunden danke ich f r den seelischen und moralischen Beistand den sie mir in den letzten Monaten gaben Ohne ihre Unterst tzung h tte ich es sicher nicht geschafft diese Arbeit zu ei
88. Zugriffe verteilen sich auf folgende Pakete Zugreifende Klassen im PaketExterneSystemeP ProtokollP ProtokollDateiA LogProtokollDateiA DebugProtokollDateiA Zugreifende Klassen im Paket UtilP MeldungP MeldungsAnzeigeA Zugreifende Klassen im PaketExterneSystemeP DruckerP DruckDokumentDK BriefDK Aufgrund der Implementierung von SeminarisK entsteht durch diese Zugriffe eine transitive Abh ngigkeit der aufgef hrten Klassen von der Datenbank der Anwendung und aufgrund der Implementierung der Datenbank siehe nachfolgenden Abschnitt 10 5 dar ber hinaus auch noch die Abh ngigkeit von der Datenhaltungsschicht Die beschriebenen Probleme resultieren letztlich aus dem ungeschickt realisierten Versuch den systemweiten Zugriff auf globale Basiskomponenten zu erm glichen Eine detaillierte Diskussion dieses Problems findet sich in Abschnitt 10 6 Dort werden auch M glichkeiten f r eine alternative Implementierung des Zugriffs vorgestellt 10 4 2 Auswirkungen auf die Testbarkeit Die beschriebenen Zugriffe auf die Kontrollschicht f hren grunds tzlich ebenfalls zu den in Abschnitt 10 3 2 erl uterten Testproblemen Zudem f hrt die transitive statische Abh ngigkeit der Basiskomponenten zur Datenbank zu den in Abschnitt 10 5 2 beschriebenen Problemen 10 5 Zugriff auf Datenhaltung durch Basiskomponente 10 5 1 Entwurfsproblem Analog zu den bereits beschriebenen Problemen wird die hierarchische Struktur der Anwendun
89. add IGeschaeftspartner iter next getSchluessel B 18 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP Geschaeftspartner T_ABSTR IGeschaeftspartner T_INTERF Class D_CALL_IF Geschaeftspartner T_ABSTR IGeschaeftspartner T_INTERF Member D_CALL_IF getAlleSchluessel T_METHOD getSchluessel T_METHOD B 19 Klasseninterner Aufruf einer nicht statischen Methode B 19 1 Erl uterung und Beispiel Wird eine nicht statische Methode derselben Klasse aufgerufen so wird hierdurch eine Abh ngigkeit vom Typ D_CALL_TI definiert Der Aufruf einer Methode einer u eren Klasse aus einer inneren Klasse wird nicht als klasseninterner Aufruf betrachtet sondern als Abh ngigkeit D_CALL_VI gespeichert public class Firma public String getName return name public String getAnrede return getName B 19 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary Class Member D getAnrede T_METHOD getName T_METHOD Klasseninterne Abh ngigkeiten werden nur auf Memberebene gespeichert B 20 Klasseninterner Aufruf einer statischen Methode B 20 1 Erl uterung und Beispiel Wird eine statische Methode derselben Klasse aufgerufen
90. altungP SeminarisP ILeitungsauftrag Loaded DatenhaltungP SeminarisP Leitungsauftrag Loaded DatenhaltungP TransformationenP DozentenvereinbarungRelation Loaded DatenhaltungP TransformationenP DozentenvereinbarungAnfragen Loaded DatenhaltungP SeminarisP Dozentenvereinbarung l Loaded DatenhaltungP SeminarisP Dozentenvereinbarung 2 Loaded DatenhaltungP SeminarisP Dozentenvereinbarung 3 Loaded DatenhaltungP SeminarisP Dozentenvereinbarung 4 Loaded DatenhaltungP SeminarisP IOeffentlicheSeminarveranstaltung Loaded DatenhaltungP SeminarisP ISeminartyp Loaded DatenhaltungP SeminarisP Geld Loaded DatenhaltungP SeminarisP Seminartyp Loaded DatenhaltungP TransformationenP IDozentenvereinbarungTripel Loaded DatenhaltungP TransformationenP DozentenvereinbarungTripel Loaded DatenhaltungP TransformationenP DVSchluessel Abbildung 30 Geladene Klassen beim Erzeugen einer Dozentenvereinbarung insg 47 Zus tzlich werden 71 Klassen des Persistenz Rahmenwerks und 50 Klassen der Java Datenbank geladen Dies zeigt den gewaltigen Aufwand der f r einen einzigen relativ simplen Methodentest alleine von der Laufzeitumgebung betrieben werden muss 9 2 1 2 Bewertung der Abh ngigkeit Bei Dozentenvereinbarung handelt es sich um eine in der Anforderungsspezifikation definierte Assoziationsklasse Eine Dozentenvereinbarung wird mit einer Person Dozent ber einen von ihm durchgef hrten Seminartyp abgeschlos
91. alysis NodeAnalysis ShowNodeMetricsPane createRootPane void addListSelectionListener void openPane void Yv updateForNode void nodeAnalysis NodeAnalysis MouseAdapter ComponentsMouseListener SaveNodeMetricsDialog actionPerformed void mediator D2TMediator components InComponentTableModel OutComponentTableModel ComponentTableModel ComponentTable ComponentsMouseListener mouseClicked void mousePressed void mouseReleased void showPopupMenu void Abbildung 21 Anzeige der Komponentenmetriken packageresults nodemetrics F r die Anzeige der Komponentenmetriken zeichnet die Klasse ShowNodeMetricsPane verantwortlich Sie bildet den Rahmen f r die von I mproveT gelieferten Ergebnisse NodeAnalysisTable und NodeAnalysis und die Anzeige der Komponenten die als Ziel oder Ursprung von Abh ngigkeiten mit der aktuell ausgew hlten Komponente verbunden sind Paket components Die Klasse NodeMetricsMouseListener ist verantwortlich f r das Bereitstellen des Kontextmen s in der Metrikanzeige die Klasse ComponentsMouseListener realisiert das Kontextmen in der Anzeige der verbundenen Komponenten In der Klasse SaveNodeMetricsDialog ist das Speichern der ermittelten Metrikwerte realisiert 6 7 5 Teilentwurf graphische Anzeige der Abh ngigkeiten Das nachstehende Klassendiagramm liefert einen berblick ber die Realisierung der graphischen Da
92. and im Verh ltnis zur Gesamtentwicklungszeit gering Neben den nachfolgend noch beschriebenen konkreten Verbesserungen die durch die Refaktorisierung im Hinblick auf die Testbarkeit von SeminarlS erreicht werden konnten lassen auch die im Anschluss gemessenen Metrikwerte mit einer Ausnahme auf eine Verbesserung der Testbarkeit schlie en Nachfolgend eine Auflistung der wichtigsten Refaktorisierungsschritte e Im Rahmen der Realisierung eines ver nderten Zugriffs auf globale Basiskomponenten wurden verschiedene in der Literatur zu findende M glichkeiten zur L sung dieses Problems diskutiert Keine der L sungen konnte letztlich aus Sicht der Testbarkeit vollst ndig berzeugen so dass ein eigenst ndiges Konzept f r den Umgang mit Basiskomponenten entwickelt und vorgeschlagen wurde Auff llig an 127 Kapitel 12 Zusammenfassung dieser L sung war dass sie zwar zu keiner Verbesserung der Metrikwerte f hrte die erreichte Konfigurierbarkeit der Basiskomponenten aber dennoch einen deutlichen Vorteil bei der Testdurchf hrung darstellt da damit im Rahmen der Initialisierung von Testf llen der Austausch der Komponenten durch Teststellvertreter erm glicht wird e Die Refaktorisierung der Datenhaltungsschicht war zwar mit dem meisten Aufwand verbunden f hrte aber daf r zu einer Verringerung des Wertes der ACD Metrik um ber 40 Prozent War vor der Refaktorisierung eine Klasse im Durchschnitt von ca 89 anderen Klassen direkt od
93. araufhin angezeigte Dialog gleicht dem zum Speichern im XML Format gt Abbildung 20 Dialog zum Speichern des Abh ngigkeitsgraphen W hlen Sie das Verzeichnis und geben Sie den Namen der Grafikdatei an unter dem das Bild des aktuell angezeigten Abh ngigkeitsgraphen gespeichert werden soll Um den Speichervorgang abzuschlie en dr cken Sie die Schaltfl che Save 185 Anhang Erweiterte Funktionen und Einstellungen 6 3 3 Druck der Graphanzeige ACHTUNG Um die Druckmen s von Design2Test nutzen zu k nnen muss das Quality Assurance QA Modul von Together geladen sein gt 1 Installation Um die aktuelle Graphanzeige auszudrucken w hlen Sie den Men punkt Print im Kontextmen des Graphanzeige Fensters Hierauf ffnet sich folgender Druck Dialog Abbildung 21 Dialog zum Drucken der aktuellen Graphanzeige W hlen Sie die gew nschten Druckeinstellungen aus und bet tigen Sie anschlie end die Schaltfl che Print um den Ausdruck zu starten 186 Anhang Kontextmen s Anhang Kontextmen s Kurz bersichten Metriktabellen Klicken Sie mit der rechten Maustaste in eine der beiden Metriktabellen so erhalten Sie ein spaltenabh ngiges Kontext Men Component Metrics nur in Komponentenspalten Edit nur in Komponentenspalten Select on Diagram nur in Komponentenspalten Refresh Restart Show Description nur in Metrikspalten Export Print Graph Pro
94. arisDatenbank getDatenbank return seminarisDatenbank public static void setDatenbank ISeminarisDatenbank aktuelleDatenbank seminarisDatenbank aktuelleDatenbank Ferner stellt die Providerklasse eine set Methode zur Verf gung ber die beispielsweise in der Testumgebung die dynamische Konfiguration der Datenbank erfolgen kann Diskussionw rdig ist sicher die vorhandene Initialisierung der Providervariable mit der Laufzeitinstanz von SeminarisDatenbank Gegen diese Initialisierung spricht die dadurch transitiv entstehende syntaktische Abh ngigkeit von dieser Klasse Aus Sicht der Testbarkeit birgt dies jedoch nur den Nachteil dass f r den Fall der noch fehlenden Implementierung der Klasse bei der Testfallerstellung eine Dummy Klasse erstellt werden muss Dem stehen aber zwei Vorteile gegen ber Die Erzeugung der Instanzen erfolgt nicht schon beim Starten des Systems z B in der Hauptschnittstellenklasse und der Zugriff auf die statische Erzeugermethode getEinzigelnstanz der Singletonklasse SeminarisDatenbank kann paketlokal gesetzt werden da kein Zugriff auf die Instanz von au erhalb des Pakets erfolgen muss 113 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung public class SeminarisDatenbank extends Datenbank implements ISeminarisDatenbank Einzige Instanz der Klasse Entwurfsmuster Einzelstueck private static SeminarisDatenbank einzigelnsta
95. arkeitsanalyse ausgew hlter Abh ngigkeiten 9 2 3 2 Bewertung In der Anforderungsspezifikation hei t es im main flow zum Anwendungsfall Seminarveranstaltung erfassen Ein Seminarsachbearbeiter w hlt zun chst einen Seminartyp aus legt eine neue Seminarveranstaltung von diesem Seminartyp an erfasst die zus tzlichen Angaben und erfasst zumindest einen Leitungsauftrag extension point LA erfassen Die in der Anforderungsspezifikation vorgeschriebene Auswahl eines Seminartyps wurde beim Entwurf von SeminarlS derart realisiert dass hierdurch eine Abh ngigkeit dieses Anwendungsfalles mit den Anwendungsf llen zur Bearbeitung eines Seminartyps entstand siehe Abschnitt 10 8 Dies f hrt zur Abh ngigkeit der zu den Anwendungsf llen implementierten Schnittstellenklassen und den damit verbundenen Testproblemen 9 2 4 DruckDokumentDK SeminarisK 9 2 4 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken pk 2 2 0 le Int static access rACD_in Abbildung 44 Komponentenmetriken DruckDokumentDK A und SeminarisK B Erl uterungen zu den Abh ngigkeitsmetriken Hier handelt es sich wiederum um eine Abh ngigkeit die nicht Teil eines Zyklus dep_comp ist Sie verl uft jedoch ebenfalls ber Paketgrenzen hinweg is_intpk Der rACD Wert stimmt in etwa mit dem rACDh Wert berein Das Entfernen der Abh ngigkeit h tte keinerlei Auswirkungen auf Zy
96. arkeitssicht der kritischste ist d_type 51 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Dar ber hinaus existieren eine Vielzahl von Metriken die zu allen im System vorhandenen Komponenten erg nzende Aussagen in Bezug auf die von ihnen ausgehenden Abh ngigkeiten liefern Hier existieren Kennziffern ber die e Anzahl der von ihnen ausgehenden direkten und indirekten Abh ngigkeiten zu anderen Komponenten innerhalb des Systems cd wie viele dieser Abh ngigkeiten statischer Natur sind cd_h ois A e bei wie vielen es sich um Typabh ngigkeiten handelt cd_t e wie viele dieser Abh ngigkeiten in der ffentlichen Schnittstelle sichtbar sind und wie viele aus den Methodenr mpfen heraus verlaufen cd_im e Daneben existieren f r die Testbarkeitsmetrik ACD zwei weitere ber alle ein und ausgehenden Abh ngigkeiten aggregierte Varianten auf Klassenebene rACD_in rACD_out In den nachfolgenden Abschnitten werden die durch mproveT verf gbaren Informationen f r eine Untersuchung und Bewertung der 30 Abh ngigkeiten mit den h chsten rACD Werten verwendet 9 2 rACD Abh ngigkeiten Die Analyse der Abh ngigkeiten ist jeweils in zwei Abschnitte unterteilt Im ersten Teil werden die Abh ngigkeitsmetriken und die f r die an der Abh ngigkeit beteiligten Klassen ermittelten Komponentenmetriken angegeben Bei den ersten Abh ngigkeiten werden die Metriken zum Vers
97. assen erzeugt und kompiliert 95 Kapitel 10 Entwurfsprobleme und Testbarkeit Dieses Problem wirkt sich deshalb extrem negativ auf die Testbarkeit aus weil aufgrund der statischen Abh ngigkeiten dieser Automatismus der Datenbank Abfrage und Proxygenerierung beim Test von e nahezu allen Klassen der kompletten Kontrollschicht SeminarisK wird fast in jeder Kontrollklasse f r Transaktionssteuerung ben tigt e und fast allen Klassen der Schnittstellenschicht die Schnittstellenklassen verwenden die Hauptschnittstellenklasse Seminari sH in der obligatorisch die Erzeugung von Seminarisk erfolgt gestartet wird Aufgrund der statischen Art der Abh ngigkeit l sst sich ohne nderung der Implementierung auch in der Testumgebung kein anderes Verhalten erreichen siehe auch Abschnitt 10 6 2 Auch f r Klassen in denen mit der tats chlichen Implementierung der Datenbank getestet werden soll z B Ordnerklassen da hier die syntaktische und semantische Korrektheit der verwendeten SQL Anweisungen nur im Zusammenspiel mit dem Persistenz Rahmenwerk und der Datenbank getestet werden kann ergeben sich Probleme F r diese Tests muss eine kompilierf hige Implementierung der Dom nenklassen vorhanden sein deren zuletzt vergebene eindeutige Bezeichner ber die Datenbankklasse ermittelt werden 10 6 Zugriff auf globale Basiskomponenten 10 6 1 Entwurfsproblem Ein zentrales Problem das auch bereits in den vorhergehenden Abschnitten deutlich
98. ast Operators B 24 1 Erl uterung und Beispiel Wird mit Hilfe des Type Cast Operators eine explizite Typumwandlung vorgenommen so wird eine Abh ngigkeit D_CAST ermittelt 154 Anhang Verwendung des instanceof Operators abstract public class SeminarbelegungAA extends SeminarisFrame protected void darstellenInhalte gpFirmaS darstellenInhalte Firma gp B 24 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Knotentyp Nach Knotentyp Summary SeminarbelegungAA T_ABSTR Firma T_CLASS Class D_CAST SeminarbelegungAA T_ABSTR Firma T_CLASS Member Um den Bezug zur Methode oder zum Attribut das die Abh ngigkeit verursacht nicht zu verlieren wird bei der auf Klassenebene eingef gten Abh ngigkeit eine Referenz auf den Elementknoten gespeichert B 25 Verwendung des instanceof Operators B 25 1 Erl uterung und Beispiel Wird mit Hilfe des instanceo Operators ein Typvergleich durchgef hrt wird eine D_INSTANC Abh ngigkeit ermittelt public class MeldungsAnzeigeA private int zeige SeminarisMeldung eineSeminarisMeldung Component cp if eineSeminarisMeldung instanceof ExceptionNachricht B 25 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP Meldu
99. backTransaktion void rolibackTransaktion void erzeuge bjekt lPersistent erzeuge bjektlPersistent abfrageAusfuehren ilterator abfrageAusfuehren iterator SeminarisDatenbank getEinzigelnstanz SeminarisDatenbank zerstoeren void starteTransaktion void commitTransaktion void rollpackTransaktion void getHoechsteKundennummer int getHoechsterRechnungsnummer int getHoechsteLeitungsauftragnummerint Abbildung 116 Abkopplung vom Persistenz Rahmenwerk durch Interface ISeminarisDatenbank 114 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung Abschlie end m ssen im gesamten Projekt die Zugriffe auf die Datenbank angepasst werden Dieses Vorgehen f hren wir analog auch f r folgende Basiskomponenten durch e Konfiguration e SynchronisationsManager e ProtokollManager DebugProtokollDateiA e LogProtokollDateiA Nach Abschluss dieser Refaktorisierung und der Verlagerung der Logik zur Verwaltung von eindeutigen Dom nenattributen siehe Abschnitt 11 4 aus der Klasse SeminarisK in die Datenhaltung kann die Klasse Sseminarisk entfallen Der Gesamtaufwand f r die Refaktorisierung betr gt 90 Minuten 11 5 3 Ergebnisse Die Refaktorisierung wirkt sich wie folgt auf die Projektmetriken aus Project Metrics EN Project Metrics 60 35496 81 0 39 0 106 0 50 57 36194 720 35 0 NCDC 103 0 50 Abbildung 117 Projektmetriken vor und na
100. barung Loaded ExterneSystemeP PersistenzP SeminarisDatenbank Loaded UtilP ExceptionP SeminarisException Loaded UtilP ExceptionP SchluesselVorhandenException Loaded AnwendungslogikP SeminarisP SeminarisK Loaded ExterneSystemeP KonfigurationP Konfiguration Loaded UtilP ExceptionP KonfigurationException Loaded UtilP SynchronisationP SynchronisationsManager Loaded ExterneSystemeP ProtokollP ProtokollManager Loaded ExterneSystemeP ProtokollP IProtokollAusgabeKunde Loaded ExterneSystemeP ProtokollP ProtokollDateiA Loaded ExterneSystemeP ProtokollP DebugProtokollDateiA Loaded ExterneSystemeP ProtokollP LogProtokollDateiA Loaded UtilP ExceptionP CommitOrRollbackWithoutStartTransactionException Loaded DatenhaltungP SeminarisP IGeschaeftspartner Loaded DatenhaltungP SeminarisP Geschaeftspartner Loaded UtilP ExceptionP UngueltigerSchluesselException Loaded DatenhaltungP SeminarisP IFirma Loaded DatenhaltungP SeminarisP Firma Loaded DatenhaltungP SeminarisP IPerson Loaded DatenhaltungP SeminarisP Person Loaded DatenhaltungP SeminarisP IBelegung Loaded DatenhaltungP SeminarisP Belegung Loaded UtilP ExceptionP AssoziationsException Loaded DatenhaltungP SeminarisP IGeld Loaded DatenhaltungP SeminarisP ISeminarveranstaltung Loaded DatenhaltungP SeminarisP Seminarveranstaltung Loaded DatenhaltungP SeminarisP IFirmenSeminarveranstaltung Loaded DatenhaltungP SeminarisP FirmenSeminarveranstaltung Loaded Datenh
101. bedges Erl uterungen zu den Komponentenmetriken Beide Klassen besitzen eine verh ltnism ig hohe Zahl von ausgehenden Abh ngigkeiten Der rACD_out Wert von SVAendernErfassenAA liegt doppelt so hoch als der rACD Wert der Abh ngigkeit Dies ergibt sich durch die zwei Abschnitte h her bereits betrachtete Abh ngigkeit zur Klasse SseminartypAuswaehlenAA Die extrem hohe Anzahl der direkten und indirekten Abh ngigkeiten beider Klassen resultiert unter anderem aus der Zyklusbeteiligung Die Anzahl statischer Abh ngigkeiten liegt in beiden Klassen verh ltnism ig hoch 9 2 5 2 Bewertung In der Anforderungsspezifikation hei t es im main flow zum Anwendungsfall Seminarveranstaltung erfassen Ein Seminarsachbearbeiter w hlt zun chst einen Seminartyp aus legt eine neue Seminarveranstaltung von diesem Seminartyp an erfasst die zus tzlichen Angaben und erfasst zumindest einen Leitungsauftrag extension point LA erfassen Die in der Anforderungsspezifikation vorgeschriebene Erfassung eines Leitungsauftrags wurde beim Entwurf von SeminarlS durch direkte Verzweigung in den zugeh rigen Anwendungsfall Leitungsauftrag erfassen realisiert Dies f hrt zur Abh ngigkeit der zu den Anwendungsf llen implementierten Schnittstellenklassen und den damit verbundenen Testproblemen Da in diesem Fall dar ber hinaus auch eine Abh ngigkeit vom Anwendungsfall Leitungsauftrag erfassen zum Anwendungsfall Seminarveranstaltung
102. berechnen actors Together Benutzer precondition Wie Anwendungsfall Testbarkeitsmetriken berechnen main flow Bei der erstmaligen Berechnung der Metriken werden dem Benutzer eingangs die f r die Analyse verf gbaren Testbarkeitsmetriken zur Auswahl angeboten includes Metriken ausw hlen Er w hlt die gew nschten Metriken aus und startet die Testbarkeitsanalyse siehe allgemeiner Anwendungsfall Testbarkeitsmetriken berechnen postcondition Wie Anwendungsfall Testbarkeitsmetriken berechnen end Testbarkeitsmetriken erstmalig berechnen 135 Anhang Textuelle Anwendungsfallspezifikationen A 2 3 Anwendungsfall Metriken ausw hlen use case Metriken ausw hlen actors Together Benutzer precondition main flow Der Benutzer erh lt alle f r die Analyse verf gbaren Testbarkeitsmetriken zur Auswahl angeboten Zu jeder der Metriken kann er eine kurze Beschreibung abrufen Er w hlt die gew nschten Metriken aus und startet die Testbarkeitsanalyse exceptional flow Keine Metriken ausgew hlt Der Benutzer erh lt einen Hinweis dass wenigstens eine Metrik zur Berechnung ausgew hlt werden muss postcondition Wenigstens eine der Testbarkeitsmetriken wurde ausgew hlt end Metriken ausw hlen A 2 4 Anwendungsfall Suchoptionen einstellen use case Suchoptionen einstellen actors Together Benutzer precondition main flow Der Benutzer kann aus dem zu analysierenden Projekt einzelne Programmkom
103. bleme und Testbarkeit hnliche Probleme folgen auch f r den Integrationstest Dort sind Strategien zu bevorzugen bei denen die Integration der Module inkrementell verl uft Im Idealfall werden dabei out getestete Komponenten in kleinen Schritten dem System hinzugef gt Dies bringt folgende Vorteile Bei geeigneter Wahl der Integrationsstrategie z B bottom up kann weitgehend auf den Einsatz von Stellvertretern und den zur Erstellung n tigen hohen Aufwand verzichtet werden Neu hinzugekommene Fehler k nnen in unmittelbarer N he der zuletzt integrierten Komponente vermutet und daher schneller lokalisiert werden Bei Integrationsstrategien die den sofortigen gleichzeitigen Test einer gro en Anzahl von Komponenten vorsehen Big Bang liegt die Schwierigkeit darin aufgetretene Fehler zu lokalisieren Au erdem kann bei diesem Vorgehen nur schwerlich eingesch tzt werden welche Fehler durch andere Fehler bedingt werden Inkrementelle Strategien werden durch hierarchische Architekturen unterst tzt Lako96 Liegt wie bei SeminarlS durch die zyklische Struktur nahezu aller Anwendungskomponenten eine Aufl sung s mtlicher Hierarchieebenen vor so kann ein sukzessiver Test von immer gr er werdenden Teilmodulen nur mit erheblichem Aufwand z B durch weitreichenden Einsatz von Teststellvertretern erreicht werden In diesen F llen wird man geneigt sein unter Inkaufnahme der damit verbundenen Nachteile auf eine andere Integration
104. ccess SVAendernErfassenAA LeitungsauftragAusw aehlenAA 1 0 1 18 3 0 1 create and access Seminarty pAendernErfassenAA Dozentenv ereinbarungAusw aehlenAA 0 0 11 6 2 3 1 create and access LeitungsauftragAendernErfassenAA SVAusw aehlenAA 1 1 116 2 5 1 2 create and access DVKostenBerechnenK Dozentenv ereinbarungLoeschenK 4 1 01 46 1 9 1 1 static access SeminarbelegungAA SVAusw aehlenAA 0 0 11 6 24 2 3 create and access SeminarisH SachbearbeiterA 1 1 015 2 4 1 static access Erw eitertPersistent SeminarisDatenbank 1 0 114 44 1 1 static access SVKurzS Seminarv eranstaltung 0 0 11 1 0 8 to abstract class MeldungsAnzeigeA Ex ceptionNachrichtA 0 0 010 0 8 1 3 create and access TeilnahmeFirmenSVRelation TeilnahmeFirmenSVPaar 1 0 010 1 2 2 2 create and access SVSeminarty pRelation SVSeminarty pPaar 1 0 010 12 2 2 create and access SVAnsprechpartnerRelation SVAnsprechpartnerPaar 1 0 010 1 2 2 2 create and access RechnungsempfaengerRelation RechnungsempfaengerPaar 1 0 010 1 2 2 2 create and access SeminarisK LogProtokollDateiA 1 1 110 1 2 1 2 create and access SeminarisK DebugProtokollDateiA 1 1 11 0 1 2 1 2 create and access AnstellungRelation AnstellungPaar 1 0 010 12 2 2 create and access BelegungRelation BelegungTripel 1 0 010 12 2 2 create and access BuchtRelation BuchtPaar 1 0 010 1 2 2 2 create and access FirmenAnsprechpartnerRelation FirmenAnsprechpartnerPaar 1 0 010 12 2 2 create and access LeitungsauftragRelation LeitungsauftragTripel 1 0 0
105. ch nderung des Zugriffs auf Datenbank Wie bereits erwartet ist ACD Wert nahezu unver ndert geblieben da durch die Initialisierung der Providerklassen die bestehenden Abh ngigkeiten transitiv erhalten geblieben sind Dennoch wurde eine Verbesserung der Testbarkeit erreicht 11 6 Direkter Zugriff auf Ordner und Relationen 11 6 1 Ausgangssituation Wie Abschnitt 10 7 beschrieben f hrt die Fassadenfunktion der Dom nenklassen sowohl zu erh htem Implementierungsaufwand als auch in der Folge zu erh htem Testaufwand Die Testbarkeitsmetriken auf Klassenebene schlagen allerdings keinen Alarm da die Abh ngigkeiten breit gestreut auf viele Klassen verteilt sind Aus dem Paketdiagramm Abbildung 107 Zugriff auf Datenhaltung mit Fassadenmuster wird aber sofort deutlich dass es sich auf Paketebene um eine klassische Hub Abh ngigkeit handelt SeminarisP ist der Hub Insoweit l sst sich festhalten dass eine Erweiterung der Testbarkeitsmetriken auf Paketebene nach wie vor absolut w nschenswert w re Ein Indiz f r das vermutete Ausschlagen der Metriken auch auf Paketebene liefert eine bersicht der Abh ngigkeiten mit den h chsten rACD Metriken die w hrend des Refactoring erstellt wurde Zum 115 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung Zeitpunkt der Errechnung der dort angezeigten Testbarkeitsmetriken war bereits s mtliche Fassaden und dar ber hinaus gehende Gesch ftslogik aus de
106. che Weise zu beseitigen wird der Parametertyp in String umgewandelt und die Zuweisung der aktuellen Policy erfolgt ber Fallunterscheidung in der Erzeugermethode 120 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung Die Implementierung der AAKlassenFabrik erfolgt trivialerweise durch Erzeugung und R ckgabe der Auswahlklassen Das Erzeugen der Fabrik erfolgt beim Start der Anwendung in der Hauptschnittstellenklasse SeminarisH Im ersten Ansatz der Refaktorisierung erfolgt die Verwaltung der Fabrik in einer neu geschaffenen Systemklasse SseminarisSystem public class SeminarisSystem private static IAAKlassenFabrik aaKlassenFabrik null public static IAAKlassenFabrik getAAKlassenFabrik if 1 null throw new IllegalStateException AAKlassenFabrik ist nicht gesetzt return aaKlassenFabrik public static void setAAKlassenFabrik IAAKlassenFabrik aktuelleAAKlassenFabrik aaKlassenFabrik aktuelleAAKlassenFabrik Dieser Ansatz der zentralen Verwaltung erweist sich im Nachfolgenden als ung nstig Eine Erl uterung bringt der nachfolgende Abschnitt Ein grunds tzliches Problem an der vorgestellten L sung ist ferner dass das Erzeugen von Auswahlinstanzen nach wie vor ber den direkten Zugriff auf die Konstruktoren und sonstige Erzeugemethoden der Auswahlklassen erfolgen kann Zur zwingenden Verwendung der Fabrik f r die Erzeugung der Instanzen
107. chicht vornehmen zu m ssen F r die Kommunikation zwischen Benutzerschnittstelle und Anwendungslogik findet man analoge Verletzungen der Hierarchie Aus folgenden Kontrollklassen erfolgt der Zugriff in die Schnittstellenschicht auf ein statisches Attribut der Hauptschnittstellenklasse SseminarisH DVKostenBerechnenK DozentenvereinbarungAendernK e DozentenvereinbarungAuswaehlenK e DozentenvereinbarungkErfassenK e DozentenvereinbarungLoeschenK Betrachtet man unter diesem Gesichtspunkt die Drei Schichten Architektur von SeminarlS so gibt das folgende Schaubild Aufschluss ber die zyklische Vernetzung aller Schichten 90 Kapitel 10 Entwurfsprobleme und Testbarkeit Benutzerschnittstelle Anwendungslogik DYKostenBerechnenK Datenhaltung Dozentenvereinbarung Abbildung 101 Invertierung der Drei Schichten Architektur SeminarlS Man sieht dass durch die oben angef hrten Verletzungen der Drei Schichten Architektur alle Schichten zyklisch miteinander verbunden sind Lediglich der Umstand dass der Aufruf der Anwendungsf lle in der Benutzerschnittstelle ber einen in diesem Zusammenhang eigentlich nicht statthaften Reflection Mechanismus erfolgt und dadurch ein Durchbrechen der zyklischen Abh ngigkeiten erreicht wird verhindert eine zyklische Vernetzung des nahezu gesamten Anwendungssystems Implementiert man in der Schnittstellenschicht zur Veranschaulichung explizit alle Abh ngigkeiten die ber den ang
108. chnis besitzen m ssen 3 Entkomprimieren Sie das Archiv durch Eingabe von uncompress d2t tar z Sie erhalten eine unkomprimierte Datei d2t tar 4 Entpacken Sie das Archiv durch Eingabe von tar xf d2 tar 5 L schen Sie die Archivdatei d2 tar im Verzeichnis TGH_MODULES Auf beiden Systemen sollte nach den oben beschriebenen Schritten im Verzeichnis STGH_MODULES ein Verzeichnis design2test existieren Damit ist die Installation bereits abgeschlossen und das Modul wird beim n chsten Start von Together geladen Sie erkennen dies daran dass Ihnen nach dem Start von Together der Men punkt Tools Testability Metrics zur Verf gung steht ACHTUNG Um die Druckmen s von Design2Test nutzen zu k nnen muss das Quality Assurance QA Modul von Together geladen sein Sie erkennen dies an den Men punkten Tools Audits und Tools Metrics im Hauptmen von Together Sind diese Men punkte nicht vorhanden schlagen Sie bitte im User Guide des Together Control Centers nach wie Sie das QA Modul nachladen k nnen 165 Anhang Schnellstart Quick Tour 2 Schnellstart Quick Tour Zur Berechnung von Testbarkeitsmetriken wird zun chst der Sourcecode von ausgew hlten Komponenten eines Projekts auf das Vorhandensein von Abh ngigkeiten zu Komponenten innerhalb und ggf auch au erhalb des Projektes analysiert F r die bei der Analyse des Sourcecodes gefundenen Abh ngigkeiten erfolgt anschlie end die Berechnung und
109. ciPatternManager defaultRootPackage SciPackage Abbildung 2 Zugriff auf die Sourcecode Schicht des Together Open API Die Methode rootPackages im Interface SciModel liefert eines oder mehrere Pakete aus denen sich das Projekt zusammensetzt Diese Pakete sind in Together als Verzeichnisse unter Project Path in den Project Properties aufgelistet wobei es sich hier zumeist nur um ein einziges Paket handelt Ausgehend von diesen Basispaketen die wie alle Pakete das Interface SciPackage implementieren k nnen ber die Methoden subpackages und classes rekursiv alle darin enthaltenen Pakete und Klassen auf der Suche nach Abh ngigkeiten durchlaufen werden interface SciPackage canSseiName boolean flles SciRleEnumeration classes SciClassEnumeration subpackages SciPackageEnu name String qualifiedName String parentPackage SciPackage modelPart String Abbildung 3 Interface SciPackage des Together Open API 13 Kapitel 5 Analyse Der komplette Sourcecode mit den darin enthaltenen Abh ngigkeiten ist in SciClass Objekte gegliedert Ausgehend von den ermittelten Basispaketen erfolgt der Durchlauf durch s mtliche in den Paketen und ihren Unterpaketen als SciClass Objekte verf gbaren Klassen Auf Klassenebene startet die Untersuchung des Sourcecodes nach Abh ngigkeiten Der Programmcode dieser Klassen ist in weitere SCI Elemente strukturiert Eine bersicht ber die elementaren Bestandteile eines SciClass Objekts gibt
110. ct on Diagram ffnet das Klassendiagramm dessen Bestandteil die angeklickte Komponente ist in der Designer Pane von Together Die angeklickte Komponente wird innerhalb des Diagramms selektiert e Show Qualified Name Zeigt den vollst ndig qualifizierten Namen der ausgew hlten Komponente an e Layout Ordnet die angezeigten Komponenten und Abh ngigkeiten neu und aktualisiert die Anzeige Set Color Schema Normal Schalter zum Standard Farbschema um e Set Color Schema Show Component Installiert ein Farbschema zur Anzeige von Zyklen e Set Color Schema Show Dependency Installiert ein Farbschema zur Anzeige der Art der Abh ngigkeit Export As Image M glichkeiten zum Speichern des Graphen zur weiteren Bearbeitung in einem Grafikformat JPEG Export As XML M glichkeiten zum Speichern des Graphen zur weiteren Bearbeitung im XML Format e Print M glichkeit zum Ausdrucken der aktuellen Graphanzeige Eine detaillierte Beschreibung der einzelnen Funktionen finden Sie in Abschnitt 5 2 Funktionen in der Graphanzeige 189
111. cts de Bei den vom Anwendungsentwickler zu realisierenden Teilen handelt es sich um die dunkel hinterlegten Komponenten im linken und mittleren Teil der Grafik z B Pr sentation JSPs Das Bemerkenswerte in diesem Zusammenhang ist dass durch Bereitstellung zahlreicher technische Basisdienste wie Namensdienst JNDI Zugriff auf Datenbanken JDBC JCA deklaratives Transaktions Management JTA JCA und Persistenz EJB der Entwickler gerade von den in diesem Abschnitt beschriebenen Aufgaben und Schwierigkeiten Entlastung finden soll 10 6 2 Auswirkungen auf die Testbarkeit Die Probleme die durch einen versehentlichen bzw fehlerhaften Zugriff auf eine der Basiskomponenten entstehen k nnen wurden bereits geschildert Abschnitte 10 3 bis 10 5 Dar ber hinaus treten weitere Probleme auf Der Zugriff auf die Datenbank erfolgt in allen Varianten fest verdrahtet Dies ist auf die Realisierung der Klasse SeminarisDatenbank als Einzelst ck Singleton zur ckzuf hren Sowohl in SeminarisK als auch in den ErweitertPersistent Klassen erfolgt die Erzeugung und Bereitstellung der Datenbankinstanz durch Aufruf der statischen Methode SeminarisDatenbank getEinzigeInstanz Durch die Abh ngigkeit der Kontrollklassen von Seminarisk und der Ableitung der Datenhaltungsklassen von ErweitertPersistent vergleiche Abschnitt 10 5 2 k nnen in der Kontrollschicht und der Datenhaltungsschicht keine Tests in Isolation von der Datenbank durchgef hrt werden
112. den veranschaulicht werden Hierf r erfolgt zun chst ein Blick auf die Modellierung von Methoden im Together Open API Jede Methode einer Klasseninstanz wird durch ein Objekt vom Typ SciOperation repr sentiert das gleichzeitig noch weitere hierarchisch angeordnete Interfaces implementiert interface SciOhject copy Sci bject cutSci bject cancutboolean delete vold canDelete boolean replace SciObject canReplace boolean setllserPropery vold getUserPropeny Object language String containingFile SciFile interface SciElement canSetName boolean hasPropery boolean setPropery void canSetPropeny boolean isProperyReadable boolean isPropenyWWritable boolean accept bject visiiReferences vold visitReferences vold uniqueName String qualifiedName String containingScope SciScope name String positions SciTextPositions tagList SciTagList Text Ging declarationText String readOnly boolean deleted boolean interface interface ScihHember SciFunction canSetReturnType boolean canSetBody boolean containingClass SciClass signature String returnType SciType definition SciMemberDefinition parameterList SciParameterLis body SciCodeBlock throwList SciThrowList interface SciOperation Abbildung 6 Repr sentation einer Methode im Together Open API Mit Hilfe der von einer Methodeninstanz ber die oben dargestellten Interfaces angebotenen Schnittstellen k nnen im Rahmen der Implementierung der
113. den berechneten Werten Die rACD Werte der Klasse RechnungsempfaengerRelation liegen deutlich ber dem rACD Wert der Abh ngigkeit 9 2 17 2 Bewertung Die beiden beteiligten Klassen resultieren aus der transformierten Assoziation zwischen einer Belegung und einem als Rechnungsempf nger f r die Belegung eingetragenen Gesch ftspartner Die Bewertung der Abh ngigkeiten zwischen Relationen und Paarklassen wurde bereits bei Abh ngigkeit 9 2 14 vorgenommen 9 2 18 SeminarisK LogProtokollDateiA 9 2 18 1 Ergebnisse der Metrikberechnung 2 8 5 z 9 15 1 5 d_type Q o 2 2 2 lt lt Z lt 1 1 10 1 2 12 26 09 00 1 2 create and access Abbildung 71 Abh ngigkeitsmetriken SeminarisK LogProtokollDateiA 73 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 25 51 EK Bn 2 e SE 4120 0 2121 0 0 89 65 62 1 0 0 4 Abbildung 72 Komponentenmetriken SeminarisK A und LogProtokollDateiA Auff lligkeiten bei den berechneten Werten Die rACD Werte der Klasse SseminariskK liegen massiv h her als der rACD Wert der Abh ngigkeit S mtliche von SeminarisK ausgehenden Abh ngigkeiten sind im Sourcecode fest verdrahtet 9 2 18 2 Bewertung Bei der Klasse LogProtokollDateiA handelt es sich um die Implementierung des Anwendungsprotokolls von SeminarlS Im Anwendungsprotokoll w
114. dencySearchlistener dependencyFoundwold classFoundvwold operationFoundvold search void setDependencySearchListener vo setSearchScope void SearchScope isCancelled boolean packageRecursion yoid countPackages void isinScope boolean getString String MyReferenceYisitor MyStatementyisitor MyNewExpressionrReferenceYisitd MyWVisitorutils MyElementYisitor MyExpressionvisitor MMyBasel isitor Abbildung 14 Klassendiagramm des Moduls zur Suche nach Abh ngigkeiten package search Eine Implementierung des Interfaces DependencySearchListener ist daf r verantwortlich auf der Grundlage der ermittelten Abh ngigkeiten den Abh ngigkeitsgraphen f r mproveT zu erzeugen Die f r den Anwender vorzusehende M glichkeit im Startdialog bestimmte Klassen und Pakete von der Sourcecode Analyse des Projekts auszuschlie en ist Inhalt der Implementierung des SearchScope Interfaces Die eigentliche Suche und Ermittlung der Abh ngigkeiten erfolgt wie in der Analyse bereits ausgearbeitet siehe Abschnitt 5 5 3 innerhalb der Klassen des visitors Pakets W hrend der DependencySearcher noch f r das Durchlaufen des Sourcecodes des kompletten Projekts verantwortlich ist bergibt er die Analyse f r jede im Projekt gefundene Klasse an eine Instanz der Klasse MyElementVisitor Diese delegiert die Zust ndigkeit f r die Analyse der einzelnen Klassenbestandteile gegebenenfalls an die anderen visitor Klassen des Paket
115. dernK LeitungsauftragErfassenK 89 Kapitel 10 Entwurfsprobleme und Testbarkeit Die vorhandenen Kontrollklassen orientieren sich an den durch die Anforderungsspezifikation vorgegebenen Anwendungsf llen Einige der Kontrollklassen finden eine nochmalige Untergliederung durch das Paket SeminarverwaltungP Da dieses Paket keine Klassen sondern nur Pakete enth lt wurde es in der Darstellung ausgegraut Zentrale Instanz in der Kontrollschicht ist die Hauptkontrollklasse SeminarisK Die in ihr realisierte Funktionalit t beschr nkt sich auf das Anbieten von statischen Variablen f r den Zugriff auf die Basiskomponenten des Systems wie beispielsweise Datenbank Protokoll und Drucker 10 3 Verletzung der Drei Schicht Architektur 10 3 1 Entwurfsproblem Obwohl als Vorgabe die Entwicklung einer strikten Drei Schicht Architektur galt wurde an drei Stellen aus der Datenhaltungsschicht direkt auf die bergeordnete Kontrollschicht zugegriffen e Die Dom nenklasse Dozentenvereinbarung besitzt Abh ngigkeiten zu den Klassen DVKostenBerechnenK undSeminarisk der Logikschicht e Die Transformationsklassen DozentenvereinbarungAnfragen und DozentenvereinbarungTripel greifen auf die Klasse Seminarisk zu Diese Abh ngigkeiten durchbrechen folglich die hierarchische Ordnung der Schichtenarchitektur und machen damit den Austausch der h her liegenden Kontrollschicht nicht mehr m glich ohne Ver nderungen an der tiefer liegenden Datenhaltungss
116. des Singletons geliefert Die Unabh ngigkeit von der Objekterzeugung wird bei dieser Variante nur auf Kosten von reduzierter Typsicherheit erreicht Da die Singleton Instanzen in der Registry blicherweise als Instanzen vom Typ Object in beispielsweise einer Hashtable gehalten werden sind die M glichkeiten der Typ berpr fung eingeschr nkt hnlich wie bei einer grunds tzlich nat rlich auch denkbaren Reflection L sung Auch hier erfolgt die Erzeugung der Singleton Instanzen blicherweise bei der Initialisierung der Anwendung z B in der Hauptkontrollklasse und damit vor dem eigentlichen Zugriffszeitpunkt Zudem ist weiterhin ein versehentlicher direkter Zugriff auf die Singleton Instanzen innerhalb der Anwendung m glich Zuletzt stellt sich auch hier wieder die Ausgangsfrage Wie erfolgt der Zugriff auf die Registry Allerdings ist hier die Realisierung als Singleton und der statische Zugriff auf die einzige Instanz ohne Nachteile hinsichtlich der dynamischen Konfigurierbarkeit der Anwendung m glich 112 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung Nimmt man also die fehlende Typsicherheit in Kauf so handelt es sich um ein durchaus probates Mittel f r den Zugriff auf globale Komponenten Nicht zuletzt deshalb weil im Rahmen der verteilten und komponentenorientierten Programmierung komplette Anwendungen auf Konzepten beruhen die diesen Mechanismus verwenden Als Stichpunkte seien nur CORBA u
117. die Sie auf Ihrem Ausdruck dargestellt haben m chten Nachdem Sie ggf weitere Angaben zu den Druckereinstellungen gemacht haben bet tigen Sie die Schaltfl che Print um den Ausdruck zu starten 184 Anhang Erweiterte Funktionen und Einstellungen 6 3 Graphanzeige 6 3 1 Speichern des Abh ngigkeitsgraphen im XML Format Um den Abh ngigkeitsgraphen zur weiteren Analyse im XML Format zu speichern w hlen Sie das Untermen Export im Kontextmen der Graphanzeige und dort den Men punkt As XML Hierauf ffnet sich folgender Dialog Save dependency graph to file E E lib E license modules E togethersoft E modules addlinked E antrunner E beans E bookmarks E declshortcuts E defDocComment Dateiname 121 Dateien des Typs XML Graphfile xmi v vg Cancel Help TERN 2 Abbildung 20 Dialog zum Speichern des Abh ngigkeitsgraphen mmm W hlen Sie das Verzeichnis und geben Sie den Namen der XML Datei an unter dem der Abh ngigkeitsgraph gespeichert werden soll Um den Speichervorgang abzuschlie en dr cken Sie die Schaltfl che Save 6 3 2 Speichern des Abh ngigkeitsgraphen im Grafikformat Um den Abh ngigkeitsgraphen im Grafikformat JPEG zu speichern w hlen Sie das Untermen Export im Kontextmen der Graphanzeige und dort den Men punkt As Image Der d
118. e von Reduktionsmetriken aufweisen Diese testkritischen Abh ngigkeiten sind potentielle Kandidaten mit deren Beseitigung bessere Voraussetzungen zur Erreichung der eingangs erw hnten Hauptziele im Testprozess erreicht werden sollten Mit dieser Fragestellung wird sich die vorliegende Arbeit in Teil Fallbeispiel n her besch ftigen Kapitel 2 Aufgabenstellung 2 Aufgabenstellung Das erste Teilziel der vorliegenden Arbeit ist es Softwareentwicklern k nftig ein Werkzeug zur Testbarkeitsanalyse als Bestandteil einer Entwicklungsumgebung anzubieten Die Testbarkeitsanalyse soll insbesondere Hinweise auf m gliche testkritische Abh ngigkeiten zwischen einzelnen Komponenten liefern da diese einen potentiell hohen Einfluss auf die Testbarkeit besitzen siehe Abschnitt 1 3 Ihre Untersuchung scheint deshalb besonders lohnenswert da ihre Entfernung eine vergleichsweise hohe Verbesserung der Testbarkeit verspricht Zur Berechnung der in Abschnitt 1 3 eingef hrten Metriken wurde bereits ein Metrikwerkzeug implementiert das f r eine Integration in eine Entwicklungsumgebung genutzt werden kann Bei der Erweiterung der Entwicklungsumgebung um die Funktionalit t zur Testbarkeitsanalyse sind im Wesentlichen folgende Aufgaben zu erf llen e Ermittlung aller in einem gegebenen Softwaresystem vorhandenen Abh ngigkeiten e Export der Abh ngigkeiten das vorhandene Metrikwerkzeug zur Berechnung der Testbarkeitsmetriken e Darstellung
119. e Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP FirmaErfassenK T_CLASS SeminarisK T_CLASS Class D_DEF_ST FirmaErfassenK T_CLASS SeminarisK T_CLASS Member D_DEF_ST getObjektFirma T_METHOD nextKundennummer T_FIELD 149 Anhang B Aufruf einer klassenfremden statischen Methode Wird auf ein Attribut innerhalb der eigenen Klasse zugegriffen so wird ebenfalls eine Abh ngigkeit auf Memberebene definiert Auf Klassenbebene bleiben klasseninterne Abh ngigkeiten jedoch unber cksichtigt B 14 Aufruf einer klassenfremden statischen Methode B 14 1 Erl uterung und Beispiel Wird eine als statisch definierte Methode einer fremden Klasse aufgerufen so wird hierdurch eine Abh ngigkeit vom Typ D_CALL_ST definiert abstract public class Seminarveranstaltung 1 public static Iterator getAlle throws DatenbankAusnahne return SeminarveranstaltungOrdner getEinzigelnstanz getSVs Als fremde Klasse gelten auch alle u eren Klassen einer inneren Klasse Der Aufruf einer klasseneigenen statischen Methode wird als Abh ngigkeit D_CALL_TS gespeichert B 14 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary 0 DER Seminarveranstaltung T_ABSTR Seminarveranstaltung Ordner CLASS Class D_CALL_ST Seminarveranstaltung T_ABSTR Seminarveranstaltung Ordner T_CLASS Member D_CALL_ST getAlle
120. e Klassen besitzen eine mittlere Zahl von ausgehenden Abh ngigkeiten Der rACD_out Wert von SVAendernErfassenAA liegt etwa beim rACD Wert der Abh ngigkeit Die Anzahl der direkten und indirekten Abh ngigkeiten cd_tr beider Klassen liegt im unteren Bereich der Schnittstellenklassen Die Anzahl statischer Abh ngigkeiten liegt insbesondere in der abh ngigen Klasse relativ hoch 9 2 6 2 Bewertung In der Anforderungsspezifikation existieren exceptional flows zu den Anwendungsf llen Seminartyp bearbeiten a und Seminartyp erfassen b a Die Dozentenvereinbarungen werden bearbeitet extension point b Die Dozentenvereinbarungen werden erfasst extension point Personal Die in der Anforderungsspezifikation vorgeschriebene Bearbeitung oder Erfassung einer Dozentenvereinbarung wurde beim Entwurf von SeminarlS derart realisiert dass hierdurch eine Abh ngigkeit dieses Anwendungsfalless mit den Anwendungsf llen zur Bearbeitung einer Dozentenvereinbarung entstand siehe Abschnitt 10 8 Dies f hrt zur Abh ngigkeit der zu den Anwendungsf llen implementierten Schnittstellenklassen und den damit verbundenen Testproblemen 64 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 9 2 7 LeitungsauftragAendernErfassenAA SV AuswaehlenAA 9 2 7 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken D 9 gt 019
121. e ProtokollManager protokollManager B 8 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP SeminarisDatenbank T_CLASS ProtokollManager T_CLASS Class D_F_TYPE SeminarisDatenbank T_CLASS ProtokollManager T_CLASS Member Um den Bezug zum abh ngigkeitsverursachenden Attribut nicht zu verlieren wird bei der auf Klassenebene eingef gten Abh ngigkeit eine Referenz auf den Attributknoten gespeichert Es erfolgt bez glich des Typs keine Unterscheidung zwischen statischen und nicht statischen Klassenattributen Attribute vom eigenen Klassentyp z B Singleton Instances werden nicht als Abh ngigkeit erkannt B 9 Typ einer lokalen Variablen B 9 1 Erl uterung und Beispiel Innerhalb eines Methodenrumpfes k nnen lokale Variablen definiert werden Handelt es sich beim Typ der lokalen Variablen um einen Objekttyp so wird eine Abh ngigkeit vom Typ D_V_TYPE festgestellt Zu den Objekttypen z hlen beispielsweise auch die mit der Java 2 Platform Standard Edition J2SE ausgelieferten Wrapper Klassen Integer Boolean oder die Klasse String Die Java Basisdatentypen int boolean bleiben hingegen unber cksichtigt public class FirmaloeschenkK public void loeschen String firmaSchluessel throws IFirma persistenteFirma Firma getObjekt firmaSchluessel Lokale Variablen vom eigenen
122. e gezeigt werden dass die Entfernung dieser Probleme mit vergleichsweise geringem Aufwand erfolgen kann Abweichend von der Aufgabenstellung konnte die vorgesehene Testfallerstellung vor und nach der Refaktorisierung des Systems und die Bestimmung der jeweiligen Testaufw nde aus Zeitgr nden nicht mehr in sinnvoller Weise durchgef hrt werden Dies lag zum einen daran dass die Erstellung von Design2Test deutlich mehr Zeit erforderte als geplant Zum anderem waren durch die vorhandenen Testprobleme die Voraussetzungen f r die Erstellung und Durchf hrung von m glichst unabh ngigen Unit Tests denkbar schlecht 128 Kapitel 13 Ausblick 13 Ausblick Der empirische Nachweis dass mit den durchgef hrten Refaktorisierungsschritten nicht nur eine qualitative Verbesserung der Testbarkeit sondern auch eine tats chliche Verringerung der Testaufw nde verbunden ist konnte wie beschrieben aus Zeitgr nden nicht mehr gef hrt werden Dies bleibt weiteren Untersuchungen vorbehalten Ferner wurde im Rahmen dieser Arbeit f r die Analyse von testkritischen Abh ngigkeiten nur ein kleiner Teil der in Design2Test verf gbaren Metriken und Informationen ausgewertet Dies f hrte in erster Linie zur Aufdeckung von Testproblemen die auf allgemeinen Entwurfsfehlern basierten Hier ist die Frage interessant welche zus tzlichen Testprobleme mit der noch nicht ausgenutzten Funktionalit t von Design2Test entdeckt werden k nnen M glicherweise w re f r
123. eg nstigen verhindern oder zumindest erschweren dies die Abh ngigkeiten der anderen Gruppe Kapitel 1 Abh ngigkeiten und Testbarkeit Die Schwierigkeit eine Komponente in der Testphase aufgrund von Abh ngigkeiten nicht f r sich alleine betrachten zu k nnen f hrt erfahrungsgem zu diversen Testproblemen Je gr er die Zahl der zu ber cksichtigenden Abh ngigkeiten einer Komponente desto wahrscheinlicher wird ein hoher Aufwand f r die Testfallerstellung und die Durchf hrung der Tests desto schwieriger im Regelfall die Fehlererkennung und umso weniger Flexibilit t besteht bei der Bestimmung einer geeigneten Testreihenfolge Ein besonderes Testproblem stellen ferner zyklische Abh ngigkeiten dar Grunds tzlich k nnen alle an einem Zyklus beteiligten Komponenten nur gemeinsam getestet werden Dies versch rft die oben bereits angef hrten Probleme wie beispielsweise die Lokalisierung von Fehlern Durch den Einsatz von Stellvertretern Stubs k nnen die zyklischen Abh ngigkeiten zwar aufgel st werden dies erfordert jedoch zus tzlichen Aufwand und f hrt zu erh hter Komplexit t bei der Testfallerstellung 1 3 Testbarkeitsmetriken zur Identifizierung testkritischer Abh ngigkeiten In der Literatur existieren bereits verschiedene Vorschl ge f r Metriken zur Beurteilung der Testbarkeit eines Systems Darunter finden sich auch bereits Ans tze die sich mit der Architektur und den Abh ngigkeiten innerhalb eines Systems aus
124. einandersetzen LoSh98 1509126 und Lako96 Diese beurteilen zwar anhand der Abh ngigkeiten die Testbarkeit einzelner Komponenten oder des gesamten Systems sie liefern jedoch keine Hinweise darauf welche konkreten Abh ngigkeiten Ausl ser f r einen Mangel an Testbarkeit sind Um in einem Softwaresystem jene Abh ngigkeiten identifizieren zu k nnen die in besonderem Ma e die Testbarkeit beeintr chtigen wurde in Jung02 ein neuer Ansatz vorgeschlagen Er basiert auf der Erwartung dass die Hauptziele im Testprozess n mlich mit m glichst geringem Aufwand und in m glichst kurzer Zeit eine m glichst hohe Qualit t der zu testenden Software zu erreichen insbesondere bei m glichst hoher Unabh ngigkeit der zu testenden Komponenten erreicht werden k nnen F r die Einsch tzung dieser Unabh ngigkeit werden in einem ersten Schritt Metriken zur Messung bestimmter Eigenschaften des Systems definiert Dabei handelt es sich beispielsweise um folgende Metriken Average Component Dependency Hierbei handelt es sich um die durchschnittliche Anzahl von Komponenten von denen eine Komponente des Systems direkt oder indirekt abh ngt e Number Of Feedback Dependencies Diese Metrik gibt die Anzahl der Abh ngigkeiten an deren Entfernung zur Aufl sung von Zyklen des Systems f hrt Number Of Stubs Needed To Break Cycles Bei der Testdurchf hrung ist das Durchbrechen von zyklischen Abh ngigkeiten zwischen An
125. eiten im System durch die zentrale B ndelung in der Klasse SseminariskK e infolge von schichtenverletzenden Zugriffen zu zyklischen Abh ngigkeiten innerhalb der Anwendung 109 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung e f hrt aufgrund der fest verdrahteten Abh ngigkeiten bei der Objekterzeugung zu einer mangelnden Austauschbarkeit der Basiskomponenten in der Testumgebung und damit zu einer ma geblichen Beeintr chtigung des Testprozesses 11 5 2 Durchf hrung des Refactoring F r die Realisierung des Zugriffs auf globale Basiskomponenten eines Systems stehen mehrere M glichkeiten zur Verf gung Nachfolgend werden zun chst einige dieser Konzepte vorgestellt und auf ihre Vor und Nachteile hin untersucht Aus Sicht der Testbarkeit ist bei dieser Untersuchung die Frage von zentraler Bedeutung wie ein Austausch der Basiskomponenten in der Testumgebung erreicht werden kann 11 5 2 1 Direkter Zugriff auf die Basiskomponenten Die Realisierung der Basiskomponenten erfolgt zumeist nach dem Entwurfsmuster Singleton Gamm94 Uber die statische Methode zur Erlangung der einzigen Instanz z B getInstance ist es m glich an jedem Punkt der Anwendung global auf die Komponente zuzugreifen Mit dem direkten Zugriff w re zwar das Problem der B ndelung und Abh ngigkeit aller Basiskomponenten beseitigt jedoch bleibt der fest verdrahtete Zugriff auf die einzige Instanz und die fehlende Austauschbarkei
126. ektmetriken vor und nach Entfernung der Abh ngigkeit von der Datenbank zur Datenhaltung Die Anzahl der Klassen von denen eine Klasse im Durchschnitt direkt oder indirekt abh ngig ist ist um 15 4 Prozent gesunken beschr nkt auf fest verdrahtete Abh ngigkeiten sogar um 27 1 Prozent Der gro e Abh ngigkeitszyklus in der Datenhaltung wurde in f nf kleinere voneinander unabh ngige Zyklen aufgespalten die Anzahl der zyklischen abh ngigen Komponenten hat sich dabei nur unwesentlich verringert Ein Blick auf die Abh ngigkeits und Komponentenmetriken zeigt insbesondere dass die rACD Werte sowohl f r die nach wie vor vorhandene Abh ngigkeit von SeminarisK nach SeminarisDatenbank Verringerung rACD von 6 05 Prozent auf 0 19 Prozent als auch f r beide Klassen deutlich gesunken sind a vor Refactoring nach Refactoring Abbildung 115 Komponentenmetriken vor und nach Entfernung der Abh ngigkeit von der Datenbank zur Datenhaltung Von dieser Refaktorisierung betroffen sind auch alle anderen testkritischen Abh ngigkeiten die von SeminarisDatenbank abh ngen Beispielsweise sinken die Werte der Metriken rACD und rACDh f r die Abh ngigkeit von ErweitertPersistent nach SeminarisDatenbank siehe Abschnitt 9 2 11 von 1 4 und 4 4 auf 0 1 und 0 6 11 5 Ver nderter Zugriff auf globale Basiskomponenten 11 5 1 Ausgangssituation Die aktuelle Form des Zugriffs auf globale Basiskomponenten f hrt e zu einer Erh hung der Abh ngigk
127. el 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten F r die Verbesserung der Testbarkeit jener Methode der Klasse MeldungsAnzeigeA in der die Abh ngigkeit ausgel st wird w rde die Entfernung keinen wesentlichen Beitrag leisten 9 2 14 TeilnahmeFirmenSVRelation TeilnahmeFirmenSVPaar 9 2 14 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken S D 9 5 z DI 3 1 2 2 8 2 lt lt lt lt lt 2 0 0 0 Abbildung 64 Komponentenmetriken TeilnahmeFirmenSVRelation und TeilnahmeFirmenSV Paar Auff lligkeiten bei den berechneten Werten Die rACD Werte der Klasse TeilnahmeFirmenSVRelation liegen deutlich ber dem rACD Wert der Abh ngigkeit 9 2 14 2 Bewertung Die Klassen TeilnahmeFirmenSVRelation und TeilnahmeFirmenSVPaar resultieren aus der Transformation der Assoziation zwischen einem Firmenseminar und einer daran teilnehmenden Person Die Transformationstechnik ist ein bliches Muster und wurde nach den Vorgaben durchgef hrt SWEI99 W hrend blicherweise allerdings der Zugriff auf die Relationenklasse aus der Kontrollschicht direkt erfolgt fungierten in SeminarlS die Dom nenklassen als Fassade f r den Zugriff auf die Assoziation Dies f hrte zu einer zyklischen Vernetzung der nahezu kompletten Datenhaltungsschicht siehe Abschnitt 10 7 Die Abh ngigkeite
128. elationenklasse im Rahmen einer Datenbankabfrage ermittelte Ergebnismenge noch aufbereitet werden so ist diese zus tzliche Logik nicht mehr in der Ordner oder Relationenklasse sondern bereits in der Dom nenklasse realisiert wie nachstehendes Beispiel aus der Dom nenklasse Firma veranschaulicht public static Collection getAlleSchluessel throws DatenbankAusnahme Iterator iter getAlle Vector ergebnisMenge new Vector while iter hasNext ergebnisMenge add IFirma iter next getSchluessel return ergebnisMenge Der ausschlie liche Zugriff ber die Dom nenklassen auf die Ordner und Relationenklassen wurde nur an einigen wenigen Stellen durchbrochen ohne funktionale Notwendigkeit sondern lediglich aus Unwissenheit Unachtsamkeit oder an ganz wenigen Stellen auch aus Performanzgr nden Im Zusammenhang mit der beschriebenen Verletzung der Drei Schichten Architektur Abschnitt 10 3 f llt auf dass ein Ausl ser in der Fassadenfunktion der Dom nenklassen vermutet werden kann Die Klasse Dozentenvereinbarung bietet in ihrer Schnittstelle eine Methode an f r deren Implementierung nennenswerte Logik zu realisieren ist Um dies erf llen zu k nnen reicht die Entit tsmethode den Aufruf auch an dieser Stelle im Stile einer Fassade weiter 99 Kapitel 10 Entwurfsprobleme und Testbarkeit public IGeld getKosten String vonDatum String vonzZeit String bisDatum String bisZeit throws Dat
129. elten Abh ngigkeits und Komponentenmetriken sind wie in Abschnitt 5 7 1 beschrieben nach Abschluss der Analysen in den beiden Tabellenmodellen VersionAnalysis und NodeAnalysis gespeichert mproveT stellt zwei von der Java Swing Klasse JTable abgeleitete Tabellen zur Anzeige der Ergebnisse zur Verf gung VersionAnalysis und NodeAnalysisTable Beide Tabellen erwarten bei der Instantiierung die w hrend der Analyse aufgebauten Tabellenmodelle siehe Abschnitt 5 7 1 als bergabeparameter Diese erm glichen den Zugriff auf die in den Tabellen angezeigten Kanten und Knoten des Abh ngigkeitsgraphen Hierzu stellen sie Methoden zur Verf gung die f r eine Zeile der Tabelle die dahinter liegende Kante oder den zugrunde liegenden Knoten liefern Ferner kann zu jeder Spalte der Tabelle die Instanz der angezeigten Metrik vom Tabellenmodell abgerufen werden Edge getEdgeForRow int row MetricSet getMetric int col Node getNodeForRow int row NodeMetric getMetric int col Die beiden Graphelemente Edge und Node stellen weiterhin verschiedene Methoden zur Verf gung um die in den vorhergehenden Abschnitten bereits beschriebene Struktur des Abh ngigkeitsgraphen wieder auslesen zu k nnen So bieten beispielsweise die Verbindungen zwischen den verschiedenen Graphebenen die M glichkeit zur Navigation innerhalb des Graphen um eine detaillierte Anzeige der Abh ngigkeiten zu realisieren Um bei der Anzeige der Metrikergebnisse die un
130. en 4 2 Komponentenmetriken Haben Sie Metriken aus der Kategorie Komponentenmetriken ausgew hlt so werden Ihnen die Ergebnisse der Berechnung in einem Unterpanel Component Metrics der Message Pane von Together angezeigt Message Pane Bisi E id name cd cdt cd_h_i cd_h_iscd_h_scd_ci cd_ci_hrACD_in rACD_out of Depend Dependee Component Co 19 0 1 17073 21 951 0 interface interface 124 SortedMap create and access SortedMap class 69 JTreeTable dep to class Graph YyiewMouseH Class Type Depend Dependent Component of Co dep to class Graph viewMouseH class EI st ch create and access Design2Test class 179 TreeTableModel 322 SortedList u 11 version nalysisTable 3 1 3 7 TableSorter 1 0 0 2 EN Messages Dependency Metrics Component Metrics Abbildung 3 Component Metrics Panel Im linken Teil der geteilten Anzeige erhalten Sie die errechneten Metriken in Tabellenform angezeigt In den Zeilen der Tabelle erhalten Sie s mtliche Komponenten des analysierten Projektes aufgelistet In den Spalten der Tabelle werden Ihnen die zugeh rigen Werte der Metriken angezeigt die von Ihnen im Startdialog ausgew hlt wurden Auff llige Metrikwerte sind in der Tabelle farbig hinterlegt Im rechten Teil der Anzeige werden Ihnen zu jeder auf der linken Seite ausgew hlten Kompo
131. en Diese Abh ngigkeiten werden durch einen entsprechenden Kommentar im Sourcecode repr sentiert Verl uft diese manuelle Abh ngigkeit zwischen zwei Klassen wird eine Abh ngigkeit D_MANU definiert 159 Anhang Manuelle Together Abh ngigkeiten public class Firma link dependency ErweitertPersistent InkErweitertPersistent B 31 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Knotentyp Nach Knotentyp Summary D_DEP Firma T_CLASS ErweitertPersistent T_CLASS Class D_MANU Firma T_CLASS ErweitertPersistent T_CLASS Member 160 Anhang B Einschr nkungen Einschr nkungen Initialisierung von Attributen durch anonyme Klassen In der Version 6 0 erkennt Together nicht wenn anonyme Klassen zur Initialisierung eines Attributes einer Klasse verwendet werden Alle Abh ngigkeiten die in dieser anonymen Klasse definiert werden bleiben derzeit unber cksichtigt Ein Workaround k nnte an dieser Stelle nur mit erheblichem Aufwand implementiert werden Die Initialisierung einer lokalen Variable mit einer anonymen Klasse ist hiervon nicht betroffen Initialisierung von Arrays Ab Version 6 0 liefert Together bei der Initialisierung eines Arrays mittels new Operator innerhalb einer Methode beim Durchlaufen des Methodenrumpfes auch eine Referenz auf diese Initialisierungs Elemente Die Referenzen innerhalb de
132. en klassenlokale Abh ngigkeiten Abh ngigkeiten zwischen Elementen derselben Klasse werden nur auf Memberebene im Graph gespeichert Abh ngigkeiten die zwischen einem Klassenelement member und einer Klasse verlaufen wie beispielsweise die Abh ngigkeit einer Methode zum Klassentyp eines Parameters werden nur auf Klassenebene im Graphen gespeichert Auch hier existiert je Abh ngigkeitstyp nur ein Eintrag Um den Bezug zu den ausl senden Klassenelementen nicht zu verlieren werden die Elemente als Unterknoten bei der Abh ngigkeit gespeichert e F r jeden Konstruktor einer Klasse wird eine Abh ngigkeit zu allen Instanzinitialisierern instance initializers der Klasse modelliert Der Eintrag erfolgt nur auf Memberebene e Auf zusammengefasster Klassenebene summary class level existiert nur maximal eine Abh ngigkeit zwischen abh ngiger und aufgerufener Klasse Alle Abh ngigkeiten der Klassenebene werden dort zusammengefasst erg nzt um die Abh ngigkeiten innerer und anonymer Klassen e S mtliche Klassen des Systems wie auch s mtliche Konstruktoren der Klassen werden als Knoten im Abh ngigkeitsgraph gespeichert Hierbei spielt es keine Rolle ob eine Klasse oder ein Konstruktor an einer Abh ngigkeit beteiligt ist oder nicht 19 Kapitel 5 Analyse 5 7 Export des Abh ngigkeitsgraphen und Start der Metrikberechnung 4 Nach der Erzeugung des Abh ngigkeitsgraphen muss der Export des Graphen nach mproveT erfolgen
133. en zu Metriken Der Benutzer ruft zu den angezeigten Metriken in einem Hilfefenster n here Erl uterungen ab alternate flow Speichern der Metriken Die errechneten Metriken k nnen im Textformat zur weiteren Verarbeitung z B mit einem Tabellenkalkulations oder Statistikprogramm gespeichert werden extension point Metriken 1 alternate flow Ausdruck der Metriken Der Benutzer l sst sich die tabellarische Anzeige der Metriken ausdrucken extension point Metriken drucken alternate flow Graphische Darstellung der Abh ngigkeiten Der Benutzer ruft eine Darstellung der Komponenten des Projektes und der zwischen ihnen ermittelten Abh ngigkeiten als geometrischer Graph auf extension point Abh ngigkeitsgraph anzeigen alternate flow Anzeige der Projektmetriken In der Anzeige der Abh ngigkeitsmetriken ruft der Benutzer die f r das Gesamtprojekt errechneten Reduktionsmetriken zur Anzeige auf alternate flow Anzeige der Projektmetriken nach Ausschluss Der Benutzer w hlt in der Anzeige der Abh ngigkeitsmetriken eine oder mehrere Abh ngigkeiten aus und erh lt die Projektmetriken angezeigt die sich nach Entfernen der ausgew hlten Abh ngigkeiten ergeben postcondition Die vom Benutzer ausgew hlten Testbarkeitsmetriken wurden berechnet und werden angezeigt end Testbarkeitsmetriken berechnen A 2 2 Anwendungsfall Testbarkeitsmetriken erstmalig berechnen use case Testbarkeitsmetriken erstmalig
134. enFabrik getAAKlassenFabrik public static void setAAKlassenFabrik IAAKlassenFabrik aktuelleAAKlassenFabrik public static JFrame getHauptFenster if hauptFenster null throw new IllegalStateException Hauptfenster ist nicht gesetzt return hauptFenster public static void setHauptFenster JFrame aktuellesHauptFenster hauptFenster aktuellesHauptFenster Dieser Entwurf f hrt jedoch dazu dass jede Klasse sich zur Anforderung der Instanz des Hauptfensters der Klasse SeminarisSystem bedienen muss vom Interface IAAKlassenFabrik und transitiv von den darin definierten Typen abh ngig wird Damit wird insbesondere die durch den Factory Mechanismus gewonnene Unabh ngigkeit in der Testphase wieder deutlich reduziert Es sollte daher auf jeden Fall von einer zentralen Instanz zur Verwaltung von Ressourcen wie z B Fabriken Datenbanken Anwendungsfenster abgesehen werden Stattdessen erh lt jede dieser Ressourcen eine eigene Provider Klasse zur Seite gestellt siehe auch Abschnitt 11 5 2 5 Dies f hrt zur Einf hrung von zwei Klassen AAKlassenFabrikProvider und MainWindowProvider die beide den ihnen zugeh rigen Part aus der oben beschriebenen Klasse SeminarisSystem bernehmen Der gesamte Zeitaufwand f r die Refaktorisierung betr gt 4 Stunden 11 7 5 Ergebnisse Man erh lt folgende Ver nderung der Projektmetriken ren Project Metrics
135. enbankAusnahme DVKostenBerechnenK dVKBK new DVKostenBerechnenK dVKBK setBisTag bisDatum dVKBK setBisUhrzeit bisZeit aVKBK setVonTag vonDatum dVKBK setVonUhrzeit vonZeit aVKBK setStundensatz stundensatz aAVKBK setTagesarbeitszeit 8 return dVKBK berechnekKosten Dieses Mal allerdings nicht an die Methoden der Ordner und Relationenklassen sondern es erfolgt der Aufruf einer in der Kontrollschicht angesiedelten Methode Dies f hrt zu der Abh ngigkeit mit dem h chsten rACD Wert des ganzen Systems siehe Abschnitt 9 2 1 M glicherweise w re die Abh ngigkeit nicht entstanden wenn bei der Realisierung von sSeminarlS auf die Fassadenfunktionalit t in der Datenhaltung verzichtet worden w re und zudem der strikte Grundsatz gegolten h tte die Dom nenklassen frei von jeglicher Gesch ftslogik zu halten 10 7 2 Auswirkungen auf die Testbarkeit Beschr nkt sich die Aufgabe der Dom nenklassen Methode ausschlie lich auf das Durchreichen des Methodenaufrufs so k nnte man versucht sein auf den Test der Methode zu verzichten da die eigentliche Funktionalit t bereits in der Ordner oder Transformationenklasse getestet wurde Leider f hrt die Entscheidung zugunsten einer Fassade im Verbund mit dem Persistenz Rahmenwerk zu gravierenden Problemen beim Durchreichen von Methodenaufrufen von den Dom nenklassen an die transformierten Assoziationsklassen Das Problem taucht auf wenn sich die Dom nenklasse beim
136. endigkeit und Sinnhaftigkeit zu pr fen und Alternativvorschl ge zu geben Die Testkritikalit t dieser Abh ngigkeit entsteht als Folge der Abh ngigkeiten 9 2 1 Dozentenvereinbarung DVKostenBerechnenK und 9 2 8 DVKostenBerechnenK DozentenvereinbarungLoeschenK F r sich alleine ist sie weitestgehend unbedenklich und auf einen Vorschlag zur Refaktorisierung der Abh ngigkeit wird deshalb aus den vorgenannten Gr nden verzichtet 9 2 29 Seminartyp SeminartypOrdner 9 2 29 1 Ergebnisse der Metrikberechnung 5 E 2 N 4 m 92 d Z lt 0 1 8 101 2 0 0 0 9 0 0 static access Abbildung 93 Abh ngigkeitsmetriken Seminartyp SeminartypOrdner 3 5 D 2 82 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten rACD_in Abbildung 94 Komponentenmetriken Seminartyp A und SeminartypOrdner B 9 2 29 2 Bewertung Auch diese Abh ngigkeit entsteht unmittelbar aus der in Abschnitt 10 7 beschriebenen Fassadenfunktionalit t der Dom nenklassen Die Klasse Seminartyp fungiert als durchreichende Stelle f r verschiedene Methodenaufrufe ihrer Ordnerklasse Zur weiteren Bewertung dieser Form der Abh ngigkeit siehe Abh ngigkeit 9 2 27 SeminarveranstaltungOrdner OeffentlicheSeminarveranstaltung 9 2 30 ParameterEingabeModel IAnfrageParameter 9 2 30 1 Ergebnisse der Metrikberechnung Q Me 2 0 z 1 8 0 0
137. endung zu erm glichen Dies ist ein grunds tzliches Problem auf das in Abschnitt 10 6 Zugriff auf globale Basiskomponenten n her eingegangen wird e Ferner wurde in SeminarisK und SeminarisDatenbank die Verwaltung von eindeutigen Bezeichnern f r einzelne Dom nen realisiert Dies f hrt insbesondere zur Abh ngigkeit der Basiskomponente SeminarisDatenbank von der Datenhaltungsschicht Diese Problematik wird in Abschnitt 10 5 Zugriff auf Datenhaltung n her beleuchtet F r eine exaktere Bestimmung des Einflusses der genannten Probleme auf den rACD Wert der Abh ngigkeit stehen in der Together Erweiterung weitere Funktionalit ten zur Verf gung Zur Erinnerung nochmals die Ver nderungen bei den Projektmetriken durch Entfernung der Abh ngigkeit Project Metrics without Excluded EN Zerovalue Improvement of components NaN 2730 NaN 83 74908 89 11439 6 0206985 36 0 39 0 7 6923065 70 50 40 0 105 0 106 0 0 9433975 79 0 81 0 2 4691315 2620 60 35496 NaN Abbildung 35 Projektmetriken nach Entfernung der Ursprungsabh ngigkeit Alternativ wird nun die Abh ngigkeit von SeminarisK zuSeminarisDatenbank beibehalten und stattdessen werden die Abh ngigkeiten von SeminarisDatenbank zur Datenhaltungsschicht entfernt Hierbei ist bemerkenswert dass alle entfernten Abh ngigkeiten einen rTACD Wert von 0 aufweisen und dar ber hinaus tats chlich erst die vollst ndige Entfernung aller acht Abh
138. er Abh ngigkeits und Komponentenmetriken e Bereitstellung der Analyseergebnisse f r die weitere Verarbeitung Eine n here Beschreibung der Funktionalit t und der angebotenen Schnittstellen von mproveT erfolgt bei der Analyse der Teilaufgaben in den nachfolgenden Abschnitten dieses Kapitels 5 3 Entwicklungsumgebung Together Im Lehrgebiet Praktische Informatik III der FernUniversit t Hagen wurden unter anderem im Rahmen von Software Praktika gute Erfahrungen mit der Software Entwicklungsplattform Together ControlCenter kurz Together der Firma TogetherSoft gemacht Diese Entwicklungsumgebung unterst tzt den kompletten Software Entwicklungsprozess Neben der Implementierung werden auch die Analyse und Entwurfsphase durch umfangreiche Funktionalit t unterst tzt Kapitel 5 Analyse Together stellt als grundlegende Voraussetzung f r die Integration von mproveT eine frei zug ngliche Java Programmierschnittstelle standardm ig zur Verf gung Diese als Together Open API bezeichnete Programmierschnittstelle bildet die Basis f r die Entwicklung von Together Erweiterungen Sie bietet hierzu die M glichkeit auf alle Modellelemente sowie den kompletten Sourcecode eines Softwareprojekts zugreifen zu k nnen Ein auf Grundlage dieser Schnittstelle entwickeltes Modul zur Bestimmung der Abh ngigkeiten eines Systems ist ebenfalls im Lieferumfang enthalten Leider zeigte sich bald dass die Funktionalit t dieses Moduls f r die Wieder
139. er Kontrollklasse die f r das L schen eines Datensatzes verantwortlich ist entsprechende Protokollfunktionalit t Diese Funktionalit t der Klasse DozentenvereinbarungLoeschenK wurde hier in fehlerhafter Weise zur Speicherung von Debug und Fehlermeldungen zweckentfremdet Wie bereits bei Abh ngigkeit 9 2 1 Dozentenvereinbarung DVKostenBerechnenK erl utert findet die Klasse DVKostenBerechnenkK in der Anwendung keine aktive Verwendung Die Klasse und damit auch die vorliegende Abh ngigkeit kann ohne Einschr nkung der Funktionalit t aus dem Projekt entfernt werden 9 2 9 SeminarbelegungAA SV AuswaehlenAA 9 2 9 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken 66 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten lasse cd_s_cu cih cd_im_h cd_tr d_h_tr cd_is_tr rACD_in _ jed_h_is ed_h_s _ jed_s_c cd_s_a cd_ci cd_im x A B Abbildung 54 Komponentenmetriken SeminarbelegungAA A und SVAuswaehlenAA Auff lligkeiten bei den berechneten Werten Die rACD Werte der Klasse SVAuswaehlenAA sind die f nfth chsten aller Klassen Die Anzahl der vonSeminarbelegungAA ausgehenden Abh ngigkeiten liegt bei einem sehr hohen Wert cd Durch direkte und indirekte Beteiligung an verschiedenen Zyklen handelt es sich ferner bei den Anzahlen der Klassen von denen beide Klassen abh ngig sind cd_tr um mit die h chsten Werte des Systems 9 2
140. er TableSorter sortedColumn int dependencyTable DependencyTable sortedAscending boolean dependencyTableModel DependencyTableModel rootPane JSplitPane e EdgeMetricsMouseListener mediator D2TMediator javax swing table AbstractTableModel mouseQlicked void mouseListener MouseListener ImproveT analysis VersionAnalysis mousePressed void mouseReleased void S5howEdgeMetricsPane showPopupMenu yoid createRootPane void 4 addListSelectionListener void openPane void updateForEdge void ActionListener SaveEdgeMetricsDialog MouseAdapter DependenciesMouseListener versionAnalysis YersionAnalysis SaveEdgeMetricsDialog actionPerformed void DependenciesMouseListener mouseClicked void mousePressed void mouseReleased void showPopupMenu void ai ShowProjectMetricsDialog DefaultProjectMetricsDialog R instance ShowProjectMetricsDialog dialog JDialog digBounds Rectangle rootPane JPanel metricsTable JTable dependencies metricTableModel DefaultTableModel DependencyTableModel columnNames Object DependencyTable etinstance ShowProjectMetricsDialo S5howProjectMetriesDialog createDialog yoid showDialog void createRootPane void closeDialog yoid Abbildung 20 Anzeige der Komponentenmetriken package nodemetrics Die Anzeige der Abh ngigkeitsmetriken wird gesteuert durc
141. er befindet sich in der Anzeige der Abh ngigkeits oder Komponentenmetriken main flow Der Benutzer l sst sich das Klassendiagramm zu einer Komponente anzeigen Hierzu wird das Klassendiagramm im Designfenster von Together ge ffnet und die ausgew hlte Komponente im Diagramm selektiert postcondition Das Klassendiagramm dessen Bestandteil die ausgew hlte Komponente ist wird im Designfenster von Together angezeigt end Navigation zu Klassendiagramm A 2 7 Anwendungsfall Metriken speichern use case Metriken speichern actors Together Benutzer precondition Eine Testbarkeitsanalyse wurde durchgef hrt Der Benutzer befindet sich in der Anzeige der Abh ngigkeits oder Komponentenmetriken main flow Der Benutzer speichert die angezeigten Metriken in einem Textformat zur weiteren Verarbeitung Der Speicherort ist frei w hlbar postcondition Die Metriken wurde in einer Textdatei gespeichert end Metriken speichern A 2 8 Anwendungsfall Metriken drucken use case Metriken drucken actors Together Benutzer Drucker precondition Eine Testbarkeitsanalyse wurde durchgef hrt Der Benutzer befindet sich in der Anzeige der Abh ngigkeits oder Komponentenmetriken main flow Der Benutzer w hlt die Druckeinstellungen und druckt die angezeigten Abh ngigkeits oder Komponentenmetriken aus postcondition Die Metriken wurden ausgedruckt end Metriken drucken 137 Anhang Textuelle Anwendungsfallspezifikationen
142. er indirekt abh ngig so sank diese Zahl nach der Refaktorisierung auf ca 51 Klassen Die durchschnittliche Zyklengr e sank durch die Umgestaltung der Datenhaltung von ca 21 Klassen auf ca 8 Klassen Im Hinblick auf den zu leistenden Testaufwand war insbesondere die Tatsache von Bedeutung dass durch die Refaktorisierung die Anzahl der Methoden in der Datenhaltung um ber ein Drittel von 964 auf 634 Methoden gesenkt werden konnte Damit wird der an dieser Stelle zu leistende Testaufwand deutlich reduziert e Zur Umgestaltung der Schnittstellenschicht wurde ein Factory Mechanismus eingef hrt der eine Trennung von Objekterzeugung und Verwendung der Instanzen erm glichte Damit konnte die Unabh ngigkeit der Anwendungsf lle erreicht und alle zyklischen Abh ngigkeiten aus der Schnittstellenschicht beseitigt werden was zu einer Reduzierung der insgesamt an Zyklen beteiligten Klassen um etwa 20 Prozent f hrte Insgesamt zeigte sich dass die mit Hilfe von Design2Test ermittelten Metriken ein hervorragendes Instrument zur Anzeige von massiven Testproblemen waren Wie gezeigt werden konnte resultierten diese Schwierigkeiten zur Testfallerstellung und Testdurchf hrung aus teilweise schwerwiegenden Entwurfsproblemen und Implementierungsfehlern ber die Beseitigung der von Design2Test identifizierten testkritischen Abh ngigkeiten konnte in der Folge eine deutliche Verbesserung der Testbarkeit des analysierten Systems erreicht werden Zudem konnt
143. ere folgende Fragen n her untersucht und soweit m glich beantwortet werden e Bieten die Testbarkeitsmetriken die M glichkeit zur Identifikation jener Programmteile die die Testbarkeit eines objektorientierten Softwaresystems berm ig verschlechtern e Welche der verf gbaren Testbarkeitsmetriken und erg nzenden Informationen zeigen dies in welchen Konstellationen und Auspr gungen an e Wie hoch ist der Aufwand der zur Beseitigung von testkritischen Abh ngigkeiten geleistet werden muss e welchem Ma e und Umfang tr gt die Beseitigung der Abh ngigkeiten zu einer Verbesserung der Testbarkeit bei F r die Beantwortung dieser Fragen waren folgende Arbeitsschritte vorgesehen e Ermittlung der Testbarkeitsmetriken f r das im Fallbeispiel zu untersuchende Softwaresystem und Bewertung der Ergebnisse e Exemplarische Durchf hrung von Refaktorisierungsschritten zur Beseitigung von ausgew hlten Abh ngigkeiten und Bestimmung des Aufwands e Erstellung und Durchf hrung von geeigneten Testf llen f r das System vor und nach der Entfernung von ausgew hlten Abh ngigkeiten und Bestimmung der Testaufw nde 47 Kapitel 8 Einf hrung e Sofern m glich Entwicklung und Beschreibung von Heuristiken zur Identifizierung von vergleichsweise einfach zu entfernenden testkritischen Abh ngigkeiten Nach einer kurzen Beschreibung des zu untersuchenden Softwaresystems SeminarlS im n chsten Abschnitt beginnt die Analyse von Se
144. erf hig im System vorhanden sein Dies reduziert die m glichen Testreihenfolgen und f hrt unter Umst nden zu Verz gerungen in der Testdurchf hrung Jede dieser Klassen muss in wenigstens einem Testfall des Moduls kompiliert und unter Umst nden auch geladen und instantiiert werden Dies erh ht den Zeitaufwand f r die Testdurchf hrung erheblich e Als Ursprung von Fehlern kommen grunds tzlich alle beteiligten Komponenten in Betracht was die Lokalisierung von Fehlern deutlich erschwert Eine M glichkeit diese Probleme zu beseitigen oder wenigstens zu reduzieren besteht in der Verwendung von Stellvertretern Stubs oder Mocks LinkO1 f r die ben tigten Klassen Dass von den durchschnittlich 90 ben tigten Komponenten zwei Drittel ber fest verdrahtete Abh ngigkeiten verbunden sind Metrik ACDh verhindert jedoch f r diese Klassen die Anwendung dieser Strategie Diese Komponenten k nnen nur dann durch Stellvertreter ersetzt werden wenn nderungen an der Implementierung der abh ngigen Klasse vorgenommen werden Eine weitere Versch rfung der Testprobleme ergibt sich durch Abh ngigkeitszyklen Alle an einem Zyklus beteiligten Komponenten k nnen nur zusammen getestet werden M chte man die Zyklen aufbrechen so m ssen zus tzliche Stellvertreter implementiert werden Dies Kann jedoch auch nicht verhindern dass die Testfallerstellung durch Abh ngigkeitszyklen erheblich an Komplexit t gewinnt 92 Kapitel 10 Entwurfspro
145. erte Metrikauswahl zu setzen bet tigen Sie im Dialog zur Metrikauswahl gt 3 Metrikauswahl die Schaltfl che Set Defaults d pe RW Load Set Abbildung 11 Optionen Leiste im Metrikdialog Select All 6 1 2 Speichern einer Metrikauswahl Sie haben die M glichkeit eine von Ihnen vorgenommene Metrikauswahl f r eine erneute Verwendung speichern Klicken Sie hierzu auf die Schaltfl che Save Set As im Dialog zur Metrikauswahl gt 3 Metrikauswahl nn d_type Select All Unselect All Set Defaul Save Set As Abbildung 12 Optionen Leiste im Metrikdialog W hlen Sie in dem erscheinenden Auswahldialog den gew nschten Speicherort und den gew nschten Namen der Datei 179 Anhang Erweiterte Funktionen und Einstellungen Save Metric Set E 9 98 9 Analysen Arbeit Datenbank Programme E JBuilder lt Together6 0 E bin bundled Dateiname defaultMetrics tms v Dateien des Typs Testability Metric Set 7 Help Ss Abbildung 13 Dialog zum Speichern einer Metrikauswahl Wie in der Abbildung als Beispiel gezeigt k nnen Sie auf diese Art auch die Standard Vorbelegung berschreiben sofern Sie dies m chten 6 1 3 Einlesen einer gespeicherten Metrikauswahl Um Ihre gespeicherten Metrikauswahlen wieder abzurufen bet tigen
146. erzeugung zu erreichen ist die Verwendung des Entwurfsmusters AbstractFactory siehe Gamm94 F r den Zugriff auf die Datenbankinstanz k nnte die Realisierung beispielsweise wie folgt aussehen Zugriff auf die Datenbank in der Anwendung public class Firma private Datenbank db public Firma AbstrakteDatenbankFabrik df db df getDatenbank Implementierung der abstrakten Fabrikklasse nach dem Entwurfsmuster AbstractFactory abstract class AbstrakteDatenbankFabrik abstract Datenbank getDatenbank Konkrete Bereitstellung der Datenbank in der Anwendungsumgebung 111 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung class LaufzeitDatenbankFabrik public Datenbank getDatenbank 1 return SeminarisDatenbank getEinzigelnstanz Konkrete Bereitstellung der Datenbank in der Testumgebung class TestumgebungDatenbankFabrik public Datenbank getDatenbank 1 return new TestDatenbank Mit diesem Entwurfsmuster wird allerdings nur die Unabh ngigkeit von der Objekterzeugung erreicht Die Frage des Zugriffs auf die globale Basiskomponente bleibt unbeantwortet In unserem Beispiel findet erneut das Konzept der Parameter bergabe Anwendung Insoweit ergibt sich kein Fortschritt bei der Frage des Zugriffs Der direkte Zugriff auf eine der Fabriken verbietet sich da damit erneut eine statische Abh ngigkeit erreicht w rde Alter
147. es gew hlten Entwurfsmusters f hrt zu einer Verdopplung des Testaufwands durch die notwendige Implementierung redundanter Testf lle f r die berwiegende Zahl der Dom nenklassenmethoden e Fin weiteres Testproblem resultierte in der Schnittstellenschicht aus der Realisierung der Beziehungen zwischen Anwendungsf llen include und extend Der Aufruf eines anderen Anwendungsfalles wurde ber die Erzeugung einer Instanz der ben tigten Schnittstellenklasse verwirklicht Dadurch entstanden fest verdrahtete Abh ngigkeiten zwischen den Schnittstellenklassen der beteiligten Anwendungsf lle War in der Anforderungsspezifikation ein wechselseitiger Aufruf vorgesehen resultierte daraus die zyklische Abh ngigkeit der Anwendungsfallklassen Dies f hrte dazu dass der unabh ngige Test der Anwendungsf lle nicht mehr durchgef hrt werden konnte Die Hauptursache f r das Entstehen der angeh uften Testprobleme lag in der Vorgehensweise bei der Entwicklung von SeminarlS Ein isolierter Test von kleineren Teileinheiten des Systems war im Entwicklungsprozess nicht vorgesehen Dies f hrte in der Konsequenz dazu dass weder bei Architekturentscheidungen in der Entwurfsphase noch w hrend der Implementierungsphase Testbarkeitsaspekte Ber cksichtigung fanden Einige der erkannten Entwurfsprobleme konnten mit minimalem Aufwand beseitigt werden Selbst bei den Problemen die eine umfassende Ver nderung in der Implementierung erforderlich machten war der Aufw
148. esign To Test Time Startup Class Path TGH modules com togethersoft modules design2test Main Class com togethersoft modules design2test Design2Test Durch Angabe der Class Path Eigenschaft ist es prinzipiell m glich von der von Together verwendeten Paketstruktur com togethersoft modules abzuweichen Allerdings f hrt dies dazu dass einige der Schnittstellenmethoden des Together Open API nicht mehr der Spezifikation entsprechen So scheitert beispielsweise die Ermittlung des home Verzeichnisses des Moduls durch die Methoden getModuleHomeDirectory java lang Class des Interfaces IdeManager sowie der Klasse ResourceUtil und m sste ersatzweise relativ aufw ndig realisiert werden Die Realisierung von Design2Test erfolgt deshalb ebenfalls auf Basis der Paketstruktur der Together Module Jedoch erm glicht der Class Path Mechanismus zumindest die Positionierung des mproveT Pakets ohne Anpassungen im Modulverzeichnis 7 3 Komponente Abh ngiskeitssuche package search Um den Entwurf siehe Abschnitt 6 3 wie beschrieben umzusetzen ist in der Implementierung vor allem auf folgende Aspekte zu achten Der komplette Sourcecode muss durchlaufen werden e Jede relevante Abh ngigkeit muss erkannt werden e Werden einzelne Codeabschnitte von verschiedenen Visitoren durchlaufen darf keine Abh ngigkeit redundant erfasst werden 38 Kapitel 7 Implementierung e Nicht relevante Abh ngigkeiten z B Attribute vom eigenen Klassen
149. esprochenen Reflection Mechanismus ausgeblendet werden so erh lt man f r SeminarlS folgende Projektmetriken Project Metrics EN 2 ACDh 60 35496 NFD 88 0 410 225 0 1 0 Project Met Zerovalue ACD 8911439 60 35496 51 0 39 0 106 0 5 0 Abbildung 102 Vergleich der Projektmetriken links ohne Reflection rechts Originalprojekt Man erkennt deutlich die unheilvollen Auswirkungen der durch die oben beschriebenen Abh ngigkeiten ausgel sten Invertierung der Drei Schicht Architektur e Ohne Verwendung von Reflection w ren 225 Komponenten des Systems in einem einzigen gewaltigen Zyklus voneinander abh ngig Jede Komponente des Systems w re im Durchschnitt von ca 219 anderen Komponenten direkt oder indirekt syntaktisch abh ngig Interessant ist dass die Abh ngigkeitsmetriken nach dem Entfernen der Reflection Mechanismen noch deutlicher auf dieses Entwurfsproblem hinweisen 91 Kapitel 10 Entwurfsprobleme und Testbarkeit Funktionalit t Abh ngige Klasse bereitstellende 2 Typ der Klasse gt Abh ngigkeit 2 7 Dozenten ereinbarung DVKostenBerechnenK 1 0 1508 9 9 11 9 create and access SeminarisH SachbearbeiterA 1 1 0 493 24 33 static access SachbearbeiterA AnfrageStellenAA 1 D 1 10 6 0 1 to class SeminarisK SeminarisDatenbank 1 0 1 5 7 12 6 20 5 static access SachbearbeiterA BelegungAusw aehlenAA 1 0 1
150. essageDialog vold showlonfirmDialog String showlonfirmDialog String showElementsSeilectorDialog showElementsSelectorDialog openPage ldeMessagePage openPage ldeMessagePage closerage void findPage idelessagePage requestFocus vold defaultPage ldeMessagePage showElementsSelectorDialog showElementsSelectorDialog createButtonPanel JPanel createButtonPanel JPanel activePage ldeMessagePage paneYisible boolean UlComponent Component createButtonPanel JPanel createButtonGroup ideDialog amp customize boolean createriiechooserlderliechog createPathChooseridePathCt createPathChooseridePathc selupStandardButtonAbstractd applicationlconlmage java awt l Abbildung 11 Wichtigste Ausgabekomponenten im Together Open API Die Ausgabe der Metriktabellen erfolgt als Seite innerhalb des Message Managers von Together die Anzeige des Abh ngigkeitsgraphen kann als eigenst ndiges Fenster im Window Manager erfolgen createDialog 23 Kapitel 6 Entwurf 6 Entwurf 6 1 Einleitung In der Analyse wurden die Grundlagen f r den anstehenden Entwurf zur Erf llung der Teilaufgaben gelegt Aufbauend auf den dort gewonnenen Erkenntnissen werden in den folgenden Abschnitten nach und nach die einzelnen Teilkomponenten entworfen Als Modellierungsplattform findet naheliegenderweise das Together ControlCenter Verwendung Zur Notation der Entw rfe dient wiederum die UML OUMLO0 Zum besseren Ve
151. etHoechste nummer zur Ermittlung der zuletzt vergebenen Bezeichner in der Klasse SseminarisDatenbank verletzt das Prinzip der Koh sion Unter dem Gesichtspunkt des starken logischen Zusammenhangs der Funktionalit t von Klassen sollten die Methoden an der Stelle angesiedelt sein von der aus die Verwaltung und der Zugriff auf die jeweilige Dom ne erfolgt Dies gilt v llig analog auch f r die Methoden getNext nummer in der Hauptkontrollklasse Seminarisk 10 5 2 Auswirkungen auf die Testbarkeit Der Zugriff aus der Datenhaltung in die Kontrollschicht siehe Abschnitt 10 3 1 in Verbindung mit dem hier beschriebenen Zugriff der Datenbank in die Datenhaltung f hrt zu der in Abschnitt 9 2 2 veranschaulichten Verst rkung der zyklischen Vernetzung in der Datenhaltungsschicht Insoweit treten auch hier die in Abschnitt 10 3 2 erl uterten Testprobleme auf Im Detail ergeben sich dar ber hinaus folgende Probleme Wird in einem Testfall auf die Klasse SeminariskK zugegriffen erfolgt die Initialisierung der dort angesiedelten statischen Variablen f r die eindeutigen DBezeichner Dies f hrt ber den Aufruf der Initialisierungsmethoden getHoechste nummer Singleton Klasse SeminarisDatenbank bereits zu Abfragen auf die Datenbank Sind die zu den Bezeichnern geh renden Dom nenklassen zu diesem Zeitpunkt der Datenbank noch nicht bekannt werden vor jeder Abfrage vom Persistenz Rahmenwerk zudem noch die Proxy Klassen f r diese Dom nenkl
152. f r ist dass in der abgefragten Tabelle der Datenbank FirmenAnsprechpartnerPaar als Referenz auf eine Firma die Objekt ID eines vom Persistenz Rahmenwerk verwalteten Proxyobjektes gespeichert ist Wird wie oben eine Instanz der Dom nenklasse bergeben so wird an dieser Stelle vom Rahmenwerk versucht die bergebene Firmeninstanz in ein Proxyobjekt zu casten um die Objekt ID auszulesen Dieser Cast f hrt zum Werfen der Ausnahme Um den Fehler zu beheben wurde die Superklasse aller Dom nenklassen die Klasse ErweitertPersistent um eine Methode getThis erweitert die zu einer Dom neninstanz das zugeh rige Proxyobjekt erneut ermittelt Dies geschieht wie folgt e Bestimmung des Stringschl ssel der Instanz dieser Stringschl ssel wird zur Anzeige in allen Auswahlmasken verwendet und ist f r alle Dom nen eindeutig e Lesen aller Datens tze vom Dom nentyp aus der Datenbank e Vergleich aller Datens tze mit dem Stringschl ssel der Instanz da dieser Stringschl ssel im Unterschied zu den eindeutigen Bezeichnern nicht in der Datenbank gespeichert ist kann keine konkrete Abfrage auf diesen Schl ssel formuliert werden Zur Vermeidung der oben beschriebenen Ausnahme m ssen also obwohl die Ergebnisinstanz bereits im Zugriff war nochmals s mtliche Datens tze einer Dom nentabelle aus der Datenbank gelesen werden Dieser redundante lesende Zugriff auf die Datenbank wirkt sich sehr negativ auf die Performanz des Systems aus tei
153. f die Abh ngigkeitsmetriken zeigt die erwarteten Ver nderungen E Funktionalit t gt 2 Typ der Abh ngige Klasse bereitstellende Klasse 3 g F Abh ngigkeit sel lt 313 SeminarisK SeminarisDatenbank 0 0 159 11 6 1 5 static access SVAendernErfassenAA Seminarty pAusw aehlenAA 0 0 41 1 2 create and access DruckDokumentDK SeminarisK 0 0 1 2 2 2 7 4 4 static access Seminarty pAendernErfassenAA Dozentenv ereinbarungAusw aehlenAA 0 0 121 3 0 1 create and access SVAendernErfassenAA LeitungsauftragAusw aehlenAA 1 0 1 2 0 3 4 1 create and access LeitungsauftragAendernErfassenAA SVAusw aehlenAA 1 1 119 2 9 1 2 create and access SeminarbelegungAA SVAusw aehlenAA 0 0 11 48 28 2 create and access Erw eitertPersistent SeminarisDatenbank 1 0 11 3 3 7 1 1 static access TeilnahmeFirmenSVRelation TeilnahmeFirmenSVPaar 1 0 011 14 4 4 create and access SVSeminarty pRelation SVSeminarty pPaar 1 0 o 14 5 5 create and access SVAnsprechpartnerRelation SVAnsprechpartnerPaar 1 0 011 1 4 4 4 create and access AnstellungRelation AnstellungPaar 1 0 011 1 4 5 5 create and access BelegungRelation BelegungTripel 1 0 o 11 1 4 6 6 create and access BuchtRelation BuchtPaar 1 0 o 11 1 4 5 5 create and access Abbildung 111 Abh ngigkeitsmetriken nach Entfernung aller Schichtenverletzungen 11 3 Kein externer Zugriff auf Kontrollschicht 11 3 1 Ausgangssituation Durch Zugriff auf globale Variablen der Hauptkontrollklasse Sem
154. figurationsdateien erfolgt durch Eintrag einer Zeile mit dem Namen der die Metrik realisierenden Klasse Die Implementierung bei der bergabe der Metriken an die Analysemodule von mproveT erfolgt analog 7 7 Ausgabekomponenten package results Durch die Realisierung der Koordination und Synchronisation der einzelnen Teilkomponenten von Design2Test nach dem Entwurfsmuster Mediator wurde der Implementierung dieser Funktionalit t ein betr chtlicher Teil der Komplexit t genommen Die Implementierung der einzelnen 43 Kapitel 7 Implementierung Benutzeroberfl chen erfordert zwar den blichen Aufwand ist aber ebenfalls ohne gr ere Schwierigkeiten zu leisten Bei der Integration der Anzeigekomponenten in das Together ControlCenter ist allerdings darauf zu achten dass die Nebenl ufigkeit der in der Ausgabeschicht von Together auszuf hrenden Prozesse gewahrt wird Hierf r stellt Together in seiner IDE Schicht siehe Abschnitt 5 4 1 ber das Interface IdeManager folgende Methoden zur Verf gung public void addCommandAndWait Runnable command public void addCommandToQueue Runnable command public void addCommandToQueue Runnable command String name Eine einfache Implementierung einer Dialoganzeige sieht beispielsweise wie folgt aus JMenultem graphItem new JMenultem Graph graphItem addActionListener new ActionLlistener 1 public void actionPerformed ActionEvent IdeAccess getIdeMa
155. fwands e Der Testaufwand ist noch dazu verh ltnism ig hoch M ssen als Parameter persistente Objekte bergeben werden so sind diese im Setup der Testf lle zu erzeugen Dazu ist der Zugriff auf das Persistenz Rahmenwerk und die Datenbank erforderlich da die Implementierung eines Stellvertreters auf Basis der deklarierten Interfaces nicht ausreichend ist siehe oben W rde man die Design Entscheidung r ckg ngig machen also den direkten Zugriff auf die Ordner und Transformationenklassen erlauben und die Dom nenklassen von jeglicher Logik befreien so k nnte der Testaufwand also in betr chtlichem Umfang reduziert werden 10 8 Erzeugung der Schnittstellenklassen 10 8 1 Entwurfsproblem Unter den Abh ngigkeiten mit den h chsten rACD Werten befinden sich insgesamt f nf Abh ngigkeiten die durch das Erzeugen und den Aufruf einer Auswahlschnittstellenklasse aus einer Schnittstellenklasse eines anderen Anwendungsfalls entstehen siehe Abh ngigkeiten 9 2 3 9 2 5 9 2 6 9 2 7 und 9 2 9 In allen F llen liegt als funktionale Anforderung zugrunde bei der Erfassung oder nderung einer Entit tsinstanz in einem Anwendungsfall ein mit dieser Instanz verbundenes Objekt bearbeiten oder ausw hlen zu k nnen Ausgangspunkt f r den Aufruf aller Anwendungsf lle ist das Seminar S Hauptanwendungsfenster das durch die Klasse SachbearbeiterA implementiert wurde Der Einstieg erfolgt bei allen Anwendungsf llen ber das Seminar S Hauptmen
156. g getGraphType short getvisibilityshort 5UMMARYCLASS int getinstance DependencyGraph DependencyGraph resetvoid isOuterClass boolean getGraph ExtendedGraph isConstructor boolean dependencyFound void MM Exception classFound void ElementDeletedException operationFound void createGraphEntvvod createGraphEntry void createGraphEntry void doPostAnalysis void description String ElementDeletedException getDescription String ingletbn factory Abbildung 25 Hilfsklassen f r die Graphmodellierung Im Zusammenhang mit anonymen Klassen traten die in Abschnitt 7 8 beschriebenen Probleme auf Die in diesem Paket realisierte Klasse ElementDeletedException dient zur Behandlung der sich aus dem Verlust von Elementen anonymer Klassen ergebenden Probleme Ein Schwachpunkt des Entwurfs siehe Abschnitt 6 4 ist die redundante Speicherung der an der Abh ngigkeit beteiligten Together Elemente im Abh ngigkeitsgraphen Neben den Eintr gen als Knoten des Graphen werden diese Elemente als Attribute der Instanzen der Klasse Dependency auch als Inhalt der Kanten gespeichert Es wird zwar derzeit auch ber die Attribute der Dependency Instanzen auf die Together Elemente zugegriffen aber die Implementierung k nnte zwar mit etwas Aufwand aber ohne gr ere Probleme dahingehend performanter gestaltet werden dass der Zugriff ausschlie lich ber die Knoteneintr ge des Graphen erfolgt F r
157. g is_intpk Wir werden sp ter sehen dass die beiden Pakete in unterschiedlichen Anwendungsschichten angesiedelt sind und die Abh ngigkeit durch ihre Richtung die Hierarchie verletzt Abschnitt 10 3 Verletzung der Drei Schicht Architektur Der mit Abstand h chste rACD Wert des gesamten Projekts stimmt in etwa mit dem rACDh Wert berein Das Entfernen der Abh ngigkeit w rde die Anzahl der Zyklen von 5 auf 6 erh hen rNDC Dies geschieht infolge der Zersplittung eines gr eren Zyklus in zwei kleinere Da gleichzeitig die Anzahl der Zyklenkomponenten von 106 auf 103 sinken w rde rNCDC wird insbesondere auch die durchschnittliche Zyklengr e von ca 21 auf ca 17 Komponenten verringert Die Abh ngigkeit wird an einer Stelle durch Erzeugung eines Objekts ausgel st auf das dann mehrfach zugegriffen wird d_type sub_hw und subedges Erl uterungen zu den Komponentenmetriken Die Klasse Dozentenvereinbarung h ngt von insgesamt 14 anderen Komponenten ab cd Ihr rACD_out Wert liegt unwesentlich h her als der rACD Wert der Abh ngigkeit Die brigen ausgehenden Abh ngigkeiten haben demzufolge keinen gr eren Einfluss auf den ACD Wert des Systems Die Anzahl der direkten und indirekten Abh ngigkeiten beider Klassen resultiert unter anderem aus der Beteiligung an einem Zyklus Die Anzahl statischer Abh ngigkeiten liegt in beiden Klassen im Mittelfeld der h chste Wert f r die Metrik cd_h betr gt 15 Die Klasse
158. g 86 Komponentenmetriken DozentenvereinbarungRelation A und DozentenvereinbarungAnfragen B Auff lligkeiten bei den berechneten Werten Die Anzahl der Statements die Ausl ser f r die vorliegende Abh ngigkeit sind ist relativ hoch subedges 9 2 25 2 Bewertung Abweichend von der Standardvorgabe bei der Realisierung von Relationenklassen wurde bei der Transformation der Assoziation Dozentenvereinbarung eine zus tzliche Klasse DozentenvereinbarungAnfragen eingef hrt In diese Klasse wurden alle Abfragen auf die Datenbank ausgelagert Bei allen anderen Assoziationen sind diese Datenbankabfragen innerhalb der Relationenklasse realisiert Der Zugriff auf die Klasse DozentenvereinbarungAnfragen erfolgt exklusiv durch die Klasse DozentenvereinbarungRelation Zur Ansteuerung der Datenbank greift die Klasse DozentenvereinbarungAnfragen aus der Datenhaltungsschicht auf die h her liegende Kontrollschicht zu Dies f hrt zur Verletzung der Hierarchie in der Drei Schicht Architektur siehe Abschnitt 10 3 Verletzung der Drei Schicht Architektur Verursacht wird dies im Bem hen auf eine Basiskomponente zuzugreifen siehe Abschnitt 10 6 Zugriff auf globale Basiskomponenten Insgesamt f hrt dies wie bei Abh ngigkeit 9 2 14 TeilnahmeFirmenSVRelation TeilnahmeFirmenSVPaar zur Hub Eigenschaft dieser Abh ngigkeit innerhalb der zyklischen Datenhaltungsschicht wodurch die erh hte rACD Metrik der Abh ngigkeit zustande kommt und die Anzeige a
159. g durch den fest verdrahteten Zugriff auf acht Datenhaltungsklassen aus der Klasse SeminarisDatenbank PaketExterneSystemeP PersistenzP verletzt 94 Kapitel 10 Entwurfsprobleme und Testbarkeit AnfragenP OrdnerP SeminarisP TransformationenP ErweitetPersistent ErweitertPersistent Abbildung 105 Zugriff auf Datenhaltung aus externem Persistenzmodul Ausschnitt aus SeminarlS Der Entwurfsfehler entstand als Folge der Vorgabe der Anforderungsspezifikation dass f r bestimmte Entit ten ein eindeutiger f r den Anwender sichtbarer und im Gesch ftsverkehr auch Verwendung findender Bezeichner vom System generiert werden sollte F r die Erzeugung und Verwaltung dieser eindeutigen Bezeichner wurde die folgenschwere Entscheidung getroffen diesen Mechanismus in der Hauptkontrollklasse und der Datenbankklasse anzusiedeln Seminarisk bietet statische synchronisierte Methoden an mit denen jeweils der n chste zu vergebende Bezeichner abgerufen werden kann zB getNextKundennummer e Die Initialisierung der Bezeichner erfolgt beim Start der Anwendung indem der h chste bisher in der Datenbank vergebene Bezeichner ermittelt wird e F r diese Initialisierung bietet SeminarisDatenbank Methoden an die durch Datenbankabfragen diese Werte liefern z B getHoechsteKundennumner e Diese Methoden werden beim Laden der Klasse SeminarisK zur Initialisierung der Bezeichner aufgerufen Die Implementierung der Methoden g
160. gef hrt so wird dieser statische Konstruktor als Element T_INIT im Graph gespeichert class FirmaLoeschenrK static IFirma firma static statischer Initialisierungs Block firma IFirma Firma erzeuge Ein statischer Initialisierer besitzt keine Parameter und wird nur einmal unmittelbar nach dem Laden der Klasse aufgerufen Eine Klasse kann mehrere statische Initialisierer besitzen B 28 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Abh ngigkeit en auf Memberebene F hrt die Abh ngigkeit zu einer Methode oder einem Attribut so erscheint auch auf Memberebene ein entsprechender Eintrag Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP FirmaLoeschenK T_CLASS Firma T_CLASS Class D_CALL_ST FirmaloeschenK T_CLASS Firma T_CLASS Member D_CALL_ST static_init_1 T_INIT erzeuge T_METHOD Initialisierer sind in Together namenlos Initialisierer derselben Klasse sind also durch ihren Namen nicht unterscheidbar Die Benennung eines statischen lInitialisierers erfolgt durch Generierung eines Namens der Art static_init_ wobei das Prozentzeichen f r eine fortlaufende Nummerierung innerhalb einer Klasse steht Abh ngigkeit en auf Klassenebene F hrt die Abh ngigkeit zu einer Klasse so wird die Abh ngigkeit nur auf Klassen und Summary Ebene gespeichert Ebene Abh ngigkeitstyp Knotentyp Nac
161. getType getPositions else it is an attribute of primitive type int boolean 7 gt nothing to do return null Zusammengefasst l sst sich sagen dass jede potentielle Abh ngigkeit vor der Benachrichtigung des angemeldeten DependencySearchListeners auf ihre jeweilige Relevanz gepr ft wird Die Basis f r die zu erfolgenden Pr fungen ist dabei ihre Beschreibung in der bersicht der Abh ngiskeiten Anhang B S mtliche Varianten bei der Ermittlung der Abh ngigkeiten an dieser Stelle zu beschreiben w rde den Rahmen dieses Dokuments sprengen Die nachfolgenden Beispiele beschr nken sich deshalb darauf noch einige interessante Implementierungsteile zu erl utern Zun chst ein Blick in die Implementierung der KlassemyElementVisitor 39 Kapitel 7 Implementierung public Object visitClass SciClass sciClass is this class excluded from search if searchScope null amp amp searchScope isInScope sciClass return null notify the listener that a class was found so we can insert all classes as nodes in the graph independently from a dependency notifyListenerClassFound sciClass getting all inheritances SciIlnheritance nextInheritance null SciElement referencedElement null SciInheritanceEnumeration inheritances sciClass inheritances while inheritances hasMoreElements nextInheritance inheritances nextScilInheritance referencedElement
162. gether Erweiterung zur Testbarkeitsanalyse Metriken ausw hlen lt lt include gt Testbarkeitsmetriken erstmalig berechnen 7 asextend gt gt Together Benutzer Suchoptionen einstellen ar 2 gt gt Testbarkeitsmetriken Metriken lt lt extend gt gt berechnen drucken lt lt gt gt Navigation zum Sourcecode CH d S ssextend gt Metriken speichern rotend gt gt Navigation zu Klassendiagramm Abh ngigkeitsgraph anzeigen 2 Drucker N lt lt extend gt gt 7 Sn lt lt extend gt gt 7 Graph Graph drucken speichern Abbildung 1 Anwendungsfalldiagramm Testbarkeitsanalyse Die textuelle Beschreibung der Anwendungsf lle erfolgt in den folgenden Abschnitten 133 Anhang Textuelle Anwendungsfallspezifikationen A 2 Textuelle Anwendungsfallspezifikationen A 2 1 Anwendungsfall Testbarkeitsmetriken berechnen use case Testbarkeitsmetriken berechnen actors Together Benutzer precondition Das Together ControlCenter ist gestartet Die Together Erweiterung f r die Testbarkeitsanalyse von Abh ngigkeiten wurde beim Start geladen Zum Starten des Moduls wurde ein Men punkt in das Hauptmen integriert Ein Together Projekt ist ge ffnet main flow Der Benutzer startet die Testbarkeitsanalyse ber das Hauptmen der Together Anwendung oder ber das Kontextmen
163. gigkeiten durchlaufen und als Ziel von Abh ngigkeiten ber cksichtigt werden sollen extension point Suchoptionen einstellen exceptional flow Abbruch der Metrikberechnung Der Benutzer kann die Testbakeitsanalyse w hrend der Berechnung der Testbarkeitsmetriken jederzeit abbrechen alternate flow Anzeige der Komponentenmetriken Der Benutzer wechselt ausgehend von einer an einer Abh ngigkeit beteiligten Klasse aus der Anzeige der Abh ngigkeitsmetriken zur Anzeige der Komponentenmetriken dieser Klasse alternate flow Anzeige der Abh ngigkeitsmetriken Ausgehend von einer ber eine Abh ngigkeit verbundene Komponente kann der Benutzer aus der Anzeige der Komponentenmetriken zur Anzeige der zugrunde liegenden Abh ngigkeitsmetriken wechseln alternate flow Navigation zum Source Code Der Benutzer kann direkt an die Stellen im Programmtext springen die Ausl ser einer Abh ngigkeit sind Ferner k nnen alle in den Metriktabellen angezeigten Klassen im Texteditor von Together ge ffnet werden extension point Navigation zum Sourcecode 134 Anhang Textuelle Anwendungsfallspezifikationen alternate flow Navigation zu Klassendiagramm Der Benutzer l sst sich zu einer beliebigen Klasse das zugeh rige Klassendiagramm anzeigen extension point Navigation zu Klassendiagramm alternate flow Testbarkeitsmetriken erneut berechnen Der Benutzer startet eine erneute Berechnung der Metriken alternate flow Anzeige von Hilfetext
164. gik Diese bisherigen sehr einfach zu realisierenden Refaktorisierungsschritte bewirken also bereits eine Reduzierung des ACD Wertes um nahezu ein Viertel Entfernt man abschlie end noch zur Kontrolle die Ausgangsabh ngiskeit von SeminarisK nach SeminarisDatenbank so stellt man fest dass die Projektmetriken nahezu unver ndert bleiben 59 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Zusammengefasst l sst sich festhalten dass der hohe rACD Wert der hier diskutierten Abh ngigkeit auf die Abh ngigkeiten von SeminarisDatenbank in die Datenhaltung sowie aus der Datenhaltungsschicht in die Kontrollschicht zur ckgef hrt werden kann Die hier diskutierte Abh ngigkeit war ein hervorragender Indikator f r zwei grundlegende Entwurfsprobleme Bei den erkannten testkritischen Abh ngigkeiten handelt es sich um direkt benachbarte adjazente Abh ngigkeiten der hier diskutierten Abh ngigkeit im Abh ngigkeitsgraphen Auch wenn im Hinblick auf den ACD Wert des Projekts eine Entfernung der Abh ngigkeit SeminarisK nach SeminarisDatenbank keine nennenswerte Verbesserung mehr bringt sollte auch sie entfernt werden Wie in Abschnitt 10 6 Zugriff auf globale Basiskomponenten beschrieben handelt es sich auch hier um ein gravierendes Testproblem da sonst insbesondere keine Konfigurierbarkeit der Datenbank in der Testumgebung m glich ist Hier erfolgt die Anzeige des Entwurfsproblems unmittelbar durch die Abh ngigkeit 9 2 3
165. gilt auch f r alle nachstehend beschriebenen Abh ngigkeiten sofern eine Komponente dieses Typs daran beteiligt sein kann B 2 Erweiterung eines Schnittstellentyps B 2 1 Die Erweiterung eines Schnittstellentyps Interface erfolgt wie bei der Vererbung durch das Schl sselwort extends Erl uterung und Beispiel 143 Anhang Implementierung eines Schnittstellentyps public interface IBelegung extends IErweitertPersistent B 2 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP IBelegung T_INTERF IErweiterPersistent T_INTERF Class D_EXTEND IBelegung T_INTERF IErweiterPersistent T_INTERF Member Implementierung eines Schnittstellentyps B 3 1 Erl uterung und Beispiel M chte eine Klasse ein Interface als Typ implementieren so folgt hinter dem Klassennamen das Schl sselwort implements gefolgt vom Schnittstellentyp Die implementierende Klasse kann auch als abstrakt definiert sein public abstract class Firma implements IFirma Steht im Rahmen der Definition einer anonymen Klasse hinter dem Schl sselwort new der Name eines Schnittstellentyps so implementiert die anonyme Klasse dieses Interface Es wird ebenfalls eine entsprechende Abh ngigkeit modelliert public class Firma extends Geschaeftspartner ActionListener a new ActionListener
166. gkeiten zur Datenhaltung Durch die Verlagerung der oben beschriebenen Methoden zur Verwaltung von eindeutigen Dom nenbezeichnern w rde also eine Verringerung des ACD Wertes um 15 8 Prozent erreicht Dies l sst die Schlussfolgerung zu dass der hohe rACD Wert der untersuchten Abh ngigkeit im Wesentlichen durch die Abh ngigkeiten von SeminarisDatenbank in die Datenhaltungsschicht ausgel st wird Dies wird dadurch best tigt dass die Entfernung der Abh ngigkeit von SeminarisK nach SeminarisDatenbank zum jetzigen Zeitpunkt nur noch eine marginale Ver nderung der Metrikwerte ACD 74 9 ergibt Einfluss auf die Metrikwerte k nnten m glicherweise auch noch jene Abh ngigkeiten aus der Datenhaltungsschicht in die Kontrollschicht haben siehe Abschnitt 10 3 Verletzung der Drei Schicht Architektur die zur Erweiterung des Datenhaltungszyklus beitragen siehe Abbildung 34 Mit der nachstehenden Entfernung der genannten Abh ngigkeiten sind s mtliche Abh ngigkeiten aus der Datenhaltung in die Anwendungslogik entfernt Bemerkenswert ist dass die Entfernung ohne Hinzuf gen zus tzlicher Abh ngigkeiten geschehen kann siehe Abschnitt 11 2 Realisierung einer strikten Drei Schichten Architektur 58 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten ee dpnt p dpne E TACIE vi PDozentenvereinbarung DVKostenBerechnenK vi Mil 18 086 G
167. gkeits und Komponentenmetriken ist direkt mit dem analysierten Sourcecode verkn pft e Doppelklicken Sie in den Metriktabellen oder der Komponentenanzeige auf eine Komponente um diese im Texteditor Fenster von Together zu ffnen Oder w hlen Sie im Kontextmen der jeweiligen Komponentenspalte den Men punkt Edit um sich den Sourcecode der Komponente im Texteditor anzeigen zu lassen e Doppelklicken Sie auf eine der ausl senden Abh ngigkeiten im rechten Teil des Panels Dependency Metrics um im Texteditor an die Stelle des Sourcecodes der abh ngigen Klasse zu springen die Ursache der Abh ngigkeit ist Oder w hlen Sie im Kontextmen der ausl senden Abh ngigkeiten den Men punkt Go to Source 4 3 2 Sortieren der Ergebnisse Sie k nnen die Metriktabellen nach den Werten jeder einzelnen Spalte sortieren Klicken Sie hierzu mit der linken aufsteigende Sortierreihenfolge oder rechten absteigende Sortierreihenfolge Maustaste auf eine der Spalten berschriften Oder w hlen Sie alternativ im Kontextmen der Metriktabellen das Untermen Sort und einen der beiden Eintr ge Ascending aufsteigend oder Descending absteigend 4 3 3 Verkn pfungen von Abh ngigkeits und Komponentenmetriken Wollen Sie sich aus dem Panel Dependency Metrics die Komponentenmetriken zu einer Komponente anzeigen lassen so klicken Sie mit der rechten Maustaste auf die Komponente und w hlen im erscheinenden Kontextmen den Men punkt Component Metrics Dara
168. h ngigkeiten Abbildung 92 Komponentenmetriken DozentenvereinbarungLoeschenK A und IDozentenvereinbarungK Auff lligkeiten bei den berechneten Werten Die Abh ngigkeit beruht nur auf einem einzigen allerdings statischen Zugriff sub_hw subedges d_type Die Klasse zu der die Abh ngigkeit f hrt besitzt keine weiteren Abh ngigkeiten cd 9 2 28 2 Bewertung Der Entwurf und die Implementierung der Schnittstellen und Kontrollklassen die sich aus den Anwendungsf llen zum Bearbeiten Erfassen und L schen von Dozentenvereinbarung ergaben erfolgte abweichend von den in der Entwurfsphase aufgestellten Design Richtlinien der Entwicklergruppe So existiert beispielsweise in der Kontrollschicht ein Interface IDozentenvereinbarungkK das von den Kontrollklassen zum Erfassen und ndern einer Dozentenvereinbarung implementiert wird Ferner wird in diesem Interface eine Konstante zur Bestimmung der Protokollpuffergr e f r Fehlermeldungen und Eintr ge in das Anwendungsprotokoll definiert Durch den Zugriff der Klasse DozentenvereinbarungLoeschenK auf diese Konstante entsteht die vorliegende Abh ngigkeit Die von den Richtlinien der Gruppe abweichende Umsetzung der Anwendungsf lle zur Dozentenvereinbarung wie auch der zugeh rigen Teile der Datenhaltung widerspricht allen Prinzipien des objektorientierten Entwurfs Aus diesem Grund ist es sehr schwierig alle in diesem Zusammenhang auftretenden Abh ngigkeiten auf ihre Notw
169. h ngigkeiten verbundenen Komponenten e graph Graphische Darstellung des Abh ngigkeitsgraphen in verschiedenen Schemata zur Veranschaulichung der ermittelten Ergebnisse Das Paket common stellt dar ber hinaus Hilfsklassen zur Navigation in die Together Anzeigekomponenten und zur Anzeige von Hilfetexten zu den Metriken zur Verf gung 31 Kapitel 6 Entwurf Bez glich der Oberfl chengestaltung erfolgt wiederum die Orientierung am look and feel von Together und seinen Quality Assurance Modulen Audits und Metrics Die Ausgabe deren Ergebnisse erfolgt in der Message Pane von Together so dass auch die Darstellung der ermittelten Testbarkeitsmetriken in der Message Pane erfolgt Die in der Anzeige zur Verf gung stehenden Funktionalit ten werden analog zu der Together Realisierung ber Kontextmen s angeboten F r die graphische Anzeige wird ein separates Dialogfenster entworfen das ebenfalls ber Kontextmen s bedient werden kann Die aufgrund des Entwurfs tats chlich realisierten Benutzeroberfl chen k nnen dem Benutzerhandbuch entnommen werden Anhang A 6 7 3 Teilentwurf Anzeige der Abh ngigkeitsmetriken Das nachstehende Klassendiagramm liefert einen berblick ber die Realisierung der Anzeige der Abh ngigkeitsmetriken MouseAdapter _ Javax swing JTable EdgeMetricsMouseListener analysisTableModel versionAnalysis ImproveT gui VersionAnalysisTable analysisTable VersionAnalysisTable mediator D2TMediator sort
170. h ngigkeitsgraphen Farbschema Normal Die Knoten des Graphen stellen hierbei die Komponenten des analysierten Projektes dar Sie sind mit dem Namen der Komponente versehen Bei den Kanten des Graphen handelt es sich um die zwischen den Komponenten ermittelten Abh ngigkeiten Die Richtung jeder Kante verl uft von der abh ngigen Komponente zum Ziel der Abh ngigkeit Sie k nnen die Komponenten ber Drag und Drop beliebig verschieben Klicken Sie hierzu den betreffenden Knoten an und ziehen Sie ihn bei gedr ckter Maustaste an die gew nschte Stelle Die Anzeige des Graphen ist mit den Metriktabellen synchronisiert W hlen Sie beispielsweise eine Abh ngigkeit im Panel Dependency Metrics aus so wird die entsprechende Kante im Graphen farbig hervorgehoben Markieren Sie umgekehrt eine Kante in der Graphanzeige so erscheint die entsprechende Zeile der Metriktabelle selektiert Analog sind die angezeigten Komponenten mit dem Panel Component Metrics verkn pft 175 Anhang Graphische Anzeige der Abh ngigkeiten 5 2 Funktionen in der Graphanzeige 5 2 1 Aktualisierung der Anzeige Sie haben die M glichkeit die angezeigten Komponenten und Abh ngigkeiten automatisch neu ordnen zu lassen z B nachdem Sie das Anzeigefenster in seiner Gr e ge ndert haben W hlen Sie hierzu aus dem Kontextmen den Men punkt Layout Die vorhandenen Komponenten und Abh ngigkeiten werden neu arrangiert und die Anzeige aktualisiert 5 2
171. h Knotentyp Summary D_DEP FirmaloeschenK CLASS Firma T_CLASS Class D_CAST FirmaloeschenK CLASS IFirma T_CLASS Member S Bei der auf Klassenebene eingef gten Abh ngigkeit wird eine Referenz zum Knoten des die Abh ngigkeit ausl senden statischen lInitialisierers gespeichert 157 Anhang Instanz Initialisierer B 29 Instanz Initialisierer B 29 1 Erl uterung und Beispiel Ein Instanz Initialisierer instance initializer besteht nur aus geschweiften Klammern dem Initialisierungsblock Wird im lnitialisierungsblock eine Abh ngigkeit begr ndet so wird der Instanz Initialisierer als Element T_INIT im Graph gespeichert class FirmaLoeschenrK private IFirma firma Initialisierungs Block firma IFirma Firma erzeuge Konstruktor public FirmaloeschenK Ein Instanz Initialisierer besitzt keine Parameter und wird genau einmal f r jede erzeugte Instanz ausgef hrt In einer Klasse k nnen mehrere Instanz Initialisierer vorkommen B 29 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Abh ngigkeit en auf Memberebene F hrt die Abh ngigkeit zu einer Methode oder einem Attribut so erscheint auch auf Memberebene ein entsprechender Eintrag Ebene Abh ngigkeitstyp Knotentyp Nach Knotentyp Summary D_DEP FirmaLoeschenK T_CLASS Firma T_CLASS Class D_CALL_ST FirmaLoeschenK T_CLASS Firma T_CLASS
172. h die Klasse ShowEdgeMetricsPane Sie bildet den Rahmen f r die von ImproveT gelieferten Ergebnisse VersionAnalysisTable und VersionAnalysis und die Anzeige der Programmteile die Ausl ser von Abh ngigkeiten sind Paket dependencies Die Klasse EdgeMetricsMouseListener ist verantwortlich f r das Bereitstellen des Kontextmen s in der Metrikanzeige die Klasse DependenciesMouseListener realisiert das Kontextmen in der Anzeige der Ausl ser von Abh ngigkeiten Die brigen Klassen des Pakets decken Teile der in den Kontextmen s angebotenen Funktionalit t ab 32 Kapitel 6 Entwurf 6 7 4 Teilentwurf Anzeige der Komponentenmetriken Das nachstehende Klassendiagramm liefert einen berblick ber die Realisierung der Anzeige der Komponentenmetriken ShowNodeMetricsPane MouseAdapter NodeMetricsMouseListener analysisTableModel NodeAnalysis analysisTable NodeAnalysisTable outComponentTable ComponentTable outComponentTableModel OutComponentTableModel inComponentTable ComponentTable inComponentTableModel InComponentTableModel rootPane JSplitPane mediator D2TMediator mouseListener MouseListener javax swing JTable ImproveT gui NodeAnalysisTable mediator D2TMediator sortedColumn int sortedAscending boolean NodeMetricsMouseListener mouseQlicked void mousePressed void mouseReleased void javax swing table AbstractTableMod _ _ _ showPopupMenumvoid ImproveT an
173. h kommt es zu Maskierungseffekten wenn beim Vorhandensein paralleler Abh ngigkeiten die Testkritikalit t dieser Abh ngigkeiten nicht erkannt werden kann Eine Verbesserung verspricht die f r die Zukunft vorgesehene Berechnung der Metriken auf Paketebene Jedoch k nnen je nach Art der Realisierung auch dort Maskierungseffekte auftreten So verlaufen zwar beispielsweise die Abh ngigkeiten aus SeminarisDatenbank in die Datenhaltung zwischen denselben Paketen siehe erneut Abh ngigkeit 9 2 2 SeminarisK SeminarisDatenbank Die Abh ngigkeiten aus der Datenhaltung in die Kontrollschicht verlaufen jedoch ebenfalls parallel zwischen verschiedenen Paketen Dort kann man mit Effekten rechnen die denen auf der Klassenebene gleichen Ein einfacher Ansatz um die oben beschriebenen Maskierungseffekte auf Klassenebene zu umgehen erfolgte durch die Einf hrung zus tzlicher Komponentenmetriken rACD_in und rACD_out Die neue Metrik rACD_out errechnet beispielsweise die Ver nderung des ACD Wertes des Gesamtprojekts nach Entfernung aller von dieser Komponente ausgehenden Abh ngigkeiten die Komponente wird also zur Senke im Abh ngigkeitsgraphen Beispielsweise erh lt man nach Entfernung aller Abh ngigkeiten die als abh ngige Komponente SeminarisDatenbank besitzen folgende Projektmetriken Project Metrics without Excluded EN Zerovalue umber of components Nah 273 0 7413333 89 11439 16 811043 35
174. ich ben tigter Code generiert und kompiliert Proxyklassen Dieser Mechanismus lie e sich nur durch Ver nderung des Originalcodes verhindern g ngige Strategien zur Herstellung isolierter Bedingungen greifen hingegen nicht z B Einsatz von Teststellvertretern Aufgrund dieser Erfahrungen erschien es sinnvoll und hilfreich abweichend von der urspr nglich geplanten Vorgehensweise eine ausf hrliche Untersuchung dieser Entwurfsprobleme an die Bewertung der testkritischen Abh ngigkeiten anzuschlie en und die Testfallerstellung vorerst zur ckzustellen Ziel der Untersuchung in Kapitel 10 war einen berblick zu gewinnen an welchen Stellen und in welchem Umfang diese grundlegenden Entwurfsprobleme die Testbarkeit des Systems ber hren Als Ergebnis dieser Untersuchung musste erkannt werden dass die durch die angezeigten Testprobleme erkannten Entwurfsprobleme so weitreichend sind dass eine Entfernung einzelner Abh ngigkeiten kein erfolgversprechendes Vorgehen bei der Refaktorisierung des Systems darstellt Die Refaktorisierung zielt folglich auf die generelle Beseitigung der beschriebenen Entwurfsprobleme ab Die Beseitigung dieser Probleme einschlie lich der Diskussion alternativer Vorgehensweisen bei der Refaktorisierung wird in Kapitel 11 beschrieben Die in der Aufgabenstellung vorgesehene Bestimmung von Testaufw nden vor und nach der Refaktorisierung konnte aus Zeitgr nden nicht mehr durchgef hrt werden Insbesondere deshalb weil
175. ichen Design der Together Erweiterung gef hrt h tten 34 Kapitel 6 Entwurf Der zum Erfolg f hrende abschlie ende Entwurf sieht die Verwendung des Entwurfsmusters Mediator Gamm94 f r die Koordination der einzelnen Teilmodule der Erweiterung vor Um den vom Mediator koordinierten Instanzen den R ckgriff auf die Mediatorinstanz zu erm glichen kommt das Observer Pattern Gamm94 zur Anwendung Hierzu bergibt sich der Mediator bei der Erzeugung einer zu verwaltenden Programmkomponente selbst als Beobachter Das resultierende Klassendiagramm zeigt nachstehende Abbildung startAnalysisWilhSelechion vold ShowEdgeMetricsPane start Analysis vold EEE showGraphvoid 2 repaintGraph void graphclosed vold edgeCchangecdvold MouseAdapter SshowNodeMetricsPane e edgeMetricsPane ShowEdgeMetricsPane MouseAdapter NodeMetricsMouseListener REESEN nodeMetricsPane ShowNodeMetricsPane graphDialog ShowGraphDialog MyObsermer edgeMetricsMouseListener EdgeMetricsMouseListener ShowGraphDialog IdeProjectAdapter D2TMediatorimpl metricsDialog SelectMetricsDialog analyzeOptions AnalyzeOptions nodeMetricsMouseListener NodeMetricesMouseListener logging Logging D2TMediatorlmpl Fre startAnalysisWithSelection yoid startAnalysis void Analyzeoptons showGraph void
176. id setSelectedEdge Edge e void setSelectedNode Node n void setColorSchema int schema Erw hnenswert ist ferner die M glichkeit Beobachter bei der Instanz registrieren zu k nnen die ber nderungen der Anzeige informiert werden Da die aktuellen Anzeigeinformationen ber die Schnittstelle ausgelesen werden k nnen erm glicht dies bei der beabsichtigten Integration in das Together ControlCenter die verschiedenen Anzeigetableaus konsistent zu halten void addNodeSelectionObserver MyObserver void addEdgeSelectionObserver MyObserver Node getSelectedNode Edge getSelectedEdge 22 Kapitel 5 Analyse 5 8 3 Ausgabem glichkeiten in Together Als Ausgabeschnittstelle steht im Together Open API die IDE Schicht zur Verf gung siehe Abschnitt 5 4 1 Die beiden Klassen IdeWindowManagerAccess und IdeMessageManagerAccess gestatten Zugriff auf die Ausgabekomponenten mit denen die Anzeige der Testbarkeitsmetriken und des Graphen erfolgen kann CI deWindowldanagerAccess LI delfessagelManagerAccess myldeWyindowManagerIdeWind printMessage void printMessage void createMessageManager ldeMg windowManagerIdewWyindowMa filterManager IdeFilterManager messageManager IdeMessage messageManagerFactory ldehd interface IdeWindowifanager interface createDislog JDialog showOptionDialog String showOptionDislog AbstractBu showMessageDialog vold showW
177. iese Schicht auch die Modellierung beeinflusst F r die Zwecke dieser Arbeit ist insbesondere von Bedeutung dass auf dieser Ebene der Sourcecode des kompletten Projekts durchlaufen und nach Abh ngigkeiten zwischen einzelnen Programmkomponenten analysiert werden kann 5 4 2 Integration von Modulen ber das Open API Eine Erweiterung von Together auf der Basis seines Open API ist ber sogenannte Together Module m glich Derartige Module k nnen als Javaklassen realisiert werden die ber die vorstehend beschriebenen verschiedenen Schichten des Together Open API auf die Informationen und Elemente des Together Modells lesend und schreibend zugreifen Ein berblick zur Erweiterung von Together ber Module findet sich ToUG02 5 5 Ermittlung von Abh ngigkeiten T 2 Nach der Aufgabenstellung sollen alle Modellelemente und der Java Sourcecode eines in Together als Projekt verwalteten objektorientierten Softwaresystems nach dem Auftreten von Abh ngigkeiten durchsucht werden Daraus ergaben sich zun chst folgende Fragen e Welche Abh ngigkeiten zwischen welchen Programmkomponenten k nnen in einem objektorientierten Java Programm berhaupt entstehen e welchen Schichten des Together Open API siehe Abschnitt 5 4 1 sind Informationen und Daten vorhanden die bei der Suche nach Abh ngigkeiten in einem Projekt ber cksichtigt werden m ssen welchen Elementen der zu untersuchenden Schichten k nnen Abh ngigkeiten zwischen Pr
178. igkeitsgraphen wieder Comparable interface Abbildung 9 Klassendiagramme der Graphelemente Node und Edge F r jede Abh ngigkeit zwischen zwei Komponenten werden die beiden beteiligten Komponenten als Knoten und die Abh ngigkeit als Kante in die entsprechende Ebene des Abh ngigkeitsgraphen eingef gt F r das Einf gen von Knoten und Kanten bietet eine Instanz eines Abh ngigkeitsgraphen die beiden Methoden Node getNode int levelNumber String qualifiedName short type Edge getEdge int levelNumber String name short type Node tailNode Node headNode an Sofern der einzuf gende Knoten oder die einzuf gende Kante bereits existieren liefern beide Methoden einen Verweis auf die bereits eingef gten Graphelemente Ansonsten werden die Objekte in der Datenstruktur des Graphen neu angelegt und an den Aufrufer der beiden Methoden zur ck geliefert Aus den Signaturen der beiden Methoden ist bereits zu erkennen dass die Elemente des Graphen durch die Ebene auf der sie sich befinden sowie einem eindeutigen Namen und einem Typ identifiziert werden Bei den Abh ngigkeiten kommen ferner als Attribute noch die beiden an der Abh ngigkeit beteiligten Komponenten hinzu Beim Typ handelt es sich um die Art der Abh ngigkeit z B Aufruf einer statischen Methode Erzeugung einer Instanz sowie im Falle von Komponenten um 18 Kapitel 5 Analyse deren Charakterisierung z B Klasse Konstruktor Attribut Die zur Ve
179. iktabelle zu der zur ausgew hlten Komponente geh rende Zeile mit den Metrikwerten Gleichzeitig erfolgt auch die Aktualisierung der ge ffneten Komponentenfenster im rechten Teil der Anzeige Auf diese Weise k nnen Sie in beliebiger Richtung entlang eines Pfads im Abh ngigkeitsgraphen navigieren e Dependency Metrics Aktiviert das Unterpanel Dependency Metrics und zeigt dort die Metrikwerte der zugrunde liegenden Abh ngigkeit an e Edit ffnet die angeklickte Komponente im Texteditor von Together e Select on Diagram ffnet das Klassendiagramm dessen Bestandteil die angeklickte Komponente ist in der Designer Pane von Together Die angeklickte Komponente wird innerhalb des Diagramms selektiert Eine detaillierte Beschreibung der einzelnen Funktionen finden Sie in Abschnitt 4 3 Funktionen in den Metrikanzeigen 188 Anhang Kontextmen s A 3 Graphanzeige Wenn Sie mit rechten Maustaste in die Graphanzeige klicken so erhalten Sie ein vom ausgew hlten Graphelement abh ngiges Kontextmen Edit nur f r Komponenten verf gbar Select on Diagram nur f r Komponenten verf gbar Show Qualified Name nur f r Komponenten verf gbar Layout Set Color Schema Export gt Print Abbildung 24 Kontextmen s in der Graphanzeige Hinter den angebotenen Men punkten verbergen sich im Einzelnen folgende Funktionalit ten e Edit ffnet die angeklickte Komponente im Texteditor von Together e Sele
180. ikwerte des zuletzt analysierten Projektes in der Spalte Value die Gesamtwerte nach Beseitigung der ausgew hlten Abh ngigkeiten und in der Spalte Improvement die daraus resultierende prozentuale Verringerung des Metrikwertes Project Metrics without Excluded Zeroyalue Improwement 9 972603 28 02198 7 178052 NFD 1 0 2 0 50 0 1 0 20 50 0 NDC 1 0 1 0 0 0 6 0 50 0 Abbildung 6 Anzeige der Projektmetriken nach Beseitigung ausgew hlter Abh ngigkeiten 174 Anhang C Graphische Anzeige der Abh ngigkeiten 5 Graphische Anzeige der Abh ngigkeiten 5 1 Darstellung M chten Sie sich den Abh ngigkeitsgraphen visualisieren lassen w hlen Sie im Kontextmen der Metriktabellen gt 4 Anzeige der Metriken den Men punkt Graph Es ffnet sich hierauf ein Fenster mit der Darstellung des Abh ngigkeitsgraphen als geometrischer Graph in der Ebene Dependency Graph E u H r S N K ch d She GAREN d pes orivisitor ShowGr sp set Sho AN icstpglewvExpregs neter ence isitor 1 i Dependenc iva serogn dar Se zato e A cet viak tefer End evisitor Sele ri s N A E Weber EA 2 Abbildung 7 Graphische Darstellung des Ab
181. in kleines Dialogfenster mit der gew nschten Angabe Qualified Name of Component EN H Com togethersoft modules design2test analysis ComputeMetrics RR Abbildung 10 Anzeige des voll qualifizierten Namens einer Komponente 5 2 6 Export des Graphen Sie k nnen den Graph im XML Format oder in einem Grafikformat JPEG zur weiteren Bearbeitung speichern W hlen Sie hierzu im Kontextmen das Untermen Export und einen der beiden Men punkte As Image oder As XML Eine n here Beschreibung des Speichervorgangs finden Sie in Kapitel 6 Erweiterte Funktionen und Einstellungen in den Abschnitten 6 3 1 Speichern des Abh ngigkeitsgraphen im XML Format und 6 3 2 Speichern des Abh ngigkeitsgraphen im Grafikformat 5 2 7 Druck der Graphanzeige Sie k nnen sich den Graph in der aktuellen Anzeige ausdrucken lassen W hlen Sie hierzu den Men punkt Print aus dem Kontextmen Eine n here Beschreibung des Druckdialogs finden Sie in Abschnitt 6 3 3 Druck der Graphanzeige von Kapitel 6 Erweiterte Funktionen und Einstellungen 178 Anhang Erweiterte Funktionen und Einstellungen 6 Erweiterte Funktionen und Einstellungen 6 1 Metrikauswahl 6 1 1 Setzen der Default Metrikauswahl Eine empfohlene Metrikauswahl ist Bestandteil des ausgelieferten Moduls Die zugrunde liegende Datei defaultMetrics tms befindet sich im Unterverzeichnis config des Installationsverzeichnisses des Moduls gt 1 Installation Um die darin gespeich
182. inarisK Protocol und SeminarisK Config aus den Paketen ExterneSystemeP ProtokollP UtilP MeldungP undExterneSystemeP DruckerP entstehen zyklische Abh ngigkeiten zwischen den beteiligten Paketen Durch die Art der Implementierung von SeminariskK entstehen ferner transitiv Abh ngigkeiten zur Datenbank und von dort zur Datenhaltungsschicht 11 3 2 Durchf hrung des Refactoring Alle vorhandenen Abh ngigkeiten k nnen durch den direkten Zugriff auf die in den globalen Variablen gespeicherten Instanzen Singletons ersetzt werden Beispiel bisheriger Zugriff ber Sseminarisk name SeminarisK Config getPropertyMitDefault Printer BigFont Name Courier Direkter Zugriff auf Konfigurationsinstanz 106 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung name Konfiguration getEinzigelnstanz getPropertyMitDefault Printer BigFont Name Courier Dies kann jedoch nur ein Zwischenschritt im Rahmen der Verbesserung des Entwurfs sein Nach einem weiteren Refaktorisierungsschritt siehe Abschnitt 11 4 wird der Zugriff nicht mehr fest verdrahtet auf die Singleton Instanzen erfolgen Damit kann die w nschenswerte Konfigurierbarkeit der Anwendung insbesondere f r Testzwecke erreicht werden Der gesamte Aufwand f r die Refaktorisierung betr gt 10 Minuten 11 3 3 Ergebnisse Man erh lt folgende Ver nderung der Projektmetriken Project Metrics EN Mei
183. insatz von Stellvertreterklassen nicht erfolgen e so dass der Unit ITest der abh ngigen Klasse SVAendernErfassenAA erst durchgef hrt werden kann sobald die Server Klasse SeminartypAuswaehlenAA implementiert ist Tritt ein Fehler auf kann sich die Fehlersuche im allgemeinen nicht mehr auf die zu testende Klasse SVAendernErfassenAA beschr nken e gr er die Anzahl der dadurch am Test beteiligten Klassen ist desto h her sind die Zeiten f r die Durchf hrung und den Ablauf der Testf lle 103 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung 11 1 Einleitung Nachfolgend werden f r einen Gro teil der Entwurfsfehler die in den Kapiteln 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten und 10 Entwurfsprobleme und Testbarkeit als Ursachen f r Testprobleme identifiziert wurden konkrete Strategien zur alternativen Realisierung der jeweiligen Aufgaben beschrieben Auf Grundlage dieser Strategien erfolgt anschlie end eine Refaktorisierung von SeminarlS W hrend und am Ende der jeweiligen Refaktorisierungsphasen wird versucht durch Beobachtung der Testbarkeitsmetriken Aussagen ber die Auswirkungen der Umbauschritte und Hinweise auf weitere Probleme zu erhalten Um abschlie end eine Einsch tzung ber den f r die Refaktorisierung notwendigen Aufwand geben zu k nnen wird versucht den Zeitaufwand f r die jeweilige
184. ird erst bei der bersetzung des Programms durch den Compiler vorgenommen Aufgrund dieser Tatsache ist das Together Open API in diesen F llen nicht in der Lage eine Referenz auf ein im Programmcode vorhandenes Konstruktor Element zu finden Da es sich aus der Sicht der Testbarkeitsanalyse hierbei um eine kritische weil festverdrahtete Abh ngigkeit handelt musste dieses Problem umgangen werden Hierzu wurde sukzessive der Kontext des zu analysierenden Ausdrucks erweitert bis die zugrunde liegende SciNewExpression erreicht wurde Hier war es dann m glich den Typ der neu erzeugten Instanz zu bestimmen und zumindest eine Referenz auf die den repr sentierende Klasse zu erhalten 7 4 Komponente Abh ngigkeitsgraph package data F r die Erzeugung der Eintr ge in den Abh ngigkeitsgraphen sind Informationen notwendig die ber den vom Open f r die Elemente des Sourcecodes bereit gestellten Funktionsumfang hinausgehen Diese zus tzliche Funktionalit t wird innerhalb der Hilfsklasse ElementAnalyzer implementiert 41 Kapitel 7 Implementierung DependencySearchListener DependencyGraph instance DependencyGraph depGraph ExtendedGraph analyzeOptions AnalyzeOptions logging Logging MEMBER int GraphTypes Element nalyzer getTheCllass SciClass getSummaryClass SciClass getQualifiedName String Ee getQualifiedName String RE getQualifiedClassName String getPackage SciPackage getFileName Strin
185. ird nach Vorgabe der Anforderungsspezifikation das L schen von Entit ten vermerkt Das Erzeugen der Klasse LogProtokollDateiA erfolgtin der Hauptkontrollklasse SseminariskK Bei ihrem Erzeugen registriert sich die Klasse LogProtokollDateiA beim Protokollmanager von SeminarlS der f r die Verteilung der Protokolleintr ge an die bei ihm angemeldeten Instanzen verantwortlich ist Bei ihrer Registrierung verwendet die Klasse LogProtokollDateiA f r den Zugriff auf die Klasse ProtokollManager die globale Variable Protocol der Klasse Seminarisk Dies f hrt zu der in Abschnitt 10 4 beschriebenen Abh ngigkeit einer Basiskomponente von der Kontrollschicht die in diesem Fall auch noch einen Zyklus erzeugt Durch die B ndelung globaler Variablen in der Klasse SseminarisK wird dadurch insbesondere auch die indirekte Abh ngigkeit der Protokolldatei von der Datenbank und in der Folge von der Datenhaltungsschicht bewirkt siehe Abh ngigkeit 9 2 2 SeminarisK SeminarisDatenbank Ursache f r die B ndelung der globalen Variablen ist der Versuch globalen Zugriff auf die Basiskomponenten zur Verf gung zu stellen siehe Abschnitt 10 6 9 2 19 SeminarisK DebugProtokollDateiA 9 2 19 1 Ergebnisse der Metrikberechnung 5 5 2 2 1 1 1 1 0 1 2 2 6 9 0 create and access Abbildung 73 Abh ngigkeitsmetriken SeminarisK DebugProtokollDateiA 74 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh
186. iskomponenten Problematisch an der vorliegenden Abh ngigkeit ist insbesondere dass aus einem au erhalb der Drei Schicht Architektur realisierten Basispaket auf die Kontrollschicht der Mehrschicht Architektur zugegriffen wird Hierdurch verliert die Druckkomponente seine Eigenst ndigkeit Eine weitere Diskussion erfolgt in Abschnitt 10 4 Zugriff auf Kontrollschicht 9 2 5 SVAendernErfassenAA LeitungsauftragAuswaehlenAA 9 2 5 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken d_type dep_comp lis_feedb create and access rACD_out o lt 3 gt 5 6 mr 153 3 8 4 5 5 1 2 gt 5 8 184 166 153 1 8 2 5 Abbildung 46 Komponentenmetriken SV AendernErfassenAA A und LeitungsauftragAuswaehlenAA Erl uterungen zu den Abh ngigkeitsmetriken Im Gegensatz zur Abh ngigkeit 9 2 3 ist diese Abh ngigkeit Teil eines Zyklus dep_comp Sie verl uft jedoch ebenfalls ber Paketgrenzen hinweg is_intpk Der rACD Wert liegt deutlich niedriger als der rACDh Wert Das Entfernen der Abh ngigkeit w rde die Anzahl der Zyklen von 5 auf 4 verringern rNDC bei gleichzeitiger Verringerung der Anzahl der Zyklenkomponenten von 106 auf 94 rNCDC 62 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Die Abh ngigkeit wird durch Erzeugung eines Objekts ausgel st auf das dann mehrfach zugegriffen wird d_type sub_hw und su
187. ject Metrics Project Metrics without nur in Spalte exclude Format nur in Metrikspalten Sort Abbildung 22 Kontextmen bei der Anzeige der Abh ngigkeitsmetriken Die einzelnen Men punkte bieten Ihnen folgende M glichkeiten e Component Metrics Bringt das Unterpanel Component Metrics gt 4 2 Komponentenmetriken in den Vordergrund und zeigt die zur angeklickten Klasse geh renden Komponentenmetriken an e Edit ffnet die angeklickte Komponente im Texteditor von Together e Select on Diagram ffnet das Klassendiagramm dessen Bestandteil die angeklickte Komponente ist in der Designer Pane von Together Die angeklickte Komponente wird innerhalb des Diagramm s selektiert Refresh Startet f r Abh ngigkeits und Komponentenmetriken eine neue Metrikberechnung mit den zuletzt ausgew hlten Metriken und den zuletzt eingestellten Optionen e Restart ffnet einen neuen Metrikdialog Die Metrikauswahl f r Abh ngigkeits und Komponentenmetriken kann neu vorgenommen werden die Optionen k nnen neu eingestellt werden e Show Description Zeigt eine kurze Erl uterung der angeklickten Metrik an Export M glichkeiten zum Speichern der Metriktabelle zur weiteren Verarbeitung im Textformat e Print M glichkeit zum Ausdrucken der Ergebnisse der Metriktabelle e Graph Graphische Anzeige des Abh ngigkeitsgraphen unter Ber cksichtigung der errechneten Metriken gt 5 Graphische Anzeige der Abh ngigkeiten
188. k ber den f r diesen Programmteil erstellten Entwurf gibt das Klassendiagramm des Paketes results in dem s mtliche vorgesehenen Ausgabekomponenten zusammengefasst sind ShowEdgeMetricsPane EdgeMetricsMouseListener SaveEdgeMetricsDialog DefaultProjectMetricsDialog ShowProjectMetrieswithoutDialog H j S5howProjectMetricsDialog DependenciesMouseListener S5howNodeMetricsPane DiagramsSelector SaveNodeMetricsDialog SourceCodeSelector NodeMetricsMouseListener S5howDescriptionDialog ComponentsMouseListener S5howGraphDialog SaveGraphxmilDialog SaveGraphimageDialog 5howGraphMouseHandler Abbildung 19 Das Ausgabepaket aller Ergebnisse package results Die Struktur des Pakets gibt bereits Aufschluss ber die vorgesehenen Ausgabekomponenten Die drei am linken Rand des Diagramms angeordneten Unterpakete skizzieren jeweils eine der durch die Aufgabenstellung vorgegebenen Benutzerschnittstellen e edgemetrics Anzeige der Abh ngigkeiten der f r die jeweiligen Abh ngigkeiten ermittelten Metriken und der Codefragmente durch die die Abh ngigkeiten verursacht werden Ferner Anzeigemodule f r die aktuellen Projektmetriken und die durch Entfernung von Abh ngigkeiten theoretisch erreichbaren Projektmetriken e nodemetrics Anzeige der Komponenten des analysierten Softwareprojekts und der f r diese Komponenten ermittelten Metriken sowie eine Auflistung aller mit einer Komponente ber Ab
189. ken 41 Abh ngigkeitsmetriken Haben Sie Metriken aus der Kategorie Abh ngigkeitsmetriken ausgew hlt so erhalten Sie nach dem Ende der Berechnung in der Message Pane von Together ein Unterpanel Dependency Metrics angezeigt Message Pane Bisi E Message 9 id dpnt dpne d is rNFD rNSBCrNCDC sub_hw d_type Type of State Sourcecode of Dependency 205 1 TopologicalGraph 5 J 1463 001 00 00 create and access virtual method _sortedList add e 84 Design2Test JTreeTable 9 756 00 00 00 create dependency 2 new sortedList new SortedList a 187 GraphviewMouse TopologicalGraph view ftype of field private SortedList _sortedList 511 1 SortedList Ej 375 JTreeTable TresTableModel da 1 336 AbstractTreeTable TreeTableModel 6 Design2Test Yersion nalysisTable 9 756 0 0 dep to class 100 00 00 3833 33 create and access 4 878 00 00 00 create and access 4 878 00 00 00 static access EI 4878 00 00 00 create and access fw E Messages 8 Dependency Metrics A Component Metrics Abbildung 2 Panel Dependency Metrics COOC Im linken Teil der geteilten Anzeige erhalten Sie die errechneten Metriken Tabellenform angezeigt In den Zeilen der Tabelle sehen Sie die ermittelten und bewerteten Abh ngigkeiten In den Spalten werden Ihnen zu jeder
190. klen Es handelt sich im brigen wieder um eine typische Hub Abh ngigkeit Von der Klasse DruckDokumentD leiten sich einige Druckerklassen ab die ber SeminarisK und SeminarisDatenbank siehe Abschnitt 9 2 2 indirekte Abh ngigkeiten zur Datenhaltung erfahren Die Abh ngigkeit wird durch mehrfachen Zugriff auf ein statisches Attribut der Klasse SeminarisK ausgel st d_type sub_hw und subedges 61 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Erl uterungen zu den Komponentenmetriken Beide Klassen besitzen nur eine geringe Zahl von ausgehenden Abh ngigkeiten Der rACD_out Wert von SVAendernErfassenAA liegt etwa beim rACD Wert der Abh ngigkeit Die Anzahl der direkten und indirekten Abh ngigkeiten wird bestimmt durch indirekte Abh ngigkeit vom Zyklus in der Datenhaltung 9 2 4 2 Bewertung Die Abh ngigkeit wird ausgel st durch den statischen Zugriff auf das Attribut Config der Klasse SeminariskK Das Attribut liefert die einzige Instanz von Konfiguration die ben tigt wird um die Druckereigenschaften aus der SeminarlS Konfigurationsdatei zu lesen Durch die Zusammenfassung globaler Attribute der Klasse SeminarisK entsteht in diesem Fall eine indirekte Abh ngigkeit der Klasse DruckDokumentDK zur Datenbank und in die Datenhaltung Eine detaillierte Diskussion des Zugriffs auf Basiskomponenten und ein Vorschlag zur L sung des Problems erfolgt in Abschnitt 10 6 Zugriff auf globale Bas
191. l Im dritten Teil dieser Arbeit erfolgt die Verwendung von Design2Test zur Analyse eines Softwaresystems auf Probleme hinsichtlich seiner Testbarkeit Nach einer nochmaligen Motivation der Aufgabenstellung und der Beschreibung des zu analysierenden Softwaresystems folgt die Analyse und Bewertung von als testkritisch identifizierten Abh ngigkeiten des Systems und eine ausf hrliche Diskussion der hinter den Testproblemen verborgenen Entwurfsm ngel Den Abschluss des zweiten Teils bildet die konkrete Entfernung verschiedener Entwurfsprobleme und Abh ngigkeiten 8 Einf hrung 8 1 Motivation Die Motivation der in dieser Arbeit realisierten Erweiterung des Together ControlCenters kurz Together um die Funktionalit t von I mproveT war den Nutzern der Together Entwicklungsumgebung ein Hilfsmittel zur Einsch tzung und insbesondere Verbesserung der Testbarkeit ihrer Anwendung zu geben Der Entwickler erh lt durch die integrierte Testbarkeitsanalyse f r alle Abh ngigkeiten seines Systems die in Abschnitt 1 3 vorgestellten Testbarkeitsmetriken geliefert angereichert um weitere Informationen die ihm zus tzliche Hinweise zur Bewertung testkritischer Abh ngigkeiten geben F r den zweiten Teil dieser Diplomarbeit sah die Aufgabenstellung vor den entwickelten Ansatz anhand eines Beispiels auf seine Effektivit t zu untersuchen siehe Aufgabenstellung in Kapitel 2 Im Rahmen der Analyse eines real existierenden Softwaresystems sollten insbesond
192. l berhaupt eine entsprechende Funktionalit t vorsieht Dies erlaubt die entsprechenden Passagen ebenfalls zu entfernen und in der Folge die Klassen DVKostenBerechnenK undZeitpunkt aus dem System zu nehmen Schritt 2 Der Zugriff auf die Datenbank kann bei den Klassen Dozentvereinbarung und DozentvereinbarungTripel ber die von der Klasse ErweitertPersistent geerbte Methode getDb erfolgen In der Klasse DozentvereinbarungAnfragen kann f r die 104 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung Refaktorisierung der Zugriff ohne Probleme auch direkt auf die einzige Instanz der Klasse SeminarisDatenbank erfolgen Der Zugriff auf die Datenbank muss sicherlich in einer der folgenden Refaktorisierungsphasen von Grund auf neu gefasst werden Schritt 3 Abweichend von der Implementierung aller brigen Anwendungsf lle wurde in den Anwendungsf llen zur Dozentenvereinbarung in der Kontrollschicht die Ausgabe von Hinweisen und Meldungen an den Anwender realisiert berhaupt wurde in diesen Anwendungsf llen von den in der Entwurfsphase aufgestellten Design Entscheidungen praktisch v llig abgewichen Dies macht das Refactoring sehr aufwendig da es durch das v llig andere Konzept stellenweise nicht m glich ist die tats chliche Implementierung an den geplanten Entwurf anzupassen Hier handelt es sich letztlich nicht um einen versehentlichen Zugriff auf die Schnittstellenschicht sondern um eine bewusste Vorgehe
193. lasse der Tripelklasse Demzufolge sollte sie auch unabh ngig von der Refaktorisierung der Datenhaltung so modelliert werden Dies h tte allerdings nur Einfluss auf die Metrikwerte und nicht auf die Testbarkeit des Programms 9 2 27 SeminarveranstaltungOrdner OeffentlicheSeminarveranstaltung 9 2 27 1 Ergebnisse der Metrikberechnung of 5 440 0 4 4 89 62 1 8 1 2 of 6 0 510 1 7 4 89 65 62 1 0 0 4 Abbildung 90 Komponentenmetriken SeminarveranstaltungOrdner A und OeffentlicheSeminarveranstaltung B Auff lligkeiten bei den berechneten Werten Die Abh ngigkeit beruht nur auf einem einzigen allerdings statischen Zugriff sub_hw subedges d_type Alle von der Klasse SeminarveranstaltungOrdner ausgehenden Abh ngigkeiten sind im Sourcecode fest verdrahtet cd_h 80 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 9 2 27 2 Bewertung Die Ordnerklassen in SeminarlS sind bez glich ihrer Funktionalit t auf die Realisierung der Datenbankabfragen reduziert Die Verwaltung der persistenten Instanzen und der Zugriff auf diese Instanzen erfolgt ber die Dom nenklassen Die in diesem Zusammenhang realisierte Fassadenfunktionalit t der Dom nenklassen wird in Abschnitt 10 7 ausf hrlicher beschrieben Diese Abh ngigkeit veranschaulicht noch einmal die in diesem Zusammenhang auftretenden Probleme Die Dom nenklasse OeffentlicheSeminarveranstaltung besitzt diverse Methoden die im Sinne einer
194. lb von Methoden der Rumpf von anonymen Klassen beim Durchlaufen des Methodenrumpfes ebenfalls durchlaufen wurde Dies war in der Version 5 02 noch nicht der Fall was rein intuitiv die korrekte und f r die Zwecke dieser Arbeit in jedem Falle die wesentlich vorteilhaftere Art der Realisierung war Leider blieb keine Wahl und es musste ein umst ndlicher workaround eingef gt werden der die in den Methoden ebenfalls erkannten Abh ngigkeiten anonymer Klassen ausfiltert Aus der Dokumentation l sst sich im brigen nicht ablesen welche der beiden beschriebenen Realisierungen aus Sicht der Together Entwickler beabsichtigt ist Im Zusammenhang mit der Behandlung anonymer Klassen besitzt Together leider auch noch die unangenehme Eigenschaft dass die Referenzen auf die Modellelemente die f r die Repr sentation anonymer Klassen erzeugt und durch das Open API geliefert werden w hrend der Laufzeit des Programms verloren gehen so dass der versuchte Zugriff zu einer NullPointerException f hrt In einer ersten Version des Moduls wurde beispielsweise der Abh ngigkeitsgraph erst nach dem vollst ndigen Durchlaufen des Sourcecodes des zu analysierenden Projekts erstellt Aufgrund des Programmfehlers kam es bei dieser Variante relativ unvorhersehbar die Gr e des analysierten Projekts spielte dabei eine Rolle zu den angesprochenen NullPointerExceptions und zu der zu Beginn dieses Abschnitts bereits beschriebenen u erst aufw ndigen Fehlersuche in Togethe
195. llenklassen kann jederzeit nachgezogen werden Insbesondere dann wenn nach Einf hrung des Factory Mechanismus f r die Auswahlklassen die Testbarkeitsmetriken f r die brigen Schnittstellenklassen h here Werte liefern w rden 11 7 2 Durchf hrung des Refactoring Eine detaillierte Beschreibung der verschiedenen Nuancen des Factory Pattern findet man in Gamm94 und 98 Um v llige Unabh ngigkeit vom Erzeugungsmechanismus zu erreichen verwenden wir das Entwurfsmuster abstrakte Fabrik Abstract Factory Wir beginnen zun chst mit der Definition des Interfaces f r die Schnittstellenfabrik public interface IAAKlassenFabrik AuswaehlenListeAA getFirmaAuswaehlenAA SeminarisFrame parent IPersonAuswaehlenAA getPersonAuswaehlenAA SeminarisFrame parent AuswaehlenListeAA getGeschaeftspartnerAuswaehlenAA SeminarisFrame parent AuswaehlenListeAA getBelegungAuswaehlenAA SeminarisFrame parent IDozentenvereinbarungAuswaehlenAA getDozentenvereinbarungAuswaehlenAA SeminarisFrame parent AuswaehlenListeAA getSVAuswaehlenAA SeminarisFrame parent AuswaehlenListeAA getSVAuswaehlenAA SeminarisFrame parent String policy ILeitungsauftragAuswaehlenAA getLeitungsauftragAuswaehlenAA SeminarisFrame parent AuswaehlenListeAA getSeminart ypAuswaehlenAA SeminarisFrame parent Hier zeigen sich leider erste Probleme Entgegen den internen Designvorgaben der Gruppe wurde die Klasse DozentenvereinbarungAu
196. ls testkritische Abh ngigkeit erfolgen kann 9 2 26 DozentenvereinbarungTripel DVSchluessel 9 2 26 1 Ergebnisse der Metrikberechnung pk rACD 5 7 D o d Z 0 10 0 8 1 2 0 0 9 05 create and access Abbildung 87 Abh ngigkeitsmetriken DozentenvereinbarungTripel DVSSchluessel ele Int 79 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten rACD_in 7 1 0 11 1 4 9 41 3 3 89 65 62 1 9 1 0 0 0 0 0 of 2 0 1 0189 0 0 1 00 Abbildung 88 Komponentenmetriken DozentenvereinbarungTripel A und DVSchluessel Auff lligkeiten bei den berechneten Werten Die Anzahl der Statements die Ausl ser f r die vorliegende Abh ngigkeit sind ist relativ hoch subedges Die Klasse DVSchluessel ist frei von statischen Abh ngigkeiten cd_h cd_h_tr 9 2 26 2 Bewertung Die Definition der KlassenDozentenvereinbarungTripel undDVSchluessel erfolgtin derselben Sourcecodedatei Die Klasse DVSchluessel stellt verschiedene Operationen zum Umgang mit den innerhalb der Anwendung verwendeten Schl sseln persistenter Instanzen zur Verf gung Der Zugriff auf die Klasse DVSchluessel erfolgt exklusiv aus der Klasse DozentenvereinbarungTripel was wiederum zur Hub Eigenschaft der Abh ngigkeit f hrt vergleiche Abh ngigkeit 9 2 14 TeilnahmeFirmenSVRelation Teilnahme FirmenSVPaar Bei dieser Klasse handelt es sich ihrem Verwendungszweck nach eigentlich um eine innere K
197. lter Abh ngigkeiten 10 5 Sobald die Abh ngigkeit der Datenbank von der Datenhaltung beseitigt ist reduzieren sich beide Metrikwerte deutlich siehe Abschnitt 11 4 3 Die Entfernung der Abh ngigkeit w rde zu einer Zersplittung des Datenhaltungszyklus in drei Teile f hren 9 2 11 2 Bewertung S mtliche Klassen deren Instanzen persistent in der Datenbank gehalten werden sollen Dom nenklassen sowie Paar und Tripelklassen des Transformationenpakets erweitern die abstrakte Klasse ErweitertPersistent die ber die Implementierung des Interfaces IErweitertPersistent auch das Interface IPersistent des Persistenz Rahmenwerks implementiert Zur Erzeugung persistenter Objekte existiert in diesen Klassen die Methode erzeuge die durch Aufruf der Methode rzeugeObjekt IPersistent templateKlasse der Datenbankklasse des Persistenz Rahmenwerks eine persistente Instanz der jeweiligen Klasse zur ckgibt Da folglich in s mtlichen von ErweitertPersistent abgeleiteten Klassen der Zugriff auf die Datenbank ben tigt wird wurde in ErweitertPersistent die Methode getDb implementiert die fest verdrahtet die Singleton Instanz der SeminarisDatenbank liefert protected static Datenbank getDb return SeminarisDatenbank getEinzigelnstanz Hier handelt es sich um eine weitere Form der Realisierung eines globalen Zugriffs auf eine Basiskomponente des Systems vergleichbar dem Zugriff auf die Datenba
198. lweise Verdopplung der Antwortzeiten Die korrekt funktionierende Implementierung der durchreichenden Methode der Dom nenklasse lautete schlie lich wie folgt public Iterator getAlleAnsprechpartner throws DatenbankAusnahme return FirmenAnsprechpartnerRelation getEinzigelnstanz getPersonen IFirma getThis Der Zugriff auf die Methoden der Ordnerklassen bleibt vom oben beschriebenen Problem unber hrt Der Grund hierf r ist dass in diesen F llen von den Dom nenklassen ausschlie lich Parameter mit primitiven Datentypen String Date als SQL Abfrageparameter an die Ordnerklassen durchgereicht werden Unabh ngig davon ist das bei den Transformationenklassen geschilderte Problem Grund genug um auch beim Durchreichen von Methoden an die Ordnerklassen Testf lle vorzusehen 101 Kapitel 10 Entwurfsprobleme und Testbarkeit Dies f hrt zu folgenden negativen Auswirkungen auf die Testaktivit ten e Der Test der Fassaden Methoden darf nicht entfallen damit auch Fehler im Zusammenwirken mit dem Persistenz Rahmenwerk entdeckt werden k nnen Hierdurch entstehen letztlich redundante Testf lle f r alle durchgereichten Methoden Neben dem Test der Methode in der Assoziationsklasse muss in der Dom nenklasse erneut die erwartete Funktionalit t getestet werden Der ohnehin schon zus tzliche Implementierungsaufwand aufgrund des gew hlten Entwurfsmuster f hrt also dar ber hinaus zu einer Verdopplung des Testau
199. m Verwendung Die Verbindung zur Datenbank wurde ber ein Persistenz Rahmenwerk PersistenzRW realisiert das im Rahmen einer Diplomarbeit an der FernUniversit t entwickelt wurde Als Entwicklungsumgebungen standen den Studenten in der Implementierungsphase wahlweise Together oder JBuilder der Firma Borland zur Verf gung Der Schwerpunkt des Software Praktikums lag aufgrund der begrenzten Zeit auf der Entwurfs und Implementierungsphase so dass die Durchf hrung von Tests berwiegend unsystematisch und insbesondere undokumentiert erfolgte F r die Analyse des Projekts hinsichtlich seiner Testbarkeit stehen demzufolge keinerlei Unterlagen aus der Entwicklungsphase wie beispielsweise Testf lle zur Verf gung 49 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 9 1 Einleitung Design2Test liefert im Rahmen der Testbarkeitsanalyse von SeminarIS Testbarkeitsmetriken f r 273 Komponenten Klassen und 1872 Abh ngigkeiten zwischen diesen Klassen Bezogen auf die in Abschnitt 1 3 vorgestellten Testbarkeitsmetriken erweitert um eine Metrikvariante ACDh bei deren Errechnung nur statische Abh ngigkeiten ber cksichtigt werden ergeben sich f r SeminarlS folgenden Werte Project Metrics EN 60 35496 810 39 0 106 0 5 0 Abbildung 26 Projektmetriken Seminarl S Jede SeminarlS Klasse ist im Durchschnitt ca 89 anderen Klassen direkt oder indirek
200. m sste die Paketstruktur dahingehend ge ndert werden dass alle Auswahlklassen exklusiv mit der Fabrik im selben Verzeichnis liegen Dann k nnte f r alle Konstruktoren der Auswahlklassen paketlokaler Zugriff gesetzt werden und die Erzeugung einer Auswahlklasse auf direktem Wege von au erhalb des Paketes w re unterbunden 11 7 3 Zwischenergebnisse Ein Blick auf die Projektmetriken vermittelt den Eindruck dass die Refaktorisierung absolut kontraproduktiv war Project Metrics EN Metric 89 11439 60 35496 81 0 39 0 106 0 5 0 142 64793 77 0 NSBC 40 0 NCDC 193 0 20 Abbildung 124 Vergleich Projektmetriken vor und nach Einf hrung einer Schnittstellen Fabrik Die durchschnittliche Abh ngigkeit einer Komponente ist um 109 Prozent angestiegen beschr nkt auf fest verdrahtete Abh ngigkeiten sogar um 138 Prozent F nf kleinere Abh ngigkeitszyklen sind zu zwei gr eren Zyklen verschmolzen die Anzahl der darin befindlichen Komponenten ist um 82 Prozent gestiegen Was sind die Gr nde f r diese unerwartete Ver nderungen der Metriken Zwei Aspekte sind f r den Anstieg bedeutsam Der erste wird augenf llig wenn wir einen Ausschnitt aus dem Klassendiagramm betrachten der die Verwendung der neu eingef hrten Fabrik veranschaulicht 121 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung 4 SeminarisFrame SVAendernErfassenAA
201. men des Ereignismanagements beobachtet werden Dies f hrte dazu dass die beim Synchronisationsmanager registrierten Komponenten nicht konsistent gehalten werden konnten Da der Zustand der geschlossenen Komponenten ferner undefiniert im Sinne von zuf llig war f hrte dies zu unvorhersagbaren Programmabl ufen e Das Synchronisationsmanagement deckte nur den Teilbereich der konsistenten Anzeige aller Komponenten ab Der Start der erneuten Metrikanalyse konnte dar ber nicht gel st werden 36 Kapitel 6 Entwurf 6 9 Abschlie endes Klassendiagramm des Entwurfs Nachfolgend das aus dem Entwurf resultierende Klassendiagramm von Design Test ideScript Design2Test interface IdeProjectAdapter D2TMediator D2TMediatorimpl ConfigSearchScope LoadMetricsfromFileDialog options VersionAnalyzer AnalyzeOptionsDialog AnalyzeOptions ComputeMetries SaveMetricSelectionDialog AnalyzeOptionsimp NodeAnalyzer SelectMetricsDialog SelectMetrics Element Analyzer visitors DependencyGraph Localization ElementDeletedException SearchScope DependencySearcher SourceCodeReference DependencySearchListener common edgemetrics graph nodemetrics Abbildung 24 Entwurfsklassendiagramm von Design2Test 37 Kapitel 7 Implementierung 7 Implementierung 7 1 Einleitung Begonnen wurde die Implementierung mit Version 5 02
202. metriken ausgew hlt so werden Ihnen die Ergebnisse der Berechnung in einem Unterpanel Component Metrics in der Message Pane von Together angezeigt ber ein Kontextmen stehen Sie Ihnen auch hier weitere Aktionen zur Verf gung gt 4 2 Komponentenmetriken Achten Sie bitte bei der Berechnung der Metriken darauf dass alle Ergebnisse nur dann zuverl ssig sind wenn Ihr Sourcecode kompilierf hig ist Enth lt Ihr Programm Syntax Fehler oder sind nicht alle Bibliotheken oder Pfade eingebunden so kann dies zu Problemen und fehlerhaften Metrikwerten f hren 166 Anhang Metrikauswahl 3 Metrikauswahl Zu Beginn einer Metrikberechnung legen Sie die zu berechnenden Metriken und die Rahmenbedingungen der Sourcecode Analyse fest 1 W hlen Sie im Hauptmen den Men punkt Tools Testability Metrics Sie erhalten folgenden Dialog angezeigt in Abh ngigkeit von den verf gbaren Metriken Testability Metrics x Component Metric Abbreviatio package of component package name of component name Dependency Metric Abbreviatio package of dependent component pkg_dpnt dependent component dpnt layer of dependent component lay_dpnt layer of component layer dependent component is interface itf dont component is interface interf package of dependee component pkg_dpne has private constructor pry_cstr dependee componert dpne total number of component dependencies cd layer of depe
203. minarisDatenbank zugegriffen Von dort erfolgt der Zugriff auf die zyklisch verbundene Datenhaltungsschicht ber die hier diskutierte Abh ngigkeit erfolgt demnach die Verkn pfung von Subgraphen woraus sich der Begriff Hub Mittelpunkt Netzknoten ableitet Ausgel st wird die Abh ngigkeit an einer Stelle durch statischen Zugriff auf die einzige Datenbankinstanz auf deren Methoden dann mehrfach nicht statisch zugegriffen wird d_type sub_hw und subedges 56 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Erl uterungen zu den Komponentenmetriken Auff llig sind insbesondere die extrem hohen Werte der Metriken rACD_in und rACD_out f r die Klasse SeminarisDatenbank Auf die Ursachen wird in der Bewertung n her eingegangen 9 2 2 2 Bewertung Bei SeminarisK handelt es sich um die Haupt Kontrollklasse der Anwendung Sie stellt verschiedene globale Attribute f r die Logikschicht zur Verf gung und liefert auf Anfrage f r bestimmte Dom nen eindeutige Bezeichner Die Klasse SeminarisDatenbank ist von der Datenbank Klasse des verwendeten Persistenz Rahmenwerkes abgeleitet Dabei wurden die Transaktionsmethoden der Superklasse berschrieben und Funktionalit t zur Initialisierung der in Seminarisk verwalteten eindeutigen Bezeichner hinzugef gt Die Abh ngigkeit basiert demnach auf folgenden Punkten In SeminarisK wird versucht den Klassen der Kontrollschicht zentralen Zugriff auf die Basiskomponenten der Anw
204. minarl mit der Ermittlung der Testbarkeitsmetriken Darauf aufbauend erfolgt die Bewertung jener Abh ngigkeiten in SeminarlS deren Beitrag zur Zahl der durchschnittlichen direkten und indirekten Abh ngigkeiten einer SeminarlS Komponente Klasse am h chsten ist Kapitel 9 Im Rahmen dieser Bewertung wird sich zeigen dass SeminarlS unter einigen massiven Testproblemen leidet die auf problematische und zum Teil auch fehlerhafte Entwurfsentscheidungen sowie einzelne Implementierungsfehler zur ckzuf hren sind e Beinahe alle in der Datenhaltungsschicht angesiedelten Klassen sind in einem einzigen Abh ngigkeitszyklus enthalten e Gro e Systemteile sind von der verwendeten Datenbank bzw dem eingesetzten Persistenz Rahmenwerk statisch abh ngig e Bei der Implementierung erfolgte mehrfach eine Verletzung der Drei Schichten Architektur durch Zugriff aus tieferliegenden Schichten auf eine der bergeordneten Schichten was zu immensen zyklischen Abh ngigkeiten SeminarIS f hrte Diese Erkenntnisse wurden beim Versuch erste Testf lle f r SeminarlS zu erstellen best tigt Hier zeigte sich dass bei der Durchf hrung von Klassentests Unit Tests die Idealvorstellung des isolierten Tests einer Klasse nicht einmal ansatzweise realisiert werden konnte So wird beispielsweise auch beim Test der meisten Benutzerschnittstellenklassen stets die Datenbank gestartet bereits abgefragt und unter Umst nden durch das Persistenz Rahmenwerk zus tzl
205. mittelbare Verbindung zu Together Elementen vornehmen zu k nnen k nnen ferner die als Inhalte von Kanten und Knoten des Graphen gespeicherten Verweise auf diese Elemente ausgelesen werden Collection contents Collection subEdges Collection subNodes Collection incomingEdges Collection outgoingEdges Da sowohl die in diesem Abschnitt beschriebenen Metriktabellen als auch ihre Tabellenmodelle in Together zur Anzeige der Metrikergebnisse verwendet werden k nnen werden diese bei der Anzeige der Testbarkeitsmetriken als Grundlage f r den Entwurf der Ausgabekomponente dienen siehe Abschnitt 6 7 5 82 Graphische Anzeige der Abh ngigkeiten Ausgabeschnittstelle von ImproveT ImproveT bietet die M glichkeit den zu Beginn erzeugten Abh ngigkeitsgraphen zu visualisieren Die Visualisierung erfolgt ber die Darstellung des Graphen als geometrischer Graph mit Knoten und Kanten in der Zeichenebene F r die Darstellung des Graphen zeichnet die Klasse TopologicalGraphView verantwortlich F r die vollst ndige Integration in eine externe Anwendung dient ferner die nach dem Listener Muster vorgenommene Implementierung GraphViewMouseHandler 21 Kapitel 5 Analyse JComponent TopologicalGraphView TopologicalGraphview addMouseHandler mouseHandler GraphviewMouseHandler void setColorSchema schemaiint void getColorSchemas tringArrayd String startSort void addNodeSelectionObserver o MyObserver
206. n BuchtPaar 76 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 3 1 Of 2 1 1 0 3 13 218 2 1 Of 1 0 0 1 4 111 118 Abbildung 80 Komponentenmetriken BuchtRelation A und BuchtPaar B Auff lligkeiten bei den berechneten Werten Die rACD Werte der Klasse BuchtRelation liegen deutlich ber dem rACD Wert der Abh ngigkeit 9 2 22 2 Bewertung Die beiden beteiligten Klassen resultieren aus der transformierten Assoziation zwischen einer Firma und einer von ihr gebuchten Seminarveranstaltung Die Bewertung der Abh ngigkeiten zwischen Relationen und Paarklassen wurde bereits bei Abh ngigkeit 9 2 14 vorgenommen 9 2 23 FirmenAnsprechpartnerRelation FirmenAnsprechpartnerPaar 9 2 23 1 Ergebnisse der Metrikberechnung o lis_feedb pk Abbildung 82 Komponentenmetriken Firmen AnsprechpartnerRelation A und FirmenAnsprechpartnerPaar Auff lligkeiten bei den berechneten Werten Die rACD Werte der Klasse FirmenAnsprechpartnerRelation liegen deutlich ber dem rACD Wert der Abh ngigkeit 9 2 23 2 Bewertung Die beiden beteiligten Klassen resultieren aus der transformierten Assoziation zwischen einer Firma und einer bei ihr als Ansprechpartner fungierenden Person Die Bewertung der Abh ngigkeiten zwischen Relationen und Paarklassen wurde bereits bei Abh ngigkeit 9 2 14 vorgenommen 77 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 9 2 24 LeitungsauftragRelation Lei
207. n Entit tsklassen entfernt mit einer Ausnahme In der Klasse Person waren noch drei Methoden verblieben die aufgrund umfassend vorhandener Logik nur mit erh htem Aufwand refaktoriert werden konnten Message Pane Jee ee dpne El d ep HER _ PPerson a PDozentenvereinbarungRelation 118 339 _ PDozentenvereinbarung PDYKostenBerechnenK 110 334 1 2 PSeminaris Datenbank 16 8566 is 1 lt 2 PSeminarisDatenbank 15 5240 l PBelegungRelation 14 0686 Sal ES _ PPerson a l 1 PTeilnahmeFirmenS W Relation 1 2 7218 1 PLeitungsauftragRelation 1 2 4808 Sin Ee PSvAendernErfassen 4 PLeitungsauftrag amp uswaehlend amp 11011 12 3154 Abbildung 118 Momentaufnahme der Testbarkeitsmetriken w hrend Datenhaltung Refaktorisierung Die in der Klasse Person zu diesem Zeitpunkt noch verbliebenen Abh ngigkeiten zu Relationenklassen verf gen ber deutlich erh hte Metrikwerte 11 6 2 Durchf hrung des Refactoring Zur Refaktorisierung der Datenhaltungsschicht wurden sukzessive alle Dom nen und Assoziationsklassen auf das Vorhandensein von Abh ngigkeiten zu Relationen und Ordnerklassen untersucht Das Vorgehen beim Entfe
208. n Metrikwerte und der Anzeige von Prozentwerten w hlen F r Abh ngigkeitsmetriken handelt es bei der Prozentangabe um den Grad der Verringerung des korrespondierenden Projekt Metrikwertes der durch Entfernung der Abh ngigkeit erreicht w rde F r Komponentenmetriken gibt der Prozentwert an welchen Anteil zu der Gesamtzahl des betreffenden Abh ngigkeitstyps ein weiter verfeinerter Typ der Abh ngigkeit beitr gt Um das von Ihnen gew nschte Anzeigeformat einzustellen w hlen Sie im Untermen Format des Kontextmen s einen der beiden Eintr ge Absolute Values oder Values as Percentage 4 3 10 Export der Metrikergebnisse Sie k nnen die Ergebnisse der Metriktabellen zur weiteren Verarbeitung im Textformat speichern W hlen Sie hierzu den Men punkt Export aus dem Kontextmen Eine n here Beschreibung des Speichervorgangs finden Sie Abschnitt 6 2 1 Speichern der Metrikergebnisse des Kapitels 6 Erweiterte Funktionen und Einstellungen 4 3 11 Druck der Metrikergebnisse Sie k nnen sich die Ergebnisse der Metriktabellen ausdrucken lassen W hlen Sie hierzu den Men punkt Print aus dem Kontextmen Eine n here Beschreibung des Druckdialogs finden Sie in Abschnitt 6 2 2 Druck der Metrikergebnisse im Kapitel 6 Erweiterte Funktionen und Einstellungen 173 Anhang Anzeige der Metriken 4 4 Projektmetriken Bei den Projektmetriken handelt es sich um folgende Abh ngigkeitsmetriken e Average cummulative Component Dependenc
209. n Refaktorisierungsschritte festzuhalten 11 2 Realisierung einer strikten Drei Schichten Architektur 11 2 1 Ausgangssituation Obwohl als Vorgabe die Entwicklung einer strikten Drei Schicht Architektur galt wurde aus drei Datenhaltungsklassen auf die Kontrollschicht zugegriffen siehe Abschnitt 10 3 Hierbei handelt es sich zum einen um den Zugriff der Dom nenklasse Dozentvereinbarung in Fassadenmanier auf die Kontrollklasse DVKostenBerechnenK siehe auch Abschnitt 10 7 Bei den brigen Zugriffen handelt es sich Versuche in der Datenhaltung die Datenbankinstanz von der Hauptkontrollklasse zu erfragen Ferner erfolgt aus f nf Kontrollklassen der Zugriff auf die Schnittstellenschicht um von der Hauptschnittstellenklasse zur Ausgabe von Meldungen die Instanz des Hauptanwendungsfensters zu erhalten 11 2 2 Durchf hrung des Refactoring Schritt 1 Die obsolete Methode getKosten kann sowohl aus der Dom nenklasse Dozentenvereinbarung als auch aus seinem Interface IDozentenvereinbarung entfernt werden Prinzipiell k nnte damit die komplette Klasse DVKostenBerechnenk entfernt werden und ebenfalls die Klasse Zeitpunkt die im selben Source File definiert ist Dies f hrt aber dazu dass das Projekt nicht mehr kompilierbar ist In der Klasse DozentenvereinbarungAuswaehlenAA existiert Sourcecode f r eine Schaltfl che zur Berechnung der Kosten eines Dozenten Diese Schaltfl che ist aktuell jedoch nicht aktiviert wie auch kein Anwendungsfal
210. n eine Neukompilierung des Design2Test Moduls nicht erforderlich Bei der Auswahl der zu berechnenden Metriken stellt sich die Implementierung des Konstruktors beispielsweise wie folgt dar public EdgeMetricsTableModel 1 String moduleHome IdeAccess getIdeManager getModuleHomeDirectory this getClass try BufferedReader edgeMetricsIn new BufferedReader new FileReader moduleHome Localization getString ImproveT EdgeMetricsInputFile String metricSetName null Class metricCls null Object metricInst null for metricSetName edgeMetricsIn readLine if metricSetName null break try 1 get the metric class metricCls Class forName Localization getString ImproveT EdgeMetricPackage metricSetName metricInst metricCls newInstance 1 MetricSet metricInst hasPercentageValue MetricSet metricInst setAsPercentage true metricSets add MetricSet metriciInst catch ClassNotFoundException e IdeMessageManagerAccess printMessage IdeMessageType ERROR_MODAL MetricClass not found e toString catch InstantiationException e IdeMessageManagerAccess printMessage IdeMessageType ERROR_MODAL MetricClass cannot be instantiated e toString catch IllegalAccessException e IdeMessageManagerAccess printMessage IdeMessageType ERROR_MODAL MetricClass cannot be accessed e toString Die Angabe der Metriken in den Kon
211. n oder verdeckten Methoden erste Anweisung einen implizit generierten super Aufruf in den Konstruktor ein Dieser vom Compiler eingef gte Aufruf des Superklassenkonstruktors bleibt bei der Ermittlung dieses Abh ngiskeitstyps unber cksichtigt public class FirmaErfassenK extends FirmaAendernErfassenK protected FirmaErfassenK super Ruft ein Konstruktor mittels der this Anweisung einen anderen Konstruktor derselben Klasse auf wird dies als klasseninterne Abh ngigkeit zu einer statischen Methode gespeichert D_CALL_TS B 16 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Der explizite Aufruf eines Superklassenkonstruktors ber die super Anweisung f hrt zu folgenden Eintr gen im Abh ngiskeitsgraph Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary T_CLASS FirmaAendernErfassenK CLASS Class D_CALL_SU FirmaErfassenK_ T_CLASS FirmaAendernErfassenK T_CLASS Member D_CALL_SU constructor T_CONSTR constructor T_CONSTR B 17 Aufruf von berschriebenen oder verdeckten Methoden B 17 1 Erl uterung und Beispiel Innerhalb einer Subklasse kann auf berschriebene oder verdeckte Methoden von Superklassen mittels des Schl sselwortes super zugegriffen werden Au er dem Namen hat dies mit dem Aufruf des Superklassen Konstruktors nichts gemeinsam public class Firma extends Geschaeftspartner
212. n von den Relationenklassen zu den Paarklassen sind gute Indikatoren f r diese Problematik da der Zugriff auf die Paarklasse exklusiv durch die Relationenklasse erfolgt Dadurch entstehen in der Datenhaltungsschicht zwischen den jeweils zusammengeh renden Relation und Paarklassen die zu Abh ngigkeit 9 2 2 beschriebenen Hub Abh ngigkeiten 9 2 15 SVSeminartypRelation SVSeminartypPaar 9 2 15 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken 71 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Abbildung 65 Abh ngigkeitsmetriken SVSeminartypRelation SVSeminartypPaar Klasse jedt jed_t_if cd_t_ac cd_t_c cd_h _ dh o ed_h_is ed_s_c 64 5 jed_ci jed_im _ ed Im rACD_out E 0 oj 2 89 9 5 0 042 89 65 6211 0 Abbildung 66 Komponentenmetriken SVSeminartypRelation A und SVSeminartypPaar Auff lligkeiten bei den berechneten Werten Die rACD Werte der Klasse SVSeminartypRelation liegen deutlich ber dem rACD Wert der Abh ngigkeit 9 2 15 2 Bewertung Die beiden beteiligten Klassen resultieren aus der transformierten Assoziation zwischen einer Seminarveranstaltung und einem Seminartyp Die Bewertung der Abh ngigkeiten zwischen Relationen und Paarklassen wurde bereits bei Abh ngigkeit 9 2 14 vorgenommen 9 2 16 SV Ansprech
213. nachfolgende Skizze Die Benennung der Elemente ist im brigen identisch mit den Zugriffsmethoden des Interfaces SciClass auf diese Komponenten SeiClass JavaKlasse Abbildung 4 Elementare Bestandteile einer SciClass Abh ngigkeiten zu anderen Programmkomponenten k nnen in allen oben aufgef hrten Elementen vorhanden sein Folglich m ssen im Rahmen der Analyse s mtliche Elemente durchlaufen werden F r das Durchlaufen der Klassen und deren repr sentierenden Elementen stellt das Together Open API ein Interface zur Verf gung das das Entwurfsmuster Visitor Gamm94 realisiert Dieses Interface findet Verwendung um durch Zuweisung des Visitors an die Klassen Zugriff auf deren Inhalte einschlie lich der oben beschriebenen Elemente der Klassen zu bekommen interface SciElementvisitor visitCiass Object yistAtribute Object yistOperation Object visitVariable Object visitFunchon Object yisitParameter Object visitinheritance Object visitT hrowSpecifier Object visiinitalizer Object Abbildung 5 Interface SciElementVisitor 14 Kapitel 5 Analyse Teilweise ist es bereits auf dieser Ebene m glich also bei der Untersuchung der Elemente mittels Implementierung der visit Methoden dieses Interfaces Abh ngigkeiten zu anderen Programmkomponenten zu identifizieren In den meisten F llen muss die Analyse allerdings noch einen Schritt weiter gehen Dies soll nachfolgend am Beispiel des Durchlaufens von Metho
214. nager addCommandToQueue new Runnable E public void run de open graph and highlight current edge mediator showGraph mediator edgeChanged edge table F r die Implementierung der Druckausgaben wurden die bereits existierenden Komponenten des Ouality Assurance Moduls OA Modul wiederverwendet Dies erspart an dieser Stelle erheblichen Aufwand der bei einer eigenen Implementierung zu leisten gewesen w re Ein kleiner Nachteil dieser Variante ist allerdings dass die Druckausgaben von Design2Test damit nur bei geladenem OA Modul verf gbar sind Da dieses Modul aber bei der Standardinstallation des Together ControlCenters automatisch geladen wird und damit blicherweise f r den auf Qualit tssicherung bedachten Anwender verf gbar sein wird kann dieser Nachteil in Kauf genommen werden 7 8 Komponente Modulkoordination class D2TMediator Die Komponente zur Modulkoordination steuert als Mediator das Zusammenspiel aller Komponenten von Design2Test Bei der zentralen Methode zur Steuerung des Programmablaufs handelt es sich um startAnalysis 44 Kapitel 7 Implementierung public void startAnalysis IdeAccess getIdeManager addCommandToQueue new Runnable 1 public void run ComputeMetrics computeMetrics new ComputeMetrics metricsDialog getEdgeMetricsClassNanes metricsDialog getNodeMetricsClassNames analyzeOptions logging compute
215. nalyse derjenig k nnen en Abh ngigkeiten eingef hrt die innerhalb der Verwendung eines new Operators auftreten 40 Kapitel 7 Implementierung public Object visitReference SciReference sciReference only the reference expressions are interesting at this point if sciReference instanceof SciReferenceExpression return null the element to which the reference points SciElement referencedElement sciReference getReferencedElement references out of classpath are null AND unfortunately references to the implicite standard constructor also if referencedElement null 1 search alternatively for the class type itsself SciType type null we must look for the SciNewExpression and its SciType SciExpression parent SciReferenceExpression sciReference getParent while parent null if parent instanceof SciNewExpression type parent getType 1 type null referencedElement type getReferencedElement if referencedElement null addNewInstanceDependency sciReference referencedElement SciClass referencedElement parent parent getParent return null Die gekennzeichneten Programmstellen basieren auf dem f r Testbarkeitsbetrachtungen ungl cklichen Umstand dass der implizite parameterlose Java Default Konstruktor nicht im Programmcode vorhanden ist Das Einf gen dieses Konstruktors in kompilierte class Dateien w
216. nalyse sieht vor diese Abh ngigkeiten in einer Graphstruktur zu speichern und sie zur Berechung von Testbarkeitsmetriken in Form dieses Graphen an mproveT weiter zu reichen In den nachfolgenden Abschnitten wird deshalb auch f r jede Abh ngigkeit beschrieben in welcher Form sie ihre Repr sentation im Graph findet Zum besseren Verst ndnis der beschriebenen Grapheintr ge wird in nachstehender Abbildung versucht anhand einiger weniger Beispieleintr ge bereits vorab die Struktur des entstehenden Abh ngigkeitsgraphen zu veranschaulichen Man erkennt die Ebenenstruktur des Graphen die Darstellung der Komponenten des Systems als Knoten und der Abh ngigkeiten als Kanten des Graphen und die hierarchische Verkn pfung der Knoten und Kanten der jeweils benachbarten Ebenen Abh ngigskeitsgraph E summary level KlasseB Zusammenfassung mit inneren Klassen auf Summary Ebene Unterknoten der Klasse Zusammenfassung der feineren Abh ngigkeiten Unterknoten auf Summaryebene class level KlasseA DF THE Unterknoten attributA ohne innere Klasse D_CALL_VI Zusammenfassung von Methoden j Zusammenfassung der Unterknoten les Sen See E AAN auf Klassenebene statichlethodeE2 PERO EAA member level methodeat 5 D_CALL_M Methode t Ke X D attributA methodeA2 E D_CALL_ST N static MethodeB2 innerel
217. nativ w re denkbar die im aktuellen Kontext g ltige Fabrik von einer Systemklasse abzufragen z B MySystem getDatenbankFabrik Dies w rde jedoch eine erneute B ndelung der Basiskomponenten bedeuten was eine verst rkte Kopplung des Systems nach sich ziehen w rde Zudem kann weiterhin unter Umgehung der Fabrik die Objekterzeugung direkt erfolgen Dass das Entwurfsmuster hier keine Hilfestellung ist liegt vermutlich daran dass es hier eine gewisse Zweckentfremdung erf hrt Die origin re Definition und Aufgabenstellung des Patterns war die dynamische und variable Objekterzeugung zur Laufzeit des Programms siehe Gamm94 und Coop98 Im hier diskutierten Fall handelt es sich aber nicht um dynamische Objekterzeugung da f r die Anwendung stets die Erzeugung derselben Objektinstanz vorgesehen ist 11 5 2 4 Zugriff ber Registry Mechanismus Ein verbreiteter Ansatz der auf die globale Bereitstellung von Systemressourcen bei gleichzeitiger Unabh ngigkeit von der Objekterzeugung zielt ist deren Bereitstellung ber einen Registry Mechanismus oder Namensdienst siehe Coop98 und Wulff02 Hierbei wird beispielsweise jede Singleton Instanz als die h ufigste Implementierung von Basiskomponenten nach Ihrer Erzeugung bei einer Registry Klasse angemeldet Jede Klasse die Zugriff auf ein Singleton ben tigt bekommt in der Folge von der Registry ber Angabe eines textuellen Bezeichners z B den Namen der Klasse die erzeugte Instanz
218. nd wiederum J2EE genannt 11 5 2 5 Auf Seminaris zugeschnittenes Alternativkonzept F r die Refaktorisierung von SeminarlS findet unter Beachtung der vorstehenden berlegungen ein Alternativkonzept Verwendung Es basiert auf der Entfernung der globalen Zugriffsm glichkeit aus den sSingleton Klassen und auf der Einf hrung einer konfigurierbaren Zugriffsklasse f r jede Singleton Instanz Diese Variante garantiert folgende Punkte e Dynamische Konfigurierbarkeit der Basiskomponenten in der Testumgebung e Erzeugung der Ressourcen bei Bedarf keine zus tzlichen Abh ngigkeiten durch B ndelung des Zugriffs auf die Basiskomponenten an einer Stelle des Systems keine Reduzierung der Typsicherheit e kein versehentliches oder absichtliches Umgehen des Konzeptes m glich e relativ geringer Implementierungsaufwand Die konkrete Realisierung des Konzept wird nachstehend am Beispiel des Zugriffs auf die Datenbank von SeminarlS erl utert Jede Basiskomponente erh lt innerhalb ihres Pakets eine Provider Klasse zur Seite gestellt die ber eine statische Methode den globalen Zugriff auf die Basiskomponente sicherstellt Diese get Methode liefert als R ckgabetyp einen noch zu definierenden Interfacetyp package SeminarisP ExterneSystemeP PersistenzP public class SeminarisDatenbankProvider private static ISeminarisDatenbank seminarisDatenbank SeminarisDatenbank getEinzigelnstanz public static ISemin
219. ndee component lay_dpne number of component dependencies to types is dependency within component dep_comp number of component dependencies to interfac cd In is feedback dependency is_feedb number of component dependencies to abstrac cd_t_ac dependency crosses package boundary is_intpk number of component dependencies to classes direct or indirect inheritance dependency is_inher COCIOOOCOICIOCOCC number of componert dependencies caused by hi number of component dependencies caused by cd_h_is number of static component dependencies wit bs number of solely create dependencies ed_s_c number of create dependencies incl static Cd Ss Cu number of static access component dependenc cd_s_a number of dependencies to final classes cd_h_f number of dependencies rooted in class interfa number of hard wired dependencies rooted reduction of average cummulative component d reduction of average cummulative component d reduction of average cummulative component d reduction of number of feedback dependencies MED number of stubs required to break dependency rNSBC reduction of number of components involved rNCDC reduction of number of dependency cycles rNDC percentage hard wired dependencies on sta sub_d_hw number of underlying dependencies on stateme sub_d
220. nden getHoechste und getNext Methoden und deren Verlagerung in die Klassen e GeschaeftspartnerOrdner Verwaltung der Kundennummer als eindeutiges Attribut eines Gesch ftspartners e SeminarveranstaltungOrdner Verwaltung der Rechnungsnummer als eindeutiges Attribut einer Firmenseminarveranstaltung BelegungRelation Verwaltung der Rechnungsnummer als eindeutiges Attribut einer Belegung LeitungsauftragRelation Verwaltung der Leitungsauftragsnummer als eindeutiges Attribut eines Leitungsauftrags Dies f hrt unter anderem dazu dass alle SQL Abfragen auf die Datenbank ausschlie lich in den Ordner und Relationenklassen angesiedelt sind Die Verlagerung der Methoden muss abschlie end in der Kontrollschicht nachvollzogen werden Hierzu sind Anpassungen des Methodenaufrufs in f nf Kontrollklassen notwendig F r die Refaktorisierung fallen folgende Aufw nde an e Leitungsauftrag 15 Minuten e Gesch ftspartner 10 Minuten e Belegung 10 Minuten e Firmenseminarveranstaltung 15 Minuten Im jeweiligen Aufwand ist bereits die Anpassung des Zugriffs aus der Kontrollschicht enthalten 108 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung 11 4 3 Ergebnisse Man erh lt folgende Ver nderung der Projektmetriken Project Metrics EN Project Metrics EN 60 35496 810 39 0 106 0 5 0 43 699475 74 0 35 0 NCDC 102 0 9 0 Abbildung 114 Proj
221. nder Dialog Bag CT doc lib license Jl modules E lt com togethersoft lt modules addlinked antrunner beans bookmarks declshorteuts defDocCommert Dateiname ei Dateien des Typs Plain Text files 154 x 2 Abbildung 18 Dialog zum Speichern der Metrikergebnisse W hlen Sie das Verzeichnis und geben Sie den Namen der Datei an unter dem die Resultate der Metrikberechnung gespeichert werden sollen Um den Speichervorgang abzuschlie en dr cken Sie die Schaltfl che Save 183 Anhang Erweiterte Funktionen und Einstellungen 6 2 2 Druck der Metrikergebnisse ACHTUNG Um die Druckmen s von Design2Test nutzen zu k nnen muss das Quality Assurance QA Modul von Together geladen sein gt 1 Installation Um die Abh ngigkeits oder Komponentenmetriken auszudrucken w hlen Sie den Men punkt Print im Kontextmen der Metriktabellen Hierauf ffnet sich folgender Druck Dialog Print E Select Columns to Print Scope Column Al rows 2 Selected rows Scale Fi page width w Preview Last Page 1 of 1 Page Setup Cancel 2 Abbildung 19 Dialog zum Drucken der Metrikergebnisse W hlen Sie im linken oberen Teil des Dialogs diejenigen Spalten der Metriktabelle aus
222. nem vern nftigen Ende zu bringen Zus tzlicher Dank geb hrt Renate Merl die mich bis zur letzten Sekunde durch Korrektur lesen unterst tzt hat Silvia Baumann danke ich daf r dass sie in den letzten Monaten der Ruhepol meines Lebens war Last but not least geht mein Dank an meine Arbeitskollegen f r ihre Nachsicht ihre Ratschl ge und daf r dass auch sie stets ein aufmunterndes Wort f r mich brig hatten Vielen Dank Inhaltsverzeichnis TEIL I EINLEITUNG keine 1 1 ABH NGIGKEITEN UND 1 1 1 Testbarkeit Motivation und Deiinurion 1 12 Einfluss von Abh ngigkeiten auf Testbarkeit en 2 1 3 Testbarkeitsmetriken zur Identifizierung testkritischer Abh neigekeiien 3 2 AUFG BENSTELTEUNG as a en essen Ee EE Ee dE 5 AUFBAU DIER RRE e Egger eege Hd ee E Ad 6 TEIL WERKZEUGERSTELLUNG 5 4 4 4 2 7 4 ANFORDERUNGSERMITTLUNG 7 41 Pr zisierung der een 7 4 2 lees AEN 8 43 Zerlegung Teilaufgaben 1 bis 5 02 0000 8 5 ANALYSE EE 9 9 5 2 Metrikwerkzeug 9 5 3 Entwicklungsumgebung Together 9 54 Erweiterung von T
223. nente alle Komponenten angezeigt die mit dieser Komponente direkt in Abh ngigkeit stehen Dabei sehen Sie in der oberen H lfte die Komponenten von denen die aktuell selektierte Komponente abh ngig ist Im unteren Teil werden die Komponenten angezeigt die von der aktuell selektierten Komponente abh ngig sind Die Anzeige erfolgt jeweils in Tabellenform Zu jeder verbundenen Komponente wird der Typ der Abh ngigkeit der Name der Komponente und der Typ der Komponente angezeigt Sobald Sie im linken Teil der Anzeige eine andere Komponente selektieren wird die Anzeige der verbundenen Komponenten im rechten Teil automatisch aktualisiert Zwischen den jeweiligen Teilfenstern Metriktabelle und Komponententabellen k nnen Sie zwei kleine Pfeile erkennen Mit Hilfe dieser beiden Pfeile k nnen Sie wahlweise einen der Fensterbereiche ausblenden und den jeweils anderen Bereich vergr ern Um ein Kontextmen angezeigt zu bekommen das Ihnen die Funktionalit t anbietet die in der jeweiligen Anzeige zur Verf gung steht klicken Sie mit der rechten Maustaste in eine der beiden Tabellen Eine detaillierte Beschreibung der Ihnen zur Verf gung stehenden Funktionen finden Sie in Abschnitt 4 3 Funktionen Eine bersicht und Kurzbeschreibung des Kontextmen s erhalten Sie in Anhang Kontextmen s Kurz bersichten 170 Anhang Anzeige der Metriken 4 3 Funktionen in den Metrikanzeigen 4 3 1 Navigation zum Sourcecode Die Anzeige der Abh ngi
224. ner Entwicklungsumgebung zur Verf gung Die Testbarkeitsanalyse umfasst Aussagen ber aus Sicht der Testbarkeit interessierende Eigenschaften eines Softwaresystems und liefert insbesondere Hinweise auf m gliche testkritische Abh ngigkeiten zwischen einzelnen Komponenten Testkritische Abh ngigkeiten sind Abh ngigkeiten die einen potentiell hohen Einfluss auf die Testbarkeit besitzen Ihre Untersuchung erscheint zur Verbesserung der Testbarkeit besonders lohnenswert Mit Design2Test erh lt der Entwickler eine vollst ndige bersicht der zwischen den Klassen eines Java Programms vorhandenen Abh ngigkeiten einschlie lich der Anzeige des zur Abh ngigkeit f hrenden Programmcodes F r jede Klasse erfolgt eine Aufschl sselung nach ein und ausgehenden Abh ngigkeiten Zur Messung der Unabh ngigkeit der Systemkomponenten stehen Metriken zur Verf gung die beispielsweise die durchschnittliche Abh ngigkeit der Komponenten untereinander oder die Anzahl und Gr e von Abh ngigkeitszyklen messen Zur Identifizierung testkritischer Abh ngigkeiten werden f r jede existierende Abh ngigkeit Reduktionsmetriken berechnet deren Wert anzeigt wie sich die Entfernung der Abh ngigkeit auf die Metrikwerte des Gesamtsystems auswirken w rde Unter Verwendung von Design2Test erfolgte im zweiten Teil dieser Arbeit die Testbarkeitsanalyse eines Softwaresystems SeminarlS Auf Grundlage der im Rahmen der Analyse errechneten Metriken wurden aus SeminarlS jene
225. ng C Installation 1 Installation Grundlegende Voraussetzung f r die Installation von Design 2Test ist eine bereits installierte Version des Together Control Centers in der Version 6 0 oder h her Das Installationsverzeichnis das Sie bei der Installation von Together festgelegt haben z B C Programme Together wird im Folgenden als TGH bezeichnet Together erwartet alle Module egal ob Eigen oder Fremdentwicklung in einem fest vorgegebenen Pfad Dieser Pfad lautet STGH modules com togethersoft modules und wird nachstehend als TGH_MODULESS abgek rzt Design2Test steht Ihnen in zwei Varianten zur Verf gung Als selbstextrahierende komprimierte Datei 42t zip f r alle Windows Systeme und als komprimiertes Archiv d2t tar z f r UNIX Linux Plattformen Die Installation der verschiedenen Versionen unterscheidet sich bei beiden Plattformen nicht wesentlich Windows 1 Kopieren Sie die Datei d2t zip in den Ablageort der Together Module STGH_MODULESS 2 Starten Sie den Extraktionsvorgang durch Doppelklick oder rechten Mausklick auf die gezippte Datei d2t zip 3 Entpacken Sie das Archiv in das aktuelle Verzeichnis STGH_MODULESS 4 L schen Sie die Kopie der Datei d2t zip aus dem Verzeichnis TGH_MODULESS UNIX Linux 1 Kopieren Sie die Datei d2t tar z in den Ablageort der Together Module TGH_MODULESS 2 Wechseln Sie in dieses Verzeichnis achten Sie darauf dass Sie Schreibrechte f r dieses Verzei
226. ngigkeiten berhaupt eine Ver nderung der Metriken bewirkt Mit anderen Worten bleibt bei der Entfernung jeder echten Teilmenge dieser acht Abh ngigkeiten der ACD Wert des Systems also unver ndert Maskierungseffekt 57 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Message Pane Message Pane p dpne P SeminarisDatenbank PlLeitungsauftrag 0 1 i 700 SeminarisDatenbank P FirmenSeminarveranstatt SeminarisDatenbank P FirmenSeminarveranstalt o l SeminarisDatenbank P Belegung P SeminarisDatenbank Belegung 0 0 P SeminarisDatenbank 02 P SeminarisDatenbank P Geschaeftspartner Dozertenvereinbarung P DYKostenBerechnenK 5 P SeminarisDatenbank Abbildung 36 Entfernung der Abh ngigkeiten von der Datenbank zur Datenhaltung Nach Entfernung dieser Abh ngigkeiten ergeben sich folgende Projektmetriken Project Metrics without Excluded EN Improvement 9 number of components 273 0 75 02952 89 11439 15 805382 35 0 39 0 10 256409 9 0 5 0 80 0 102 0 106 0 3 7735825 74 0 81 0 8 641975 Me 262 0 160 35496 Abbildung 37 Projektmetriken nach Entfernung der Abh ngi
227. ngsAnzeigeA T_CLASS ExceptionNachricht T_CLASS Class D_INSTANC MeldungsAnzeigeA T_CLASS ExceptionNachricht T_CLASS Member Um den Bezug zur Methode oder zum Attribut das die Abh ngigkeit verursacht nicht zu verlieren wird bei der auf Klassenebene eingef gten Abh ngigkeit eine Referenz auf den Elementknoten gespeichert 155 Anhang Lokale innere Klassen statisch und nicht statisch Java Abh ngiskeiten in besonderem Kontext B 26 Lokale innere Klassen statisch und nicht statisch B 26 1 In nachstehendem Beispiel handelt es sich bei der Klasse UseCaseActionListener um eine innere Klasse der Klasse SachbearbeiteraA Klassen die nicht innerhalb anderer Klassen definiert werden werden nachfolgend als u ere Klassen bezeichnet Bei der Klasse Sachbearbeiter handelt es sich um eine u ere Klasse Erl uterung und Beispiel public class SachbearbeiterA private SachbearbeiterA mainWindow SeminarisH MainWindow protected class UseCaseActionListener implements ActionListener public void actionPerformed ActionEvent event try 1 catch ClassNotFoundException e MeldungsAnzeigeA anzeigen Class missing mainWindow B 26 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP SachbearbeiterA T_CLASS MeldungsAnzeigeA T_CLASS Class D_CALL_ST UseCaseActi
228. nk aus der Kontrollschicht in Abh ngigkeit 9 2 2 Durch den fest verdrahteten Zugriff kann ein von der Datenbank isolierter Test somit nur durch eine nderung der Implementierung in der Klasse ErweitertPersistent oder durch den Austausch der Klasse SeminarisDatenbank stattfinden siehe Abschnitt 10 6 9 2 12 SVKurzS Seminarveranstaltung 9 2 12 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken s 5 3 d_type 106 o 2 8 5 2 2 lt lt Di N 0 0 0 0 0 0 8 abstract class 2 el 0 010 5 1 Abbildung 60 Komponentenmetriken SVKurzS A und Seminarveranstaltung 69 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Auff lligkeiten bei den berechneten Werten Beim Blick auf die Abh ngigkeitsmetriken f llt auf dass es sich hier um eine nicht statische Abh ngigkeit zu einer abstrakten Klasse handelt sub_hw d_type Bemerkenswert ist ferner dass die abh ngige Klasse nur eine sehr geringe Zahl von Abh ngigkeiten besitzt cd und sich darunter keine einzige statische Abh ngigkeit befindet cd_h 9 2 12 2 Bewertung Bei der Klasse SVKurzS handelt es sich um die Kurzform einer Sichtschnittstellenklasse die in fremden Anwendungsf llen Leitungsauftrag erfassen Teilnehmer anmelden zur Zuo
229. nschaulicht wird Daher bleibt die Frage unbeantwortet wie sinnvoll und zweckm ig dieses Konzept f r den Entwurf eines gr eren Projekts sein kann Am Beispiel des Datenbankzugriffs in SeminarlS sollen die Konsequenzen aus dem beschriebenen Vorgehen illustriert werden e SeminarlS erfolgt augenblicklich der Zugriff auf die Datenbank sowohl den Kontrollklassen zur Transaktionssteuerung als auch in der Datenhaltung zur Abfrage oder Manipulation der Datenbasis Die Erzeugung der Kontrollklassen erfolgt in den zum jeweiligen Anwendungsfall geh renden Schnittstellenklassen Geht man davon 110 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung aus dass die Instanz der Datenbank bei der Initialisierung der Anwendung z B in der Hauptschnittstellenklasse erzeugt wird w rde dies bedeuten dass die Hauptschnittstellenklasse bereits jeder Schnittstellenklasse bei deren Erzeugung die Datenbankinstanz als Parameter bergeben muss Die Schnittstellenklassen wiederum reichen die Datenbankinstanz an die Kontrollklassen bei deren Instantiierung weiter Die Kontrollklassen schlie lich reichen die Instanz dann beim Zugriff auf die Datenhaltung an die Entit tsklassen durch Verf hrt man analog auch f r andere globale Basiskomponenten des System Protokollinstanz Druckerinstanz Konfigurationsinstanz so Kann dies in manchen Klassen zu einer wahren Inflation von Konstruktorparametern f hren e Wird die E
230. nsweise F r die Refaktorisierung fallen dabei folgende Aufw nde an Schritt1 5 Minuten e Schritt2 2 Minuten Schritt 3 160 Minuten 11 2 3 Ergebnisse Man erh lt folgende Ver nderung der Projektmetriken LE Metrics RER Hetrics Zerovalue 54 28077 76 0 NSBC 39 0 NCDC 103 0 15 0 60 35496 810 390 106 0 50 53 226925 760 760 139 0 139 0 103 0 1030 70 Abbildung 110 Projektmetriken nach den weiteren Schritten zur strikten Drei Schicht Architektur W hrend der erste Refaktorisierungsschritt die deutlichste Ver nderung brachte f hrte die Entfernung der restlichen Abh ngigkeiten aus der Datenhaltung in die Kontrollschicht nur mehr zu einer kleinen Ver nderung der Testbarkeitsmetriken Das mit dem meisten Aufwand verbundene Beseitigen der 105 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung Abh ngigkeiten aus der Kontrollschicht in die Schnittstellenschicht ergab hingegen keine nennenswerte Ver nderung Die Anzahl der Klassen von denen eine Klasse im Durchschnitt direkt oder indirekt abh ngig ist ist um 10 8 Prozent gesunken beschr nkt auf fest verdrahtete Abh ngigkeiten um 11 8 Prozent Der gro e Abh ngigkeitszyklus in der Datenhaltung wurde in drei kleinere voneinander unabh ngige Zyklen aufgespalten die Anzahl der zyklischen abh ngigen Komponenten hat sich dabei nur unwesentlich verringert Ein Blick au
231. nt Object visitcasestatement bject visitReference Object visitffStatementObject visitLoopStatement bject visit sserSstatement bject visitExpressionListStatementObjg visitEventHandlingStetementObjg Abbildung 7 Weitere Visitor Klassen im Together Open Die Identifizierung aller festgelegten Abh ngigkeiten siehe Abschnitt 5 5 1 kann ber die Implementierung der in diesen Visitor Interfaces zur Verf gung stehenden Methoden abgedeckt werden Die beschriebene Vorgehensweise die am Beispiel der Suche nach Abh ngigkeiten in Methoden aufgezeigt wurde kann analog f r alle anderen Sourcecode Bestandteile verwendet werden Somit sind die Voraussetzungen geschaffen darauf aufbauend den Entwurf der Teilkomponente zur Ermittlung der Abh ngigkeiten erstellen zu k nnen siehe Abschnitt 6 3 5 6 Erzeugung des Abh ngigkeitsgraphen T 3 F r den Entwurf ist die Frage von Bedeutung welche Schnittstellenbeschreibung mproveT im Hinblick auf das Erzeugen und den Aufbau eines Abh ngigkeitsgraphen vorsieht Dies wird in den n chsten beiden Abschnitten beschrieben Im Anschluss daran muss gekl rt werden in welcher Form jede einzelne in Abschnitt 5 5 1 bestimmte m gliche Abh ngigkeit in Java Programmen in geeigneter Weise in den Abh ngigkeitsgraphen eingef gt werden kann Dies wird die Basis f r den sp teren Entwurf siehe Abschnitt 6 4 zur Umsetzung dieser Teilaufgabe sein 16 Kapitel 5 Analyse 5 6 1 Defini
232. nter Verwendung des Together Open API getestet werden Dieser Teilbereich kann also nicht unabh ngig von einer gestarteten Instanz des Together ControlCenter getestet werden so dass das Debug Problem voll zum Tragen kommt e Die Dokumentation der Programmierschnittstelle ist in vielen Teilen sehr knapp gehalten Es gibt zwar einige einfache Beispielmodule die mit dem ControlCenter ausgeliefert werden doch beim tieferen Einstieg in die Modulprogrammierung steht als einziges Hilfsmittel die nicht immer besonders aussagekr ftige javadoc Kommentierung des Open API zur Verf gung 45 Kapitel 7 Implementierung Im Nutzer Forum der Firma TogetherSoft www togethercommunity com finden sich einige kritische Beitr ge zu diesen Problematiken Hierbei ist jedoch zu bedenken dass der Fokus des Together Entwicklungsteams sicher auf der eigentlichen Funktionalit t von Together und nicht auf der Unterst tzung der Programmierschnittstelle liegt An verschiedenen Stellen der Implementierung traten auch noch andere Unzul nglichkeiten des Together Open API zu Tage So mussten beispielsweise in der Version 5 02 von Together anonyme Klassen aus der die Klasse erzeugenden new Anweisung noch manuell extrahiert werden Mit der Version 6 0 wurde das Interface SciJavaHelper allerdings um eine Methode anonymousClasses SciClass mit der gew nschten Funktionalit t erweitert Diese nderung f hrte aber vermutlich dazu dass ab der Version 6 0 innerha
233. nz null Standard Konstruktor soll nicht mehr genutzt werden protected SeminarisDatenbank int dbms 1 Liefert die einzige Instanz der Seminaris Datenbank synchronized static SeminarisDatenbank getEinzigelnstanz Durch den paketlokalen Zugriffsmodifikator kann verhindert werden dass au erhalb des Paketes ein direkter Zugriff auf das Einzelst ck der Datenbank erfolgt F r die Ersetzbarkeit der Datenbank in der Testumgebung ist ferner Voraussetzung dass beim Zugriff auf die Providerklasse als R ckgabewert lediglich ein Interfacetyp zugesichert wird So kann jede beliebige Implementierung dieses Interfaces als aktuell zu verwendende Datenbank gesetzt werden W hrend bei den brigen SeminarlS Basiskomponenten die Implementierung des Interfaces trivial ist muss zur Verkapselung der externen Rahmenwerksklasse persistenz Datenbank das Interface ISeminarisDatenbank zus tzlich als Adapter fungieren Dies erfolgt unter Ausnutzung der in Java vorhandenen M glichkeit dass gleich lautende Methodensignaturen in Superklassen und implementierten Interfaces vorhanden sein d rfen persistenz Datenbank MYS L int ACGESS int INSTANTDB iint interface ISeminarisDatenhank Datenbank schliessen void schliessenvold starteTransaktion void starteTransaktion vold istGeoeffnet boolean istGeoeffnet boolean commitTransaktion void commiTransaktion void roll
234. ogether IJ 10 5 5 Ermittlung von Abh ngigkeiten 21 11 5 6 Erzeugung des Abh ngigkeitsgraphen 3 2 16 5 7 Export des Abh ngigkeitsgraphen und Start der Metrikberechnung 4 20 5 8 Anzeige der Testbarkeitsmetriken 31 21 6 2 DCH EE 24 i 24 6 2 Erweiterung von Together class Design2Test nennen 24 6 3 Komponente Abh ngigkeitssuche package 25 6 4 Komponente Abh ngigkeitsgraph package 28 6 5 Komponente Analysesteuerung package analysis 29 6 6 Komponente Metrikauswahl package 050 29 6 7 Ausgabekomponenten package results 30 6 8 Komponente Modulkoordination class D2TMediator neeeneene 34 6 9 Abschlie endes Klassendiagramm des Entwurfs 37 IMP EMENT ERUN G 38 7 1 EE EE 38 72 Erweiterung von Together class Desion 2fest 38 73 Komponente Abh ngigkeitssuche package 38 7 4 Komponente Abh ngigkeitsgraph package dote 41 7 5 Komponente Analysesteuerung package analysis 42 7 6 Komponente Metrikauswahl package 43 7 7 Ausgabekomponenten package results 43 7 8 Komponente Modulkoordination class D 3TMedioior 44 7 9 Probleme der Jnnplementierunge
235. ogrammkomponenten auftreten und wie kann der Zugriff ber das Together Open API auf diese Elemente erfolgen Die Antworten auf diese Fragen werden in den n chsten Abschnitten beschrieben 11 Kapitel 5 Analyse 5 5 1 bersicht m glicher Abh ngigkeiten Java Programmen Die wichtigsten Entscheidungen die bei der Bestimmung der im Rahmen der Testbarkeitsanalyse zu ber cksichtigenden Abh ngigkeiten zu treffen waren sind nachstehend aufgelistet e Alle Abh ngigkeiten innerhalb von inneren und anonymen Klassen werden analog zu den Abh ngigkeiten der sie umschlie enden Klassen ber cksichtigt Dies umfasst beispielsweise auch Vererbung und Implementierung eines Schnittstellentyps bei der Definition von anonymen Klassen e In den Bl cken von statischen und Instanz Initialisierern k nnen ebenfalls Abh ngigkeiten auftreten Diese finden in geeigneter Weise Ber cksichtigung Alle Abh ngigkeiten zu Java Basistypen int boolean bleiben unber cksichtigt Im Rahmen der Testbarkeit sind diese Typen ohne Einfluss da sie zum Sprachumfang von Java geh ren und somit w hrend der Kompilierung in jedem Falle verf gbar sind Together liefert in seinem Modell auch ausschlie lich Referenzen auf Klassentypen wie beispielsweise String oder auch auf die Wrapperklassen f r primitive Datentypen Integer Boolean e Abh ngigkeiten zwischen Attributen und Methoden innerhalb derselben Klasse werden ber cksichtigt Damit wird
236. omponenten werden weder auf Abh ngigkeiten analysiert noch als Ziel von Abh ngigkeiten ber cksichtigt Um Komponenten auszuschlie en klicken Sie auf die kleine Schaltfl che neben dem Textfeld Es ffnet sich folgendes Auswahlfenster Select Packages EN Available content Existing and or ready to add elements TA Model evalustedependencie Data Gui Konfiguration Search SR evalustedepende EvalusteDepende lt lt lt lt TA SearchiClasspath Favorites lt lt Remove lt lt Abbildung 16 Ausschluss von Komponenten Ihnen werden alle Pakete und Klassen des eigenen Projektes angezeigt Andere Komponenten z B Diagramme oder Komponenten aus dem Classpath sind f r Sie an dieser Stelle nicht sichtbar W hlen Sie die Komponenten des Projekts im Dialog als Model bezeichnet aus die nicht nach 181 Anhang Erweiterte Funktionen und Einstellungen Abh ngigkeiten durchsucht werden sollen Bet tigen Sie die Schaltfl che Add um die auszuschlie enden Komponenten der Liste auf der rechten Seite hinzuzuf gen Sobald Sie Ihre Auswahl getroffen haben klicken Sie auf die Schaltfl che Ok 6 1 4 2 Komponenten als Ziele von Abh ngigkeiten hinzuf gen Im unteren Teil des Dialogs gt Abbildung 15 Analyze Options Dialog k nnen Sie einzelne Pakete und Klassen die im Classpath liegen als Ziel von Abh ngigkeiten
237. onListener T_INRCL MeldungsAnzeigeA T_CLASS Class D_USES_ST UseCaseAtctionListener T_INRCL SachbearbeiterA T_CLASS Member D_CALL_ST actionPerformed T_METHOD_ anzeigen T_METHOD Member D_USES_ST actionPerformed MainWindow T_FIELD Innere Klassen werden auf Member und Klassenebene wie eine eigenst ndige Klasse behandelt Auf Summary Ebene wird die innere Klasse als Bestandteil der u ersten Klasse betrachtet so dass e Abh ngigkeiten von der inneren zu ihrer u eren Klasse als klasseninterne Abh ngigkeit auf Summary Ebene verschwinden und alle anderen Abh ngigkeiten von der u eren Klasse ausgehend modelliert werden B 27 Anonyme innere Klassen Anonyme innere Klassen werden v llig analog zu benamten inneren Klassen behandelt Die einzige Besonderheit ist dass f r anonyme Klassen ein eindeutiger Name generiert werden muss So wird beispielsweise eine anonyme Klasse der Klasse SachbearbeiterA mit SachbearbeiterA anonym_class_ bezeichnet wobei f r die fortlaufende Nummerierung der anonymen Klassen innerhalb einer Klasse steht 156 Anhang Statischer Konstruktor Initialisierer B 28 Statischer Konstruktor Initialisierer B 28 1 Erl uterung und Beispiel Sofern m glich sollte die Initialisierung der statischen Attribute sofort bei der Deklaration erfolgen Wird dies bei einer komplexen Initialisierung in einem statischen Konstruktor static initializer durch
238. orgesehen die neben dem eigentlichen Ansto en der Metrikberechnung in mproveT auch die Erzeugung des Abh ngigkeitsgraphen und die der Grapherstellung obligatorisch vorausgehende Suche nach Abh ngigkeiten steuert Den Zugriff auf die in Abschnitt 5 7 1 beschriebenen mproveT Module VersionAnalysis undNodeAnalysis verkapseln die beiden Klassen VersionAnalyzer undNodeAnalyzer ComputeMetrics ProgressListener Node Analyzer selectedEdgeMetricClassNames Yector selectedNodeMetricClassNames Vector ProgressListener analyzeOptions AnalyzeOptions VersionAnalyzer logging Logging versionAnalyzer VersionAnalyzer versionAnalysis VersionAnalysis nodeAnalyzer NodeAnalyzer graphToAnalyze ExtendedGraph metricClassNames Vector progress ldeProgress isCancelled boolean nodeAnalysis NodeAnalysis graphToAnalyze ExtendedGraph metricClassNames Vector progress ldeProgress isCancelled boolean ComputeMetrics start void getyersion Analysis YersionAnalysis getNodeAnalysis NodeAnalysis NodeAnalyzer analyze void getNNodeAnalysis NodeAnalysis startProgress void setCountProgress void isCancelProgressRequested boolean stopProgress void isCancelled boolean VersionAnalyzer analyze void getVersionAnalysis VersionAnalysis startProgress void setCountProgress void isCancelProgressRequssted boolean stopProgress void isCancelled boolean Abbild
239. partnerRelation SV AnsprechpartnerPaar 9 2 16 1 Ergebnisse der Metrikberechnung pk lis_feedb rACD 5 2 D 10 1 2 0 0 0 9 0 create and access Abbildung 67 Abh ngigkeitsmetriken SV AnsprechpartnerRelation SV AnsprechpartnerPaar Int _ lcd hi o ed_h_is vw ed_h_s ed 6 EH _ cd_im_h cd_tr LACH rACD_out Abbildung 68 Komponentenmetriken SV AnsprechpartnerRelation A und SV AnsprechpartnerPaar Auff lligkeiten bei den berechneten Werten Die rACD Werte der Klasse SVAnsprechpartnerRelation liegen deutlich ber dem rACD Wert der Abh ngigkeit 72 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 9 2 16 2 Bewertung Die beiden beteiligten Klassen resultieren aus der transformierten Assoziation zwischen einer Seminarveranstaltung und einer als Ansprechpartner fungierenden Person Die Bewertung der Abh ngigkeiten zwischen Relationen und Paarklassen wurde bereits bei Abh ngigkeit 9 2 14 vorgenommen 9 2 17 RechnungsempfaengerRelation RechnungsempfaengerPaar 9 2 17 1 Ergebnisse der Metrikberechnung pk 2 2 0 olis_int cd_is_tr 2 4 3 e 62 2 9 2 3 OI 4 0 89 65 6211 0 0 4 Abbildung 70 Komponentenmetriken RechnungsempfaengerRelation A und RechnungsempfaengerPaar B Auff lligkeiten bei
240. pboase 45 A LEE 46 ii TEIL FALLBEISPIEL r0202000000000000000000000r000000en0nsnnesnensensnnsnennesnessersnnsnnsnsssernansnnen 47 8 EINF HRUNG 4 N lerne 47 6 17 EE een ee ee 47 8 2 Beschreibung des zu analysierenden Softwaresystems 9 49 9 TESTBARKEITSANALYSE AUSGEW HLTER ABH NGIGKEITEN 50 91 TEE 50 92 Top FACD Abh ngigkeiten n eniansciksnakunitambansisewtannlansninhlah 52 9 3 Adaption der Testborkeitemetriken nennen 84 10 ENTWURFSPROBLEME UND 00 0 2 0 6 1010000 0000 20 2 85 10 1 de 85 10 2 Entwurfs berblick 15 86 10 3 Verletzung der Drei Schicht Architektur 90 10 4 Zugriff auf Kontrollschicht durch Basiekomponenten 93 10 5 Zugriff auf Datenhaltung durch Basiskomponente 94 10 6 Zugriff auf globale 96 10 7 Realisierung der Dom nenklassen als Fassaden 98 10 8 Erzeugung der Schnittstellenklassen 102 11 ENTFERNUNG TESTKRITISCHER ABH NGIGKEITEN DURCH 104 11 1 EE 104 11 2 Realisierung einer strikten Drei Schichten Architektur 104 11 3 Kein externer Zug
241. piel beschreibt die Verwendung des entwickelten Werkzeugs bei der Testbarkeitsanalyse der Abh ngigkeiten eines gegebenen Softwaresystems Zun chst wird in Kapitel 8 f r diesen Teil der Arbeit wiederum die Aufgabenstellung aus Kapitel 2 pr zisiert und das zu analysierende Softwareprojekt vorgestellt Begonnen wird die Testbarkeitsanalyse in Kapitel 9 mit der Ermittlung der Testbarkeitsmetriken des zu untersuchenden Softwaresystems Auf Basis der erhaltenen Ergebnisse werden 30 testkritische Abh ngigkeiten f r eine n here Untersuchung ausgew hlt Im Rahmen der Untersuchung erfolgt eine Beschreibung der Ursachen der Abh ngigkeit und eine Bewertung der Abh ngigkeit unter dem Gesichtspunkt der Testbarkeit In Kapitel 10 erfolgt eine Untersuchung der Entwurfsprobleme die bei der Analyse in Kapitel 9 als Hauptursachen f r Testprobleme ermittelt wurden Es werden verschiedene Entwurfsprobleme wie die Verletzung von Hierarchien in Schichtenstrukturen der Zugriff auf globale Basiskomponenten oder die Fassadenfunktion der Dom nenklassen und ihre jeweiligen Auswirkungen auf die Testbarkeit im Detail beschrieben Nach der Untersuchung und Beschreibung der Entwurfsprobleme werden in Kapitel 11 Ans tze f r die Beseitigung der Entwurfsprobleme durch eine Ver nderung der Implementierung beschrieben Auf Basis dieser Ans tze erfolgt die Refaktorisierung des untersuchten Softwaresystems und die Bestimmung der hierf r erforderlichen Aufw nde Den
242. ponenten Pakete Klassen abw hlen die bei der Suche nach Abh ngigkeiten weder durchlaufen noch als Ziel von Abh ngigkeiten ber cksichtigt werden sollen Er Kann ferner Komponenten aus dem Klassenpfad seines Projektes ausw hlen die als zus tzliche Ziele von Abh ngigkeiten erkannt werden sollen postcondition end Suchoptionen einstellen A 2 5 Anwendungsfall Navigation zum Sourcecode use case Navigation zum Sourcecode actors Together Benutzer precondition Eine Testbarkeitsanalyse wurde durchgef hrt Der Benutzer befindet sich in der Anzeige der Abh ngigkeits oder Komponentenmetriken main flow Der Benutzer l sst sich den Teil des Sourcecodes anzeigen der Ausl ser f r eine Abh ngigkeit ist Hierzu wird die Klasse mit der Abh ngigkeit im Texteditor von Together ge ffnet und die betreffende Stelle hervorgehoben Analog k nnen auch alle in den Metriktabellen aufgelisteten Komponenten im Texteditor von Together ge ffnet werden postcondition Die ausgew hlte Abh ngigkeit oder Komponente ist im Texteditor von Together ge ffnet Wurde zum Ursprung einer Abh ngigkeit navigiert so ist die entsprechende Textstelle hervorgehoben end Navigation zum Sourcecode 136 Anhang Textuelle Anwendungsfallspezifikationen A 2 6 Anwendungsfall Navigation zu Klassendiagramm use case Navigation zu Klassendiagramm actors Together Benutzer precondition Eine Testbarkeitsanalyse wurde durchgef hrt Der Benutz
243. r In der abschlie end realisierten Version wird der Abh ngigkeitsgraph deshalb bereits w hrend des Durchlaufs durch die Together Repr sentation des Sourcecodes und der Ermittlung der Abh ngigkeiten erzeugt Dies f hrt zu keinerlei Nachteilen Um den Fehler ferner bei der Anzeige der Testbarkeitsmetriken und der dort angebotenen M glichkeit zur Navigation zum Sourcecode ebenfalls zu umgehen wurde die Implementierung der Klasse SourceCodeReference zus tzliches Attribut String sourceCodeFileName erweitert Dadurch kann auch an dieser Stelle der Zugriff auf das nicht mehr referenzierte Element zur Bestimmung des Dateinamens vermieden werden 7 10 Fazit Im Hinblick auf die Komplexit t der Realisierung lag der eindeutige Schwerpunkt auf der Erkennung und Ermittlung der im Vorfeld festgelegten Abh ngigkeiten ber das Together Open API Bei der Analyse bestimmter Programmteile und der Erkennung einzelner Abh ngigkeiten ergaben sich teilweise nur mit erheblichem Aufwand in den Griff zu bekommende Probleme Ein weiterer aufw ndiger Teil der Implementierung der mehrfach einen R ckschritt in die Entwurfsphase und eine berarbeitung des Entwurfs erforderte war die Synchronisation und Verkn pfung der Ausgabekomponenten Hier ergab sich erst durch die Verwendung eines geeigneten Design Patterns eine Reduzierung der in diesem Zusammenhang aufgetretenen Probleme 46 Kapitel 8 Einf hrung Teil Fallbeispie
244. r ber hinaus auch eine Abh ngigkeit vom Anwendungsfall Seminarveranstaltung erfassen zum Anwendungsfall Zeitungsauftrag erfassen besteht f hrt dies sogar zu einer zyklischen Abh ngigkeit der Schnittstellenklassen beider Anwendungsf lle Die umgekehrte den Zyklus schlie ende Verkn pfung erfolgt durch Abh ngigkeit 9 2 5 SVAendernErfassenAA LeitungsauftragAuswaehlenAA 65 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 9 2 8 DVKostenBerechnenK DozentenvereinbarungLoeschenK 9 2 8 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken D x 9 5 z DI 16 1 41 d_type E N 2 2 8 2 lt lt lt lt lt lt 2 0 0 1 1 E lt 50 Of 5 0 4 89 e e 8 8 7 8 100 0 10 0 ja 9 89 65 62 1 8 1 2 Abbildung 52 Komponentenmetriken DVKostenBerechnenK und DozentenvereinbarungLoeschenK Auff lligkeiten bei den berechneten Werten Die Abh ngigkeit beruht nur auf einem allerdings fest verdrahteten Zugriff sub_hw subedges Die rACD Werte der Klasse DVKostenBerechnenK liegen massiv h her als der rACD Wert der Abh ngigkeit Die Anzahl der von DozentenvereinbarungLoeschenK ausgehenden Abh ngigkeiten liegt bei einem sehr hohen Wert 9 2 82 Bewertung In der Anforderungsspezifikation war das Protokollieren von L schvorg ngen gefordert Somit existiert in jed
245. r Initialisierung werden derzeit doppelt erkannt Die mehrfache Speicherung der Abh ngigkeiten erfolgt allerdings nur auf Member Ebene Zeilenumbruch in Import Anweisungen Befindet sich in einer import Anweisung ein Zeilenumbruch so ist Together nicht in der Lage Abh ngigkeiten zu der mit diesem Statement importierten Klasse und deren Elementen zu erkennen Befindet sich also beispielsweise im Rumpf der Klasse der Aufruf einer Methode einer dergestalt importierten Klasse wird vom Together Open API als Referenz auf diese Methode ein null Wert geliefert Gleichwohl verl uft der Kompiliervorgang auch bei Zeilenumbr chen ohne Probleme Umlaute in Bezeichnern Die Verwendung unterschiedlicher Parser beim Kompiliervorgang und beim Durchlaufen des Sourcecodes im Together Open API zeigt sich auch bei der Verwendung von Umlauten in Bezeichnern Laut Java Spezifikation sind Unicode Bezeichner zul ssig und die Kompilierung erfolgt in diesen F llen auch ohne Fehler in Together Beim Parsen des Projektes im Rahmen der Suche nach Abh ngigkeiten liefert das Together Open API jedoch Fehlermeldungen ber syntaktisch fehlerhaften Code 161 Anhang B Zusammenfassung Zusammenfassung Abschlie end soll ein berblick ber alle in den vorausgehenden Abschnitten definierten Abh ngigkeiten gegeben werden Die nachfolgende Graphik ordnet die Abh ngigkeiten ferner den Ebenen des Graphen zu in denen sie auftreten k nnen Die selbe Zuordnung erfolgt
246. r verf gbaren Komponentenmetriken 167 Anhang Metrikauswahl 2 W hlen Sie die Metriken die Sie berechnet und angezeigt haben m chten indem Sie in der jeweils letzten Spalte der Metriktabellen das Auswahlfeld aktivieren Um zu einer der Metriken im unteren Teil des Dialogs eine kurze Erl uterung zu erhalten klicken Sie bitte einfach in die zugeh rige Zeile der Tabelle F r die Berechnung von Abh ngigkeitsmetriken wie auch f r die Berechnung von Komponentenmetriken muss in der jeweiligen Tabelle mindestens eine der Metriken ausgew hlt sein Haben Sie keine Auswahl getroffen erhalten Sie einen entsprechenden Hinweis Die beiden Schaltfl chen Select All und Unselect All k nnen Sie zur Auswahl aller Metriken bzw dem kompletten Zur cksetzen einer durchgef hrten Auswahl nutzen Eine Beschreibung der w hrend der Metrikauswahl zus tzlich vorhandenen Funktionalit t wie das Setzen Speichern und Laden von Metriken sowie der Analyseoptionen erhalten Sie in den Abschnitten 6 1 1 Setzen der Default Metrikauswahl 6 1 2 Speichern einer Metrikauswahl und 6 1 3 Einlesen einer gespeicherten Metrikauswahl des Kapitels 6 Erweiterte Funktionen und Einstellungen 3 Sobald Sie mit der Auswahl der Metriken fertig sind und auch keine weiteren Einstellungen vornehmen wollen klicken Sie auf die Schaltfl che Start Damit wird die Berechnung der Metriken angesto en 168 Anhang Anzeige der Metriken 4 Anzeige der Metri
247. rdnung einer Seminarveranstaltung genutzt wird Die vorliegende Abh ngigkeit verl uft zu der von ihr angezeigten Dom nenklasse Seminarveranstaltung Dieser Abh ngigkeit liegt eine durchaus bliche und auch empfohlene Vorgehensweise zugrunde SWEII99 Die bergabe der zu pr sentierenden Seminarveranstaltung erfolgt als Parameter an die Klasse SVKurzS Da es sich beim Typ des bergabeparameters um eine abstrakte Klasse handelt scheint auf Anhieb durch eine nderung der Implementierung keine Verbesserung der Testbarkeit erreichbar 9 2 13 MeldungsAnzeigeA ExceptionNachrichtA 9 2 13 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken d_type dep_comp olis_feedb create and access o S 5120 O 3 0 59 85 2 9 2 3 2 2 0 1 0 0 0 Abbildung 62 Komponentenmetriken MeldungsAnzeigeA A und ExceptionNachrichtA Auff lligkeiten bei den berechneten Werten Die Klasse ExceptionNachrichtA geh rt zu den Klassen mit den wenigsten direkten und indirekten Abh ngigkeiten im System cd_fr 9 2 13 2 Bewertung Bei den Klassen MeldungsAnzeigeA und ExceptionNachrichtenA handelt es sich um Schnittstellenklassen zur Ausgabe von Hinweisen und Fehlermeldungen Die Klasse ExceptionNachrichtenA wird ausschlie lich von der Klasse MeldungsAnzeigeA genutzt um die Ausgabe der Fehlermeldung in abgewandelter Form vorzunehmen 70 Kapit
248. rechende Verweise untereinander verbunden werden So k nnen beispielsweise einem Knoten auf Klassenebene alle seine in der Memberebene als Knoten gespeicherten Attribute und Methoden in einer Datenstruktur als Unterknoten zugeordnet werden Dasselbe gilt f r die Zuordnung der Abh ngigkeiten der tiefer liegenden Ebene zu der aggregierten Abh ngigkeit auf der jeweils unmittelbar benachbarten h heren Ebene Diese Vernetzung der einzelnen Graphebenen bietet die M glichkeit ausgehend von einer Abh ngigkeit und den daran beteiligten Komponenten auf den h heren Ebenen eine verfeinernde Darstellung der verursachenden Abh ngigkeiten bis hin zur untersten Ebene des Graphen zu erhalten 17 Kapitel 5 Analyse 5 6 2 Einf gen der Abh ngigkeiten und Komponenten den Graph Nach der Definition der verschiedenen Ebenen des Abh ngigkeitsgraphen durch mehrfachen Aufruf der Methode void addLevel int LevelNumber String levelName des Abh ngigkeitsgraphen k nnen auf den dadurch festgelegten Ebenen die dort anzusiedelnden Knoten Komponenten und Kanten Abh ngigkeiten eingef gt werden Bei den Knoten und Kanten des Graphen handelt es sich um Instanzen die die Interfaces Node und Edge als Typen implementieren Nachfolgend Ausschnitte aus den Klassendiagrammen der beiden Typen Die zwischen den Klassen und Interfaces vorhandenen Assoziationen und Abh ngigkeiten spiegeln die Struktur des entstehenden Abh ng
249. rf gung stehenden Typen sind im Interface GraphTypes von definiert Um die im einleitenden Abschnitt bereits beschriebene Verbindung der verschiedenen Ebenen des Graphen modellieren zu K nnen stellen die Interfaces Edge und Node die Methoden void addSubEdge Edge subEdge void setSuperEdge Edge superEdge void addSubNode Node node void setSuperNode Node node bereit Bei der Integration von mproveT in das Together ControlCenter kommt ferner der Eigenschaft eine wichtige Bedeutung zu beliebige Objekte im Rahmen dieser Arbeit werden dies Objekte des Together Open API sein als Inhalt der Kante bzw des Knotens speichern zu k nnen Hierf r existiert in beiden Interfaces die Methode void addContent Object content 5 6 3 Modellierungsaspekte der Java Abh ngigkeiten im Graphen Die bereits in Abschnitt 5 5 1 eingef hrte bersicht Anhang B ber alle in einem Java Programm m glichen Abh ngigkeiten wurde zur L sung dieser Frage um die konkreten Modellierungsaspekte jeder Abh ngigkeit erweitert Die wichtigsten Grundlagen der Modellierung sind nachstehend noch mal in komprimierter Form zusammengefasst e Abh ngigkeiten zwischen zwei Klassenelementen members werden auf Memberebene als eigenst ndige Abh ngigkeit gespeichert Gleiche Typen von Abh ngigkeiten in der Memberebene werden in der Klassenebene zu einer Abh ngigkeit zusammengefasst e Eine Ausnahme hiervon bild
250. riff auf Kontrollschicht 106 11 4 Kein externer Zugriff auf 108 11 5 Ver nderter Zugriff auf globale 1 109 11 6 Direkter Zugriff auf Ordner und Relottonen 115 11 7 Einf hrung einer 1 119 TEIL 0 EE 126 12 ZUSAMMENFASSUNG tn EE E 126 13 AUSBLICK En a en 129 5 130 ANHANG A ANWENDUNGSF LLE TESTBARKEITSANALYSE ENEE sess 132 ANHANGB BERSICHT JIANA ABHANGIGKEITEN REENEN 140 ANHANG BENUTZERHANDBUCH 2 163 iii Kapitel 1 Abh ngigkeiten und Testbarkeit Teil I Einleitung Im ersten Teil dieser Arbeit wird der Zusammenhang von Testbarkeit eines Softwaresystems und den im System vorhandenen Abh ngigkeiten beschrieben und ein Weg gezeigt wie der Einfluss von Abh ngigkeiten auf die Testbarkeit mit Hilfe von Metriken eingesch tzt werden kann Hierzu werden die Begriffe Testbarkeit und Abh ngigkeiten definiert und darauf aufbauend ein Konzept zur Identifizierung testkritischer Abh ngigkeiten beschrieben Ein berblick ber die Aufgabenstellung und ber den Aufbau der Arbeit schlie t diesen Teil ab 1 Abh ngigkeiten und Testbarkeit 1 1 Te
251. rma T_INTERF Class D_RETURN Person T_CLASS IFirma T_INTERF Member Um den Bezug zur abh ngigkeitsverursachenden Methode nicht zu verlieren wird bei der auf Klassenebene eingef gten Abh ngigkeit eine Referenz auf den Methodenknoten gespeichert 145 Anhang Typspezifikation in der throws Klausel einer Methode B 6 Typspezifikation der throws Klausel einer Methode B 6 1 Erl uterung und Beispiel Zeigt eine Methode durch Angabe einer Ausnahme in ihrer throws Klausel an dass sie eine bestimmte Exception nicht selbst behandelt sondern diese an die aufrufende Methode weitergibt so wird hierdurch eine Abh ngigkeit vom Typ D_THROWS definiert public class Person extends Geschaeftspartner implements IPerson public static IPerson getObjekt String einSchluessel throws UngueltigerSchluesselException DatenbankAusnahme B 6 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP Person T_CLASS UngueltigerSchluesselException T_CLASS Class D_THROWS Person T_CLASS UngueltigerSchluesselException T_CLASS Member Um den Bezug zur abh ngigkeitsverursachenden Methode nicht zu verlieren wird bei der auf Klassenebene eingef gten Abh ngigkeit eine Referenz auf den Methodenknoten gespeichert B 7 Typ eines Parameters in einem catch Block B 7 1 Erl uterung und
252. rnen der Abh ngigkeiten unterschied sich nach dem Grad der Gesch ftslogik die in den zu refaktorierenden Fassadenmethoden vorhanden war Weitestgehend problemlos verlief die Entfernung derjenigen Methoden die sich auf ein Durchreichen des Methodenaufrufs in die Ordner oder Relationenklassen beschr nkten In diesen F llen konnte in der Entit tsklasse die implementierte Methode und in der zugeh rigen Interface Klasse die Deklaration der Methode entfernt werden Alle Zugriffe auf die Methode wurden ersetzt durch direkten Aufruf der Methoden in den Ordner und Relationenklassen Der Aufwand f r die Refaktorisierung betrug in etwa 6 gt Stunden und ergibt sich aufgeschl sselt nach Komponenten aus nachfolgender bersicht Refaktorierte Klasse jeweils einschlie lich NYfwand implementiertes Interface Minuten Belegung 30 Firma 45 FirmenSeminarveranstaltung 50 Geschaeftspartner 15 Leitungsauftrag 20 OeffentlicheSeminarveranstaltung 30 Person 105 Seminartyp 35 Seminarveranstaltung 50 Dozentenvereinbarung 10 Gesamt 390 Abbildung 119 Aufwand f r Entfernung von Methoden ohne Logik Wesentlich aufwendiger gestaltete sich die Entfernung aller Methoden bei denen der Aufruf der Methoden der Ordner und Relationenklassen in zus tzliche Logik eingebettet waren Nachteilig 116 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung wirkte sich an dieser Stelle aus dass innerhalb der Entit
253. rst ndnis wird nachstehend bereits vorab ein berblick ber die aus dem Entwurf zur Erledigung der Teilaufgaben resultierenden Komponenten gegeben Neben der Zuordnung der Komponenten zu den Teilaufgaben ergibt sich ein erster Eindruck ber die Struktur und die Abh ngigkeitsbeziehungen der entworfenen Komponenten Modulkoordination Metrikauswahl Analysesteuerung Export des bh ngigkeitsgraphen und Start der Metrikberechnung 4 DI Anzeige der Ausgabekomponenten Testbarkeitsmetriken 5 t ere Abh ngigkeitsgraph Abh ngigkeitssuche Abbildung 12 berblick ber die Teilkomponenten der Together Erweiterung Erzeugung des Abh ngigkeitsgraphen 3 Ermittlung von Abh ngigkeiten T 2 Vor der Beschreibung der Teilkomponenten erfolgt zun chst noch die Kl rung der Frage wie die Integration der zu realisierenden Funktionalit t in Together erfolgen kann 6 2 Erweiterung von Together class Design2Test Together bietet verschiedene Stufen der Integration einer Erweiterung ber seine Programmierschnittstelle an Ein Together Modul kann bereits beim Start von Together geladen werden und dem Anwender damit bereits unmittelbar nach dem Hochfahren des System zur Nutzung zur Verf gung stehen Alternativ bietet Together noch zwei verschiedene Formen der sp teren Aktivierung des Moduls durch den Anwender nach dem Start des ControlCenters 24 Kapitel 6 Entwurf
254. rstellung der Abh ngigkeiten 33 Kapitel 6 Entwurf MyObserver javax swing JComponent ShowGraphDialog ImproveT gui TopologicalGraphView dialog JDialog GraphviewMouseHandler rootPane JPanel ShowGraphMouseHandler graphview TopologicalGraphview graph ExtendedGraph _graphYview TopologicalGraphview mediator D2TMediator colorSchemastatus int ShowGraphDialog gt ShowGraphMouseHandler createDialog yoid mousePressed void showGraph void mouseReleased void createRootPane void showPopupMenu void closeDialog void repaint void update void updateForEdge void SaveGraphXmiDialog updateForNode void SaveGraphlmageDialog graphview TopologicalGraphview SaveGraphlmageDialog open void open void Abbildung 22 Graphische Darstellung der Abh ngigkeiten package results graph Die Klasse ShowGraphDialog bindet die von mproveT bereit gestellte Graphanzeige TopologicalGraphView in Together ein Die Klasse ShowGraphMouseHandler zeichnet verantwortlich f r das Bereitstellen des Kontextmen s in der Graphanzeige die brigen Klassen realisieren die zur Speicherung des Graphen im Kontextmen angebotene Funktionalit t 6 8 Komponente Modulkoordination class D2TMediator Aus den verschiedenen Details der die funktionalen Anforderungen beschreibenden Anwendungsf lle siehe Abschnitt 4 2 ergibt sich ein Komplexes Zusammenwirken der einzelnen Teilmodule e
255. rzeugung der globalen Ressourcen bei der Initialisierung der Anwendung vorgenommen so erfolgt dies unter Umst nden lange vor der erstmaligen Nutzung oder m glicherweise sogar ohne eine sp tere Verwendung der Basiskomponente e k nnte aufgrund der vorstehenden Anmerkungen versucht sein die globalen Basiskomponenten erst bei konkretem Bedarf in der Anwendung zu erzeugen So k nnte sich beispielsweise eine Kontrollklasse die Datenbankinstanz erst unmittelbar vor dem Aufruf einer Datenhaltungsklasse mit Datenbankzugriff besorgen Dann landet man aber wieder beim Ausgangsproblem wie ein globaler Zugriff auf die Datenbankinstanz an dieser Stelle am g nstigsten erfolgen sollte Unter Abw gung aller F r und Wider scheint das beschriebene Konzept der Parameter bergabe in Verbindung mit der Definition des Parameters als Interfacetyp dennoch ein gut geeignetes Instrument f r den Umgang mit Basiskomponenten zu sein Aus den Erfahrungen mit SeminarlS scheint ein Nachteil lediglich zu sein dass das Konzept an beliebigen Stellen der Anwendung durch direkten Zugriff auf die Basiskomponenten umgangen werden kann F r die Refaktorisierung von SeminarIS kommt es auch deshalb nicht zur Anwendung weil die dort vorhandene Struktur zu einem sehr hohen Refaktorisierungsaufwand bei der Umsetzung dieses Musters f hren w rde 11 5 2 3 Verwendung des Entwurfsmusters Factory zur Objekterzeugung Ein verbreiteter Ansatz um Unabh ngigkeit von der Objekt
256. s 26 Kapitel 6 Entwurf MyBaseVisitor dependencySearchListener Depe setDependencySearchListener vo notifyListenerDependencyFound notifyListenerClassFound void notifyListener perationFound voig getCompleteExpressionText Strinl 1 SciElementlisitor SciStatementl isitor GraphTypes GraphTypes MyElementYisitor MyStatementYisitor dependentElement SciElement dependentClass SciClass expressionYisitor MyExpressionvig referenceYisitor MyReferencewisitg setDependents void statemnentYisitor MyStaternentyisit yisitStatement bject yisit ssertStatement bject yisitElement Object visitCaseStatenent bject visitVariable Object E pas visitCompoundStatement Object visitFunction Object visitEventHandlingStatement Objec visitParameter Object yisitExpressionListStatement Objec yisitInheritance Object visitExpressionStaternent Object visifThrowSpecifier Object referencevisitor MyReferencevisitd visitlfStatement Object visitClass Object newExprRefvisitor MyNewExpress visitLoopStatement Object yisit ttribute Object visitReturnStatement Object visitOperation Object yisitSwitchStatenent Object yisitinitializer Object yisitThrowStaternent Object setSearchScope void yisitTryStatement Object yisitCatehBlockStatement bject yisitDeclarationStatenent Object initializerNumber int searchScope SearchScope SciExpressionl lisitor dependentElemen
257. sTableMouseListener getNodeSelections Yector SmallButton AnalyzeOptionsDialog createDialog void createRootPane void createOptionsPane JPanel createlnputPane JPanel SaveMetricSelectionDialog u closeDialog void showModelElementsSelectorDialog Vector showClasspathElementsSelectorDialog vecto showElementsSelectorDialog Yector Abbildung 18 Benutzerschnittstelle zur Auswahl der Testbarkeitsmetriken Bei der Klasse SelectMetrics handelt es sich um die zur Schnittstellenklasse SelectMetricsDialog geh rende Kontrollklasse Sie stellt Zugriffsmethoden zur Verf gung um die zuletzt ausgew hlten Metriken abfragen zu k nnen Im Unterpaket tables erfolgt die Bereitstellung der zur Auswahl vorgesehen Metriken Auf die Beschreibung des Designs der Oberfl chen wird innerhalb dieser Arbeit verzichtet Das Aussehen der entworfenen Benutzerschnittstellen kann dem Benutzerhandbuch entnommen werden siehe Anhang A 6 7 Ausgabekomponenten package results 6 7 1 Einleitung Nach Abschluss der Metrikberechnung k nnen aus mproveT die Ergebnisse dieser Berechnung abgerufen werden Dieser Abschnitt beschreibt den Entwurf zur Pr sentation der Ergebnisse in den Ausgabekomponenten des Together ControlCenters Die f r den Entwurf ben tigten Schnittstellen wurden in Abschnitt 5 8 beschrieben 30 Kapitel 6 Entwurf 6 7 2 Entwurf der Ausgabeschnittstelle des Moduls berblick Einen einleitenden berblic
258. sen Bei der Klasse DVKostenBerechnenK handelt es sich um eine Kontrollklasse in der Logikschicht Sie bietet die Funktionalit t zur Berechnung der Kosten die der Einsatz eines Dozenten f r eine Seminarveranstaltung verursachen w rde 54 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Der Ursprung dieser Klasse l sst sich auf die Anforderungsspezifikation zur ckf hren In der textuellen Klassenspezifikation der Klasse Dozentenvereinbarung wird folgende Methode definiert gibKosten vonDatum Datum vonZeit Uhrzeit bisDatum Datum bisZeit Uhrzeit Geld comment liefert die Honorarkosten die ein Dozent bei Besch ftigung im angegebenen Zeitraum verursachen w rde Abbildung 31 Auszug aus der textuellen Klassenspezifikation der Klasse Dozentenvereinbarung Vermutlich war diese Methode zur Verwendung f r den Anwendungsfall Seminarveranstaltung kalkulieren vorgesehen Dort wird sie jedoch in dieser Form nicht ben tigt W hrend in den anderen Entwicklungsgruppen des Praktikums diese Methode aufgrund der ungenauen Spezifikation z B fehlen t glicher Seminarbeginn und Seminarende f r eine exakte Berechnung und ihrer Entbehrlichkeit nicht realisiert wurde resultierte im vorliegenden Projekt daraus die Klasse DVKostenBerechnenK Problematisch an dieser Abh ngigkeit ist insbesondere dass sie von der tiefer liegenden Datenhaltungsschicht in die h her liegende Kontrollschicht verl uft siehe Abschnitt
259. skussion der Entwurfsprobleme ihre Erw hnung finden 86 Kapitel 10 Entwurfsprobleme und Testbarkeit Einen groben berblick ber den Aufbau der Datenhaltungsschicht liefert das folgende Klassendiagramm IPersistert interface iErweitertPersistent TransformationenP LeitungsauftragRelation LeitungssuftragTripel BuchtPaar Belegung Tripel SVAnsprechpartnerfaar DYSchluessel FirmenAnsprechpartnerRelation BuchtRelation 5 5 DozentenvereinbarungRelstion DozentenvereinbarungTripel AnstellungRelation LeitungsauftragTripel AnstellungPaar RechnungsempfgengerPagr DozentenvereinbarungTripel DozentenvereinbarungAnfragen 5YAnsprechpartnerRelation Geld RechnungsempfaengerPaar DatumUhrzeit TellnahmeFirmenSl Paar Seminartyp BuchtPaar Seminarveranstaltung BelegungRelation Belegung ErweitertPersistentRelation FirmenSeminamveranstaltung TeilnahmeFirmenS YPaar Firma 5YvAnsprechpartnerPaar RechnungsempfaengerRelation Person 5V SeminartypPaar Geschseftspartner TeilnahmeFirmenS YRelation Leitungsauftrag FirmenAnsprechpartnerPaar Leitungsauftrag BelegungTripel lGeschaeftspartner 5YySeminartypRelation DeffentlicheSeminameranstaltung FirmenAnsprechpartnerPaar OeffentlicheSeminaryveranstaltung lAnstellungPaar Person Seminartyp Dozentenvereinbarung FirmenSeminarveranstaltung Seminamveranstaltung
260. sse definiert oder eine bestehende Klasse um ein Attribut oder eine Methode erweitert so wird durch automatisches Generieren des entsprechenden Sourcecodes auch die Implementierung angepasst Da auch die weiter oben erw hnten manuell in Klassendiagrammen eingef gten Abh ngigkeiten durch einen entsprechenden Kommentar im Sourcecode verf gbar sind reicht die alleinige Analyse des Sourcecodemodells aus um dadurch alle f r die Beurteilung der Testbarkeit relevanten Java Abh ngigkeiten erkennen und bestimmen zu k nnen 12 Kapitel 5 Analyse 5 5 3 Auswertung des Sourcecodes ber das Together Open API Der Zugriff auf den Sourcecode erfolgt im Together Open wie bereits beschrieben ber die 5 Schicht siehe Abschnitt 5 4 1 Ausgangspunkt ist dort die Klasse SciModelAccess das eine nach dem Interface SciModel implementierte Instanz der Sourcecode Repr sentation eines Together Projekts liefert QI SciModel ccess interface 5 myModel SciModel findElementSciElement model SciModel findCiass SciClass findMemberSciMember findPackage SciPackage findPackage SclPackage findFlle SciFiie findPackageTorasterile SciPackage 5 getGenericFactormy SciGenericractomy getLanguageHeilperSciLanguageHeiper languages StringEnumeration isLanguageSupportedboolean rootPackages SciPackageEnumeration rootPackages SclPackageEnumeration formatrilevoid patternManager S
261. sstrategie Big Bang auszuweichen 10 4 Zugriff auf Kontrollschicht durch Basiskomponenten 10 4 1 Entwurfsproblem Ein hnliches Problem wie im vorhergehenden Abschnitt stellt sich auch durch den Zugriff auf die Kontrollschicht durch die Basiskomponenten der Pakete ilP undExterneSystemeP die sich au erhalb der Drei Schicht Architektur befinden septionP D dungP SynchronisationP AnfragenP FirmenverwaltungP PersonenverwaltungP SeminarbelegungP SeminarisP SeminarverwaltungP ExterneSystemeP akaDocP igurationP PersistenzP ProtokollP Abbildung 104 Zugriff auf Kontrollschicht aus externen Modulen Ausschnitt aus SeminarlS 93 Kapitel 10 Entwurfsprobleme und Testbarkeit Damit verlieren diese Pakete und die in ihnen enthaltenen Komponenten ihre Unabh ngigkeit von der Anwendung Erfolgt der Austausch oder eine Ver nderung der Kontrollschicht so m ssen die Teile der Basiskomponenten in denen der Zugriff auf die Kontrollschicht erfolgt gegebenenfalls angepasst werden Die Zugriffe erfolgen auf die globalen Variablen SeminarisKk Protocol und SeminarisK Config der Hauptkontrollklasse Bemerkenswert hieran ist dass es sich bei diesen globalen Variablen der Kontrollschicht um Instanzen anderer Basiskomponenten handelt Damit liegt eine unn tige Inanspruchnahme der Kontrollschicht vor und demzufolge auch eine sehr einfach zu entfernende Abh ngigkeit Die beschriebenen
262. static access Erw eitertPersistent SeminarisDatenbank 1 0 1 1 5 48 1 1 static access SeminarisH SachbearbeiterA 1 1 0 14 23 1 static access SVKurzS Seminarv eranstaltung 0 0 1 12 2 0 8 dep abstract class MeldungsAnzeigeA Ex ceptionNachrichtA 0 0 0 1 0 0 8 1 create and access SeminarisK LogProtokollDateiA 0 0 11 0 1 2 1 2 create and access SeminarisK DebugProtokollDateiA 0 0 110 1 2 1 2 create and access Abbildung 113 Abh ngigkeitsmetriken nach Entfernen des externen Zugriffs auf Kontrollschicht 107 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung 11 4 Kein externer Zugriff auf Datenhaltung 11 4 1 Ausgangssituation Die Verwaltung von eindeutigen Dom nenbezeichnern erfolgte durch Ansiedlung entsprechender Logik in der Hauptkontrollklasse SeminarisK und der Datenbankklasse SeminarisDatenbank Dies f hrte zum Zugriff auf acht Datenhaltungsklassen aus dem Basismodul ExterneSystemeP PersistenzP In Verbindung mit der fest verdrahteten Abh ngigkeit zwischen SseminarisK und SeminarisDatenbank f hrte dies zu gravierenden Problemen siehe Abschnitt 10 5 11 4 2 Durchf hrung des Refactoring Der vorliegende Entwurfsfehler wird beseitigt durch Verlagerung der SseminarisDatenbank Methoden getHoechste nummer sowie der Seminari sK Methoden getNext nummer in Datenhaltungsschicht Im Einzelnen erfolgt dies durch Verschmelzung der Funktionalit t der beiden jeweils zusammengeh re
263. stbarkeit Motivation und Definition Die Aussage Testen sei ein wichtiger Qualit tsfaktor bei der Entwicklung von Softwaresystemen trifft bei jedem Entwickler auf volle Zustimmung Betrachtet man die umfangreich vorhandene Testliteratur so l sst sich auch nicht sagen dass f r die Planung und Durchf hrung von Tests nur wenig Unterst tzung zu finden w re Und trotzdem ist in vielen Projekten der Testprozess der am meisten vernachl ssigte Teil im Rahmen der Softwareentwicklung Es gibt sicherlich viele Ursachen hierf r Kommt der bliche Stress im Programmieralltag auf so verbleibt in der Regel am wenigsten Zeit f r die zumeist letzte Phase im Entwicklungsprozess Die Testphase Ist man zudem der Meinung dass Testen unter dem Strich stets zu Mehraufwand und l ngeren Entwurfszeiten f hrt so steigert dies nicht gerade die Motivation f r Tests Testen wird von vielen Entwicklern ferner als monoton wenig kreativ und langweilig empfunden Und au erdem kann man zu guter Letzt immer noch auf die Arbeit der Testabteilung im Hintergrund vertrauen M glicherweise liegen die Ursachen aber auch an anderer Stelle Neben Faktoren wie e G te der Testmethodik e Umfang der Unterst tzung durch Testwerkzeuge e M glichkeit zur Bereitstellung einer ad quaten Testinfrastruktur e Ausbildung und Erfahrung der Tester e Korrektheit und Vollst ndigkeit der Spezifikation gegen die getestet werden soll haben insbesondere die e Eigenschaf
264. stellten Schnittstellen im Mittelpunkt 5 2 Metrikwerkzeug ImproveT Zur Umsetzung des in Abschnitt 1 3 vorgestellten Konzeptes zur Identifizierung von testkritischen Abh ngigkeiten wurde von Stefan Jungmayr ein Metrikwerkzeug mit dem Namen mproveT realisiert Dieses Werkzeug analysiert Abh ngigkeiten objektorientierter Software die in einem mehrschichtigen Abh ngigkeitsgraphen vorliegen Auf Basis dieses Abh ngigkeitsgraphen werden die Testbarkeitsmetriken Reduktionsmetriken und zus tzliche Informationen f r die Abh ngigkeiten und Programmkomponenten eines Softwaresystems errechnet Ferner bietet mproveT die M glichkeit zur Visualisierung der Komponenten des Systems und der zwischen ihnen ermittelten Abh ngigkeiten als Graph Die Implementierung von mproveT ist vollst ndig in Java gehalten Parallel zu dieser Diplomarbeit und der Integration von mproveT in Together siehe Abschnitt 5 3 erfolgte durch Stefan Jungmayr die Fortentwicklung des Werkzeugs auch auf Basis der in dieser Arbeit gewonnenen Erkenntnisse Die Beschreibung des Werkzeugs basiert auf dem gegen Ende der Diplomarbeit verf gbaren Release Die Berechnung der Testbarkeitsmetriken durch mproveT l uft im Wesentlichen wie folgt ab e Erzeugung eines Abh ngigkeitsgraphen ber das Einf gen von Abh ngigkeiten und Programmkomponenten des zu analysierenden Systems als Kanten und Knoten des Graphen e Analyse des Abh ngigkeitsgraphen und darauf basierend Berechnung d
265. swaehlenAA nicht von der im Grobentwurf hierf r festgelegten Templateklasse AuswaehlenListeAA abgeleitet Diese zus tzliche Indirektion ist aber Voraussetzung daf r die aufrufende Klasse absolut frei von der Abh ngigkeit zu Konkreten Auswahlklasse zu bekommen Gelingt dies nicht so verbleibt zumindest noch eine Typabh ngiskeit bei der aufrufenden Klasse DozentenvereinbarungAuswaehlenAA dvAuswaehlenAA Factory getDozentenvereinbarungAuswaehlenAA Das nachtr gliche Ableiten w rde die zus tzliche Implementierung der abstrakten Methoden von AuswaehlenListeAA bedeuten die derzeit noch nicht vorhanden sind Einfacher ist es ein Interface IDozentenvereinbarung einzuf hren in dem die von den aufrufenden Instanzen ben tigten Methoden definiert werden Die Klassen PersonAuswaehlenAA und LeitungsauftragAuswaehlenAA leiten sich zwar von der abstrakte Klasse AuswaehlenListeAA ab bieten jedoch den aufrufenden Klassen noch weitere Methoden an die nicht in der abstrakten Klasse definiert sind Um auch hier die angesprochenen Typabh ngigkeiten zu vermeiden m ssen auch f r diese Klassen Interfaces geschaffen werden Die Klasse SVAuswaehlenAA bietet noch eine zweite Methode zur Erzeugung einer Auswahlinstanz an Diese Methode erh lt im Originalcode als zweiten Parameter eine Policy Klasse bergeben bei der es sich um eine von sechs m glichen inneren Klassen der Klasse SVAuswaehlenAA handelt Um diese Abh ngigkeit auf m glichst einfa
266. t ndnis ihrer Bedeutung ausf hrlich erl utert w hrend bei den restlichen Abh ngigkeiten nur noch Auff lligkeiten bei den Metriken beschrieben werden und sie sonst unkommentiert bleiben Im zweiten Teil erfolgt eine Bewertung der Abh ngigkeiten Diese soll die Entstehung und die Ursachen der Abh ngigkeit aufzeigen eine Einsch tzung ihres Einflusses auf die Testbarkeit vornehmen und gegebenenfalls die M glichkeiten zur Entfernung der Abh ngigkeit beleuchten Auch diese Bewertung erfolgt bei den ersten Abh ngigkeiten etwas ausf hrlicher In der Folgezeit beschr nkt sich die Bewertung aus Zeit und Platzgr nden darauf in aller K rze auf die wichtigsten Aspekte hinzuweisen 9 2 1 Dozentenvereinbarung DVKostenBerechnenK 9 2 1 1 Ergebnisse der Metrikberechnung Man erh lt folgende Abh ngigkeits und Komponentenmetriken 2 0 rACD co rNSBC rNCDC sub_hw subedges _ E ES i o create and access Abbildung 28 Abh ngigkeitsmetriken Dozentenvereinbarung DVKostenBerechnenK 52 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten 5 4 6219 4 8 8 4 4 89 65 62 8 8 7 8 Abbildung 29 Komponentenmetriken Dozentenvereinbarung A und DVKostenBerechnenK Erl uterungen zu den Abh ngigkeitsmetriken Die Abh ngigkeit ist Teil eines Zyklus dep_comp und verl uft ber Paketgrenzen hinwe
267. t SciElement dependentClass SciClass setDependents void yisitExpression Object yisitAssignmentExpression Objec yisitConstantExpression Object yisitDirectinitExpression Object yisitFunctionCallExpression Objeg SciReferencel isitor visitMemberAccessExpression H GraphTypes yisitTypeExpression Object MyReferenceYisitor yisitNewExpression Object SciReferencel isitor yisitReferenceExpression bject GraphTypes yisitTypeCastExpression bject MyNewExpressionReferenceVisit dependentElement SciElement dependentClass SciClass dependentElement SciElement setDependents void dependentClass SciClass yisitReference Object isDefined boolean setDependents void visitReference bject addNewinstanceDependency yoid Abbildung 15 bersicht ber die Struktur der implementierten visitor Klassen Der Ablauf beim Start einer Suche nach Abh ngigkeiten in einem Together Projekt stellt sich zusammengefasst wie folgt dar e Erzeugung einer Instanz eines DependencySearcher e Erzeugung einer das Interface DependencySearchListener implementierenden Instanz und Registrierung dieser Instanz beim DependencySearcher Erzeugung einer das Interface SearchScope implementierenden Instanz und Registrierung beim DependencySearcher e Starten der Abh ngigkeitssuche durch Aufruf der Methode search 27 Kapitel 6 Entwurf 6 4 Komponente Abh ngiskeitsgraph package data Zentrale
268. t der Komponente in der Testumgebung Aus Sicht der Testbarkeit bringt diese L sung deshalb keinen Vorteil 11 5 2 2 bergabe der Basiskomponenten bei der Konstruktion Die Ber cksichtigung von Testbarkeitsbelangen besitzt einen sehr hohen Stellenwert innerhalb der testgetriebenen Entwicklung Test First Design ein wesentliches Element von Xtreme Programming blicherweise wird dort die Bereitstellung von Basiskomponenten durch bergabe der Komponente als Parameter den Konstruktor einer Klasse gel st siehe beispielsweise LinkO1 Durch die Verwendung von Interfacetypen als Typen der bergabeparameter wird die Abh ngigkeit der nutzenden Klassen von einer konkreten Instanz vermieden Beispiel f r die bergabe der Datenbank in der Datenhaltung public class EntityClass public EntityClass Databaselnterface db Jede Klasse die Zugriff auf eine Basiskomponente z B die Datenbank ben tigt erh lt wie in obigem Beispiel eine den Interfacetyp implementierende Ressource bei der Objekterzeugung bergeben Bei der Erstellung von Testf llen hat dies den gro en Vorteil dass die Verwendung eines f r Testzwecke implementierten Teststellvertreters vom Interfacetyp auf einfache Art durch Parameter bergabe im Rahmen der Initialisierung des Testfalls erfolgen kann Es liegt in der Natur der Sache dass dieses Parameterkonzept in der Literatur zumeist an kleinen einfachen und einpr gsamen Beispielen vera
269. t syntaktisch abh ngig Metrik ACD Dabei handelt es sich bei etwa zwei Drittel dieser Abh ngigkeiten um statische Abh ngigkeiten Metrik ACDh Der Abh ngigkeitsgraph von SeminarlS enth lt 5 Zyklen Metrik NDC an denen 106 Klassen beteiligt sind Metrik NCDC Es existieren 81 Abh ngigkeiten deren Entfernung einen Beitrag zum Aufbrechen der Zyklen leisten w rde Metrik NFD M chte man im Testprozess die vorhandenen Zyklen aufbrechen so sind 39 Teststellvertreter Stubs hierf r notwendig Metrik NSBC Aufgrund der Vielzahl der Informationen die von mproveT geliefert werden ist es in dieser Arbeit nicht m glich eine vollst ndige Analyse und berpr fung aller Ergebnisse durchzuf hren Wir konzentrieren uns auf jene Abh ngigkeiten deren ersatzlose Entfernung den st rksten Beitrag zur Reduzierung der Abh ngigkeit von Komponenten gemessen an der Metrik ACD leisten w rde Die nachfolgende Tabelle gibt einen berblick ber die 30 Abh ngigkeiten mit den h chsten rACD Werten in SeminarlS 50 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Abh ngige Klasse Funktionalit t bereitstellende Klasse Typ der Abh ngigkeit Dozentenv ereinbarung DVKostenBerechnenK 1 0 185 9 9 1 9 create and access SeminarisK SeminarisDatenbank 1 0 1 6 0 12 6 1 5 static access SVAendernErfassenAA Seminarty pAusw aehlenAA 0 0 1 3 3 1 2 create and access DruckDokumentDK SeminarisK 0 0 121 2 9 4 4 static a
270. tems war weder vorgesehen noch wurde er f r notwendig erachtet Dies f hrte in der Konsequenz dazu dass weder bei Architekturentscheidungen in der Entwurfsphase noch w hrend der Implementierungsphase Testbarkeitsaspekte Ber cksichtigung fanden Hinzu kam noch dass im Hinblick auf den Einsatz des Persistenz Rahmenwerks sich die Bem hungen in erster Linie darauf richteten eine funktionierende Anbindung der Datenbank zu erreichen F r eine tiefergehende Besch ftigung beispielsweise einem Vergleich verschiedener Alternativen zur Anbindung des Rahmenwerks an die Anwendung blieb dabei keine Zeit Eine der Aufgaben des zweiten Teils dieser Arbeit siehe Abschnitt 8 1 sollte die Erstellung von Testf llen f r ausgew hlte Teilkomponenten die Refaktorisierung der Teilkomponenten zur Beseitigung von testkritischen Abh ngigkeiten und die erneute vergleichende Erstellung von Testf llen auf Basis der ver nderten Architektur sein Um die Ermittlung des Aufwandes f r die Erstellung einzelner Testf lle frei zu halten von Aufw nden f r die Diskussion grundlegender systemweiter Testprobleme erschien es sinnvoll diese Diskussion vor Beginn der Testfallerstellung zu f hren Dies wird in den n chsten Abschnitten erfolgen Dort werden einige zentrale Entwurfsprobleme und ihr m glicher Einfluss auf die Testbarkeit diskutiert Zus tzlich zur Diskussion erfolgt an manchen 85 Kapitel 10 Entwurfsprobleme und Testbarkeit Stellen der Versuch L
271. ten der zu testenden Software ma geblichen Einfluss auf die Komplexit t des Tests und den zu leistenden Testaufwand Der Grad zu dem die zu testende Software die Durchf hrung der Testaufgaben zur berpr fung von zu ermittelnden Testkriterien erleichtert wird als Testbarkeit bezeichnet IEEE90 Die Abneigung gegen die systematische und umfassende Durchf hrung von Tests wird also auch darin begr ndet sein dass Softwaresysteme die ohne R cksicht auf ihre Testbarkeit entworfen wurden Kapitel 1 Abh ngigkeiten und Testbarkeit Eigenschaften besitzen die in der Tat zu einem u erst unangenehmen und aufw ndigen Testprozess f hren Eine m gliche L sung dieses Problems ist unter anderem auch Bestandteil des Konzepts von Extreme Programming XP Beck00 Mit dem Aufkommen und der Propagierung von XP fand die Durchf hrung von Komponententests Unit Tests und insbesondere deren Erstellung vor oder parallel zum eigentlichen Entwicklungscode Test First Design breites Interesse W hrend also beim Gro teil der in der Literatur beschriebenen klassischen Entwurfs und Testverfahren die Testaktivit ten und Testf lle auf Basis eines detaillierten vorab bereits fertig gestellten Entwurfs definiert werden erfolgt dies in XP parallel zu Softwaredesign und Implementierung Das auf diesem Wege entstehende Design scheint prinzipiell besser f r die Erledigung der Testaufgaben geeignet zu sein Daraus folgt das Bestreben unabh ngig vom
272. tion des Abh ngigkeitsgraphen mproveT Die Basis f r alle Metrikberechnungen in mproveT bildet ein Abh ngigkeitsgraph Zur Objekterzeugung eines Abh ngigkeitsgraphen liefert im Paket system die Klasse Factory eine Instanz einer Implementierung des Interfaces GraphFactory von der ber eine gleichnamige getter Methode eine Instanz einer Implementierung des Interfaces ExtendedGraph empfangen werden kann interface ImproveT graph GraphFactory Facto d getExtendedGraph ExtendedGraph interface graph GraphrFactory ge Graph Graph AnprovoT graph Extenda dareph getEdge Edge getNode Node getLevel Level resetidentifiervold Graph getExtendedGraph ExtendedGraph getGraph Graph getEdge Edge getNode Node getLevel Level resetldentifiervoid Abbildung 8 Klassendiagramm zur Erzeugung eines Abh ngigkeitsgraphen Die Modellierung der Abh ngigkeiten eines objektorientierten Softwaresystems erfolgt im Abh ngigkeitsgraphen von mproveT auf verschiedenen Ebenen z B Member und Klassenebene Auf jeder dieser Ebene werden die abh ngigen sowie weitere f r die Metrikberechnung relevante Programmkomponenten als Knoten des Graphen modelliert z B Attribute und Methoden als Knoten auf der Memberebene Eine Abh ngigkeit zwischen zwei Komponenten wird durch eine die beiden Knoten verbindende Kante dargestellt Die verschiedenen Ebenen des Abh ngigkeitsgraphen k nnen ferner durch entsp
273. tionenklassen ben tigt so werden die Methodenaufrufe von den Dom nenklassen entgegen genommen und an die jeweils zust ndigen Relationen und Ordnerklassen durchgereicht In den meisten F llen ist dabei keine zus tzliche Funktionalit t in der Dom nenklasse angesiedelt d h die Aufgabe der Dom nenklassenmethode beschr nkt sich ausschlie lich auf das Durchreichen des Methodenaufrufs Dieses Design entsprach nicht den Empfehlungen aus SWEII99 und wurde demzufolge auch kontrovers diskutiert Letztlich setzte sich innerhalb der Entwicklergruppe folgende Argumentation durch e Entit tsklassen lassen sich in objektorientierten Sprachen unmittelbar aus den Entwurfsmodellen ableiten e Assoziationen hingegen m ssen erst in implementationsf hige Entwurfsklassen transformiert werden e Hierf r existieren unterschiedliche Transformationsvarianten von denen es nicht immer die Beste gibt e Deshalb sollte dieser m glicherweise eher ver nderliche Teil der Implementierung der Datenhaltung vor der Kontrollschicht verborgen bleiben Hierf r bietet sich obligatorisch das Entwurfsmuster Fassade an Das eben angesprochene ausschlie liche Durchreichen des Methodenaufrufs wird aus folgendem Programmauszug der Dom nenklasse Firma deutlich public static Iterator getAlle throws DatenbankAusnahme return iter GeschaeftspartnerOrdner getEinzigelnstanz getFirmen Muss die von einer Ordner oder R
274. tring sciTexdPositions SciTextPositions sourceCodeFileName String SourceCodeReference getTextPassage String getSciTextPositions SciTetPositions getSourceCodeFileName String Abbildung 16 Klassendiagramme des DependencyGraph Pakets package data Anhand dieser Informationen zeichnet das Einzelst ck der Klasse DependencyGraph in den Methoden createGraphEntry verantwortlich f r die korrekte Erstellung der Eintr ge in den nach mproveT zu exportierenden Abh ngigkeitsgraphen Sie besitzt ein Attribut vom Interface Typ AnalyzeOptions ber das die Relevanz der Zielkomponenten von Abh ngigkeiten gepr ft werden kann Eine Instanz von diesem Typ wird bei Aufruf der Methode reset als Parameter bergeben Der Aufruf dieser Methode muss jeder neuen Testbarkeitsanalyse vorausgehen In ihr wird unter anderem f r jeden Durchlauf eine neue ExtendedGraph Instanz erzeugt und initialisiert F r jede ermittelte und tats chlich relevante Abh ngigkeit wird eine Instanz vom Typ Dependency erzeugt Der Bezug zur Quelle der Abh ngigkeit im Sourcecode wird in einer Instanz der Klasse SourceCodeReference als Attribut der Abh ngigkeit verwaltet Diese Referenz zum Sourcecode wird bei der Anzeige der Abh ngigkeitsmetriken zur Navigation zum Ursprung der Abh ngigkeit ben tigt 28 Kapitel 6 Entwurf 6 5 Komponente Analysesteuerung package analysis Als zentrales Element dieser Teilkomponente wird die Klasse ComputeMetrics v
275. ts IPerson public void loeseAnstellungFirma IFirma f throws DatenbankAusnahme AnstellungRelation getEinzigelnstanz loese IPerson getThis f B 4 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP Person T_CLASS IFirma T_INTERF Class D_PARAM Person T_CLASS IFirma T_INTERF Member Um den Bezug zur abh ngigkeitsverursachenden Methode nicht zu verlieren wird bei der auf Klassenebene eingef gten Abh ngigkeit eine Referenz auf den Methodenknoten gespeichert B 5 des R ckgabewerts einer Methode B 5 1 Erl uterung und Beispiel Liefert eine Methode als Returnwert einen Objekttyp zur ck so wird eine Abh ngigkeit vom Typ D_RETURN definiert Zu den Objekttypen z hlen beispielsweise auch die mit der Java 2 Platform Standard Edition J2SE ausgelieferten Wrapper Klassen Integer Boolean oder die Klasse String Die Java Basisdatentypen int boolean bleiben hingegen unber cksichtigt public class Person extends Geschaeftspartner implements IPerson public IFirma getAnstellungFirma throws DatenbankAusnahme return AnstellungRelation getkEinzigelnstanz getFirma IPerson getThis B 5 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Knotentyp Nach Knotentyp Summary D_DEP Person T_CLASS IFi
276. tungsauftragTripel 9 2 24 1 Ergebnisse der Metrikberechnung x 9 5 z DI 3 kel N 2 2 D lt lt lt lt Z Z 9 D 0 0 0 0 3 E lt OI 4 3 7 2 9 2 3 1 5 89 65 621 0 0 4 Abbildung 84 Komponentenmetriken LeitungsauftragRelation A und LeitungsauftragTripel Auff lligkeiten bei den berechneten Werten Die rACD Werte der Klasse LeitungsauftragRelation liegen deutlich ber dem rACD Wert der Abh ngigkeit 9 2 24 2 Bewertung Die beiden beteiligten Klassen resultieren aus der transformierten Assoziation zwischen einer Person einer von ihr geleiteten Seminarveranstaltung und der Assoziationsklasse Leitungsauftrag Die Bewertung der Abh ngigkeiten zwischen Relationen und Paarklassen wurde bereits bei Abh ngigkeit 9 2 14 vorgenommen Die Abh ngigkeiten zwischen Relationen und Tripelklassen sind v llig analog zu sehen 9 2 25 DozentenvereinbarungRelation DozentenvereinbarungAnfragen 9 2 25 1 Ergebnisse der Metrikberechnung x 5 gt Mm Ex d_type kel 0 d 2 o Lg L VS VS Le 2 2 0 0 10 12 12 00 09 0 0 6 7 static access Abbildung 85 Abh ngigkeitsmetriken DozentenvereinbarungRelation DozentenvereinbarungAnfragen 78 Kapitel 9 Testbarkeitsanalyse ausgew hlter Abh ngigkeiten Abbildun
277. typ Seminarveranstaltung nstellungRelation BelegungRelation DozentenvereinbarungRelation DozentenvereinbarungTripel LeitungsauftragRelation RechnungsempfaengerRelation TeilnahmeFirmenSV Relation Abbildung 123 Ver nderung Lines Of Code LOC Number of Operations NOO in der Datenhaltung Man erkennt dass die Anzahl der implementierten Methoden in der Datenhaltungsschicht um etwa ein Drittel von 964 auf 634 abgenommen hat Auch dies l sst auf eine deutliche Reduzierung des Testaufwandes schlie en vergleiche auch Abschnitt 10 7 11 7 Einf hrung einer Schnittstellenklassen Factory 11 7 1 Ausgangssituation Wie in Abschnitt 10 8 beschrieben f hrt die Abh ngigkeit von Anwendungsf llen ber exceptional oder alternative flows durch die direkte Abbildung dieser Abh ngigkeiten beim Entwurf der Schnittstellenschicht zu einer starken Abh ngigkeit der zu den Anwendungsf llen entworfenen Schnittstellenklassen Zur Aufl sung dieser Abh ngigkeiten erfolgt die Implementierung einer Factory Klasse die f r die Erzeugung der Schnittstellenklassen zust ndig ist Die Implementierung bleibt darauf beschr nkt nur die Auswahlklassen SeminartypAuswaehlenAA LeitungsauftragAuswaehlenAA etc ber den Factory Mechanismus zu verwalten da zun chst nur deren Erzeugung bei den Testbarkeitsmetriken ausschl gt Die Verwaltung der brigen 119 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung Schnittste
278. typ m ssen ignoriert werden Um die vorgenannten Punkte sicherzustellen wurde parallel zur Implementierung der Suchkomponente ein Referenzprojekt mit allen relevanten Abh ngigkeiten aufgebaut Ferner wurde versucht auch die brigen aufgef hrten Konstellationen durch eine geeignete Implementierung im Referenzprojekt abzudecken Anhand dieses Referenzprojekts wird sukzessive die Implementierung der Suchkomponente getestet Nachstehend folgt anhand einer relativ einfach zu behandelnden Abh ngigkeit eine kurze Schilderung des in den meisten F llen typischen Vorgehens bei der Identifizierung von relevanten Abh ngigkeiten es handelt sich um einen komprimierten und aufbereiteten Auszug aus dem Originalsourcecode public Object visitAttribute SciAttribute sciAttribute 1 SciElement referencedElement sciAttribute getType getReferencedElement SciClass containingClass sciAttribute getContainingClass references out of classpath are ignored if referencedElement null 1 return null ignoring the Attributes of own Class Type e g singletonInstance if referencedElement containingCclass return null its an attribute of class type may also be an java something type if referencedElement instanceof SciClass 80 add a new Dependency object notifyListenerDependencyFound sciAttribute referencedElement deleteNewLinesAndSpaces sciAttribute getDeclarationTexst sciAttribute
279. ublic void InitArrayMethod ClassType var new ClassType 5 B 22 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary InitArrayExample T_CLASS ClassType T_CLASS Class DNEW InitArrayExample T_CLASS ClassType T_CLASS Member Um den Bezug zur Methode oder zum Attribut das die Abh ngigkeit verursacht nicht zu verlieren wird bei der auf Klassenebene eingef gten Abh ngigkeit eine Referenz auf den Elementknoten gespeichert B 23 Initialisierung eines mehrdimensionalen Arrays B 23 1 Erl uterung und Beispiel Bei der Initialisierung eines mehrdimensionalen Arrays mit dem new Operator wird eine Abh ngigkeit D_NEW_MAR definiert public class InitMultiArrayExample public void InitMultiArrayMethod ClassType var new ClassType 5 2 B 23 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary InitMultiArrayExample T_CLASS ClassType T_CLASS Class D_NEW_MAR InitMultiArrayExample T_CLASS ClassType T_CLASS Member Um den Bezug zur Methode oder zum Attribut das die Abh ngigkeit verursacht nicht zu verlieren wird bei der auf Klassenebene eingef gten Abh ngigkeit eine Referenz auf den Elementknoten gespeichert B 24 Verwendung des Type C
280. ufhin wird Ihnen das Unterpanel Component Metrics gt 4 2 Komponentenmetriken angezeigt Die Zeile mit den zu dieser Komponente geh renden Metriken erscheint selektiert Wenn Sie sich im Panel Component Metrics in der Anzeige der verbundenen Komponenten befinden k nnen Sie sich die Metrikwerte der zugrunde liegenden Abh ngigkeit anzeigen lassen W hlen Sie hierzu im Kontextmen der Komponententabelle den Men punkt Dependency Metrics Daraufhin wird Ihnen das Unterpanel Dependency Metrics gt 4 1 Abh ngigkeitsmetriken angezeigt Die Zeile mit den Metriken der korrespondierenden Abh ngigkeit erscheint selektiert Im Panel Component Metrics besteht ferner die M glichkeit sich zu jeder verbundenen Komponente die Komponentenmetriken anzeigen zu lassen W hlen Sie hierzu im Kontextmen der ber Abh ngigkeit verbundenen Komponente den Men punkt Select Component Metrics Daraufhin wird die Anzeige der Metriktabelle aktualisiert und die Metrikwerte der verbundenen Komponente erscheinen selektiert Gleichzeitig erfolgt auch die Aktualisierung der ge ffneten Komponentenfenster im rechten Teil der Anzeige Auf diese Weise k nnen Sie in beliebiger Richtung entlang eines Pfads im Abh ngigkeitsgraphen navigieren 4 3 4 Anzeige im Klassen Diagramm M chten Sie sich das Klassendiagramm f r eine an einer Abh ngigkeit beteiligten Komponente anzeigen lassen so w hlen Sie in den Metriktabellen oder der Komponentenanzeige den Men punkt Select
281. ung 17 Benutzerschnittstelle zur Auswahl der Testbarkeitsmetriken Nachdem der zu analysierende Abh ngigkeitsgraph vorliegt erzeugt ComputeMetrics die beiden Instanzen der Analyzer Klassen Diese sorgen f r den Export des Graphen und den Start der Metrikberechnung in mproveT indem sie die in Abschnitt 5 7 1 beschriebenen Aufgaben bernehmen e Erzeugung von Instanzen der mproveT Klassen VersionAnalysis bzw NodeAnalysis e Zuweisung des ermittelten Abh ngigkeitsgraphen e Erzeugung und Zuweisung der zu berechnenden Metriken e Starten der Testbarkeitsanalysen 6 6 Komponente Metrikauswahl package selection Die Anforderungsspezifikation sieht die M glichkeit vor die im Rahmen der Testbarkeitsanalyse zu ermittelnden Metriken vor dem Start der Analyse durch den Anwender bestimmen zu lassen Um nicht mit der Benutzeroberfl che also dem Look and Feel des Together ControlCenters zu brechen erfolgt bei der Implementierung des Auswahldialogs die Orientierung an den in Together bereits integrierten Audit und Metrikmodulen Die auszuw hlenden Metriken werden folglich in Tabellenform angeboten Ferner stehen modale Unterdialoge zum Speichern und Laden von Metriken sowie zur Einstellung von Optionen bei der Grapherstellung siehe Abschnitt 6 4 zur Verf gung 29 Kapitel 6 Entwurf SelectMetricsDialog control SelectMetrics dialog JDialog digBounds Rectangle rootPane JPanel SelectMetrics edgeMetricsTable MetricsTable
282. uswaehlenK PersonenverwaltungP PersondendernErfassenK DozentenvereinbarungP LeitungsauftragP SeminartypP SeminarveranstaltungP 5YDurchfuehrenK AbsageMitteilungDK DeSi AendernErfassenK BegleitschreibenDK FSYAuftragsbestaetigungDK TeilnehmerListeDK 5YyAuswaehlenK 5YvorbereitenK 0eSYErfassenK Sl AendernErfassenK EM Aender FSYRechnungDK FSl AendernErfassenK 5YAbsagenK FSVErfassenK HonorarUeberweisungDK 0eSYAendernK TeilnahmebescheinigungDK 5WLoeschenK GutschriftlieberweisungDK FSY Teilnehmer ZuordnenK AenderungsmitteilungDK Abbildung 100 Paketdiagramm Anwendungslogik FirmenverwaltungP Firma amp uswaehlenK PersonErfassenK FirmaErfassenK PersonAuswaehlenK FirmalLoeschenK PersonLoeschenK FirmaAendernErfassenK Person amp endernK Firma amp endernK AnfrageStellenK ListenDruckDK ErgebristabellenModel ZeilenSelektierer AnfrageDefinierenK SpaltenModel BilanzDK BilanzErstellenK TableEingsbeModel ParameterModel ExpressionEvalustor ListendruckK AnfrageLoeschenK AnfrageErfassenK AnfrageAendernK ParameterEingabeModel SeminartypAuswaehlenK SeminartypAendernK 5YKalkulierenK SeminartypLoeschenK SeminartypErfassenK KalkulationDK SeminartypAendernErfassenK LeitungsauftragLoeschenK LeitungsauftragdendernErfassenK Leitungsauftrag uswaehlenK Leitungsauftrag amp en
283. verwendeten Vorgehensmodell dem Entwickler bereits so fr h als m glich eine R ckmeldung ber die Testbarkeit seines Designs zu geben Hierzu soll ihm mit der vorliegenden Arbeit ein Werkzeug an die Hand gegeben werden das ihn auch bei klassischen Entwurfsverfahren in die Lage versetzt fr hzeitig Hinweise auf jene Eigenschaften und Strukturen seiner Software zu erhalten die negativen Einfluss auf die Testbarkeit seines Projekts aus ben 1 2 Einfluss von Abh ngigkeiten auf Testbarkeit Einer der Faktoren der Auswirkungen auf die Testbarkeit eines Programms besitzt sind Abh ngigkeiten zwischen Programmteilen Ben tigt eine Komponente hierbei kann es sich beispielsweise um eine Klasse Interface oder Paket handeln zur Erf llung ihrer Aufgaben keine weitere Funktionalit t aus anderen Komponenten vereinfacht dies ihre Betrachtung in der Testphase Komplexere Anwendungsfunktionalit t l sst sich jedoch erst dadurch realisieren dass verschiedene Komponenten miteinander kommunizieren Dieses Zusammenwirken f hrt zu unvermeidbaren Abh ngigkeiten unter diesen Komponenten Mit Abh ngigkeiten sind im Rahmen dieser Arbeit syntaktische Abh ngigkeiten von Programmkomponenten gemeint Der Begriff der syntaktischen Abh ngigkeit einer Komponente A von Komponente B bedeutet dass Komponente A ohne das Vorhandensein von Komponente B nicht kompilierf hig ist Daneben existieren noch semantische Abh ngigkeiten von Programmkomponenten wenn beispiels
284. verwendung bei der Realisierung der Abh ngigkeitssuche Teilaufgabe T 2 nicht ausreichte Together zeichnet sich ferner dadurch aus dass alle gespeicherten Informationen automatisch synchronisiert werden ToSZ02 Das bedeutet insbesondere dass zwischen allen Modellelementen des Entwurfs wie z B Klassendiagrammen und dem implementiertem Sourcecode zu jeder Zeit vollst ndige Konsistenz herrscht Durch die dadurch vorhandene Abbildung von beispielsweise Klassendiagrammen im Sourcecode wird die notwendige Ermittlung der vorhandenen Abh ngigkeiten innerhalb eines Softwareprojekts vereinfacht Dies erleichtert es auch bereits mit Beginn der Entwurfsphase Testbarkeitsanalysen vornehmen zu k nnen Eine n here Beschreibung des Aufbaus und der Funktionalit t des Together Open API erfolgt bei der Analyse der Teilaufgaben in den nachfolgenden Abschnitten dieses Kapitels 5 4 Erweiterung von Together T 1 5 4 1 Aufbau des Together Open API Das Together Open API gliedert sich auf oberster Ebene in drei Pakete Diese Pakete realisieren verschiedene Zugriffsebenen auf die Entwicklungsplattform und dem der Plattform zugrunde liegenden internen Programmmodell Die Struktur der Programmierschnittstelle ist dreischichtig konzipiert IDE Together s IDE RWI sources diagrams links etc SCI sources Abbildung 1 Die drei Schichten des Together Open Quelle ToUG02 Die drei Schichten des Together Open API erm glichen
285. vlethodeA Abbildung 1 Beispielhafte Struktur eines Abh ngigkeitsgraphen In der Abbildung sind bereits einige Abh ngigkeitstypen zu erkennen Die f r die verschiedenen Typen verwendeten K rzel sind durch ImproveT vorgegeben Die Klassifizierung in verschiedene Typen erfolgt nicht nur f r Abh ngigkeiten sondern auch f r die im Graph als Knoten gespeicherten Komponenten Folgende Komponenten und ihre in ImproveT festgelegten K rzel treten in den 141 Anhang Einleitung nachfolgenden Abschnitten auf wobei die feinere Klassifizierung immer Vorrang vor der allgemeineren Beschreibung haben wird e Klassen T_CLASS e Finale Klassen T_CL_FINAL e Interfaces T_INTERF e Abstrakte Klassen T_ABSTR e Innere Klassen T_INRCL e Konstruktoren T_CONSTR e Methoden T_METHOD e Finale Methoden T_M_FINAL e Attribute T_FIELD e Finale Attribute T_F_FINAL Initialisierer Eine zusammenfassende Auflistung aller in den nachfolgenden Abschnitten definierten Abh ngigkeitstypen sowie ein berblick ber die M glichkeit des Auftretens der Abh ngigkeiten und Komponenten in den verschiedenen Ebenen des Abh ngigkeitsgraphen befindet sich am Ende dieses Dokuments 142 Anhang Vererbung Subclassing Java Abh ngigkeiten B 1 Vererbung Subelassing 1 1 Hierunter fallen Abh ngigkeiten durch Vererbung von Programmteilen durch explizite Angabe des Schl sselworts extends definiert
286. weise eine Komponente in ihrer Implementierung auf ein bestimmtes Verhalten einer anderen Komponente vertraut Die Einschr nkung auf syntaktische Abh ngigkeiten im Rahmen dieser Arbeit basiert auf dem Umstand dass syntaktische Abh ngigkeiten maschinell erfasst werden k nnen Semantische Abh ngigkeiten sind einer automatisierten Erkennung kaum oder nur mit wesentlich h herem Aufwand zug nglich Durch Abh ngigkeiten wird eine transitive Relation zwischen den Komponenten eines Systems definiert Dies bedeutet zum einen dass jede Abh ngigkeit eine Richtung besitzt und zwar von der abh ngigen Komponente dependent oder client class zu derjenigen Komponente die im Rahmen der Abh ngigkeit Funktionalit t liefert dependee oder server class Somit k nnen zwischen zwei Komponenten maximal zwei Abh ngigkeiten mit jeweils entgegengesetzter Richtung existieren Zudem f hren direkte Abh ngigkeiten der Komponente A von Komponente B und der Komponente B von Komponente C zu einer indirekten Abh ngigkeit der Komponente A von Komponente C In einem der Anh nge Anhang B bersicht Java Abh ngigkeiten erfolgt eine Aufstellung und Klassifizierung der m glichen syntaktischen Abh ngigkeiten in Java Programmen Bez glich der M glichkeit zur isolierten Testdurchf hrung lassen sich die ermittelten Abh ngigkeiten in zwei Gruppen einteilen W hrend die Abh ngigkeiten der einen Gruppe durch ihre Eigenschaften den isolierten Test einer Komponente b
287. wendungskomponenten durch den Einsatz von Stellvertretern Stubs m glich Diese Metrik liefert die Anzahl der Stellvertreter die zum Durchbrechen aller Zyklen ben tigt werden e Number Of Components Within Dependency Cycles Verzichtet man auf den Einsatz von Teststellvertretern so k nnen die Komponenten eines Zyklus nur zusammenh ngend getestet werden Diese Metrik liefert die Anzahl der Komponenten die in Abh ngigkeitszyklen involviert sind Im zweiten Schritt wird f r s mtliche Abh ngigkeiten des Systems eine Kenngr e definiert die erkennen l sst welchen Einfluss eine einzelne Abh ngigkeit auf eine der gemessenen Systemeigenschaften hat Dies erfolgt ber die Einf hrung der Reduktionsmetriken reduction metrics f r Abh ngigkeiten Eine Reduktionsmetrik bezieht sich dabei stets auf eine der im ersten Schritt definierten Projektmetriken Der Wert einer Reduktionsmetrik gibt an um welchen Kapitel 1 Abh ngigkeiten und Testbarkeit prozentualen Anteil sich die f r das Gesamtsystem ermittelte Metrik ver ndern w rde falls die betreffende Abh ngigkeit aus dem System entfernt werden k nnte Besitzt das Gesamtsystem beispielsweise einen ACD Wert von 90 und w rde die Entfernung der Abh ngigkeit zu einem ACD Wert von 81 f hren so betr gt der Wert der Reduktionsmetrik rACD f r diese Abh ngigkeit 10 Prozent Als testkritisch werden schlie lich jene Abh ngigkeiten betrachtet die vergleichsweise hohe Wert
288. werden Subclass extends Superclass Bei Subklasse kann es sich insbesondere auch um abstrakte oder finale Klassen handeln Erl uterung und Beispiel public class Firma extends Geschaeftspartner Folgt bei der Definition einer anonymen Klasse hinter dem Schl sselwort new der Name einer Klasse so handelt es sich auch ohne Angabe des Schl sselworts extends bei der anonymen Klasse um eine Subklasse dieser Klasse public class Firma extends Geschaeftspartner Date datum new Date 1 2 Die Grapheintr ge bei der expliziten Vererbung mittels extends lauten wie folgt Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Knotentyp Nach Knotentyp Summary D_DEP Firma T_CLASS Geschaeftspartner T_CLASS Class D_EXTEND Firma T_CLASS Geschaeftspartner T_CLASS Member Bei anonymen Klassen verl uft die Abh ngigkeit auf Klassenebene von der anonymen Klasse zur Superklasse Auf Summary Klassenebene hingegen geht die Abh ngigkeit von der Klasse aus in der die anonyme Klasse definiert wird Ebene Abh ngigkeitstyp Knotentyp Nach Knotentyp Summary D Firma T_CLASS Date T_CLASS Class D_EXTEND anonym_class T_INRCL Date T_CLASS Member Anmerkung Abstrakte finale sowie innere und anonyme Klassen werden durch eigene Typen T_ABSTR T_CL_FINAL T_INRCL repr sentiert Dies
289. wird hierdurch eine Abh ngigkeit vom Typ D_DEF definiert abstract public class FirmaAendernErfassenK protected Firma transienteFirma public class FirmaErfassenK extends FirmaAendernErfassenK public Firma getObjektFirma transienteFirma Firma erzeugeTransient B 12 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Von Knotentyp Nach Knotentyp Summary D_DEP FirmaErfassenK T_CLASS FirmaAendernErfassenK T_ABSTR Class D_DEF FirmaErfassenK T_CLASS FirmaAendernErfassenK T_ABSTR Member D_DEF getObjektFirma T_METHOD transienteFirma T_FIELD Wird auf ein Attribut innerhalb der eigenen Klasse zugegriffen so wird ebenfalls eine Abh ngigkeit auf Memberebene definiert Auf Klassenebene bleiben klasseninterne Abh ngigkeiten jedoch unber cksichtigt Der Zugriff auf lokale Methodenvariablen bleibt auf allen Ebenen unber cksichtigt B 13 Schreibender Zugriff auf statisches Klassenattribut B 13 1 Erl uterung und Beispiel Wird der Wert eines statischen Attributes einer Klasse neu gesetzt so wird hierdurch eine Abh ngigkeit vom Typ D_DEF_ST definiert public class SeminarisK private static int nextKundennummer public class FirmaErfassenK public Firma getObjektFirma nextKundennummer 12345 13 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Eben
290. xtmen s Gegebenenfalls M glichkeit zum Wechsel zwischen Klassen Ebene und Paket Ebene bei der Metrikberechnung Die Realisierung dieser Anforderung wurde im Verlauf der Arbeit allerdings auf einen sp teren Zeitpunkt verschoben siehe auch Abschnitt 6 8 4 2 Anwendungsf lle Zur exakten Beschreibung der bei der Erweiterung von Together zu realisierenden funktionalen Anforderungen wurden Anwendungsf lle verwendet Die Notation der Anwendungsf lle erfolgte auf Basis der Unified Modelling Language UML OUMLO00 Ausgehend von der Aufgabenstellung wurden die daraus resultierenden Funktionalit ten in einem Anwendungsfalldiagramm und in textuellen Anwendungsfallspezifikationen beschrieben Dabei wurden einige der obigen Anforderungen pr zisiert und teilweise auch um zus tzliche Funktionalit ten erweitert Die vollst ndige Beschreibung der Anwendungsf lle findet sich in Anhang A zu dieser Arbeit 4 3 Zerlegung in Teilaufgaben T 1 bis T 5 F r die zu leistende Integration von mproveT in Together l sst sich auf Basis der Aufgabenstellung und der beschriebenen Anwendungsf lle f r eine erste Analyse der beteiligten Systeme folgende Zerlegung in Teilaufgaben vornehmen T1 Integration der zu implementierenden Erweiterung in die Men struktur von Together Anbindung der Erweiterung an das Together Open API und Realisierung als Together Modul 2 Realisierung eines Teilmoduls auf Basis des Together Open zur Untersuchung der
291. y e NFD Number of Feedback Dependencies e Number of Stubs required to Break dependency Cycles NCDC Number of Components involved in Dependency Cycles e NDC Number of Dependency Cycles Sie erhalten in den nachfolgend beschriebenen Panels stets nur diejenigen Projektmetriken angezeigt die Sie w hrend der Metrik Auswahl gt 3 Metrikauswahl zur Berechnung vorgesehen haben 4 4 1 Projektmetriken f r das Gesamtprojekt In der Anzeige der Abh ngigkeitsmetriken Panel Dependency Metrics haben Sie die M glichkeit sich die Metriken f r das Gesamtprojekt anzeigen zu lassen W hlen Sie hierzu den Men punkt Project Metries im Kontextmen Es ffnet sich ein kleines Dialogfenster mit den bei der Analyse der Abh ngigkeiten errechneten Werten Neben dem K rzel der jeweiligen Metrik erhalten Sie in der Spalte ZeroValue die Gesamt Metrikwerte des zuletzt analysierten Projektes Project Metrics EN Abbildung 5 Anzeige der Gesamt Projektmetriken 4 4 2 Projektmetriken nach Beseitigung von Abh ngigkeiten In der Spalte exclude der Anzeige der Abh ngigkeitsmetriken haben Sie die M glichkeit sich die Projektmetriken anzeigen zu lassen die sich nach Beseitigung der ausgew hlten Abh ngigkeiten ergeben w rden W hlen Sie hierzu den Men punkt Project Metrics without des Kontextmen s Zur Anzeige ffnet sich ein eigenes Fenster Zu jeder Metrik erhalten Sie in der Spalte ZeroValue die Gesamtmetr
292. zentenvereinbarung 5 n PASY Auswaehlens A PSY Auswaehlens PDozentenvereinbarungAuswaehl PDYKostenBerechnenK 2 8689 4 005615 2 731285 4 2107544 2 5936 14 2539444 2 564659 3 0878983 2 4777 11 4467773 Abbildung 122 Top rACD Abh ngigkeitsmetriken nach Entfernung des Fassadenmusters Eine andere bersicht ber die Ver nderungen in der Datenhaltungsschicht erh lt man indem man die Anzahl der Programmzeilen und die Anzahl der Methoden in den Datenhaltungsklassen vor und nach der Refaktorisierung gegen berstell Zum besseren berblick wurden alle Komponenten ausgeblendet bei denen sich keine Ver nderung ergab 118 Kapitel 11 Entfernung testkritischer Abh ngigkeiten durch Refaktorisierung Vor Refactoring Nach Refactoring Lines Of Number Of Lines Of Number Of Paket Klasse lnterface Code Operations Code Operations SeminarisP DatenhaltungP 5441 964 4255 634 GeschaeftspartnerOrdner 192 SeminartypOrdner 2 SeminarveranstaltungOrdner 125 is a En Dozentenvereinbarung Firma FirmenSeminarveranstaltung Geschaeftspartner Belegung Firme IFirmenSeminarveranstaltung IGeschaeftspartner lLeitungsauftrag IOeffentlicheSeminarveranstaltung Person ISeminartyp ISeminarveranstaltung Leitungsauftrag OeffentlicheSeminarveranstaltung Person Seminar
293. zu verschaffen w hlen Sie im Untermen den Men punkt Show Dependency Type Daraufhin werden reinen Vererbungsabh ngigkeiten orange die brigen fest verdrahteten Abh ngigkeiten rot und alle verbleibenden Abh ngigkeiten gr n dargestellt Dependency Graph EN EdgeMetricffluseListener Abbildung 9 Graphanzeige im Farbschema Show Dependency Type 5 2 3 Navigation zum Sourcecode Die Anzeige des Graphen ist mit dem analysierten Sourcecode verkn pft Klicken Sie mit der rechten Maustaste auf eine der angezeigten Komponenten und w hlen Sie im Kontextmen den Men punkt Edit um sich den Sourcecode der Komponente im Texteditor von Together anzeigen zu lassen 5 2 4 Anzeige im Klassen Diagramm M chten Sie sich das Klassendiagramm f r eine an einer Abh ngigkeit beteiligten Komponente anzeigen lassen so klicken Sie mit der rechten Maustaste die betreffende Komponente an und w hlen Sie im erscheinenden Kontextmen den Men punkt Select on Diagram Es ffnet sich die Designer Pane von Together und die betreffende Komponente erscheint innerhalb des Diagramms selektiert 177 Anhang Graphische Anzeige der Abh ngigkeiten 5 2 5 Anzeige des qualifizierten Namens M chten Sie sich den voll qualifizierten Namen einer der Komponenten anzeigen lassen so klicken Sie mit der rechten Maustaste die betreffende Komponente an und w hlen im Kontextmen den Men punkt Show Qualified Name Es ffnet sich e
294. zugegriffen so wird ebenfalls eine Abh ngigkeit auf Memberebene definiert Auf Klassenebene bleiben klasseninterne Abh ngigkeiten jedoch unber cksichtigt Der Zugriff auf lokale Methodenvariablen bleibt auf allen Ebenen unber cksichtigt B 11 Lesender Zugriff auf statisches Klassenattribut 11 1 Wird lesend auf den Wert eines statischen Attributes einer Klasse zugegriffen so wird hierdurch eine Abh ngigkeit vom Typ D_USES_ST definiert Erl uterung und Beispiel abstract public class FirmaAendernErfassenK public SeminarisMeldung speichern throws DatenbankAusnahnme SeminarisK Database starteTransaktion B 11 2 Modellierung der Abh ngigkeit im Abh ngigkeitsgraphen Ebene Abh ngigkeitstyp Knotentyp Nach Knotentyp Summary D_DEP FirmaAendernErfassenK T_ABSTR SeminarisK T_CLASS Class D_USES_ST FirmaAendernErfassenK T_ABSTR SeminarisK T_CLASS Member D_USES_ST speichern T_METHOD Database T_FIELD Wird auf ein statisches Attribut innerhalb der eigenen Klasse zugegriffen so wird ebenfalls eine Abh ngigkeit auf Memberebene definiert Auf Klassenebene bleiben klasseninterne Abh ngigkeiten jedoch unber cksichtigt 148 Anhang Schreibender Zugriff auf nicht statisches Klassenattribut B 12 Schreibender Zugriff auf nicht statisches Klassenattribut B 12 1 Erl uterung und Beispiel Wird der Wert eines Attributes einer Klasse neu gesetzt so
295. zus tzlich ber cksichtigen lassen Klicken Sie hierzu auf die kleine Schaltfl che neben dem Textfeld Es ffnet sich folgendes Auswahlfenster Select Packages EN Available content Existing and or ready to add elements Model HA Searchiclasspath Sie ImproveT com components SE le java javax org e 5 lt lt Remove lt lt sunw GI Favorites IE ee Abbildung 17 Hinzuf gen von Zielkomponenten Ihnen werden alle Pakete und Klassen die innerhalb des Classpaths liegen angezeigt Andere Komponenten z B Diagramme oder Komponenten aus dem Projekt sind f r Sie an dieser Stelle nicht sichtbar W hlen Sie die Komponenten im Classpath aus die als Ziel von Abh ngigkeiten Ber cksichtigung finden sollen Bet tigen Sie die Schaltfl che Add um die zus tzlich zu ber cksichtigenden Komponenten der Liste auf der rechten Seite hinzuzuf gen Sobald Sie Ihre Auswahl getroffen haben klicken Sie auf die Schaltfl che Ok 182 Anhang Erweiterte Funktionen und Einstellungen 6 2 Metrikanzeige 6 2 1 Speichern der Metrikergebnisse Um die Abh ngigkeits oder Komponentenmetriken zur weiteren Verarbeitung im Textformat zu speichern w hlen Sie den Men punkt Export im Kontextmen der Metriktabellen Hierauf ffnet sich folge

Volltext - Stefan Jungmayr

Contents

Download Pdf Manuals

Related Search

Related Contents