Home

Qualitätssicherung für objektorientierte Software

1. Abb 20 1 SCORESTOOL Klassendiagramm Editor Use Cases Die Spezifikation von Use Cases erfolgt im ScoresTool haupts chlich textuell wobei die Eingabe spezieller Werte wie z B der Profile s Abschnitt 8 5 ber ent sprechende vorgefertigte Eingabefelder Widgets vgl VosNen98 erfolgt Das Hauptfenster des Spezifikations Editors f r Use Cases ist in Abb 20 2 gezeigt Use Case Schritte und Use Case Schrittgraphen In einem speziellen Graph Konstruktions und Visualisierungsframework sind vorgefertigte Werkzeuge zur Erstellung gerichte ter Graphen oder B ume enthalten Use Case Schritte werden direkt im Use Case Bankautomat Use cases I Name Anmelden Steps Weight Usage Criticality RTechnical RBusiness RProject 18 high medium high high Vorbedingung Kartenleser betriebsbereit Bedienpult gesperrt H Beschreibung Nach Eingabe der Karte durch den Bankkunde liest der Bankautomat den Code vom Magnetstreifen und pr ft ihn auf Zul ssigkeit Bei zul ssigem Code fordert der Bankautomat die Eingabe der Identifikationsnummer PIN Der Bankkunde gibt die PIN Anmelden D e gt Le ein Der Bankautomat berpr ft die PIN falsche PIN eingegeben so wird der Versuch nez hlt nach drei Fehlversurhen wird die Karte Nachbedingung Karte ausgeworfen oder Zentralrechner busy Karte ausgeworfen und Kartenleser betriebsbereit
2. Kartenleser Transaktion Bedienpult Auszahlung ZentralrechnerSchnittstelle Belegdrucker Geldausgabe Bargeld Abb 4 3 Vereinfachtes Objektdiagramm zum Use Case Geld Abheben Ein Interaktionsdiagramm fiir den normalen Ablauf des Use Cases Geld Abheben zeigt Abb 4 4 Im Diagramm sind fast alle Ereignisse direkt durch eine Operation an der Benutzungs schnittstelle Klasse Bedienpult ausgel st und keine komplexen internen Abl ufe model liert 45 Fallbeispiel Bankautomat aqrey Tpery emp quufugus spuny ted usj smeny uejiemsne sJ1eyyTpsay usJ smenyaz ey uspusoguorzyesuei Botsgsduntyezsny uap Jwufugus epuny req usxonzadstsgsbuntyezsny usgs sne Pia u q b bsnypT 9 pre auaqebebsne sep quwtujue epuny sq ueqebsnypteo yo untyezsny Le us JNAgG eAAOApTsy Le S Voyn aduntyezsny Berzsgsbuntyezsny Per S usp pun oyuoy ute uns Temuesbuntyezsny FTypm epuny zeg j uebtezue spupysoquoy pun uequoy uoquoya raz uequoyez jes usquoyqr3 Buntyezsny Buntyezsny u ITyem opuny Zeg usbrozue gt us4rexuorIsgustysgea NIdezjes Je ute n a eutes 1 aqtB puny req u
3. N Konto read Operation gt gt Vererbung Auszahlung pr fe C Konto modify gt Benutzung rg Polymorphe Benutzung Abb 16 1 KBD f r einige Operationen im Dom nen Klassenmodell des Bankautomaten lementation an welches alle m glichen Interaktionen zwischen Objekten der Implementation unter Beachtung der Vererbungsstruktur erfasst Hierbei betrachten wir als Interaktionen den Botschaftsfluss sowie m gliche Zustands nderungen aufgrund einer Botschaft Weitere Details bez glich interner Interaktionen in objektorientierten Anwendungen sind in Anhang A 2 ausgef hrt Im Folgenden skizzieren wir wie aus dem Quellcode der Anwendung das Klassen Bot schaftsdiagramm f r die Implementation KBDp abgeleitet werden kann welches genau die sen Zweck erf llt In Anhang A 3 ist zus tzlich zur formalen Definition des KBD ein Algorithmus zu seiner Konstruktion aus den Java Quellcodes der Anwendung angegeben Analog zu den im KBD erfassten Benutzungsbeziehungen gehen wir bei der Ableitung des KBD von folgenden Beobachtungen aus Q Die Quelle einer Botschaft liegt syntaktisch eindeutig identifizierbar in einer im Kon text eines Objekts ausgef hrten Methode die wir Quellmethode der Botschaft nen nen Das den Kontext angebende Objekt ist Instanz einer eindeutig bestimmten Klasse Q Das Zielobjekt einer Botschaft ist ein Objekt dessen Klasse bei ungetypten Sprachen nicht syntaktisch ermittelbar ist
4. id AH 10 2 Use Case Kanten berdeckung Als zweite m chtigere Metrik stellen wir die Use Case Kanten Uberdeckung cF vor die das Pendant zur Zweig berdeckung c eines Kontrollflussgraphen ist vgl Riedemann97 Wir definieren die zwei Hilfsfunktionen StepGraph allEdges zur Ermittlung der Kanten menge eines Use Case Schrittgraphen uc 10 3 und TestScenario visitedUseCaseEdges uc allEdges ucs ucs uc steps x uc steps UCS UCS successors 10 3 zur Ermittlung der von einem Test Szenario ts berdeckten Kanten des Use Case Schrittgra ts visitedUseCaseEdges uce e uc allEdges I15 tss e ts steps 10 4 tss tss SUCCessor A tss UseCaseStep tss UseCaseStep uce phen 10 4 F r einen Use Case uc ergibt sich damit die Kanten berdeckung zu SE U e uc validationProtocol ts visitedUseCaseEdges 10 5 1 uc allEdges size Es ist Sa 1 wenn jede Kante im Use Case Schrittgraph in mindestens einem Test Szena rio durchlaufen ist Beispiel 10 2 In dem in Abb 10 1 b skizzierten Schrittgraph sind die von Test Szenarien berdeckten Kanten fett hervorgehoben Nach 10 5 ist eine Use Case Kanten Uberdeckung von cy 66 66 erreicht m 118 Validierungsmetriken 10 3 Use Case Szenario berdeckung Die Use Case Kanten berdeckung ist nicht ausreichend da einerseits bei vollst ndiger Kan ten berdeckung nicht unbedingt alle Endschritte des Use Case Schrittgrap
5. a A g Sien UseCaseStep ctor S j A 1 rootClass Class successors 4 o 1 A InteractionStep ContextualStep MacroStep o P a Feature Operation 3 1 rootOperation Abb 7 2 Erweitertes Use Case Metamodell den Wurzelklasse und Wurzeloperation werden durch die Assoziationen rootClass und roo tOperation zwischen Objekten der Klassen InteractionStep und Class bzw Operation abgebildet 7 5 Vollstandigkeitsmetriken Metriken dienen dem quantitativen Verst ndnis von Entwicklungsprodukten und sind mit tlerweile integraler Bestandteil der objektorientierten Softwareentwicklung und des Softwa re Engineering allgemein vgl Henderson96 Hierbei werden Produktmetriken von Prozessmetriken unterschieden W hrend erstere sozusagen als Schnappschuss den Stand des Produkts zu einem bestimmten Zeitpunkt widerspiegeln geben letztere statistische Ten denzen der Entwicklung ber einen Zeitraum an und ben tigen zu ihrer Interpretation zus tz liche Modelle In Hendersons Worten Process contains a time rate of change and requires a process model to fully understand what is happening Henderson96 Wir beschr nken uns in dieser Arbeit auf Produktmetriken und wollen in diesem Abschnitt mit Vollst ndigkeitsmetriken messen wie eng das Klassenmodell und die Use Cases bzw Use Case Schrittgraphen der Anforderungsspezifikation miteinander gekoppelt sind Validie 92 Kopplung von Use Cases und Klassenmodell rungs und Verifika
6. seines Generierungsziels z B Transformation der Objektkonstellation in Testskripte welche die Konstellation in der Zielumgebung aufbauen eine Regelmenge aus und legt mit Hilfe von sogenannten globalen und lokalen Strategien eine ad quate Aus wertungsstrategie fest Nach Aktivierung des Scanners der die Modelle der SCORES Anfor derungsspezifikation als Tokenstrom an den Parser des Frameworks bergibt erstellt der Parser einen attributierten Syntaxbaum in einer tempor ren Datenstruktur Der Evaluator des Frameworks wertet den Syntaxbaum gem der gew hlten Auswertungsstrategie und der zu geh rigen Regelmenge aus Das Ergebnis wird wahlweise in einem Browser angezeigt oder in eine Datei ausgelagert und ggf von einem Testwerkzeug CAST Computer Aided Softwa re Testing gelesen Szenariogenerierung Testkriterien bzw entsprechende Metriken dienen einerseits zur Kontrolle der Tests und andererseits zur gezielten Ableitung von Testf llen In Be zug auf die Validierungsmetriken k nnen in der Testkomponente des SCORESTOOL Szenario Browsers weitere Test Szenarien zur Erreichung der 100 igen Use Case Knoten Kanten Grenze Inneres und Szenarien berdeckung generiert werden Abb Test 207 20 10 zeigt noch einmal die Metrik Sicht des Szenario Browsers nachdem durch Anklicken des entsprechenden 1 0 Buttons die Generierung von Szenarien zur 100 igen Use Case Kanten berdeckung erfolgt ist Die generierten Test Szen
7. 88 Kopplung von Use Cases und Klassenmodell Betrachten wir hierzu noch einmal die Beispiele in den vorherigen Kapiteln Die Bedingun gen beschreiben einerseits den Zustand konkreter Anwendungs bzw Realweltobjekte vor und nach der Bearbeitung der Aufgabe also z B Bankautomat Betriebsbereit oder Karte Lesbar Andererseits werden auch ber den Zustand einzelner Objekte hinaus Aussagen z B der Art Es existiert ein Objekt der Klasse Konto mit oder PIN dreimal falsch einge geben gemacht Ein Use Case ist eine statische Beschreibung von mehreren m glichen Abl ufen bzw Szenarien die bei der Bearbeitung einer Aufgabe auftreten k nnen Insbesondere soll ein Use Case Szenarien f r den normalen Ablauf alternative Abl ufe und Ausnahmeabl ufe beinhal ten Jedem Szenario liegt eine bestimmte Objektkonstellationen zugrunde Als abstrahierende funktionale Beschreibung kann ein Use Case die Menge m glicher Objektkonstellationen als Zustand einer Anwendung bzw als Manifestation ihres bisherigen Ablaufs nur ab strahierend durch Angabe der Klassen und ggf weiterer Bedingungen beschreiben In der Anforderungsermittlung bevorzugt man daher die Modellierung auf der Klassenebene vgl CoaYou90 Meyer97 RBP 91 WalNer95 Dabei darf jedoch nicht vergessen wer den dass f r den Benutzer wenn berhaupt nur konkrete Konstellationen von Realwelt objekten aus seinem Anwendungsgebiet verst nd
8. Ausl ser bzw das ausl sende Ereignis der Aufgabenausf hrung enthalten muss sollte der Startschritt offensichtlich ein Wurzelschritt sein Regel 5 4 4 Schrittgraph Startschritt Der Startschritt zu eines Use Cases uc muss ein Wur zelschritt sein o sg 2 S uc so Ebenso muss jedes Szenario welches einen Schritt ohne Folgeschritte enth lt mit diesem Schritt enden Wir erhalten die n chste Modellierungsregel Regel 5 4 5 Schrittgraph Endschritte Alle Schritte ohne Nachfolgeschritt m ssen in der Menge der Endschritte des Use Case Schrittgraphen enthalten sein Y se S uc o s gt s e SE uc Der Fall SE uc ist definitorisch ausgeschlossen Wir m ssen allerdings beachten dass Regel 5 4 5 Endschritte mit Nachfolgeschritten erlaubt Szenarien k nnen in ihrem Verlauf mehrere Endschritte durchlaufen Solange es noch m glich ist die Aufgabe erfolgreich zu bearbeiteten werden Alternativen und Ausnahmebehandlungen versucht Im Extremfall kann SE uc S uc sein Use Case Schritte und Schrittgraphen entsprechen einer funktionalen Zerlegung bei der Auf gaben auf verschiedenen Abstraktionsgraden modelliert werden Zyklische Benutzungen bzw Referenzen durch Makroschritte deuten hierbei erfahrungsgem oft auf eine unsaubere Zerlegung oder auf vorweggenommene Navigationsm glichkeiten der Benutzungsschnitt stelle hin Analog zur Benutzungsstruktur in Modulgraphen siehe z B PagSix94 fordern wir auch bei
9. Freistil Entw rfe f hren erfahrungsgem nur bei kleinen Projekten zu lauff higen Anwendungen vgl Hatton98 Lauesen98 Rein transformatori sche Entw rfe auf der Grundlage formaler Spezifikationen sind zumindest heute nur in eng eingegrenzten Dom nen wie z B bei eingebetteten Echtzeitsystemen m glich vgl Lauesen98 TheGot98 Da wir diese Arbeit im Umfeld kommerzieller Anwendungen z B Informationssysteme an siedeln konzentrieren wir uns auf manuelle Entw rfe bei denen die Entwurfsfreiheit durch die Architektur sowie die Entwurfsmethodik eingeschr nkt wird vgl Shaw94 ShaGar96 GHJ 94 BMR 97 Wie wir sehen werden m ndet der Entwurf mit OOSE in eine Archi tektur mit den drei Schichten Benutzungsschnittstelle Anwendungslogik und Datenhaltung s z B ShaGar96 BMR 97 Allgemein halten wir fest je klarer die Architekturvorgabe ist und je disziplinierter sie eingehalten wird desto schematischer und nachvollziehbarer wird der Entwurf und die Implementation Jacobsons OOSE stiitzt sich im Prinzip auf fiinf Modelle Abb 2 7 LI das Anforderungsmodell requirements model spezifiziert mit Use Cases die funkti onalen Anforderungen an die zu entwickelnde Anwendung m das Analysemodell analysis model spezifiziert mit einem Klassenmodell m glichst robust und leicht nderbar die strukturellen Anforderungen Q das Entwurfsmodell design model verfeinert das Analysemodell im Hinblick auf die gew h
10. In Kapitel 3 wenden wir uns der Qualit tssicherung in der objek torientierten Softwareentwicklung zu Da die Komplexit t hier in den Interaktionen zwischen Objekten liegt erweisen sich strukturelle white box Klassentests als wenig aussagekr ftig Aufgrund des z T sehr hohen Aufwandes ist ihr Einsatz nicht ef fektiv F r funktionale black box Tests der Anwendung gegen die Anforderungsspezifikation sind im Falle objektorientierter Anforderungsspezifikationen neue Verfahren notwendig wo mit wir bei der Kernthematik der Arbeit angelangt sind In Kapitel 4 listen wir Schwachpunkte der objektorientierten Anforderungsspezifikation mit Use Cases und Klassenmodellen auf welche die Qualit tssicherung bei der Anforderungsermitt lung und den Test der Anwendung gegen die Anforderungsspe zifikation betreffen In diesem Zusammenhang stellen wir auch relevante Arbeiten anderer Autoren zu diesen Themen vor Ein Zwischenfazit beendet diesen Teil Kapitel 1 Motivation und berblick Irren ist menschlich berliefert Am 4 Juni 1996 endete der Jungfernflug der Ariane 5 Rakete Flug 501 40 Sekunden nach dem Start in einer H he von rund 3700 m mit der Selbstzerst rung der Rakete Der offizielle Untersuchungsbericht beschreibt den Hergang folgenderma en The launcher started to disintegrate at about HO 39 seconds because of high aerodynamic loads due to an angle of attack of more than 20 degrees that led to separation of the
11. Q Benutzungskanten stellen wir durch einen geschlossenen ausgef llten Pfeil von der benutzenden zur benutzten Operation mit der Spitze zur Zieloperation dar Q Gehen Benutzungskanten an redefinierte Operationen polymorph substituierbarer Zielklassen Relation P so werden ihre Ausgangspunkte zusammengelegt Beispiel 16 1 Aus den in den Abbildungen 11 1 12 2 und 12 3 dargestellten Episoden ermit teln wir mit dem Algorithmus Generiere KBDA s Anhang A 1 die Benutzungsbeziehun gen zwischen Operationen der Klassen Karte Transaktion Auszahlung und Konto Abb 16 1 Wir erkennen dass die Operation Transaktion pr fe in der Unterklasse Auszahlung redefiniert wird Operation f hrePlanAus welche in der Klasse Transaktion definiert und in der Klasse Auszahlung unver ndert geerbt ist benutzt polymorph je nach der Klasse des ausf hrenden Objekts die beiden Operationen Transaktion pr fe und Auszahlung pr fe m 16 2 Klassen Botschaftsdiagramm der Implementation Das KBD stellt in kompakter Art und Weise die Abh ngigkeiten im Dom nen Klassenmo dell zusammen Wir streben analog dazu ein m glichst einfaches Test Modell f r die Imp Klassen Botschaftsdiagramm der Implementation 171 Transaktion pr fePIN C Transaktion offline q Karte modify Karte prifePIN Zentralrechnersch nittstelle priifePIN Transaktion fihrePlanAus 4 Transaktion pr fe
12. jeweils kopiert und f r die Reihenfol getests manuell angepasst Chang etal pr sentieren einen Ansatz zum high level test f r objektorientierte Anwendun gen der auf einer formalen Spezifikation in Object Z vgl DKR 91 CarSto94 und Nutzungsprofilen usage profiles basiert CLS 98 Sie schreiben The behavior of a software system is specified in an object oriented formal specification A state model provides a complementary representation of the dynamic behavior In the model a state represents the cumulative results of the system behavior Probability distributions are used to de rive the anticipated operation sequences of a program from the state model An enhanced state transition diagram ESTD is used to describe the state model which incorporates hierarchy us age and parameter information This paper describes the construction of state transition diagrams STDs based on the formal specification and the derivation of test scenarios from the ESTD CLS 98 Einen berblick ber die Methode gibt Abb 3 2 Die manuell auszuf hrenden T tig keiten sind durch die stilisierte ausf hrende Person gekennzeichnet wobei insbeson dere die Konstruktion der Zustandsautomaten aus den Object Z Spezifikationen bisher nur manuell unter Einsatz von Heuristiken m glich ist The derivation guideline for the ESTD requires extensive human effort A subset of the Object Z grammar is being investigated to study the possibility
13. mock up ge nannt Diese Elemente werden dann in animierten Walk Throughs zusammen mit den auf bereiteten Objektkonstellationen dargestellt Die Beteiligten simulieren bei einem Walk Through den Use Case Schritt f r Schritt unter Ber cksichtigung des jeweiligen Anwendungs Zustands d h der jeweiligen Objektkon stellation Hierbei konzentrieren sich die Benutzer und Dom nenexperten auf die textuellen Spezifikationen der Schritte bzw der bergangsbedingungen und sichern ihre Korrektheit zu Am Ende der Simulation d h wenn kein weiterer Schritt mehr notwendig bzw m glich ist wird gepr ft ob ein Endschritt im Use Case Schrittgraph erreicht ist und der sich erge 112 Validierung bende Ablauf und die resultierende Objektkonstellation mit dem erwarteten Gesch ftsvorfall verglichen Falsche fehlende und mehrdeutige Schritte werden zusammen mit dem Pfad und Kommentaren protokolliert korrigiert und erneut validiert Gesch ftsvorf lle werden so zu Testf llen der Anforderungsspezifikation Da hierbei auch die Verantwortlichkeiten der beteiligten Klassen gepr ft werden sind somit implizit auch zumindest Teile des Klassenmodells validiert Hauptaugenmerk richten die Analytiker auf fehlende unvollst ndige oder berfl ssige Klassen und Beziehungen Mehr deutigkeiten und die Ad quatheit des vorgeschlagenen Klassenmodells hinsichtlich der Use Cases Die bei der Validierung Schritt f r Schritt durchlaufenen Szenari
14. myB a 7B super c S 14B und 15B Abb A 4 Direkte Intra Klassen Inter Objekt Aufruf Interaktionen Bez glich der direkten Intra Klassen Inter Objekt Interaktionen betrachten wir Tabelle 22 1 Spalte B sowie Abb A 4 Da berschriebene Methoden au erhalb eines Objekts in Java im Gegensatz zu c s auch BlaFr 98 nicht durch eine explizite Typangabe vor dem Aufruf zugreifbar sind primary bzw cast GJS96 sind ihre Aufrufe bei Inter Objekt Interaktio nen in Java nicht m glich wohl aber die Tatsache dass berschriebene Methoden durch vor heriges super selbst ausgef hrt werden und somit auch Aufrufer sein k nnen Im Gegensatz zu berschriebenen Methoden sind berschriebene Variablen durch entsprechende Typ Kon vertierungen cast von aussen zugreifbar Gosling et al schreiben hierzu Indeed there is no way to invoke the overridden getX method of class Point for an instance of class RealPoint from outside the body of RealPoint no matter what the type of the variable we may use to hold the reference to the object Thus we see that fields and methods behave different ly hiding is different from overriding GJS96 Wir fassen unsere bisherigen Uberlegungen zusammen Als direkte Aufrufinteraktionen ha ben wir die durch die Schliisselworte this bzw super erkenntlichen dynamisch bzw statisch gebundenen selbstrekursiven vgl BlaFr 98 Aufrufe sozusagen als M glichkeiten der ver ti
15. Bei jeder Ausf hrung eines einfachen also mit this oder gar nicht gekennzeichneten Metho denaufrufs ml wird dynamisch also zur Ausf hrungszeit gebunden eine in der Klasse TYP ml oder einer ihrer Unterklassen s Funktion PolyKBDI in Abb 22 4 definierte Methode ausgef hrt Im Gegensatz dazu sind die mit super bzw new ge kennzeichneten Methodenaufrufe statisch an eine bestimmte syntaktisch ermittelbare Methodendefinition gebunden vgl GJS96 s a M lPoe98 Q F r eine Klasse k ergibt der Ausdruck k InstanceVariables die Menge aller innerhalb der Methoden von k sichtbaren Instanzvariablen m F r eine Instanzvariable i ergibt die Funktion DEFCLASS i die i definierende Klasse Q F r einen Ausdruck e ergibt die Funktion VARIABLES e die Menge der in e vorkom menden Variablen Fassen wir zusammen Das Klassen Botschaftsdiagramm stellt mit jedem Knoten eine Me thode dar Mit den Kanten werden entweder direkte Aufruf bzw Dateninteraktionen oder aber Vererbungsbeziehungen dargestellt Weitere Anwendungen des KBD Die Ermittlung bzw Verfeinerung von Integrations Strategien auf der Basis des KBD ist in Winter98 beschrieben Dar ber hinaus ist es m glich mit dem KBD die Menge der f r ei nen Regressionstest erneut auszuf hrenden Testf lle einzugrenzen Von einem exempla risch f r Anwendungen in der Programmiersprache Smalltalk 80 GolRob89 implementierten Testwerkzeug wird das KBD generiert Mit Hilf
16. Calif 1998 KniMye93 John C Knight E Ann Myers An Improved Inspection Technique Communica tions of the ACM Jahrg 36 Nr 11 1993 S 51 61 K sters97 Georg K sters Requirements Engineering f r GIS Applikationen Dissertation Fachbereich Informatik FernUniversit t Hagen 1997 KPS95 Georg K sters Bernd Uwe Pagel Hans Werner Six Software Engineering II Kurs 1794 FernUniversit t Hagen 1995 226 KPS96 Georg K sters Bernd Uwe Pagel Hans Werner Six GeoOOA Object Oriented Analysis for Geographic Information Systems Proc of the 2 d International Con ference on Requirements Engineering Colorado Springs 1996 KPW97 Georg K sters Bernd Uwe Pagel Mario Winter Coupling Use Cases and Class Models in Andy Evans Kevin Lano Hrsg Proc of BCS FACS EROS Work shop on making object oriented methods more rigorous London GB Juni 1997 KPR 97 Georg K sters Bernd Uwe Pagel Thomas de Ridder Mario Winter Animated Requirements Walkthroughs Based on Business Scenarios Proc 5 euroSTAR 97 Edinburgh Scotland Nov 1997 CD ROM KPW98 Georg K sters Bernd Uwe Pagel Mario Winter Kombinierte Validierung von Use Cases und Klassenmodellen Proc Modellierung 98 M nster M rz 1998 S 117 121 Kruchten99 Philippe Kruchten Der Rational Unified Process OBJEKTspektrum 1 99 Jan Feb 1999 S 38 42 KSV96 Georg K sters Hans Werner Six Josef Voss Combined Analysis of User Interface and Domain Requi
17. CooDan94 des KBD gezeigt 248 Klassen Botschaftsdiagramme Wir betrachten hierzu die in Abschnitt A 2 aufgez hlten M glichkeiten der Interaktion nach einander und unterscheiden jeweils im Kontext der Klasse des aufrufenden bzw aufgerufe nen Objekts LI neu definierte N LI redefinierte R sowie LI unver ndert geerbte 1 Methoden vgl PerKai90 HMGF92 HKR 97 und zus tz lich auch noch LI berschriebene Methoden overridden hidden O vgl BlaFr 98 Daneben betrachten wir den Fall des Aufrufs einer identischen Methode jeweils gesondert Rekursion s auch BlaFr 98 Zur Illustration zeigen wir dieses Vorgehen f r direkte Intra Klassen Interaktionen Zum Schluss skizzieren wir kurz den Fall indirekter Interaktionen Direkte Intra Klassen Interaktionen in Java F r die Intra Klassen Interaktionen ergeben sich die in Tabelle 22 1 gezeigten Kombinatio nen von aufrufender Methode m1 in Objekt 01 Sender und aufgerufener Methode m2 in Objekt 02 Empf nger Unterschiede bei Klassen und Instanz Methoden sind durch vor angestelltes I bzw C kenntlich gemacht Betrachten wir zun chst die direkten Intra Klassen Intra Objekt Interaktionen in Tabelle 22 1 Spalte A f r die Abb A 3 jeweils Beispiele zeigt Insbesondere die Interaktionsarten 10 A und 14 A spiegeln die Kernidee der Erweiterung ob jektorientierter Klassen durch das berschreiben sogenannter Template Methoden s GHJ 94 wi
18. In Java nicht m glich C nach Cast 17 x x m1 m2 echte Rekursion m1 m2 strukturelle Rekursion Iterator Tab 22 1 Direkte Intra Klassen Aufruf Interaktionen Indirekte Interaktionen in Java Haworth et al bezeichnen sowohl neu als auch redefinierte Methoden bzw Variablen als lokal und unver ndert geerbte sowie berschriebene Methoden bzw Variablen als geerbt HKR 97 Sie notieren indirekte Intra Klassen IntraObjekt Interaktionen in der Form lt m1 v m2 gt wobei m1 den Typ der schreibenden Methode v die Art der betroffenen Vari ablen und m2 die Art der lesenden also beeinflussten Methode bedeuten Hierbei k nnen sol che zwischen je einem modifizierenden Zugriff und lesenden Zugriffen liegenden Interaktionen vernachl ssigt werden welche die modifizierte Variable nicht erneut modifi zieren man betrachtet also im Prinzip analog zum datenflussbasierten Test sogenannte def uses Paare vgl Beizer90 Beizer95 Myers79 PagSix94 Riedemann97 So be deutet z B das Tripel lt N I R gt dass nach der Modifikation einer Variablen durch eine neu definierte Methode eine geerbte Methode die modifizierte geerbte Variable liest 251 Direkte Interaktionen im KBD Wir betrachten zun chst wie das KBD direkte Interaktionen also Methodenaufrufe re flektiert Im Gegensatz zu den Modellen in HMGF92 und HKR 97 beschr nkt sich das KBD nicht auf Aufrufe innerhalb einer Klasse bzw eine
19. ModelElement alllnstances die Menge aller Modellierungselemente Jede Instanz der Klasse Dependency bzw einer der angesprochenen Unterklassen erfasst eine Teilmen ge von M F r ein Modellierungselement x bedeutet jede Assoziation zu einer Instanz f von Dependency dass x abh ngig von jedem anderen an der Assoziation beteiligten Modellie rungselement y t Client ist Die Menge aller Instanzen von Dependency ergibt mit der quivalenz 13 1 eine reflexive symmetrische Relation dependsOn c M x M dependsOn x y dd e Dependency alllnstances x e d Client y e d Client 13 1 Ebenso k nnen wir speziellere Relationen refinedBy oder tracesTo definieren Sei z B m ein Modell der Anforderungsspezifikation mp ein Entwurfsmodell und m die Implementa tion F r ein bestimmtes Element der Anforderungsspezifikation x m erhalten wir mit dem Ausdruck 13 2 die Menge aller Abh ngigkeiten die x enthalten x allDependencies de Dependency alllnstances x e d client 13 2 Die Menge aller Entwurfselemente die zu x zur ck verfolgbar sind erhalten wir dann mit dem Ausdruck 13 3 x allDesignElements y m dependsOn y 13 3 Dementsprechend ermitteln wir mit 13 4 die Menge aller das Element x der Anforderungs spezifikation im Entwurf verfeinernden Modellelemente x allDesignRefinements y mp refinedBy x y 13 4 F r unsere Belange gen gen diese Ausf hrungen Wie bzw durch wen oder welche T tigkeit d
20. Peter Wegner Why Interaction is More Powerfull than Algorithms Communica tions of the ACM Jahrg 40 Nr 5 May 1997 WegGol99 Peter Wegner Dina Goldin nteraction as a Framework for Modeling Technical Report Brown University erscheint in LNCS 1565 Springer Berlin April 1999 Weihrauch87 Klaus Weihrauch Computability EATCS Monographs on Theoretical Com puter Science Nr 9 Springer Berlin 1987 Weyucker86 Elaine J Weyuker Axiomatizing Software Test Data Adequacy IEEE Transac tions on Software Engineering Nr 12 Dez 1986 S 1128 1138 WFMC97 Workflow Management Coalition The Workflow Reference Model Dok Nr TC00 1003 Issue 1 1 WFMC Br ssel 1997 233 Wiegers98 Karl E Wiegers Read my Lips No New Models TEEE Software Sep Okt 1998 S 10 13 Winter97 Mario Winter Reviews in der objekt orientierten Softwareentwicklung TAV 10 6 7 03 1997 B blingen in GI Softwaretechnik Trends 17 Jahrg Heft 2 Mai 1997 S 6 11 Winter98 Mario Winter Managing Object Oriented Integration and Regression Testing Proc 6 euroSTAR 98 M nchen Dez 1998 S 189 200 Winter99 Mario Winter Zur Komplexit t der Generierung von Daten f r objektorientierte Anwendungen Technischer Report FernUniversit t Hagen 1999 WPJ 98 Klaus Weidenhaupt Klaus Pohl Matthias Jarke Peter Haumer Scenarios in Sys tem Development Current Practice IEEE Software Marz April 1998 S 34 45 Wulf2000 Cornelia Wulf Validierung einer
21. Teil Aufgaben eines Use Cases bearbeitet werden k nnen Wir modellieren sozusagen den Kontrollfluss eines Use Cases Hierzu streben wir eine der strukturierten Programmierung entsprechende Ausdrucksst rke an m ssen also in der Lage sein die sequentielle alternative und die wiederholte Bearbei tung der Aufgaben zu modellieren In Analogie zu verallgemeinerten Flussdiagrammen vgl Weihrauch87 ordnen wir jedem Use Case Schritt eine Menge m glicher Nachfolgeschritte Use Case Schrittgraphen 65 zu Zus tzlich markieren wir genau einen Schritt des Use Cases als sogenannten Startschritt und eine nichtleere Teilmenge der Schritte eines Use Cases als sogenannte Endschritte Pr zisieren wir diese berlegungen so kommen wir zur folgenden Definition Definition 5 4 Ein Use Case Schrittgraph zu einem Use Case uc ist ein 4 Tupel UCG S so SE o mit 1 S ist eine nichtleere Menge von Use Case Schritten Knoten 2 Sg S ist der Startschritt des Use Case Schrittgraphen 3 SE c S ist die nichtleere Menge der Endschritte des Use Case Schrittgraphen 4 oc SxS ist die Menge der gerichteten Kanten des Use Case Schrittgraphen Jede Kante e s s e o wird mit einer Zusicherung oder bergangsbedingung c e an notiert die angibt unter welcher Bedingung s als Folgeschritt ausgew hlt wird LI Die Beschr nkung auf genau einen Startschritt f r jeden Use Case Schrittgraphen folgt aus der grundlegenden Eigenschaft
22. The process of studying user needs to arrive at a definition of system hardware or software requirements 2 The process of studying and refining system hardware or software requirements IEEE610 90 Zum Begriff der Anforderung requirement lesen wir in der IEEE 610 Requirement 1 A condition or capability needed by a user to solve a problem or achieve an ob jective 2 A condition or capability that must be met or possessed by a system or system compo nent to satisfy a contract standard specification or other formally imposed document 3 A documented representation of a condition or capability as in 1 or 2 IEEE610 90 Nach dem IEEE Standard 830 Guide to Software Requirements Specifications werden bei der Spezifikation von Anforderungen solche die das externe beobachtbare Verhalten betref fen functional requirements von technischen Anforderungen und Qualit tsanforderungen non functional requirements unterschieden IEEE830 93 Oo Externes Verhalten e Funktionen oder Eigenschaften Operationsfolgen alternative Abl ufe und Ausnah mebehandlungen zu beachtende Gesch ftsregeln e Externe Schnittstellendefinitionen Ein Ausgabedaten Datenbankanbindungen 1 Funktionale Anforderungen werden auch als behavioral requirements Davis90 oder operative Anforderungen PagSix94 bezeichnet Gesch ftsprozesse und Anforderungsermittlung 17 Q Nichtfunktionale Anforderungen
23. Weyucker stellt eine Reihe von Axiomen zur analytischen Bewertung von Testkriterien auf Gefordert wird dass vern nftig formulierte Testkriterien alle Axiome erf llen sollen Weyucker86 Perry und Kaiser benutzen die Axiome zur Angabe einiger insbesondere durch das Konzept der Vererbung bedingter Probleme der Testbarkeit objektorientierter An wendungen PerKai90 Diese Probleme lassen die Anwendbarkeit herk mmlicher Testkri terien f r objektorientierte Anwendungen zweifelhaft erscheinen vgl Binder94 JorEri94 HAKR 97 Wir schlagen daher in diesem Kapitel einige Testkriterien f r den Test von objektorientierten Anwendungen vor Hierbei unterscheiden wir Q funktionsbezogene Kriterien die auf dem Use Case Schrittgraph basieren von Q strukturellen Kriterien die sich auf die Implementation beziehen Diese unterteilen wir weiter in 188 Endekriterien Ausf hrung und Auswertung e strukturell ablaufbezogene Kriterien die sich an den Aufruf Interaktionen orientie ren und e strukturell datenbezogene Kriterien welche sich auf die Daten Interaktionen kon zentrieren Funktionsbezogen Selbstverst ndlich sollte die Anwendung in den System und Abnahmetests gegen alle Use Cases bzw Test Szenarien gepr ft werden Anhand der in den Tests gegen die Anforde rungsspezifikation erzielten berdeckung der Use Case Schrittgraphen messen wir die funktionale Vollst ndigkeit der Tests Hierf r verwenden wi
24. arbeitenden Ansatz zur objektorientierten Anwen dungsentwicklung Z llighoven98 Zentrale Idee dieses Ansatzes ist die Gegenst nde und Konzepte des Anwendungsbereichs als Grundlage des softwaretechni schen Modells zu nehmen Das Ergebnis soll eine enge Korrespondenz zwischen dem anwen dungsfachlichen Begriffsgeb ude und der Softwarearchitektur sein Diese Struktur hnlichkeit hat zwei entscheidende Vorteile Die Anwender finden die Gegenst nde ihrer Arbeit und die Begriffe ihrer Fachsprache im Anwendungssystem repr sentiert Sie k nnen entsprechend ihre Arbeit in gewohnter Weise organisieren Die Entwickler k nnen Softwarekomponenten und Anwendungs 54 Probleme der Anforderungsermittlung mit Use Cases konzepte bei fachlichen und softwaretechnischen nderungen zueinander in Beziehung setzen und somit die wechselseitigen Abh ngigkeiten erkennen Z llighoven98 Nach unserer Begriffsbildung deckt der Ansatz von Z llighoven die funktionale Sicht Werkzeuge und Automaten die Informationssicht Materialien und mit dem Leitbild des Arbeitsplatzes auch Teile der organisatorischen sowie der Leistungs sicht ab Als fachliches Modell zur Ist Analyse dient dabei in erster Linie das Daten w rterbuch aus dem sich die Objekte des Anwendungsbereichs herauskristallisieren sollen Diese werden dann ggf nach nderungen am Gesch ftsprozess in Do m nenklassen transformiert bzw auf solche abgebildet welche das so
25. bei getypten Sprachen kann sie eine von mehreren polymorph substituierbaren Klassen sein die syntaktisch ermittelbar sind Versteht das Ziel die Botschaft so entspricht dies der Ausf hrung einer anhand der Verer bungsstruktur zu ermittelnden Methode der Zielmethode der Botschaft 172 SCORES grey box Test Q Der aktuelle Zustand als quivalenzklassen von Werten der Klassen und Instanzva riablen vgl Binder96a bestimmt den Ablauf der Methoden wobei diese Variablen innerhalb von Methoden gelesen und modifiziert werden Als Knoten des KBD kommen prinzipiell Klassen Objekte Methoden oder einzelne Anwei sungen in Frage Klassen scheiden als zu grobgranular aus da Botschaften nur innerhalb von Methoden erzeugt werden Objekte als Knoten w rden das Modell auf die jeweils betrachtete Objektkonstellation einschr nken und somit in einem Modell nicht alle m glichen Interakti onen erfassen W rden wir den Knoten einzelne Anweisungen zuordnen so m ssten wir zus tzlich eine dem Kontrollfluss innerhalb der Methoden entsprechende Kantenart zuf gen die jedoch keiner Botschaft entspr che Dies w rde der Forderung dass wir uns auf die durch Botschaften m glichen Interaktionen zwischen Objekten in einer Anwendung kon zentrieren wollen zuwiderlaufen Dar ber hinaus w re die Granularit t des so entstehenden Graphen zu fein f r den Test einer vollst ndigen Anwendung Wir w hlen daher member GJS96 oder Featur
26. dikate genannt vgl PagSix94 und Ausdr cken wobei wir zudem Selektoren mit boole schen R ckga bewerten sowie Vergleiche als Terme ansehen 138 Verifikationsmetriken Q Die Vorbedingung muss vor der Bearbeitung der Teil Aufgabe des Schritts erf llt sein dies schr nkt die Anzahl der ben tigten Testf lle ein und gibt Hinweise auf notwendige Initialisierungen Insbesondere muss die Vorbedingung des Use Cases vor dem Test erf llt sein Q Die Nachbedingung wird von der Aufgabe des Schritts zugesichert wenn vor ihrer Bearbeitung die Vorbedingung erf llt ist die Nachbedingung spezifiziert also ei nerseits das erwartete Ergebnis der Testf lle Andererseits k nnen wir versuchen durch die Auswahl gewisser Eingangsdaten eine bestimmte Belegung der Terme der Nachbedingung zu erzwingen oder sogar die Aufgabe des Schritts quasi so zu sa botieren dass die Nachbedingung trotz erf llter Vorbedingung nicht erf llt wird Genauso wie in bedingten Anweisungen oder Schleifen innerhalb von Methoden der Kon trollfluss gesteuert wird steuern die Bedingungen die Traversierung von Kanten und damit die Ausf hrung oder Nicht Ausf hrung der Aufgaben von Schritten Nun sollten die Bedingungen der Kanten in verschiedenen Szenarien zu einem Use Case Schrittgraph im Allg beide Wahrheitswerte true und false annehmen da sonst evtl un erreichbare Schritte berfl ssige Kanten oder nie ausgef hrte bzw nicht termi
27. e Technische Anforderungen Performanz Last Umgebungseinschr nkungen Ent wurfseinschr nkungen e Qualit tsanforderungen Nutzbarkeit Zuverl ssigkeit Sicherheit Wartbarkeit Die Anforderungsspezifikation Software Requirements Specification SRS soll als Ergeb nis der Anforderungsermittlung pr zise Vorgaben f r den Entwurf die Implementation und den Test der zu entwickelnden Anwendung liefern Die Anforderungsspezifikation soll nur beinhalten was die Anwendung leisten soll nicht aber wie diese Leistung erbracht wird Der IEEE Standard 830 fordert f r die Anforderungsspezifikation zus tzlich A good software requirements specification is unambiguous complete verifiable consistent modifiable traceable and usable during the operation and maintenance phase IEEE830 93 Die Anforderungsspezifikation als wichtiger Bestandteil des Vertrages zwischen Auftragge ber und Softwareentwickler muss f r alle beteiligten Partner verst ndlich formuliert sein Um aus dem Problembereich die relevanten Anforderungen zu extrahieren und pr zise verst nd lich und konsistent zu formulieren ist eine enge Zusammenarbeit zwischen Analytikern und Benutzern erforderlich Die Gr nde hierf r sind vielf ltig Im Allgemeinen sind Analytiker zu Beginn der Anforderungsermittlung nicht ausreichend mit dem Problembereich und seiner spezifischen Terminologie vertraut w hrend Benutzer und Auftraggeber wenig Kenntnisse ber die technisch
28. einzahlung auszahlung sperre pruefeAuszahlung Betrag kannAusgeben pruefe gibAus Bargeld Abb 7 3 Klassenmodell des Bankautomaten Vollst ndigkeitsmetriken Kartenleser Transaktion 95 Bankkunde Karte ZentralrechnerSchnittstelle Anmelden Zentralrechner Konto Abb 7 4 Use Case Anmelden Klassenbereich beginnt eine Transaktion und setzt einen betriebsbereiten Kartenleser voraus der die im Le seschlitz befindliche physikalische Kreditkarte liest und mit den Daten der Kreditkarte ein Objekt der Klasse Karte erzeugt Wir ordnen diesem Schritt also den Klassenbereich Trans aktion Kartenleser Karte zu hnlich verfahren wir mit den brigen Schritten des Use Case Schrittgraphen und erhalten die in Abb 7 5 den Schritten zugeordneten Klassenberei che Wurzelklassen und Wurzeloperationen Karte Einf hren 2 Kartenleser Ca Bankkunde Karte Lesen C ZI Kartenleser leseDaten Transaktion Karte PIN Anfordern Transaktion Bedienpult lesePIN Y E PIN gt Pr fen d Transaktion pr fePIN Zentralrechner Schnittstelle Karte Y 9 Karte Schreiben Transaktion J Auswahl comm
29. genannt wenn sich irgendein NP vollst ndiges Pro blem auf p reduzieren l t vgl GarJoh79 3 Die Namen abstrakter Klassen sind kursiv gesetzt Komplexit t 185 L sung z B Nicht l sbar a Abb 17 2 Einfache Beispiele zur polynomialen Transformation von SAT auf GOK b m glichen Belegungen der Variablen Durch die 1 1 Beziehung wird sichergestellt dass die Variable nicht gleichzeitig mit verschiedenen Werten belegt wird Belegung mit wahr w und falsch f das ausgeschlossene Dritte 2 Jedes Literal der Form a bilden wir auf eine Klasse a ab die Unterklasse der Klasse Wa ist Dementsprechend wird jedes Literal der Form a auf eine Klasse a abgebil det die wiederum Unterklasse der Klasse Wa ist Diese beiden Klassen nennen wir auch L Klassen des entsprechenden Literals sie entsprechen der Belegung der Aussa genvariablen a mit w a instanziert oder f a instanziert 3 Jeden zusammengesetzten Term bilden wir auf eine abstrakte Klasse T Klasse ab von der die T bzw L Klassen der Teilterme erben Bei einer Konjunktion f gen wir im Klassenmodell zus tzlich zwischen allen den Teiltermen der Konjunktion entspre chenden T oder L Klassen eine ungerichtete 1 1 Beziehung ein Diese Beziehungen werden zu den L Klassen vererbt und stellen die wesentlichen Beschr nkungen auf grund der aussagenlogischen Verkn pfungen dar Zwei einfache Beispiele zur Trans formation zeigt Abb 17 2 a b Ein etwa
30. kreten Nachbedingung des Szenarioschritts und der Ubergangsbedingung der entsprechenden Kante zum Folgeschritt im Use Case Schrittgraph Interaktionsparameter atomare Testf lle Die Objektkonstellationen werden zusammen mit den Interaktionsparametern Signaturen der Wurzeloperationen als Eingabemengen der Testf lle ausgewertet Verfahren zur Ablei ds Testsuitte LH Test De SL A alt ek Funktional Testfall Testskript 5 Testdatum Abb 15 1 Struktur der Test Elemente Testfallermittlung 163 tung von Testf llen f r primitive Interaktionsparameter geben z B Myers79 Beizer90 Beizer95 Poston96 und Riedemann97 Hierbei ber cksichtigen wir auch die mit der f r die Verifikation der Use Case Schrittgraphen durch die minimale Mehrfach Bedingungs ber deckung ermittelten Testf lle bez glich der Vor und Nachbedingungen der Schritte in den Use Case Schrittgraphen Abschnitt 12 1 Test Szenario Schritte Testf lle Zur Ableitung der Testf lle betrachten wir die Schrittart des dem Test Szenarioschritt zuge ordneten Use Case Schrittes Interaktionsschritt Die Test Botschaften ergeben sich ber die Verfolgbarkeitsrelation aus der Wurzelklasse und operation Die Interaktionsparameter ermitteln wir wiederum ber die Verfolgbarkeitsrelation aus der den Signatur en der Operationen bzw den Eingabefeldern der Elemente der Benutzungsoberfl che welche der Wurzeloperation entsprech
31. meineTransaktion Description 11 es Anmeldung Die Konten f r welche die Karte D d E Transaktion transaktionsberechtigt ist IC meine Schnittstelle IC meine Karte ESCH Sree EB Karte IC meineKarte H einKonto eineTransaktion In klx Relationships Related objects E ImeineKarte Cards A fdieKarte amp Karte D forinterface Accounts erstesKonto dasKonto Candidate objects existing objects Anmeldung dieKarte dieKonten Abb 20 4 SCORESTOOL Objektkonstellations Editor wichte priorisiert Die Priorit ten geben Anhaltspunkte f r die Reihenfolge und die Intensit t der Validierung bzw Verifikation des Elements Da z B bei Benutzern und Dom nenexperten keine entsprechenden Computer und CASE Kenntnisse vorausgesetzt werden k nnen empfiehlt es sich f r solche an der Validierung teilnehmenden Stakeholder vorab textuelle Spezifikationen zu generieren und an diese zu verteilen Hierf r erm glicht das SCORESTOOL die Generierung von Spezifikationsausz gen entsprechend der Validierungseinheiten Im Weiteren skizzieren wir den Objektkonstellati ons Editor die Komponenten des Szenario Browsers zur Konstruktion und Protokollierung der Test Szenarien und gehen kurz auf die Validierungsmetriken ein Objektkonstellationen F r die Validierung und Verifikation erlaubt das SCORESTOOL die manuelle Konstruktion von Objektkonstellationen anhan
32. oder nicht zul ssige negativer Test Ob jektkonstellation aufbauen Zeile 12 Danach werden Interaktionsdaten generiert Zeile 13 und dann die den Schritten des Test Szenarios zugeordneten Wurzeloperationen ausgef hrt bzw aufgerufen Zeile 14 Dies erfolgt solange bis das Test Endekriterium erf llt ist z B Ber hrte Elemente der Implementation berdeckt oder die Test Ressourcen f r das Test Szenario ausgesch pft sind Zeile 15 Aus dem KBD abgeleitete Test Endekriterien bez g lich der Interaktionen in objektorientierten Anwendungen geben wir in Kapitel 18 an In Zeile 16 versuchen wir falls noch Ressourcen verf gbar sind und es technisch m glich ist die bisher noch nicht berdeckten Teile der Anwendung auszuf hren Ist nach der Durch f hrung der so ausgef hrten grey box Tests die geforderte strukturelle berdeckung noch nicht erreicht Zeile 16 so ermitteln wir unter Benutzung der Verfolgbarkeitsrelation Ab schnitt 13 2 weitere Testf lle nach der folgenden Vorgehensweise 1 Nicht berdeckte Teile der Implementation k nnen z B technische Ausnahmebehand lungen aber auch in der Anwendung tats chlich nicht verwendete Operationen z B von wiederverwendeten Klassen sein Methodisches Vorgehen 179 Zun chst berechnen wir ber die invers betrachtete Verfolgbarkeitsrelation alle Elemente des Dom nen Klassenmodells der Anforderungsspezifikation die sich vorw rts zu noch nicht berdeckten Elementen d
33. schritt Klasse_1 Op_1 Klasse_2 Abb 7 1 Interaktionsschritt mit Klassenbereich und Wurzeloperation Op_1 hergestellt Wir wollen die Verantwortlichkeiten der Aufgaben objektorientiert auf Opera tion en von Klasse n verteilen In diesem Sinne ordnen wir jedem Interaktionsschritt zu n chst eine bestimmte Klasse im Klassenmodell und eine ihrer Operationen zu Definition 7 2 Seien K die Menge aller Klassen eines Klassendiagramms und uc ein Use Case Schrittgraph Die Abbildung WK S uc Iinteraktion gt K ordnet jedem Interaktionsschritt s eine f r seine Aufgabe verantwortliche Klasse WK s e B s zu d h die Klasse muss im Klassen bereich des Schritts enthalten sein Wir nennen WK s die Wurzelklasse von s Wir definie ren zus tzlich eine Abbildung WO Slinteraktion x K gt OPS mit WO s k o f r k WK s und o k operations die jedem Interaktionsschritt eine f r die Abbildung der Aufgabe im Dom nen Klassenmodell verantwortliche Operation der Wurzelklasse zuordnet Diese Ope ration nennen wir Wurzeloperation des Interaktionsschrittes Q Analog zum Verh ltnis der Spezifikationen eines Makroschritts und des von ihm referenzier ten Use Cases sollte die Spezifikation eines Interaktionsschritts von der Spezifikation seiner Wurzeloperation befriedigt werden d h die Vorbedingung des Interaktionsschritts impliziert die der Wurzeloperation und deren Nachbedingung impliziert die des Interaktionsschritts Zur
34. tsdiagramm weist hnlichkeiten zum Use Case Schrittgraphen auf da beide den Kontrollfluss von Aktivit t zu Aktivit t beschreiben Wir le sen Activity diagrams accomplish much of what people want from DFDs and then some activity di agrams are also usefull for modeling workflow The activity diagram is similar to the work flow diagrams developed by many sources including many pre OO sources OMG97 Summa ry The activity diagram is a variation of a state machine in which the states represent the perform ance of actions or subactivities and the transitions are triggered by the completion of the actions or subactivities OMG97 Semantics In anderen Worten das Aktivit tsdiagramm ist eine spezielle Zustandsmaschine in der Zu st nde zu Aktivit ten redefiniert sind und berg nge das Ende einer Aktivit t darstellen Wir wollen mit Use Case Schrittgraphen das interaktive Verhalten mehrerer Entit ten Ak toren und Anwendung modellieren Das Aktivit tsdiagramm und andere Arten von Zu standsmaschinen dient in erster Linie zur Modellierung von prozeduralem reaktiven Verhalten einer Entit t Operation Klasse Anwendung Betrieblicher Prozess Wir lesen in der UML The entire activity diagram is attached through the model to a class or to the implementation of an operation or a use case The purpose of this diagram is to focus on flows driven by internal processing as opposed to external events Use activity
35. tzlich zu den Definitionen und Meta Klassendiagrammen und der oben vorgestellten Semantik von Use Case Schritten und Schrittgraphen geben wir in diesem Abschnitt noch einige weitere Modellierungsregeln f r semantisch sinnvolle Use Case Schrittgraphen an Wir kommen also nach den bisherigen syntaktischen Regeln zu eher semantischen Re geln die insbesondere den Gebrauch der Vor und Nachbedingungen kl ren W hrend die syntaktischen Regeln strukturelle Eigenschaften beschreiben und zum Standardrepertoire der Werkzeugunterst tzung z hlen verk rpern die eher semantischen Regeln sozusagen Best Practices bei der Anforderungsermittlung u a IEEE830 93 Meyer85 FMD97 Fowler97a und sind nur eingeschr nkt durch Werkzeuge pr fbar vgl LamWil98 Zuerst einmal kann ein Szenario nur dann beginnen wenn die Vorbedingung des Startschritts erf llt ist Damit dies zu Beginn der Bearbeitung jedes Use Cases gilt geben wir die folgende Regel an Regel 6 3 1 Use Case Vorbedingung Die Vorbedingung eines Use Cases uc muss die Vor bedingung seines Startschritts S uc implizieren Prey Preg uc Nat rlich sollte es f r einen Use Case kein Szenario geben in dem die Aufgabe des Use Ca ses nicht abgearbeitet wird Dies pr zisieren wir sogleich in Regel 6 3 2 Use Case Nachbedingung Zu einem Use Case darf es kein Szenario geben f r das die UND Verkn pfung aller Nachbedingungen der im Szenario ausgef hr
36. ucs 10 12 1 Vereinfachend sagen wir dass ein Test Szenario einen Pfad im Use Case Schrittgraph berdeckt wenn der Pfad Teilpfad des dem Test Szenario entsprechenden Szenarios ist 120 Validierungsmetriken F r zwei Pfade v vo v1 Vm und w Wo W1 Wal mit O lt m lt n des Use Case Schritt graphen uc definieren wir den Teilpfad Operator lt uc allPaths x uc allPaths bool zu vow 10 13 true falls 30 lt i lt n m Wp Wi 4 m V false sonst d h es ist genau dann v lt w true wenn v vollst ndig in w enthalten ist Das Zeichen L be deute den leeren Pfad es gelte L lt v f r alle Pfade v e uc allPaths F r den Spezialfall dass f r den End bzw Startschritt der Pfade v und w gilt v wo definieren wir den Verkettungs Operator uc allPaths x uc allPaths uc allPaths zu vw ei Un a Wel falls v Wo 10 14 L sonst F r ie IN bezeichnen wir mit v die i fache Verkettung eines Pfads v mit sich selbst es ist also v v i mal v und v9 L Zus tzlich seien wie blich v SS N v die Menge aller aus beliebig vielen Verkettungen von v mit sich selbst bestehenden Pfade einschlie lich des leeren Pfads und vt v 1 Hiermit k nnen wir nun mit der Operation uc allBoundaryCycles alle Zyklen im Use Case Schrittgraph ermitteln die genau einmal von einem Test Szenario berdeckt werden uc allBoundaryCycles c e uc allCy
37. wird z B durch Befragungen von prospektiven Benutzern ermittelt Q Das Projektrisiko Rp inwiefern gef hrdet die Nichterf llung den weiteren Projekt fortschritt ergibt sich aus der Anzahl der ber den Makro Mechanismus vom betrach teten Use Case abh ngigen Use Cases sowie der Gr sse des Klassenbereichs Die Zuteilung der Profile zu den ersten Skizzen der Use Cases erfolgt aus der Erfahrung fr herer Projekte und Risikoabsch tzungen des Projektmanagements Drei Werte low medium und high reichen erfahrungsgem zur Quantifizierung der einzelnen Faktoren des Profils aus zudem diese auch nicht unabh ngig voneinander sind s z B Lyu96 Indem wir diese drei Werte auf die nat rlichen Zahlen 1 2 und 3 abbilden k nnen wir z B mit Formel 8 1 je dem Use Case uc ein bestimmtes Gewicht wy zuweisen F r die Planung der Entwicklung bertragen wir die Gewichte der Use Cases ber die Klas senbereiche zun chst auf Elemente des Dom nen Klassenmodells und nehmen erste grobe Rr Rg Rp tie 3 F Rz C Rr 8 1 w 102 Methodisches Vorgehen Aufwandssch tzungen vor Hierbei berechnen wir das Gewicht einer Klasse z B als Mittel wert oder konservativer als Maximum der Gewichte aller Use Cases in deren Klassen bereich die Klasse vorkommt Feinere Zuteilungen k nnen z B auch noch Wurzelklassen bzw Wurzeloperationen ber cksichtigen ber die Verfolgungsrelation s Kapitel 13 k n nen wir die Gewichte sp te
38. zise sein also jedes De tail eines Gesch ftsprozesses eindeutig beschreiben und eine konsistente Gesamtbeschrei bung liefern Oft wird der Begriff Business Process Reengineering synonym f r die Analyse und Spezifikation von Workflows gebraucht vgl HamCha94 Integrierte Systeme sowohl zur Spezifikation als auch zur Ausf hrung von Workflows werden Workflow Management Systeme genannt Workflow Management System A system that completely defines manages and executes workflows through the execution of software whose order of execution is driven by a computer representation of the workflow logic WFMC97 Workflow Modelle spiegeln verschiedene sachliche Aspekte wider nach Jablonski95 m der organisatorische Aspekt zeigt wer etwas ausf hrt bzw ausf hren kann und darf m der funktionale Aspekt spezifiziert was ausgef hrt wird Q der operationale Aspekt gibt an wie etwas ausgef hrt wird z B computergest tzt durch spezielle Anwendungen oder manuell Gesch ftsprozesse und Anforderungsermittlung 15 Q mit dem ablauf oder verhaltensbezogenen Aspekt wird beschrieben wann etwas aus gef hrt wird also der Kontrollfluss im Workflow spezifiziert LI die Daten also das Womit werden durch den informationsbezogenen Aspekt beschrie ben Q der kausale Aspekt letztendlich gibt an warum bzw aufgrund welcher Intra Work flow Abh ngigkeiten etwas ausgef hrt wird Weiterhin enthalten Workflow Modelle auch ni
39. 1 3 berblick uber die Arbeit 4 ent te et line essen 9 2 Entwicklungst tigkeiten 12 2 1 Gesch ftsprozesse und Anforderungsermittlung 00005 14 2 2 Entwurf und Implementation u und Sara ir en 24 2 3 Test und Administration aussen arte ae a ie aes 26 3 Probleme der Qualit tssicherung f r objektorientierte Anwendungen 27 SE Formale Methoden ra a2 aan e NEEN 28 3 2 Struktureller white box Test sans titan det 30 3 3 Black box Test gegen die Antorderungsspez2fkanon nan nannunenna 33 3 4 Relevante Arbeiten Test gegen objektorientierte Anforderungsspezifikationen36 4 Probleme der Anforderungsermittlung mit Use Cases 4 4 1 Fallbeispiel Bankautomat nee a a Rare ee a 41 4 2 Offene Fragen und Kritik EE 46 4 3 Relevante Arbeiten Pr zisierung von Use Cases 50 SE EE 54 II Anforderungsermittlung 57 5 Grundlegende Konzepte 58 eet Use Case Schritten hee Ot ee Ge tala a E 61 5 2 Use Eu e 2 23 42 EE 64 5 3 SCORES Metamodell i e 68 5 4 Modellierungsregeln E ee rar en ne 69 5 5 Darstellungskonventionen etc ote es E Eege eee eee wee tek 71 6 Semantik 73 6 1 Schritte in Use Case Schrittgraphen 20 0 cee eee eee eee 13 6 2 Interpretation und Entscheidbarkeit 0 0 00 cece eee ee eee 78 6 3 Modellierungsregeln MI degt Gu ee Oy ehe EE 80 Inhalt 6 4 Makroschritte extends uses und Generalisierung 7 Kopplung von Use Cases und Klassenmodell 7 1 Elem
40. 2 F r alle Use Cases die solche Elemente ber hren spe zifizieren wir ggf neue Test Szenarien und leiten weitere Testf lle ab Hierbei ber cksichti gen wir ber 3 alle Interaktionsschritte deren Wurzeloperationen sich ggf transitiv ber das KBD zu nicht ausreichend berdeckten Elementen der Implementation verfolgen lassen Implementation Anforderungsspezifikation Abb 16 5 SCORES grey box Testfallgenerierung mit dem KBD 180 SCORES grey box Test Grafisch interaktive Benutzungsoberfl che EE ge gt en une Een Initialisieren Stimulieren Validieren y Tester Tool A rer Funktionaler Kern der Anwendung E Persistente Objekte Datenbank L Abb 16 6 SCORES Grey box Test 4 Zum Schluss werden dann noch die so nicht erreichten Elemente der Implementation mit strukturellen Klassentests gepr ft 5 Abb 16 6 verdeutlicht die technischen Voraussetzungen f r den grey box Test Gegebenen falls unter Umgehung der Benutzungsoberfl che wird der funktionale Kern der Anwendung nach der Initialisierung der persistenten Objekte und der Anwendung selbst mit den Wurzel botschaften der Interaktionsschritte des Test Szenarios stimuliert und die Ergebnisse anhand der tats chlichen Abl ufe in der Anwendung und der sich ergebenden Objektkonstellation gepr ft Beispiel 16 3 Das in Abb 15 6 gezeigte Testskript zum Test Szenario Anmeldung OK des Use Cases Anmelden wird
41. 92 Opdyke92 Hiirsch95 Rumpe96 welche wir in den SCORES Elementen folgenderma en ber cksichtigen Q Einf gen einer neuen Klasse Abb 13 4 a SCORES Elemente k nnen die neue Klas se nicht referenzieren sind also durch das Einf gen der Klasse erst einmal nicht be troffen m Entfernen einer Klasse Abb 13 4 b Normalerweise sind die SCORES Elemente nicht mehr betroffen da vorher mit den weiter unten aufgef hrten nderungen die Klasse sozusagen aus dem Entwurf herausgesch lt wurde Referenzieren SCORES Elemente die Klasse dennoch so sind nach dem Entfernen der Klasse aus dem Ent wurf und den SCORES Elementen i e Klassen Bereiche sowie Episoden erneute Walk Throughs der betroffenen Test Szenarien durchzuf hren Q Aufspalten einer Klasse bzw Verschmelzen mehrerer Klassen Diese Operatoren sind auf Kombinationen der beiden ersten Operatoren zur ckf hrbar Q Einf gen einer Vererbungsbeziehung Abb 13 4 c Hat die Oberklasse eine Entspre chung im Dom nen Klassenmodell so m ssen ggf SCORES Elemente der Oberklasse im Kontext der Unterklasse erneut verifiziert werden vgl PerKai90 HMGF92 Nat rlich sind sp ter auch dementsprechende geerbte Tests notwendig Haben Ob er und Unterklasse Entsprechungen im Dom nen Klassenmodell so sind zus tzlich alle SCORES Elemente polymorph zu erweitern die Objektbeziehungen zur Ober 1 Besonders interessant sind in diesem Zusammenhang semantik
42. Aktor pro Use Case erscheint dieses Modell eher zugeschnitten auf die Spezifikation von Mensch Maschine oder Maschine Maschine Schnittstellen und die Ableitung von Testf llen f r den statistischen Benutzungstest statistical usage testing vgl RegRun98 Rolland und Achour kombinieren die Ans tze von Regnell Cockburn und Dano RAB96 Cockburn97 DBB97 und entwickeln eine Methodik zur textuellen Spe zifikation von Use Cases die auf sogenannten linguistischen Strukturen basiert RolAch98 Anhand dieser Strukturen wird die umgangs sprachliche Beschrei bung von Gesch ftsvorf llen analysiert und strukturiert Rolland und Achour schrei ben A use case specification comprises contextual information of the use case its change history the complete graph of possible pathways attached requirements and open issues The proposed ap proach delivers a use case specification as an unambiguous natural language text This is done by a stepwise and guided process which progressively transforms initial and partial natural language descriptions of scenarios into well structured integrated use case specifications RolAch98 Lamsweerde und Willemet beschreiben einen wissensbasierten Ansatz zur Inferenz deklara tiver Anforderungsspezifikationen aus textuellen Beschreibungen von Szenarien LamWil98 Sie verfolgen ebenso wie Rolland und Achour das Ziel einer konsis tenten und vollst ndigen textuellen Spezifikation der Use Cases Scenar
43. Arbeit sichtbar Der Tester muss im Prinzip alles beherrschen was die ande Zusammenfassung und Ergebnisse 211 ren Stakeholder wie z B Benutzer Analytiker und Entwickler k nnen nur ein bisschen besser Der Ausgangsfragestellung Wie wird eine objektorientierte Anforderungsspezifikation ge pr ft bzw erst pr fbar gestaltet und wie k nnen Testf lle f r den Test gegen die gepr fte An forderungsspezifikation abgeleitet werden entsprechend betreffen die zentralen Ergebnisse die drei jeweils aufeinander basierenden Themenbereiche Q Pr zisierung und Verfeinerung des Use Case Konzepts Q Qualit tssicherung bei der Anforderungsermittlung und Q Test der Anwendung gegen die Anforderungsspezifikation Zur Pr zisierung der Anforderungsspezifikation mit Use Cases haben wir in dieser Arbeit SCORES Systematic Coupling of Requirements Specifications eingef hrt SCORES pr zisiert und verfeinert das Use Case Konzept durch sog Use Case Schrittgraphen welche die Ab straktionsl cke zwischen Use Cases und dem Klassenmodell berbr cken und dar ber hin aus die Modellierung von Abl ufen bzw Kontrollfluss im Use Case Konzept gestatten Abb 21 1 Das Konzept des Makroschritts setzt die uses extends und Generalisierungs beziehungen zwischen Use Cases auf die entsprechenden Use Case Schrittgraphen fort und erm glicht somit erstmals deren pr zise Semantikdefinition Die Anforderungsermittlung mit SCORES erfass
44. B mit der quivalenzklassenbildung der Grenzwertanalyse und hnlichen funktionalen Testverfahren Q F r Abnahmetests verwenden wir vorzugsweise anonymisierte Produktionsdaten die durch den Benutzer bereitzustellen sind vgl Hetzel88 Sind diese nicht vorhan den so m ssen wir in Absprache mit dem Benutzer Parameter zur Generierung der In teraktionsdaten festlegen Beispiel 17 2 Einen ausf hrbaren Test mit konkreten Interaktionsdaten zum Test Szenario bzw Skript Anmeldung OK des Bankautomat Beispiels zeigt Abb 17 4 TEST AnmeldungOK Bankleitzahl 33050000 Kontonummer 4712042 G ltigkeitsdatum 01 01 2000 Kartennummer 1234 PIN 4656 Abb 17 4 Interaktionsdaten zum Test Skript Anmeldung OK Kapitel 18 Endekriterien Ausf hrung und Auswertung One of the most difficult problems in testing is knowing when to stop Myers79 F r die Bewertung einer durchgef hrten Pr fung ben tigen wir sogenannte Testendekriteri en Wir erwarten von solchen Kriterien quantitative Aussagen ber das Risiko eine gepr fte Anwendung tats chlich einzusetzen Im Prinzip sollte ein solches Kriterium also Aussagen der Art Testende erreicht nicht erreicht erm glichen Zus tzlich zu verschiedenen Endekri terien f r den Test der Anwendung gegen die objektorientierte Anforderungsspezifikation geben wir in diesem Kapitel noch einige Hinweise zur Ausf hrung und Auswertung der Tests 18 1 Test und Testendekriterien
45. Bankautomat Als durchgehendes Anwendungsbeispiel dieser Arbeit betrachten wir die Arbeitsweise eines Bankautomaten vgl WBW 90 Jacobson95 Wir beginnen mit einer informellen Pro duktskizze An dem Bankautomaten k nnen Kunden ohne die Beteiligung eines Bankangestellten bestimmte Transaktionen vornehmen Vor der Eingabe einer Kreditkarte zeigt der Automat eine Eingabeauf forderung Nach der Eingabe einer Kreditkarte wird diese gelesen Nicht lesbare Karten werden eingezogen nicht zum Zugriff berechtigende Karten direkt ausgeworfen Ist die Karte lesbar und berechtigt zum Zugriff auf den Automaten so fordert der Automat die Eingabe der Geheimzahl PIN Ist der Zentralrechner verf gbar so wird die PIN dorthin bermittelt und von diesem ge pr ft wobei direkt auch etwaige Sperrvermerke des Karteninhabers gepr ft werden Ansonsten pr ft der Automat die PIN anhand der Kartendaten Wird eine falsche PIN eingegeben so wird dieser Versuch gez hlt nach drei Fehlversuchen wird die Karte gesperrt und ausgeworfen 42 Probleme der Anforderungsermittlung mit Use Cases Nachdem die richtige PIN eingegeben wurde werden verschiedene Verarbeitungsm glichkeiten angezeigt wie Kontostand anzeigen Geld abheben Geld einzahlen Geld zwischen verschiede nen Konten transferieren etc Die Auswahl dieser Punkte verursacht einen Zugriff auf einen Zentralrechner zur Abfrage bzw Ver nderung der Kontost nde Ist der Zentralrechner nicht ver f gb
46. Bedienpult gesperrt IN Objects display OUT Objects v display klx D Karte D Transaktion Abb 20 2 SCORESTOOL Use Case Spezifikations Editor 200 SCORESTOOL Use case Anmelden m Karte Lesen Karte Einziehen PIN Anfordern Karte Schreiben Karte Anbieten Karte Eninehmen PIN Pr t Auswahl Anzeigen E f Karte Einf hren lelt FRORERET H Karte Lesen 7 E f Karte Einziehen s PIN Anfordern ge E s Karte Schreiben e PIN Pr fen Children s Karte Lesen Karte Einf hren Karte Einziehen PIN Anfordern Karte Schreiben Karte Anbieten Karte Entnehmen PIN Pr fen Auswahl Anzeigen lelt GE H Karte Anbieten KI Auswahl Anzeigen Condition Kate ist een Name Karte Einf hren Precondition processed by Kartenleser betriebsbereit i J User Description Der Bankkunde gibt seine Karte ein jE Postcondition Karte im Kartenleser UND Kartenleser A gesperrt Step Goal Der Bankkunde gibt seine Karte ein i Abb 20 3 SCORESTOOL Use Case Schrittgraph Editor BE ch m e f Karte Entnehmen SH m Bankkunde Bediener Zentralrechner Schrittgraph Editor spezifiziert und miteinander verbunden Hierbei k nnen die Vor und Nachbedingungen der Schritte sowie die bergangsbedingungen der Kanten ne b
47. Case Schritts vage beschrieben Sind die Vor und Nachbedingungen und die Bedingungen der Kanten pr fbar Ist jeder Use Case zu seinem Ursprung bzw den Stakeholdern vor verfolgbar nderbarkeit Ist jeder nicht von einem Makroschritt referenzierte Use Case ohne Einfluss auf die brigen Use Cases nderbar Abb 9 1 Exemplarische Checklistenpunkte f r die Validierung Externes Verhalten 111 9 3 Externes Verhalten Im zweiten Schwerpunkt der Validierung werden die Use Case Schrittgraphen gegen opera tionale und kausale Aspekte sowie die Ablaufaspekte des Gesch ftsprozesses gepr ft Erfah rungsgem f hrt bei dynamischen bzw ablaufbezogenen Spezifikationen eine Reihe von Walk Throughs zu den besten Ergebnissen Hierbei werden bei der Validierung von Anfor derungsspezifikationen konkrete Gesch ftsvorf lle als angemessenes Medium zur Validie rung des extern zu beobachtenden bzw erw nschten Verhaltens verwendet business scenarios vgl Boehm84 Gerrard94 PTA94 WPJ 98 SCORES Anforderungsspezifika tionen sind hierbei besonders testbar da sich konkrete Gesch ftsvorf lle bzw Szenarien unmittelbar als Pfade durch einen Use Case Schrittgraphen wiederfinden KPR 97 In SCORES validieren Benutzer Dom nenexperten und Analytiker somit die Use Case Schrittgraphen indem sie in Walk Throughs anhand einer angenommenen konkreten Ge sch fts Situation und Aufgabenstellung die entsprechenden Pfade
48. Cases orientiert sich dabei an den mit dem Einsatz der Anwendung verfolgten Zielen goals vgl LamWil98 wobei Cockburn f r jeden Use Case erfolgreiche von nicht erfolgrei chen Szenarien unterscheidet Relevante Arbeiten Pr zisierung von Use Cases 51 Regnell et al entwickeln ein Use Case Modell mit drei Hierarchieebenen RAB96 Die Umgebungsebene environmental level entspricht Jacobsons Use Case Modell eine Zwischenebene structure level definiert zusammenh ngende Teilabl ufe eines Use Cases genannt Episoden deren Semantik ber Vor und Nachbedingungen spezifi ziert wird Episoden bei Regnell et al sind als funktional hierarchisch strukturierte Teilabl ufe am ehesten mit den von uns vorgestellten Makroschritten zu vergleichen und werden zeitlich ber Konstrukte verkn pft die an Message Sequence Charts MSC vgl ITU93 angelehnt sind Auf der Ereignisebene event level wird der Nachrichtenaustausch genau eines Aktors mit der Anwendung betrachtet als Black Box in zeitlicher Reihenfolge mittels MSC modelliert Alle Use Cases eines Aktors k nnen in einem sogenannten Synthesized Usage Model zusammengefasst werden welches alle m glichen Interaktionen dieses Aktors mit der Anwendung darstellt vgl RKW95 Regnell et al schreiben hierzu The synthesized usage model is an abstraction mechanism that conceals the detailed protocol of interactions RKW95 Aufgrund des Detaillierungsgrads und der Beschr nkung auf einen
49. Darstellung der Klassenbereiche von Use Case Schritten erweitern wir die Use Case Schritt Symbole um eine Sektion in der wir die Klassen im Klassenbereich des Schritts tex tuell auff hren Abb 7 1 Hierbei kennzeichnen wir die Wurzelklasse des Schritts durch ein vorangesetztes und f hren optional vom Klassennamen durch einen Punkt abgetrennt noch den Namen der Wurzeloperation auf Wie in Abb 7 4 dargestellt visualisieren wir Klassenbereiche von Use Cases mit Kollaborationen vgl OMG97 7 4 SCORES Metamodell II Wir erweitern das in Abb 5 7 gezeigte Metamodell f r Use Cases um entsprechende Primi tive zur Modellierung von Wurzelklassen sowie Wurzeloperationen und erhalten das UML Klassendiagramm in Abb 7 2 Der schon in Abb 5 7 gezeigte Teil des Metamodells ist ab geschw cht bzw bei Farbdruck rot gezeichnet Die erforderliche Assoziation f r die Klas senbereiche Assoziation scope ist der abstrakten Klasse ValidationClassifier zugeordnet von der die Klassen StepGraph und UseCaseStep erben Objekte der Klassen StepGraph und UseCaseStep k nnen dementsprechend mit Objekten der Klasse Class verbunden wer Vollst ndigkeitsmetriken 91 refersTo 1 referencedStepGraph StepGraph 1 0 1 p a g ValidationClassifier E 3 E a E A KS E g g g Di Q 2 e oO
50. Direkt auf Instanzvariablen zugreifende Anweisungen m ssen klassisch mit der Anweisungs bzw Zweig berdeckung und mit entsprechen den datenflussbezogenen Kriterien betrachtet werden 190 Endekriterien Ausf hrung und Auswertung kriterien berdeckungsprotokoll Zum Ergebnis geh rt auch ein Testvorfallsbericht in dem alle Probleme bzw Abweichungen vom Soll oder sonstige Besonderheiten notiert sind Die Test Skripte werden hierbei entweder durch ein Werkzeug zur automatischen Ansteue rung der Benutzungsoberfl che ausgef hrt Abb 15 4 Seite 166 oder aber z B f r die grey box Tests in eine objektorientierte Programmiersprache transformiert bersetzt und direkt ausgef hrt Zu den Ergebnissen einer Testausf hrung geh ren in erster Linie die Aus sage ob das tats chliche Ergebnis der Testausf hrung dem erwarteten im Testfall spezifi zierten Ergebnis entspricht sowie die berdeckungsprotokolle Wir sammeln die Ergebnisse in den entsprechenden Test Suiten 18 3 Testauswertung Nach der Durchf hrung werden die Testergebnisse analysiert und verdichtet Ziel der Test auswertung ist es zu entscheiden ob ein Pr fgegenstand den Test bestanden hat oder ob der Test nach einer Korrektur der Fehler bzw Defekte wiederholt werden muss Die Bewertungs resultate dokumentieren sich im Testbericht In der Testauswertung werden die protokollier ten Ergebnisse der Testausf hrung mit den Sollwerten verglichen Hierbe
51. In den beiden letzten Kapiteln dieses Teils gehen wir auf die Komplexit t der Generierung von Objektkonstellationen als Testdaten sowie kurz auf die Testausf hrung und auswertung ein Kapitel 14 Probleme und Ziele In diesem Kapitel zeigen wir die bei dem Test von objektorientierter Anwendungen gegen eine objektorientierte Anforderungsspezifikation auftretenden Probleme auf und fassen die Ziele zusammen die wir in diesem Teil erreichen wollen 14 1 Probleme In der Literatur sind berwiegend Verfahren zur Pr fung einzelner Klassen Klassentest ver ffentlicht vgl Binder96a KHG98 Diese erweisen sich f r objektorientierte Software je doch zunehmend als wenig effektiv und sind nicht auf den Test komplexer Anwendungen mit hunderten von Klassen erweiterbar s Kapitel 3 Rufen wir uns zudem ins Ged chtnis dass die Komplexit t objektorientierter Anwendungen nicht im Quellcode einzelner Methoden sondern in den Interaktionen liegt so m ssen wir die Effektivit t herk mmlicher white box Testverfahren bzw struktureller Testkriterien berhaupt in Frage stellen Wir erinnern an den Stand der Qualit tssicherung in der industriellen Praxis systematische Pr fungen von neu erstellten bzw ge nderten Anwendungen werden wenn berhaupt berwiegend in sp ten Phasen der Softwareentwicklung durchgef hrt vgl M lWie98 Aufgrund der og Problematik des white box Tests spielen hierbei black box Tests wie z B System u
52. JCJ 92 Testt tigkeiten nach Grimm95 Problematik des Klassentests nach Sneed96 Object Z basierte Testmethode von CLS 98 Herk mmlicher black box Systemtest Use Case Geld Abheben Textuelle Spezifikation bersetzt aus JCJ 92 Use Case Diagramm Bankautomat Vereinfachtes Objektdiagramm zum Use Case Geld Abheben Interaktionsdiagramm zum Use Case Geld Abheben Die drei Informationsarten bei der Anforderungsermittlung PohHau97 Die Abstraktionsl cke zwischen Use Case Modell und Klassenmodell Das Kosten Teufelsquadrat der Anforderungsermittlung Spezifikation des Use Case Anmelden Textuelle Spezifikation einiger Use Case Schritte Bedingungen der Schritte im Use Case Schrittgraph Anmelden Kanten im Use Case Schrittgraph Anmelden Use Case Schrittgraph Metamodell Use Case Schrittgraphen Anmelden a und Geld Abheben b Erfolgreiche Szenarien zu den Use Cases Anmelden a und Geld Abheben b Semantik 1 einfachster Fall Semantik 2 kein Endschritt ein Folgeschritt Semantik 3 Endschritt ein Folgeschritt Semantik 4 kein Endschritt mehrere sich ausschliessende Folgeschritte a unabh ngige Folgeschritte b abk rzende Notation Semantik 5 kein Endschritt Parallel ausf hrbare Folgeschritte 6 10 12 15 18 22 22 23 25 25 26 31 39 40 43 44 44 45 46 59 60 62 64 67 68 68 72 72 73 74 74 75 76 76 vi Abbildungen Abb 6 7 Semantik 6 Endschritt mehrere Folgeschr
53. Karte Einf hren Karte Pr fen Zentralrechner Lesen Karte Anbieten Karte Entnehmen Karte Unlesbar Karte Einf hren arte Auswahl Karte ZS Anzeigen Schreiben Lesen Karte Einziehen Y ZweimalFalsche PIN Karte Einf hren Ki K si EE al ara Karte Lesen PIN Anfordern PIN Pr fen PIN Anfordern PIN Pr fen PIN Karte Anfordern Karte Schreiben Karte An Entnehmen bieten Karte Entnehmen a b Abb 10 2 Use Case Schrittgraph a und f nf textuell beschriebene Szenarien b Wir erhalten Cal wenn f r jeden Zyklus im Use Case Schrittgraph jeweils mindestens ein Test Szenario existiert das den Zyklus keinmal genau einmal und mindestens zweimal durchl uft Letztendlich k nnen wir als m chtigste wiederum nur f r azyklische Use Case Schrittgra phen vollst ndig zu erf llende Validierungsmetrik die Use Case Pfad Uberdeckung c de finieren ts path cuc LA e uc ValidationProtocol oo uc allPaths gt size 10 19 Beispiel 10 4 Wir illustrieren die strukturellen Metriken dieses Abschnitts an dem in Abb 10 2 a gezeigten Schrittgraph des Use Cases Anmelden Abb 10 2 b skizziert hierzu tex tuell einige Szenarien Die Use Case Schritt berdeckung erreichen wir bereits mit den beiden Szenarien Online Anmeldung Abb 10 3 bzw Abb 10 4 a und Anmeldung Abbrechen Abb 10 4 b Die fehlenden Kanten vom
54. Methode zur Integration statischer und dyna mischer Sichten in der objektorientierten Anforderungsermittlung Diplomarbeit Praktische Informatik III FernUniversit t Hagen erscheint vor Jan 2000 Yourdon89 Edward Yourdon Modern Structured Analysis Prentice Hall Englewood Cliffs New Jersey 1989 ZRL96 Sean Zhang Barbara G Ryder William Landi Program Decomposition for Pointer Aliasing A Step towards Practical Analyses Proc qth Symposium on the Founda tions of Software Engineering Okt 1996 Ziegler96 Jiirgen Ziegler Eine Vorgehensweise zum objektorientierten Entwurf graphisch interaktiver Informationssysteme IPA IAO Forschung und Praxis Bd 240 Sprin ger Berlin 1997 zugl Dissertation Univ Stuttgart 1996 Z llighoven98 Heinz Z llighoven Das objektorientierte Konstruktionshandbuch D Punkt Verlag 1998 234 Anhang Im Anhang pr zisieren wir zun chst das im Text nur skizzierte Klassen Botschaftsdiagramm f r die Anforderungsspezifikation KBD Danach detaillieren wir den Begriff der internen Interaktion in objektorientierten Programmen und geben darauf aufbauend die Definition und einen Algorithmus zur Generierung des Klassen Botschaftsdiagramms f r die Implementation KBD an Hier bei beziehen wir uns auf die objektorientierte Programmierspra che Java Zus tzlich haben wir noch die Syntax der im Rahmen der Arbeit entwickelten Test Beschreibungssprache angef gt Anhang A Klassen Botschaft
55. Operation 141 Abb 12 2 Episode zum Schritt PIN Pr fen im Test Szenario Online Anmeldung 145 Abb 12 3 Episode zum Schritt PIN Pr fen im Test Szenario Offline Anmeldung 146 Abb 13 1 Verfolgbarkeit f r den Grey box Systemtest 148 Abb 13 2 Vertikale Verfolgbarkeit nach Davis90 149 Abb 13 3 UML Auxiliary Elements Dependencies and Templates OMG97 150 Abb 13 4 Einfache strukturelle Entwurfs nderungen 154 Abb 14 1 Vom Test der Anforderungsspezifikation zum System und Abnahmetest 159 Abb 15 1 Struktur der Test Elemente 162 Abb 15 2 Testskript f r die Klasse Stack 164 Abb 15 3 Algorithmus Black box Test 165 Abb 15 4 Black box Test 166 Abb 15 5 Gerichteter azyklischer Graph zur Inter Use Case Referenzfunktion 167 Abb 15 6 Black box Testf lle zum Use Case Anmelden 168 Abb 16 1 KBDA f r einige Operationen im Dom nen Klassenmodell des Bankautomaten 171 Abb 16 2 Java Code a und Klassen Botschaftsdiagramm f r die Implementation b 174 Abb 16 3 KBDI vs KBDA 175 Abb 16 4 Algorithmus Grey box Test 178 Abbildungen Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb 16 5 SCORES grey box Testfallgenerierung mit dem KBD 16 6 SCORES Grey box Test 16 7 Grey box Testf lle 17 1 Beispiel zur Generierung von Objektkonstellationen 17 2 Einfache Beispiele zur polynomialen Transformation von SAT auf GOK 17 3 Komplexeres Beispi
56. Proc SOGESTA 81 Urbino Italien Elsevier North Holland 1981 S 279 287 CLS 98 K H Chang S S Liao S B Seidman R Chapman Testing object oriented pro grams from formal specification to test scenario generation Journal of Systems and Software Jahrg 42 Nr 2 Aug 1998 S 141 151 CoaYou90 Peter Coad Edward Yourdon Object Oriented Analysis Prentice Hall Engle wood Cliffs New Jersey 1990 221 CoaYou91 Peter Coad Edward Yourdon Object Oriented Design Prentice Hall Engle wood Cliffs New Jersey 1991 Cockburn97 Alistair Cockburn Goals and Use Cases Journal of Object Oriented Pro gramming Jahrg 8 Nr 6 7 Sep Nov 1997 CooDan94 Steve Cook John Daniels Designing Object Systems Software isn t the Real World Journal of Object Oriented Programming Mai 1994 S 22 28 Corriveau96 Jean Pierre Corriveau Traceability Process for Large OO Projects IEEE Computer Sep 1996 S 63 68 CusSel96 Michael A Cusumano Richard W Selby Die Microsoft Methode Heyne M n chen 1996 DBB97 Benedicte Dano Henri Briand Frank Barbier An approach based on the concept of use case to produce dynamic object oriented specifications Proc 3rd TEEE International Symposium on Requirements Engineering Annapolis Maryland USA 1997 S 54 64 Davis90 Alan M Davis Software Requirements Analysis and Specification Prentice Hall Englewood Cliffs New Jersey 1990 DHP 99 Bernhard Deifel Ursula Hinkel Barba
57. Regel vom Benutzer bzw Kunden Komponenten und Integrationstest werden eher von Entwicklern durchgef hrt e Bez glich der Qualit tsmerkmale liegt das Hauptaugenmerk des System bzw Ab nahmetests auf der Benutzbarkeit Zuverl ssigkeit Robustheit und Performanz w hrend sich der Komponenten und Integrationstest auf die Korrektheit der Anwen dung konzentriert Auch Hetzel geht ausf hrlich auf den System und Abnahmetest ein Hetzel88 Der Sys temtest beginnt wenn der Integrationstest beendet ist und endet wenn die Anwen dung vertrauensvoll genug erscheint um vom Kunden abgenommen zu werden Hetzel differenziert den Systemtest in einen anforderungsbasierten einen perfor manzbasierten und einen entwurfsbasierten Teil e Der anforderungsbasierte Systemtest zeigt systematisch die Verf gbarkeit aller Funktionen und ihre bereinstimmung mit der Spezifikation auf Die Vorgehens weise orientiert sich dabei am Benutzer d h es werden keine systeminternen Infor mationen verwendet Die Testf lle werden aus dem Benutzerhandbuch oder der Anforderungsspezifikation abgeleitet e Der performanzbasierte Systemtest pr ft systematisch die Performanzeigenschaften der Anwendung und zeigt dass die entsprechenden Anforderungen erf llt sind Zu erst wird die Anwendung mit den spezifizierten Daten bzw Transaktionsvolumina getestet danach bis hin zum Abbruch der Anwendung 36 Probleme der Qualit tssicherung f r objektorientierte Anwendung
58. Schritt PIN Pr fen zur ck zum Schritt PIN Anfor dern und vom Schritt PIN Anfordern zur ck zum Schritt Karte Schreiben decken wir mit dem Szenario Falsche PIN ab Abb 10 4 c Dementsprechend deckt das Szenario Karte Ung ltig die Kante vom Schritt Karte Lesen zum Schritt Karte Schreiben ab Zur 100 igen Erf llung der Use Case Kanten berdeckung durchl uft das Szenario Karte Unlesbar noch die Kante vom Schritt Karte Lesen zum Schritt Karte Einziehen Zur 100 igen Grenze Inneres ber deckung fehlt noch eine Wiederholung des durch die beiden Kanten zwischen den Schritten 122 Validierungsmetriken x Bankkunde ATM Zentralrechner Karte Einf hren Karte Lesen ee Kartenleser leseDaten Transaktion Karte PIN Anfordern lt dt gt Bedienpult lesePIN Transaktion PIN Pr fen Transaktion pr fePIN Zentralrechner Schnittstelle Karte Auswahl Anzeigen 4 OBedienpult leseAuswahl Abb 10 3 Sequenzdiagramm zum Test Szenario Online Anmeldung Use Case Anmelden PIN Anfordern und PIN Pr fen gebildeten Zyklus Dies erreichen wir durch zweimalige Fehl eingabe der PIN wie es im Szenario ZweimalFalsche PIN gezeigt ist Schon f r diesen Use Case Schrittgraphen sind die vollst ndige Szenario berdeckung oder gar die Pfad berde ckung aufgrund des Zyklus theoretisch unerreichbar Abb 10 5 zeigt eine mit Piktogram men animierte Sicht des Test Szenarios
59. Specifications in M Ardis 232 Edt Proc gnd Workshop on Formal Methods in Software Practice FMSP 98 Clearwater Beach Florida USA Marz 1998 Tichy94 Walter F Tichy Ed Trends in Software Configuration Management J Wiley amp Sons Chichester 1994 Uh197 R Uhl Qualifizierte Suche und Konsistenzpr fungen in GEOOOA Modellen Diplomarbeit Praktische Informatik III FernUniversit t Hagen 1997 VosGrH93 Gottfried Vossen Margaret Gro Hardt Grundlagen der Transaktionsverarbei tung Addison Wesley Bonn 1993 VosNen98 Josef Voss Dietmar Nentwig Graphische Benutzungsschnittstellen Modelle Techniken und Werkzeuge der User Interface Gestaltung Hanser M nchen 1998 Voss97 Josef Voss Vorgehensweisen und Werkzeuge f r ein Ineinandergreifen von Model lierung und Prototyping Proc PB 97 Prototypen f r Benutzungsschnittstellen Fachgespr ch der GI Fachgruppe 2 1 2 Paderborn 1997 VW98 VISUALWORKS Release 3 0 ParkPlace Systems Inc Sunnyvale CA 1998 WalNer95 Kim Walden Jean Marc Nerson Seamless Object Oriented Software Architec ture Prentice Hall Englewood Cliffs New Jersey 1995 WBW 90 Rebecca Wirfs Brock Brian Wilkerson Lauren Wiener Designing Object Ori ented Software Prentice Hall Englewood Cliffs New Jersey 1990 WBM96 David A Wheeler Bill Brykczinski Reginals N Meeson Jr Software Inspektion An Industrial Best Practice IEEE Press Los Alamitos 1996 Wegner97
60. Use Case Schrittgraphen 77 Wir sehen von einer weitergehenden Modellierung m glicher Nebenl ufigkeiten ab und ver weisen in diesem Zusammenhang auf UND Zust nde in Zustandsdiagrammen vgl HarNaa96 OMG97 und auf Petri Netze vgl DesObe96 Abgesehen vom oben gezeig ten Spezialfall modellieren wir die betreffenden Schritte in irgendeiner Reihenfolge als Se quenz Technisch schlagen sich diesbez gliche Anforderungen an die Mehrbenutzerf higkeit bzw Multiple Sessions auf Einplatz Systemen im Transaktionsmechanismus vgl VosGrH93 bzw den Modalit ten zwischen Elementen der Benutzungsschnittstelle nieder vgl KSV96 VosNen98 Q Kontext oder Interaktionsschritt mehrere Folgeschritte und Endschritt Abb 6 7 BEGIN Schritt Schritt Aufgabe CASE c Schritt FolgeSchritt_1 GOTO FolgeSchritt_1 Schritt c Schritt FolgeSchritt_n Folgeschritt 1 Folgeschritt n GOTO FolgeSchritt_n un ELSE UseCaseEnde END END Schritt Abb 6 7 Semantik 6 Endschritt mehrere Folgeschritte Dieser Fall unterscheidet sich lediglich aufgrund des zus tzlichen ELSE Teils in der CASE Anweisung vom vorigen Es darf hier der Fall eintreten dass nach der Bearbei tung der Aufgabe keine der Bedingungen c Schritt FolgeSchritt_1 bis c Schritt FolgeSchritt_n zutrifft In diesen F llen wird die Bearbeitung des Use Cases beendet Kommen wir nun zur Semantik der Makroschritte Jeder Makroschritt s nakro referenzie
61. Verfolgbarkeit zwischen den Modellen The first attempt at a design model can be made mechanically based on the analysis model The transformation is made so that initially each analysis object becomes a block As each analy sis object is traceable to a block changes introduced in the analysis model will be local in the de sign model and thus also in the source code Note that the traceability is bidirectional that is it also goes the other way we can trace a class in the source code back to the analysis and see whatever gave rise to it JCJ 92 Nach dieser initialen Entwurfstransformation werden Verfeinerungen der Bl cke und Er weiterungen um implementationsspezifische Klassen und Teilsysteme durchgef hrt Verhalten Verhalten Implementations umgebung a g p p Information Information Pr sentation Pr sentation Abb 2 8 Von der Anforderungsermittlung zum Entwurf OOSE nach JCJ 92 26 Entwicklungst tigkeiten 2 3 Test und Administration Dem Stand der Technik der Qualit tssicherung f r objektorientierte Anwendungen ist das n chste Kapitel gewidmet so das wir hier lediglich noch einmal festhalten dass sich gerade in der objektorientierten Softwareentwicklung die Qualit tssicherung ber die gesamte Pro jektdauer erstreckt PagSix94 vgl auch Abb 1 2 und Abb 2 1 Je nach Projektfortschritt bzw Phase verschiebt sich ihr Fokus von der Pr fung der Anforderungsspezifikation bis hin zum S
62. Wurzeloperation ent fernt so m ssen die entsprechenden Use Case Schritte Test Szenarien und Episoden ge ndert werden Handelt es sich um eine im inneren von Episoden verwendete Operation sind die betroffenen Episoden abzu ndern Ggf m ssen wir die betroffe nen Teile der Anforderungsspezifikation erneut verifizieren Die Anwendung dieser Operatoren transformiert die Elemente der Anforderungsspezifikati on schrittweise in solche des Entwurfs und der Implementation Tab 13 2 zeigt die empfoh 156 Verfolgbarkeit lenen Verfolgbarkeiten Y von Elementen der Anforderungsspezifikation und ihren Pr fprotokollen zu Elementen der Implementation I bzw des Tests T an I T Si v 4 5 u q D 2 v 4 P v S H fe K 3 E 4 a H 5 yy H H 9 v 43 o 0 E n Ee Y D 5 Ge a Y D x R Ne gt m Ke u Ai xe Se W 4 a N yy B D D 13 o A x N S u o o un Set 4 m Q 0 Ke Z 0 v E a E Z Ei E S Q 0 S G qi Use Case v v Use Case Schritt v v Test Szenario v v Test Szenario v v Schritt Episodenschritt v v Paket Vv Y Klasse v v Generalisierung v Beziehung v De Attribut Y Vv Operation Y Vv Tab 13 2 Verfolgbarkeiten zwischen Anforderungsspezifikation Implementation und Test Fassen wir zusammen Aus den verschiedensten Griinden sind im Entwurf Anderungen am Dominen Klassenmodell notwendig Durch die Zur ckf hrung von nderungen a
63. alle von diesen Elementen erreichbaren Elemente der Implementation Diese Teile der Implementation werden instru mentiert Zeile 10 178 SCORES grey box Test Algorithmus Grey box Test Eingabe Anforderungsspezifikation Implementation Ausgabe Test berdeckungs und Ausf hrungsprotokolle 1 Test Reihenfolge tre generieren 2 KBD aus der Implementation generieren 3 FORALL uc UC ORDERED BY tre DO 4 FORALL is e uc Test Szenarien DO 5 kbdEP Uber die Nach Verfolgbarkeit Einstiegspunkte in das KBD ermitteln 6 FORALL ep e ts allEpisode DO 7 kbdEP kbdEP U ep rootOperation alllmplementationElements 8 Uber transitive H lle des KBD ber hrte Elemente der Implementation ermitteln 9 kbdEP KBD 10 Ber hrte Elemente der Implementation instrumentieren 11 REPEAT 12 Objektkonstellation aufbauen 13 Daten f r die Interaktionsparameter der Schritte von ts generieren 14 Test Skript ausf hren hierbei die Wurzeloperationen der Test Szenarioschritte f r die entsprechenden Wurzelobjekte aufrufen 15 UNTIL Test Endekriterium erreicht OR Test Ressourcen f r Test Szenario ausgesch pft FORALL 16 Testfalle f r die noch nicht berdeckten Teile des KBD ermitteln und ausf hren END Grey boxTest Abb 16 4 Algorithmus Grey box Test In der Schleife ab Zeile 11 f hren wir dann die Testf lle aus wobei wir zun chst eine f r den Start des Test Szenarios zul ssige positiver Test
64. auch injektiv d h ein Feature redefiniert h chstens ein anderes Fea ture Die Relation PC Ex E ber cksichtigt dynamisch gebundenen Methodenaufrufe bzw Variablenzugriffe Stehen Kanten zueinander in der Relation P so wird abh ngig von der tats chlichen Klasse des Zielobjekts durch den Aufruf genau eine der den Ziel Knoten entsprechenden Methoden ausgef hrt bzw auf die entsprechend definierte Va riable zugegriffen P ist reflexiv und transitiv m 244 Klassen Botschaftsdiagramme Generierung des KBD f r Java Klassen Innerhalb des in Abb 22 3 angegebenen Algorithmus Generiere KBDI beziehen wir uns auf die Syntaxregeln insbesondere die Nicht Terminale der Java Grammatik aus GJS96 F r den Parse Baum der Klasse k ergibt z B der Ausdruck k MethodDeclarations die Menge al ler Teilb ume der Methodendeklarationen in K Zur Vereinfachung der Darstellung gehen wir davon aus dass Zuweisungen immer die Form LeftHandSide RightHandSide haben wobei LeftHandSide ein Name einer lokalen oder Instanz Variablen ist und RightHandSi de ein Ausdruck vom syntaktischen Typ ConditionalOrExpression d h wir betrachten keine Zuweisungsketten Wir treffen noch einige weitere Vereinbarungen und Hilfsfunktionen Sei hierzu ml ein Methodenaufruf MethodInvocation innerhalb einer Klasse k Q F r eine Deklaration einer Variablen v oder Methode m sei lt k m gt die Zeichenkette mit dem qualifizierten Namen der Variablen oder Meth
65. ber alle Entwicklungst tigkeiten hinweg auf die Elemente der Implementation abbilden Abb 13 1 Bereits in der Einf hrung haben wir die Methodik OOSE JCJ 92 skizziert welche die Elemente des Dom nen Klassenmodells als Entit tsklassen in den Entwurf einbettet In diesem Kapitel stellen wir zun chst allgemeine Betrachtungen zur Verfolgbarkeit an Dann betrachten wir in Abschnitt 13 2 wie sich die im Entwurf durchgef hrten nderungen am Klassenmodell auf die Elemente der SCORES Anforderungsspezifikation auswirken und wie wir die in den Episoden enthaltene systeminterne Information durch den Entwurf verfolgen 148 Verfolgbarkeit Black box Abnahmetest Te ru zZ est der Anforde ngsspezifikatio L Fehler der Fehler d ehler der Ae A Test der Soft Anforderungs Senne warespezifikation ermittlungs eee ES Testf lle 4 Entwurfsfehler Codierungsfehler Abb 13 1 Verfolgbarkeit f r den Grey box Systemtest 13 1 Konzepte Das Identifizieren von aufeinander aufbauenden bzw inhaltlich zusammenh ngenden Ele menten wird als Verfolgbarkeit traceability bezeichnet vgl IEEE830 93 GotFin94 Was aber bedeutet Verfolgbarkeit genau und wie wird sie erm glicht Eine Definition gibt die IEEE Norm 830 Guide to Software Requirements Specifications A SRS software requirements specification is traceable if the origin of each of its requirements is clear and if it facilitates t
66. bernehmen Innerhalb eines Moduls bilden die Interaktionen modulinterner Operationen einen Aufrufgraph f r jeden Operationsaufruf steht fest welche Operation ausgef hrt wird Benutzungsbeziehungen modellieren die Inter aktionen zwischen Komponenten Sie bilden die Kanten des sogenannten Komponentengra phen dessen Zyklenfreiheit gefordert wird es ergibt sich also eine Komponentenhierarchie Die m glichen Interaktionen zwischen Komponenten lassen sich statisch aus den Benutzungsbeziehungen und den expliziten Importen bzw Exporten von Operationen in bzw aus einer Komponente ermitteln Zum Vergleich der Komplexit t modularer und objektorientierter Anwendungen betrachten wir Abb 22 2 a Im Spezialfall einer bin ren Benutzungshierarchie mit n Knoten gibt es n Interaktionen Im Gegensatz dazu ergeben sich bei einem beliebigen vollst ndigen schlichten Benutzungsgraph oder einem Objektnetzwerk mit n Knoten n n 1 vin Interaktionsm glichkeiten Abb 22 2 b Die Komplexit t objektorientierter Software hat drei Ursachen 1 Klassen und insbesondere Methoden haben im Vergleich zu Moduln und Prozeduren meistens eine wesentlich feinere Granularit t vgl Binder94 Hatton98 2 Dazu kommt die im Vergleich zur in der Anzahl der Moduln meistens linear wach senden Komplexit t modularer Software quadratisch wachsenden Anzahl von In teraktionsm glichkeiten der Klassen bzw ihrer Methoden in objektorien
67. bestimmten Betrachtungszeitpunkt bekannt sind Die Ver nderung bzw Erweiterung des Sichtbarkeitsbereichs im Verlauf der simulierten Operationsausf hrung skizzieren wir zun chst informell Q Der Sichtbarkeitsbereich eines Episodenschritts ohne Folgeschritte d h unmittelbar nach dem Aufruf der Operation wird als initialer Sichtbarkeitsbereich bezeichnet Er besteht aus der Klasse des ausf hrenden Objekts selbst und den Klassen ihrer At tribute Hinzu kommen die Klassen aller Parameter der dem Episodenschritt zugeord neten Operation Q Hat der Episodenschritt Folgeschritte d h im Verlauf der Operationsausf hrung wur den bereits weitere Operationen aufgerufen so erweitert sich der Sichtbarkeitsbe reich um alle Klassen der Ausgabeparameter der den Folgeschritten zugeordneten Operationen d h der benutzten oder aufgerufenen Operationen LI Im Falle des Aufrufs einer der beiden Standardoperationen x query Zugriff auf ein zelne Objekte und x iterate Zugriff auf alle bezogenen Objekte erweitert sich der Sichtbarkeitsbereich um die Klasse zu der die Assoziation x besteht Der initiale Sichtbarkeitsbereich geht statisch aus dem Klassendiagramm hervor Bei den je weiligen Operationsaufrufen werden dann die Klassen und ihre Unterklassen nachgehalten um die sich der Sichtbarkeitsbereich erweitert Wir pr zisieren dies sogleich in der folgenden Definition Definition 11 3 Seien ES die Schritte einer Episode e z
68. boosters from the main stage in turn triggering the self destruct system of the launcher This angle of attack was caused by full nozzle deflections of the solid boosters and the Vulcain main engine These nozzle deflections were commanded by the On Board Computer OBC software on the basis of data transmitted by the active Inertial Reference System SRI 2 Part of these data at that time did not contain proper flight data but showed a diagnostic bit pattern of the computer of the SRI 2 which was interpreted as flight data The reason why the active SRI 2 did not send correct altitude data was that the unit had declared a failure due to a software exception The OBC could not switch to the back up SRI 1 because that unit had already ceased to function during the previous data cycle 72 milliseconds period for the same reason as SRI 2 The internal SRI software exception was caused during execution of a data conversion from 64 bit floating point to 16 bit signed integer value The floating point number which was converted had a value greater than what could be represented by a 16 bit signed integer This resulted in an Oper and Error The data conversion instructions in Ada code were not protected from causing an Op erand Error although other conversions of comparable variables in the same place in the code were protected the failure was due to a systematic software design error Lions97 Tats chlich hatte man Teile der Lageregelungsso
69. dass jeder Use Case eine und nur eine klar umrissene Auf gabe beschreibt Der Startschritt spiegelt sozusagen den Ausl ser bzw das ausl sende Er eignis der Aufgabenausf hrung wider und wird insofern meistens von einem Aktor ausgef hrt Erst nach dieser ersten Reaktion sollten alternative Abl ufe d h Verzweigungen im Use Case Schrittgraphen auftreten Die mit dem Startschritt beginnenden und mit einem Endschritt abgeschlossenen Pfade durch den Use Case Schrittgraphen spiegeln genau die m glichen Szenarien wider die bei der Be arbeitung der dem Use Case zugeordneten Aufgabe auftreten k nnen Definition 5 5 Ein Szenario Sz eines Use Case Schrittgraphen ucs S s SE o ist ein Tu pel Sz ag Gul n gt 0 von Use Case Schritten so das gilt 1 de 5 2 dg n und a SE 3 A ola f r alle 0 lt i lt n LI Seien UC eine endliche Menge von Use Cases und uc e UC ein Use Case mit der Schrittmen ge S uc Wir erhalten eine Benutzungsrelation auf Use Cases indem wir jedem Use Case die Menge der von den Makroschritten seines Schrittgraphen referenzierten Use Cases zuord nen Aufbauend auf Definition 5 3 Makroschritt Referenzfunktion und Definition 5 4 kom men wir zur folgenden Definition 5 6 1 Wir erinnern daran dass wir Zusicherungen entweder informell umgangssprachlich oder formal als mehrsortige pr dikatenlogische Ausdr cke z B in OCL angeben 66 Grundlegende Konzepte D
70. def und uses Kanten Solche indirekten Interaktion spiegeln sich im KBD durch eine Struktur wie die in Abb A 3 fett hervorgehobene wider class A public integer a public void opA a 1 class B extends A public A einA public void opA super opA a a 1 einA opA Operation Variable a b gt gt Botschaft def uses gt Vererbung Abb A 5 Java Code und KBD zu einer lt N R gt Zustands Interaktion 252 Syntax der Test Skriptsprache Anhang B Syntax der Test Skriptsprache Dieser Anhang beschreibt die Syntax der SCORES Skriptsprache f r Testf lle Die Testf lle werden vom Test Treiber gelesen und mit aktuellen Parametern Testdaten f r eine zu tes tende Klasse CUT Class Under Test ausgef hrt Testf lle f r Klassen Cluster und Sys temtests werden rekursiv in Testsuiten organisiert Zur Erzeugung von Parameterobjekten k nnen Testf lle in Methodenaufrufen und zur Initialisierung der CUT textuelle Substituti on in einem Testfall rekursiv eingesetzt werden Terminale Symbole sind fett gedruckt nichtterminale Symbole in Standard Die verwendeten Metazeichen haben folgende Bedeutung wobei A und B beliebige syntaktische Einheiten sei en A Kein oder ein A A keines eins oder mehrere A X A entspricht X XA AB Fasst A und B zu einer syntaktischen Einheit zusammen AB Ein oder mehrere durch B getrennte A s z B A ABA oder ABABA Die Pro
71. definierte Operation op ermitteln wir nun ob op im Kontext sei ner definierenden Klasse in einer Episode simuliert wurde op isSimulated Jes e EpisodeStep alllnstances 12 8 es rootOperation op A es rootClass op Class Zuletzt miissen wir ermitteln welche dieser redefinierten Operationen in Episodenschritten im Kontext der Oberklassen benutzt wurden Dies ermittelt Funktion 12 9 k redefinedAndUsedOps op k redefinedOperations J e e EpisodeStep alllnstances e rootClass gt k A e rootOperation op 12 9 Den Prozentsatz der redefinierten und sowohl in Episoden der Oberklasse als auch der Un terklasse benutzten Operationen berechnet die polymorphe Operations berdeckung 12 10 KM O I lt Class allinstances 2P op e c redefinedAndUsedOps op isSimulated p 5 c redefinedAndUsedOps IU e Class alllnstances 12 10 Zur Illustration der minimalen Mehrfach Bedingungs berdeckung sowie dem objektorien tierten Walk Through mit der Simulation von Episoden folgt nun noch jeweils ein Beispiel Beispiel 12 2 Betrachten wir die Spezifikationen der Schritte und Kanten des Use Case Schrittgraphen Anmelden in Abb 5 5 bzw 5 6 Um das Beispiel bersichtlich zu halten be schr nken wir uns auf die vier Schritte Karte Einf hren Karte Lesen PIN Anfordern und PIN Pr fen In Tab 12 1 haben wir zun chst die Vor und Nachbedingungen dieser vier Schritte nach Konjunktionstermen getrennt aufgelistet Bei de
72. dem Test bereits existieren m ssen leiten wir aus dem Klassenbereich des dem Test Szenario Schritt zugeordneten Use Case Schritts ab Aus den Signaturen der Wurzeloperationen und der von den Episodenschritten ausgef hrten Operationen bestimmen wir als Testorakel die innerhalb eines Test Szenarios modifizierten bzw erzeugten Instanzen von Klassen die von den Dom nenklassen aus verfolgbar sind Nat rlich k nnen wir nicht erwarten die so spezifizierten erwarteten Abl ufe tats chlich eins zu eins bei der Ausf hrung wiederzufinden Nach den Ausf hrungen im vorigen Ab schnitt finden zus tzliche interne Interaktionen statt die implementationstechnische Details verk rpern Allerdings sollten die spezifizierten Abl ufe von den sich ergebenden Abl ufen berdeckt werden bzw sich in diese einbetten lassen 16 5 Methodisches Vorgehen Wir gehen beim Scores grey box Test nach dem Algorithmus Grey box Test Abb 16 4 vor Die Test Reihenfolge ermitteln wir wie im black box Test ber die invertierte topologische Sortierung der als azyklischen Graph interpretierten Inter Use Case Referenzfunktion REF Dann iterieren wir in dieser Reihenfolge ber alle Use Cases und alle Test Szenarien jedes Use Case Zeilen 5 15 Zun chst ermitteln wir in den Zeilen 5 10 die Einstiegspunkte also die ber die Verfolgbarkeit den Operationen der Episoden direkt zugeordneten Elemente der Implementation und danach ber die transitive H lle des KBD
73. den Implementationsklassen welche die Beziehung x des Klassendiagramms der Anfor derungsspezifikation realisieren Die Standardoperation query spiegelt sich in mindestens ei ner mit new markierten Kante des KBD wider die Standardoperation destroy in entsprechenden Methodenknoten des KBD Ausgehend von den direkt vom KBD erreichbaren Knoten des KBD erreichen wir transitiv weitere Knoten des KBD den resultierenden Teil des KBD nennen wir KB A Es ver bleibt ggf ein nicht leerer Teil Graph KBD KBD ra Dieser Sachverhalt ist in Abb 16 3 dargestellt Ist KBD KB ra so k nnen verschiedene Umst nde vorliegen von denen wir die wichtigsten kurz erl utern und Ma nahmen zu ihrer Behandlung im grey box Test angeben KBD Implementation Anforderungsspezifikation Abb 16 3 KBD vs KBD 1 Da def bzw uses Kanten immer vom Variablen zum Methodenknoten bzw umge kehrt gerichtet sind enthalten die indirekten Interaktionen entsprechenden Pfade immer gleichviele jeweils aufeinanderfolgende def und uses Kanten 176 SCORES grey box Test Q Es kann eine Botschaft erzeugt werden f r die keine zugeh rige Operation in den bei der Generierung des KBD ber cksichtigten Klassen gefunden wird In diesem bei Bibliotheksklassen h ufig eintretenden Fall ist die betrachtete Anwendung nicht ab geschlossen Den Abschluss erreicht man entweder durch Hinzuf gen geeigneter wei terer Bibliotheks Klassen oder aber neuer
74. der Beschreibung eines Use Case Schritts bezogen auf die entspre chende Gesch ftsregel Abb 9 1 zeigt einige exemplarische Checklistenpunkte f r die Validierungs Inspektionen Umfassendere und konkretere Checklisten sind abh ngig von der Anwendungsdom ne und z B den personellen und fachlichen Gegebenheiten zu erstellen Nach den Inspektionen ist die fachliche Vollst ndigkeit der Anforderungsspezifikation in Bezug auf die Funktionalit t und die fachliche Korrektheit der Aufgabenbeschreibungen gegen die Organisatorische Sicht und die Leistungssicht des Gesch ftsprozesses gepr ft Fachliche Vollst ndigkeit Sind alle Eintr ge der Produktskizze in Use Cases erfasst Sind alle Gesch ftsvorf lle in den Use Cases erfasst Gibt es L cken in den Use Case Schrittgraphen also fehlende Schritte oder Kan ten Sind f r alle Use Case Schritte und alle Kanten Vor und Nachbedingungen defi niert Sind alle betroffenen Klassen im Bereich eines Schritts enthalten Fachliche Korrektheit Erfassen die Vorbedingungen der Use Cases erlaubte Gesch ftssituationen Beachten die Spezifikationen der Use Cases die bekannten Gesch ftsregeln Erfassen die Nachbedingungen der Use Cases erlaubte Gesch ftssituationen Ist das erwartete Ergebnis eines Szenarios korrekt in den Nachbedingungen der im Szenario enthaltenen Schritte insbesondere im Endschritt wiedergegeben Pr fbarkeit Ist die Aufgabe eines Use Cases bzw Use
75. f r den grey box Test erweitert Hierbei sind zun chst lediglich die in den Episoden simulierten Abl ufe in den Test Orakeln zu spezifizieren Bei der Testaus f hrung bzw der Testauswertung wird dann gepr ft ob diese Abl ufe sich in die tats chlich gemessenen Abl ufe einbetten lassen Methodisches Vorgehen 181 TESTCASE AnmeldungOKGreyBox USECASE Anmelden Bankleitzahl String 8 Kontonummer String 10 G ltigkeitsdatum Date Kartennummer Integer PIN Integer Der BankKunde identifiziert sich durch Eingabe der Karte und der PIN PRECONDITION AccountCreatedOrExists Bankleitzahl Kontonummer AND CardNotLocked Bankleitzahl Kontonummer G ltigkeitsdatum Kartennummer AND ATMReadyAndOnline BEGIN Karte Eingeben KarteEinf hren Bankleitzahl Kontonummer G ltigkeitsdatum Kartennummer ORACLE Kartenleser state asString locked Kartenleser leseKarte Karte new PIN Anfordern und pr fen Transaktion pr fePIN PINAnfordern PIN ORACLE Kartenleser state asString locked AND PIN_OK Bedienpult lesePIN Transaktion pr fePIN ZentralrechnerSchnittstelle pr fePIN Karte modify Auswahl anzeigen Bedienpult Men Anzeigen END TESTCASE KarteHinfiihren ROOTCLASS Kartenleser Bankleitzahl String 8 Kontonummer String 10 G ltigkeitsdatum Date Kartennummer Integer LOCAL theCard Karte BEGIN Der BankKunde f hrt die Karte in den Kartenleser ein Kartenleser erwarte
76. f r die formale Korrektheit der Anforderungsspezifikation Q Unter dem Begriff der fachlichen Korrektheit werden bei der Anforderungsermittlung alle Unstimmigkeiten der Anforderungsspezifikation mit den eigentlichen Anforde rungen bzw der Dom ne zusammengefasst in der die Anwendung eingesetzt werden soll Hierunter fallen z B verletzte Gesch ftsregeln oder Gesetze fehlerhafte Daten definitionen oder aber falsch verstandene Benutzerw nsche Zus tzlich enth lt diese Kategorie berspezifikationen ein Element das die Realisierung von Anforderungen beschreibt und nicht testbare Anforderungen Wunschdenken bells and whistles Anforderungen deren Erf llung entweder unm glich oder aber nicht berpr fbar ist Die Validierung soll die fachliche Korrektheit und Vollst ndigkeit sicherstellen die Verifi kation die formale Korrektheit Die Anforderungsspezifikation ist der erste Meilenstein in der Entwicklung oder Erweite rung einer Anwendung Daher stehen Analytiker und Tester im Rahmen der Qualit tssiche rung vor dem Problem die Anforderungsspezifikation zumeist nicht z B unter Benutzung umfassender Checklisten gegen ein qualit tsgesichertes Ausgangsdokument validieren zu k nnen sondern nur gegen die oft eher vagen Vorstellungen und W nsche der Benutzer M gliche Methoden zur Validierung sind somit das Prototyping sowie Reviews als manu elle statische Verfahren zur Pr fung von Entwicklungsprodukten bzw i
77. gilt o e K operations abk r zend auch k o OPS sei die Menge aller Operationen im Klassenmodell also OPS UJ a k operations Jede Operation o e OPS wird durch ihren Namen o name und ihre Signatur o signature e Kerl syntaktisch spezifiziert wobei n e IN die Anzahl der Para meter von o angibt und jede Operation genau einen R ckabewert liefert Sei n gt 0 F r o sig nature Ko Kp sind Ko Ka die Typen bzw Klassen der Parameter und k diejenige des R ckgabewerts der Operation Abk rzend schreiben wir auch o name Ko K K F r s Ko Kp K bezeichnen wir mit Ko K die Menge der in s vorkommenden Klassen d h Ko k ke Kl3ieN k k Neben den Signaturen spezifizieren wir die Semantik von Operationen durch Vor und Nach bedingungen die wir in OCL mit o pre und o post ansprechen Die Semantik einer Klasse wird durch die Angabe von Klasseninvarianten spezifiziert Jedes Objekt der Klasse erf llt vor und nach der Ausf hrung einer Operation die Klasseninvariante Wir bezeichnen die In variante einer Klasse k mit k invariant Vor und Nachbedingungen sowie Klasseninvarianten 1 Die in Invarianten und Vor und Nachbedingungen verwendeten Operationen werden als Seiteneffektfrei vorausgesetzt bzw angenommen vgl Meyer97 0MG97 Klassenbereiche 87 notieren wir wie schon bei der Spezifikation von Use Cases und Use Case Schritten entwe der umgangssprachlich oder in
78. hren Nachbedingung arte im Kartenleser UND Kartenleser gesperrt true true i Ea AER true true true arte Lesen Vorbedingung arte im Kartenleser UND Kartenleser gesperrt Lesen Nachbedingung lesbar UND Code g ltig Lesen Nachbedingung arte lesbar Lesen Nachbedingung Code g ltig ln lr EES true zanse lr true PIN Anfordern Vorbedingung Karte im Kartenleser UND Kartenleser gesperrt UND Karte lesbar UND Code g ltig PIN Anfordern Nachbedingung PIN gelesen PIN Anfordern Nachbedingung Abbruch PIN Pr fen Vorbedingung Karte im Kartenleser UND Kartenleser gesperrt UND Karte lesbar UND Code g ltig UND PIN gelesen PIN Pr fen Nachbedingung PIN OK PIN Pr fen Nachbedingung NICHT PIN OK false true Tab 12 1 Testfallermittlung zur minimalen Mehrfach Bedingungs berdeckung ausgerichtet in den Kartenleser eingef hrt wurde erwarten wir dass sich die Karte im Kar tenleser befindet und der Kartenleser gesperrt i st Diese Belegung der Terme in der Nachbe dingung erf llt auch die Vorbedingung des Folgeschritts Karte Lesen den wir als n chstes ausf hren k nnen da ja auch die Bedingung der entsprechenden Kante hier trivialerweise erf llt ist Aufgrund der Annahme lesbare zum Zugriff auf diesen Automaten berechtigen den Karte wird diese vom Kartenleser gelesen so dass der erste Konjunktionsterm der Nach bedingung
79. im Kartenleser Kartenleser gesperrt Karte lesbar Code g ltig PIN gelesen PIN OK Bedienpult auswahlbereit ODER Karte nicht lesbar Karte eingezogen ODER Code nicht g ltig Karte ausgeworfen ODER PIN dreimal falsch eingegeben Karte gesperrt Karte ausgeworfen UND Kartenleser betriebsbereit Bedienpult gesperrt END Anmelden Abb 5 3 Spezifikation des Use Case Anmelden oO Die Summe der Use Cases stellt eine relativ abstrakte funktionale Sicht auf die Anforderun gen dar die insbesondere in Hinblick auf das Klassenmodell sowie die Ableitung von Test f llen nicht hinreichend ist Wir verfeinern daher jeden Use Case analog zu einer Aufgabenhierarchie vgl KSV96 Rosson99 in einzelne Teilaufgaben entsprechende Use Case Schritte Zus tzlich halten wir fest welcher der dem Use Case zugeordneten Aktoren ei nen bestimmten Use Case Schritt bearbeitet und spezifizieren die Teil Aufgaben der Schritte analog zur Aufgabe des Use Cases mit Vor und Nachbedingungen Wie schon bei Use Cases beschreiben die Vor und Nachbedingungen die Aufgaben der Use Case Schritte ber den Zustand von ihnen betroffener Realweltobjekte Definition 5 2 Ein Use Case Schritt eines Use Cases uc ist definiert durch m einen im Kontext des Use Cases uc eindeutigen Namen die textuelle Beschreibung der Teil Aufgabe des Schritts LI LI eine Menge A c A uc von in die Teil Aufgabe des Schritts involvierten Aktoren LI eine Vor und eine Nachbeding
80. im Use Case Schrittgraph durchlaufen H ufig entdeckte Fehler sind hierbei fehlende falsche oder mehrdeutige Schrit te Gesch ftsregeln verletzende Vor und Nachbedingungen der Schritte bzw bergangsbe dingungen der Kanten und die unvollst ndige Behandlung von Ausnahmesituationen Zur Vorbereitung eines Walk Throughs leiten Analytiker und Tester aus dem Klassenmodell anhand der Vorbedingung des Use Cases und seinem Klassenbereich eine initiale Objektkon stellation ab welche die angenommene Gesch ftssituation widerspiegelt s auch Abschnitt 17 1 Zu Beginn des Walk Throughs pr fen Benutzer und Dom nenexperten ob die zum Start des Gesch ftsvorfalls notwendige Information bzw Situation gegeben ist Hierzu ver gleichen Analytiker gemeinsam mit den Benutzern die jeweilige Objektkonstellation mit re alen Konstellationen in der Problemwelt Zur Unterst tzung der Benutzer die im Allg mit Klassenmodellen bzw Objektkonstella tionen wenig vertraut sind k nnen Metaphern in Multimediasequenzen festgehaltene Realwelt Szenen oder einfache dom nenspezifische Piktogramme verwendet werden vgl Z llighoven98 MCP 98 Hasselbring98 Zur weiteren Erh hung der Anschaulichkeit lassen sich einzelnen Szenarioschritten auch manuell erstellte oder mit einem GUI Werkzeug skizzierte Layouts von Fenstern oder Bildschirmmasken zuordnen Wir erhalten auf diese Weise N herungen an nicht operationale Prototypen der Anwendung auch
81. internes Verhalten und damit die Frage wie die funktionalen Anforderungen im Dom nen Klassenmodell abgebildet werden 11 1 Struktureller Aufbau Die Verifikation in SCORES beinhaltet zun chst eine Serie separater schrittweiser Inspektio nen der Use Case Schrittgraphen und des Klassenmodells Ziel der Inspektionen ist die Auf deckung inkonsistenter und oder mehrdeutiger sowie unvollst ndiger Spezifikationen Analytiker konzentrieren sich bei der Verifikation von Use Case Schrittgraphen auf die kor rekte Umsetzung der textuell angegebenen Vor und Nachbedingungen in pr dikatenlogische bzw OCL Ausdr cke So muss z B die Bearbeitung der Aufgabe eines Use Case Schritts s f r alle Objektkonstellationen und ggf Eingaben die laut der Vorbedingung von s und dem Klassenmodell erlaubt sind s auch Kapitel 17 ein Ergebnis erbringen welches der Nach bedingung von s und dem Klassenmodell gen gt Um die Bedingungen der von s ausgehen den Kanten im Use Case Schrittgraph zu verifizieren suchen die Analytiker f r jede Kante zumindest eine laut Vorbedingung von s erlaubte Objektkonstellation f r welche nach der Ausf hrung von s die Bedingung der betrachteten Kante erf llt ist Zus tzlich wird im Falle eines Interaktionsschritts der Klassenbereich und die Spezifikation der Wurzeloperation ge pr ft Auch globale Eigenschaften wie z B die Erreichbarkeit der einzelnen Schritte und die Terminierung der Abl ufe sind Gegenstand der Verifi
82. k nnen abh ngig von seiner Metaklasse weitere Spezifikationseditoren z B f r die Operationen einer Klasse oder die Multip lizit ten von Beziehungen aktiviert werden Abb 20 1 zeigt einen Screen Shot des Klassendiagramm Editors Anforderungsspezifikation 199 SCORES Editor Bankautomat ATMGerman2 mdl I Datei Tools Darstellung Themenbereich Netz Klasse Beziehung Evaluation Hilfe Zentralrechner Schnittstelle Kartenleser Transaktion Zustand Start leseDaten Ende schreibeDaten Betrag zieheKarteEin Plan Kontonummer werfeKarteAus Zustand Ident Code erwartekarte SC beginne commit end pruefePIN fuerePlanAus rollback Geldeingabe Zustand gibKonto pruefePIN Karte Datum AnzahiVersuche Bedienpult GesamtBetragDatum Kredit Limit pruefePIN leseAuswahl G zeigeGruss lesePIN leseKonto leseBetrag Auszahlung Einzahlung Belegdrucker Konto pruefe pruefe Kontonummer drucke Zeie BLZ Zustand Kontotyp Krecitlimit Saldo eroeffne Geldausgabe berweisung schliesse Betrag einzahlung auszahlung kannAusgeben sperre gibAus pruefeAuszahlung Bargeld pruefe
83. kel Verifikation Episode Testdaten Testorakel Grey box Objektkonstellation Testumgebung Tab 18 1 Anforderungsermittlung vs Test Mit dem vorgestellten methodischen Vorgehen haben die Tester konkrete Aufgaben ber alle T tigkeiten hinweg und stehen damit in der Entwicklung nicht mehr am Ende der Schlange ber die direkte Zuordnung der Testelemente zu Elementen aus der Anforderungsermittlung wird der Testfortschritt messbarer und damit der Testprozess steuerbar Die am Anfang der Entwicklung erforderliche Mehrarbeit Abb 5 2 s Seite 60 z B bei der Spezifikation von Use Case Schrittgraphen und der Formalisierung der Bedingungen zahlt sich durch den bei den Tests der Anwendung gegen die Anforderungsspezifikation abgesch pften Mehrwert aus 1 Die Fehlerrate gibt die Anzahl gefundener Fehler pro Implementationseinheit z B Fehler 1000 Lines of Code error KLOC an s Riedemann97 192 Endekriterien Ausf hrung und Auswertung Teil V Werkzeugunterst tzung Die in den bisherigen Teilen der Arbeit vorgestellte Methode SCORES zur Anforderungsermittlung Validierung und Verifika tion der Anforderungsspezifikation und Testfallgenerierung stellt hinsichtlich einer w nschenswerten umfassenden Werk zeugunterst tzung keine Ausnahme dar so dass wir SCORES durch ein entsprechendes Werkzeug das SCORESTOOL erg nzt haben In diesem Teil gehen wir daher in Kapitel 19 kurz auf die Kon zept
84. ki 5 Karte Lesen Actors Bankkunde Goal Subgoals Der Bankkunde gibt seine Karte ein Der Kartenleser liest den Magnetstreifen der Karte Der Bankautomat fragt nach der PIN der Bankkunde gibt Scenario Step E f Karte Einziehen 5 PIN Anfor Der Kartenleser liest den Magnetstreifen der Karte A El Karte Schreiben Abb 20 5 SCORESTOOL Szenario Browser textuelle Sicht Test Szenarien Wahrend einer Validierungssitzung verwenden Analytiker bzw Tester den SCORESTOOL Szenario Browser zur Konstruktion und Protokollierung der Test Sze narien In Abb 20 5 ist ein Screen Shot des Szenario Browsers bei der Konstrukti on eines Test Szenarios zum Use Case Anmelden gezeigt Oben in der Mitte erkennt man das Test Szenario links unten den Schrittgraphen des in der Listbox oben links ausgew hlten Use Cases hier Anmelden Der Szenario Browser erm glicht ver schiedene Sichten auf das Test Szenario in Abb 20 5 ist die textuelle Sicht gew hlt Comment Benutzerfreundlicher als die textuelle Sicht ist die in den Walk Th roughs vornehmlich verwendete mit Skizzen der Benutzungsoberfl che animierte Sicht des Szenario Browsers OUT vgl KPR 97 F r den Schritt PIN Eingeben im Test Szenario Erfolgreiche Online Anmeldung zum Use Case Anmelden ist eine solche Sicht in Abb 20 6 dargestellt Validierungsmetriken Auf Anforderung k nnen dir
85. orientieren uns an dem aus Objectory JCJ 92 hervorgegangenen Rational Unified Process RUP Kruchten99 JBR99 der die Vorteile herk mmlicher Vorgehens modelle wie z B des iterierten Phasenmodells oder der evolution ren Softwareentwicklung vgl PagSix94 in sich zu vereinigen sucht Wir zeigen dann wie Gesch ftsprozesse und Workflow Modelle den Kontext f r die zu entwickelnden Anwendungen bilden und gehen auf die Anforderungsermittlung den Entwurf und die Implementation sowie kurz auf die Qualit tssicherung ein Letztere ist Gegenstand des n chsten Kapitels Kruchten und Jacobson beschreiben den RUP anhand der zwei Dimensionen Zeit und T tig keiten Abb 2 1 Organisation nach der Zeit Phasen Zentrale Entwicklungst tigkeiten Konzept Ausarbeitung Konstruktion bergang Gesch ftsprozess Modellierung Anforderungsermittlung Entwurf Organisation nach den Implementation Tatigkeiten Test Auslieferung Administrative Tatigkeiten Konfigurationsmanagement Projektmanagement Umgebungsmanagement Iterationen Abb 2 1 Der Rational Unified Process nach JBR99 berblick ber die Arbeit 13 Q Die horizontale Achse repr sentiert die Zeit und zeigt die Dynamik der einzelnen T tigkeiten also das Wann Die Zeitachse ist in Zyklen Phasen und Iterationen einge teilt Der Lebenszyklus objektorientierter Software wird im Allgemeinen f r jede Generation bzw Version einer Anwendung durch
86. orientierte Welt der elektronischen Datenverarbeitung und ihre Fachbe griffe besitzen Aus den W nschen und h ufig vagen Vorstellungen des Auftraggebers ent wickeln sich erst allm hlich konkrete Vorgaben an die Anwendung die wieder und wieder berarbeitet und gemeinsam validiert werden Wenn die Vorstellungen des Auftraggebers und der Benutzer nicht richtig ermittelt und in der Anforderungsspezifikation entsprechend fixiert sind Kann keine Produktakzeptanz erreicht werden Dar ber hinaus stellt die Anforderungsspezifikation den Ausgangspunkt f r die weiteren Entwicklungst tigkeiten dar und hat somit auf alle Teilaspekte der Softwareentwicklung ei nen zum Teil erheblichen Einfluss vgl Faulk97 Die Anforderungsspezifikation muss als hierf r taugliche Basis ausreichend pr zise sein Ohne eine sorgf ltig durchgef hrte Anforderungsermittlung werden fehlerhafte fehlende widerspr chliche oder mehrdeutige Anforderungen oftmals erst in der letzten Entwicklungs phase d h beim System oder Abnahmetest entdeckt Fehler die das Au enverhalten des Produkts betreffen werden beim praktischen Einsatz vom Benutzer rasch festgestellt und las sen ihn an der Eignung des Produkts zweifeln Tab 2 1 gibt einen berblick der relativen Kostenfaktoren zur Behebung eines Fehlers der Anforderungsspezifikation der bei einer bestimmten T tigkeit der Softwareentwicklung ent deckt wird Die Kosten steigen berproportional da mit fortschreitender
87. priifePIN pr fePIN 1 Zentralrechner pr fePIN Schnittstelle R gt Karte offline Auswahl Anzeigen Auswahl Bedienpult pr fePIN leseAuswahl modiy wl T Abb 12 3 Episode zum Schritt PIN Pr fen im Test Szenario Offline Anmeldung Hiermit sind wir am Ende unserer Ausf hrungen zu den qualit tssichernden T tigkeiten bei der Anforderungsermittlung angelangt Zur besseren Einordnung fasst Tab 12 2 die verwen deten Begriffe und SCORES Elemente noch einmal bezogen auf die T tigkeiten Spezifikation Validierung und Verifikation zusammen Spezifikation Validierung Workflow Aspekt Verifikation Funktionale Zerlegung Externes Verhalten Struktureller Aufbau Internes Verhalten Use Cases Use Case Schritte Use Case Schritt graphen lassen Attribute Assoziationen lassenbereiche Verantwortlichkei ten Organisation Funktio nalit t Operational Kausalit t vorf lle Ablauf Gesch fts Information Objektkonstellationen Verantwortlichkeiten von Dom nenobjekten Vor und Nachbedin gungen bergangsbedingun gen Test Szenarien Klassenmodell Operationen den Episo Tab 12 2 Einsatz der SCORES Elemente bei der Anforderungsermittlung Nach einem Exkurs zur Verfolgbarkeit der Elemente der Anforderungsspezifikation ber den Entwurf in die Implementation kommen
88. r einen erh hten Quali t tssicherungsbedarf bei der Entwicklung objektorientierter Software finden wir bei Perry und Kaiser die bei der Untersuchung des Wiederverwendungspotentials objektorientierter Software 1990 feststellen 28 Probleme der Qualit tssicherung f r objektorientierte Anwendungen we have uncovered a flaw in the general wisdom about object oriented languages that prov en that is well understood well tested and well used classes can be reused as superclasses without retesting the inherited code PerKai90 Der bekannte Test Spezialist Boris Beizer bemerkt letztendlich it costs a lot more to test oo software than to test ordinary software perhaps four or five times as much inheritance dynamic binding and polymorphism creates testing problems that might effect a testing cost so high that it obviates the advantages Beizer94 Die Objektorientierung ist heute ein weitverbreitetes Entwicklungsparadigma Allerdings wird ihre Eignung nach der anfanglichen Begeisterung in neuester Zeit auch angezweifelt Hatton98 Betrachten wir die objektorientierte Softwareentwicklung aus dem Blickwinkel der Qualit tssicherung so stellen sich Fragen wie z B Q Welche Fehler treten bei objektorientierter Software auf Q Welche Modelle sind brauchbar um auf m gliche Fehlerquellen schlie en zu k n nen Q Mit welchen Verfahren k nnen Tests f r objektorientierte Modelle Spezifikationen und Implemen
89. r jede Klasse k aus K eine Multiplizit t ck Anzahl der zu generierenden Instan zen der Klasse k Gesucht ist eine zu KM konsistente Objektkonstellation Die Komplexit t von GOK ergibt sich aus dem folgenden Satz Satz 17 1 GOK ist NP hart Beweis Skizze Wir w hlen als NP vollst ndiges Problem das Erf llbarkeitsproblem f r aussagenlogische Formeln in konjunktiver Normalform satisfiability SAT vgl GarJoh79 Zur Reduktion von SAT auf GOK transformieren Instanzen von SAT in drei Schritten auf In stanzen von GOK 1 Zun chst erzeugen wir f r jede Aussagenvariable a zwei Klassen eine die Variable selbst darstellende Klasse Va mit der Kardinalit tsbeschr nkung 0 1 von jeder Klasse darf also h chstens eine Instanz generiert werden und eine den Wert der Va riablen symbolisierende abstrakte Klasse Wa zu deren Objekten genauer zu Objek ten konkreter Unterklassen wir das singul re Objekt der Klasse Va in eine 1 1 Beziehung setzen Wir nennen diese beiden Klassen die VW Klassen zur Aussagenva riable a Die Kardinalit tsbeschr nkung der Klasse Va spiegelt sozusagen die Identit t bzw Einmaligkeit der Aussagenvariable a wider die Klasse Wa generalisiert die 1 Wir nennen eine Objektkonstellation konsistent zu einem Klassenmodell wenn sie keine Instanzen abstrakter Klassen enth lt und keine der angegebenen Multiplizit ten f r Klas sen und Beziehungen verletzt 2 Ein Problem p e NP wird NP hart
90. rungsspezifikation gg is Fehler der Fehler der a a Anforderungs ermittlungs ermittlungs Test der Soft warespezifikation EEE IR Testf lle Entwurfsfehler Klassentest 2 KEES Entwurfsfehler Codierungsfehler Abb 1 2 Fokus der Arbeit Grafik nach PagSix94 der Anforderungsermittlung und den Test der Anwendung gegen die Anforderungsspezifika tion betreffen und die wir mit dieser Arbeit beheben wollen In diesem Zusammenhang stel len wir auch relevante Arbeiten anderer Autoren zu diesen Themen vor Nach diesen motivierenden Worten geben wir nun einen berblick in Form eines Weg weisers durch die weiteren Teile der vorliegenden Arbeit Im Mittelpunkt steht SCORES Systematic Coupling of Requirements Specifications unsere qualit tszentrierte Methode zur Anforderungsermittlung Die Arbeit gliedert sich in die in Abb 1 2 hervorgehobenen drei jeweils aufeinander aufbauenden Themenbereiche Q Pr zisierung und Verfeinerung der Anforderungsspezifikation mit Use Cases Q Qualit tssicherung bei der Anforderungsermittlung und Q Ableitung von Testf llen aus der Anforderungsspezifikation Im zweiten Teil stellen wir die Konkretisierung und Spezifikation von Anforderungen mit SCORES vor In Anbetracht der aufgedeckten Schwachpunkte der klassischen Use Case Analyse nach Jacobson f hren wir Use Case Schrittgraphen zur Pr zisierung und Verfeine rung von Use Cases al
91. support for the model based develop ment of interactive applications The FLUID approach Proc 4th Eurographics Workshop on Design Specification and Verification of Interactive Systems Gra nada Espagne 1997 HOR98 A H M ter Hofstede M E Orlowska J Rajapaske Verification Problems in Con ceptual Workflow Specifications Data amp Knowledge Engingeering Jahrg 24 1998 S 239 256 HsiKun97 Pei Hsia David Kung Software Requirements and Acceptance Testing Annals of Software Engineering Jahrg 3 1997 S 291 317 H rsch95 Walter L H rsch Maintaining Consistency and Behavior in Object Oriented Systems during Evolution Dissertation Northeastern University 1995 Hurlbut98 Russel R Hurlbut Managing Domain Architecture Evolution Through Adaptive Use Case and Business Rule Models Ph D Thesis Illinois Institute of Techno logy Chicago USA 1998 IEEE610 90 IEEE Standard Glossary of Software Engineering Terminology IEFE Stan dard 610 IEEE New York 1990 IEEE829 83 IEEE Standard for Software Test Documentation IEEE Standard 829 IEEE New York 1983 best tigt 1990 IEEE830 93 IEEE Guide to Software Requirements Specifications IEEE Standard 830 IEEE New York 1993 IEEE1233 96 IEEE Guide for Developing System Requirements Specifications IEEE Stan dard 1233 IEEE New York 1996 225 ISO9001 3 92 DIN ISO 9000 Teil 3 Qualit tsmanagement und Qualitdtssicherungsnor men Leitfaden f r die Anwendung
92. ten dementsprechend f r den Aktor Bankkunde drei Use Cases F r den Aktor Bediener mo dellieren wir zun chst einen Use Case Administration Der maschinelle Aktor Zentralrechner partizipiert an den drei den Transaktionen entsprechenden Use Cases Geld Abheben Geld Einzahlen und Geld Transferieren Spezifzieren wir beispielsweise den Use Case Geld Abheben textuell so erhalten wir ohne Anspruch auf Vollst ndigkeit die in Abb 4 1 dargestellten Haupt und alternativen Abl ufe Bei der Spezifikation der weiteren Use Cases f r den Aktor Bankkunde stellen wir fest dass wir f r jeden der drei Use Cases Geld Abheben Geld Einzahlen und Geld Transferieren die Anmeldung des Bankkunden am Bankautomaten spezifizieren m ssten Da die Anmeldung f r sich alleine den beobachtbaren Fortschritt Angemeldet f r den Aktor Bankkunde liefert modellieren wir Sie als eigenst ndigen Use Case Anmelden der von den anderen drei Use Cases benutzt wird wir verwenden die uses Beziehung wobei der Use Case Anmelden als abstrakter Use Case bezeichnet wird JCJ 92 Das vollst ndige Use Case Diagramm zeigt Abb 4 2 Wenden wir uns dem strukturellen Modell zu Ein rudiment res Objektdiagramm f r den Bankautomaten zeigt Abb 4 3 Wir stellen uns den normalen Ablauf des Use Cases Geld Ab 1 Die Anmeldung alleine k nnte allerdings z B der Validierung der Karte bzw der PIN durch den Bankkunden dienen so dass in diesem Falle auch der Einsatz der ext
93. tenteils nicht miteinander kombinierbar bzw erweiterbar sind versuchen Qe SS SKI 32 wet QO fe I Interaktionsdiagramm Klasse D Beziehung O H 2 Operation E Niedri ERR Poeh Strukturelle Abstraktion Abb 5 1 Die Abstraktionsl cke zwischen Use Case Modell und Klassenmodell 60 Grundlegende Konzepte Pr zision Testbarkeit Vollst ndigkeit Konsistenz Korrektheit nderbarkeit Verst ndlichkeit Abb 5 2 Das Kosten Teufelsquadrat der Anforderungsermittlung wir daher in den folgenden Kapiteln die interessantesten Ideen in einem flexiblen aus drucksstarken Konzept zu vereinigen und mit eigenen Vorschl gen zur Erf llung aller oben genannten Anforderungen zu vervollst ndigen Es bleibt zu Bemerken dass pr zisere Anforderungsspezifikationen zun chst nicht kosten neutral erstellt werden k nnen Abb 5 2 zeigt z B wie bei gegens tzlichen Forderungen die Erh hung der Pr zision und Testbarkeit bei gleichbleibenden Kosten zu einer verminderten Erf llung anderer Forderungen f hrt Ein h herer Einsatz bei der Anforderungsermittlung er gibt jedoch eine besser oder berhaupt erst pr fbare Anforderungsspezifikation Zus tzlich sind im weiteren Verlauf der Produktentwicklung gegen diesen Einsatz der u erliche Mehrwert z B einer h heren Gebrauchstauglichkeit und der innerliche Mehrwert eines gegen die Anforderungsspezifikation pr fbaren Pr
94. tionen pr fen und gezielt vertraglich geforderte Werte f r strukturelle Testkriterien erreichen Kapitel 16 Im Hinblick hierauf nutzen wir in sogenannten SCORES grey box Tests die Vor teile der Pr fung des Zusammenspiels mehrerer Methoden mit Aufrufsequenzen unter Mini mierung des h heren Aufwands bei der Erstellung der erwarteten Ergebnisse Hierzu verwenden wir das Klassen Botschaftsdiagramm f r die SCORES Anforderungsspezifikation KBD welches die bei der Verifikation betrachtete systeminterne Information der Episo den geeignet zusammenfasst Zus tzlich generieren wir auch f r die zwischen Implementati onsklassen m glichen internen Interaktionen ein Klassen Botschaftsdiagramm KBD Dann geben wir an wie die systeminterne Information der Anforderungsspezifikation auf die zwischen Implementationsklassen m glichen Interaktionen abgebildet werden kann Indem wir Episoden quasi als Testorakel verwenden k nnen wir die Testf lle des black box Tests erweitern und kommen zu SCORES grey box Testf llen die gezielt versuchen eine bestimmte geforderte strukturelle berdeckung zu erf llen F r den Test ben tigen wir eine geeignete Initialisierung z B der persistenten Daten Dies f hrt im Falle objektorientierter Daten zum Problem der Generierung von Objektkonstellati onen Kapitel 17 Wir zeigen dass dieses Problem NP hart ist und geben Hinweise auf ent sprechende Heuristiken Kapitel 15 Black box Test Black box testing wil
95. ts SE uc Wir werden Test Szenarien w hrend der Verifikation um weitere systeminterne Information anreichern In Teil IV zeigen wir dann wie solche Test Szenarien f r den dynamischen Test der Anwendung gegen die Anforderungsspezifikation wiederverwendet werden 9 4 Scores Metamodell III In diesem Abschnitt erweitern wir die in den Abbildungen Abb 5 7 und Abb 7 2 dargestell ten partiellen Sichten des SCORES Metamodells um Primitive zur Modellierung von Test Sze narien und erhalten das in Abb 9 1 gezeigte UML Klassendiagramm Die Klasse TestScenario ist Unterklasse von ValidationClassifier und erbt somit ihren Klassenbe reich Die Folgeschrittfunktion wird durch die Beziehung successor modelliert deren Mul tiplizit ten die m glichen Strukturen der Szenarien auf lineare Listen einschr nken 114 refersTo 7 validation StepGraph 1_Protocoll TestScenario 0 1 F 0 1 g ValidationClassifier rk n 8 e S p 2 E 8 G A S Actor oO ba n Assertion t Ss g l T UseCaseStep 1 ScenarioStep e E A successor Class successors rootClass 1 InteractionStep ContextualStep MacroStep Abb 9 1 SCORES Metamodell mit Test Szenario Validierung Kapitel 10 Validierungsmetriken Question What do you do when you see a graph Answer
96. und Benut zungen der Variablen schon zu Beginn des Tests der gesamten Anwendung gepr ft sein Mit den SCORES grey box Tests k nnen gezielt Definitionen und Benutzungen von solchen Va riablen gepr ft werden die sich zur ck zu Attributen und Assoziationen im Dom nen Klas senmodell verfolgen lassen Im Falle polymorpher k nnen wir zur Auswahl der Klassen auch hier wieder das Verfahren OATS einsetzen s Roy90 McDMcG94 18 2 Testausf hrung Mit den konkreten Testdaten und dem ggf instrumentierten Pr fgegenstand erfolgt in der spezifizierten Testumgebung die Testausf hrung Hierzu werden die Tests in der angegebe nen Reihenfolge ausgef hrt und die Testergebnisse protokolliert Gem dem gew hlten strukturellen Testkriterium Anweisungs berdeckung Zweig berdeckung etc wird zu n chst in der nstrumentierung der Pr fgegenstand so um zus tzliche Anweisungen erweitert dass bei der Testausf hrung Informationen zur Berechnung der erzielten berdeckung aus gegeben werden z B in Form von Datei oder Datenbankeintr gen f r jede durchlaufene An weisung bzw jede ausgewertete Bedingung Die Testausf hrung ist somit der dynamische Test im herk mmlichen Sinn Dabei werden diverse Testprotokolle produziert darunter ein Ablaufprotokoll ein Ergebnisprotokoll und ein Protokoll der erreichten Werte f r die Test 1 Hierbei gehen wir davon aus dass Zugriffe auf atomare Instanzvariablen in entsprechen den Methoden gekapselt sind
97. von ISO 9001 auf die Entwicklung Liefe rung und Wartung von Software Beuth Verlag Berlin 1992 ITU93 ITU Telecommunications Standard Sector Z 120 Message Sequence Charts ITU 1993 Jablonski95 Stefan Jablonski Workflow Management Systeme TAT 9 Thomson Publishing Bonn 1995 JBR99 Ivar Jacobson Grady Booch James Rumbaugh The Unified Software Development Process Addison Wesley acm Press Reading Mass 1999 JCJ 92 Ivar Jacobson Magnus Christerson Patrik Jonsson Gunnar Overgaard Object Oriented Software Engineering Addison Wesley acm Press Reading Mass 1992 Jacobson95 Ivar Jacobson The Use Case Construct in Object Oriented Software Enginne ring in Carroll95 S 309 336 JGJ97 Ivar Jacobson Martin Griss Patrik Jonsson Softwae Reuse Addison Wesley acm Press Reading Mass 1997 Johnson97 Ralph E Johnson Frameworks Components Patterns Communications of the ACM Jahrg 40 Nr 10 Okt 1997 S 39 42 JorEri94 Paul C Jorgensen Carl Erickson Object Oriented Integration Testing Communi cations of the ACM Jahrg 37 Nr 12 Sep 1994 S 30 38 J ttner93 Peter J ttner Testen Objektorientierter Software Dissertation Universitat Inns bruck Dez 1993 Kahlbrandt98 B Kahlbrandt Software Engineering Objektorientierte Softwareentwick lung mit der UML Springer Verlag Berlin 1998 KHG98 David C Kung Pei Hsia Jerry Gao Testing Object Oriented Software IEEE Com puter Soc Press Los Alamitos
98. wir dann im n chsten Teil zum Test der Anwen dung gegen die Anforderungsspezifikation Kapitel 13 Verfolgbarkeit Traceability is a tremendously important property in system development JCJ 92 In der Anforderungsermittlung haben wir Use Cases zu Use Case Schrittgraphen verfeinert und Use Case Schritte mit Dom nenklassen und Wurzel Operationen verkn pft Zus tzlich haben wir bei der Validierung der Anforderungsspezifikation Test Szenarien durchgespielt und bei ihrer Verifikation mit Episoden die Ausf hrung der Wurzel Operationen im Kon text des Test Szenarios simuliert Neben der rein funktionalen Wiederverwendung der Test Szenarien als black box Testf lle werden wir die in den Episoden enthaltene systeminterne Information als Testorakel sogenannter SCORES grey box Testf lle f r den entwurfsbasierten Systemtest vgl Hetzel88 verwenden Diese berpr fen ob bei der Ausf hrung eines Test Szenarioschritts f r alle in der Episode durchgespielten Operationen bzw alle von ihr be r hrten Elemente des Dom nen Klassenmodells auch die entsprechenden Elemente der Im plementation ausgef hrt bzw ber hrt werden Notwendige Voraussetzung f r die Ableitung von Testf llen f r den grey box Test ist dass wir f r alle Elemente der Anforde rungsspezifikation entsprechende Elemente in der Implementation identifizieren k nnen Wir m ssen die bei der Anforderungsermittlung erfasste systeminterne Information also
99. wir die Ver erbungskanten des Klassen Botschaftsdiagramms es ist m inheritance n Ey wenn Operation m die Operation n redefiniert und zus tzlich gilt v b m inheritance a m Ey Vk e K b lt k lt a gt me k operations Es gelten Eg U Ey E und Eg A Ey d h Eg und Ey partitionieren E Ey ist ir reflexiv asymmetrisch und injektiv d h eine Operation redefiniert im Rahmen einer Vererbungshierarchie h chstens eine andere Operation Q Die Relation PC Eg X Eg ber cksichtigt die aufgrund der Vererbung und Redefinition von Methoden m glichen dynamisch gebundenen Methoden 7 Aufrufe Stehen Bot schaftskanten zueinander in der Relation P so wird bei jeder Ausf hrung des Aufrufs genau eine der Zieloperationen benutzt P ist reflexiv und transitiv LI Zur Generierung des Klassen Botschaftsdiagramms aus Episoden erinnern wir daran dass die Benutzungsbeziehungen zwischen Operationen in der Nachfolgerschritt Relation der Episoden protokolliert sind Diese Tatsache liegt den im Folgenden angegebenen Generie rungsregeln f r das KBD zugrunde Bei den einzelnen Punkten sind in Klammern die ent sprechenden Zeilen des Algorithmus Generiere KBDA Abb A 1 angegeben l Einer in Klasse k im Klassenmodell definierten Operation o entspricht ein Knoten mit dem qualifizierten Namen k 0 des KBD Zeilen 2 4 238 Klassen Botschaftsdiagramme Algorithmus Generiere KBDA Eingabe Dom nen Klassen K Episod
100. zur Pr zisierung von Use Cases bzw der funktionalen Aspekte der Anforderungen 1 Anders wie bei Jacobson und der UML JCJ 92 OMG97 umfasst das Konzept Sze nario bei Weidenhaupt et al ebenso wie bei Carroll das des Use Cases WPJ 98 Carroll95 50 Probleme der Anforderungsermittlung mit Use Cases 4 3 Relevante Arbeiten Pr zisierung von Use Cases Aus der F lle der Arbeiten greifen wir nun solche auf die Ans tze zur L sung eines der im letzten Abschnitt dargestellten Probleme bei der Anwendung des Use Case Konzepts geben Potts et al stellen eine Methode zur Anforderungsermittlung vor die insbesondere den zu be stimmten Anforderungen f hrenden Prozess unterst tzen und dokumentieren soll PTA94 Das zugrundeliegende Inquiry Cycle Model basiert auf einem Hypertext Framework welches den laufenden Prozess der Anforderungsermittlung im Zyklus aus Anforderungsdokumentation diskussion und evolution abbildet Szenarien als Grundlage f r Diskussionen zur Ermittlung Konkretisierung und Validierung der An forderungen werden auf zwei Komplexit ts bzw Abstraktionsebenen repr sentiert Vollst ndige Szenarien complete scenarios unterst tzen die sequentielle bzw be dingte Ausf hrung von Teilszenarien feiner aufgel ste Teilaktivit ten k nnen als so genannte Episoden in verschiedenen Szenarien wiederverwendet werden Zus tzlich k nnen Szenarien entweder mit Typen Rollen Klassen oder Instanzen konkreten P
101. 12 Verifikationsmetriken 12 1 Minimale Mehrtach Bedmgungst berdeckung Inhalt iii 12 2 Vollst ndige und polymorphe Operations berdeckung 140 13 Verfolgbarkeit 147 E e D ee a a a Duos Aa en DA ren 148 13 2 Elemente der SCORES Anforderungsspezifikation 151 IV Test gegen die Anforderungsspezifikation 157 14 Probleme und Ziele 158 E EEN 158 14 27 Ze EI EN Al 159 15 Black box Test 161 Eder e EE EE E 161 19 2 Lestfallernitllune au Poy lee 162 15 3 Methodisches Vorgehen esse irn einer 165 16 SCORES grey box Test 169 16 1 Klassen Botschaftsdiagramm der Anforderungsspezifikation 169 16 2 Klassen Botschaftsdiagramm der Implementation 170 16 3 Verfolgbarkeit und Klassen Botschaftsdiagramme 175 16 4 Testfallerweiterne sn at Reg deer eet 176 16 5 Methodisehes Vorgehen uns a 29 Ho 177 17 Umgebungsaufbau und Testdatengenerierung 182 17 1 Generierung von Objektkonstellationen 0 0 0 0 00 00 182 14 2 Komplett EEN 184 17 3 Interaktionsdaten sul eege che td oe eae dew ae es 186 18 Endekriterien Ausfiihrung und Auswertung 187 18 1 Testund Testendekriteriens ur 2 42 oes ieee tees oes 187 182 Testaust uhrune reason lee 189 18 3 TEst uswertung 4 54 asien ern 190 V Werkzeugunterst tzung 193 19 Konzepte 194 19 1 Entwicklung u ae ne an Kan 194 19 2 FArchiiektur a Den ee a hl he oat I e aa 195 20 SCORESTOOL 198 20 1 Anf
102. 2 2 7 Bankkunde ATM Karte Einf hren Karte Lesen Kartenleser P Kartenleser leseDaten Transaktion Karte PIN PIN Anfordern La p gt Bedienpult lesePIN Kos O Transaktion Transaktion Karte Zentralrechner PIN Pr fen Schnittstelle Zentralrechner Transaktion 7 prifePIN pr fePIN Zentralrechner R Schnittstelle pr fePIN ne priifePIN Karte Auswahl Anzeigen Auswahl Bedienpult modiy e leseAuswahl W s Abb 12 2 Episode zum Schritt PIN Pr fen im Test Szenario Online Anmeldung H tten wir angenommen dass der Bankautomat keine Verbindung zum Zentralrechner auf bauen kann w rde die Episode in Abb 12 3 zutreffen in der die Transaktion sich selbst mit 146 Verifikationsmetriken der Operation offline in eben diesen Zustand versetzt und danach die eingegebene PIN durch eine entsprechende Operation der Klasse Karte pr fen l sst x Bankkunde ATM Karte Einf hren Karte Lesen Kartenleser BD oKartenleser Kartenleseer leseDaten leseKarte Karte Transaktion new m Karte ees PIN PIN Anfordern f 4 La gt Bedienpult lesePIN Transaktion PIN Pr fen F g Zentralrechner Transaktion Karte Schnittstelle Transaktion 2 T
103. 2 Vertikale Verfolgbarkeit nach Davis90 150 Verfolgbarkeit rein als Gegenstand des Konfigurations Managements bzw der Versionsverwaltung vgl Tichy94 Auch die Vor Verfolgbarkeit wird in diesem Zusammenhang nicht betrachtet Wir sprechen somit im Weiteren wenn keine Verwechslungsgefahr besteht anstelle von ver tikaler Nach Verfolgbarkeit nur noch von Verfolgbarkeit Wir vereinbaren nun einige Relationen mit denen wir sp ter zu den Elementen der Anforde rungsspezifikation die entsprechenden Entwurfs bzw Implementationselemente ermitteln k nnen In Anlehnung an die UML verwenden wir Abh ngigkeitsbeziehungen zur Modellie rung der Verfolgbarkeitsrelationen In dieser Arbeit gen gen uns die zwei Relationen Verfol gung trace OMG97 und Verfeinerung refinement OMG97 als Unterarten der allgemeinen Relation Abh ngigkeit dependency OMG97 Im UML Semantics Guide le sen wir A dependency indicates a semantic relationship among model elements themselves rather than instances of them in which a change to one element may affect or require changes to other ele ments A trace is a conceptual connection between two elements or sets of elements that represent a sin gle concept at different semantic levels or from different points of view However there is no spe cific mapping between the elements The construct is mainly a tool for tracing of requirements It is also useful for the modeler to keep track of changes to dif
104. 4 GJS96 J Gosling B Joy G Steele The Java Language Specification Addison Wesley Reading Mass 1996 223 Glass98 Robert L Glass How Not to Prepare for a Consulting Assignment and Other Ugly Consultancy Truths Communications of the ACM Jahrg 41 Nr 12 Dez 1998 S 11 13 Glinz95 Martin Glinz An Integrated Formal Model of Scenarios Based on Statecharts Proc ESEC 95 Sitges Spain LNCS 989 Springer 1995 GolRob89 Adele Goldberg David Robson Smalltalk 80 The Language Addison Wes ley Reading Mass 1989 GotFin94 O C Z Gotel A C W Finkelstein An Analysis of the Requirements Traceability Problem Proc 1 Int Symp on Requirements Engineering Colorado Springs IEEE Press 1994 S 94 101 Griffel98 Frank Griffel Componentware Konzepte und Techniken eines Softwarepara digmas dpunkt Verlag Heidelberg 1998 Grimm95 Klaus Grimm Systematisches Testen von Software Eine neue Methode und eine effektive Teststrategie GMD Bericht Nr 251 R Oldenbourg Verlag Miin chen zugl Dissertation Fachbereich Informatik TU Berlin 1995 GutHor78 J V Guttag J J Horning The Algebraic Specification of Abstract Data Types Acta Informatica Jahrg 10 1978 S 27 52 HamCha94 Michael Hammer James Champy Business Reengineering Die Radikalkur f r das Unternehmen Campus Verlag Frankfurt 1994 HMGF92 Mary Jean Harrold John D McGregor Kevin J Fitzpatrick Incremental Testing of Object Oriente
105. 97 JGJ97 RAB96 Die Beziehungen zwischen Use Cases uses extends Generalisierung m ssen auf der Verfeinerung fortsetzbar sein Das resultierende Modell muss systeminterne interaktions und kontextuelle Infor mation ausdr cken k nnen PohHau97 vgl Abb 4 5 Das Klassenmodell beschreibt die Dom nenobjekte welche Verantwortlichkeiten zur Bearbeitung der Use Cases haben in Hinblick auf ihre anwendungsinterne Darstel lung vgl Meyer97 WBW 90 Daher kommt der systeminternen Information be sondere Bedeutung zu Die St rken des urspr nglichen Ansatzes wenige Metaobjekte leichtverst ndliche grafische Darstellung Konzentration auf das Wesentliche m ssen f r die Anwen dung des resultierenden Konzepts erhalten bleiben da sie die Haupts ule des heraus ragenden Erfolgs des Use Case Konzepts bilden Es folgen einige Ziele hinsichtlich der Verfolgbarkeit vgl GotFin94 Q Gefordert ist ein klarer nachvollziehbarer bergang zwischen funktionalen und strukturellen Aspekten der Anforderungsspezifikation also zwischen Use Cases und dem Klassenmodell s auch Abb 5 1 Q 59 Dar ber hinaus m ssen die Elemente der Anforderungsspezifikation ber den Ent wurf in die Implementation verfolgbar sein vgl GotFin94 Zum Schluss unserer Aufz hlung beziehen wir uns auf Aspekte der Qualit tssicherung Q Damit die weitestgehende Validierung der Anforderungen durch die Benutzer vgl Boehm84 G
106. Anforderungsspezifikation 33 de beispielsweise ein 26 Klassen enthaltender Cluster gemessen Mohl97 Winter98 Eine dies ber cksichtigende Integrationsstrategie kann zu einem um ber 80 verminderten Aufwand f r die Erstellung von Stubs und Treibern f hren erscheint jedoch ohne Werkzeug unterst tzung kaum sinnvoll vgl Overbeck94 In Frameworks bzw Klassenbibliotheken liegt oft eine Mischung abstrakter und instanzier barer Klassen vor vgl Johnson97 Die Nutzung erfordert somit eine Mischung von Unter klassenbildung Vererbungsnutzung und Delegation bzw Methodenaufrufen Anwendungsnutzung was den Test weiter erschwert vgl Berard93 J ttner93 Overbeck94 Wiederverwendbare Klassen werden so allgemein wie m glich gehalten um eine m glichst breite Benutzbarkeit zu gew hrleisten Daher m ssen beim Test wiederverwendbarer Klas sen strengere Ma st be angelegt werden wobei im Prinzip alle m glichen Wiederverwen dungen der Klasse in Benutzungs und in Vererbungsbeziehungen ber cksichtigt werden m ssen Da dies in der Regel nicht m glich ist ist bei jeder Wiederverwendung zu pr fen ob der Anwendungskontext weitere Tests der wiederverwendeten Klasse notwendig macht Bei der Wiederverwendung wird jedoch oft nur ein kleiner Teil der Funktionalit t der Klasse be nutzt so dass eine vollst ndige berdeckung der wiederverwendeten Klasse im Rahmen der Anwendung nur schwer erreicht wird Fassen wir zus
107. Angabe von Metriken bzw Testkriterien zur Formulierung operationaler Testendekriterien wodurch man erstmalig quantitative Ma e f r die Steuerung und Kontrolle des Validierungs und Verifikationsprozesses erh lt Aus der SCORES Anforderungsspezifikation und den bei ihrer Validierung und Verifikation protokollierten Test Szenarien lassen sich Testf lle f r den black box Test der Anwendung gegen die Anforderungsspezifikation generieren Zus tzlich k nnen im sogenannten SCORES grey box Test ohne gr eren Mehraufwand vertraglich geforderte Werte f r strukturelle Testkriterien erreicht werden Wir nutzen dazu die Vorteile der Pr fung des Zusammenspiels mehrerer Methoden mit Aufrufsequenzen unter Minimierung des Aufwands bei der Spezifi kation der erwarteten Abl ufe Hierzu verwenden wir das Klassen Botschaftsdiagramm KBD f r die SCORES Anforderungsspezifikation welches die bei der Verifikation betrach tete systeminterne Information der Episoden geeignet zusammenfasst Zus tzlich generieren wir auch f r die zwischen Implementationsklassen m glichen Interaktionen ein Klassen Bot schaftsdiagramm Dann bilden wir die anforderungsspezifische systeminterne Information auf die zwischen Implementationsklassen m glichen Interaktionen ab welche daraufhin mit entsprechenden SCORES grey box Testf llen gezielt ausgef hrt werden Die Generierung entsprechender Testdaten bzw der Test Umgebungsaufbau f hren zum Problem der Erzeugung von Objek
108. Auszahlung OK im Use Case Geld Abheben s auch Abb 5 8 b Die Interaktionen verlaufen zeitlich gesehen von oben nach unten F r Szena rien in denen viele Aktoren involviert sind ist neben dieser Darstellung auch eine an das UML Kollaborationsdiagramm angelehnte Sicht m glich bei der z B eine Nummerierung die zeitliche Reihenfolge der Interaktionen verdeutlicht Abb 10 6 zeigt ein mit Skizzen der Benutzungsoberfl che animiertes Test Szenario zum Use Case Anmelden m F F a b c d Abb 10 4 berdeckung des Use Case Schrittgraphen Anmelden 1 Praktisch ist die vollst ndige Szenario berdeckung erreichbar da bei dreimalig inner halb von 24 Stunden aufeinanderfolgender Fehleingabe der PIN die Karte gesperrt wird Der Grenzfall viermalige Fehleingabe der PIN in mehr als 24 Stunden muss nat rlich trotzdem getestet werden Grenze Inneres und Pfad berdeckung 123 L Anmelden Auswahl Betrag pr fen Betrag eingeben Karte schreiben amp Karte auswerfen Karte entnehmen Kartenleser leer Vi i AT Geld ausgeben Geld entnehmen Abb 10 5 Benutzerfreundliche Sicht f r das ATM Test Szenario Auszahlung OK Zum Ende dieses Kapitels beleuchten wir noch die M glichkeiten und Grenzen bzw das Ziel der Validierung in Abh ngigkeit vom angestrebten bzw zu
109. B tats chlich um die Klasse C bzw eines ihrer Objekte erweitert Da Klasse D keine Operation redefi niert die in einer im Kontext der Klasse A simulierten Episode benutzt wird ist hier keine zu s tzliche Episode notwendig a c A Be S c S j j BR p a B D c gt b d a b Abb 12 1 Klassendiagramm und Episode mit redefinierter Operation m F r den Fall redefinierter Operationen wollen wir also ermitteln f r welche redefinierten Operationen die in einer Episode der Oberklasse benutzt werden in der redefinierenden Un terklasse noch keine Episode simuliert wurde Wir bezeichnen die entsprechende Metrik als polymorphe Operations berdeckung Ge gt 12 10 Zun chst ermitteln wir f r eine Klasse k die Menge der in ihr neu oder re definierten Operationen 12 5 k operations p k properties p Operation alllnstances 12 5 Operation 12 6 bestimmt rekursiv die von k unver ndert geerbten Operationen k inheritedOperations Kg Class allinstances k lt sk Sk InheritedOperations U sk operations 12 6 Damit k nnen wir die in der Klasse k redefinierten Operationen bestimmen zu k redefinedOperations op e k inheritedOperations 12 7 drop k operations op name rop name A op signature rop signature 142 Verifikationsmetriken F r eine im Klassenmodell
110. Benutzer erstellen gemeinsam die textuelle Beschreibung der Aufgaben der Use Cases vgl RolAch98 Zus tzlich werden die Aufgaben funktional in Teilaufgaben zerlegt die wiederum Aktoren zugeordnet werden Dieser Prozess wird fortgesetzt bis die resultie renden Teilaufgaben von normalerweise einem Aktor in einer zeitlich und r umlich zusam menh ngenden Aktion unter Beachtung nur weniger einfacher Gesch ftsregeln bearbeitbar sind Analytiker und Anwender spielen hierzu z B einfache Gesch ftsvorf lle durch und gleichen die funktionale Zerlegung entsprechend an Jede dieser Teilaufgaben bildet einen Use Case Schritt W hrend dieser T tigkeiten sammeln Analytiker Begriffe und Definitionen und fassen sie in einem normsprachlichen organisationsweit g ltigen Datenlexikon zusammen welches im weiteren Verlauf der Anforderungsermittlung fortgeschrieben wird vgl Z llighoven98 Parallel dazu werden anhand der Datenaspekte erste sozusagen ER diagrammartige Skiz zen des Klassenmodells angefertigt 8 2 Externes Verhalten W hrend der funktionalen Zerlegung der Use Cases werden die kontextuelle Information und die Interaktionsinformation in der SCORES Anforderungsspezifikation erfasst Analytiker und Benutzer simulieren unter Ber cksichtigung der Ablaufaspekte des Gesch ftsprozess Modells z B in Rollenspielen wieder gemeinsam grundlegende Gesch ftsvorf lle Die Pro duktskizze und die operationalen Aspekte des Gesch ftsp
111. Benutzer zu demonstrieren dass die entwickelte Anwen dung die Anforderungen erf llt Allerdings sieht die Praxis anders aus Weidenhaupt et al schreiben hierzu We found that current practice rarely satisfies this demand Often the scenarios developed during requirements engineering and system design were out of date by the time system testing began Most projects therefore lacked a systematic approach for defining test cases based on scenarios WPJ 98 Tests gegen die Anforderungsspezifikation nur durch manuelles Nachspielen der Szenarien bzw der in Interaktionsdiagrammen modellierten Abl ufe sind einerseits schwer zu automa tisieren Der Tester steht vor Fragen wie was sind die zul ssigen Eingabewerte wie sieht der Anwendungszustand vor dem Szenario aus inkl der persistenten Objekte Anderer seits erlaubt die fehlende Struktur textuell spezifizierter Use Cases nicht objektive Testende kriterien zu formulieren Die Frage wann ein Use Case ausreichend getestet ist bleibt unbeantwortet Bez glich der Generierung von Testf llen aus Use Cases lassen wir zum Ende unserer Auf z hlung noch einmal Poston zu Wort kommen However use cases fall short of their intended purpose because they do not provide enough infor mation for test case or script generation Testers must go outside use cases to find enough infor mation to create test cases Poston98 Im n chsten Abschnitt betrachten wir relevante Arbeiten
112. Case Schrittgraphen durch ausgef llte Dreiecke links oben und rechts unten im Sym bol Tab 5 2 Startschritt Endschritt ka I 4 Tab 5 2 Start und Endschritt Markierung Beispiel 5 4 Wir greifen das Beispiel des Bankautomaten wieder auf Abb 5 8 a und b zeigen Use Case Schrittgraphen zu den Use Cases Anmelden und Geld Abheben 72 Grundlegende Konzepte Es Karte Anmelden Einf hren O Karte 1 Auswahl Lesen SC 2 Anfordern v gt Antordern O PN 2 Anfordern Bankkunde y A Bankkunde Betrag ES Pr fen Betrag L SR y Zentralrechner PIN gt Pr fen Karte q Zentralrechner Schreiben Let Auswahl _ Karte Karte N Le Karte Zs Anzeigen A un O Entnehmen d ZAAnbieten Karte y gt LI Einziehen Karte ag Karte El fo Einziehen 3 Geld D Z Anbieten TI Karte SE Z Entnehmen L__ F Geld Entnehmen a b Abb 5 8 Use Case Schrittgraphen Anmelden a und Geld Abheben b Szenarien visualisieren wir mit Sequenzdiagrammen Makroschritte wie der Schritt Anmel dung im Szenario in Abb 5 9 b werden hierbei komprimiert dargestellt und sollen ein Szenario des ref
113. Cover it Beizer95 Validierung und Verifikation sowie das Testen von Programmen weisen eine Reihe hnlicher Probleme auf Unter diesen Problemen ist eines der schwierigsten die Frage nach dem Ende der Pr fung Einerseits soll die Pr fung eine solide Basis f r die weitere Entwicklung oder den Einsatz des Produkts sicherstellen andererseits K nnen Pr fungen zumindest im Sin ne von stichprobenartigen Tests niemals die Korrektheit garantieren sondern nur das Vertrauen in das Produkt erh hen vgl Dijkstra76 Somit ist eine m glichst objektive Kosten Nutzen Abw gung w nschenswert Dementsprechend wurden z B f r das Testen von Programmen viele Testkriterien angegeben welche zusammengefasst zu Testendekri terien den Tester bei der Ermittlung des richtigen Zeitpunkts zum Abbruch der Pr fungen unterst tzen vgl Myers79 Beizer90 Riedemann97 Auch die Validierungs und Verifi kationst tigkeiten bei der Anforderungsermittlung werden bei der Anwendbarkeit solcher quantitativen Ma e besser planbar und kontrollierbar Granularit t und Semantik der SCORES Anforderungsspezifikation erlauben es bekannte Testkriterien f r die Pr fung von Programmen auf die Qualit tssicherung bei der Anforde rungsermittlung zu bertragen Da die Validierung sowie Teile der Verifikation auf dem Konzept des Use Case Schrittgraphen aufbauen k nnen wir z B auf bekannte berde ckungskriterien des kontrollflussbasierten
114. Entwicklung nach der Entdeckung des Fehlers immer mehr auf dem fehlerhaften Teil der Anforderungsspezifi 18 Entwicklungst tigkeiten Ras BEAT K Ka SE E Anforderungsermittlung 1 2 Entwurf 5 Implementation 10 System und Abnahmetest 20 50 Einsatz und Wartung 200 Tab 2 1 Relative Kostenfaktoren zur Korrektur eines RE Fehlers nach Faulk97 kation basierende Entscheidungen bzw Entwicklungsprodukte betroffen sind und korrigiert werden m ssen Pohl identifiziert innerhalb der Anforderungsermittlung das Extrahieren Konkretisieren Spezifizieren sowie Validieren und Verifizieren von Anforderungen als die wichtigsten T tigkeiten Pohl96 Abb 2 3 zeigt die gegenseitige Beeinflussung dieser vier T tigkeiten zusammen mit potentiell involvierten Personengruppen Stakeholder Die Anforderungsermittlung startet mit der Extraktion Elicitation der Anforderungen den W nschen und Einschr nkungen an das zu erstellende Softwareprodukt Ziel dieser fortlau Analytiker Validieren und Verifizieren Is jeizadswalsisS Projektleiter Q N ONE Spezifizieren H D k CH Ee Q Abb 2 3 Die vier T tigkeiten der Anforderungsermittlung aus Poh96 Gesch ftsprozesse und Anforderungsermittlung 19 fenden T tigkeit ist es die zum Teil verborgenen Anforderungen an das zu entwickelnde Softwareprodukt explizit zu machen und zwar in einer Form die allen involvierte
115. Erweiterung der MSC Notation aus ITU93 Episoden 129 11 3 Episoden Bei dem Durchspielen eines Test Szenarios liegt das Hauptaugenmerk auf der systeminter nen Information also den aufgrund der Ausf hrung eines Schritts ausgel sten Operationen im Klassenmodell Innerhalb von Test Szenarien spielen Analytiker und Tester f r jeden Szenarioschritt der einem Interaktionsschritt im Use Case zugeordnet ist die Ausf hrung der Wurzeloperation des Interaktionsschritts durch Da die zuerst aufgerufene Operation offen sichtlicherweise die Wurzeloperation des Interaktionsschritts ist dient sie quasi als Ein stiegspunkt in das Klassenmodell In den meisten F llen senden Objekte w hrend der Ausf hrung von Operationen Botschaften an weitere Objekte oder sich selbst welche dann wiederum die Ausf hrung anderer Opera tionen bewirken Dies entspricht einem Aufruf Baum von Operationen im Klassenmodell den wir als Episode bezeichnen Episoden protokollieren somit systeminterne Information die sp ter einerseits mit entsprechenden Verifikationsmetriken ausgewertet wird und ande rerseits im Test der Anwendung gegen die Anforderungsspezifikation die Grundlage der SCORES grey box Testf lle darstellt s Kapitel 16 Episoden spiegeln die Ausf hrung der dem Interaktionsschritt zugeordneten Wurzeloperati on in der angenommenen Objektkonstellation wider Im Einzelfall entscheiden Analytiker und Tester ob sie die Episode bis hin zu element
116. Experimentelle Prototypen k nnen in manchen F llen in die Anwendung integriert werden teilen jedoch meistens das Schicksal explorativer Prototypen d h sie werden weggewor DI fen Q Evolution re Prototypen werden mit der Intention erstellt nicht weggeworfen zu wer den sondern in einem kontinuierlichen zyklischen Prozess in die Anwendung zu kon vergieren Evolution re Ans tze m ssen in einen dementsprechend ausgerichteten Entwicklungspro zess integriert werden vgl Davis90 Beschr nken wir uns auf die Validierung der Anfor derungsspezifikation so erscheinen von den prototyp basierten Ans tzen aus Kostengr nden nur explorative generierte Wegwerf Prototypen sinnvoll vgl Boehm84 Davis90 Zur Generierung solcher Prototypen ist der Einsatz formaler Spezifikationen wie beispielsweise Reviewtechniken 107 State Charts oder anderweitig spezifizierter Zustandsautomaten vgl Glinz95 HarNaa96 HsiKun97 Petri Netzen vgl Barbey97 DBB97 algebraischen bzw modellbasierten Spezifikationssprachen wie Object Z CarSto94 oder spezieller Techniken zur Spezifi kation von Benutzungsschnittstellen s KSV 96 Voss97 notwendig Da diese Arbeit die Anforderungsspezifikation mit verfeinerten Use Cases und Klassenmo dellen zum Inhalt hat und wir keine Anforderungen an den Grad der Formalisierung stellen wollen betrachten wir als Validierungsmethode im Wesentlichen verschiedene Formen von Reviews Werden
117. G97 Semantics Guide Generalisiert ein Aktor a einen Aktor a so schreiben wir abk rzend az a Wir kommen nun zu den funktionalen Aspekten Einfach gesprochen spezifiziert jeder Use Case eine in sich abgeschlossene Teil Funktionalit t die bei der Benutzung der Anwen dung f r die beteiligten Aktoren einen messbaren Fortschritt oder ein bestimmtes Teil Ergebnis innerhalb des Gesch ftsprozesses erbringt Jacobson beschreibt einen Use Case als a specific way of using the system by using some part of the functionality Each use case constitutes a complete course of events initiated by an actor and it specifies the interaction that takes place between the actor and the system JCJ 92 Operationale und verhaltensbezogene Aspekte der Use Cases werden textuell spezifiziert wobei Jacobson einen mehr oder weniger prosaischen Stil vorschl gt Jeder Use Case be schreibt f r eine klar umrissene Aufgabe den normalen Ablauf sowie alternative und z B aufgrund von Ausnahmesituationen notwendige Varianten The use case construct is used to define the behaviour of a system or other semantic entity without revealing the entity s internal structure Each use case specifies a sequence of actions including variants that the entity can perform interacting with actors of the entity OMG97 Semantics Guide Jede konkrete Ausf hrung eines Use Case stellt eine Sequenz von Ereignissen dar die als Szenario bezeichne
118. Initialisieren Stimulieren Validieren Tester Tool A Grafisch interaktive Benutzungsoberflache E Funktionaler Kern der Anwendung _ Persistente Objekte Datenbank I Li E Ge SCH Cer Ges g J Abb 15 4 Black box Test Nach der Initialisierung der persistenten Daten z B mit vorhandenen anonymisierten Pro duktionsdaten wird die Anwendung ber die Benutzungsoberfl che stimuliert Nach jedem Test berpr ft der Tester bzw das Test Werkzeug die resultierenden Ausgaben und damit in direkt den Zustand der Anwendung mit den M glichkeiten der Benutzungsoberfl che Feld vergleiche Zustand der Oberfl chenelemente 1 Die Fehleraufdeckungsrate gibt an wie viele Fehler pro Zeiteinheit entdeckt werden vgl Riedemann97 Methodisches Vorgehen 167 Beispiel 15 2 F r drei Use Cases uc_1 bis uc_3 seien REF uc_1 uc_2 uc_ 3 REF uc_2 und REF uc_3 uc_2 Die topologische Sortierung der Knoten des ent sprechenden Graphen Abb 15 5 ergibt die Test Reihenfolge uc_2 uc_3 uc_1 Abb 15 5 Gerichteter azyklischer Graph zur Inter Use Case Referenzfunktion Q Beispiel 15 3 Abb 15 6 zeigt ein Testskript mit einigen Testf llen zum Test Szenario Online Anmeldung des Use Case Anmelden Abb 10 3 Der erste Testfall AnmeldungOK benutzt die beiden Testf lle KarteEinf hren und PINAnfordern Wir ermitteln die Interaktionsparameter f
119. Irrwegen bewahrt hat Von unsch tzbarem Wert bei der Abfassung der Dissertation waren mir die langj hrige Ver trautheit in die industrielle Problematik der Qualit tssicherung in die mich die Mitglieder des Arbeitskreises Testen objektorientierter Programme TOOP der GI Fachgruppe 2 1 7 Test Analyse und Verifikation von Software TAV eingef hrt haben Mein Dank gilt ins besondere Harry Sneed und Prof Dr Andreas Spillner die das Testen von Software in Deutschland berhaupt erst hoff hig gemacht haben Zus tzlich danke ich den Studierenden der FernUniversit t Cornelia Wulf Gabriele Mohl Thorsten Ritter die im Rahmen Ihrer Diplomarbeiten die Konzepte der Arbeit implementiert und validiert haben Das h ufig mutierende Manuskript wurde von Brigitte Wellmann mit en gelhafter Geduld korrekturgelesen Weiterer Testleser war Dr Markus M ller Last but not least danke ich meiner Frau Petra die es verstanden hat und versteht die Launen eines nur allzuoft an die Arbeit denkenden Ehemanns zu ertragen und unseren lieben Kindern Mischa und Jonas verbunden mit der Entschuldigung daf r dass sie ihren Papa in der letzten Phase der Arbeit oft nur sporadisch zu Gesicht bekamen Sie haben mir die Energie und das Selbstvertrauen gegeben diese Arbeit zu Ende zu f hren Inhaltsverzeichnis I Einleitung 1 1 Motivation und berblick 2 1 1 Begriffe und Gebiete der Oualt tsecheung 22222220 reenen 4 ar TEE E Bes 7
120. Karte theCard Kartenleser leseKarte ORACLE Kartenleser state asString locked theCard isEqual Karte Bankleitzahl Kontonummer G ltigkeitsdatum Kartennummer END TESTCASE PINAnfordern ROOTCLASS Bedienpult PIN Integer LOCAL thePIN Integer BEGIN Der BankKunde gibt die PIN ein thePIN Bedienpult lesePIN ORACLE thePIN isEqual PIN END Abb 16 7 Grey box Testf lle Kapitel 17 Umgebungsaufbau und Testdatengenerierung Preparation of test data is a major component of the total cost of system testing and acceptance testing CGL81 W hrend die Ableitung von Testf llen und Testdaten bez glich primitiver Typen als Interak tionsparameter z B integer real string in der klassischen Testliteratur ausf hrlich be leuchtet ist vgl Beizer90 Beizer95 Myers79 Riedemann97 wurde die Generierung von Objekten und Objektkonstellationen bisher nur in wenigen speziellen Anwendungsge bieten untersucht z B K sters97 Wir gehen daher nach unserer eher skizzenhaften Be trachtung der Interaktions Testf lle Abschnitt 15 2 in diesem Kapitel ausf hrlicher auf dieses Problem ein 17 1 Generierung von Objektkonstellationen Bei der Validierung und Verifikation der Anforderungsspezifikation haben wir bei den Walk Throughs der Test Szenarien und Simulationen der Episoden konkrete Objektkonstellationen zugrundegelegt In den Episoden sind mit den Sichtbarkeitsbereichen und den Aufrufen al le
121. Karte Ist der Code der Karte unlesbar so zieht der Bankautomat die Karte mit einem Alarmton ein Unzul ssige Karte Ist der Typ der Karte falsch so wirft der Bankautomat die Karte aus Falsche PIN Ist die eingegebene PIN falsch so wird dieser Versuch gez hlt nach drei Fehlversuchen wird die Karte gesperrt und ausgeworfen Unzul ssige Transaktion Erkl rt der Zentralrechner die angeforderte Transaktion f r unzul ssig wird eine dementsprechende Meldung ausgegeben und die Karte ausgeworfen Abbruch durch den Bankkunden Der Bankkunde kann die laufende Transaktion jederzeit ab brechen was zum Auswurf der Karte und Abbruch der begonnenen Transaktion f hrt Abb 4 1 Use Case Geld Abheben Textuelle Spezifikation bersetzt aus JCJ 92 heben vor An diesem Ablauf partizipieren die in Abb 4 3 gezeigten acht Objekte Die ersten drei Kartenleser Transaktion und Bedienpult sind die am Use Case Anmelden betei ligten Objekte der vom Use Case Geld Abheben ber die uses Beziehung benutzt wird An letzterem sind die anderen f nf Auszahlung ZentralrechnerSchnittstelle Belegdru cker Geldausgabe und Bargeld beteiligt 44 Probleme der Anforderungsermittlung mit Use Cases Lt Administration Bediener Geld Abheben Uses USES Zentralrechner Bankkunde Uses Geld Transferieren Geld Einzahlen Abb 4 2 Use Case Diagramm Bankautomat
122. Klassen bzw Stellvertreter welche die betroffenen Methoden definieren Q Es existieren Operationen f r die innerhalb des Systems keine entsprechenden Bot schaften erzeugt werden Einerseits kann dieser Fall auftreten wenn die Anwendung nur bestimmte Aspekte von Bibliotheksklassen verwendet Meyer s Shopping List Ansatz Meyer97 Auf der anderen Seite k nnten entsprechende die Operation auf rufende Bibliotheksklassen bei der Generierung des KBD nicht ber cksichtigt sein Einige Operationen der Anwendung werden z B als Callback Operationen von nicht betrachteten Klassen verwendeter GUI Frameworks eingesetzt In diesem Fall k nnen wir diese Operationen entweder vernachl ssigen oder aber die entsprechenden Klassen des Frameworks in unsere Betrachtungen mit einbeziehen Es ist also zu pr fen ob wir weitere Klassen bei der Generierung des KBD ber cksichtigen m ssen oder ob diese Methoden Wurzeloperationen ggf neu zu definierender Use Case bzw Test Szenarioschritte sind m Es existieren Botschaftskanten im KBD f r die beim Ablauf der Anwendung keine entsprechenden Aufrufe erzeugt werden k nnen Dies ist z B der Fall wenn in der Anwendung kein Objekt der betroffenen Klasse erzeugt wird oder die Botschaftsquel le keine entsprechende Referenz annehmen kann Dieser Fall kann nur in ungetypten Sprachen auftreten und z B mit Algorithmen zur Typinferenz weitgehend statisch eli miniert werden vgl PalSch94 Of
123. Komplexit t der einzelnen Bedingungen zu einer gro en Anzahl hnlicher Szenarien bei operationalen Bedingungen in einer for malen Sprache wie z B OCL oder sogar in einer Programmiersprache ist die Testfallerzeu gung allerdings mit bekannten Techniken automatisierbar vgl Poston94 Poston96 12 2 Vollst ndige und polymorphe Operations berdeckung Als eine erste einfache berdeckungsmetrik messen wir mit der vollst ndigen Operations berdeckung S welcher Prozentsatz der Operationen mit Episoden simuliert und damit mindestens einmal bei der Verifikation betrachtet wurde Zuerst ermitteln wir f r eine Episo de e die benutzten Operationen 12 1 dann f r ein Test Szenario ts die Menge der Episoden 12 2 und schlie lich die Menge der von einem Test Szenario ausgef hrten Operationen im Klassenmodell 12 3 e operationsUsed J est rootOperation 12 1 este e steps ts episodes J s executes 12 2 se ts Steps n InteractionStep alllnstances ts operationsUsed J e OperationsUsed 12 3 ee ts episodes Hiermit k nnen wir die vollst ndige Operations berdeckung angeben zu KM O_ LA e TestScenario alllnstances ts operationsUsed 1 Operation alllnstances size 12 4 KM g EE Wir erhalten c i SE 1 wenn jede Operation im Klassenmodell in zumindest einer Episode verwendet wird Diese Metrik k nnen wir in mehrfacher Hinsicht verfeinern Zum einen entlang der Verer bungsh
124. OCL wobei wir auch die von den betroffenen Klassen ange botenen Operationen verwenden Bez glich der OCL verweisen wir auf den OMG Standard UML 1 1 OMG97 Ist eine Klasse I Unterklasse einer Klasse k schreiben wir auch I lt k Ist k und I lt k so nen nen wir eigentliche Unterklasse von k und schreiben I lt k Folgt zus tzlich f r alle k aus I lt ks lt k entweder I kg oder k k so nennen wir direkte Unterklasse von k und schreiben hierf r I k Stehen die beiden Klassen in keiner Vererbungsbeziehung zueinander so schrei ben wir I V k F r zwei Operationen I o und k o mit I o name k o name und I o signture k o signature sagen wir I 0 redefiniert berschreibt k o F r den Fall von im Rahmen einer Vererbung redefinierten Operationen beleuchten z B FNZ96 Meyer97 Poetzsch97 in welcher Beziehung die Signaturen sowie Spezifikationen Vor und Nachbedingungen Klasseninvarianten der berschreibenden Operation zu denen der berschriebenen stehen sollten Wir setzen voraus dass in Anforderungsspezifikationen ausnahmslos die konforme Vererbung verwendet wird und geben wie bei Aktoren je weils nur die am h chsten in der Vererbungshierarchie stehenden Klasse an F r eine Klasse k aus K ermitteln wir mit k allAttributes die Menge aller die Objekte der Klas se k beschreibenden neu definierten berschriebenen oder unver ndert geerbten Attribute und mit k allOperations dementsprechend die Me
125. ORES Anforderungsspezifikation ist Inhalt von Teil IV Nach einem berblick leiten wir als angestrebten Mehrwert der Anfor derungsermittlung mit SCORES in Kapitel 15 zun chst reine black box Testf lle ab Da white box Klassen Tests f r objektorientierte Software nicht effektiv sind und black box Testver fahren die fehlertr chtigen komplexen internen Interaktionen objektorientierter Anwendun gen nicht ad quat pr fen erweitern wir in Kapitel 16 die black box Testf lle zu sogenannten SCORES grey box Testf llen Wir pr fen hierbei die internen Interaktionen der Anwendung gegen die bei der Verifikation protokollierte systeminterne Information der Anforderungs spezifikation die wir daf r geeignet im sogenannten Klassen Botschaftsdiagramm zusam menfassen In Kapitel 17 gehen wir auf die Generierung von Objektkonstellationen als Testdaten ein Wir zeigen das die Generierung solcher Objektkonstellationen ein NP hartes Problem ist und geben Hinweise auf entsprechende Heuristiken Im letzten Kapitel von Teil IV skizzieren wir die Testausf hrung und auswertung Abschlie end skizzieren wir in Teil V die im Rahmen der Arbeit implementierte Werkzeug unterst tzung und schlie en in Teil VI mit einer Bewertung der erzielten Ergebnisse und ei nem Ausblick auf laufende und zuk nftige Arbeiten Kapitel 2 Entwicklungst tigkeiten In diesem Kapitel skizzieren wir typische T tigkeiten in der objektorientierten Softwareent wicklung Wir
126. Pr fungen Hierzu geh ren Fehlerbe richte an die Entwickler und Aufstellungen ber erreichte Werte von Metriken wie z B der Fehlerrate der Fehleraufdeckungsrate der erreichten Test berdeckung und der Test ber deckungsrate Letztendlich fasst der Testabschlussbericht alle Testereignisse und ergebnis Testauswertung 191 se eine Fehlerstatistik eine Beurteilung der Test berdeckung und eine Aussage ber die erreichte Qualit t relativ zur geplanten Qualit t zusammen Hiermit sind wir am Ende unserer konzeptuellen bzw methodischen Ausf hrungen ange langt Die geforderte Br cke von der Anforderungsermittlung ber die Pr fung der Anforde rungsspezifikation bis hin zum Test der Anwendung s Abb 14 1 auf Seite 159 wurde errichtet Grundlegende Pfeiler sind die Verfeinerung und Pr zisierung von Use Cases zu Use Case Schrittgraphen die Kopplung mit dem Klassenmodell die Validierung und Verifikation der Anforderungsspezifikation und die bernahme bzw Erweiterung der Test Szenarien und Episoden zu black box bzw grey box Testf llen Zum besseren berblick stellt Tabelle 18 1 noch einmal die Elemente der SCORES Anforderungsermittlung den entsprechenden bzw re sultierenden Elementen des Tests gegen ber Use Case Diagramm Spezifikation Use Case Schrittgraph Testsuite Management Use Case Schritt Testfall Test Szenario Testskript Validierung Test Szenarioschritt Testfall Black box Bedingungen Testdaten Testor
127. Qualit tssicherung f r objektorientierte Software Anforderungsermittlung und Test gegen die Anforderungsspezifikation Fachbereich Informatik der FernUniversit t Gesamthochschule in Hagen Zur Erlangung des Grades eines Doktors der Naturwissenschaften Dr rer nat an genommene Dissertation von Dipl Inform Mario Winter Erster Berichterstatter Prof Dr H W Six Zweiter Berichterstatter Prof Dr A Poetsch Heffter Datum der m ndlichen Pr fung 10 September 1999 dissertation de Verlag im Intemet Sonderausgabe des Werkes mit der ISBN Nummer 3 89825 031 8 dissertation de Verlag im Intemet Leonhardtstr 8 9 D 14 057 Berlin Email dissertation de snafu de Internetadresse http www dissertation de Wann beginnt das Testen Geleitwort von Prof Dr Andreas Spillner Die ersten Programme in der Fr hzeit der Computertechnik ab 1940 wurden sicherlich ge testet oder besser formuliert vor deren Einsatz ausprobiert Auftraggeber Anwender Programmierer und Tester waren in einer Person vereint Der Anwendungsbereich der Pro gramme war auf rein mathematische Berechnungen beschr nkt Mit zunehmender Leistung der Rechner wurden die dadurch erbrachten M glichkeiten auch f r Kunden interessant Es gab einen Auftraggeber Aufgabe der Rechner war immer noch das Rechnen allerdings oft mit einem starken Anwendungsbezug zum Beispiel der m g lichst exakten Vorausberechnung der Flugbahnen von Geschosse
128. Schritte PIN Anfordern und PIN Pr fen In Szenario D w hlen wir als Interaktionsparameter des Schritts PIN Anfordern den Abbruch des Vorgangs so dass der zweite Konjunktionsterm der Nachbedingung des Schritts PIN Anfordern Karte im Kartenleser UND Kartenleser gesperrt UND Karte lesbar UND Karte g ltig UND Abbruch erf llt ist und das Szenario mit dem Schritt Karte schreiben fortgesetzt wird im Beispiel nicht mehr dargestellt In Szenario E geben wir eine syntaktisch richtige aber bez glich der Karte falsche PIN ein und erf llen so den zweiten Konjunktionsterm der Nachbedingung des Schritts PIN Pr fen Da wir weitere negative Testf lle physikalisch nicht ausf hren k nnen betrachten wir die vier Schritte bez glich der minimalen Mehrfach Bedingungs berdeckung ausreichend getestet LI Beispiel 12 3 Wir betrachten einen Walk Through durch den Schrittgraphen des Use Cases Anmelden in der Bankautomaten Fallstudie vgl Abb 5 8 b Das in Abb 5 9 b gezeigte Szenario setzt eine Verbindung zum Zentralrechner voraus der Bankautomat sei also Onli ne Zusammen mit den in Beispiel 7 2 Abb 7 5 dargestellten Klassenbereichen und den Vor und Nachbedingungen der Use Case Schritte erhalten wir das in Abb 10 3 dargestellte Test Szenario Online Anmeldung bei dem die eingegebene PIN durch den Zentralrechner ge pr ft werden kann M gliche Fragestellungen bei dem Walk Through sind m Existiert eine Instanz der Klasse Kartenl
129. Softwareentwicklung auch auf ob jektorientierte Software anwendbar sind Binder96a konfrontiert uns letztere auch hier mit speziellen Problemen welche neue L sungen erfordern s auch Anhang A 2 F r dynami sche Pr fungen stehen wir prinzipiell vor zwei Extremen bei der Vorgehensweise Q Wir pr fen alle Methoden separat danach die Interaktionen von Methoden innerhalb einer Klasse und letztlich die Interaktionen zwischen Methoden verschiedener Klas sen Q Wir f hren direkt Integrations bzw partielle Systemtests durch und testen somit von Beginn an die Interaktionen zwischen Methoden verschiedener Klassen Betrachten wir zun chst die Pr fung der einzelnen Methoden Solche Pr fungen sind f r ob jektorientierte Software schwierig da die Methoden einer Klasse ber die Instanzvariablen 1 Ein Cluster ist eine Gruppe logisch zusammengeh render Klassen Meyer97 Generierung Struktureller white box Test 31 Vererbung Aggregation und Assoziation Eingangsnachricht Vorbedingung_ Parameterobjekt p el t Te S Initialisierung gt R ckgabeobjekt de N Lig Validierung Abb 3 1 Problematik des Klassentests nach Sneed96 gekoppelt sind und dar ber hinaus meistens weitere Methoden der eigenen oder anderer Klassen benutzen Pr fverfahren aus der prozeduralen bzw modularen Programmierung sind eingeschr nkt anwendbar jedoch oft we
130. Status wie z B in Arbeit Validiert oder Verifiziert zuteilen Der QS Status beeinflusst optional die Berechnung der entsprechenden Metriken so dass z B Elemente mit dem QS Status in Arbeit nicht im Z hler der Metriken ber cksichtigt werden 20 4 Test In Kapitel 15 haben wir gezeigt wie aus den bei der Validierung und Verifikation der SCORES Anforderungsspezifikation verwendeten und protokollierten Test Szenarien mit mi nimalem Aufwand Testf lle f r den black box Test der Anwendung gegen die Anforderungs spezifikation generiert werden Die Granularit t und Semantik der Use Case Schrittgraphen erm glicht zudem die Anwendung der f r die Validierung der Anforderungsspezifikation verwendeten Testkriterien wie z B Use Case Knoten und Kantenabdeckung auch beim dy namischen Test der Anwendung Wesentlich f r die Generierung der Testskripte ist die auf dem Generator Framework aufset zende Exportschnittstelle des SCORESTOOLs Von au en und vereinfacht betrachtet kann das Analytiker Tester Exportschnittstelle Testskripte Testfalle Importschnittstelle Transformator ral Integrations liest werkzeug erzeugt Objektkon stellationen ANFORDE RUNGS SPEZIFIKATI ON Test Modell lt gt ndert SCORESTOOL externes Dateisystem CAST Tool Abb 20 9 Testfall und Testdaten Generierung 206 SCORESTOOL Bankauto
131. Testf lle f r positive und negative Tests w hrend positive Tests die jeweiligen Vorbedingungen ein halten verletzen negative Tests ganz bewusst eine Vorbedingung und spezifizieren als erwar tetes Ergebnis eine bestimmte Ausnahme situation vgl Berard93 Zur textuellen Spezifikation von Testf llen haben wir eine einfache Skriptsprache entwickelt deren Syntax in Anhang B angegeben ist Hierzu betrachten wir ein einfaches Beispiel 164 Black box Test Beispiel 15 1 Wir beschreiben Testf lle zur Pr fung der Klasse Stack mit den Operationen push zuf gen eines Elements auf den Stapel pop entfernen des obersten Elements vom Stapel und top Zugriff auf das oberste Element des Stapels vgl Meyer97 Abb 15 2 zeigt ein entsprechendes Testskript TESTCASE TFStackl ROOTCLASS Stack A B Object LOCAL C Object PRECONDITION A null AND B null BEGIN CREATE create ORACLE count 0 push A ORACLE count 1 top A push B ORACLE count 2 top B C top ORACLE count 2 top C pop ORACLE count 1 top A pop ORACLE count 0 pop EXCEPTION EmptySet EmptySet END Abb 15 2 Testskript f r die Klasse Stack Test Szenario Testskript Jeder Test beginnt jeweils mit dem Hochfahren der Anwendung Test Setup wobei wir die Zust nde persistenter Objekte aus den konkreten Vorbedingungen des durchzuspielenden Test Szenarios ermitteln und vor dem Start der Anwendung in der Datenban
132. Tool geben wir das in Abb 5 7 gezeigte vorl ufige UML Metamodell f r die Use Case Schrittgraphen entsprechenden Primitive von SCORES an Wir verwenden dabei an englische Begriffe angelehnte Bezeichner wobei die bertragung auf die bei den entspre chenden Konzepten verwendeten deutschen Bezeichner problemlos m glich sein sollte 1 referencedStepGraph refersTo as r StepGraph T 0 1 e n bail 2 S a bi 2 o bail n Ka o in Q n 2 g 1 a t e e UseCaseStep Assertion r successors InteractionStep ContextualStep MacroStep Abb 5 7 Use Case Schrittgraph Metamodell not referencedStepGraph Modellierungsregeln I 69 Betrachten wir die Assoziation referencedStepGraph welche die Klassen MacroStep und StepGraph verbindet und die Makroschritt Referenzfunktion modelliert s Definition 5 3 Der Constraint not referencedStepGraph self StepGraph verbietet direkte rekursive Be z ge von einem Makroschritt auf den diesen Schritt enthaltenden Use Case Schrittgraphen Die abgeleitete selbstrekursive Assoziation refersTo der Klasse StepGraph bertr gt die durch die Makroschritte bedingten Abh ngigkeiten auf die entsprechenden Use Case Schritt graphen und modelliert die Inter Use Case Referenzfunktion s Definition 5 6 Die abgelei tete Assoziation von der Klasse StepGraph zur Klasse Actor wird aus der entsprechenden Assoziation der zuge
133. Ze ae Ba SE Ee 66 Ma an ee nn 120 tee ee 86 A Abbruchkriterium n n nanaaaaa 6 Abrlachen nasser ee 133 Abnahmetest se ar HEN Ee 28 7 161 Ad quatheitskriterium 6 Aktivit tsdiagramm 96 POP ee Sele aunt Abee Band r de oy 20 Generalisierung 20 Alias ee 242 247 Anforderung A 16 extern beobachtbar 16 funktionale an ee 16 nicht funktionale 17 Anforderungsermittlung 16 Anforderungsspezifikation 17 Konsistenz Aere Ee a ote ats 105 Korrektheit fachliche 3 4 2 04 243 105 formale 2222 105 Vollst ndigkeit fachliche 105 formale 2222 105 Aspekt blanne rer 15 funktionaler 14 informationsbezogener 15 operationaler 14 organisatorischer 14 Musial ook oh ele ae EH 4 B Bedingungs berdeckung einfache u ae ra 138 Mehrfach 222 138 Minimale Mehrfach 138 Benutzbarkeitstest 7 Botschaft 137 Botschaftskante 172 Business scenario 2222 111 C FAST EEN 206 CUSTER 4 2 due eee dee E ie 30 32 D RE GE 4 Delegalons zzux bie eee ua a 249 Dom nenobjekt anwendungsinterne Darstellung 58 88 elen Sun Cake 88 Dom nen Operation 129 256 E Entscheidungstabelle 142 Episodi ses nn er 129 130 169 Episodenschritt 130 Evaluation use t
134. ablen 0 0 173 Romponententest e a a L L sttest ts hee ran 7 N Nebenl ufigkeitstest 7 O OCE EE 61 P Prototyping evolution res 106 experimentelles is acon ote SY 106 Exploralivessz er real 106 horizontales 106 vertikales 106 Pr fgegenstand EE 4 Qualit tssicherung 5 objektorientierter Anwendungen 26 R Realzeittest ou 5226 dea cade ken 7 Referenzfunktion Intra Use Case 2 2222 66 Makroschritt 00 63 Regressionstest 0000 7 Reviews EE a e 107 techniken x a at 22 sen AE 107 Ro b stheit u LH sta 34 S Schritt Test Szenario 112 Use Case 62 112 SCORES Metamodell 113 vollst ndiges 135 Metamodell 68 90 Meth dikass nee 98 Sequenzdiagramm 23 Sichtbarkeitsbereich 131 initialer 22 22222222 131 von Episodenschritten 131 Stakeholder nna 18 47 Standard Operation 129 Stresstest 0 eee 7 E onc SAS ae eee Bae ee bee 7 anforderungsbasiert 161 Szenario 222222 20 47 65 118 Tests une 112 129 161 SZENE E Su tae mg are ass 99 T Template Methode 248 257 Test Abnahme i 0 0060040 KEEN 35 black bOX EE 6 C2 Bedingungs berdeckung einfache C3 gt Bedingungs berdeckung Mehrfach gegen die Anforderung
135. aiser Adequate Testing and Object Oriented Pro gramming Journal of Object Oriented Programming Jahrg 3 Nr 2 Jan Feb 1990 S 13 19 PinGog96 Francisco A C Pinheiro Joseph A Goguen An Object Oriented Tool for Tra cing Requirements IEEE Software M rz 1996 S 52 64 Poetzsch91 Arnd Poetzsch Heffter Logic Based Specification of Visibility Rules Proc 3rd Int Symp of Programming Language Implementation and Logic Programming LNCS 528 Springer Miinchen 1991 S 63 74 Poetzsch97 Arnd Poetzsch Heffter Specification and Verification of Object Oriented Pro grams Habilitationsschrift TU Miinchen Jan 1997 PohHau97 Klaus Pohl Peter Haumer Modelling Contextual Information about Scenarios Proc 3rd International Workshop on RE Foundation for SW Quality Barcelona Spain 1997 Pohl96 Klaus Pohl Process Centered Requirements Engineering J Wiley amp Sons Rese arch Studies Press Ltd Somerset England 1996 Pol98 Martin Pol The Future of Testing What Should We Prepare For Keynote Presenta tion at 6 euroSTAR 98 M nchen Dez 1998 Poston87 Robert Poston Preventing the Most Probable Errors in Requirements IEEE Soft ware Jahrg 4 Nr 9 Sep 1987 S 81 83 Poston94 Robert Poston Automated Testing from Object Models Communications of the ACM Sep 1994 S 48 58 Poston96 Robert Poston Automating Specification Based Software Testing IEEE Computer Soc Press Los Alamitos Calif 1996 230 Posto
136. aktion bzw die Wurzelopera tion f hrePlanAus zugeordnet Der Aufruf der Wurzeloperation f hrePlanAus f hrt zu ei nem Aufruf der Standardoperation read im Kontext eines Objekts der Klasse Konto Danach wird die Operation pr fe der Klasse Transaktion aufgerufen in diesem Falle muss sich aus der betrachteten Objektkonstellation ergeben und im Episodenschritt protokolliert werden ob sich dieser Aufruf an das gleiche Objekt richtet oder an eine andere Instanz der Klasse Transaktion bzw einer zu ihr konformen Klasse Letztendlich wird die Standardoperation modify im Kontext des Objekts der Klasse Konto aufgerufen m 11 6 Vollst ndiges Scores Metamodell In diesem Abschnitt erweitern wir die in den Abbildungen 5 7 7 2 und 9 1 dargestellten par tiellen Sichten des SCORES Metamodells zum letzten Mal Wir beziehen Primitive f r Episo den ein und erhalten das vollst ndige SCORES Metamodell in Abb 11 2 Der Constraint zwischen den Klassen Episode und InteractionStep deutet an dass Episoden nur dann mo delliert werden wenn der dem Szenarioschritt zugeordnete Use Case Schritt ein Interaktions schritt ist nur in diesem Fall wird die Aufgabe ja von der Anwendung unterst tzt Die Klasse EpisodeStep ist ebenso wie nun auch die Klasse InteractionStep Unterklasse der abstrakten Klasse SupportedStep so dass sich jeder Episodenschritt auf genau eine Klasse und eine darin enthaltene Operation abst tzen kann Mit der Aggregation calls mo
137. ammen Aufgrund der Verkapselung von Methoden und Attributen in Klassen kleinen Methoden und der damit verbundenen erh hten Komplexit t des Zusammenspiels von Methoden sowie der gr eren Ausdrucksst rke durch Vererbung und Polymorphismus sind systematische Pr fungen in der objektorientierten Softwareentwicklung deutlich kom plexer als z B in der modularen Softwareentwicklung vgl J ttner93 Binder96a White box Tests auf der Granularit t einzelner Klassen oder gar einzelner Methoden erweisen sich in der Praxis zunehmend als wenig aussagekr ftig da die Komplexit t in den Interaktionen zwischen verschiedenen Objekten liegt vgl z B JorEri94 HKR 97 Wegner97 Dar ber hinaus sind solche Tests mit sehr hohem Aufwand verbunden so dass ihr gewinnbringender Einsatz nicht gegeben ist vgl Sneed95 StrH r98 Wir gehen daher im n chsten Abschnitt n her auf den black box Test einer Anwendung gegen die Anforderungsspezifikation ein 3 3 Black box Test gegen die Anforderungsspezifikation In der Literatur ber objektorientiertes Testen wurden bisher haupts chlich strukturelle oder auf formalen Spezifikationen basierende funktionale Verfahren f r den Klassentest sowie der Integrationstest betrachtet vgl Binder96a KHG98 Da in der industriellen Praxis haupt 1 Da Smalltalk 80 eine ungetypte objektorientierte Programmiersprache ist und die Mes sungen ohne eine vorgeschaltete Typinferenz erhoben wurden stellen die angegebe
138. anager f r persistente Datenspeicherung MDS Das Speichern und Laden von Modellen erfolgt ausschlie lich ber den MDS des GEOOOA bzw des SCORESTOOLs Der MDS stellt eine einheitliche Schnittstelle zu verschiedenen Technologien der persis tenten Datenhaltung zur Verf gung Frameworks Mit dem Begriff Framework wird ein halbfertiges Teil System bezeichnet das in einem spezifischen Kontext instanziiert werden kann vgl Johnson97 Griffel98 Beispielsweise definiert das Generator Framework die Ar chitektur f r eine Familie von Dokument und Codegeneratoren sowie Modelltrans formatoren Es enth lt die grundlegenden Basisbausteine z B Scanner Parser Regel Interpreter um anwendungsspezifische Generierungs bzw Transformations regeln zu definieren und Modelle damit auszuwerten Mit dem Editor und Browser Framework stehen zwei weitere Frameworks zur Bearbeitung der Modellierungspri mitive bzw deren textueller Spezifikationen bereit Auf der untersten Ebene befinden sich externe Basiskomponenten auf denen das WERKZEUG aufsetzt Zur Speicherung von Modellen k nnen unterschiedliche Datenbanksysteme einge setzt werden sofern deren Einsatz durch den MDS unterst tzt wird Die Schnittstellen zum Betriebssystem und zum User Interface Management System UIMS vgl VosNen98 wer den bereits von der Entwicklungsumgebung VISUALWORKS plattform unabh ngig zur Ver f gung gestellt so dass keine weiteren Vorkehrungen f r den Einsatz au
139. anten auch Instanziierungs kanten Da in Java wie auch in Eiffel im Gegensatz zu C die explizite Zerst rung von Objekten nicht vorgesehen ist Garbage Collection s z B GJS96 Meyer97 gibt es im KBD bei einer Implementation in Java keine mit der Marke destroy gekennzeichneten Kanten Die explizite Entfernung persistenter Objekte z B aus einer Datenbank spiegelt sich in der Im plementation in Methoden wider die zur ck zu entsprechenden destroy Standardoperationen im Dom nen Klassenmodell der Anforderungsspezifikation verfolgbar sind Zus tzlich ber cksichtigen wir auch noch Klassen bzw Instanz Variablen also die Zu standsspeicher direkte Daten Interaktionen F r jede Variable f gen wir dem KBD einen mit dem qualifizierten Namen der Variablen gekennzeichneten Variablennoten hinzu Zu griffe auf die Variable werden dann auf speziell markierte Botschaftskanten abgebildet Q Eine mit der Marke uses gekennzeichnete Kante vom Methodenknoten a zum Va riablenknoten x bedeutet dass w hrend der Ausf hrung von Methode a nicht modifi zierend auf Variable x zugegriffen werden kann Q Analog bedeutet eine Kante mit der Marke def vom Variablenknoten x zum Metho denknoten a dass bei der Ausf hrung von Methode a die Variable x modifiziert wer den kann Anders herum ausgedr ckt benutzt Variable x die Methode a zu ihrer Definition F r die Darstellung des KBD treffen wir folgende zus tzlich zur Dar
140. aphen und teilweise umgekehrt Die SCORES Anforderungsspezifika tion erlaubt es dabei f r die Validierung und die Verifikation Metriken bzw Testkriterien sowohl f r Testendekriterien als auch zur Ableitung entsprechender Testf lle anzugeben Im Test der Anwendung gegen die Anforderungsspezifikation zielen sogenannte SCORES grey box Testfalle auf die internen Interaktionen der Anwendung ab Wir zeigen daher in Kapitel 13 wie die Anforderungsspezifikation und die bei ihrer Pr fung protokollierte Information ber den Entwurf in die Implementa tion hin nach verfolgt werden kann Kapitel 9 Validierung A bug prevented is cheaper than a bug discovered Beizer95 Die Anforderungsspezifikation ist sowohl bei ihrer Erstellung als auch sp ter immer dann wenn neue Anforderungen gefunden oder bereits spezifizierte Anforderungen ge ndert wer den zu validieren und zu verifizieren Validierung und Verifikation der Anforderungsspezi fikation sind also fortlaufende ineinander greifende T tigkeiten die sowohl f r Zwischenergebnisse als auch f r die endg ltige Anforderungsspezifikation durchzuf hren sind vgl Boehm84 Cockburn97 Gerrard94 Zur pr ziseren Abgrenzung der Validierung und Verifikation ziehen wir wieder den IEEE Standard 610 zu Rate Validation The process of evaluating a system or component during or at the end of the develop ment process to determine whether it satisfies specified requirement
141. ar so kann nur Geld bis zu einem bestimmten Betrag ausgezahlt werden und die anderen Ver arbeitungsm glichkeiten sind gesperrt F hrt der Automat eine Aktion durch so wird eine Besch ftigt Anzeige ausgegeben Jede ausgew hlte Aktion kann durch die Abbruch Taste ge stoppt werden Geldbetr ge m ssen mit der Best tigungstaste endg ltig festgelegt werden Soll Geld ausgezahlt werden so muss zuvor die Kreditkarte entnommen werden Anschlie end wird das Geld ausgegeben stets 100 Mark Scheine bis auf den letzten dieser wird in kleineren Scheinen ausgegeben z B 50 20 20 10 Nach Abschluss einer Transaktion druckt der Bankau tomat einen Beleg mit bestimmten Informationen ber die Transaktion und dem bzw den aktuel len Kontost nden Der Bankautomat wird regelm ig von einem geschulten Bediener gewartet d h es werden Ressourcen wie Geld und Druckerpapier nachgef llt schmutzgef hrdete Teile ge reinigt und etwaige St rungen beseitigt Hierf r ist ein besonderer Bedienermodus vorzusehen Beginnen wir die Use Case Analyse nach Jacobson JCJ 92 Aus der Produktskizze ermit teln wir die drei Aktoren Bankkunde Bediener und Zentralrechner Wir betrachten zun chst den Aktor Bankkunde n her Der Bankkunde muss sich mit seiner Kreditkarte und der Ge heimnummer gegen ber dem Automaten identifizieren bevor er eine der Transaktionen Geld Abheben Geld Einzahlen und Geld Transferieren durchf hren kann Wir erhal
142. ar bp ext ndS en 21 82 F Fehler a dead Stabes 4 Fehler korrektur 4 2 2428 22 at 28 5 ursache E ae A 4 Fehleraufdeckungsrate 166 Fehlerhypothese 5 Fehlerrate u 190 flattening gt Abflachen G Generalisierung 20 21 Geschaltsprozess nase Tek Aaa ees 14 GUEST ES EE 7 I Information Interaktions 46 58 86 Kontextuelle 46 58 63 86 Systeminterne47 58 86 129 133 169 Inspektion 22 A8 Ss ses ee A 108 Schrittweise 108 Instrumentierung 189 Integrationstest 000 7 T tera k n sa dee AE Ze S 46 direkte m u as 241 EXLEINE a 46 indirekte 224 a ek 241 interne A 28 29 47 241 ERT te EE 174 direkte Aufruf 172 direkte Daten 173 174 indirekte ur aed AS 174 Zustands 00 cee cee eee 241 Interaktionsdiagramm 23 K KBD Aufruf Interaktionskanten 243 Botschaftskante 238 Daten Interaktionskanten 243 Vererbungskante 238 Klassen Botschaftsdiagramm der Anforderungsspezifikation 169 236 der Implementation 170 242 Klassen Botschaftsdiagramm KBD f r die Anforderungsspezifikation 237 f r die Implementation 242 Klassendiagramm 131 Klassenmodell Elemente 00 86 Klassentest 2 2 2 222 Seren ae 32 Knoten Methoden 172 Vari
143. aren Attributzugriffen oder aber nur bis hin zu Aufrufen von wohlverstandenen Operationen modellieren bzw verfolgen und protokollie ren Auch hier ben tigen wir f r die Werkzeugunterst tzung wieder etwas Formalismus Zur Vereinfachung des Klassenmodells bzw der Simulation von Episoden vereinbaren wir zun chst f r jede Dom nenklasse zus tzlich zu ihren explizit spezifizierten fachlichen Do m nen Operationen implizit einige Standard Operationen vgl CoaYou91 PagSix94 Poetzsch97 Q new erzeugt eine neue Instanz der Klasse Q destroy zerst rt eine Instanz der Klasse Q read symbolisiert das Lesen von Attributen einer Instanz der Klasse Q modify symbolisiert das Setzen bzw ndern von Attributen einer Instanz der Klasse Q F r jede eine Klasse betreffende Beziehung x Assoziation Aggregation und Kompo sition bietet die Klasse die Standardoperationen e x connect zum Erstellen e x disconnect zum L sen der Beziehung e x count zur Abfrage der Anzahl aktuell referenzierter Objekte sowie x query zum Zugriff auf einzelne und x iterate zum Zugriff auf alle bezogenen Ob jekte an 130 Verifikation Wir beginnen bei den folgenden Definitionen mit der Simulation der Ausf hrung einer ein zelnen in einer Klasse im Klassenmodell definierten Operation Hierbei bezeichne K wieder die Menge der Klassen im Klassenmodell vgl auch Abschnitt 7 1 Definition 11 1 Ein Episodenschritt es beschreibt die Ausf h
144. arien sind in der Test Szenario Listbox direkt ber dem Use Case Schrittgraphen sichtbar F r den betrachteten Use Case Schrittgraph Anmelden erreicht die 100 ige Use Case Kanten berdeckung auch die 100 ige Use Case Grenze Inneres berdeckung was nat rlich im Allg nicht gilt Da der betrachtete Use Case Schrittgraph Zyklen be inhaltet und somit die 100 ige Szenario berdeckung nicht erreichbar ist ist der entsprechende 1 0 Button deaktiviert Testfall und Testdatengenerierung Aus Test Szenarien werden mit dem Transformations Framework die Botschaftsfolgen sowie Orakel in der Test Skriptsprache generiert s Anhang B Testdaten in Form von Objektkonstellationen werden aus den manuell er stellten Konstellationen unter Beachtung der Klassenbereiche und des Klassenmo dells generiert vgl Rogotzki97 Hierbei werden ber das Transformations Framework die entsprechenden Botschaftsfolgen zum Aufbau der Objektkonstellati onen als Testf lle erzeugt und abgespeichert Im Hinblick auf strukturelle Testkriterien nutzen wir in den SCORES grey box Tests die Vor teile der Pr fung des Zusammenspiels mehrerer Methoden mit Aufrufsequenzen unter Mini mierung des h heren Aufwands bei der Erstellung der erwarteten Ergebnisse Hierzu generiert eine Komponente des SCORESTOOLs das Klassen Botschaftsdiagramm f r die SCORES Anforderungsspezifikation welches die bei der Verifikation betrachtete systemin terne Information der Episoden geei
145. ario Generation and Use Proc 3rd International Workshop on RE Founda tion for SW Quality Barcelona Spain 1997 Mohl97 Gabriele Mohl Regressionstesten objektorientierter Software Diplomarbeit Prak tische Informatik III FernUniversit t Hagen 1997 228 MSL96 Monika M llerburg Andreas Spillner Peter Liggesmeyer Hrsg Test Analyse und Verifikation von Software Aus der Arbeit der FG 2 1 7 TAV der GI R Ol denbourg Verlag M nchen Wien 1996 M lPoe98 Peter M ller Arnd Poetzsch Heffter Kapselung und Methodenbindung Javas Designprobleme und ihre Korrektur in C H Cap Ed JIT 98 Java Informati ons Tage 1998 Informatik Aktuell Springer Verlag 1998 M lWie98 Uwe M ller Thomas Wiegmann State of the practice der Pr f und Testpro zesse in der Softwareentwicklung Ergebnisse einer empirischen Untersuchung bei Softwareunternehmen in Deutschland Technischer Bericht Universit t K ln M rz 1998 Myers79 Glenford J Myers The Art of Software Testing J Wiley amp Sons New York 1979 Nuseibeh97 Bashar Nuseibeh Ariane 5 Who Dunnit IEEE Software Mai Juni 1997 S 15 16 OMG97 OMG Unified Modeling Language Specification V 1 1 OMG Sep 1997 OMG AT98 OMG UML Task Force Activity Diagram Issues OMG Juli 1998 OMG99 OMG Unified Modeling Language Specification V 1 3 alpha R2 OMG Jan 1999 Opdyke92 Wiliam F Opdyke Refactoring Object Oriented Frameworks PhD Dissertation University
146. assen Botschaftsdiagramme Letztendlich m ssen wir noch den Unterschied zwischen Klassen und Instanz Variablen so wie die Effekte der gleichzeitigen Referenzierung und Manipulation eines Objekts ber mehrere Variablen aliases ber cksichtigen W hrend die Modifikation einer Instanzvariab len unmittelbar nur den Zustand eines Objekts beeinflusst wirkt sich die Modifikation einer Klassenvariablen in Java mit dem Schl sselwort static deklariert auf alle Instanzen der Klasse und ihrer Unterklassen aus Im Falle eines Alias k nnen die aus der Transaktions theorie bekannten Synchronisations und Serialisierbarkeitsprobleme auftreten vgl z B VosGrH93 Die Test Problematik versch rft sich also bei der Einbeziehung von Instanzvariablen atoma ren Typs hin zu Instanzvariablen vom Referenztyp ohne Aliases ber Instanzvariablen mit der M glichkeit von Aliases Kommen dar ber hinaus noch Klassenvariablen vom atomaren Typ oder sogar vom Referenztyp mit der M glichkeit globaler Aliases Singleton s GHJ 94 hinzu sollten zur ad quaten Pr fung der Anwendung zus tzlich globale Kontroll und Datenfluss sowie Alias Analysen durchgef hrt werden vgl MGMS96 ZRL96 A 3 Klassen Botschaftsdiagramme f r die Implementation Das KBD stellt in kompakter Art und Weise die Abh ngigkeiten im Dom nen Klassenmo dell zusammen Wir streben analog dazu ein m glichst einfaches Test Modell f r die Imp lementation an welche
147. auch Abschnitt 7 5 In den Ausdr cken verwenden wir die SCORES Primitive und verweisen diesbez glich auf das Metamodell Abb 9 1 Im Fol genden sei uc ein Use Case Schrittgraph und ts ein Test Szenario von uc 10 1 Use Case Schritt berdeckung Die Use Case Schritt berdeckung Co entspricht der Anweisungs berdeckung cg des white box Tests vgl Riedemann97 Die Operation uc validationProtocol ermittelt zu n chst die Menge aller fiir den Use Case protokollierten Test Szenarien F r ein bestimmtes Test Szenario ermittelt die OCL Operation visitedUseCaseSteps die vom Test Szenario berdeckten Schritte des Use Cases ts visitedUseCaseSteps 10 1 ucs uc steps Jtss e ts steps rss UseCaseStep ucs F r uc ist dann die Use Case Schritt berdeckung ts visitedUseCaseSteps gs JU uc validationProtocol 0 uc steps size 10 2 Es ist RL 1 wenn jeder Schritt im Use Case Schrittgraph durch mindestens einen Schritt in einem Test Szenario berdeckt ist Beispiel 10 1 In dem in Abb 10 1 a skizzierten Use Case Schrittgraph sind die von Szena rien berdeckten Schritte fett hervorgehoben Nach 10 2 wurde eine Use Case Schritt ber deckung von eG S 80 erreicht Use Case Kanten berdeckung 117 4 za A a b c Abb 10 1 Beispiele zur Use Case Schritt a Kanten b und Szenario berdeckung c
148. benl ufigkeitstest betrachtet die Ausf hrung des Pr fgegenstands zusammen mit weiteren konkurrenten Anwendungen Der Lasttest untersucht den Pr fgegenstand hinsichtlich extremer Quantit ten bestimmter Daten der Stresstest hinsichtlich extremer Quantit ten bestimmter Ereignisse Mit dem GUI Test wird die Abbildung innerer Zust nde des Pr fgegenstands auf die Benutzungs schnittstelle mit dem Benutzbarkeitstest die ergonomische Ad quatheit des Pr fge genstands gepr ft Testwerkzeuge unterst tzen die Tester bez glich einzelner oder mehrerer Testverfah ren sowie bei den administrativen T tigkeiten Evaluationen bewerten bekannte oder neue Methoden und Verfahren im praktischen Einsatz oder versuchen bestimmte Hypothesen ber dieselben mit kontrollierten Ex perimenten bzw empirischen Methoden zu best tigen oder zur ckzuweisen Letztendlich geh ren der Testprozess und das Testmanagement zu den administrati ven Punkten der Qualit tssicherung Wir skizzieren nun noch kurz die historische Entwicklung der Software Qualit tssicherung sowie den diesbez glichen Stand in der industriellen Praxis 1 2 Geschichte Gelperin und Hetzel unterscheiden von den Anf ngen der Programmierung bis 1988 f nf Epochen der Software Qualit tssicherung GelHet88 1956 In der Debugging Epoche bereiteten Hardware Fehler weitaus gr ere Probleme als Fehler in der Software Im Wesentlichen bestanden die qualit tssichernden T t
149. bis acht Personen Der Moderator der ein erfahrener Softwareentwickler sein sollte leitet hauptverantwortlich die Inspektionssitzung und protokolliert alle gefundenen Defek te Au erdem muss er die anschlie ende Behebung aller w hrend der Inspektion ge fundenen Defekte sicherstellen Die weiteren Teilnehmer sind der Autor des Dokuments der Programmdesigner wenn es sich um ein Codedokument handelt und ein Testspezialist Eine Inspektion l uft in den folgenden vier Etappen ab berblick Der Moderator verteilt das zu pr fende Dokument inkl s mtlicher Vor g ngerdokumente die bindende und damit zu testende Vorgaben enthalten z B die Produktskizze an die Teilnehmer F r nicht mit dem Produkt vertraute Teilnehmer kann optional noch ein kurzer Informationsvortrag ber das Produkt und das zu pr fende Dokument gegeben werden Vorbereitung Die Teilnehmer setzen sich intensiv mit dem Stoff auseinander Sitzung Der Autor erl utert sein Dokument Schritt f r Schritt Alle in der Diskussion erkannten Defekte werden protokolliert jedoch nicht korrigiert Als Hilfsmittel die nen dabei z B Checklisten m glicher Defekte Nachbereitung In dieser Phase werden die gefundenen Defekte behoben Die Sitzung sollte nicht l nger als 120 Minuten dauern da danach die Konzentrations f higkeit der Teilnehmer und damit die Produktivit t zu stark nachl sst In dieser Zeit k nnen ca 250 300 Anweisungen Quelltext inspiziert werden Na
150. ch Parnas kann der Inspektionserfolg dadurch verbessert werden dass unterschiedlich qualifizierte Reviewer z B Benutzer Entwickler Anwendungsspezialist Teile des Pr f gegenstands anhand verschiedener defektspezifischer Techniken untersuchen active design reviews ParWei85 In mehreren kleineren Treffen der Entwickler mit jeweils einem Re viewer werden die aufgeworfenen Punkte weiter diskutiert und so ein umfassendes Protokoll erstellt Eine weitere Verbesserung durch die Unterteilung der Reviews in kleine aufeinander auf bauende Schritte phases schlagen Knight und Myers mit schrittweisen Inspektionen phased inspections vor KniMye93 In Einzelinspektorschritten wird das Produkt zuerst Funktionale Zerlegung 109 von jeweils einem Reviewer gegen relativ einfache aber wichtige anwendungsunabh ngige Defekte z B Spezifikations Richtlinien gepr ft Danach pr fen mehrere Reviewer in sog Multi Inspektorschritten das Produkt unabh ngig voneinander gegen dom nen oder anwen dungsspezifische Defekte z B Gesch ftsregeln Robustheit Benutzerfreundlichkeit In ei ner jede Multiinspektorphase abschlie enden Sitzung vergleichen die Reviewer ihre Ergebnisse und erstellen ein gemeinsames Protokoll Im Unterschied zu den anderen Review Techniken die jeweils einen Teil des Produkts gegen viele Kriterien pr fen wird in jedem Schritt das gesamte Produkt gegen eine oder einige wenige Eigenschaften gepr ft Experi mentell wurde
151. cherung f r objektorientierte Anwendungen Q Zur berpr fung von Vertr gen also Vor und Nachbedingungen von Operationen sowie Klasseninvarianten sind Zugriffe auf den Zustand des Pr fgegenstands als auch auf die Zust nde der Botschaftsparameter notwendig Q Im Unterschied zu prozedural implementierten Anwendungen muss bei der berde ckungsmessung f r dynamische Tests objektorientiert implementierter Anwendun gen unterschieden werden ob die Angaben sich auf Klassen oder Objekte beziehen Beispiel Eine Klasse K bietet zwei Operationen M1 und M2 an Instanziiert man nun zwei Objekte O1 und O2 von K und verwendet nach O1 M1 dann O2 M2 ist dann die Abdeckung 50 oder 100 Q Eine hnliche Unterscheidung muss im Falle der Vererbung bez glich der Klasse des die Operation ausf hrenden Objekts getroffen werden Strau und H rnke stellen dementsprechend fest In C sind die Klassen tendenziell sehr stark vernetzt so dass die Eingabe der Daten zu den In stanzen und die Instanzenverwaltung zeitaufwendig und unhandlich war StrH r98 Methodische Unterst tzung zum Klassentest geben z B die Arbeit von J ttner und die meis ten der von Binder bzw Kung et al betrachteten Arbeiten J ttner93 Binder96a KHG98 Barbey leitet aus einer algebraischen Spezifikationssprache und hierarchischen Petrinetzen Testf lle f r den Klassentest ab Barbey97 Siepmann und Newton beschrei ben ein Werkzeug zum Klassen und Integrations
152. chie wobei die eine Unterklasse der anderen ist und umgekehrt Intra Klassenhierarchie Interaktionen oder Q zwischen zwei Objekten verschiedener Klassen die nicht ber die Vererbung verbun den sind Inter Klassenhierarchie Interaktion Wir orientieren uns bei den folgenden Betrachtungen an den sequentiellen Konstrukten der Programmiersprache Java s GJS96 Zur Vereinfachung gehen wir davon aus dass alle Methoden sowie ggf Klassen bzw Instanz Variablen in allen Klassen einer Anwendung sichtbar sind public Da in Java enge Wechselwirkungen zwischen den Kapselungskonst rukten und den Regeln f r die Bindung von Methoden bestehen die im Extremfall bis hin zu Anomalien bei der dynamischen Bindung von Methodenaufrufen bzw Botschaften an die ausgef hrte Methode f hren k nnen vgl M lPoe98 betrachten wir auch den Paket Me chanismus von Java nicht Die Java Sprachspezifikation unterscheidet Klassen und Instanz Methoden wobei erstere durch das Schl sselwort static in der Deklaration gekennzeichnet sind Wird von einer Un terklasse eine Klassenmethode berschrieben hiding so ist die berschriebene Methode durch Verwendung des Schl sselworts super innerhalb der Methoden der Unterklasse bzw nach einem cast eines Objekts der Unterklasse in eine Instanz der Oberklasse auch von Aussen Inter Objekt sichtbar berschriebene Instanz Methoden overriding sind im Ge gensatz dazu von Aussen nicht sichtbar 242 Kl
153. chtsachliche Aspekte wie z B den histori schen Aspekt zur Protokollierung von T tigkeiten und den transaktionalen Aspekt zur Koor dination von nebenl ufigen T tigkeiten Der die T tigkeiten in einem Unternehmen beschreibende Gesch ftsprozess wird also mit ei nem Workflow Modell in einem WFMS spezifiziert welches den Gesch ftsprozess dann durch die koordinierte Ausf hrung verschiedener Anwendungen automatisiert Diesen Zu Gesch ftsprozess Spezifikation Workflow Management System Ausf h usfuhrung Anwendung 1 2 Anwendung n Abb 2 2 Gesch ftsprozess WFMS und Anwendungen sammenhang zeigt Abb 2 2 Engen wir nun den Blickwinkel auf eine bestimmte innerhalb eines Workflows auszuf hren de Anwendung ein so k nnen wir bestimmte Sichten bzw Aspekte zun chst als vorgege bene und relativ stabile Randbedingungen ansehen Einige Aspekte wie z B die Organisation und die Ziele des Gesch ftsprozesses ergeben hervorragende Einstiegspunkte in die Anforderungsermittlung f r eine bestimmte Anwendung Anhand der Organisations struktur ermitteln wir wer mit der Anwendung welche Ziele erreichen soll Die Informations bzw Datensicht gibt die Struktur der Daten an welche die Anwendung lesen bzw erzeugen soll Dies kann z B in Form von Dateiformaten oder Datenbankschemata oder aber bei ma nueller Dateneingabe umgangssprachlich bzw mit Formularen erfolgen Fassen wir zusammen zu Beginn einer E
154. cles 3rs e uc ValidationProtocol ccts path a Ype c c p c ts path 10 15 Ebenso ermitteln wir mit der Operation uc alllnteriorCycles alle Zyklen im Use Case Schritt graph die zwei oder mehrmals von einem Test Szenario tiberdeckt werden uc alllnteriorCycles c e uc allCycles 3rs e uc ValidationProtocol 3p c p Cts path 10 16 Zus tzlich ermitteln wir noch alle Zyklen im Use Case Schrittgraph die von mindestens ei nem Test Szenario nicht berdeckt also umgangen werden 10 17 uc allExtPaths c e uc allCycles 3rs e uc ValidationProtocol Jp c p Cts path 10 17 Nach diesen Voriiberlegungen sind wir in der Lage fiir einen Use Case Schrittgraph uc die Use Case Grenze Inneres Uberdeckung zu definieren Suez uc allBoundaryCycles n uc alllnteriorCycles N uc allExtPaths am uc allCycles size 10 18 Grenze Inneres und Pfad berdeckung 121 Online Anmeldung Karte Einf hren Karte Lesen PIN Anfordern PIN Pr 2 Karte fen Auswahl Anzeigen Einf hren 3 e Anmeldung Abbrechen Karte Einf hren y Karte Lesen PIN Anfordern arte ioe Schreiben Karte Anbieten Karte Ent nehmen Karte Einziehen y Falsche PIN Karte Einf hren arte Ee JI PN Lesen PIN Anfordern PIN Pr fen PIN 2 Anfordern Bankkunde A Anfordern PIN Pr fen Karte Schrei ben Karte Anbieten Karte Entnehmen II _PIN SR Karte Ung ltig
155. d IF static k m Modifiers THEN Klassen Member I class ELSE l instance Instanz Member V Vu k m l FORALL FORALL ke K DO Kanten f r die direkten Interaktionen erzeugen FORALL k m e k MethodDeclarations DO FORALL ml k m MethodInvocations DO ky TYP ml i4 ml Identifier s PREFIX ml IF s e THEN einfacher Methodenaufruf E EU kiim k i message ELSE super this oder new E E U kim k 2 1 8 IF FORALL a k m Assignments DO def uses Kanten erzeugen i a LeftHandSide e a RightHandSide IF ie k InstanceVariables THEN der ky DEFCLASS i E EU k 2 i kum def IF FORALL ie e VARIABLES DO IF ie k InstanceVariables THEN uses ky DEFCLASS i E Eu kim k i uses IF FORALL FORALL CALL PolyKBD I Vererbung und Interface Implementation ber cksichtigen Abb 22 4 RETURN VE P END Generiere KBD Abb 22 3 Algorithmus Generiere KBD 246 Klassen Botschaftsdiagramme und im Falle von PREFIX ml super um einen statisch gebundenen selbstrekursi ven Methodenaufruf Q Die Funktion TYP ml ermittelt nach der Sprachdefinition die Wurzel der Vererbungs bzw Interface Hierarchie mit den als Ziel des Aufrufs erlaubten polymorph substi tuierbaren Klassen bzw Interface Implementationen In anderen Worten
156. d Class Structures Proc Int Conf on Software Engineering ACM Mai 1992 S 68 80 HarNaa96 David Harel Amnon Naamad The STATEMATE Semantics of Statecharts ACM Transactions on Software Engineering and Methodology Jahrg 5 Nr 4 Okt 1996 Hasselbring98 Wilhelm Hasselbring Erfahrungen mit dem Einsatz von anwendungsspezifi schen Piktogrammen zur partizipativen Anforderungsanalyse Informatik For schung und Entwicklung 13 Jahrg Nr 4 1998 S 217 226 Hatton98 Les Hatton Does OO Sync with How We Think TEEE Software Mai Juni 1998 S 45 54 HDK93 P Hsia A Davis und D Kung Status Report Requirements Engineering IEEE Software Jahrg 10 Nr 6 1993 S 75 79 224 Henderson96 Brian Henderson Sellers Object Oriented Metrics Measures of Comple xity Prentice Hall Upper Saddle River New Jersey 1996 Hetzel88 Bill Hetzel The Complete Guide to Software Testing 2 Aufl QED Information Sciences Wellesley Mass 1988 HitKap98 Martin Hitz Gerti Kappel Developing with UML Some Pitfalls and Worka rounds in Proc UML 98 Beyond the Notation J Bezivin and P A Muller Hrsg 1 Int Workshop on UML Mulhouse France Springer LNCS 1998 HKR 97 Brigid Haworth Colin Kirsopp Marc Roper Martin Shepperd Steve Webster Towards the Development of Adequacy Criteria for Object Oriented Software Proc 5 euroSTAR 97 Edinburgh Scotland Nov 1997 S 417 427 HomVos97 Andreas Homrighausen Josef Voss Tool
157. d des Klassenmodells Aus gehend von einem sogenannten Wurzelobjekt k nnen Analytiker und Tester anhand der Beziehungen der entsprechenden Klasse im Klassenmodell zu weiteren Klassen navigieren und diese instanziieren Hierbei werden z B Multiplizit tsbeschr nkungen der Beziehungen automatisch ber cksichtigt In Abb 20 4 ist der SCORESTOOL Ob jektkonstellations Editor gezeigt Ausgehend von der Wurzelklasse Transaktion ist zun chst ber die Beziehung meineSchnittstelle zur Klasse ZentralrechnerSchnitt stelle das Objekt Host 1 erzeugt und mit der Transaktion verkn pft worden Danach wurde ein Objekt der Klasse Karte und ber die Beziehung meinKonto zwischen den Klassen Karte und Konto einige Instanzen der Klasse Konto in die Objektkonstella tion eingef gt 202 SCORESTOOL Bankautomat Scenario Browser xj Anmelden Geld Auszahlen Test Erfolgreiche Anmeldur Scenario Geld Tiana ion D Karte Einf hren Karte Lesen H PIN Anfi Nal al BEE 2 DW ep EI sl J F zE vais z Processed by system Actor UseCase Functional Profile U highC mediumRt Rb Rp high high en high H Actors Bankkunde Pre Condition Kartenleser betriebsbereit Bedienpult e f Karte Einf hren gesperrt Description Nach Eingabe der Karte durch den Bankkunde liest der Bankautomat den Code vom est Scenario Protocol coverage
158. definierte Operationen zu Dementsprechend erfolgt die Kommunika tion zwischen Objekten ausschlie lich ber Operationsaufrufe Botschaften was sich auf die Kommunikation im System fortsetzen l sst Die Bedingungen der Schritte und Kanten im Use Case Schrittgraph werden mit der minima len Mehrfach Bedingungs berdeckung Abschnitt 12 1 verifiziert Da wir dar ber hinaus das Verhalten der Dom nenklassen pr fen zielen die strukturell orientierten Verifikations metriken haupts chlich auf Testmethoden f r die im Klassenmodell definierten Operationen ab und geben Analytikern und Testern Kriterien daf r wie umfassend das Klassenmodell ve rifiziert wurde Abschnitt 12 2 Bez glich der in den Definitionsgleichungen der Metriken verwendeten SCORES Primitive verweisen wir auf das Metamodell in Abb 11 2 12 1 Minimale Mehrfach Bedingungs berdeckung Testszenarien alleine nach der Struktur der Use Case Schrittgraphen auszuw hlen ist nicht ad quat da die eigentlichen Spezifikationen d h die Vor und Nachbedingungen der Use Cases bzw der einzelnen Use Case Schritte nicht im Mittelpunkt ihrer Ermittlung stehen Analytiker und Tester k nnen die Vor und Nachbedingungen unter Ausnutzung folgender Eigenschaften verifizieren Q Jede Bedingung besteht aus einer pr dikatenlogischen Formel bzw einem boo le schen OCL Ausdruck meistens in Form einer UND bzw ODER Verkniipfung oder einer Implikation zwischen Termen auch atomare Pr
159. dellieren wir den Aufruf beliebig vieler weiterer Episodenschritte Folgeschritte Dies entspricht 136 Verifikation der Intention dass Episoden sowie die sie visualisierenden Sequenz und Kollaborationsdi agramme Aufruf B ume von Operationen darstellen gd validationProtocoll refersTo 1 1 nr StepGraph 0 1 1 0 ValidationClassifier F Q 2 o g Actor 2 o 2 SE a A S g g i D bi n Ka E Ze ScenarioStep Se SZ UseCaseStep d P an A 1 test protocoll S Successor 1 rootClass g Class successors S S x g 1 SupportedStep 1 Y8 Se Le Pr D A g E lk InteractionStep ContextualStep MacroStep i Episode Feature Operation EpisodeSte p 1 rootOperation p p Abb 11 2 Vollst ndiges SCORES Metamodell Kapitel 12 Verifikationsmetriken W hrend die Validierung haupts chlich die funktionalen Aspekte der Anforderungsspezifi kation also die Use Cases und ihre Schrittgraphen betrifft bezieht sich die Verifikation auch auf das Zusammenspiel der funktionalen und strukturellen Aspekte also zus tzlich auf das Dom nen Klassenmodell Objekte verstecken ihre Daten bzw ihren Zustand und lassen Zugriffe nur ber wohl
160. der Modellierung von Use Case Schrittgraphen dass die Inter Use Case Referenzfunktion 1 Die Formulierung mindestens alle anderen Schritte macht nur im Falle genau eines Schritts mit dieser Eigenschaft Sinn Dieser darf den Eingangsgrad 0 haben 2 Der Stern bezeichnet hier den transitiven Abschlu einer Relation Darstellungskonventionen 71 REF UC 20C azyklisch sein muss Diese Vereinbarung vereinfacht insbesondere Be trachtungen zur Terminierung der mit Use Case Schrittgraphen beschriebenen Aufgaben vgl HOR98 Regel 5 4 6 Makro Struktur Der transitive Abschluss der Inter Use Case Referenzfunktion ist irreflexiv V uc e UC uc REF uc 5 5 Darstellungskonventionen Wir kommen nun zur Darstellung von Use Case Schrittgraphen Use Case Schritte werden mit einem der Schrittart entsprechenden Symbol gezeichnet Tab 5 1 Symbol Bedeutung Kontextschritt Interaktionsschritt Tab 5 1 Symbole der Use Case Schritte Nachfolgeschritte werden mit ihrem Vorg ngerschritt durch einem Pfeil mit geschlossener ausgef llter Spitze verbunden Die dem Use Case Schritt zugeordneten Aktoren werden wie im Use Case Diagramm dargestellt vgl OMG97 Verl uft die Kommunikation zwischen Aktor und Schritt nur in einer Richtung deuten wir dies mit einem Pfeil mit offener Spitze an Den Startschritt markieren wir mit einem doppelt gezeichneten Rahmen alle Endschritte ei nes Use
161. diagrams in situations where all or most of the events represent the completion of internally generated actions that is procedural flow of control OMG97 Exkurs Use Case Schrittgraphen und Aktivit tsdiagramme 97 Somit k nnen in einem Aktivit tsdiagramm entweder kontextuelle interaktions oder syste minterne Information nicht aber mehrere Informationsarten gleichzeitig abgedeckt werden Zus tzlich zu diesen eher konzeptuellen M ngeln k nnen wir Use Case Schrittgraphen aus weiteren Gr nden nicht ohne nderungen des UML Metamodells auf Aktivit tsdiagramme abbilden Q Referenzen von Zust nden Aktivit ten auf vollst ndige Aktivit tsdiagramme sind nicht erlaubt Daher lassen sich die extends und uses Beziehungen nicht auf Aktivi t tsdiagramme fortsetzen was die Ausdrucksst rke des Modells stark beeintr chtigen w rde Die M glichkeit in sogenannten Untermaschinen Zust nden Submachine States auf vollst ndige Zustandsdiagramme zu verweisen ist eher auf syntaktischer Ebene zu sehen und wird semantisch auf eine textuelle Ersetzung des Untermaschi nen Zustands durch das referierte Zustandsdiagramm zur ckgef hrt Hierarchien sind auf ein Ober Aktivit tsdiagramm beschr nkt und k nnen nicht zur Redundanzver meidung verwendet werden Q Zust nde sind nicht Unterklasse der UML Metaklasse Classifier Damit k nnen ein zelnen Zust nden keine Aktoren oder Elemente des Klassenmodells zugeordnet wer den was die
162. die Semantik des inte grierten Szenarienmodells ab und gibt Regeln zu seiner Analyse und Verifikation z B in Hinblick auf deadlocks Konsistenz und Vollst ndigkeit an Abschlie end skizziert Glinz wie Klassen bzw Objektmodelle in das Szenarienmodell integriert werden k nnten Aufgrund der Einschr nkung auf die systeminterne Information und des De taillierungsgrades erscheinen die Modelle eher f r die Entwurfst tigkeiten als zur An forderungsermittlung geeignet Die vorgeschlagene Integration von Klassen bzw Objektmodellen in das Szenarienmodell stellt Objekte als Zust nde bzw Statecharts dar und ist insbesondere zur Generierung von Prototypen vorgesehen Ziegler entwickelt basierend auf der Vereinigung von Aufgabenhierarchien und Zustandsma schinen eine Vorgehensweise zum Entwurf von Anwendungen mit grafischen Benut zungsschnittstellen Ziegler96 Zur Modellierung von Aufgaben und Prozessen f hrt Ziegler die sog Task Object Charts ein welche besondere Darstellungsmittel f r Aufgabenhierarchien nebenl ufige Bearbeitung und flexible Aufgabenstellungen be reitstellt Durch die Verwendung von Objektzust nden zur Steuerung von Aufgabe nabl ufen wird eine Kopplung zwischen Objekt und Aufgabenmodell angestrebt mit welcher der Entwurf von Dialogstrukturen in systematischer Weise abgeleitet wird Z llighoven beschreibt einen Leitbild orientierten haupts chlich mit den Metaphern Werk zeug Automat und Material
163. dlichen Clustern keine Aggregationen und Kompositionen existieren Wir in spizieren z B gegen folgende Kriterien Q Sind die erkennbaren Cluster explizit als solche dokumentiert Q Sind die dokumentierten Cluster entkoppelt d h bestehen zwischen Klassen aus ver schiedenen Clustern keine Aggregationen und Kompositionen Q Existieren zwischen Klassen aus verschiedenen Clustern wenige klar dokumentierte Assoziationen welche die notwendigen Navigationen zum Botschaftsaustausch er m glichen Nach den Inspektionen sind sowohl das Use Case Modell als auch das Klassenmodell kon sistent und eindeutig also formal korrekt In der Validierung wurde das Use Case Modell hin sichtlich seiner fachlichen Korrektheit und Vollst ndigkeit untersucht so dass es nun vollst ndig gepr ft ist Da w hrend der Validierung nur Teile des Klassenmodells gepr ft wurden k nnen wir seine Vollst ndigkeit und fachliche Korrektheit noch nicht zusichern Es verbleibt also zu verifizieren ob das Klassenmodell bez glich der validierten und verifizier ten Use Cases vollst ndig und korrekt ist Externes vs internes Verhalten 127 Hierzu pr fen wir ob das Klassenmodell die Aufgaben im Use Case Modell ad quat wider spiegelt wobei der durch die Klassenbereiche Wurzelklassen und der Wurzeloperationen hergestellte nahtlose und nach verfolgbare bergang von den Use Case Schritten zu Opera tionen und Klassen im Klassenmodell eine ausschlaggebende Ro
164. dlungen eines Use Cases be schreiben W hrend jedoch bei der Generalisierung hnlich zu Jacobsons Interpretation der extends Beziehung vgl JCJ 92 nur die Konformit t der Vor und Nachbedingungen ge fordert ist und der Schrittgraph des spezialisierenden Use Cases beliebige weitere Aufgaben 1 sz generalisiert szg wenn Sz durch Streichung endlich vieler Schritte aus szg entsteht und f r jeden verbleibenden Makroschritt smg in szg und den entsprechenden Makro schritt sm in sz gilt RefUC smg lt RefUC sm 84 Semantik enthalten bzw Szenarien erm glichen kann sind bei der von uns pr zisierten uses und ex tends Beziehungen im Sinne der UML vgl OMG99 nderungen bzw Spezialisierungen nur noch f r ganz bestimmte durch die Erweiterungspunkte hier Makroschritte ange zeigte Teile m glich Fassen wir die Ergebnisse dieses Teils der Arbeit zusammen Use Case Schrittgraphen kom binieren die funktionalen Anforderungen also das Was bzw die Aufgaben unserer Anwen dung mit der Ablauflogik also dem Wann und Warum Als funktionales Konzept haben Use Cases nat rlich kein Ged chtnis wir haben daher Aufgaben und insbesondere den Kontext bzw Zustand in dem sie ausgef hrt werden rein deskriptiv anhand von Vor und Nachbe dingungen ber Realwelt bzw Dom nenklassen spezifiziert Die im Klassenmodell spezifizierten Operationen der Dom nenklassen als eine weitere funk tionale Sicht haben aufgrund ihres g
165. drei statischen Teilgraphen CHS CDS und DDS des OPDG AA KBD Ausdrucksst rke Das KBD ist rein syntaktisch also auf Klassenebene definiert Es abstrahiert von Aspekten der Objektebene wie z B Aliases und aktuellen Belegungen der Parameter eines Methoden aufrufs Auch der Kontrollfluss bzw die tats chliche Reihenfolge der gesendeten Botschaf ten bei der Ausf hrung einer Methode wird vernachl ssigt Dem KBD liegt somit ein asynchrones broadcast basiertes Ausf hrungsmodell zugrunde vgl CooDan94 Q Die w hrend der Ausf hrung einer Methode gesendeten Botschaften bzw bewirkten Zustandsmodifikationen werden quasi als simultan angenommen Q Jede Botschaft wird gleichzeitig an alle Instanzen der Zielklasse n gesendet Effektiv erfasst das KBD so eine Obermenge der bei der Ausf hrung einer Anwendung m g lichen Interaktionen zwischen Objekten und wir erhalten den Satz 22 3 Das KBD repr sentiert eine obere Grenze f r die zwischen Objekten einer Anwen dung zur Laufzeit m glichen Interaktionen Beweis Skizze Der Beweis erfolgt zun chst durch Enumeration aller m glichen direkten Aufruf und Daten Interaktionen und ihre Konstruktive Ber cksichtigung im Algorithmus Generiere KBDI Abb 22 3 bzw der Funktion PolyKBD Abb 22 4 Die Uberdeckung der indirekten Zustands Interaktionen sowie durch Aliasing verursachten Nebenwirkungen wird mit der asynchronen Broadcast basierten Betrachtungsweise
166. ds bergangsdiagramm vereinigt aus dem dann wei tere Ereignissequenzen f r den Abnahmetest generiert werden Dieses Vorgehen ist analog zum statistischen Benutzungstest statistical usage testing vgl Lyu96 Oshana98 RegRun98 Zusammenfassend gesagt pr ft der anforderungsbasierte Test die Anwendung gegen ihre An forderungsspezifikation Zus tzlich pr ft der entwurfsbasierte Systemtest systematisch die Anwendung gegen den Entwurf In dieser Arbeit konzentrieren wir uns auf diese beiden Ar ten von System und Abnahmetests da die Pr fung gegen nicht funktionale Anforderungen wie z B der Performanz und Stresstest oder der Benutzbarkeitstest in der Tat unabh ngig von der Art der Anforderungsspezifikation bzw der Entwicklungsmethode sind Wir betrach ten daher im Folgenden die bez glich der Fragestellung Test gegen die funktionale Anfor derungsspezifikation relevanten Arbeiten 3 4 Relevante Arbeiten Test gegen objektorientierte Anforderungsspezifikationen Binder skizziert eine Strategie zum Use Case basierten Systemtest welche jeden Use Case entsprechend seiner Benutzungsh ufigkeit operational profile pr ft Binder96b Er empfiehlt hnlich wie Poston s Unten die f r den konkreten Ablauf eines Use Case erforderliche Information in sogenannten operationalen Variablen operational variables zu spezifizieren die er dann in einer Art Entscheidungstabelle operational Relevante Arbeiten Test gegen objektorien
167. duktion X AB ist quivalent zu X A BA und ZU X A XBA Produktionsregeln ClassTestCase TESTCASE TCld TestCase TestCase TCHeader FormParams LokalDekls Precond TCBody TCHeader ROOTCLASS Classld USECASE UCld FormParams Params Params OList Classld OList Objectld LokalDekls LOCAL Params Precond PRECONDITION ObjectQuery TCBody BEGIN Constructor TestMessage END Constructor CREATE Message Outcome TestMessage Executable Outcome Executable MessageExp TestCaseSubst MessageExp Objectld Objectid Message Message Messageld ActualParams ActualParams ActualParam ActualParam BasicExpr Objectld TestCaselnst TestCaseSubst SUBST TCld ActualParams TestCaselnst INST TCld ActualParams BasicExpr IntegerExp RealExp BoolExp Char String null Outcome Exception Oracle Exception EXCEPTION Objectld Classid String ObjectQuery ObjectQuery Executable RelOp Executable BasicExpr Oracle ORACLE OrPart OrPart pre ObjectQuery MessageTrace RelOp isEqual isEqual Objectld Identifier Classld Identifier TCld Identifier UCld Identifier MessageTrace MessageTrace Message Message Classld MessagelD Messageld Identifier IntegerExp integer String string Char c
168. dung von Defekten zu denen au er Pr fen Debuggen Validierung und Verifikation auch die Planung und Kontrolle dieser T tigkeiten geh ren Die Qualit tssicherung bzw das Testen im weitesten Sinne kann in die Gebiete Theorie Verfahren Werkzeuge Evaluierung und Management unterteilt werden Binder96a In nerhalb dieser Gebiete nehmen wir die in Abb 1 1 gezeigte weitere Unterteilung vor vgl Beizer90 PagSix94 Binder96a Riedemann97 Die in dieser Arbeit angesprochenen Ge biete der Qualit tssicherung QS sind in Abb 1 1 mit 40 gekennzeichnet Q Die Testtheorie als Grundlage jeder Testmethode ben tigt zun chst Beobachtungen zur Testbarkeit der betrachteten Klasse von Pr fgegenst nden Basierend auf diesen Beobachtungen bisherigen Erfahrungen gesundem Misstrauen und Experimenten werden geeignete Fehlerhypothesen aufgestellt Jede Fehlerhypothese stellt eine An nahme bez glich der Fehlerwahrscheinlichkeit einer Klasse von Pr fgegenst nden re lativ zu einem bestimmten Aspekt dar Aufbauend auf Fehlerhypothesen werden Testmodelle z B anhand der Struktur des Pr fgegenstands z B Kontroll oder Datenfluss strukturelles white box Vorge hen oder seiner Spezifikation funktionales black box Vorgehen entwickelt aus denen mit entsprechenden Testverfahren konkrete Testf lle f r die zu testenden Pr f 1 Falsifizierendes Pr fen entspricht der modernen Interpretation des Begriffs Testen vgl My
169. e Case uc und tss tss1 tSS die Folge der Schritte von ts Es gelte also tss ts steps first und tss o tss f r 0 lt i lt n Wir ermitteln zun chst den ein eindeutig dem Test Szenario entsprechenden Pfad im Use Case Schrittgraph und de finieren hierf r Operation ts path 10 9 ts path ucs UcS ucs e uc allPaths Vie IN ucs tss UseCaseStep 10 9 Zus tzlich ermittelt die Operation ts isComplete 10 10 ob der dem Test Szenario entspre chende Pfad auch tats chlich ein Szenario im Use Case Schrittgraph darstellt also mit dem Startschritt beginnt und in einem Endschritt endet Grenze Inneres und Pfad berdeckung 119 ts isComplete tss UseCaseStep ts UseCase startStep A 10 10 tss UseCaseStep e uc finalSteps Die Use Case Szenario berdeckung cSz ermittelt nun den Prozentsatz aller von einem Test Szenario berdeckten m glichen Szenarien im Use Case Schrittgraph zu uc ftse uc ValidationProtocol rs isComplete C o S Sz uc allScenarios gt size 10 11 Es ist cs 1 wenn jedes m gliche Szenario des Use Case Schrittgraphen also jeder Pfad der mit dem Startschritt beginnt und in einem Endschritt endet auch als Test Szenario proto kolliert ist Beispiel 10 3 In den drei in Abb 10 1 c gezeigten Skizzen eines Schrittgraphen sind die von Test Szenarien berdeckten Kanten fett hervorgehoben Nach 10 5 ist eine Use Case Sze nario berdeckung von Zeg 4 get e
170. e Lesen Use Case Kanten Uberdeckung 0 727273 1 0 Boundary Interior berdeckung 0 0 1 0 Szenario berdeckung Zykeln 1 0 5 PIN Anfordern s Karte Schreiben s PIN Pr fen 1 BI Abb 20 7 SCORESTOOL Szenario Browser Metrik Sicht 204 SCORESTOOL 20 3 Verifikation Die Werkzeugunterst tzung f r die Verifikation ist hnlich aufgebaut wie die zur Validie rung arbeitet jedoch auf einer wesentlich feineren Granularit t und zielt wesentlich umfas sender auf das Klassenmodell ab Wir stellen in diesem Abschnitt den Episoden Editor und einige erweiterte M glichkeiten der Verifikationsmetriken vor Episoden Mit dem Klassenbereich der Wurzelklasse und der Wurzeloperation f r die Use Case Interaktionsschritte ist festgehalten welche Operation welcher Klasse im Klas sendiagramm f r die Aufgabe eines Use Case Schrittes verantwortlich ist Hierauf ba sierend k nnen Analytiker und Tester f r ein Test Szenario in Episoden die Ausf hrung der dem Interaktionsschritt zugeordneten Wurzeloperation in der ange nommenen Objektkonstellation durchspielen bzw simulieren Die unterst tzende Komponente des SCORESTOOLs ist der Episoden Editor Abb 20 8 zeigt den Episo den Editor bei der Simulation der Operation pr fePIN in der Klasse Zentralrechner Schnittstelle Der aktuelle Sichtbarkeitsbereich ist in der mit Actual Scope betitelten Listbox oben rechts angezeigt bei Auswahl eines ihrer Elemente werden in der Bo
171. e Schritte Folgeschritt_1 bis Folgeschritt_m jeweils eine oder mehrere Vorbedingungen der Schritte Folgeschritt_m 1 bis Folgeschritt_n erf llen F r diesen Spezialfall vereinbaren wir die in Abb 6 6 skizzierte Semantik F r einen Schritt x gebe hierbei das Pr dikat exe cuted x an ob die Aufgabe von x innerhalb des aktuellen Ablaufs bereits ausgef hrt ist Folgeschritt n BEGIN Schritt Schritt Aufgabe WHILE NOT executed FolgeSchritt_1 AND AND executed FolgeSchritt_m DO CASE NOT executed FolgeSchritt_1 FolgeSchritt_l NOT executed FolgeSchritt_m FolgeSchritt_m END END CASE c Schritt FolgeSchritt_m 1 GOTO FolgeSchritt_mt1 eens Folgeschritt 1 Folgeschritt m c Schritt FolgeSchritt_n GOTO FolgeSchritt_n It Folgeschritt m 1 Folgeschritt n ELSE ERROR END END Schritt Abb 6 6 Semantik 5 kein Endschritt Parallel ausf hrbare Folgeschritte 1 Wir h tten auch die in der Literatur oft verwendete bewachte nichtdeterministische An weisung z B in der Form DO NOT executed FolgeSchritt_1 FolgeSchritt_1 NOT executed FolgeSchritt_2 FolgeSchritt_2 NOT executed FolgeSchritt_m FolgeSchritt_m OD zur Spezifikation des zusammenfassenden Schritts benutzen k nnen Dijkstra76 Da wir jedoch bei der CASE Anweisung sowieso keine Reihenfolge f r die Pr fung der Be dingungen voraussetzen erschien dies nicht als zwingend Schritte in
172. e des KBD ermittelt das Werkzeug dann alle m glicherweise von den nderungen am Quellcode der Anwendung be troffenen erneut zu testenden Methoden s Mohl97 Andere Modelle f r objektorientierte Programme Palsberg und Schwarzbach verwenden zur Typ Inferenz und zur Ermittlung nicht ausf hr barer Teile objektbasierter Anwendungen sogenannte Trace Graphen PalSch94 1 Als Regressionstest wird wir die erneute Ausf hrung und Auswertung von Tests nach nderungen der Implementation bezeichnet vgl Riedemann97 247 Das KBD stellt eine die Vererbung ber cksichtigende auf den Test zugeschnittene Erweiterung des Trace Graphen dar McGregor et al stellen mit dem Object Oriented Program Dependency Graph OPDG ein feingranulares heterogen zusammengesetztes Modell vor IMGMS96 Der OPDG besteht aus den vier Teilgraphen Class Hierarchy Subgraph CHS Klassendiagramm Control Dependency Subgraph CDS Kontrollflussgraphen der Methoden Data Dependency Subgraph DDS Datenflussgraphen der Methoden und LU DUU wo Object Dependency Subgraph ODS Objektkonstellation als Ergebnis einer abstrak ten Interpretation des CHS CDS und des DDS Der OPDG ist isomorph zum Quellcode der Anwendung und mit Hinblick auf interprozedu rale Kontroll und Datenflussanalysen sowie Alias Untersuchungen entworfen worden Das KBD bildet sozusagen einen f r unsere Zwecke passenden abstrahierenden und unifizieren den Schnitt durch die
173. e und Ziele der Werkzeugunterst tzung bei der Anforde rungsermittlung sowie beim Test ein In Kapitel 20 skizzieren wir das SCORESTOOL unsere Werkzeugkomponenten f r die Anforderungsermittlung Validierung und Verifikation der An forderungsspezifikation und die Testfallgenerierung mit SCORES Kapitel 19 Konzepte Die Tatsache ob zu einer Methode Werkzeugunterst tzung existiert ent scheidet fast schon allein ber deren Einsatz PagSix94 Bei der zunehmenden Komplexit t heutiger Anwendungen ist eine effektive Softwareent wicklung ohne ad quate Werkzeugunterst tzung unm glich so dass die Anwendbarkeit und Akzeptanz neuer Methoden zur Softwareentwicklung entscheidend von der Verf gbarkeit entsprechender Werkzeuge abh ngen CASE Computer Aided Software Engineering Im Allg werden besondere Anstrengungen bei der Anforderungsermittlung nur dann als sinnvoll betrachtet wenn sich die in die Anforderungsspezifikation investierte Arbeit bei nachfolgenden T tigkeiten z B Erstellung und Validierung der Softwarearchitektur oder der Ableitung von Testf llen unmittelbar auszahlt vgl WPJ 98 DHP 99 Wir haben die dementsprechenden M glichkeiten von SCORES in den vorherigen Teilen der Arbeit aufge zeigt Das SCORESTOOL ist im Wesentlichen eine Sammlung von Werkzeugkomponenten welche einerseits die Anforderungsermittlung andererseits auch die Validierung und Verifikation der Anforderungsspezifikation sowie die Generierung v
174. eder Gosling Joy und Steele schreiben hierzu in der Java Sprachspezifikation Overriding is sometimes called late bound self reference a reference invokes a method chosen late at run time based on the run time class of the object referenced by this rather than a method chosen early at compile time based only on the type of this This provides the Java programmer a powerful way of extending abstractions and is a key idea in object oriented pro gramming GJS96 A a this c 1A wenn in A Objekt ausgef hrt 10A B Objekt DI this a 17A a b this a 11A wenn in B Objekt ausgef hrt b Det EC 4 8thtS EL RI sti s7 c Eist E Z 15A S au Le WEE ECK A WEE 6A EN this a 7A B super c 8A Standard Gebrauch von super Is EH E a 5A c d super c 8A Missbrauch von super d e this c 2A e this a 3A super c 4A Abb A 3 Direkte Intra Klassen Intra Objekt Aufruf Interaktionen 249 a al myA c 10B wenn in B Objekt ausgef hrt und myA Class B eee myA a 17B 11B Sw a Pr his IWA a Soni aA TAMBE e SZ b myA a 15B ane KT c di myA e myB e 1B 17B IN B myB d 2B myB myB a 3B di myB e 5B dien tyi El 6B e
175. efinition 5 6 Wir definieren die Inter Use Case Referenzfunktion REF UC gt 2UC zu REF uc Oye su REF 9 LI Wir behandeln Makroschritte ausf hrlich in den Abschnitten 6 3 und 6 4 Zur Notation Im Weiteren werden wir wenn keine Mi verst ndnisse zu bef rchten sind die Begriffe Use Case und Use Case Schrittgraph synonym verwenden Weiterhin bezeichnen wir wie blich mit IN die nat rlichen mit Z die ganzen und mit IR die reellen Zahlen Q Slinteraktion f r se S SA s Interaktion f r die Menge aller Interaktionsschritte ei nes Use Case Schrittgraphen Q F r die Menge aller Folgeschritte eines Use Case Schritts s schreiben wir auch o s und nennen o auch Folgeschrittrelation LI F r se o s bzw s s e o nennen wir s einen Vorg ngerschritt von s und umge kehrt s Nachfolgeschritt von s m Schritte aus der Menge S SE nennen wir innere Schritte des Use Case Schrittgraphen E Schritte aus SE die keinen Nachfolgeschritt haben bezeichnen wir als Blattschritte des Use Case Schrittgraphen Zu den obigen Definitionen folgen nach einem Beispiel noch einige Anmerkungen und Modellierungsregeln Beispiel 5 3 Abb 5 5 zeigt textuelle Spezifikationen der Schritte des Use Case Schrittgra phen Anmelden die Vor und Nachbedingungen sind noch umgangssprachlich formuliert Es ist deutlich zu erkennen dass sich die meisten Bedingungen auf Eigenschaften oder Zu st nde von Dom nenobjekten beziehe
176. egr ten am meisten die hierarchische redundanzvermei dende Modellierung von Use Cases sowie die erstmals anhand der funktionalen Anforderun gen berpr fbare Funktionalit t des Klassenmodells KPW98 Tester sind erstmals in der Lage auch bei der Qualit tssicherung in der Anforderungsermittlung systematische mit entsprechenden Endekriterien untermauerte Pr fverfahren anwenden zu k nnen Winter97 Alles in allem wurden Werkzeuge wie der SCORESTOOL Szenario Browser als ad quate Unterst tzung der entsprechenden T tigkeiten angesehen Kapitel 22 Ausblick 22 1 Laufende Arbeiten Zur Zeit portieren wir wesentliche Komponenten des SCORESTOOLs in entsprechende Stere otype und Skripts f r das kommerzielle CASE Tool Rational Rose Rose98 Die Erwei terungen werden in Diplomarbeiten implementiert und getestet vgl Ritter2000 Wulf2000 Wenn der interne Entwicklungs und Erprobungsprozess abgeschlossen ist ha ben wir eine stabile Basis um Methode und Werkzeug in normalen Entwicklungen zu er proben Es haben sich bereits kommerzielle Softwareentwickler interessiert gezeigt SCORES in ihren Projekten einzusetzen Allerdings sind die Konzepte f r die Aufteilung der Anforde rungsspezifikation in berschaubare Teile in SCORES weitgehend auf das UML Paketkonzept abgest tzt so dass angeregt durch Erfahrungen der Analytiker und Tester beim prakti schen Einsatz der Methode noch mit Erg nzungen oder Pr zisi
177. ehungen auf Sub Use Cases und entsprechende Makroschritte ab Dar 100 Methodisches Vorgehen ber hinaus k nnen Generalisierungen zwischen Use Cases gebildet und auf die entsprechen den Schrittgraphen bertragen werden 8 3 Struktureller Aufbau Sind die betrachteten Use Cases und die sie verfeinernden Schrittgraphen stabil konzentrie ren sich die Analytiker auf das Klassenmodell d h auf die statische systeminterne Infor mation Sie halten zun chst fest welche Verantwortlichkeiten responsibilities vgl WBW 90 die Aufgabe eines Schritts umfasst Hierzu verwenden die Analytiker das Da tenlexikon die textuelle Beschreibung der Aufgabe und die Vor und Nachbedingung Erste Kandidaten f r Verantwortlichkeiten sind z B Q Verben in den textuellen Spezifikationen Q Mehrfach angesprochene Eigenschaften von Dom nen Objekten m Alternative Pfade bzw Ausnahmebehandlungen in den Use Case Schrittgraphen Zur Auswahl von Klassen werden die textuellen Beschreibungen der Use Cases herangezo gen JCJ 92 Zus tzlich k nnen und sollten die in anderen Methoden zur Anforderungs ermittlung gegebenen Hinweise und Ideen zur Auffindung von Klassen beachtet werden wie z B Herauskristallisieren der Schl sselabstraktionen des Anwendungsbereichs durch Haupt wortanalyse vgl Meyer97 Booch94 CoaYou90 CRC Karten WBW 90 Leitbilder Metaphern und Analogien Z llighoven98 und weitere Heuristiken Weiter
178. eilmenge des Klassenbereichs des referenzierten Use Cases Gibt es Referenzen auf nicht existierende Use Cases Gibt es Klassen im Bereich eines Schritts die nicht im Klassenmodell existieren Gibt es Wurzeloperationen die nicht in der Wurzelklasse definiert sind Konsistenz Bezieht sich die Spezifikation eines Interaktionsschritts nur auf Klassen in sei nem Klassenbereich Impliziert die Vorbedingung eines Interaktionsschritts die der Wurzeloperation Stellen die Nachbedingungen der in einer Episode ausgef hrten Operationen die des vom Test Szenarioschritt referenzierten Interaktionsschritts sicher Falls eine Kante e des Schrittgraphen von einem Test Szenario berdeckt ist ist ihre Bedingung c e in der augenblicklichen Objektkonstellation erf llt Sind f r eine Objektkonstellation verschiedene Szenarien eines Use Case m glich Ist die Disjunktion der Bedingungen aller ausgehenden Kanten eines inneren Schritts von der Nachbedingung des Schritts impliziert Sind verschiedene Episoden einer Wurzeloperation f r eine bestimmte Objektkon stellation m glich Ist eine Operation Wurzeloperation verschiedener Schritte in veschiedenen Use Case SChrittgraphen Sind f r eine Operation widerspr chliche Episoden simuliert worden Sind alle Objektkonstellationen vertr glich zum Klassenmodell Treten in den Episoden Nutzungs Anomalien auf create destroy modify modify destroy read Abb 11 1 Exemplarische Checklisten
179. ein spezielles Entwurfsmuster die Fassade s GHJ 94 Kapitel 3 Probleme der Qualit tssicherung f r objektori entierte Anwendungen Things had literally crawled to halt in system testing with each new bugfix generating enough new bugs that almost no forward progress was achieved Glass98 W hrend zu Beginn der 80er Jahre die ersten objektorientierten Programmiersprachen indus triell verwendet wurden und sich ab 1985 methodische Ans tze zur objektorientierten Soft wareentwicklung durchzusetzen begannen blieb die Qualit tssicherung in der Objektorientierung lange Zeit unbeachtet Viele popul re Methodologisten verlieren kein Wort hier ber vgl CoaYou90 WBW 90 WalNer95 Grady Booch schreibt lediglich the use of object oriented design doesn t change any basic testing principles what does change is the granularity of the units tested Booch94 Jacobson behauptet The testing of a system which has been developed with an object oriented method does not differ considerably from the testing of a system developed by any other method JCJ 92 Bei James Rumbaugh lesen wir sogar Both testing and maintenance are simplified by an object oriented approach RBP 91 Die anf nglich oft vertretene Meinung dass objektorientierte Software einen erheblich redu zierten Pr fungsaufwand erfordert und bekannte Pr fverfahren unmodifiziert verwendet werden k nnen hat sich allerdings nicht erf llt Erste Anzeichen f
180. einzelner Bedingungen i Allg nicht entscheidbar sind Dar ber hinaus ist nat rlich auch das Terminierungsproblem in Use Case Schrittgraphen 1 In der Praxis sind die Vor und Nachbedingung des Makroschritts oft gleich denen des referenzierten Use Cases Interpretation und Entscheidbarkeit 79 nicht entscheidbar Wir nehmen hier den pragmatischen Standpunkt ein dass gerade bei der Anforderungsermittlung die konkreten praktisch auftretenden Bedingungen in der Re gel entscheidbar sind und setzen somit im Weiteren stillschweigend voraus dass die Bedin gungen sich nicht widersprechenden d h die Konjunktionen bzw Disjunktionen nicht zu Tautologien degenerieren Wir illustrieren die Interpretation von Use Case Schrittgraphen an einem Beispiel Beispiel 6 1 Abb 5 8 a zeigt den Schrittgraph des Use Case Anmelden im Fallbeispiel Bankautomat Eine erfolgreiche Bearbeitung des Use Cases f hrt zur Identifikation des Kun den und Anzeige der Auswahlm glichkeiten wie es Abb 5 9 a zeigt Die Wirkung des Sze narios ermitteln wir indem wir die Nachbedingungen der im Szenario besuchten Schritte sowie die Bedingungen der durchlaufenen Kanten betrachten Abb 6 9 sowie Abb 6 10 Kontextschritt Karte Einf hren In Use Case Anmelden Nachbedingung Karte im Kartenleser UND Kartenleser gesperrt Interaktionsschritt Karte Lesen In Use Case Anmelden Nachbedingung Karte lesbar UND Code g ltig ODER NICHT Code g ltig ODER NICHT Karte
181. eitung der Aufgabe des referenzierten Use Cases in Abschnitt 6 3 angeben 6 2 Interpretation und Entscheidbarkeit Wir interpretieren einen Use Case Schrittgraphen folgenderma en Beginnend mit der Teil Aufgabe des Startschritts und konkreten Wertebelegungen f r die in der Vorbedingung des Use Cases bzw der des Startschritts vorkommenden Variablen i e Instanzen von Dom nen klassen werden die Teil Aufgaben der Schritte bearbeitet Nach jeder Aufgabe wird gem der im vorigen Abschnitt definierten Semantik anhand des Ergebnisses und damit wie wir in Kapitel 11 zeigen des Zustands in dem sich die betrachteten Objekte des Anwendungsbe reichs befinden einer der Folgeschritte ausgew hlt oder die Bearbeitung des Schrittgraphen ggf beendet Endschritt Jede solcher Bearbeitungen spiegelt sich in einem Szenario wider Die Wirkung eines Szenarios wird durch die Wertebelegungen f r die in der Nachbedingung des Use Cases sowie der aller im Szenario ausgef hrten Use Case Schritte bzw der ber gangsbedingungen der Kanten vorkommenden Variablen konkretisiert Alle so m glichen Szenarien definieren die Semantik des Use Case Schrittgraphen Die Bedingungen werden formal als mehrsortige pr dikatenlogische Ausdr cke z B in OCL angeben Aus der Unentscheidbarkeit der Pr dikatenlogik folgt dass Fragen wie z B der gegenseitige Ausschluss von bergangsbedingungen der ausgehenden Kanten eines Use Case Schritts oder die Erf llbarkeit
182. eizer95 Riedemann97 Wie bei strukturellen Programmtests verwenden wir die Validierungsmetriken auch zur Ge nerierung weiterer Test Szenarien So ist z B die automatische Auswertung von Verzwei gungsbedingungen und Variablendeklarationen zur Generierung von Testf llen und daten bekannt s Beizer90 Riedemann97 Analog zu den Verzweigungsbedingungen werden die Bedingungen der Schritte und Kanten im Use Case Schrittgraph ausgewertet Analog zu den Deklarationen von Variablen werten wir Attribute der Klassen in den Klassenbereichen und die Signaturen der Wurzeloperationen als Eingaben der Testf lle aus 15 3 Methodisches Vorgehen Methodisch gehen wir nach dem Algorithmus Black box Test Abb 15 3 vor Die Reihenfol ge der Tests wird durch die invertierte topologische Sortierung der als azyklischen Graph in terpretierten Inter Use Case Referenzfunktion REF bestimmt s Definition 5 6 und Regel 5 4 6 Die Testskripte werden im Falle der manuellen Testausf hrung aus den Beschreibun gen der entsprechenden Use Case Schritte generiert Wird ein Testwerkzeug eingesetzt so werden die entsprechenden Elemente der Oberfl che mit den dazugeh renden Testdaten in der Skriptsprache des Werkzeugs generiert Als Test Endekriterium wenden wir z B alle Test Szenarien gepr ft oder alle Knoten des Use Case Schrittgraphen berdeckt an Bez glich weiterer auf Prozessmetriken wie der Algorithmus Black box Test Eingabe Anforderungs
183. ekt im Szenario Browser die erreichten Werte der Validierungsmetriken berechnet und angezeigt werden so dass Analytiker und Tester unmittelbar den Fortschritt der Sitzung verfolgen k nnen Abb 20 7 zeigt die entsprechende Sicht des SzenarioBrowsers Validierung 203 Bankautomat Scenario Browser Anmelden A 4 Test Erfolgreiche Anmeldur Geld Auszahlen cenario Geld Einzahlen Geld Transferieren 4 te Lesen PIN Anfordern ofPIN Pr fen ol NI H 7 EI Erfolgreiche Anmeldung Falsche PIN za Wd gt m x z el vials sl Bitte geben Sie Ihre Geheimnummer ein kO Karte Einf hren Protocol zial Abbruch coverage All el 1 8 a Al 5 Karte Lesen 5 PIN Anfordern s Karte Schreiben s PIN Pr fen Bankautomat Scenario Browser Anmelden Geld Auszahlen Geld Einzahlen Geld Transferieren D Karte Einf hren Karte Lesen PIN Anfi Erfolgreiche Anmeldung Falsche PIN D m Lx bx oe Processed by system Actor E r Vollst ndigkeitsmetriken comment Einfache Klassen berdeckung 0 0769231 Pr D Episode ec f Karte Einf hren Klassen berdeckung 0 153846 cu Protocol r Validierungsmetriken coverage Use Case Schritt Uberdeckung 0 888889 1 0 5 Kart
184. ektorientierte Anwendungen nur falls der Compiler dieselbe Programmsemantik hat wie das Validationswerkzeug Nachteile Probleme Ein als korrekt bewiesenes Programm kann dennoch falsche Resultate liefern i Die Semantik der Programmiersprache kann falsch modelliert sein ii Der Compiler das Betriebssystem oder die Hardware k nnen anders als angenommen arbeiten iii Die Ein gabe und Ausgabezusicherungen in ihrer pr dikatenlogischen Form k nnen die eigentliche meist verbale Anforderungsspezifikation des Auftraggebers falsch wiedergeben Riedemann97 Nach diesen Ausf hrungen zur prinzipiellen Notwendigkeit qualit tssichernder T tigkeiten gerade in der objektorientierten Softwareentwicklung betrachten wir nun dynamische Ver fahren zur Pr fung von ausf hrbaren Programmen Hierbei gehen wir zun chst auf struktu relle Tests white box Tests und danach auf Tests gegen die Anforderungs Spezifikation black box Tests ein 3 2 Struktureller white box Test Kommen wir zum white box Test also zu dynamischen Pr fungen gegen strukturelle Eigen schaften der Anwendung bzw des Codes Als Pr fgegenst nde sind in der objektorientier ten Softwareentwicklung nach ihrer Granularit t Q Methoden Klassen Cluster Teilsysteme und LU UU vo die gesamte Anwendung zu unterscheiden vgl Binder96a Siegel96 Sneed96 Obwohl viele Techniken aus der Qualit tssicherung in der prozeduralen bzw modularen
185. el zur polynomialen Transformation von SAT auf GOK 17 4 Interaktionsdaten zum Test Skript Anmeldung OK 19 1 SCORESTOOL Grundlegender Aufbau vgl K sters97 20 1 SCORESTOOL Klassendiagramm Editor 20 2 SCORESTOOL Use Case Spezifikations Editor 20 3 SCORESTOOL Use Case Schrittgraph Editor 20 4 SCORESTOOL Objektkonstellations Editor 20 5 SCORESTOOL Szenario Browser textuelle Sicht 20 6 SCORESTOOL Szenario Browser GUI Sicht 20 7 SCORESTOOL Szenario Browser Metrik Sicht 20 8 SCORESTOOL Episoden Editor 20 9 Testfall und Testdaten Generierung 20 10SCORESTOOL Szenario Browser Szenario Generierung 21 1 SCORES bergang vom Use Case Modell zum Klassenmodell 21 2 SCORES Abdeckung der drei Informationsarten nach PohHau97 21 3 Qualit tssicherung mit SCORES 22 1 Vollst ndiger GUI basierter Systemtest 22 2 Beziehungsgeflechte Modular a und Objektorientiert b 22 4 Funktion PolyKBDj 22 3 Algorithmus Generiere KBD vil 179 180 181 183 185 186 186 196 199 199 200 201 202 203 203 204 205 206 211 212 213 217 240 244 245 Vili Abbildungen Teil I Einleitung Teil Ibesteht aus vier Kapiteln Im ersten Kapitel motivieren wir zun chst die Thematik Qualitatssicherung in der Softwareent wicklung und geben einen berblick ber die Arbeit Danach skizzieren wir in Kapitel 2 die T tigkeiten bei der Entwicklung objektorientierter Software und stellen damit den Bezugsrahmen f r die Arbeit her
186. eme einsetzen Neue andere Ans tze sind zwingend erforderlich In den zur ckliegenden Jahren wurde auch zunehmend deutlich dass die berlegungen zum Testen nicht erst am Ende der Implementierung beginnen d rfen Wenn nicht beispielsweise schon bei der Konzeption der Systemstruktur berlegt wird wie sie die Testbarkeit beein flusst werden nicht testbare Systeme entworfen und realisiert Mario Winter verkn pft in der Arbeit beide Aspekte Test von objektorientierter Software und berlegungen hierzu in der fr hen Entwicklungsphase Anforderungsermittlung Die UML Unified Modelling Language hat sich als Standard Darstellungsmethode f r die Ent wicklung von objektorientierten Systemen etabliert Sie dient Herrn Winter als Grundlage um zu einem fr hen Zeitpunkt Test berlegungen anzustellen und neben der Vorbereitung auf das eigentliche dynamische Testen mittels Programmausf hrung schon in dieser Ent wicklungsphase Fehler und M ngel aufzudecken Er verfolgt somit einen Ansatz der leider noch immer die Ausnahme ist Generell ist f r die Zukunft zu w nschen oder besser zu fordern dass bei neuen Ent wicklungen zur Verbesserung des Softwareentwicklungsprozesses wie es die objektorien tierte Vorgehensweise und auch die Verwendung der UML darstellen die Testaktivit ten bereits fr hzeitig in die berlegungen einbezogen werden Erst wenn diese Forderung kon sequent umgesetzt werden wird hat das Testen und Pr f
187. en e Der entwurfsbasierte Systemtest erzielt eine systematische Uberdeckung der Ent wurfsstrukturen der Anwendung Hierf r schl gt Hetzel die Verwendung entspre chender spezifikationsbasierter Testf lle aus dem Klassen und Integrationstest oder die Modellierung des Transaktionsflusses in der gesamten Anwendung vor und wen det auf das resultierende Modell strukturelle Testverfahren an Sinnvollerweise soll te zun chst die strukturelle berdeckung Code berdeckung oder berdeckung der durch die Verfolgbarkeit identifizierten Entwurfselemente w hrend der anforde rungs und performanzbasierten Systemtests gemessen werden Danach identifiziert der Tester die Teile der Anwendung f r die weitere Testf lle ben tigt werden Der Abnahmetest soll nach Hetzel zeigen dass die Anwendung bereit bzw geeignet f r den Einsatz in der Produktion ist Hierbei fokussieren die Tester wieder auf die An forderungen der Abnahmetest wird in der Regel unter der Regie des Auftraggebers durchgef hrt und soll diesen davon berzeugen dass die Anwendung der Anforde rungsspezifikation entspricht Hsia und Kung geben ein szenariobasiertes Verfahren zur Erstellung eines Benutzungsmo dells usage model f r den Abnahmetest an HsiKun97 Aus der textuellen Anfor derungsspezifikation werden manuell Sequenzen externer Ereignisse events zur Erf llung einer funktionalen Anforderung modelliert Diese Ereignissequenzen sce narios werden in einem Zustan
188. en Regel 6 3 4 Makro Aktoren Die Aktoren eines Makroschritts m ssen konform zu den Akto ren des referenzierten Use Cases sein Y s e S uc SA s Makro gt A s Cy A REF s Im Weiteren wollen wir die Anzahl der Folgeschritte eines Makroschritts nicht beschr nken sonder lediglich das Zusammenspiel von Makroschritten und den von ihnen referenzierten Use Cases regeln Es lassen sich drei F lle unterscheiden Als Erstes betrachten wir den Fall dass ein Makroschritt innerer Schritt ist und somit min destens einen Nachfolgeschritt hat s Regel 5 4 5 F r jedes Szenario des referenzierten Use Cases m ssen wir in der Lage sein einen Folgeschritt des Makroschritts anzugeben mit dem die Aufgabenbearbeitung fortgesetzt werden kann Regel 6 3 5 Makro Innerer Schritt Ist ein Makroschritt s innerer Schritt so muss die Nach bedingung jedes Endschritts sf des referenzierten Use Cases REF s die Bedingung von mindestens einer ausgehenden Kante des Makroschritts implizieren V se S uc s amp SE uc A SA s Makro gt V sfe SE REF s 3ee o s Posts gt c e Ist der Makroschritt s ein Blattschritt also Endschritt ohne Nachfolgeschritte so muss jedes s enthaltende Szenario des Use Cases in einem Endschritt des referenzierten Use Case REF s enden Insbesondere muss also die Nachbedingung jedes Endschritts von REF s die Nach bedingung von s implizieren Regel 6 3 6 Makro Blattschritt Ist ein Makroschritt s Blattschritt und s
189. en Die entsprechenden Elemente der Benutzungsoberfl che ergeben sich im optimalen Fall aus Entwurfsdokumenten vgl KSV96 Ansonsten muss die Zu ordnung aus einer Analyse der Quellcodes der Anwendung manuell oder semi auto matisch mit Werkzeugen zum Test grafischer Benutzungsoberfl chen erfolgen Hierbei hilft eine konsistente Namenswahl welche Elemente der Oberfl che zu ent sprechenden Interaktionsschritten zuordnet Die Typen der atomaren Interaktionspa rameter ermitteln wir dann aus den Attributen der betroffenen Klassen Kontextschritt Jeder Kontextschritt beschreibt eine T tigkeit die vom Aktor manuell bzw maschinell ausgef hrt wird Hier werden externe Abl ufe simuliert und gepr ft wo mit die Grenze zum Gesch ftsprozess bzw Business Process Reengineering erreicht ist vgl HamCha94 Weitere Information ergibt sich ggf aus dem Klassenbereich des Use Case Schritts Makroschritt Jeder Makroschritt wird zu einem Verweis auf ein Testskript der Test Suite des referenzierten Use Cases Wir ermitteln passende Skripts anhand der Vor und Nachbedingung des dem Makroschritt zugeordneten Schritts im Test Szenario und der Test Szenarien des referenzierten Use Cases F r alle drei Schrittarten gilt der Test Setup wird aus der Vorbedingung des Schritts ermit telt f r das Testorakel ziehen wir die Nachbedingung des Schritts und die bergangsbedin gung der entsprechenden Kante im Use Case Schrittgraph heran Wir unterscheiden
190. en EPS Ausgabe Klassen Botschaftsdiagramm KBD V E P Initialisierung 1 V E P Operationen Knoten erzeugen 2 FORALLke K DO Alle Klassen 3 FORALL k oe k operations DO 4 V VU kon Kanten f r die direkt in den Episoden protokollierten Benutzungen erzeugen 5 FORALL ee EPS DO Alle Episoden 6 FORALL s s e e ES DO Alle Episodenschritte 7 IF s o s THEN So ist Nachfolgeschritt von s4 8 ky AK s ko AK s2 Klassen der ausf hrenden Objekte 9 ou WO s4 05 WO s2 P Ausgef hrte Operationen 10 E EU k 01 k2 0 message k IF Vererbung und Polymorphismus ber cksichtigen 11 CALL PolyKBD 12 RETURN V E P END Generiere KBD Abb A 1 Algorithmus Generiere KBD 2 Ist f r zwei Episodenschritte s4 und so mit AK s k sowie WO s 0 und AK s2 ka sowie WO s Oo der Episodenschritt sz Nachfolgerschritt von s4 gilt also So 0 S so f gen wir im KBD eine Botschaftskante Marke message von k4 0 nach k2 05 ein Zeilen 5 10 3 Ist eine Klasse k eigentliche Unterklasse einer Klasse k und berschreibt Operation k2 a die Operation ka so f gen wir eine Vererbungskante Marke inheritance vom Knoten ka a zu Knoten k ain das KBD ein Zeilen 1 5 in Funktion PolyKBDa Abb A 2 Zus tzlich duplizieren wir in diesem Fall alle Kanten die in Knoten k a des KBD enden f r Knoten ka a Diese duplizierte
191. en auch bei der Konzeption von neu en Verfahren und Vorgehensweisen die Bedeutung die es in der Praxis bereits heute inneh lt eine sehr hohe Prof Dr Andreas Spillner Hochschule Bremen Sprecher der GI Fachgruppe 2 1 7 Testen Analysieren und Verifizieren von Software Bremen im Oktober 1999 Danksagung Diese Arbeit entstand in den Jahren 1995 1999 am Lehrgebiet Praktische Informatik III im Fachbereich Informatik der FernUniversit t in Hagen in dem ich nach langj hriger indu strieller und universit rer Projektarbeit in der Software Entwicklung seit 1994 t tig bin Mein Dank gilt allen die mir bei der Erstellung dieser Arbeit zur Seite gestanden haben zuerst und ganz besonders aber meinem Betreuer Prof Dr Hans Werner Six f r die interes sante Themenstellung und seine Bereitschaft mich in den vielen Diskussionen neben der Vermittlung des Sinns f r das Wesentliche auch in die Grundregeln wissenschaftlichen Pu blizierens eingeweiht zu haben Herrn Prof Dr Arnd Poetsch Heffter danke ich f r die spon tane bernahme des Korreferats und seine hilfreichen und kritischen Bemerkungen zur Arbeit Ich danke meinen Kolleginnen und Kollegen an der FernUniversit t f r ihre st ndige Ge spr chsbereitschaft besonders Dr Bernd Uwe Pagel f r die lebendigen Dialoge in den fr hen Stadien der Arbeit und Dr Georg K sters f r seine Geduld und seinen Humor mit denen er mich in unz hligen Diskussionen vor Um und
192. en der textuellen Spezifikation und der OCL optional auch in Smalltalk 80 Code eingegeben und auf entsprechenden Objektkonstellationen ausgewertet werden Abb 20 3 zeigt den Use Case Schrittgraph Editor bei der Bearbeitung des Use Case Schritt graphen Anmelden Zus tzlich zu den Editoren sorgen spezielle Browser sowie Verfolgbarkeitshilfen f r die kon zentrierte Darstellung der gesamten Information f r ein selektiertes Element der Anforde rungsspezifikation So k nnen z B s mtliche Operationen einer selektierten Klasse sortiert nach der Vererbungsstruktur in einer Liste dargestellt werden wobei geerbte Operationen nach den jeweils definierenden Klassen zusammengefasst sind 20 2 Validierung Jede Validierungssitzung bezieht sich auf eine sogenannte Validierungseinheit welche eine Gruppe von zusammenh ngenden Use Cases darstellt Zun chst k nnen spezielle Sichten auf die Anforderungsspezifikation bez glich der Validierungseinheit generiert werden d h die mit den Use Cases der Validierungseinheit interagierenden Aktoren die Schrittgraphen und die in den entsprechenden Klassenbereichen enthaltenen Klassen werden zusammengestellt Daneben werden diese Elemente anhand des aus den Profilen der Use Cases berechneten Ge Validierung 201 xf Bankauto mat Object Diagram Name dieKonten t Glass Konto E Al Hoste i E Zentralrechner Schnittstelle I Muliple with capacity 2 DC
193. en mit den Kantenbedingungen die Auswahl eines n chsten Schritts oder im Falle von Endschritten ggf das Ende der Bearbeitung 6 1 Schritte in Use Case Schrittgraphen Wir beginnen mit Kontext und Interaktionsschritten und behandeln danach Makroschritte In den Beschreibungen ist der betrachtete Schritt jeweils schwarz ohne eingehende Kanten ge zeichnet die f r den Kontext des Schritts im Use Case Schrittgraphen ma geblichen Schritte sind grau gezeichnet und k nnen von beliebiger Schrittart sein oO Kontext oder Interaktionsschritt kein Folgeschritt Abb 6 1 BEGIN Schritt Schritt Aufgabe Schritt SE UseCaseEnde END Schritt Abb 6 1 Semantik 1 einfachster Fall Der Schritt beschreibt eine elementare Aufgabe welche entweder die mit dem Use Case beschriebene Aufgabe erfolgreich beendet oder aber f r den Fall dass die Auf gabe des Use Cases nicht mehr erfolgreich abgearbeitet werden Kann sozusagen Aufr umarbeiten verrichtet Jede Bearbeitung der Aufgabe des Use Cases in der die Teilaufgabe des Schritts ausgef hrt wird muss also mit diesem Schritt enden vgl Re 74 Semantik m gel 5 4 5 Wir deuten diesen Sachverhalt in Abb 6 1 durch das Schl sselwort Use CaseEnde an Kontext oder Interaktionsschritt ein Folgeschritt kein Endschritt Abb 6 2 Schritt BEGIN Schritt Schritt Aufgabe GOTO FolgeSchritt Folgeschritt END Schritt Abb 6 2 Semantik 2 ke
194. en stehen analog zum KBD 4 jeweils in einer Relation P zur urspr nglichen Kante Die Relation P repr sentiert explizit die Tatsache dass Aufrufe der Methode b dy namisch an polymorph substituierbare Objekte der Klassen A und B gebunden werden k nnen Jedes Vorkommen eines Methodenaufrufs der Form this a in einer Methode x der Klasse A wird als mit der Marke this gekennzeichnete Botschaftskante von Methodenknoten x zu Klassen Botschaftsdiagramm der Implementation 173 dem Methodenknoten dargestellt welcher der ersten Deklaration oder Redefinition der Me thode a aufw rts in der Vererbungshierarchie der Klasse A inklusive A entspricht In der gleichen Art und Weise wird jedes Vorkommen eines Methodenaufrufs der Form super a in einer Methode x der Klasse A als mit der Marke super gekennzeichnete Botschaftskante von Methodenknoten x zu dem Methodenknoten dargestellt welcher der ersten Deklaration oder Redefinition der Methode a aufw rts in der Vererbungshierarchie der Klasse A ex klusive A entspricht Nun betrachten wir noch die explizite Erzeugung von Objekten in der Anwendung Sei Aiko Kn ein Konstruktor der Klasse A Jedes Vorkommen eines Methodenaufrufs der Form new Aiko Kn in einer Methode x wird als eine mit der Marke new gekennzeichnete Botschaftskante von Methodenknoten x zu dem Konstruktor Methodenknoten mit entspre chender Signatur in der Klasse A dargestellt Wir nennen solche K
195. en werden von den Analyti kern bzw Testern protokolliert Wir nennen solche protokollierten Szenarien Test Szenarien Hiermit wird deren Wiederverwendung bei der Verifikation und im Test sowie auch das er neute Durchspielen nach nderungen an der Anforderungsspezifikation erm glicht Wir be n tigen zur Werkzeugunterst tzung wieder ein etwas formaleres Ger st Definition 9 1 Ein Test Szenarioschritt ts beschreibt die Ausf hrung eines Use Case Schritts ucs eines Use Case Schrittgraphen uc und ist charakterisiert durch LI eine erl uternde Beschreibung m einen Verweis ts ucs e uc steps auf den ihm zugeordneten Use Case Schritt ucs Q im Fall dass der zugeordnete Use Case Schritt ucs ein Makroschritt ist optional einen Verweis auf ein Test Szenario des referenzierten Use Cases m Entsprechend der bisherigen Definition des Begriffs Szenario als Pfad durch den Use Case Schrittgraphen ist ein Test Szenario eine Folge von Test Szenarioschritten welche die kon krete Ausf hrung eines einzelnen bestimmten Use Cases beschreiben Pr ziser Definition 9 2 Sei uc ein Use Case Schrittgraph Ein Test Szenario zum Use Case Schrittgra phen uc ist ein 4 Tupel TS ST so Se o mit 1 ST ist eine nichtleere Menge von Test Szenarioschritten 2 zue ST ist der Startschritt des Test Szenarios H s S ist der Endschritt des Test Szenarios 4 o ST s gt ST ist die Folgeschrittfunktion die jedem Test Szenarioschritt mit A
196. ends Be ziehung denkbar ist Wir folgen in diesem Beispiel Jacobson vgl Jacobson95 Fallbeispiel Bankautomat 43 USE CASE Geld Abheben Normaler Ablauf Der Bankautomat zeigt eine Begr ssungsmitteilung an Der Bankkunde gibt seine Karte ein Der Bankautomat liest den Code der Karte vom Magnetstreifen und pr ft ihn auf Zu l ssigkeit Ist der Code zul ssig fragt der Bankautomat den Bankkunden nach der pers nlichen Identifikationsnummer PIN Der Bankautomat wartet auf die Eingabe der PIN Der Bankkunde gibt seine PIN ein Ist die PIN korrekt fragt der Bankautomat den Bankkunden nach der gew nschten Transaktion Der Bankautomat wartet auf die Eingabe der Transaktion Der Bankkunden w hlt die Transaktion Geld Abheben aus Der Bankautomat sendet die PIN zum Zentralrechner und fragt nach den Konten des Bankkunden Der Bankautomat zeigt die erhaltenen Kontonummern an und wartet auf die Auswahl ei nes Kontos durch den Bankkunden Der Bankkunde w hlt eine Kontonummer aus und gibt den auszuzahlenden Betrag ein Der Bankautomat sendet die Kontonummer aus und den auszuzahlenden Betrag zum Zen tralrechner Der Bankautomat pr pariert die Banknoten zur Ausgabe Der Bankautomat wirft die Karte aus Der Bankkunde entnimmt die Karte Der Bankautomat druckt den Auszahlungsbeleg Der Bankautomat gibt die Banknoten aus Der Bankkunde entnimmt die Banknoten Alternative Abl ufe Unlesbare
197. enen Minimalanforderungen wie z B 95 ige Anweisungs berdeckung welche die Beantwortung der Frage nach einer ausrei chenden Pr fung dient Unter einem Testfall versteht man eine z B aus der Spezifi kation black box Test oder dem Quellcode der Anwendung white box Test abgeleitete Menge von Eingabedaten inklusive der zugeh rigen Ergebnisse welche die berpr fung einer bestimmten Eigenschaft des Pr fgegenstands erm glicht Test m Geschichte 7 daten bilden die Teilmenge mit welcher der Pr fgegenstand tats chlich getestet wird Ein Testorakel ermittelt automatisch das erwartete Ergebnis eines Testfalls aus der Spezifikation gegen die gepr ft wird Die Klassifikation von Testverfahren erfolgt nach der Granularit t des Pr fgegen stands der Sichtweise auf den Pr fgegenstand und der ggf mit einem validierenden Test nachzuweisenden Eigenschaft Man unterscheidet den Komponententest vom In tegrationstest und Systemtest sowie zus tzlich den unter Einbeziehung der Endbenut zer durchgef hrten Abnahmetest und den nach nderungen am Pr fgegenstand ggf notwendigen Regressionstest Hinsichtlich der Sichtweise auf den Pr fgegenstand gibt es funktionale und strukturelle Verfahren wobei auch Mischformen bzw hybride Tests m glich sind Der Realzeittest weist temporale Eigenschaften des Pr fgegen stands wie z B die Reaktionszeit auf ein Ereignis oder die Ausf hrungsdauer einer be stimmten Operation nach Der Ne
198. ener Use Cases erweitern l sst Bei mehreren Instanzen ei nes Use Cases ist sicher dann eine Synchronisierung notwendig wenn identische Objekte von der Bearbeitung betroffen sind Bei verschiedenen Use Cases k nnen wir ber die Klassenbereiche die Vor und Nachbedingungen und insbesondere die bei der Verifikation protokollierten Episoden m gliche Synchronisationsprobleme erken nen Es k nnten Transaktionsmechanismen und Sperrverfahren bei Datenbanken zur Anwendung kommen Andererseits l sst sich diese Information auch zur gezielten Ableitung von Last und Stresstests verwenden Dazu muss das geforderte Antwort verhalten in der Anforderungsspezifikation enthalten sein Formalisierung Eine weitergehende werkzeugunterst tzte Verifikation der Anforderungs spezifikation setzt eine st rkere Formalisierung voraus die dann auch f r den ber gang in den Entwurf hilfreich w re Aufbauend auf objektorientierten Spezifikationssprachen vgl Poetzsch97 ist ein Verifikationskalk l f r Use Case Zuk nftige Arbeiten und offene Fragen 217 Schrittgraphen denkbar Allerdings ist der bergang zu eher informellen benutzero rientierten Sichten der Anforderungsspezifikation zu wahren Simulation Werden Use Case Schrittgraphen mit Aktivit tsdiagrammen modelliert erlaubt die Ausdrucksst rke der zugrundeliegenden Zustandsmaschinen Statecharts vgl HarNaa96 eine automatische Simulation Solche Simulationen k nnten in Ver bindung
199. enge aller Kantenmarkierungen mit der Bedeutung e inheritance message wie in Definition 22 1 e this Botschaftsaufruf ist dynamisch gebunden und selbstrekursiv e super Botschaftsaufruf ist statisch gebunden e new Botschaft f hrt zur Instantiierung eines neuen Objekts e def modifizierender Zugriff auf eine Variable und e uses nicht modifizierender Zugriff auf eine Variable E S Vx Lix Vist die Menge aller direkten Aufruf und Daten Interaktionen vereinigt mit der Menge aller zwischen Methoden bzw Variablen Features bestehenden Ver erbungsbeziehungen Wir bezeichnen mit EC E x EL x m j n mitj e mes sage this super new die Menge der Aufruf Interaktionskanten des Klassen Botschaftsdiagramms F r j e message this super new ist m j n Er wenn in Methode m ein Aufruf der Methode n erfolgen kann Ep CE xe Ep amp x m j n mitj def uses bezeichnen wir als die Menge der Daten Interaktionskanten des Klassen Botschaftsdiagramms F r j e def uses ist m j n Ep wenn Variable m innerhalb der Methode n definiert wird bzw in Methode m eine Benutzung der Va riablen n erfolgen kann Ist j inheritance dann ist m j n Er wenn Methode m Schnittstelle und oder Implementation von Methode n erbt bzw die Definition der Variablen m von der Definition der Variablen n berschrieben wird Ep Er und Ey partitionieren E Ey ist irreflexiv und asymmetrisch Bei einfacher Vererbung ist Ey dar ber hinaus
200. engesetzten Ausdrucks ndert Bez glich der Nachbedingungen wollen wir auch m gliche Verletzungen erreichen wir befinden uns ja auf der Jagd nach Fehlern Wir versuchen laut der minimalen Mehrfachbe dingungs berdeckung Testf lle f r folgende Wahrheitswert Kombinationen der Terme in den Nachbedingungen zu finden oO ODER verkn pfte Terme versuchen wir zu false false als negativen Testfall sowie zu true false und false true als positive Testf lle zu erzwingen LI UND verkn pfte Terme versuchen wir zu true true als positiven Testfall und true false sowie false true als negative Testf lle zu erzwingen Q Die beiden Terme einer Implikation versuchen wir dementsprechend zu false false und true true als positive Testf lle sowie true false als negativen Testfall zu er zwingen Q Bei geschachtelten Ausdr cken werden alle Belegungen gepr ft bei denen die nde rung des Wahrheitswerts eines Terms den Wahrheitswert des zusammengesetzten Ausdrucks ndert Das Vorgehen erl utern wir in Beispiel 12 2 weiter unten F r die negativen Testf lle m ssen wir bei korrekten und vollst ndigen Spezifikationen die Vorbedingung verletzen da sonst die Nachbedingung ja garantiert wird Wir setzen voraus dass f r alle Use Cases und Use Case Schritte bzw Kanten die minimale Mehrfach Bedingungs berdeckung erreicht 140 Verifikationsmetriken wird Dies f hrt nat rlich in Abh ngigkeit von der
201. ente des Klassenmodells doe Klassenbeteiche vr s an au Ba eine 7 3 Wurzelklasse und Wurzeloperation 2222222020 ee eee eee 7 4 SCORES Metamodell ID a Nd EE 2 2 Ur AN a 7 5 Vollst ndigkeitsmetriken 2 22 2202 eneeeeeeeeneeene nenn 7 6 Exkurs Use Case Schrittgraphen und Aktivit tsdiagramme 8 Methodisches Vorgehen 8 1 Funktionale Zerlegung 70 SNE NEE hate a ANN 8 2 Externes Verhalten usteet 8 3 Struktureller Aufbau u Sa A una 8 4 Internes Verhalten 3209 2 24 elek Eh ee 8 5 Administrative T tigkeiten eke eee nee 8 6 ZWISCHENFAZIE eesse ed ak sale Bla Drive III Validierung und Verifikation der Anforderungsspezifikation 9 Validierung 9 1 Reviewtechniken cee eee nnn nes 9 2 Funktionale Zerlegung e SCENE ose sa a 9 3 Externes Verhalten 0 44088 ENEE a E Bel sn Rh 9 4 Scores Metamodell OU 10 Validierungsmetriken 10 1 Use Case Schritt berdeckung 4 eo 22 EE re 10 2 Use Case Kanlen berdscking soo sn ea bow ee Ba Bee 10 3 Use Case Szenario Uberdeckung 0 0 0c cece cece eens 10 4 Grenze Inneres und Pfad berdeckung 0 0 00 e eee 11 Verifikation 11 1 Struktureller Aufbau 2 22 elt ede ee Frl 11 2 Externes vs internes Verhalten Sek are EUREN ted e d UR Episoden cere eeror aenor EE EE EI EISE a oe ea aka ae ee wei 11 5 Objektorientierte Walk Throughs 11 6 Vollst ndiges Scores Metamodell 2 22 2202 eee eee
202. er Implementation m verfolgen lassen Bezeichnen wir mit J die noch nicht ausreichend berdeckten Elemente der Implementation und mit 74 die entspre chenden Elemente des Dom nen Klassenmodells m4 so ermitteln wir J zu I Ire IER e I refinedBy x y Zu diesen Elementen des Dom nen Klassenmodells ermitteln wir ber die Kopplung von Use Cases und dem Klassenmodell der SCORES Anforderungsspezifikation alle Use Cases welche noch nicht berdeckte Elemente der Implementation ber hren Mit den Techniken aus Teil III spezifizieren wir f r diese Use Cases ggf neue Test Szenarien und leiten weitere Testf lle ab Hierbei konzentrieren wir uns auf solche Interaktionsschritte zu deren Wurzeloperationen sich nicht berdeckte Elemente der Implementation ggf tran sitiv ber das KBDy zur ck verfolgen lassen Mit den so abgeleiteten Testf lle verbessern wir gezielt die strukturelle berdeckung K nnen auch mit dieser Vorgehensweise einige Elemente der Implementation nicht ber deckt werden so m ssen f r diese Elemente white box Tests abgeleitet werden Beizer90 Riedemann97 Bez glich dieses Falles erinnern wir auch an die in Abschnitt 16 2 genann ten M glichkeiten nicht verfolgbarer Elemente der Implementation Abb 16 5 verdeutlicht die Vorgehensweise ber die Verfolgungsrelation 1 ermitteln wir alle Elemente der Anforderungsspezifikation die nicht ausreichend berdeckten Elementen der Implementation entsprechen
203. er Schachtelungsstufe die gleiche Aufmerksamkeit ge widmet PagSix94 Nach Riedemann97 ist die minimale Mehrfach Bedingungs berdeckung genau dann er reicht wenn f r jeden boole schen Ausdruck alle Belegungen der Terme erzwungen wurden Minimale Mehrfach Bedingungs berdeckung 139 bei denen die nderung des Wahrheitswerts eines Terms den Wahrheitswert des zusammen gesetzten Ausdrucks ndert Beginnen wir mit der Verifikation der Vorbedingungen Da positive Testf lle die Vorbe dingungen einhalten m ssen wenden wir die minimale Mehrfach Bedingungs berdeckung zun chst eingeschr nkt auf insgesamt erf llte Vorbedingungen an Q Liegt ein Term A vor erzeugen wir einen Testfall mit A true liegt ein negierter Term NICHT A vor erzeugen wir einen Testfall mit A false Q Im Falle von ODER verkn pften Termen A und B muss jeder Term einmal den Wert true und einmal den Wert false erhalten wir erzeugen also f r eine Vorbedingung vom Typ A ODER B zwei Testf lle welche die Belegungen A true B false und A false B true erzwingen Q Bei UND verkn pfter Terme brauchen wir nur einen Testfall mit A true B true zu erzeugen Q im Falle einer Implikation WENN A DANN B zwei Testf lle mit A false B false und A true B true Q Bei geschachtelten Ausdr cken werden alle die Vorbedingung erf llenden Belegun gen gepr ft bei denen die nderung des Wahrheitswerts eines Terms den Wahrheits wert des zusamm
204. er Tester bis jetzt vor unbeantworteten Fragen wie z B Q Q Welche konkreten Abl ufe sind f r jeden Use Case zu testen Mit welchen von der Benutzungsoberfl che angebotenen Operationen ist eine gege bene Anforderung auszuf hren und zu berpr fen Wie ist die Anwendung zu initialisieren d h wie kann der f r die zu testende Anfor derung erforderliche Zustand der Anwendung und oder der persistenten Objekte her gestellt werden Welche Operationen des Dom nen Klassenmodells entsprechen welcher Funktionali t t und welchen Operationen der Implementation Wie kann der Zustand der Anwendung und oder der persistenten Objekte nach der Testausf hrung beobachtet werden 40 Probleme der Qualit tssicherung f r objektorientierte Anwendungen Q In welchen Zust nden m ssen sich die Anwendung und oder die persistenten Objekte nach der Testausf hrung befinden Zusammenfassend halten wir fest dass f r die Qualit tssicherung in der objektorientierten Softwareentwicklung bisher gr tenteils Verfahren f r den dynamischen Klassentest ent wickelt wurden Beim funktionalen Test der Anwendung gegen die Anforderungsspezifika tion bleiben Verfahren aus der prozeduralen Welt nur zum Teil relevant denn objektorientierte Anwendungen m ssen zunehmend gegen objektorientierte Anforderungs spezifikationen getestet werden Zu statischen Pr fungen gibt es f r objektorientierte Spezi fikationen so gut wie keine methodische Un
205. er die von einem Use Case betroffenen Teile der Anwendung bzw des strukturellen Modells h chstens als Kommentar angeben Aufgrund des relativ ho hen Abstraktionsgrads tritt insbesondere die Problematik auf dass die Funktionalit t eines Use Cases sich nicht unmittelbar auf einzelne Dom nenklassen und dann ber den Entwurf in die Implementation verfolgen l sst Dies hat zu der Ansicht gef hrt dass solche Funktiona lit t ganz vom Klassenmodell getrennt und auf freie Operationen Lauesen98 bzw Kon troll Objekte JCJ 92 abgebildet wird sicherlich eine Ansicht die von vielen Vertretern der objektorientierten Softwareentwicklung nicht geteilt wird vgl CoaYou91 Meyer97 WalNer95 WBW 90 Struktur Betrachten wir als n chstes den Zusammenhang zwischen einem Use Case als Klasse und einem Szenario als Use Case Instanz vgl JCJ 92 Ein Use Case soll alle Szenarien aus dr cken also alle m glichen konkreten Abl ufe zur Erledigung der Aufgabe unter Benut zung der Anwendung Jacobson sieht jedoch das Instanzieren eines Use Cases im Wesentlichen als die berf hrung der textuellen Spezifikation in jeweils ein Interaktionsdi agramm f r den normalen Ablauf und die alternativen Abl ufe Insofern m ssen alle m gli chen Abl ufe auch textuell spezifiziert sein die textuelle Spezifikation beinhaltet also dieselbe Information wie die Menge aller Interaktionsdiagramme bzw Szenarien Ein Inter aktionsdiagram
206. er eingef hrten Begriffe Klassenbereich Wurzelklasse und Wurzeloperation betrachten wir den Use Case Anmelden des Bankautomaten Abb 7 3 skizziert das im Weiteren zugrundeliegende teilweise unvollst ndige Klassenmodell Den Use Case Anmelden zusammen mit den in seinem Klassenbereich enthaltenen Klassen zeigt Abb 7 4 Die Kopplung von Use Case Schrittgraph und Klassenmodell beginnt mit dem Kontextschritt Kreditkarte Eingeben Dieser setzt auf den ersten Blick lediglich das physikalische Vorhan densein des funktionsbereiten Kartenlesers im Bankautomaten voraus Wir ordnen diesem Schritt also den Klassenbereich Kartenleser zu Der Interaktionsschritt Kreditkarte Lesen ZentralrechnerSchnittstelle Kartenleser Transaktion Zustand Zustand Zustand Start Ende Betrag gibKonto leseDaten pruefePIN schreibeDaten zieheKarteEin werfeKarteAus erwarteKarte Kontonummer IdentCode BLZ Datum AnzahlVersuche GesamtBetragDatum KreditLimit beginne commit end pruefePIN fuerePlanAus rollback Bedienpult leseAuswahl zeigeGruss lesePIN leseKonto leseBetrag Geldeingabe Auszahlung Einzahlung Belegdrucker druckeZeile pruefe pruefe Kontonummer BLZ Zustand Kontotyp Kreditlimit Saldo Geldausgabe berweisung eroeffne schliesse
207. er97 Dorothee Behringer Modelling Global Behavior with Scenarios in Object Oriented Analysis Dissertation Dept of Informatics Ecole Polytechnique Feder ale de Lausanne Swiss 1997 Beizer90 Boris Beizer Software Testing Techniques 2 Aufl Van Nostrand Reinhold New York 1990 Beizer94 Boris Beizer Testing Technology The Growing Gap American Programmer Jahrg 7 Nr 4 1994 Beizer95 Boris Beizer Black Box Testing J Wiley amp Sons New York 1995 Berard93 Edward V Berard Essays on Object Oriented Software Engineering Prentice Hall Englewood Cliffs New Jersey 1993 BerMar93 Antonia Bertolino Martina Marr Automatic Generation of Path Covers Based on the Control Flow Analysis of Computer Programs IEEE Transactions on Soft ware Engineering Jahrg 20 Nr 12 1993 S 885 899 BHJ 98 Rainer Burkhardt Peter Hruschka Nicolai Josuttis Bernd Kahlbrand Arnulf Mester Horst Neumann Bernd Oestereich Markus Reinhold UML auf gut Deutsch OBJEKTspektrum Nr 5 Sep Okt 1998 S 48 49 Aktuelle Version verf gbar unter http www system bauhaus de uml 220 Binder94 Robert V Binder Design for Testability in Object Oriented Systems Communica tions of the ACM Jahrg 37 Nr 12 Sep 1994 S 87 101 Binder95 Robert V Binder The FREE Approach to Testing Object Oriented Software Technischer Report RBSC Corporation 1995 Binder96a Robert V Binder Testing Object Oriented Software A Survey Software Testi
208. erden in der Zeit O ES eingef gt Zeilen 5 10 Funktion Poly KBDA l uft in der Zeit O I OPS Insgesamt ergibt sich eine Zeitkomplexit t von O l OPS 1 ES F r die OPS Knoten ergibt sich f r die Generierung des KBD eine Raumkomple xit t von O I OPS da jeder Knoten h chstens zu OPS 1 anderen Knoten ber Botschaftskanten und zu h chstens einem anderen Knoten ber eine Vererbungskante adjazent sein kann Eine auf den Nachfolgerschritt Relationen der Episoden basierende partielle Ordnung auf den Operationen im Dom nen Klassenmodell kann u a zur Planung der Entwicklungs und Testt tigkeiten auf der Basis des KBD verwendet werden s Winter98 A 2 Interaktion in objektorientierten Anwendungen In diesem Abschnitt untersuchen wir welche internen Interaktionen in objektorientierten An wendungen prinzipiell m glich sind Da im Folgenden keine Verwechslungen mit externen Interaktionen zu bef rchten sind reden wir kurz von Interaktionen und meinen interne Inter aktionen 240 Klassen Botschaftsdiagramme Zur Einstimmung erinnern wir zun chst an die Grundkonzepte der modularen Programmie rung vgl Parnas72 s auch PagSix94 Daten und Funktionen die im Kontext der Ge samtaufgabe eine besondere Affinit t besitzen werden zu Moduln und diese wiederum zu Teilsystemen vereinigt die als Komponenten der Systemarchitektur jeweils eine klar abge grenzte und pr zise definierte Teilaufgabe
209. ereich des Objektorientierte Walk Throughs 133 Vorg ngerschritts so wollen wir wissen in welcher Klasse die ausgef hrte Operation defi niert ist Es liegt nahe alle geerbten Eigenschaften quasi mittels Copy amp Paste einfach in die erben de Klasse zu bernehmen vgl Binder95 Bei redefinierten Operationen sorgen wir dabei durch geeignete Umbenennungen daf r dass sowohl die geerbte als auch die redefinierte Operation innerhalb der Klasse sichtbar sind vgl PalSch94 LI Wird eine Operation in einer Unterklasse berschrieben so wird dem Namen der Ope ration der Name der definierenden Klasse vorangestellt und durch abgetrennt Jede Benutzung der in einer Oberklasse definierten und in der kontextgebenden Klasse ber schriebenen Operation wird dann analog behandelt Q Der Name der Oberklasse wird dem Botschaftsnamen vorangestellt und durch ab getrennt oO Die Operation mit dem so entstehenden Bezeichner wird benutzt Im Kontext aufrufender Objekte ist nur die redefinierte Operation sichtbar Die umbenann te Operation kann also nicht in Episodenschritten denen Instanzen anderer Klassen zugeord net sind aufgerufen werden Dieses auch als Abflachen der Vererbungshierarchie bekannte Vorgehen flattening vgl Binder95 f hrt im schlimmsten Fall zu einer K fa chen Vervielf ltigung einer Operation 11 5 Objektorientierte Walk Throughs W hrend der Validierung noc
210. erenzierten Use Cases hier Anmelden symbolisieren probe vgl JCJ 92 HitKap98 T 7 Be Bankkunde ATM Zentralrechner Geschl d Anmeldung Customer ATM Zentralrechner Karte Einf hren Karte Lesen ra gt Auswahl Anfordern a a PIN Anfordern 4 gt Betrag Anfordern PIN Pr fen Abe Pr fen a gt cll Sp 4 Auswahl Anzeigen Karte Schreiben ile eg Karte Anbieten L er Karte Entnehmen Geld Entnehmen L Geld Anbieten a b Abb 5 9 Erfolgreiche Szenarien zu den Use Cases Anmelden a und Geld Abheben b Schritte in Use Case Schrittgraphen 73 Kapitel 6 Semantik Wir skizzieren in diesem Abschnitt eine operationale oder treffender gesagt ablaufbe zogene Semantik f r Use Case Schrittgraphen Hierzu geben wir analog zu Berechnungen in Flussdiagrammen vgl Weihrauch87 zu den m glichen Schrittarten und der Anzahl der Folgeschritte keiner einer oder mehrere Nachfolgeschritte in Pseudocode an welches Ver halten der Schritt im Kontext eines Use Case Schrittgraphen bewirkt Umgangssprachlich k nnen wir die Semantik der Schritte im Use Case Schrittgraph wie folgt beschreiben Die Vorbedingung eines Schritts gibt die minimalen Voraussetzungen an mit der die Bearbeitung seiner Aufgabe begonnen werden kann Die Nachbedingung bestimmt zusamm
211. erf llt wird Da diese Belegung auch die Bedingung der Kante vom Schritt Karte Lesen zum Schritt PIN Anfordern erf llt setzt letzterer das Szenario A fort Interaktionspara 144 Verifikationsmetriken meter dieses Schritts ist die PIN als vierstellige Folge von Ziffern wobei wir in diesem Sze nario von der Eingabe der richtigen PIN ausgehen Auf diese Weise fahren wir fort bis ein Endschritt des Schrittgraphen erreicht und keine Fortsetzung m glich ist Da wir die Nachbedingung des Startschritts Karte Einf hren nur durch mechanische Einwir kung verletzen geknickte Karte und insbesondere die beiden Terme der Konjunktion nicht getrennt beeinflussen k nnen betrachten wir diesen Schritt als ausreichend getestet und konzentrieren uns in Szenario B auf den zweiten Konjunktionsterm der Nachbedingung des Schritts Karte Lesen also Kartenleser gesperrt UND NICHT Karte lesbar Als Test Eingabe datum gehen wir von einer entmagnetisierten nicht lesbaren Karte aus so dass der zweite Term erf llt wird Szenario B endet dementsprechend mit dem Endschritt Karte Einziehen In einem weiteren Szenario C wird jetzt noch die Eingabe einer lesbaren aber f r diesen Auto maten nicht g ltigen Karte gepr ft Die Konjunktionsterme der Nachbedingung des Schritts Karte Lesen k nnen wir nicht gleichzeitig zu false zwingen und erachten somit auch diesen Schritt f r ausreichend getestet Entsprechend betrachten wir mit den Szenarien D und E die
212. erhaltende nderungen sog Refaktorisierungen Opdyke92 Diese sind automatisch auch auf die SCORES Ele mente fortsetzbar und erleichtern so die Wartung der Testf lle 154 Verfolgbarkeit f klasse verwenden In allen anderen F llen sind SCORES Elemente zun chst nicht be troffen Entfernen einer Vererbungsbeziehung Abb 13 4 d Haben Ober und Unterklasse Entsprechungen im Dom nen Klassenmodell und sind f r die Unterklasse eigene auf geerbte Elemente der Oberklasse zur ckgreifende SCORES Elemente definiert wor den so werden die SCORES Elemente entsprechend ge ndert L schen aller geerbten Elemente und erneut validiert und verifiziert Dar ber hinaus m ssen Test Szenarien der Oberklasse die mit in der Unterklasse redefinierten Operationen beginnen f r die Unterklasse dupliziert angepasst und erneut durchgespielt werden vgl PerKai90 HMGF92 In allen anderen F llen sind SCORES Elemente nicht betrof fen Einf gen einer Assoziations Aggregations oder Kompositionsbeziehung Abb 13 4 e Haben beide Beziehungspartner Entsprechungen im Dom nen Klassenmodell so sind alle Episoden zu pr fen in denen die neu in Beziehung gesetzten Klassen vor kommen Ggf sind die Signaturen von Operationen zu beschr nken da die benutzte A HERSE t b Kar Abb 13 4 Einfache strukturelle Entwurfs nderungen Elemente der SCORES Anforderungsspezifikation 155 Klasse jet
213. eringeren Abstraktionsgrades oft keinen direkten Bezug zu extern beobachtbaren Aufgaben und Abl ufen In anderen Worten sind die funktionalen Anforderungen oft ber die Klassen und Operationen hinweg verwischt Es ergibt sich ebenso wie bei den in ER und Datenflussdiagrammen getrennten struktu rellen und funktionalen Sichten der strukturierten Analyse vgl Yourdon89 eine L k ke die sich in Fragestellungen wie z B Erf llt das Klassenmodell die funktionalen Anforderungen oder Wie spezifiziert man die funktionalen Anforderungen im Klassen modell niederschl gt Zur Beantwortung solcher Fragen werden wir in den n chsten beiden Kapiteln Use Case Schrittgraphen und Klassenmodelle koppeln Kapitel 7 Kopplung von Use Cases und Klassenmodell No approach can be complete unless it accounts both for the function and the objects parts Meyer97 Wir spezifizieren mit Use Cases bzw Use Case Schrittgraphen verhaltensbezogene funkti onale und ablaufbezogene Aspekte der Anforderungen Strukturelle bzw datenbezogene Aspekte werden im Klassenmodell spezifiziert Da die Anforderungsermittlung auf den Soll Zustand abzielt beschreiben Dom nenklassen im Kontext dieser Arbeit Objekte die wir in dem betrachteten Gesch ftsprozess nach der Einf hrung unserer Anwendung finden Ad quat zu den Zielen der Anforderungsermittung spezifiziert auch das Dom nen Klassenmo dell das Was der Anwendung Operatio
214. errard94 MMM 97 PTA94 gew hrleistet ist muss das resultieren de Modell die Ableitung benutzerfreundlicher Sichten erlauben vgl Hasselbring98 Z llighoven98 Die in verschiedenen Modellen wie z B Use Cases und Klassenmodellen spezifizier ten Aspekte der Anforderungen m ssen gegeneinander gepr ft werden k nnen Die Anforderungsspezifikation muss f r den bergang zu formalen Spezifikationen im Entwurf sowie zur Unterst tzung von Testt tigkeiten ausreichend formal bzw zu mindest formalisierbar sein Der Pr zisierungsgrad bei der Anforderungsspezifikation muss z B die Ableitung von Testf llen und die Anwendung von Testendekriterien erm glichen s z B Myers79 Beizer90 Riedemann97 Zur Automatisierung von Tests sind z B umgangssprachlich beschriebene Testf lle z B JCJ 92 nicht ausreichend Wir zitieren Riedemann Das spezifikations und entwurfsorientierte Testen leidet darunter dass meist eine formale Basis fehlt Daher sind formale Spezifikations und Entwurfsverfahren zu entwickeln bzw f r das Te sten nutzbar zu machen z B zum m glichst automatischen Generieren der Testf lle und Testda ten Riedemann97 Wie wir in Kapitel 4 gezeigt haben wurden einige dieser Anforderungen an ein Konzept zur Verfeinerung und Pr zisierung von Use Cases bereits in anderen Arbeiten ber cksichtigt Al lerdings deckt kein bekannter Ansatz s mtliche Anforderungen ab Da die verschiedenen An s tze zudem gr
215. ers79 Beizer90 Motivation und berblick QS Theorie Testbarkeitseigenschaften amp L Fehlerhypothesen amp Fehlerklassifikationen Testmodelle 42 Ad quatheitskriterien 40 L Testkriterien Testendekriterien 40 Verfahren Dynamischer Test Komponententest I r Funktional m Integrationstest I Systemtest f 1 Strukturell Inspektionen Reviews 4 A bnahmetest Zu i Hybrid I Statische Analysen amp Reese Realzeittest L Debugging H Nebenl ufigkeitstest I Lasttest Werkzeuge Zi Stresstest GUI Test a Evaluierung Experimente L Benutzbarkeitstest Erfahrungsberichte 4 Prozess Management amp Abb 1 1 Gebiete der Qualit itssicherung gegenst nde abgeleitet werden Ein Ad quatheitskriterium gibt f r eine Menge von Testf llen bzw Testdaten an ob sie den Pr fgegenstand bzgl einer Fehlerhypothese oder eines Testmodells ausreichend testet vgl Weyucker86 Ein algorithmisch auswertbares Ad quatheitskriterium welches z B in einer prozentualen Angabe m n det bezeichnen wir auch als Testkriterium So ist z B die Anweisungs berdeckung ein Testkriterium zum Testmodell Kontrollflussgraph bzw dem Testverfahren Kontrollflussbasiertes Testen vgl Myers79 Ein Testendekriterium oder Ab bruchkriterium ist eine Menge von Testkriterien sowie ggf weiteren Kenngr ssen zu sammen mit entsprechenden vorgegeb
216. ersonen Objekten mehr oder weniger generisch beschrieben werden wobei die Au toren sagen Introducing instances into scenarios has the drawback of doubling their size and possibly intro ducing irrelevant details but make scenarios more concrete which may make requirements dis cussions easier and help resolve conflicts more quickly Scenario analysis and the inquiry cycle model complement each other PTA94 Interessant ist die Verfolgbarkeit der Anforderungsspezifikation zu den Informations quellen Vor Verfolgbarkeit vgl Kapitel 13 Hierzu werden nderungen der Anfor derungen mit ihren treibenden Fragen und Antworten verkn pft Vollst ndige Szenarien bei Potts et al entsprechen Use Cases Episoden verkapseln komplexere Abl ufe und dienen zur hierarchischen Strukturierung der Anforderungsspezifikation Da Potts et al die Objekt Identifikation eher als Entwurfst tigkeit sehen werden strukturelle Aspekte nicht betrachtet Cockburn klassifiziert zun chst bekannte Use Case Modellierungsans tze anhand der vier Dimensionen Zweck purpose Inhalt contents Pluralit t plurality und Struktur structure Cockburn97 Er schl gt dann selbst ein hierarchisches Use Case Modell zur Anforderungsspezifikation vor Zweck in dem Use Cases normsprachlich mo delliert Inhalt mehrere Szenarien in einem Use Case erfasst Pluralit t und Use Ca ses semiformal strukturiert werden Struktur Die Struktur der Use
217. erungen hinsichtlich der Verwaltung gro er Anforderungsspezifikationen zu rechnen ist Weitere laufende Arbeiten betreffen die Wiederverwendung und die weitergehende Auswer tung von Use Case Schrittgraphen Wiederverwendung Im Hinblick auf die Wiederverwendung von Use Case Schrittgraphen untersuchen wir zur Zeit sogenannte Analyse Muster die als wiederverwendbare Teile von Anforderungsspezifikationen bisher haupts chlich f r die strukturellen As pekte angegeben wurden vgl Fowler97a Wir wollen solche Muster mit den ent sprechenden Use Case Schrittgraphen erweitern und als generische Minispezifikationen katalogisieren bzw im SCORESTOOL verf gbar machen bzgl der Werkzeugunterst tzung f r Entwurfsmuster s auch PagWin96 Objektkonstellationen Die Vor Nach und Kantenbedingungen der Use Case Schrittgra phen werden in Heuristiken zur Generierung von Objektkonstellationen verwendet s Abschnitt 17 2 Hier wird zur Zeit der Einsatz verschieden ausdrucksstarker Teilmen gen von Programmiersprachen zur Formulierung und automatischen Auswertung der Constraints untersucht 216 Ausblick UML Aktivit tsdiagramm Die in Abschnitt 7 6 aufgeworfenen Probleme von Aktivit tsdi agrammen werden zur Zeit von der UML Task Force der Object Modeling Group OMG bearbeitet vgl OMG AT98 Wir untersuchen die notwendigen nderun gen des UML Metamodells bzw der UML Semantik um das von uns vorgeschlagene Konze
218. es Meyer97 als die den Knoten des KBD entsprechende Elemente der Implementation aus also wie beim KBD Metho den und zus tzlich auch Klassen und Instanzvariablen Im Weiteren bezeichnen A und B Klassen Falls Verwechslungen ausgeschlossen sind sagen wir im Kontext des KBD einfach Methodenknoten A a anstatt der die Methode a in Klas se A repr sentierende Knoten mit dem Namen lt A a gt Wir betrachten zun chst Aufrufe von Methoden direkte Aufruf Interaktionen Eine einfache gerichtete Botschaftskante verbindet Methodenknoten A a mit Methodenknoten B b wenn bei der Ausf hrung von a in einer Instanz der Klasse A eine Botschaft zu einem Objekt der Klasse B gesendet werden kann welche die Ausf hrung der Methode b bewirkt In anderen Worten benutzt Methode A a Methode B b Als n chstes beziehen wir die Vererbung den Polymorphismus sowie die damit verbundenen Schl sselworte bzw Konstrukte this und super zur Steuerung der dynamischen Methoden bindung mit ein Zun chst einmal f gen wir eine als Vererbungskante bezeichnete gerichtete mit der Marke inheritance gekennzeichnete Kante von Methodenknoten B b zu Methoden knoten A b wenn Klasse B Unterklasse von A ist d h Methode B b redefiniert Methode A b Zus tzlich duplizieren wir in diesem Fall alle unmarkierten Botschaftskanten die in Metho denknoten A a enden f r den Methodenknoten B b Die duplizierten und umgeleiteten Botschaftskant
219. eser zu Beginn des Test Szenarios m Wann wird eine Instanz der Klasse Transaktion erzeugt m Welchen Zustand hat die Instanz der Klasse Transaktion e nach der Erzeugung e nach den einzelnen Szenarioschritten Vollst ndige und polymorphe Operations berdeckung 145 e nach dem Szenario Q Wie kann die Instanz der Zentralrechnerschnittstelle die PIN pr fen Q Sind die resultierenden Objektkonstellationen sinnvoll oO Wo manifestiert sich der Zustand des Bankautomaten Wir simulieren noch eine Episode zum Szenarioschritt PIN pr fen Test Szenario Online Anmeldung Abb 10 3 F r den Fall des verf gbaren Zentralrechners pr ft dieser die einge gebene PIN sowie ggf eine vorherige Sperrung der Karte Die in der Wurzelklasse Transak tion definierte Operation pr fePIN benutzt die gleichnamige Operation der Klasse ZentralrechnerSchnittstelle die der Transaktion ber eine Beziehung bekannt ist Wie diese Operation in der ZentralrechnerSchnittstelle mit dem zentralen Bankrechner kommu niziert sei an dieser Stelle nicht betrachtet die Operation ist also ein Blatt der Episode Im betrachteten Test Szenario habe der Benutzer die richtige Geheimnummer eingegeben Sze narioschritt PIN anfordern Die Zentralrechner Schnittstelle best tigt dies die darauf fol gende Standard Operation modify beschreibt das R cksetzen des Attributs AnzahlVersuche des die Kreditkarte darstellenden Objekts der Klasse Karte Abb 1
220. f der linke Seite des Interaktionsdiagramms an der Anwendungsgrenze beschreiben entsprechende Texte aus der Use Case Beschreibung den Ablauf bzw die Ereignisse Jedem am Use Case beteiligten Objekt wird eine vertikale Linie im Diagramm zugeordnet vertikale Rechtecke auf diesen Linien veranschaulichen die Ausf hrung einer Operation Horizontale Pfeile spiegeln die im Verlauf einer Operation gesendeten Botschaften wider die dement sprechend zur Ausf hrung einer Operation im Zielobjekt der Botschaft f hren Beispiel 2 1 Abb 2 6 zeigt exemplarisch ein Interaktionsdiagramm f r den Ablauf der Ope ration push in einem Objekt der Klasse ArrayStack vgl Meyer97 Array ArrayStack 1 push setSize Abb 2 6 Interaktionsdiagramm der Operation ArrayStack push 24 Entwicklungst tigkeiten 2 2 Entwurf und Implementation Beginnend mit einigen berlegungen zur Software Architektur betrachten wir in diesem Ab schnitt exemplarisch den Entwurf objektorientierter Software mit Jacobsons OOSE object oriented software engineering der Methode des Objectory Software Entwicklungspro zesses JCJ 92 s a Kapitel 2 In der Welt des objektorientierten Software Engineering herrscht mittlerweile bereinstim mung darin dass gute Entw rfe und insgesamt erfolgreiche Projekte nur auf der Grundlage einer guten Architektur m glich sind vgl Booch94 JGJ97 Meyer97 Z llighoven98 Sogenannte
221. f unterschiedlichen Plattformen getroffen werden m ssen Kapitel 20 SCORESTOOL Wir stellen in diesem Kapitel exemplarisch einige ausgew hlte Komponenten des SCORE STOOLs vor Hierbei unterscheiden wir Komponenten zur haupts chlichen Unterst tzung Q der Spezifikation der Anforderungen Q ihrer Validierung und Verifikation und m des Tests der Anwendung gegen die Anforderungsspezifikation Die unterschiedlichen Prototypen der einzelnen Teilwerkzeuge und die damit durchgef hrten Fallstudien haben wiederholt zu einer berarbeitung bzw Pr zisierung von SCORES gef hrt Mittlerweile n hert sich der Prototyping Prozess seinem Abschluss und das SCORESTOOL stellt die gew nschte Funktionalit t fast vollst ndig zur Verf gung 20 1 Anforderungsspezifikation Bei der Spezifikation der Anforderungen unterst tzt das SCORESTOOL die Erstellung von Use Cases und Klassenmodellen durch entsprechende Editorkomponenten Die Visualisierung und das grafische Layout der Diagramme erfolgt hierbei auf verschiedenen Abstraktionsstu fen Die textuellen Spezifikationen werden ber spezielle Spezifikations Editoren eingege ben bzw ge ndert wobei spezielle Browser das Editieren und die Verfolgung verschachtelter textueller Spezifikationen erlauben Klassendiagramme Klassendiagramme werden in der UML Notation OMG97 oder wahlweise in der Notation nach Coad und Yourdon CoaYou90 dargestellt Nach der Markierung eines Modellierungselements
222. feingranulare Nach Verfolgbarkeit der Anforderungen w hrend des Entwurfs bis hin zur Implementation erschwert Diese und weitere Probleme wurden von der UML Task Force der Object Modeling Group OMG erkannt und sollen in sp teren Versionen der UML verbessert werden vgl OMG AT98 Nach entsprechenden nderungen k nnen wir die von uns vorgeschlagenen Use Case Schrittgraphen mit Aktivit tsdiagrammen und den drei Typen von Use Case Schrit ten entsprechenden Stereotypen modellieren Die in dieser Arbeit eingef hrte Semantik und Methodik w re dann vollst ndig mit der UML vertr glich was insbesondere der Forderung nach einer einheitlichen Modellierungssprache entgegenkommt vgl Wiegers98 1 Die sogenannten Schwimmbahnen Swimlanes in Aktivit tsdiagrammen dienen als rein graphisches Element lediglich zur visuellen Zuteilung von Aktivit ten zu beteiligten Aktoren haben jedoch keine weitere Semantik und spiegeln sich auch nicht im Meta modell wieder Kapitel 8 Methodisches Vorgehen Most methodologists now agree that user centred analysis is the best way to solve the right problem Rumbaugh94 Geeignete Modellierungselemente sind zwar notwendige aber keine hinreichenden Voraus setzungen f r eine im industriellen Alltag anwendbare Software Engineering Methode F r den erfolgreichen praktischen Einsatz einer Methode stellen Hinweise zum methodischen Vorgehen und eine geeignete Werkzeugunterst tzung wicht
223. ferent models A refinement is a relationship between model elements at different semantics levels such as anal ysis and design The derivation cannot necessarily be described by an algorithm human deci sions may be required to produce the clients OMG97 semantics guide Abb 13 3 stellt einen Ausschnitt des UML Metamodells dar Objekte der Klassen Trace und Refinement als Unterklassen von Dependency fassen jeweils eine Menge von Modellie rungselementen zusammen Zur Verfolgbarkeit dienen Instanzen der Klasse Trace die Mo dellierungselemente aus verschiedenen Modellen verkniipfen Kann tiber eine einfache Zuordnung hinaus angegeben werden wie die Modellelemente einander entsprechen wird diese Verfeinerung genannte Abh ngigkeit im Attribut Mapping einer Instanz der Klasse Refinement festgehalten W hrend Instanzen der Klasse Trace also lediglich syntaktische template Eu subDependencies parameter u F Dependenc Dependency P y Requirement Client ModelElement gt description template 1 ordered Refinement Usage Trace Mapping Abb 13 3 UML Auxiliary Elements Dependencies and Templates OMG97 Elemente der SCORES Anforderungsspezifikation 151 Abh ngigkeiten angeben erfassen Instanzen der Klasse Refinement zus tzlich semantische Abh ngigkeiten die z B zur Steuerung von Verfolgbarkeits Anfragen etc verwendet werden k nnen vgl PinGog96 Sei M
224. ftware des SRI unver ndert aus dem Vor g ngermodell der Ariane 4 bernommen ohne ausreichend zu ber cksichtigen dass diese eine v llig andere Starttrajektorie aufweist Entsprechende Versuchsl ufe wurden aus Kostengr nden nur mit eigens erstellten Software Simulationen der SRI s durchgef hrt Immer wieder melden die Medien solche und hnliche Nachrichten ber mehr oder weniger katastrophale Software Fehler wobei die Auswirkungen mit dem zunehmenden Grad der Computerisierung unserer Alltagswelt f r eine rasch wachsende Anzahl von Menschen sp rbar werden Sei es die Regelung des Herzschrittmachers die Einkommenssteuererkl rung mit dem Heimcomputer oder der Bordcomputer des Airbus A 320 berall zieht un sichtbar im Hintergrund Software an den F den der Geschehnisse Aufgrund ihrer zunehmend h heren Komplexit t werden nicht geplante und unvorhersehbare Wechselwir kungen wahrscheinlicher Nancy Leveson stellt fest We are building systems today and using computers to control them that have potential for large scale destruction of life and environment More than ever software engineers and systems developers as well as their managers must understand the issues and develop the skills needed to anticipate and prevent accidents before they occur Professionals should not require a catastrophe to happen before taking action Leveson95 Versuchen wir die Ursachen von Software Fehlern wie dem oben Illus
225. ftwaretechni sche Modell bilden und sp ter im Rechner realisiert werden sollen Die Ablauf oder Verhaltenssicht ist nicht abgedeckt Fassen wir zusammen W hrend die rein textuelle Formulierung der Use Cases bei Cockburn s Cockburn97 die Validierung erschwert ist die von Regnell et al s RAB96 schon auf relativ hoher Abstraktionsebene verwendete MSC Notation zu sehr auf Anwendungsgebiete wie z B die Telekommunikation beschr nkt Beide Arbeiten vernachl ssigen genauso wie Jacobson JGJ97 Potts PTA94 Rolland und Achour RolAch98 Lamsweerde und Willemet LamWil98 und Hurlbut Hurlbut98 die strukturellen Anteile der Anforde rungsdokumente Aufgrund der unterschiedlichen Ans tze lassen sich die meisten Arbeiten nicht kombinieren vgl Carroll95 PohHau97 Eine Ausnahme bilden die auf Zustandsmaschinen state charts basierenden Arbeiten von Glinz und Ziegler Die implizite Hypothese Funktionalit t und Verhalten kompletter Anwendungen unter Verwendung lediglich einer einzigen neuen formalen Notation spezifizieren zu k nnen ger t jedoch immer mehr in das Kreuzfeuer von Kritikern vgl FMD97 Wiegers98 Q Keines der bekannten monolithischen Modelle kann alle Aspekte realer Anwendun gen erfassen Q Je komplexer die Modelle werden desto weniger wahrscheinlich ist die M glichkeit Anwendungen realer Gr e damit vollst ndig spezifizieren zu k nnen und Q desto weniger werden Analytiker und Entw
226. g conducted on a complete integrated system to evaluate the system s compliance with its specified requirements IEEE610 90 Spezifischer wird Beizer der jedoch tiber diese Definition hinaus nicht auf den Systemtest eingeht System System Testing A system is a big component System testing is aimed at revealing bugs that cannot be attributed to components as such to the inconsistencies between components or to the planned interactions of components and other objects System testing concerns issues and behaviors that can only be exposed by testing the entire integrated system or a major part of it System testing includes testing for performance security accountability configuration sensitivity start up and recovery Beizer90 Oft wird der Systemtest mit dem Test quantifizierbarer Merkmale der nicht funktionalen An forderungen wie z B dem Last und Stresstest zusammengefasst diese aber explizit vom Ab nahmetest unterschieden Wir lesen bei Pagel und Six Sind die Integrationsarbeiten abgeschlossen und liegt das System vollst ndig montiert vor erfolgt der Systemtest Dabei werden neben Tests der operativen Anforderungen und der Schnittstellen zu externen Systemen insbesondere Leistungstests in Form von Laufzeit und Stresstest durchge f hrt welche die Effizienzanforderungen validieren und das Verhalten z B die Robustheit des Systems unter extremer Belastung untersuchen Stresstest testen das Systems ber einen l ngere
227. gangenen Elemen te der Anforderungsspezifikation referenziert Q Verfolgbarkeit vorw rts von den Anforderungen impliziert das Wissen welche Ele mente der Anwendung eine bestimmte Anforderung befriedigen also z B welche Entwurfselemente ihren Ursprung in einer bestimmten Anforderung haben Q Verfolgbarkeit zur ck zu den Anforderungen erm glicht zu jedem Element der An wendung festzustellen welche Anforderung es zu erf llen hilft Bei den ersten beiden Richtungen wird auch von Vor Verfolgbarkeit pre traceability ge sprochen bei den letzten beiden dementsprechend von Nach Verfolgbarkeit post traceabi lity vgl GotFin94 Im weiteren Verlauf dieser Arbeit sind wir im Wesentlichen am Test der objektorientierten Anwendung gegen die Anforderungsspezifikation interessiert Somit steht die Nach Verfolg barkeit der Anforderungsspezifikation ber den Entwurf in die Implementation im Mittel punkt Der eigentliche Entwurf bzw die Evolution bestehender Entw rfe und oder Anwendungen ist nicht Gegenstand der Arbeit Daher betrachten wir im Rahmen dieser Ar beit nicht die horizontale Verfolgbarkeit im Sinne des zeitlichen Bezugs sondern sehen diese Protokolle der Anforderungsermittlung Vor Verfolgbarkeit pre traceability Zur ck von Vorw rts zu Anforderungs Spezifikation Nach Verfolgbarkeit post traceability Zur ck zu Vorw rts von Entwurfselemente Implementation Abb 13
228. gezielt zur Erf llung struk tureller Testkriterien beitragender Testf lle Es sind also neben den black box Tests auch white box Tests durchzuf hren was zum ersten Problem zur ckf hrt wenn die Menge be troffener Klassen gro ist 14 2 Ziele Zur Behebung der obengenannten Probleme behandeln wir in diesem Teil aufbauend auf der Anforderungsermittlung und spezifikation mit SCORES und den im vorigen Teil gezeigten Techniken f r die Qualit tssicherung bei der Anforderungsermittlung zun chst die Pr fung der externen Funktionalit t der Anwendung In Kapitel 15 werden wir die bei der Validierung und Verifikation der SCORES Anforderungsspezifikation verwendeten und protokollierten Test Szenarien mit minimalem Aufwand als Testf lle f r den black box Test der Anwendung gegen die Anforderungsspezifikation verwenden Die Granularit t und Semantik der Use Case Schrittgraphen erm glicht zudem die Anwendung der f r die Validierung der Anforde 1 Strukturelle programmbasierte white box Testkriterien sind z B die Cy berdeckung bei der jede Anweisung mindestens einmal ausgef hrt werden muss oder die C Uber deckung bei der jeder Zweig des Kontrollflussgraphen mindestens einmal durchlaufen werden muss vgl Riedemann97 160 Probleme und Ziele rungsspezifikation verwendeten Testkriterien auch beim dynamischen Test der Anwen dung Zus tzlich wollen wir mit den Tests ohne gr eren Mehraufwand auch die internen Interak
229. gl z B Carroll95 WPJ 98 22 Entwicklungst tigkeiten Wi Ein Use Case Ein Aktor lt lt uses gt gt an EI Erweiternder Use Cas Wiederverwendender Use Cas Abb 2 4 Elemente des UML Use Case Diagramms sie in einer uses oder einer extends Beziehung zueinander stehen hierbei kennzeichnen wir an dem Pfeil um welche der beiden Beziehungen zwischen Use Cases es sich handelt Abb 2 4 Beziiglich der informationsbezogenen Aspekte empfiehlt Jacobson fiir jeden Use Case ein separates Objektdiagramm zu erstellen welches die am Use Case partizipierenden Objekte und ihre Abh ngigkeiten darstellt For each use case you prepare an object diagram which shows the objects participating in the use case and their dependencies Jacobson95 Er schl gt vor die Funktionalit t der Use Cases in Anlehnung an die drei Perspektiven Pr sentation Information und Verhalten auf Objekte aus den drei Kategorien Schnittstelle En tit ten und Kontrolle zu verteilen deren Symbole Abb 2 5 zeigt JCJ 92 oO Schnittstellen Objekte interface objects verkapseln die funktionalen Teile der An wendung die unmittelbar von der Anwendungsumgebung abh ngen Hauptaufgabe der Schnittstellen Objekte ist die T tigkeiten von Aktoren in anwendungsinterne Er Schnittstellen Objekt Entit ts Objekt Kontroll Objekt Abb 2 5 Darstellung der drei Objektarten nach Jacobson 1 In JGJ97 bezeichnet Jacobson Schnittstel
230. gnet zusammenfasst Mit dem Generator Framework werden dann entsprechende Skripte f r die SCORES grey box Testf lle generiert Mit diesem Querschnitt durch einige Spezifikations Validierungs und Verifikations sowie Testkomponenten des SCORESTOOLs beenden wir unsere kleine Leistungsschau und kom men zum letzten Teil der Arbeit 208 SCORESTOOL Teil VI Res mee und Ausblick Mit der Bewertung der erzielten Ergebnisse einer Zusammen fassung sowie einem kurzen Ausblick erreichen wir in diesem Teil das Ende der Arbeit Zus tzlich zum Verzeichnis der in dieser Arbeit verwendeten Li teratur und einem kleinen Index haben wir im Anhang noch ei nige technische Details bez glich der internen Interaktionen in objektorientierten Anwendungen sowie der Klassen Botschafts diagramme aufgef hrt welche den angemessenen Umfang ein zelner Abschnitte sowie den Lesefluss betr chtlich gest rt h tten Kapitel 21 Res mee Die Qualit tssicherung ist eine der wichtigsten Aufgaben bei der Entwicklung unternehmens kritischer Software Gerade in der Anforderungsermittlung ist die Qualit tssicherung kritisch f r den Projekterfolg denn Fehler in der Anforderungsspezifikation werden oft erst in sp ten Projektphasen z B beim Abnahmetest aufgedeckt und sind aufwendig zu beheben da meist alle vorangegangen T tigkeiten betroffen sind Die systematische Validierung und Verifika tion der Anforderungsspezifikation sind daher von gro e
231. h konkrete Objektkonstellationen f r die Szenarien zugrunde lagen konzentrieren sich Analytiker und Tester in der Verifikation mehr auf das Klassenmo dell also auf die systeminterne Information der Anforderungsspezifikation Wir schlagen die folgende Form des objektorientierten Walk Through s vor vgl auch Winter97 Q Die Objekte jeder beteiligten Klasse werden von einer Person vertreten die auch den Zustand der Objekte Werte der Attribute Referenzen auf andere Objekte nachh lt Q Beginnend mit dem Ereignis welches die durchzuspielende Aufgabe ausl st werden anhand der Beschreibung der Operationen Botschaften zwischen den Objekten bzw den sie vertretenden Personen gesendet und so die Episode simuliert und protokolliert Die zugrundeliegende Objektkonstellation kann entweder vorgegeben oder besser aber zeitraubender von einem Wurzelobjekt ausgehend innerhalb der Walk Th roughs selber aufgebaut werden 1 Entspricht einem Auftreten von super in der objektorientierten Programmierung 2 Programmiertechnisch alle Vorkommen von super werden durch self ersetzt 134 Verifikation Formale Vollst ndigkeit Ist jede Klasse in wenigstens einem Klassenbereich enthalten Ist jedem Interaktionsschritt eine Wurzeloperation zugeordnet Sind alle Klassen der Parameter der Wurzeloperation im Klassenbereich des aufru fenden Interaktionsschritts enthalten Ist der Klassenbereich eines Makro Schritts eine T
232. haracter Kommentare 1 Lokale Objekte dienen zur Aufnahme von R ckgabeobjekten der Botschaften und k nnen im Orakel der Botschaft sowie im Verlauf des Testfalls z B als Botschaftspa rameter verwendet werden Botschaften an lokale Objekte d rfen nur im Orakel ge sendet werden 254 Syntax der Test Skriptsprache TestCaseSubst ist semantisch eine textuelle Einsetzung des betreffenden Test skripts mit den substituierten formalen Parametern aber ohne den Konstruktor Der aufgerufene Testfall muss dabei f r eine Oberklasse oder f r dieselbe Wurzelklasse wie der aufrufende Testfall definiert sein Es wird kein neues Objekt erzeugt TestCaselnst beinhaltet dagegen die Objekterzeugung und Initialisierung Identifizierer lt name gt wie Messageld ClassId sowie Ausdr cke wie Intege rExp RealExp BoolExp String und Char etc m ssen der Syntax der Imple mentationssprache entsprechen bzw auf diese abbildbar sein Im Orakel bedeuten e pre der Attributwert vor Ausf hrung hnlich wie in OCL e die Pr fung auf Objekt Identit t Referenz Gleichheit e isEqual die Pr fung auf Objekt Gleichheit Werte Gleichheit nicht rekursiv auf Instanzvariablen Index Symbole Messen esse a De a rt 87 EE 120 Se e OEE ON Ne DE a ne E 120 EEE EEE 120 EE 86 ee Ers 20 83 87 Ss ee oe ee ae 87 Se ease ee ER 92 ee Paste RA Se AS 87 IN were er 66 IR Besen I ae Se Bee 66 LEE 86 AERO SET 120 e GE 87
233. he Auswertung bzw Pr fung k nnen wir sie dann in der Anfor derungsspezifikation bis hin zu formalen mehrsortigen pr dikatenlogischen oder OCL Ausdr cken ber dem Klassenmodell pr zisieren 1 OCL Object Constraint Language s OMG97 62 Grundlegende Konzepte Beispiel 5 1 Abb 5 3 zeigt die Spezifikation f r den Use Case Anmelden des Bankautoma ten Die verschiedenen mit ODER verkn pften Bedingungen der Nachbedingung geben die m glichen Ausg nge bzw Ergebnisse der Aufgabenbearbeitung an In den einzelnen Bedin gungen benutzen wir zun chst die im Verlauf der Bearbeitung gewonnene Information wie z B Karte unlesbar Daneben erkennen wir auch bestimmte Zust nde von Anwendungsob jekten z B Kartenleser gesperrt oder PIN dreimal falsch eingegeben Use Case Anmelden In Modell Bankautomat Beschreibung Nach Eingabe der Karte durch den Bankkunde liest der Bankautomat den Code vom Magnetstreifen und pr ft ihn auf Zul ssigkeit Bei zul ssigem Code fordert der Bankautomat die Eingabe der Identifikationsnummer PIN Der Bankkunde gibt die PIN ein Der Bankautomat berpr ft die PIN Wird eine falsche PIN eingegeben so wird der Versuch gez hlt nach drei Fehlversuchen wird die Karte gesperrt Nach der Eingabe der korrekten PIN fragt der Bankautomat nach der gew nschten Transaktion Aktoren Bankkunde Zentralrechner Vorbedingung Kartenleser betriebsbereit Bedienpult gesperrt Nachbedingung Karte
234. he referencing of each requirement in future development or enhance ment documentation IEEE830 93 Man kann bei der Verfolgbarkeit zun chst die horizontale und vertikale Verfolgbarkeit un terscheiden vgl Davis90 RamEdw93 Q Die horizontale Verfolgbarkeit setzt einerseits Elemente der gleichen Entwicklungs t tigkeit in einen zeitlichen Bezug man spricht in diesem Zusammenhang auch von Versionen eines Artefakts Andererseits beschreibt die horizontale Verfolgbar keit wie bestimmte Modellierungselemente innerhalb einer Entwicklungst tigkeit durch andere gleichartige Elemente verfeinert bzw pr zisiert werden Q Die vertikale Verfolgbarkeit betrachtet die Relationen zwischen Elementen verschie dener Entwicklungst tigkeiten und gibt Antwort auf die Frage wie ein bestimmtes Element z B eine Klasse im Code aus einem anderen z B einer Entwurfsklasse hervorgegangen ist Konzepte 149 Relativ zur Anforderungsspezifikation lassen sich mit der obigen Definition die in Abb 13 2 gezeigten vier Richtungen der vertikalen Verfolgbarkeit ableiten nach Davis90 Q Verfolgbarkeit zur ck von den Anforderungen impliziert das Wissen warum ein Element der Anforderungsspezifikation existiert also eine Referenz zur Quelle der Anforderung Gespr chsprotokolle Skizzen Q Verfolgbarkeit vorw rts zu den Anforderungen bedeutet dass jedes der Anforde rungsspezifikation vorausgehende Dokument die aus ihm hervorge
235. hen auch schon als Endschritt in einem Test Szenario vorkommen Andererseits haben wir Zyklen im Schritt graph die zur wiederholten Bearbeitung von Aufgaben f hren k nnen bisher berhaupt noch nicht betrachtet Als n chstes definieren wir daher die Use Case Szenario berdeckung cSz Zur Beschreibung von Pfaden im Use Case Schrittgraph ben tigen wir zun chst einige wei tere Begriffe und Hilfsfunktionen Sei ne IN 0 Zun chst ermittle die Operation StepGraph allPaths integer SetOfSequenceOfUseCaseStep 10 6 alle Pfade der L nge n d h mit n Kanten n 1 uc allPaths n ucso ucs uc steps vo lt i lt n ucs je O ucs 10 6 und die Operation StepGraph allPaths SetOfSequenceOfUseCaseStep 10 7 alle Pfade in einem Use Case Schrittgraph uc uc allPaths _ lt lt uc allPaths i 10 7 Wir nennen einen Pfad einfach wenn kein Schritt im Pfad mehrfach vorkommt d h ucs ucs f r 0 lt i lt j lt n Nat rlich sind wir bei der Validierung nicht an beliebigen Pfaden im Use Case Schrittgraph interessiert sondern an Szenarien also Pfaden die mit dem Startschritt des Schrittgraphen beginnen und in einem der Endschritte abgeschlossen sind Operation allSce narios 10 8 ermittelt genau die Menge der in einem Use Case Schrittgraph m glichen Sze narien uc allScenarios UCS UCS UCS uc allPaths ucs uc startStep ucs uc finalSteps 10 8 Sei ts ein Test Szenario zum Us
236. hin erg nzen und verfeinern die Analytiker das Klassenmodell d h f gen fehlende Klassen hinzu vervoll st ndigen Vererbungshierarchien und Objektbeziehungen Welche Klassen den Klassenbereichen der Use Case Schritte zugeordnet werden leiten die Analytiker aus den Beschreibungen und Verantwortlichkeiten der Schritte ab Ist eine Klasse in der Beschreibung erw hnt wird sie zun chst dem Klassenbereich hinzugef gt Auswir kungen der Teil Aufgabe des Schritts auf Instanzen der Klasse werden soweit ersicht lich notiert Mit den der Klasse zugeteilten Verantwortlichkeiten werden Attribute und Operationen ermittelt und spezifiziert Vereinzelt k nnen Interaktionsschritten schon Wur zeloperationen zugewiesen werden 8 4 Internes Verhalten Zur Spezifikation des internen Verhaltens also der dynamischen systeminternen Informa tion werden die Interaktionsschritte der Use Cases durch die Auswahl einer Wurzelklasse aus dem Klassenbereich und einer entsprechenden Wurzeloperation an das Klassenmodell gekoppelt Analytiker spielen z B die bei der funktionalen Zerlegung dokumentierten Szena rien erneut durch um dabei die Aufgaben der Interaktionsschritte mit den Verantwortlichkei ten der Klassen bzw den Operationen abzugleichen Operationen werden entsprechend den Administrative T tigkeiten 101 Aufgaben der Interaktionsschritte angepasst oder im Klassenmodell erg nzt Besondere Be r cksichtigung finden Szenarien die Sonde
237. hren unterschiedli chen Repr sentationen vgl Boehm84 FreWei90 ABR 94 PagSix94 Gerrard94 WBM96 Winter97 Wir betrachten zun chst kurz das Prototyping das Hsia Davis und Kung im Rahmen der An forderungsermittlung folgenderma en pr zisieren In context of requirements engineering prototyping is the construction of an executable system model to enhance the understanding of the problem and identify appropriate and feasible external behaviors for possible solutions Prototyping is an effective tool to reduce risk on software projects by an early focus on feasibility analysis identification of real requirements and elimina tion of unnecessary requirements HDK93 Im Weiteren orientieren wir uns an KPS95 Geht man von Anwendungen mit geschichte ten Architekturen aus vgl Abschnitt 2 2 so ist es sinnvoll von horizontalen und vertikalen Prototypen zu sprechen 106 Validierung Q Horizontale Prototypen realisieren eine Architekturschicht des Systems vollst ndig Die anderen Schichten werden nur skizzenhaft ausgef hrt und soweit simuliert dass der Prototyp lauff hig ist Die bekanntesten horizontalen Prototypen sind Oberfl chenprototypen welche die Interaktionen zwischen Benutzer und Anwendung model lieren vgl VosNen98 Q Vertikale Prototypen fokussieren auf einige wenige Funktionalit ten die durch alle Schichten hindurch realisiert werden Hier geht es z B darum unklare Funktionalit ten zu st
238. hritt in Richtung des Lasttests zu sehen der dann zur teilweisen Use Case Szenario berdeckung bzw sogar zur Use Case Pfad berdeckung c f hrt Da hierbei jedoch auch Pfade im Use Case ber cksichtigt werden die keinen Szenarien und insofern keinen vollst ndigen Abl u fen in der Realwelt entsprechen ist die Use Case Pfad berdeckung nur theoretisch sozusa gen in ihrer Abschlusseigenschaft als obere Schranke interessant 124 Validierungsmetriken ATM Guten Tag Bitte geben Sie Ihre Karte ein Karte wird gelesen Bitte geben Sie Ihre Geheimnummer ein zl 3 Abbruch alse 71212 3 PIN eingeben p L W hlen Sie die gew nschte Aktion Auszahlung Einzahlung berweisung Abbruch ech Abb 10 6 Bildschirmskizzen f r das ATM Test Szenario Anmeldung OK Kapitel 11 Verifikation Validierung und Verifikation der Anforderungsspezifikation sind hnliche T tigkeiten wo bei letztere auf einer erheblich detaillierteren und formaleren Ebene arbeitet Die Verifikation zielt auf die Konsistenz und formale Korrektheit der Anforderungsspezifikation ab Aus diesem Grund k nnen Benutzer und auch viele Dom nen Experten im Allgemeinen nicht bei der Verifikation mitwirken und Analytiker und Tester verbleiben als die einzig ausf h renden Parteien Diese verifizieren den strukturellen Aufbau sowohl der Use Case Schrittgra phen als auch des Klassenmodells sowie dessen
239. i fication and Verification of Interactive Systems Granada Spanien Juni 1997 Firesmith98 Donald G Firesmith Use Cases The Pros and Cons Technical Journal Knowledge Systems Corp Jahrg 1 Nr 8 1998 Fowler97a Martin Fowler Analysis Patterns Reusable Object Models Addison Wesley Reading Mass 1997 Fowler97b Martin Fowler UML Distilled Addison Wesley Reading Mass 1997 FreWei90 Daniel P Freedman Gerald M Weinberg Handbook of Walkthroughs Inspec tions and Technical Reviews grd Ed Dorset House Publishing New York 1990 FNZ96 Arne Frick Rainer Neumann Wolf Zimmermann Eine Methode zur Konstruktion robuster Klassenhierarchien Proc Softwaretechnik 96 Koblenz Sep 1996 S 16 23 Fuggetta97 A Fuggetta 1997 A Classification of CASE Technology in Software Enginee ring Hrsg M Dorfman u R Thayer IEEE Computer Society Press Los Alami tos 1997 S 469 482 GarJoh79 Michael R Garey David S Johnson Computers and Intractability W H Free man and Company San Franzisco 1979 GHJ 94 Erich Gamma Richard Helm Ralph E Johnson John Vlissides the Gang of Four Design Patterns Elements of Object Oriented Reusable Software Addi son Wesley Reading Mass 1994 GelHet88 David Gelperin Bill Hetzel The Growth of Software Testing Communications of the ACM Jahrg 31 Nr 6 Juni 1988 S 687 695 Gerrard94 Paul Gerrard Testing Requirements Proc gnd euroSTAR Briissel Belgien Okt 199
240. i schen Vorgehens des SCORES Metamodells und des SCORESTOOLS Der Grund daf r dass wir derartige Re Engineering Versuche einer konstruktiven Entwick lung von Anwendungen vorgezogen haben ist die Tatsache dass SCORESTOOL zur Zeit nur als Prototyp vorliegt der fortw hrend vervollst ndigt und berarbeitet wird Au erdem sind in einem kommerziellen Projekt schon allein wegen des meist doch sehr engen Zeitrahmens parallellaufende Vergleichsentwicklungen kaum m glich Soweit Auftraggeber und Benutzer von SCORES betroffen sind erwarten wir weiterhin das gleiche hohe Ma an Zustimmung wie wir es bereits bei den Re Engineeringprojekten und unseren Studierenden erhalten haben Ausschlaggebend sind die benutzerfreundlichen Sich ten und die Betonung des Ablaufaspektes In der Regel waren die Anwender offen f r den Ansatz und empfanden die erstellten SCORES Anforderungsspezifikationen als zweckm i ger und aussagekr ftiger als die bisherigen textuellen Pflichtenhefte Kombinierte Walk Th roughs der Use Cases vgl KPR 97 mit konkreten benutzerfreundlich dargestellten Objektkonstellationen haben insbesondere bei Personen ohne Modellierungserfahrung sehr zum Verst ndnis der strukturellen Aspekte der Anforderungsspezifikation beigetragen und bei der pr zisen Formulierung von Kommentaren und nderungsw nschen geholfen Auch auf Seiten der Analytiker und Tester hatten wir bisher keine Probleme diese f r SCORES zu begeistern Analytiker b
241. i 1983 bis November 1985 an gestellt in einem Softwarehaus Arbeitsgebiet Entwicklung von CAD Systemsoftware Von Dezember 1985 bis April 1986 Zivildienst Danach bis Juni 1987 weiter angestellt in obigem Softwarehaus Von Oktober 1987 bis August 1994 Laboringenieur an der Universit t Ge samthochschule Wuppertal Arbeitsgebiet Entwicklung von KI gest tzter Software f r die Regelungstechnik Ab September 1991 dort Leiter der entsprechenden Arbeitsgruppe Seit September 1994 wissenschaftlicher Mitarbeiter am Lehrgebiet Praktische Informatik III Fachbereich Informatik der FernUniversit t Gesamthochschule in Hagen Arbeitsgebiete Software Engineering Software Qualit tssicherung r umliche Datenstrukturen
242. i wird entschieden ob der Test einen Fehler offenbart hat oder nicht Au erdem wird gepr ft ob bzw wie weit das Testendekriterium erreicht ist Die Pr fung der Testergebnisse kann dabei z B mit Druck Repr sentationen Zusicherungen speziell f r den Test geschriebenen Auswerteme thoden oder aber ausf hrbaren Spezifikationen erfolgen Die Testauswertung ist schlie lich eine Bewertung der Testergebnisse im Hinblick auf die Testziele Hier gilt es zu entscheiden wann der Test zu Ende ist bzw wann der Test abzubrechen ist Das Ergebnis ist ein Testab schlu bericht Wir nutzen wieder das Klassen Botschaftsdiagramm Objekt Instanziierung und ggf Zer st rung werden protokolliert und mit entsprechenden Kanten des KBD verglichen Unbe nutzte Funktionen welche die Angabe realistischer Aussagen zur erzielten strukturellen berdeckung erschweren ergeben sich direkt als Wurzelknoten des KBD Die Interaktio nen zwischen Objekten werden wieder auf entsprechende Kanten des KBD abgebildet und gegen das KBD gepr ft In der Testdokumentation werden die T tigkeiten und ihre Ergebnisse festgehalten Hierzu geh ren die Pr fgegenst nde selbst Methoden Klassen Teilsysteme sowie die jeweils ben tigte Testumgebung die Testfallspezifikation sowie Testdaten und Testergebnisse Die Testberichte f r die Auswertung der Pr fung einer objektorientierten Anwendung sind hn lich gestaltet wie die Berichte ber konventionelle
243. ich kind Person da kind kind 0 2 Name Osad un kina von Geburtsdatum Geschlecht c Person d Person ne SE geschwi ste Tina in x 12 10 95 geschwister m nnlich weiblich kind kind L i geschwister king e Person geschwister NOT kindVon a a AND kindVon a b gt Basen Geburtstag a Geburtstag b gt 16 Jahre 09 07 97 m nnlich Abb 17 1 Beispiel zur Generierung von Objektkonstellationen 184 Umgebungsaufbau und Testdatengenerierung Constraints der Beziehungen z B weitere Kinder oder aber Eltern der miteinander verheira teten Personen Anne und Paul generiert werden Die zus tzlich generierten Objekte bzw Links sind in Abb 17 1 rechts grau gezeichnet LI 17 2 Komplexit t Unsere ersten Ans tze zur Erzeugung semantisch sinnvoller Objektkonstellationen aus Klas senmodellen mit abstrakten Objektstrukturen und Constraints erwiesen sich zun chst als viel versprechend s Rogotzki97 Jedoch konnten f r einige einfach erscheinende Klassenmodelle ohne vom Analytiker oder Tester manuell vorgegebene Muster Objekt strukturen keine Objektkonstellationen generiert werden Wie sich herausstellte ist der Grund daf r die inh rente Komplexit t des Problems der wir den Rest dieses Abschnitts wid men Wir formulieren zun chst das Problem Generierung von Objektkonstellationen GOK pr ziser Gegeben sei ein UML Klassenmodell KM mit einer Teil Menge K von Klassen so wie f
244. ich auf die modellbasierte Entwicklung von Program men mit ausgepr gter grafischer Benutzungsoberfl che und geben mit FLUID eine Vorgehensweise zur kombinierten Ermittlung von Dom nen und Benutzungsschnitt stellenanforderungen an KSV96 die z Zt von Homrighausen und Voss f r den Entwurf erweitert wird HomV0s97 Kern von FLUID sind vier miteinander gekop pelte Modelle e Das Aufgabenmodell kl rt die Frage was ein Benutzer mit der Anwendung bewerk stelligen will Zur Strukturierung werden Aufgaben in Teilaufgaben zerlegt sowie Wechsel zwischen logisch oder organisatorisch zusammengeh rigen Aufgaben mo delliert e Zur Problemweltmodellierung wird die objektorientierten Analyse CoaYou90 mit dem Ergebnis eines Dom nen Klassenmodells verwendet e Anforderungen an die Benutzungsschnittstelle werden im Oberfl chen Analysemo dell user interface analysis model UIA Modell festgehalten wobei haupts chlich das Aufgabenmodell in einer auf direkt manipulative Oberfl chen zugeschnittenen Weise zu einer verbindlichen Vorgabe f r die weitere Entwicklung pr zisiert wird e Semantische Anteile der Benutzungsschnittstelle und die Vermittlung zwischen ih ren Objekten und dem funktionalen Kern der Anwendung werden im Oberfl chen Entwurfsmodell user interface design model UID Model spezifiziert Hier werden auch wesentliche Teile der Architektur der Anwendung festgelegt Auch Rosson beschreibt wie die ineinander verwobene A
245. ickler solche Modelle lesen geschweige denn erstellen k nnen Die angesprochenen Probleme sowie weitere Forderungen an Anforderungsspezifikationen werden in Teil II dieser Arbeit angegangen 4 4 Zwischenfazit Wir haben in Abschnitt 1 2 gesehen dass in der industriellen Praxis haupts chlich in den sp ten Phasen der Softwareentwicklung und dort relativ unsystematisch gepr ft wird Zur Verbesserung dieser Situation sind die folgenden Problematiken zu behandeln Q Q Zwischenfazit 55 Es fehlen Verfahren zur Qualit tssicherung bei der objektorientierten Anforde rungsermittlung In der Literatur sind haupts chlich Verfahren zur Generierung von Testf llen und Testdaten aus formalen Spezifikationen angegeben Der Test von Reihenfolgebedingungen Riedemann97 ist problematisch da die meis ten Techniken zur Anforderungsspezifikation auf rein funktionale Spezifikationen hinauslaufen Die Komplexit t objektorientierter Anwendungen liegt in den Interaktionen vgl An hang A 21 so dass die in der Praxis oft verwendeten white box Testendekriterien we nig aussagekr ftig sind Ben tigt werden neue Testkriterien zur Abdeckung der Interaktionen sowie neue darauf abzielende Testverfahren Bekannte Verfahren zur Qualit tssicherung bei der Anforderungsermittlung und zum System und Abnahme Test gegen die Anforderungsspezifikation beziehen sich auf herk mmliche Techniken und Modelle zur Anforderu
246. ierarchie wobei wir z B verlangen k nnen dass eine vererbte Operation mindestens dann in einer Episode im Kontext der Unterklassen simuliert wird wenn sie in mindestens einer Episode im Kontext der Oberklasse eine in der Unterklasse redefinierte Operation be nutzt vgl PerKai90 HMGF92 Zum anderen ist es sinnvoll f r die einzelnen Elemente des Klassenmodells dediziert anzugeben wie weit der Verifikationsprozess gediehen ist Be trachten wir zun chst ein Beispiel einer Vererbungshierarchie Beispiel 12 1 Wir betrachten die vier Klassen A B C und D in Abb 12 1 a Klasse A defi niert die beiden Operationen a und b Die Klassen B und D sind Unterklassen von Klasse A wobei Klasse B Operation b redefiniert Klasse C definiere die Operation c Klasse D Opera Vollst ndige und polymorphe Operations berdeckung 141 tion d In der in Abb 12 1 b gezeigten Episode mit Wurzelklasse A und Wurzeloperation a benutzt die Operation a zun chst Operation b welche als R ckgabewert ein Objekt der Klas se C liefere C kommt damit in den Sichtbarkeitsbereich der Ausf hrung von Operation a in Klasse A die dann die Operation c aufrufe Da Operation b in Klasse B berschrieben ist for dern wir dass eine zus tzliche Episode mit Wurzelklasse B und der unver ndert geerbten Wurzeloperation a simuliert wird Diese soll zeigen dass die redefinierte Operation b den Sichtbarkeitsbereich bei der Ausf hrung von Operation a im Kontext der Klasse
247. ierungsregeln geben wir auch zur sinnvollen Simulation von Episo den einige Regeln an Diese betreffen den Sichtbarkeitsbereich also die im Kontext einer be stimmten Operationsausfiihrung zugreifbaren Klassen E bezeichne wieder die Menge aller Episoden Bez glich der ausf hrenden Klassen bzw der Sichtbarkeitsbereiche von Episodenschritten orientieren wir uns an statisch getypten objektorientierten Programmiersprachen vgl Meyer97 Es ergeben sich die folgenden unmittelbar einsichtigen Regeln Regel 11 4 1 Episode Wurzelklasse Die Klasse des ausf hrenden Objekts des Startschritts einer Episode ist konform zur Wurzelklasse des dem Test Szenarioschritt zugeordne ten Use Case Schritts V ee E sy e AK lt e tsc ucs WK Regel 11 4 2 Episode Konformitat1 Die ausf hrende Klasse jedes Folgeschritts muss kon form zu einer Klasse im Sichtbarkeitsbereich des aufrufenden Schritts sein Vee E Vese S e ss o es gt Ak es SK s AK lt k Regel 11 4 3 Episode Konformitat2 Die in der Signatur der ausgef hrten Operation des Fol geschritts enthaltenen Parameter miissen konform zu Klassen im Sichtbarkeitsbereich des aufrufenden Schritts sein VeeE Vese S e spe O es A S WO signature Ko Kn gt liken Kn 1 Er SK es Betrachten wir den Sichtbarkeitsbereich noch unter dem Aspekt der Vererbung Ist die aus f hrende Klasse eines Episodenschritts Unterklasse einer Klasse im Sichtbarkeitsb
248. iese Relationen bei der Modellierung gesetzt werden ist nicht Gegenstand dieser Arbeit Hinweise und technische Einzelheiten finden sich z B in Corriveau96 und PinGog96 13 2 Elemente der SCORES Anforderungsspezifikation Sowohl OOA D CoaYou91 als auch OOSE JCJ 92 bieten klare Richtlinien was die Einbettung der Dom nenklassen in den Entwurf angeht In OOA D werden sie zun chst eins zu eins bernommen in OOSE spielen sie im Entwurf die Rolle der Entit tsklassen W h rend jedoch OOA D die gesamte Funktionalit t quasi ber die Entwurfsklassen verteilt Kap 152 Verfolgbarkeit selt OOSE Teile der fachlichen Logik also die Use Case Funktionalit t in speziellen Kontroll Klassen Beide Entwurfsmethoden spalten die Benutzungsoberfl che hnlich ab OOA D f hrt den GUI Bereich ein OOSE sieht sog Interface Klassen als Mediator zwi schen der eigentlichen Benutzungsoberfl che und den Kontroll Klassen vor s auch Ab schnitt 2 2 F r OOSE gibt Tab 13 1 einige Beispiele der Verfolgbarkeit von Elementen der Anforderungsspezifikation ber den Entwurf in die Implementation Analyse Entwurf Implementation Analyseobjekt Block Eine oder mehrere Klassen Verhalten Operation Operation Attribut der Klasse Attribut der Klasse Statische Variable Attribut der Instanz Attribut der Instanz Instanzvariable Aggregation Aggregation Instanzvariable Tempor re Assoziatio
249. ige Erg nzungen der Modellie rungskonzepte dar Ohne diese Hilfestellungen wird eine Software Engineering Methode in der heutigen Zeit kaum Akzeptanz finden Deshalb erg nzen wir in diesem Kapitel unsere bisherigen Ausf hrungen durch einige Bemerkungen zum methodischen Vorgehen bei der Spezifikation der Anforderungen Wir betrachten hierbei separat die vier Aspekte funktionale Zerlegung externes Verhalten strukturelle Zerlegung und internes Verhalten Besonderen Wert legen wir bei der funktionalen Zerlegung und der Spezifikation des externen Verhaltens der Anwendung auf die Einbeziehung der zuk nftigen Benutzer 8 1 Funktionale Zerlegung Die Anwendung soll den z B in einer Produktskizze grob beschriebenen Teil von einem Gesch ftsprozess unterst tzen Anhand der organisatorischen Aspekte dieses Gesch ftspro zesses werden entsprechende Benutzer bzw von der Anwendung betroffene Personen oder Personengruppen ermittelt F r diesen Kreis von Personen und ggf anderen Anwendungen bilden wir anhand von Aufgaben und Verantwortlichkeiten Rollen die wir dann wiederum zu Aktoren abstrahieren Ergebnis dieser T tigkeit sind Aktoren und Aktorhierarchien mit ihren jeweiligen in den Gesch ftsprozess eingebetteten Aufgaben Die Aufgaben der einzelnen Aktoren werden anhand der funktionalen Sicht des Gesch fts prozesses zu Use Cases gruppiert vgl Kapitel 2 Analytiker und bestimmte Aktoren repr Externes Verhalten 99 sentierende
250. igkei ten im konzentrierten Durchlesen der Programme durch den Entwickler und in einer darauffolgenden Erprobungsphase Debugging und Pr fen waren nicht voneinander unterschieden 8 Motivation und berblick 1957 1978 In der Demonstrations Epoche wurden Debugging und Pr fen erstmals als unter schiedliche T tigkeiten herausgestellt Pr fungen wurden als erfolgreich bezeich net wenn sie die Funktionst chtigkeit des Programms nachwiesen 1979 1982 Eingeleitet durch das richtungsweisende Buch von Glenford Myers r ckte in der Destruktions Epoche das Aufzeigen von Fehlern in den Mittelpunkt der Pr f T tig keiten Myers79 Da der Entwickler die Fehlerfreiheit seines Programms anstrebt sollten speziell geschulte Tester das Programm unbarmherzig unter die Lupe nehmen Tests wurden als erfolgreich bezeichnet wenn sie die Funktionsunt chtigkeit des Programms nachwiesen 1983 1987 In der Epoche der Evaluierung wurde die Qualit tssicherung erstmals auf alle T tigkeiten der Softwareentwicklung ausgedehnt Jeder Entwicklungst tigkeit wurden entsprechende qualit tssichernde T tigkeiten zugeordnet Qualit tssicherung wurde jedoch immer noch eher als Qualitatskontrolle angesehen d h Produkte wurden nach ihrer Fertigstellung gepr ft 1988 1991 W hrend der Epoche der Fehlervermeidung versuchte man durch einen Mix an konstruktiven und analytischen Ma nahmen Fehler m glichst schon an ihrem Entste hungsort zu ve
251. in Endschritt ein Folgeschritt Der Schritt beschreibt eine elementare Teilaufgabe nach der die im Folgeschritt be schriebene Aufgabe bearbeitet werden muss Dies wird durch das Schliisselwort GOTO gekennzeichnet Abb 6 2 rechts Kontext oder Interaktionsschritt ein Folgeschritt Endschritt Abb 6 3 BEGIN Schritt Schritt Aufgabe Schritt IF c Schritt FolgeSchritt THEN GOTO FolgeSchritt ELSE Folgeschritt UseCaseEnde END END Schritt Abb 6 3 Semantik 3 Endschritt ein Folgeschritt Der Schritt beschreibt eine elementare Teilaufgabe mit der ein Szenario entweder en det oder aber wenn die Bedingung Pre erfiillt ist mit der im Folgeschritt beschriebe nen Aufgabe fortgesetzt werden muss Die Bedingung c Schritt FolgeSchritt darf hier nicht schon alleine von der Nachbedingung Postscprit des Schritts impliziert werden da Schritt sonst kein echter Endschritt ware und der vorherige Fall vorliegt Meistens wird c Schritt FolgeSchritt aus um weitere Bedingungen erg nzten Teilen der Nach bedingung POStgenrit des Schritts Schritt zusammengesetzt sein Wir kommen nun zu Schritten denen mehrere Folgeschritte zugeordnet sind und unterschei den die folgenden drei Falle m Kontext oder Interaktionsschritt mehrere Folgeschritte bergangsbedingungen der ausgehenden Kanten schliessen sich gegenseitig aus kein Endschritt Abb 6 4 F r 1 lt i j lt n ist c Schritt FolgeSchritt_i A c Schritt FolgeSch
252. ios are in general partial procedural and leave required properties about the intended sys tem implicit In the end such properties need to be stated in explicit declarative terms for consist ency completeness analysis to be carried out A formal method is proposed for supporting the process of inferring specifications of system goals and requirements inductively from interaction 52 Probleme der Anforderungsermittlung mit Use Cases scenarios provided by stakeholders The method is based on a learning algorithm that takes sce narios as examples counterexamples and generates a set of goal specifications in temporal logic that covers all positive scenarios while excluding all negative ones LamWil98 Beide Ans tze k nnen komplement r zu dieser Arbeit zur Extraktion und Konkretisierung sowie bei der textuellen Spezifikation von Use Cases benutzt werden Hurlbut erhebt Szenarien im Sinne konkreter Abl ufe eines Use Cases zur Modellierungs elementen und heftet sie an sogenannte adaptive Use Cases adaptive use cases Hurlbut98 Er orientiert sich hierbei an dem Workflow Referenzmodel vgl WFMC97 und fokussiert dementsprechend auf Gesch ftsprozesse Innerhalb eines Szenarios k nnen Erweiterungspunkte definiert werden an denen alternative Abl ufe bzw Ausnahme und Sonderabl ufe eingeschoben werden k nnen Eine klare Seman tik f r die Szenarien und die Einsch be ist nicht angegeben K sters Six und Voss konzentrieren s
253. ird verwendet wenn mehrere Use Cases eine bestimmte Teilfunktio nalit t ben tigen Diese notwendige Teilfunktionalit t wird zur Redundanzvermeidung in ei nem separaten Use Case beschrieben der von den anderen Use Cases verwendet wird A uses relationship from use case A to use case B indicates that an instance of the use case A will also include the behaviour as specified by B OMG97 Notation Guide Sowohl die uses als auch die extends Beziehung f gen also zus tzliche Funktionalit t in eine Basisfunktionalit t ein Im Falle von uses ist die zus tzliche Funktionalit t unabdingbar im Falle von extends ist sie optional d h eine Instanziierung des erweiterten Use Cases er gibt auch ohne die zus tzliche Funktionalit t sinnvolle Szenarien Zur berblicksartigen Darstellung der Use Cases f r eine Anwendung benutzt Jacobson das Use Case Diagramm In ihm werden menschliche und maschinelle Aktoren als Strich m nnchen visualisiert Jeder Use Case wird durch eine Ellipse dargestellt die mit dem Na men des Use Cases gekennzeichnet wird Die an einem Use Case beteiligten Aktoren werden durch ungerichtete oder gerichtete Assoziationen mit der dem Use Case entsprechenden El lipse verbunden Geschlossene Pfeile Generalisierungen verbinden zwei Use Cases wenn 1 Typische meist informell beschriebene Szenarien zur Illustration funktionaler Anforde rungen bilden seit Mitte der neunziger Jahre einen eigenen Forschungsgegenstand v
254. it Anzeigen A Kartenleser Karte Bedienpult zeigeAuswahl y Karte ZS Anbieten x Kante ra Transaktion Entnehmen end Kartenleser Bedienpult Zentralrechner Yy Karte ZS Einziehen Kartenleser zieheKarteEin Bedienpult Abb 7 5 Use Case Schrittgraph mit Klassenbereichen Wurzelklassen und Wurzeloperationen 96 Kopplung von Use Cases und Klassenmodell Wir ermitteln nun die Werte der Vollst ndigkeitsmetriken Von den 13 Klassen Abb 7 3 sind 3 als Wurzelklassen zugeteilt Kartenleser Bedienpult und Transaktion Die einfache Klassen berdeckung ergibt sich somit zu 23 08 In den Klassenbereichen kommen zus tzlich noch die Klassen Karte und Zentralrechner Schnittstelle vor Wir erhalten also eine Klassen berdeckung von PMP _ 38 46 B Von den 29 im Klassenmodell definierten Operationen sind 6 als Wurzeloperationen zuge teilt so dass wir eine einfache Operations berdeckung von erhalten GEN 5 20 69 Q 7 6 Exkurs Use Case Schrittgraphen und Aktivit tsdiagramme In der im September 1997 zeitgleich zu unseren Entwicklungen s KPW97 ver ffentlich ten Version 1 1 der UML ist das Metamodell der Verhaltenssicht Common Behavior erwei tert worden OMG97 Die Autoren schlagen den Einsatz von Aktivit tsdiagrammen zur Modellierung einzelner Operationen im Klassenmodell bis hin zur Spezifikation von voll st ndigen Workflows vor Das Aktivit
255. it tssicherung 5 Dokumente die Pr fungen unterworfen werden geh ren hierzu Pr fen ist eine Kon trollfunktion im Software Entwicklungsprozess Sie umfasst nicht die Fehlerkorrek tur Daneben wird validierendes und falsifizierendes Pr fen unterschieden Ersteres hat die Frage Was kann der Pr fgegenstand letzteres die Frage Was kann der Pr fgegenstand nicht als Ausgangspunkt Debuggen ist das Beheben von Fehlern Zu einem festgestellten Fehler wird zun chst die Fehlerursache aufgesp rt und anschlie end korrigiert Validierung bezeichnet die berpr fung einer allgemeinen Aussage mit positivem Ausgang So wird z B die Behauptung dass eine Anwendung bei Eingabe bestimmter Werte ein spezifiziertes Ergebnis liefert durch Ausf hrung der Anwendung validiert Unter der Verifikation versteht man die Pr fung eines Artefakts gegen seine Spezifi kation Wir fassen den Begriff der Verifikation in dieser Arbeit im Sinne der angel s chsischen Literatur bauen wir das System richtig Boehm84 wesentlich weiter als die meisten deutschsprachigen Autoren die unter der Verifikation eher mathema tische Techniken zum Korrektheitsbeweis z B des Quellcodes der Anwendung auf der Grundlage einer formalen Semantik der verwendeten Programmier Sprache ge gen eine formale Spezifikation verstehen s auch Teil IV Die Qualitdtssicherung ist die Gesamtheit aller die Softwareentwicklung begleitenden T tigkeiten zur Vermei
256. itte T11 Abb 6 8 Semantik 7 Makroschritt 78 Abb 6 9 Nachbedingungen der im Szenario Erfolgreiche Anmeldung besuchten Use Case Schritte 79 Abb 6 10 Bedingungen der im Szenario Erfolgreiche Anmeldung besuchten Kanten 79 Abb 6 11 Illustration der Semantik von uses a und extends b 83 Abb 7 1 Interaktionsschritt mit Klassenbereich und Wurzeloperation Op_1 90 Abb 7 2 Erweitertes Use Case Metamodell 91 Abb 7 3 Klassenmodell des Bankautomaten 94 Abb 7 4 Use Case Anmelden Klassenbereich 95 Abb 7 5 Use Case Schrittgraph mit Klassenbereichen Wurzelklassen und Wurzeloperatio nen 95 Abb 9 1 Exemplarische Checklistenpunkte f r die Validierung 110 Abb 9 1 Scores Metamodell mit Test Szenario 114 Abb 10 1 Beispiele zur Use Case Schritt a Kanten b und Szenario berdeckung c 117 Abb 10 2 Use Case Schrittgraph a und f nf textuell beschriebene Szenarien b 121 Abb 10 3 Sequenzdiagramm zum Test Szenario Online Anmeldung Use Case Anmelden 122 Abb 10 4 berdeckung des Use Case Schrittgraphen Anmelden 122 Abb 10 5 Benutzerfreundliche Sicht f r das ATM Test Szenario Auszahlung OK 123 Abb 10 6 Bildschirmskizzen f r das ATM Test Szenario Anmeldung OK 124 Abb 11 1 Exemplarische Checklistenpunkte f r die Verifikation 134 Abb 11 1 Sequenzdiagramm Episode mit Wurzelklasse Transaktion und Wurzeloperation f hrePlanAus135 Abb 11 2 Vollst ndiges Scores Metamodell 136 Abb 12 1 Klassendiagramm und Episode mit redefinierter
257. jektorientierte Programmier Sprachen entwickelt Erst das Zusammenspiel m chtiger Sprachen f r Schnittstellenspezifikationen und Implementationen mit entspre chenden Kalk len und universellen Techniken zur Spezifikation und zum automatischen Be weis der Korrektheit in einer logik basierten Programmierumgebung wird den Einsatz formaler Methoden in der objektorientierten Softwareentwicklung praktikabel machen vgl Poetzsch97 Daneben behindert die unabdingbare Forderung nach benutzerfreundlichen Sichten bei der Anforderungsermittlung den Einsatz formaler Methoden da die unterschiedlichen Abstrak tions und Granularit tsniveaus den bergang von informellen f r den Benutzer verst ndli chen Dokumenten zu formalen Spezifikationen erschweren Zur Zeit spielen daher formale Methoden in der industriellen Softwareentwicklung noch kei ne gro e Rolle und werden fast ausschlie lich f r bestimmte Teile hoch sicherheitskritischer Anwendungen eingesetzt vgl DHP 99 Auch wenn die komplette Anwendung formal spezifiziert und verifiziert w re reicht dies f r die Qualit tssicherung nicht aus In Riede mann s Worten Die Programmverifikation hat folgende Vorteile und Nachteile bzw Probleme Vorteile Das Programm wird bez glich der Eingabe und Ausgabezusicherungen als korrekt f r alle Eingabef lle bewiesen Dies gilt f r den Quellcode f r den Objektcode gilt dies nat rlich 30 Probleme der Qualit tssicherung f r obj
258. k auf eine effiziente Automatisierung beschr nken wir uns auf ein graphentheore tisch definiertes Modell Knoten repr sentieren die in den Klassen des Klassenmodells defi 237 nierten Operationen Kanten stellen Benutzungsbeziehungen zwischen Operationen dar Zus tzlich merken wir uns ob zwei oder mehrere Kanten einer aufgrund der Vererbung und des Polymorphismus dynamisch gebundenen Benutzung entsprechen Wir pr zisieren dies in der folgenden Definition Definition 22 1 Sei K die Menge aller Dom nen Klassen im Klassenmodell einer Anforde rungsspezifikation Das Klassen Botschaftsdiagramm f r die Anforderungsspezifikation KBD ist ein gerichteter kantenmarkierter Graph V E P mit der Markenmenge Ly Hier bei treffen wir folgende Vereinbarungen Q V COPS repr sentiert die Menge aller expliziten Methodendefinitionen in K LI La message inheritance ist die Menge der Kantenmarkierungen mit der Bedeu tung e message Benutzung einer Operation Botschaft e inheritance es handelt sich um eine Vererbungskante Q E S V x La x V repr sentiert die Menge aller in der Anwendung m glichen Operati onsbenutzungen vereinigt mit den aufgrund von Redefinitionen zwischen Operatio nen bestehenden Vererbungsbeziehungen Wir bezeichnen mit Eg C E x Eg amp x m j n mit j message die Menge der Botschaftskanten des Klassen Botschafts diagramms Die Menge Ey CE x Ey amp x m inheritance n nennen
259. k setzen oder mit dem Durchspielen vorgelagerter Test Szenarien Makroschritte direkt mit der Anwen dung erzeugen In einem Testskript stellen wir anhand der Vor und Nachbedingungen der Testf lle und der Flussbedingungen der Kanten im Use Case Schrittgraph passende Testf lle zu einem Ab lauf zusammen Auch hier unterscheiden wir wieder positive und negative Tests positive Testskripte halten die Bedingungen explizit ein Gezielte Verletzungen der Constraints f r die erlaubten Objekt konstellationen sowie insbesondere der Bedingungen der Schritte und Kanten im Use Case Schrittgraph und der Interaktionsparameter f hren zu negativen Testf llen mit denen wir die Robustheit unserer Anwendung pr fen Use Case und Use Case Schrittgraph Testsuite Die Testsuite ordnet die Testskripte und Testf lle bzw daten einem bestimmten Use Case zu Es sind keine Entsprechungen in den Test Skripten erforderlich da lediglich eine struk turierende Ebene eingef hrt wird Daher sind in der Syntax f r Test Spezifikationen Anhang B auch keine Konstrukte f r Testsuiten vorgesehen Methodisches Vorgehen 165 Bei den black box Tests messen wir die erzielte berdeckung bez glich des Use Case Schrittgraphen analog zu den Validierungsmetriken funktionale berdeckung Kapitel 10 und des Quellcodes der Anwendung strukturelle berdeckung Kapitel 16 Zus tzlich wer den in black box Tests auch Reihenfolgebedingungen verwendet vgl B
260. kalen Wiederverwendung oder Kopplung innerhalb einer Vererbungshierarchie darge stellt Alle anderen Aufrufe bedeuten eine horizontale Wiederverwendung oder Kopplung im Sinne der Delegation vgl GHJ 94 also dynamisch gebundene einfache Aufrufe ber schriebene overridden Instanz Methoden sind von aussen nicht sichtbar berschriebene hidden Klassen Methoden sind nach einem Cast von aussen sichtbar 1 berschriebene Methoden sind in PerKai90 HMGF92 und HKR 97 nicht betrach tet 250 Klassen Botschaftsdiagramme Nr Typ ml Typ m2 Intra Objekt ol o2 A Inter Objekt ol lt gt o2 B 1 N N Standard Aufruf auch this Standard Aufruf 2 N R Wie 1 Wie 1 3 N l Wie 1 redundantes super Standard Vertikale Kopplung 4 N O Fraglicher gebrauch von super I In Java nicht m glich C nach Cast 5 R N Wie 1 Wie 1 6 R R Wie 1 Wie 1 7 R l Wie 3 Wie 3 8 R O Standardgebrauch von super I In Java nicht m glich C nach Cast 9 l N In Java nicht m glich I In Java nicht m glich C nach Cast 10 I R Polymorphismus auch this Polymorphismus 11 I l Wie 1 Wie 1 12 l O In Java nicht m glich I In Java nicht m glich C nach Cast 13 O N In Java nicht m glich I In Java nicht m glich C nach Cast 14 O R Polymorphismus nur nach super Nur nach super Template Strategy 15 O l Nur nach super Nur nach super 16 O O In Java nicht m glich I
261. kation und bei ausreichender For 126 Verifikation malisierung der Bedingungen teilweise automatischen Pr fungen zug nglich vgl DesObe96 HOR98 Im Zentrum der Inspektionen des strukturellen Aufbaus des Klassenmodells stehen die Ge neralisierungen und die Assoziations Aggregations und Kompositionsbeziehungen vgl MMB 96 Siegel96 Winter97 Einige Kriterien z B f r die Vererbungshierarchie sind Q Ist dokumentiert ob es sich um Vererbung im Sinne einer Generalisierung Speziali sierung oder um Vererbung f r Wiederverwendung handelt Q Ist die Vererbungsbeziehung konzeptuell notwendig oder l sst sich der erw nschte Effekt auch durch eine Benutzungsbeziehung bzw mittels Aggregation erreichen Q Sind Bl tter der Vererbungshierarchie abstrakte Klassen Wenn ja warum K nnen Sie eliminiert werden Q Erben abstrakte Klassen von konkreten Klassen Wenn ja warum K nnen Sie elimi niert werden m Gibt es Klassen die keine Attribute und oder Dienste neu definieren bzw redefinie ren Wenn ja warum K nnen Sie eliminiert werden Zus tzlich bei mehrfacher Vererbung Q Ist der gew nschte Effekt einer wiederholten Vererbung klar dokumentiert Q Realisiert die Klasse mehrere Konzepte bzw Aufgaben Wenn ja warum Anhand der Assoziationen teilen wir das Klassenmodell in mehrere Gruppen gekoppelter Klassen Cluster auf Grob gesagt erkennen wir solche Cluster daran dass zwischen Klassen aus unterschie
262. ktionen an Die mit uses markierten von der Methode B opA ausgehen den Kanten bedeuten die m gliche nicht modifizierende Verwendung der Instanzvariablen einA und a in dieser Methode class A public integer a public void opA a 1 def CH class B extends A public A einA public void opA super opA a a 1 einA opA Operation Variable a b gt gt Botschaft def uses C Vererbung Abb 16 2 Java Code a und Klassen Botschaftsdiagramm fiir die Implementation b Wir erkennen die direkten Aufruf Interaktionen anhand der Kanten des KBD Zustandsbe dingte Abh ngigkeiten zwischen den Methoden indirekte Interaktionen spiegeln sich im KBD in Pfaden von einem Methodenknoten zu einem nicht notwendigerweise verschiede Verfolgbarkeit und Klassen Botschaftsdiagramme 175 nen Methodenknoten wider die mindestens eine mit def oder mit uses markierte Kante be inhalten s Anhang A 21 m 16 3 Verfolgbarkeit und Klassen Botschaftsdiagramme ber die Verfolgbarkeitsrelation k nnen wir das aus der Anforderungsspezifikation generier te KBD auf einen Teil des aus der Implementation generierten KBD abbilden diesen Teil bezeichnen wir mit KB a Hierbei entsprechen z B jeder Benutzung der Standardo peration modify im KBD eine oder mehrere mit def markierte Kanten des KBDy Benut zungen der Standardoperation x query im KBD entsprechen im KBD Kanten zu Methoden aus
263. l shift to testing business solutions Pol98 Wir wenden uns nun der Testfallermittlung f r den Test der Anwendung gegen die Anforde rungsspezifikation zu also im V Modell Abb 14 1 Seite 159 den beiden oberen mit Fra gezeichen markierten T tigkeiten In diesem Kapitel leiten wir rein funktionale auf die kontextuelle Information Gesch ftsprozesse und die Interaktions Information bezogene black box Testf lle ab 15 1 berblick Der black box Test als anforderungsbasierter Systemtest zeigt systematisch die Verf gbar keit aller Funktionen und ihre bereinstimmung mit der Anforderungspezifikation auf Es wird keine systeminterne Information verwendet Die Testf lle werden aus der Anforde rungsspezifikation abgeleitet Der black box Test als Abnahmetest soll zeigen dass die An wendung bereit bzw geeignet f r den Einsatz in der Produktion ist Er wird in der Regel unter der Regie des Auftraggebers unter Einbeziehung der Benutzer durchgef hrt und soll diese da von berzeugen dass die Anwendung der Anforderungsspezifikation bzw dem Pflichten heft entspricht Hierbei werden ausgew hlte Test Szenarien manuell vornehmlich von Benutzern in ihrer Umgebung ausgef hrt Grundlage der black box Testf lle sind die Use Case Schrittgraphen und die bei der Validie rung und Verifikation der Anforderungsspezifikation verwendeten Test Szenarien so dass wir die Validierungsmetriken aus Kapitel 10 als Testkriterien f r den black b
264. laufen Im RUP ist der Lebenszyk lus in die vier aufeinanderfolgende Phasen Konzeptualisierung Entwurf Konstrukti on und bergang unterteilt LI Auf der vertikalen Achse werden die einzelnen Aspekte der T tigkeiten also das Wie Was und Wer abgetragen Hier sehen wir auf der obersten Ebene die T tigkeiten Zu jeder T tigkeit geben wir die erzeugten bzw bearbeiteten Entwicklungs produkte die jeweiligen Aktivit tstr ger Worker und die Workflows der einzelnen T tigkeit an Jede Phase wird mit wohldefinierten Meilensteinen abgeschlossen bei denen auf der Grund lage der bisherigen erreichten Ziele Entscheidungen f r das weitere Vorgehen getroffen wer den Innerhalb der Phasen werden die T tigkeiten iterativ ausgef hrt wobei jede Iteration in einer lauff higen internen Teilversion der Anwendung m ndet Inkrement Da jede Itera tion bestimmte Teil Funktionalit ten implementiert die wiederum mit Use Cases beschrie ben werden vgl Teil II wird der Prozess als Use Case gesteuert inkrementell und iterativ charakterisiert s JBR99 Zur pr zisen Spezifikation der durch die verschiedenen T tigkeiten erstellten Produkte bzw Modelle wird eine hinreichend ausdrucksstarke Notation ben tigt Nachdem Anfang der neunziger Jahre ber 30 verschiedene objektorientierte Methoden mit unterschiedlichen Notationen existierten vereinigten die bekannten Methodologisten Grady Booch und Ja me
265. len Objekte passender als Begrenzer Objekte boundary objects Gesch ftsprozesse und Anforderungsermittlung 23 eignisse zu bersetzen und umgekehrt anwendungsinterne Ereignisse und Zust nde an denen die jeweiligen Aktoren interessiert sind in eine dem Aktor pr sentierbare Form zu berf hren oO Entit ts Objekte entity objects modellieren Daten welche die Anwendung ber l n gere Zeit verwendet Typischerweise berleben solche Daten den Ablauf einzelner Use Cases Neben den eigentlichen Daten Kapseln Entit ts Objekte auch solche Funk tionalit ten die ihre Informationen unmittelbar betreffen oO Kontroll Objekte control objects kapseln die verbleibende Funktionalit t komple xer Use Cases die sich nicht eindeutig zu Objekten der beiden anderen Kategorien zu teilen l sst typischerweise also transaktionsbezogene Funktionalit t Teil Funktionalit t die von mehreren Use Cases verwendet wird oder aber Funktionalit t welche eine Br cke von Interface Objekten zu Entit ts Objekten bildet Zur Spezifikation des dynamischen Ablaufs verwendet Jacobson Interaktionsdiagramme hnlich dem UML Sequenzdiagramm An interaction diagram shows how participating objects interact to offer the use case one is re quired for each concrete use case Interaction takes place when objects send stimuli to one anoth er As you draw the diagram you also define all the stimuli sent including the parameters Jacobson95 Au
266. lesbar Interaktionsschritt PIN Anfordern In Use Case Anmelden Nachbedingung PIN gelesen ODER Abbruch Interaktionsschritt PIN Pr fen In Use Case Anmelden Nachbedingung PIN OK ODER NICHT PIN OK Interaktionsschritt Auswahl Anzeigen In Use Case Anmelden Nachbedingung Bedienpult auswahlbereit END Auswahl Anzeigen Abb 6 9 Nachbedingungen der im Szenario Erfolgreiche Anmeldung besuchten Use Case Schritte Kante Karte Einf hren Karte Lesen In Use Case Anmelden Bedingung Karte im Kartenleser END Karte Einf hren Karte Lesen Kante Karte Lesen PIN Anfordern In Use Case Anmelden Bedingung Karte lesbar UND Code g ltig END Karte Lesen PIN Anfordern Kante PIN Anfordern PIN Pr fen In Use Case Anmelden Bedingung PIN gelesen END PIN Anfordern PIN Pr fen Kante PIN Pr fen Auswahl Anzeigen In Use Case Anmelden Bedingung PIN OK END PIN Pr fen Auswahl Anzeigen Abb 6 10 Bedingungen der im Szenario Erfolgreiche Anmeldung besuchten Kanten In Worten ergibt sich f r den Use Case Anmelden dass nach Ablauf des Szenarios Erfolgrei che Anmeldung die Karte im Kartenleser der Kartenleser f r weitere Karten gesperrt und die Karte lesbar sowie der Code der Karte g ltig ist Die PIN wurde eingegeben und als richtig 80 Semantik gepr ft Nach dem Szenario ist das Bedienpult auswahlbereit d h die angebotenen Dienste werden angezeigt und der Bankkunde kann seine Auswahl treffen u 6 3 Modellierungsregeln II Zus
267. lich ist bis jetzt unklar wie sich der globale Zustand der Anwendung mani festiert und wie er sich w hrend der Bearbeitung eines Use Cases ndert Ohne dieses Wissen m ssten wir jedoch zur pr zisen Spezifikation der Wurzeloperation die Kapselung der einzelnen Klassen durchbrechen und in der Vor und Nachbedingung von Wurzeloperationen Informationen aufnehmen die nicht im Verantwortungsbereich der je weiligen Wurzelklasse liegen Behringer nennt diesen Sachverhalt in ihrer Dissertation als Hauptnachteil der auf mehreren getrennten Modellen basierenden Matrix Ans tze Though encapsulation is one of the key concepts of object orientation in matrix approaches there is no encapsulation of data and functions into objects Data and functions are not modelled on the same level of granularity The data is modelled on the level of individual objects the func tions on the level of the whole system The scenarios system operations or use cases are orthogo 1 Unter dem Namen Matrix Ansatz fasst Behringer alle objektorientierten Methoden wie z B OOSE JCJ 92 und OMT RBP 91 zusammen welche die funktionale Sicht und die Datensicht getrennt modellieren und in denen diese Sichten nur durch eine implizite oder explizite Abh ngigkeitsmatrix zwischen Funktionen und Daten auf einander abgebildet werden 128 Verifikation nal to objects They are purely functional abstractions and could just as well be used as inp
268. lich sind vgl Hasselbring98 Z llighoven98 Die Anforderungsspezifikation muss solche Sichten ber cksichtigen da mit die Validierbarkeit durch den Benutzer gew hrleistet ist Wir kommen auf diese Aspekte in Kapitel 9 zur ck Der Modellierung auf Klassenebene entsprechend bestimmen wir aus den Teil Aufgaben beschreibungen der Use Cases bzw ihrer Schrittgraphen sowie der einzelnen Use Case Schritte zun chst jeweils bestimmte Mengen von Klassen die wir als Klassenbereiche be zeichnen Ein Klassenbereich enth lt alle Klassen deren Instanzen von der Teil Aufgabe betroffen sein k nnen d h die erzeugt gel scht oder aber in ihrem Zustand ge ndert und zur Formulierung der Bedingungen f r die Auswahl und Ausf hrung weiterer Teil Aufgaben ben tigt werden Definition 7 1 Seien K die Menge aller Klassen eines Klassenmodells und uc S s SE o ein Use Case Schrittgraph Die Abbildung B S gt 2K ordne jedem Use Case Schritt eine Men ge m glicher in die Aufgabe des Schritts involvierter Klassen zu B s hei t Klassenbereich des Schritts s die Vereinigung der Klassenbereiche aller Schritte eines Use Case Schrittgra phen bezeichnen wir als Klassenbereich des Use Case Schrittgraphen und erweitern dem entsprechend die obige Abbildung auf Use Cases zu B UC gt 2K BUc DJ uB LI Hierbei betrachten wir im Klassenbereich eines Kontextschritts reale Dom nenobjekte und im Klassenbereich eines Interaktion
269. liebig viele Fol geschritte jedoch h chstens einen Vorg ngerschritt haben was durch die Injektivit t von ep o gesichert ist Da die Episode insgesamt zusammenh ngend sein muss erhalten wir die folgende Regel E bezeichne die Menge aller Episoden Regel 11 3 1 Episode Folgeschritte Mit Ausnahme des Startschritts einer Episode ist jeder Episodenschritt Folgeschritt von mindestens einem anderen Episodenschritt d h V ep E Y se ES ep so sy s ep o s 2 1 Episoden 131 Die Injektivit t von o und die in Definition 11 2 enthaltenen Bedingung dass der Startschritt Sg der Episode nicht Folgeschritt irgend eines Schritts ist sichern zu dass o zyklenfrei ist und somit jeder Schritt mit Ausnahme von sy Folgeschritt von genau einem anderen Episoden schritt ist Nehmen wir an es g be einen Zyklus Der Startschritt kann It Definition 11 2 nicht Element des Zyklus sein Also m sste mindestens ein Schritt der Episode mehr als einen Vor g ngerschritt haben n mlich sowohl den Vorg ngerschritt auf dem Pfad zum Startschritt als auch den Vorg ngerschritt im Zyklus Dies widerspricht der Injektivit t von o In Anlehnung an den Sichtbarkeitsbegriff f r Programmiersprachen vgl Poetzsch91 kom men wir nun zum Sichtbarkeitsbereich eines Episodenschritts Vereinfacht gesagt verstehen wir hierunter die Klassen bzw ihre Operationen Attribute und Assoziationen welche der vom Schritt ausgef hrten Operation zu einem
270. lle spielt 11 2 Externes vs internes Verhalten In der Validierung werden Test Szenarien in Form von Gesch ftsvorf llen als Pfade im Use Case Schrittgraph oder genauer gesagt als konkrete Abl ufe gepr ft Analytiker und Tester untersuchen nun ob und wie die validierten extern beobachtbaren Auswirkungen der Szenarien aufgrund des Zustands von Anwendungsobjekten bzw der Anwendung selbst zustandekommen k nnen In anderen Worten Sie pr fen ob das strukturelle Anforderungs modell also das Klassenmodell die funktionalen Aspekte der Anforderungen also die Use Cases auch wirklich reflektiert bzw ausf hren kann Ausgehend von den validierten und in Inspektionen verifizierten Use Case Schrittgraphen werden daf r die Elemente des Klas senmodells im Einzelnen untersucht Mit der Angabe des Klassenbereichs der Wurzelklasse und der Wurzeloperation f r jeden Use Case Interaktionsschritt ist zun chst in Verbindung mit den Vor und Nachbedingun gen des Schritts festgehalten welche Operation welcher Dom nenklasse im Klassendia gramm f r die betrachtete Teil Aufgabe verantwortlich ist Was diese Operation allerdings in Abh ngigkeit von ihrem Ausf hrungskontext genau bewirkt und ob bzw wie sie sich auf weiteren in den Dom nenklassen definierten Operationen abst tzt ist in unseren bisherigen zumindest bez glich des Klassenmodells eher statischen Betrachtungen noch nicht ausge dr ckt Zus tz
271. lte Implementations Umgebung m das Implementationsmodell implementation model besteht aus dem ausf hrlich do kumentierten Quellcode und den zus tzlichen Dateien zur Anwendungs Erstellung build Q das Testmodell test model spezifiziert die Komponenten Integrations und System testf lle Die f nf Modelle werden mit den T tigkeiten Anforderungsermittlung Konstruktion und Test iterativ und inkrementell erstellt Entwurf und Implementation 25 Anforderungs ermittlung Konstruktion Anforderungsmodell Entwurfsmodell Analysemodell Implementationsmodell Testmodell Abb 2 7 Teilprozesse und Modelle in OOSE JCJ 92 Jacobson verteilt die in Use Cases spezifizierte Funktionalit t bez glich der Perspektiven Pr sentation Information und Verhalten auf Objekte im Analysemodell Hierbei unterschei det Jacobson Schnittstellenobjekte Entit tsobjekte und Kontrollobjekte Diese Modelle die nen der Kommunikation sowohl mit dem Auftraggeber als auch mit den Entwicklern Die auf den Modellen der Anforderungsermittlung aufbauende Konstruktion besteht aus dem Entwurf und der Implementation Im Wesentlichen besteht die Grundidee des Entwurfs nach OOSE im Hinzuf gen einer vierten Perspektive der Implementations Umgebung Abb 2 8 Analyseklassen werden zu Teilsystemen des Entwurfs Bl cke vgl JCJ 92 Auch Jacob son bernimmt also das Analysemodell als erste N herung des Entwurfsmodells Er legt be sonderen Wert auf die
272. m spezifiziert genau eine konkrete Ausf hrung des Use Cases Auch eine Menge von Interaktionsdiagrammen kann nicht alle m glichen Abl ufe erfassen vgl PTA94 RAB96 Zudem repr sentieren viele Use Cases komplexe Aufgaben Die Zerlegung solcher Aufgaben erfolgt ber uses und extends Beziehungen zwischen Use Cases Diese Beziehungen lassen sich nicht auf die Interaktionsdiagramme fortsetzen so dass letztere entweder unvollst ndig 48 Probleme der Anforderungsermittlung mit Use Cases sind oder aber bei der Darstellung des vollst ndigen Ablaufs schnell un bersichtlich werden siehe z B Abb 4 4 Dementsprechend sollte eine geeignete Use Case Verfeinerung Bau steine zur Modellierung des Kontrollflusses beeinhalten und alle m glichen Abl ufe in einem Diagramm ausdr cken k nnen In der Anforderungsspezifikation wird nicht nur spezifiziert welche Funktionalit t ben tigt wird sondern auch wann bzw in welchen Reihenfolgen und mit welchen Auswirkungen Hierzu werden z B Datenflussdiagramme s z B Yourdon89 RBP 91 PagSix94 oder Informationsfluss bzw Kooperationsdiagramme KWR96 Hasselbring98 verwendet Die textuelle Spezifikation von Use Cases nach Jacobson sowie Interaktionsdiagramme er scheinen hierzu nicht ausreichend Kommen wir zu dem von Jacobson vorgeschlagenen Metamodell der Use Cases Insbeson dere die unklare bzw fehlende Semantik der von Jacobson angegebenen uses und extends Beziehungen zwi
273. mat Scenario Browser Sj Anmelden A de A at ari al Scenario 4107 Geld Auszahlen Geld Einzahlen Geld Transferieren Verte Einf hren Karte Lesen Karte Einziehe gt x t La 3 Erfolgreiche Anmeldung ep E x Falsche PIN l E Scenario 4109 N Scenario 4107 j P S 4 A 4 lin Processed by system Actor r Vollst ndigkeitsmetriken comment Einfache Klassen berdeckung 0 0769231 ee Episode ce f Karte Einf hren Klassen berdeckung 0 153846 Su Protocol r Validierungsmetriken coverage Use Case Schritt berdeckung 1 0 1 0 d 5 Karte Lesen 2 Use Case Kanten Uberdeckung 1 0 1 0 Boundary Interior berdeckung 1 0 1 0 d Szenario berdeckung Zykeln 1 0 s PIN Anfordern 5 Karte Schreiben s PIN Pr fen D Abb 20 10 SCORESTOOL Szenario Browser Szenario Generierung Generator Framework als konfigurierbarer Cross Compiler verstanden werden der die Mo delle der SCORES Anforderungsspezifikation und die Validierungs bzw Verifikationsproto kolle in unterschiedliche Zielmodelle bzw Sprachen bersetzen kann vgl K sters97 Schulte97 Abb 20 9 zeigt vereinfacht das Schema der Generierung Zun chst erstellt der Analytiker mit Hilfe der Modellierungswerkzeuge z B eine Objektkonstellation Anschlie Bend w hlt er gem
274. mer ORACLE Kartenleser gesperrt AND Karte im KartenLeserAND Karte lesbar AND Code g ltig PIN Anfordern PINAnfordern PIN ORACLE PIN OK Auswahl anzeigen Bedienpult MentiAnzeigen END TESTCASE KarteEinf hren ROOTCLASS Kartenleser Bankleitzahl String 8 Kontonummer String 10 G ltigkeitsdatum Date Kartennummer Integer BEGIN Der Bankkunde f hrt die Karte in den Kartenleser ein END TESTCASE PINAnfordern ROOTCLASS Bedienpult PIN Integer BEGIN Der Bankkunde gibt die PIN ein END Abb 15 6 Black box Testf lle zum Use Case Anmelden Kapitel 16 SCORES grey box Test Die black box Testf lle des vorigen Kapitels pr fen die Anwendung gegen die kontextuelle und die Interaktionsinformation der Anforderungsspezifikation Wir wollen dar ber hinaus noch pr fen ob die Implementation der systeminternen Information der Anforderungsspezi fikation gen gt Mit den black box Testf llen k nnen wir dies nur indirekt indem wir die an der Benutzungsoberfl che oder ggf ber externe Abfragem glichkeiten der verwendeten Datenbank beobachtbaren Zust nde und Zustands nderungen untersuchen Verwenden wir nun die bei der Simulation der Episoden festgehaltenen systeminterne Inter aktionen als Testmodell so m ssen wir beachten dass Episoden zun chst nur interne Inter aktionen zwischen Dom nenklassen widerspiegeln Wir fassen die systeminterne Information aller Episoden zun chst geeignet im sogenann
275. mit funktionsf higen generierten Dom nenklassen zur Validierung und Verifikation der Anforderungsspezifikation verwendet werden Entwurf Eine der St rken der objektorientierten Softwareentwicklung ist die Durchg ngig keit der Methoden von der Anforderungsermittlung OOA ber den Entwurf OOD bishin zur Implementation OOP In bezug auf die Anforderungsspezifikation mit SCORES stellt sich beim Entwurf nat rlich die Frage ob die in den Episoden protokol lierte systeminterne Information im Entwurf weiter verwendet bzw adaptiert werden oder ob nur neue entwurfsspezifische dynamische Sichten konstruiert und verwendet werden Jacobson z B schl gt vor die einem Use Case zugeordneten Teile eines Mo dells zu isolieren und dann auf die diesem Use Case zugeordneten Entit ten anderer Modelle abzubilden s Kap 12 in Carroll95 Wir glauben dass in objektorientier ten Entw rfen solche in Kontroll Klassen implementierte und isolierte Funktionali t t gerade in Bezug auf die Testbarkeit mit Vorsicht behandelt werden muss GUI Unterst tzung In den abgeleiteten black box und SCORES grey box Testf llen ist der Bezug zur Benutzungsoberfl che zur Zeit nur ber die Verfolgbarkeit der entspre chenden Interaktionsschritte bzw Wurzeloperationen m glich Zur GUI gest tzten Ausf hrung der Tests muss schon bei der Anforderungsermittlung mehr Information r 7717 1 17 e H Initialisieren Stimulieren Validieren Teste
276. n Die Rechner wurden schneller die Aufgaben die jetzt mit ihnen erledigt werden konnten umfangreicher und anspruchsvoller Viele Auswertungen und Volks Z hlungen wurden jetzt von den elektronischen Helfern bernommen Eine Person konnte die Realisierung der gestellten Aufgabe nicht mehr allein bew ltigen Es mussten Dinge besprochen ver einbart und festgehalten werden Vielleicht wurde die Pr fung von Programmen oder Teilen davon bereits zu diesem Zeitpunkt von anderen Personen vorgenommen Die Gruppe der Tester entstand Der Test die berpr fung ob eine gestellte Aufgabe entsprechend umgesetzt und realisiert wurde bedarf der genauen Kenntnis der gestellten Aufgabe Was soll berechnet werden was ist das erwartete Ergebnis und wie kann die berpr fung vorgenommen werden Das Wie besch ftigt die Forschung seit den 70er Jahren Ein unstrukturierter Test ein Test aus dem Bauch heraus ist leider immer noch in der Praxis eine h ufig anzutreffende Test Metho de Heutzutage kann von einer Konsolidierung bei den Testmethoden f r prozedurale Software ausgegangen werden Es ist klar welche Verfahren bei welcher Art von Software zur wel chen Fehlerhinweisen f hren bzw am besten geeignet sind M ngel und Fehler aufzudecken Neue Herausforderungen entstehen durch das objektorientierte Vorgehen Testmethoden f r prozedural entwickelte Programme lassen sich nur bedingt zur Pr fung objektorientierter Syst
277. n Zeitraum unter Spitzenbelastungen z B Transaktionen oder Arithmetik oder konfrontieren es Black box Test gegen die Anforderungsspezifikation 35 mit einer umfangreichen Datenmenge Massentest Der Systemtest ist nicht zu verwechseln mit dem Abnahmetest der vom Auftraggeber auf seiner eigenen Plattform vorgenommen wird und eine anders gelagerte Zielsetzung hat PagSix94 Im Weiteren stellen wir zun chst einige klassische und dann die bekannten objektorien tierten Ans tze zum Test der Anwendung gegen die Anforderungsspezifikation vor Celentano et al geben eine Methode zum System und Abnahmetest an CGL81 Sie be tonen die Entwicklersicht beim Systemtest im Gegensatz zur Benutzersicht beim Ab nahmetest sowie die Notwendigkeit neben der reinen Funktionalit t den Aufgabenhierarchien auch die erlaubten und nicht erlaubten Abl ufe zu testen unterscheiden also positives und negatives Testen Den Hauptunterschied zwischen dem System bzw Abnahmetest und anderen Testt tigkeiten sehen Celentano et al in folgenden Punkten e Der System bzw Abnahmetest testet gegen die Anforderungsspezifikation der Komponenten und Integrationstest gegen Entwurfsdokumente e Die Sichtweise ist im System und Abnahmetest eher funktional Komponenten und Integrationstest konzentrieren sich auf die innere Struktur der Anwendung e Der Systemtest wird haupts chlich vom QS Team durchgef hrt der Abnahmetest in der
278. n Es sind alle Pfade im KBD durchlaufen Bei rein objektorientierten Sprachen wie z B Smalltalk 80 subsumiert der C 1 Test die An weisungs berdeckung Cg da jeder atomaren Anweisung eine Botschaft entspricht Die 100 ige C 2 berdeckung kann als minimales Endekriterium bei der Pr fung objektori entierter Anwendungen angesehen werden wenn im Klassentest die Zweig berdeckung f r jede Klasse bereits erreicht wurde Ansonsten sollte die C 3 berdeckung angestrebt wer Testausf hrung 189 den da erst diese auf Iterationen sowie direkt und indirekt rekursive Aufrufe abzielt Die C n berdeckung l sst sich zu 100 nur f r zyklenfreie Klassen Botschaftsdiagramme errei chen und ist somit analog zur Szenarien und zur vollst ndigen Pfad berdeckung in Use Case Schrittgraphen f r die meisten Anwendungen ohne einschr nkende Nebenbedingun gen nicht erreichbar vgl hierzu Beispiel 10 4 Strukturell datenbezogen F r daten bzw zustandsbezogene Testkriterien betrachten wir die mit def und uses mar kierten Kanten des KBD In Analogie zu den datenflussorientierten Kriterien beim Test pro zeduraler Programme geben wir die folgenden drei Kriterien an Q Mindestens eine der m glichen Definitionen mindestens eine Benutzung Q Alle m glichen Definitionen mindestens eine Benutzung Q Alle m glichen Definitionen und Benutzungen Im Prinzip sollten bei ausreichenden Klassentests alle m glichen Definitionen
279. n wie z B Kartenleser betriebsbereit oder Karte les bar Kontextschritt Karte Einf hren In Use Case Anmelden Vorbedingung Kartenleser betriebsbereit Nachbedingung Karte im Kartenleser UND Kartenleser gesperrt END Karte Einf hren Interaktionsschritt Karte Lesen In Use Case Anmelden Vorbedingung Karte im Kartenleser UND Kartenleser gesperrt Nachbedingung Karte lesbar UND Code g ltig ODER NICHT Code g ltig ODER NICHT Karte lesbar END Karte Lesen Interaktionsschritt PIN Anfordern In Use Case Anmelden Vorbedingung Karte im Kartenleser UND Kartenleser gesperrt UND Code g ltig Nachbedingung PIN gelesen ODER Abbruch END PIN Anfordern Interaktionsschritt PIN Pr fen In Use Case Anmelden Vorbedingung Karte im Kartenleser UND Kartenleser gesperrt UND Karte lesbar UND Code g ltig UND PIN gelesen Nachbedingung PIN OK ODER NICHT PIN OK Use Case Schrittgraphen 67 END PIN Pr fen Interaktionsschritt Auswahl Anzeigen In Use Case Anmelden Vorbedingung Karte im Kartenleser UND Kartenleser gesperrt UND Karte lesbar UND Code g ltig UND PIN gelesen UND PIN OK Nachbedingung Bedienpult auswahlbereit END Auswahl Anzeigen Interaktionsschritt Karte Schreiben In Use Case Anmelden Vorbedingung Karte im Kartenleser UND Kartenleser gesperrt UND Karte lesbar UND Code g ltig UND PIN heute dreimal falsch ODER Abbruch Nachbedingung WENN PIN heute dreimal falsch DANN Karte gesperrt END Karte Schreiben Interaktionsschritt Karte Anbieten In Use Ca
280. n Personen verst ndlich ist Die Konkretisierung Negotiation der Anforderungen hat das Ziel hinsicht lich der Anforderungen an das Produkt eine weitgehende bereinstimmung zwischen allen involvierten Personen zu erzielen Allgemein wird als Hauptziel bei der Spezifikation der An forderungen die Ableitung einer m glichst formalen Produktspezifikation angesehen die als Referenzdokument bei den nachfolgenden Entwicklungst tigkeiten eingesetzt wird Hierzu muss die Dokumentation der Anforderungen f r die beteiligten Personengruppen eine Reihe von Modellen mit unterschiedlichen graphischen Darstellungen und Abstraktionsebenen be reitstellen beispielsweise formale Spezifikationen f r Softwareentwickler graphische Dar stellungen f r Manager oder umgangssprachliche Beschreibungen f r Benutzer Beim Validieren und Verifizieren der Anforderungen ist nicht nur sicherzustellen dass die Anfor derungsspezifikation vollst ndig ist und mit den Erwartungen der Benutzer bereinstimmt sondern es muss auch gew hrleistet werden dass die spezifizierten Anforderungen konsistent und korrekt sind Beim Validieren der Anforderungen ist eine enge Zusammenarbeit zwi schen Benutzer und Analytiker erforderlich denn ein versierter Analytiker kann zwar wider spr chliche Anforderungen in der Anforderungsspezifikation entdecken prinzipiell K nnen aber nur Auftraggeber bzw Benutzer validieren ob die Anforderungsspezifikation mit ihren Erwartungen an das zu ers
281. n Tempor re Assoziation Botschaftsparameter Interaktion Stimulus Botschaft Prozeduraufruf Use Case Interaktionsdiagramm Botschaftsfolge Teilsystem Teilsystem Paket Tab 13 1 Verfolgbarkeit in OOSE nach JCJ 92 Nat rlich wundert es nicht auch in kommerziellen Frameworks vgl z B GHJ 94 BMR 97 Johnson97 Ziillighoven98 hnliche Entwurfsentscheidungen vorzufinden da sich Coad und Yourdon CoaYou91 explizit auf das MVC Framework GolRob89 be rufen und auch Jacobson die OOSE auf in kommerziellen Projekten gewonnenen Erfahrun gen aufgebaut hat und umgekehrt JCJ 92 JGJ97 Auch Z llighoven schreibt Die anwendungsfachliche Modellierung bestimmt die technische Dies geschieht nicht durch eine einfache Eins zu eins Transformation aller fachlichen Begriffe in Klassen und aller Umgangsfor men in Operationen Trotzdem l sst sich das im Modell des Anwendungsbereichs realisierte Be griffsgeb ude ohne Modellbruch und erkennbar struktur hnlich in Klassen und Klassenbeziehungen bertragen Z llighoven98 Wie Cook und Daniels in der Einleitung zu ihrer objektorientierten Entwicklungsmethode Syntropy schreiben gilt also vgl insbesondere auch CoaYou91 JCJ 92 All object oriented methods are based on the notion that objects identified in the problem anal ysis have a meaningful place in the solution design CooDan94 Im Normalfall werden jedoch in der inkrementellen iterativen Entwicklung w hrend des Ent
282. n auch Strau und H rnke Entscheidungstabellen Sie schreiben 38 Probleme der Qualit tssicherung f r objektorientierte Anwendungen Nach unserer Erfahrung ist es nur mit den sp teren Benutzern eines Systems den fachlichen Experten m glich komplexe praxisrelevante Testf lle zu finden ohne gleichzeitig eine Masse von nicht praxisrelevanten Tests zu produzieren Deshalb ben tigen wir in unserem Kontext eine Darstellungsform die auch von den Benutzern verstanden wird damit wir diese in die Testfallent wicklung einbeziehen k nnen StrH r98 Allerdings treten bei der Verwendung der Entscheidungstabellen folgende Probleme auf e Die Erstellung konsistenter Testf lle ist nicht immer sichergestellt d h die Kombi nation unvertr glicher Testpr fpunkte l sst sich bei der Testfallbildung prinzipiell nicht vermeiden e Die Dokumentation von Abh ngigkeiten zwischen Varianten verschiedener Testkri terien Verfolgbarkeit wird nicht besonders unterst tzt was f r die Qualit tssiche rung und die Pflege der Testf lle problematisch sein kann Zus tzlich geben Strau und H rnke einen Ansatz zur Automatisierung von Tests ber die Benutzungsschnittstelle an der jedoch deutliche Schw chen insbesondere beim Test solcher Anforderungen Gesch ftsvorf lle hat die unterschiedliche Einga bereihenfolgen unterst tzen Da in den erstellten Testskripten die Reihenfolge fest vorgegeben war wurde ein Mastertestskript
283. n en Diagramme Quellcode die ausf hrbare Anwendung und die Testdokumente selbst Eine wichtige Unterscheidung erfolgt zwischen einem Fehler und seiner Ursache Ein Fehler ist das Abweichen eines berechneten beobachteten oder gemessenen Werts oder eines Zu stands von dem entsprechenden spezifizierten richtigen Wert bzw Zustand z B die Ausgabe eines falschen Funktionswerts Die Fehlerursache kann dabei unbekannt sein Au erdem k nnen mehrere Fehler dieselbe Ursache haben Weiter differenzieren wir zwischen einem Defekt und einem Ausfall Q Bei einem Defekt weicht ein Merkmal des Pr fgegenstands von seiner Spezifikation ab Defekte k nnen m ssen aber nicht als Fehlerursache die Funktionst chtigkeit des Pr fgegenstands beeintr chtigen z B fehlerhaft realisierte Anforderungen aber auch mangelhafte Lesbarkeit Verletzung von Dokumentationsrichtlinien Q Ein Ausfall bedeutet dass der Pr fgegenstand aufgrund eines Defekts nicht mehr in der Lage ist die geforderte Funktion auszuf hren z B Absturz Livelock oder Deadlock Zustand Die T tigkeiten Pr fen Debuggen Verifikation und Validierung werden folgenderma en ab gegrenzt Q Pr fen ist das gezielte Suchen nach Fehlern und Defekten des Pr fgegenstands Ge pr ft werden s mtliche Artefakte die bei der Softwareentwicklung entstehen Auch 1 Begriffe der Objektorientierung werden von uns vorausgesetzt s z B BHJ 98 Begriffe und Gebiete der Qual
284. n nach der Anwendung solcher Verbesserungen Effizienzsteigerungen von bis zu 35 gemessen vgl PVB95 Nach diesem berblick wenden wir uns nun den Techniken und dem methodischen Vorge hen bei der Validierung der Anforderungsspezifikation zu Durch das Konzept der Kontext schritte kann in SCORES die Anforderungsspezifikation von der kontextuellen Information bis zur Interaktionsinformation validiert werden vgl KPR 97 KPW98 Neben Analytikern Testern und Dom nenexperten sind auch verschiedene Benutzergruppen also die Stakehol der der entsprechenden Gesch ftsprozesse beteiligt Sie validieren in schrittweisen Inspek tionen und Walk Throughs die funktionale Zerlegung und das externe Verhalten der Anwendung wobei das Hauptaugenmerk auf der fachlichen Vollst ndigkeit und Korrektheit der Anforderungsspezifikation in Bezug auf den Anwendungsbereich liegt Die Zusammen arbeit aller betroffenen Personengruppen ist eine notwendige Voraussetzung f r die erfolg reiche Validierung und sichert dar ber hinaus zu dass die textuellen Teile der qualit tsgesicherten Anforderungsspezifikation in einer von allen Parteien akzeptierten und verstandenen Sprache formuliert sind 9 2 Funktionale Zerlegung Die Zerlegung der funktionalen und organisatorischen Aspekte der Gesch ftsprozesse spie gelt sich in Aktoren sowie den Aufgaben von Use Cases und Use Case Schritten wider Aus der SCORES Anforderungsspezifikation werden die Aktor Hierarchie
285. n und umgeleiteten Kanten repr sentieren explizit die Tatsache dass Benutzungen der Operation a dynamisch an Ob jekte sowohl der Klasse k4 als auch der Klasse k gebunden werden k nnen Zeilen 6 9 in Funktion PolyKBD Abb A 1 zeigt den resultierenden Algorithmus Generiere KBDA Abb A 2 die verwendete Funktion PolyKBDA 1 Wir qualifizieren den Namen einer Methode bzw Variablen indem wir ihm mit ab gesetzt den Namen der sie deklarierenden Klasse voranstellen Funktion PolyKBDA ak GO M oO ON Oo Eingabe Klassen K Klassen Botschaftsdiagramm KBD V E P Ausgabe Klassen Botschaftsdiagramm KBDa mit polymorphen Benutzungen FORALL k k K DO Alle Paare von Klassen IF k lt k THEN Alle Vererbungsbeziehungen FORALL oe k redefinedOperations DO IF ak k lt k lt k Aoe k operations THEN E EU k 0 k 0 inheritance Kanten f r die polymorphen Benutzungen erzeugen FORALL e k p k 0 message e E DO ees k p k 0 message E Euvue P i PU e e FORALL IF END PolyKBD Abb A 2 Funktion PolyKBD 239 Wie betrachten noch kurz die Zeit und Raum Komplexit t der Generierung des KBD OPS bezeichne die Menge aller Operationen im Dom nen Klassenmodell ES die Menge aller Episodenschritte im Verifikationsprotokoll Q Die Ermittlung der Knoten Zeilen 2 4 ben tigt OU OPS I Schritte die Benutzungs kanten w
286. n98 Robert Poston Making Test Cases from Use Cases Automatically Proc Quality Week Europe 98 Br ssel Belgien 1998 PTA94 Colin Potts Kenji Takahashi Annie I Anton Inquiry based requirements analysis IEEE Software Nr 3 M rz 1994 S 21 32 PVB95 Adam A Porter Lawrence G Votta Victor R Basili Comparing Detection Methods for Software Requirements Inspections A Replicated Experiment IEEE Transactions on SE Jahrg 21 Nr 6 Juni 1995 S 563 575 RamEdw93 Balasubramaniam Ramesh Michael Edwards ssues in the Development of a Requirements Traceability Model Proc 1 IEEE Int Conf on Requirements Engineering RE93 San Diego Los Alamitos Jan 1993 S 256 259 RAB96 Bj rn Regnell Michael Andersson Johan Bergstrand A Hierarchical Use Case Model with Graphical Representation Proc ECBS 96 IEEE Int Workshop on Engineering of Computer Based Systems IEEE Press M rz 1996 RBP 91 James Rumbaugh Michael Blaha William Premerlani Frederick Eddy William Lorensen Object Oriented Modeling and Design Prentice Hall Englewood Cliffs New Jersey 1991 RegRun98 Bj rn Regnell Per Runeson Combining Scenario based Requirements with Static Verification and Dynamic Testing Proc REFSQ 98 4U Int Workshop on RE Foundation for SW Quality Pisa Italy 1998 Riedemann97 Eike Hagen Riedemann Testmethoden f r sequentielle und nebenl ufige Software Systeme B G Teubner Stuttgart 1997 Ritter2000 Thorsten Ritter Ent
287. nalyse von Benutzungs und soge nannten Objekt Interaktions Szenarien das Verst ndnis der gegenseitigen Be schr nkungen der Anforderungen und des Software Entwurfs verbessern kann Rosson99 Wir lesen Relevante Arbeiten Pr zisierung von Use Cases 53 User tasks and the software designed to support them are independent Tasks set requirements for new systems as systems are developed their software and hardware characteristics create con straints or opportunities for the tasks The paper argues for a more direct integration of the design of user tasks and their corresponding software design an integration provided through object ori ented analysis and design OOAD of user interaction scenarios Rosson99 Beide Ans tze erg nzen einerseits die Spezifikation der Oberfl che und erm glichen ande rerseits die Nach Verfolgung der Dom nenklassen der Anforderungsspezifikation zu den Entwurfsklassen Wir sprechen den zweiten Aspekt im Verlauf der Arbeit noch an Glinz entwickelt ein auf dem Zustandsdiagramm basierendes integriertes formales Modell zur ausf hrbaren Spezifikation und Komposition von Szenarien Glinz95 Ein Sze nario ist als ein Statechart mit genau einem Ein und Ausgang modelliert Glinz gibt Regeln zur Komposition von Statecharts in ein integriertes Modell an welches das Verhalten der Anwendung modelliert Aufbauend auf der Semantik f r Statecharts vgl HarNaa96 und den Kompositionsregeln leitet Glinz
288. nd Abnahme Tests mit Abdeckung des Pflichtenhefts eine prominente Rolle Pr zise Vorgaben f r die Pr fung der Anwendung gegen die objektorientierte Anforde rungsspezifikation fehlen jedoch weil die Anforderungsermittlung und insbesondere ihre Qualit tssicherung stiefm tterlich behandelt wird vgl M lWie98 Aus herk mmlichen Verfahren zur Qualit tssicherung bei der Anforderungsermittlung wie z B Reviews und Pro totypen vgl Boehm84 Davis90 Gerrard94 Pohl96 WBM96 ergeben sich dar ber hi naus keine unmittelbar verwendbaren Testf lle f r den Test der Anwendung gegen die Anforderungsspezifikation Im Endeffekt stehen die Tester vor der in Abb 14 1 skizzierten Situation nicht testbarer Anforderungen vgl Poston94 Ziele 159 Abnahmetest Testf lle Systemtest gt 9 Test der Anforde Ny Ge rungsspezifikatign J Testf lle EN Am A amp D Fehler Codierungsfehler Abb 14 1 Vom Test der Anforderungsspezifikation zum System und Abnahmetest Daneben wird bei der Vergabe von Software Entwicklungsauftr gen oft vertraglich der Nachweis struktureller Testkriterien festgelegt Diese sind nat rlich nicht das Ziel bzw die Grundlage herk mmlicher black box Testverfahren Zwar kann nach den black box Tests die erreichte strukturelle berdeckung gemessen werden Im Falle nicht erf llter Kriterien haben die Tester jedoch keine Unterst tzung bei der Ableitung weiterer
289. neben dem SCORES grey box Test auch Integrations und Regressionstests f r objektorientierte Anwendungen vgl Winter98 Die erzeugten Testf lle sind aufgrund der gew hlten Einschr nkung auf ffentliche Methoden und den Verzicht auf besondere Testmethoden auch in Bezug auf das Testorakel weitestgehend sprachunabh ngig Test der Anforde rungsspezifikation Testf lle rv Systemtest IR estf lle Fehler der Fehler der Anforderungs pst der Soft Anforderungs ermittlung ermittlung fu e warespezifikation Testf lle FF Si Testf lle Entwurffehler a e EE A Codierungsfehler Abb 21 3 Qualit tssicherung mit SCORES 214 Res mee Die Negativ Ergebnisse bez glich struktureller Klassentests und der Generierung von Ob jekt Konstellationen stellen den propagierten Vorteilen der Objektorientierung wie z B Wie derverwendbarkeit und h here Produktivit t einen erh hten Aufwand beim Test entgegen Dieser kann durch die SCORES grey box Tests zumindest teilweise wieder aufgefangen werden 21 2 Erfahrungen Bis jetzt haben wir die Methode und das Werkzeug haupts chlich in eigenen Re Engineering Projekten erprobt in denen wir die Anforderungen an einige kleinere bis mittelgro e z T kommerzielle Anwendungen mit SCORES spezifiziert und gepr ft haben Die Ergebnisse die ser Aktivit ten f hrten zu einer wiederholten berarbeitung bzw Pr zisierung des method
290. nen Werte Obergrenzen dar vgl PalSch94 34 Probleme der Qualit tssicherung f r objektorientierte Anwendungen s chlich in den sp ten Phasen der Softwareentwicklung gepr ft wird vgl Kapitel 1 kon zentrieren wir uns auf den Test der Anwendung gegen die Anforderungsspezifikation System und Abnahmetest Mit dem h ufig geh rten Argument dass einer Anwendung ihre Implementationssprache von Au en nicht anzusehen ist wurde der System und Abnahmetest als Test gegen die Anforderungsspezifikation f r objektorientierte Anwendungen bisher kaum behandelt In Binders Worten Established practices for system testing can be transferred to object oriented implementations with no loss of generality Binder96a Anforderungen an objektorientierte Anwendungen sind jedoch zunehmend mit objektorien tierten Methoden und Modellen spezifiziert gegen die getestet werden muss Dies l sst die bertragbarkeit herk mmlicher Verfahren auf objektorientierte Anwendungen problema tisch erscheinen Zun chst pr zisieren wir die grunds tzliche Problemstellung mit einigen allgemeinen Defi nitionen und Erl uterungen zum System und Abnahmetest sowie Arbeiten zum Test gegen herk mmliche Anforderungsspezifikationen und skizzieren dann in Abschnitt 3 4 die rele vanten Arbeiten zum Test gegen objektorientierte Anforderungsspezifikationen Der IEEE Standard 610 definiert den Systemtest wie folgt System testing Testin
291. nen in Dom nenklassen sollen also nicht vorschreiben wie bestimmte Teil Aufgaben implementiert werden sollen sondern pr zi sieren lediglich auf einer feingranulareren Ebene welche Wirkung sie auf Instanzen von Do m nenklassen haben Eines der Hauptprobleme von Ans tzen die auf mehreren Modellen basieren besteht darin die involvierten Modelle konsistent zueinander aufzustellen und die Konsistenz bei nderun gen bzw Erweiterungen zu erhalten vgl z B RBP 91 Berard93 Behringer97 Hierzu m ssen die jeweiligen Modellierungselemente einander zugeordnet werden Als Problem er weist sich hierbei die Abstraktionsliicke zwischen dem Use Case Modell und dem Dom nen Klassenmodell s S 59 Abb 5 1 Um diese L cke zu berbr cken haben wir die Granularit t von Use Cases auf die von Schritten in Use Case Schrittgraphen heruntergebrochen Dies erm glicht es die Spezifika tionen der verhaltensbezogenen und der strukturellen bzw datenbezogenen Aspekte der An forderungen aneinander koppeln wir koppeln also Use Case Schrittgraphen und das Klassenmodell Die resultierende integrierte Anforderungsspezifikation beschreibt sowohl die fl chtigeren funktionalen und ablaufbezogenen Aspekte der Anforderungen als auch deren stabilere strukturelle Fassetten Wir n hern uns somit nach der bereits im Use Case 86 Kopplung von Use Cases und Klassenmodell Schrittgraphen ausdr ckbare kontextuelle und Interaktionsinformati
292. ng Verification and Reliability Jahrg 6 1996 S 125 252 Binder96b Robert V Binder The FREE Approach For System Testing Object Magazine Jahrg 5 Nr 9 Feb 1996 S 72 79 81 BlaFr 98 G nther Blaschek Joachim Hans Fr hlich Recursion in Object Oriented Pro grams Journal of Object Oriented Programming Nov Dez 1998 S 28 35 Boehm84 Barry B Boehm Verifying and Validating Software Requirements and Design Specifications IEEE Software Jahrg 1 Nr 1 Jan 1984 S 75 88 Booch94 Grady Booch Object Oriented Analysis and Design Addison Wesley Reading Mass 1994 Brooks87 Frederick P Brooks Jr No Silver Bullet Essence and Accidents of Softwae Engineering IEEE Computer Jahrg 20 Nr 10 April 1987 S 10 20 BMR 97 Frank Buschmann Regine Meunier Hans Rohnert Peter Sommerlad Michael Stal Pattern Oriented Software Architecture A System of Patterns J Wiley amp Sons Chichester 1996 Carroll95 John M Carroll Ed Scenario Based Design Envisioning Work and Techno logy in System Development J Wiley amp Sons New York 1995 CarSto94 David Carrington Phil Stocks A Tale of Two Paradigms Formal Methods and Software Testing TR Nr 94 4 Software Verification Research Centre Univ Queensland Australia 1994 CGL81 Augusto Celentano Carlo Ghezzi Frederica Liguori A Systematic Approach to System and Acceptance Testing in B Chandrasekaran S Radicchi Hrsg Com puter Program Testing zugl
293. nge aller in der Klasse k bekannten Opera tionen Entsprechend den obigen Ausf hrungen ist eine Menge B von Klassen konform zu ei ner Menge A von Klassen wenn jede in B enthaltene Klasse konform zu mindestens einer in A enthaltenen Klasse ist In diesem Fall schreiben wir A cy B 7 2 Klassenbereiche Wir beschreiben die Aufgaben von Use Cases und Use Case Schritten durch Vor und Nach bedingungen Die Vorbedingung gibt die Voraussetzungen an mit der die Aufgabe begonnen werden kann die Nachbedingung gibt m gliche Auswirkungen bzw Ergebnisse der Aufga benbearbeitung an Es stellt sich nun die Frage ob die Bedingungen mit konkreten Objekten oder auf der Klassenebene spezifiziert werden sollen Genauer gesagt m ssen wir entschei den ob wir f r jeden Use Case und jeden Use Case Schritt eine konkrete Objektkonstellation oder aber lediglich die Klassen eventuell involvierter Objekte und eine m glichst minimale Menge von Beschr nkungen vorgeben sollen die angeben welche Objektkonstellationen vor bzw nach Bearbeitung der Aufgabe vorliegen K nnen 1 Eine Klasse B wird konform zu einer Klasse A genannt wenn B jede Operation von A enth lt die Klasseninvariante von B die der Klasse A impliziert und die Vorbedingung jeder Operation von A die der entsprechenden Operation von B impliziert sowie umge kehrt die Nachbedingung jeder von B redefinierten Operation die der entsprechenden Operation von A impliziert vgl FNZ96 Meyer97 Poetzsch97
294. ngsspezifikation Daher sind diese Verfahren bei der Pr fung der Anwendung gegen eine objektorientierte Anfor derungsspezifikation nicht anwendbar Grunds tzlich gilt dass die Produkte aller T tigkeiten bei der Softwareentwicklung einerseits selbst qualit tsgesichert und andererseits f r den Test abh ngiger Produkte herangezogen werden m ssen Mit Blick auf Abb 1 2 s Seite 10 argumentieren wir folgenderma en f r die Auswahl der Qualit tssicherung bei der Anforderungsermittlung und den System und Abnahme Test gegen die Anforderungsspezifikation als Inhalt dieser Arbeit Q Q Die Entwicklung und damit die qualit tssichernden T tigkeiten beginnen mit der An forderungsermittlung bzw der Pr fung der Anforderungsspezifikation Aufgrund des Kosten Nutzen Verh ltnisses Entstehungsort Aufdeckungswahr scheinlichkeit und Behebungskosten von Fehlern versprechen die Anforderungser mittlung und darauf aufbauenden Tests gegen die Anforderungsspezifikation die gr te Effizienz und Akzeptanz in der industriellen Praxis Tab 2 1 s Seite 18 Die grunds tzliche Fragestellung dieser Arbeit lautet somit Wie wird eine objektorientierte Use Case basierte Anforderungsspezifika tion gepr ft bzw erst pr fbar gestaltet und wie k nnen Testf lle f r den Test gegen die gepr fte Anforderungsspezifikation abgeleitet werden 56 Probleme der Anforderungsermittlung mit Use Cases Teil I Anforderungsermittl
295. nicht nachzuvollziehen da Jacobson keine innere Struktur f r Use Ca ses vorschl gt Anwendbarkeit im Test gegen die Anforderungsspezifikation Wie unterst tzen Jacobsons Use Cases nun den Test gegen die Anforderungsspezifikation Jacobson schreibt Offene Fragen und Kritik 49 In the use case test you perform an operation test of the basic courses of the use case that is the expected flow of events The tests of the odd courses are all other flows of events Nor mally we test all use cases one by one Those use cases with an extends association are tested after testing the use cases where it is to be inserted When we test the system the use cases should be tested in parallel both in step and out of step We should also stress the system by running sev eral use cases at the same time Each test is now divided into subtests with different condi tions We can consequently decompose the test hierarchically JCJ 92 In einer empirischen Untersuchung tiber den aktuellen Stand der Verwendung von Szenarien in f nfzehn industriellen Projekten stellen Weidenhaupt et al zun chst Folgendes fest that while many companies express interest on Jacobson s use case approach actual scenario usage often falls outside what is described in textbooks and standard methodologies WPJ 98 Alle befragten Entwickler sehen die Notwendigkeit Systemtests auf der Grundlage von Sze narien zu erstellen und damit dem
296. nierende Schleifen vorliegen Die Vor und Nachbedingungen der Schritte jedoch sollen vor und nach einer Aufgabenbearbeitung immer den Wert true annehmen da im Falle einer verletzten Zu sicherung ja ein Fehler aufgetreten ist Das Ziel dieses Vertragstests vgl Overbeck94 ist es also mit gezielten Szenarien die Nachbedingungen der Schritte negativ zu pr fen d h zu false auszuwerten Kontrollflussorientierte Testverfahren unterscheiden zwischen der einfachen Bedingungs berdeckung C gt Test bei der alle Terme einer Bedingung mindestens einmal den Wert true und einmal den Wert false erhalten m ssen und der Mehrfach Bedingungs berdeckung C3 Test welche die berpr fung aller Wertekombinationen fordert vgl Riedemann97 Die einfache Bedingungs berdeckung wird als ein zu schwaches Kriterium angesehen da sie nicht einmal die Zweig berdeckung umfasst Das Problem der Mehrfach Bedingungs berde ckung ist der exponentielle Anstieg der Testf lle in Abh ngigkeit von der Anzahl der vor kommenden Terme F r den effektiven Test von Programmen wird daher oft die minimale Mehrfach Bedingungs berdeckung herangezogen Die minimale Mehrfach Bedingungs berdeckung die einen guten Kompromiss zwischen der ein fachen und mehrfachen Bedingungs berdeckung darstellt wertet jedes Pr dikat ob atomar oder nicht atomar zu beiden Wahrheitswerten aus Dadurch wird die hierarchische Struktur von Bedingungen ber cksichtigt und jed
297. nig aufschlussreich weil die Methoden im Allg nur eine geringe strukturelle Komplexit t haben vgl Binder96a Daher gilt die Klasse bzw das einzelne Objekt im Normalfall als der kleinste Pr fgegenstand s z B McGreKor94 Binder96a Sneed95 Auch bei der Pr fung einer einzelnen Klasse bzw eines isolierten Objekts treten Schwierig keiten auf Abb 3 1 Q Es m ssen Eingangsnachrichten generiert werden diese enthalten oft Objekte als Parameter F r die Klassen der Parameterobjekte ergibt sich durch die Vererbung und den damit verbundenen Polymorphismus eine mit der Anzahl ihrer Unterklassen exponentiell wachsende Anzahl von Kombinationen Der Pr fgegenstand sowie alle Parameterobjekte untereinander m ssen initialisiert also in einen bestimmten Zustand gebracht werden Sieht das Klassenmodell f r den Pr fgegenstand bzw die Parameterobjekte Assozia tions oder Aggregationsbeziehungen zu anderen Objekten vor sind auch diese ge eignet zu initialisieren Bei der Erstellung des erwarteten Ergebnisses bei der Testausf hrung sind neben dem R ckgabewert der aufgerufenen Methode auch die Parameter und Ergebnisse sowie die korrekte Reihenfolge der bei dem Test ausgef hrten Methoden zu ber ck sichtigen vgl JorEri94 1 Zum Test einer Operation muss ein Objekt der die Operation definierenden Klasse in stanziiert werden es gibt also keine Operationentreiber im herk mmlichen Sinn 32 Probleme der Qualit tssi
298. nstanzen von Unterklassen der in einem Klassenbereichen angegebenen Klassen vorkommen Wir werden diesen Sachver halt in Kapitel 15 Black box Test benutzen Weitere Hinweise daf r welche Klassen durch die Abbildung B den Klassenbereichen der Kontext oder Interaktionsschritten zuge ordnet werden geben wir in Kapitel 8 7 3 Wurzelklasse und Wurzeloperation Die bisherige Zuteilung der Klassen zu Klassenbereichen der Use Cases und Use Case Schrit te sowie die Beschreibung der Aufgaben gibt einen berblick welche Klassen bzw Instan zen welcher Klassen von der Teil Aufgabe betroffen sein k nnen und erm glicht eine grobe Absch tzung der Wirkungen einer Aufgabenausf hrung Wir K nnten diese Wirkung weiter pr zisieren indem wir in der Spezifikation des Use Cases die m glicherweise betrof fenen elementaren Entit ten des Klassendiagramms angeben z B Assoziation a zwischen zwei Objekten der Klassen A und B aufgebaut oder Attribut x einer Instanz der Klasse Y de finiert Damit w re allerdings die Kapselung der Klassen durchbrochen und immer noch kei ne echte Integration der funktionalen Sichten der Use Cases und des Klassenmodells 1 Formal angeben bzw automatisch pr fen k nnen wir diese Regel nur f r den Fall von in OCL oder einer anderen formalen Sprache notierten Bedingungen sehen also in diesem Fall von einer Pr zisierung der Regel ab 90 Kopplung von Use Cases und Klassenmodell Interaktions
299. nte Karte Lesen Karte Anbieten In Use Case Anmelden Bedingung NICHT Code g ltig END Karte Lesen Karte Anbieten Kante Karte Lesen Karte Einziehen In Use Case Anmelden Bedingung NICHT Karte lesbar END Karte Lesen Karte Einziehen Kante PIN Anfordern PIN Pr fen In Use Case Anmelden Bedingung PIN gelesen END PIN Anfordern PIN Pr fen 68 Grundlegende Konzepte Kante PIN Anfordern Karte Schreiben In Use Case Anmelden Bedingung Abbruch gew hlt END PIN Anfordern Karte Schreiben Kante PIN Pr fen PIN Anfordern In Use Case Anmelden Bedingung NICHT PIN OK UND NICHT PIN heute dreimal falsch END PIN Pr fen PIN Anfordern Kante PIN Pr fen Auswahl Anzeigen In Use Case Anmelden Bedingung PIN OK END PIN Pr fen Auswahl Anzeigen Kante PIN Pr fen Karte Schreiben In Use Case Anmelden Bedingung PIN heute dreimal falsch END PIN Pr fen Karte Schreiben Kante Karte Schreiben Karte Anbieten In Use Case Anmelden Bedingung True END Karte Schreiben Karte Anbieten Kante Karte Anbieten Karte Entnehmen In Use Case Anmelden Bedingung True END Karte Anbieten Karte Entnehmen Kante Karte Entnehmen Karte Einziehen In Use Case Anmelden Bedingung Timer gt 60 END Karte Entnehmen Karte Einziehen Abb 5 6 Kanten im Use Case Schrittgraph Anmelden 5 3 SCORES Metamodell I In Hinblick auf die Implementation des vorgeschlagenen hierarchischen Use Case Modells in einem CASE
300. ntwicklung erfolgt eine Ist Analyse des Gesch fts feldes business analysis Danach wird der angestrebte Gesch ftsprozess envisioned busi 16 Entwicklungst tigkeiten ness process als Soll Zustand modelliert business reengineering vgl HamCha94 F r die einzelnen Aufgaben des Gesch ftsprozesses werden der Grad automatisch rechnerge st tzt manuell sowie die Art Standard oder Individualsoftware der DV Unterst t zung festgelegt und ggf im Workflow Managementsystem modelliert Letztendlich werden die den einzelnen Aufgaben entsprechenden Anwendungen angepasst bzw neu entwickelt Wir kommen somit zur Anforderungsermittlung f r eine Anwendung Anforderungsermittlung In der Anforderungsermittlung requirements engineering RE werden informelle Ideen hin sichtlich der Ziele Funktionen und Beschr nkungen eines Softwareprodukts zu einer pr zi sen Spezifikation ausgearbeitet und in der Anforderungsspezifikation sorgf ltig dokumentiert Da die Zufriedenheit der Benutzer mit dem System in zunehmendem Ma e als ausschlaggebendes Kriterium zur Feststellung der Systemqualit t herangezogen wird gewin nen das richtige Verst ndnis f r die Anforderungen und Bed rfnisse des Benutzers deren Spezifikation Dokumentation und Validierung an Bedeutung Der IEEE Standard 610 Glossary of Software Engineering Terminology definiert die An forderungsermittlung requirements analysis als Requirements analysis 1
301. nzfreie hierarchische Spe zifikation der Use Cases und bertragen die uses und extends Beziehungen von Use Cases auf die entsprechenden Use Case Schrittgraphen s Abschnitt 6 4 Vorl ufig reicht die fol gende informelle Beschreibung m Jeder Makroschritt S nakro enth lt einen Verweis RefUC Sakro auf einen anderen Use Case und beschreibt somit eine Teil Aufgabe indirekt indem er den referenzierten Use Case sozusagen aufruft Bei der Bearbeitung eines Makroschritts wird analog zu einem Prozeduraufruf der be nutzte Use Case Schrittgraph sozusagen vom Makroschritt aufgerufen Sei UC eine endli che Menge von Use Cases und uc e UC ein Use Case Schrittgraph mit der Schrittmenge S uc Definition 5 3 Die Makroschritt Referenzfunktion wird definiert als REF S uc gt UC mit REF s falls SA s Makro und REF s RefUC s e UC uc sonst Q Beispiel 5 2 Im Rahmen des Use Cases Anmelden finden wir z B als Kontextschritt das Ein geben der Karte in den Kartenleser des Bankautomaten als Interaktionsschritt die Eingabe der PIN Abb 5 4 zeigt die textuellen Spezifikationen der Use Case Schritte Karte Einf hren 64 Grundlegende Konzepte sowie Karte Lesen des Use Cases Anmelden und den Use Case Makroschritt Anmelden im Use Case Geld Abheben Kontextschritt Karte Einf hren In Use Case Anmelden Beschreibung Der Bankkunde f hrt die Karte in den Kartenleser ein Aktoren Bankkunde Vorbedingung Kartenle
302. ode m Der Ausdruck ml ldentifier liefert den Namen der aufgerufenen Methode m Die Funktion PREFIX ml liefert ggf das dem Methodenaufruf vorangestellte prima ry also eines der drei Schl sselworte this super und new Ist PREFIX ml so handelt es sich um einen dynamisch gebundenen einfachen Methodenaufruf bei PRE FIX ml this um einen dynamisch gebundenen selbstrekursiven Methodenaufruf FUNCTION PolyKBD Eingabe Klassen K Klassen Botschaftsdiagramm KBD V E P Ausgabe KBD mit polymorphen Interaktionen FORALL k k K DO IF k lt k THEN FORALL fe k redefinedFields DO IF 3k k lt k lt k fe k Fields THEN E EU k1 f kof inheritance Kanten f r die polymorphen Aufrufe erzeugen FORALL e k p k fP x e E DO IF xe message this THEN e ki Ak E zs Eve 0 P PU e e LIFE IF ak GO M ON OD END PolyKBD Abb 22 4 Funktion PolyKBD 245 Algorithmus Generiere KBD OMAN DA FWD 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Eingabe Klassen und Interface Deklarationen X Ausgabe Klassen Botschaftsdiagramm KBD V E P V E P Initialisierung FORALL ke K DO Operationen und Variablen Knoten erzeugen FORALL k m k memberDeclarations DO IF k m e k MethodDeclarations THEN method ELSE fiel
303. odell enthaltenen Instanzen vom Typ ValidationClassifier Q Im Folgenden bezeichne uc einen Use Case Schrittgraphen und UC die Menge aller Schritt graphen der Anforderungsspezifikation Als erste einfache Metrik messen wir mit der einfachen Klassen berdeckung MKK x UC gt R welcher Prozentsatz der Klassen im Klassenmodell als Wurzelklasse der Interaktionsschritte in den Use Case Schrittgraphen vorkommen Zun chst ermitteln wir mit der Operation StepGraph rootClasses Set of Class die Wurzelklassen der Schritte eines Use Case Schrittgraphen uc rootClasses U e uc Steps N InteractionStep alllnstances s rootClass 7 1 Vollst ndigkeitsmetriken 93 Hiermit k nnen wir die einfache Klassen berdeckung angeben zu uc rootClasses c KMK LJ e UseCase alllnstances 0 Class alllnstances size 7 2 Esito 100 wenn jede Klasse als Wurzelklasse in mindestens einem Interaktions schritt der Use Case Schrittgraphen vorkommt Von hier an verzichten wir auf die Angabe detaillierter Signaturen f r die definierten Opera tionen bzw Funktionen da alle Metriken den Wertebereich IR haben und der Definitionsbe reich jeweils durch die betroffenen Modellierungs bzw Validierungselemente festgelegt wird Sicherlich werden nicht alle Klassen als Wurzelklassen verwendet d h im Normalfall wird keine 100 ige einfache Klassen berdeckung erreicht Als vollst ndige Klassen berdek kung SE geben wir daher an welcher Prozentsat
304. odukts sowie einfach ableitbarer oder im Idealfall generierbarer System und Abnahmetestf lle aufzurechnen In Hinblick auf die Werkzeugunterst tzung f hren wir in diesem Kapitel ein Metamodell f r die neu eingef hrten Elemente ein welches wir dann in den folgenden Kapiteln schrittweise erweitern Die eher formale Darstellung soll die informelle Sicht auf Use Cases keinesfalls er setzen sondern lediglich pr zisieren Weitere Sichten wie z B die unerl ssliche informelle Benutzersicht werden automatisch aus der werkzeuginternen Darstellung abgeleitet In diesem und den weiteren Kapiteln werden wir neue Konzepte jeweils mit kleinen kon textfreien Beispielen illustrieren Daneben erg nzen wir am Schluss jedes Kapitels entspre chende Teile des Fallbeispiels Bankautomat Use Case Schritte 61 5 1 Use Case Schritte Wir verschmelzen in diesem Kapitel funktionale und ablaufbezogene Aspekte der Anforde rungen zu einem verfeinerten Use Case Konzept das wir dann mit den strukturellen Aspekten der Anforderungen dem Dom nen Klassenmodell koppeln in dem Dom nenklassen ihre Attribute Operationen und ihre Beziehungen untereinander modelliert werden s OMG97 Die dort spezifizierten Operationen stellen eine weitere funktionale Sicht dar nun aber auf einer tieferen Abstraktionsstufe und oft ohne direkten Bezug auf die extern be obachtbaren Aufgaben und Abl ufe Zun chst erweitern wir das aus Abschnitt 2 1
305. of Illinois Urbana Champaign 1992 Oshana98 Robert S Oshana Tailoring Cleanroom for Industrial Use IEEE Software Nov Dez 1998 S 46 55 Overbeck94 Jan Overbeck Integration Testing for Object Oriented Software Dissertation TU Wien 1994 Paech98 Barbara Paech Plddoyer fiir ein einheitliches Grundgeriist bei der System und Softwaremodellierung Proc Modellierung 98 Miinster Marz 1998 S 9 14 PagSix94 Bernd Uwe Pagel Hans Werner Six Software Engineering I Addison Wesley Bonn 1994 PagWin96 Bernd Uwe Pagel Mario Winter Towards Pattern Based Tools EuroPLoP 96 Conf Proc Irsee 1996 http www informatik fernuni hagen de import pi3 abstracts pi3 EuroPLoP96 html PalSch94 Jens Palsberg Michael I Schwarzbach Object Oriented Type Systems J Wiley amp Sons Chichester 1994 229 Parnas72 David L Parnas A Technique for the Specification of Software Modules with Examples Communications of the ACM Jahrg 15 Nr 1 1972 S 330 336 ParWei85 David L Parnas and David M Weiss Active Design Reviews Principles and Practices Proc 8 International Conference on Software Engineering IEEE Com puter Society Press Aug 1985 S 132 136 Paulk91 Mark C Paulk et Al Capability Maturity Model for Software Technical Report CMU SEI 91 TR 024 Software Engineering Institute 1991 Paulk95 Mark C Paulk How ISO 9001 Compares with the CMM IEEE Software Jan 1995 S 74 83 PerKai90 Dewayne E Perry Gail E K
306. of constructing a parser to recognize schema dependency in the specification This will be a major step towards a semi automated tool for the ESTD derivation CLS 98 Relevante Arbeiten Test gegen objektorientierte Anforderungsspezifikationen 39 Nutzungs Profil o Object Z Zustands N Test Spezifikation Automat Szenarien Daten gt Test Lexikon Daten Abb 3 2 Object Z basierte Testmethode von CLS 98 hnlich zu dem weiter oben besprochenen herk mmlichen Verfahren von Hsia und Kung HsiKun97 ist es bei dem Ansatz von Chang et al problematisch dass die An forderungsspezifikation die m glichen Ereignisse bzw Elemente der Benutzungs schnittstelle und somit Realisierungsdetails enth lt Zus tzlich enthalten die aus Zustandsautomaten und dem Datenlexikon generierten Testdaten nur atomare Da ten bzw Ereignisse und ber cksichtigen somit keine persistenten Objekte Daneben ist die Schachtelung von Testf llen nicht m glich da jede Sequenz einen vollst ndi gen Pfad durch die Anwendung beschreibt Abb 3 3 stellt die den bekannten Verfahren zugrundeliegende Vorgehensweise bei der Aus f hrung von Systemtests im grau hinterlegten Bereich dar der Tester bzw das Testwerk zeug stimulieren und validieren die Anwendung ber die Ein und Ausgabem glichkeiten der grafisch interaktiven Benutzungsoberfl che Bei dieser Vorgehensweise steht d
307. omit nat rlich End schritt so muss die Nachbedingung jedes Endschritts sf des von s referenzierten Use Cases die Nachbedingung von s implizieren Y s e S uc SA s Makro o s gt V sfe SE REF s Post Post Als letztes betrachten wir einen Makroschritt s der Endschritt mit mindestens einem Nach folgeschritt sei In jedem s enthaltenden Szenario wird zun chst der von s referenzierte Use Case RefUC s bearbeitet Abh ngig von der Nachbedingung des erreichten Endschritts von RefUC s m ssen wir entscheiden k nnen ob das Szenario mit s endet oder aber in einem der Folgeschritte von s weitergef hrt wird Die folgende Regel 6 3 7 erg nzt Regel 6 3 3 82 Semantik Regel 6 3 7 Makro Endschritt Ist ein Makroschritt s Endschritt aber kein Blattschritt so muss die Nachbedingung mindestens eines Endschritts sfdes referenzierten Use Cases REF s nicht die Disjunktion aller Bedingung der ausgehenden Kanten des Makro schritts implizieren V se S uc se SE uc ASA s Makro o s gt A sf SE REF s Post y gt V e e o s Ce 6 4 Makroschritte extends uses und Generalisierung Die in Use Cases bzw Use Case Schritten modellierten Funktionalit ten haben unterschied liche Komplexit t die von einfachen Informationseingaben bis hin zu komplizierten Interak tionen reicht vgl Cockburn97 Bei der Verfeinerung unterschiedlicher Use Cases ergeben sich oft hnliche Teilaufgaben die wi
308. on Fachbereich Informatik Softwaretechnik TU Berlin 1996 Scheer98a August Wilhelm Scheer ARIS Vom Gesch ftsproze zum Anwendungssystem 3 Aufl Springer Berlin 1998 Schulte97 Egbert Schulte Ein Transformations Framework f r GeeOOA Modelle Diplom arbeit Praktische Informatik III FernUniversit t Hagen 1997 Shaw94 Mary Shaw Comparing Architectural Design Styles IEEE Software Nov 1995 S 27 41 ShaGar96 Mary Shaw David Garlan Software Architecture Perspectives of an Emerging Discipline Prentice Hall Upper Saddle River New Jersey 1996 Siegel96 Shel Siegel Object Oriented Software Testing A Hierarchical Approach J Wiley amp Sons New York 1996 SieNew94 Ernst Siepmann A Richard Newton TOBAC A Test Case Browser for Testing Object Oriented Software Proc ISSTA 94 Washington 1994 S 154 168 Sneed95 Harry M Sneed Objektorientiertes Testen Informatik Spektrum Jahrg 18 Nr 1 Feb 1995 S 6 12 Sneed96 Harry M Sneed Ein objektorientiertes Testverfahren in MSL96 S 25 48 Spillner90 Andreas Spillner Dynamischer Integrationstest modularer Softwaresysteme Dissertation Universit t Bremen 1990 StrH r98 Friedrich Strau Thiemo H rnke Testfallentwicklung und automatisierung in gro en OO Projekten Proc Softwaretechnik 98 Paderborn 1998 TheGot98 JoachimThees Reinhard Gotzhein The eXperimental Estelle Compiler Auto matic Generation of Implementations from Formal
309. on be stehend aus Pflichtenheft Produktmodell z B OOA Modell Konzept der Benutzungsoberfl che und Benutzerhandbuch Balzert98 Speziell zum sogenannten Funktionstest r t Balzert dem Quaalit tssicherer lediglich zu berpr fen ob alle in der Anforderungsspezifikation Produktdefinition geforder ten Funktionen vorhanden und wie vorgesehen realisiert sind Hierf r sollen aus dem Pflichtenheft die Testsequenzen bernommen und oder mit funktionalen Testverfah ren systematisch und vollst ndig hergeleitet werden Liegt ein Produktmodell z B in Form eines OOA Modells vor dann k nnen aus diesem Modell die externen Opera tionen d h die Operationen die aus Benutzersicht aufrufbar sind entnommen wer den Ist bei der Anforderungsspezifikation bereits das Konzept der Benutzungsoberfl che erstellt worden dann k nnen daraus auch die m glichen Funk tionen f r den Funktionstest ermittelt werden Balzert98 Wie dies allerdings durch gef hrt werden soll wird nicht weiter geschildert Strau und H rnke geben einen Erfahrungsbericht zum Thema Testen in grossen objekto rientierten Projekten StrH r98 Sie berichten hierbei vom Testen bei der Erstel lung von Individualsoftware und erl utern die konkrete Umsetzung und Erweiterung von bekannten Methoden zur Testfallentwicklung anhand einer Spezifikation Sie stellen die Test berdeckung und die Test konomie in den Vordergrund F r den funk tionalen Systemtest verwende
310. on Testf llen f r den Test der An wendung gegen die Anforderungsspezifikation unterst tzen Wir skizzieren in den folgenden Abschnitten das Vorgehen bei der Entwicklung und die grundlegende Architektur des SCORESTOOLs und stellen in Kapitel 20 einige ausgew hlte SCORESTOOL Komponenten vor 19 1 Entwicklung Das SCORESTOOL basiert auf dem GEOOOA Tool einem Werkzeug zur Unterst tzung der GEOOOA K sters97 Zu Beginn der Entwicklung des GEOOOA Tools wurden weitge hend unabh ngige Teilwerkzeuge identifiziert Die Realisierung erfolgte inkrementell wobei Architektur 195 die einzelnen Teilwerkzeuge in einem iterativen Prototyping Prozess haupts chlich durch Studierende der FernUniversit t Hagen im Rahmen ihrer Diplomarbeiten implementiert wur den u a Rogotzki97 Schulte97 Uh197 Das Hauptaugenmerk bei der Entwicklung des GEOOOA Tools und auch des SCORESTOOLS lag auf der durchg ngigen Anwendung objektorientierter Entwicklungsmethoden Die Er mittlung der funktionalen Anforderungen an die Komponenten des SCORESTOOLs erfolgte dabei im Wesentlichen mit Hilfe von SCORES selbst Spezielle Anforderungen bez glich der Benutzungsschnittstelle wurden mit FLUID ermittelt und spezifiziert KSV96 der Entwurf orientierte sich an OOSE JCJ 92 s auch Abschnitt 2 2 und am Responsibility Driven De sign WBW 90 Implementiert wurde das SCORESTOOL in der Smalltalk Programmierumgebung VISUAL WORKS VW98 F r die Auswahl v
311. on VISUALWORKS sprachen neben der umfangreichen Klassenbibliothek und der komfortablen Programmierumgebung zwei pragmatische Gr nde Erstens ist die Programmierumgebung f r Studenten bzw Diplomanden allgemein verf g bar da die FernUniversit t Hagen ber eine Campus Lizenz verf gt Zweitens ist VISUAL WORKS auf fast allen g ngigen Hardware Plattformen lauff hig was eine breite Einsetzbarkeit des Werkzeugs gew hrleistet 19 2 Architektur Die Komponenten des SCORESTOOLs sind im Grunde als unabh ngige Werkzeuge f r die Anforderungsermittlung konzipiert die eine einfache Anbindung als Fremdwerkzeug an eine offene Software Entwicklungsumgebung SEU vgl Fuggetta97 erm glichen Abb 19 1 stellt den grundlegenden Aufbau des SCORESTOOLs dar Die Architektur baut im Wesentli chen auf der des GEOOOA Tools auf und l sst sich grob in drei Schichten einteilen die wir nachfolgend kurz besprechen wobei wir uns eng an K sters97 und Schulte97 anlehnen Auf der obersten Schicht befinden sich einzelne Analytikern und Testern zug ngliche Teil werkzeuge des SCORESTOOLs Auf dieser Ebene trennt das SCORESTOOL noch die an der An forderungsermittlung beteiligten Modellierungs bzw Validierungs und Verifikations werkzeuge von den externen Schnittstellen mit welchen beispielsweise die Modelle der An forderungsspezifikation bzw die bei der Validierungs und Verifikation protokollierte Infor mation in soweit wie m glich quivalen
312. on auch der systemin ternen Information Im Wesentlichen identifizieren wir Interaktionsschritte als m gliche Verbindungspunkte zwischen Use Cases und Klassenmodell denn 1 die Verantwortlichkeit der Teil Aufgabe eines Interaktionsschritts muss auf Ele mente des Klassenmodells abgebildet werden k nnen vgl WBW 90 und 2 die erfolgreiche Ausf hrung eines Use Case Schritts ist nur auf bestimmten durch die Aufgabe bzw die Vor und Nachbedingung des Schritts eingeschr nkten Objekt konstellationen m glich die zum Klassenmodell konsistent sein m ssen Nach einigen notationellen Vereinbarungen bez glich der Elemente des Klassenmodells be handeln wir diese beiden Aspekte dann getrennt in den Abschnitten 7 2 bis 7 3 7 1 Elemente des Klassenmodells Wir treffen zuerst einige Vereinbarungen zur Referenzierung von Elementen im Klassenmo dell wobei wir uns an Meyer und Poetzsch Heffter anlehnen vgl Meyer97 Poetzsch97 Mit K bezeichnen wir die Menge der in einem Klassenmodell enthaltenen Klassen wobei wir standardklassen CoaYou90 bzw primitive Typen GJS96 wie z B Boolean Inte ger Real und String je nach Bedarf als in K enthalten betrachten F r eine Klasse k aus K be zeichnen wir mit k attributes die Menge aller in k definierten Attribute Der Ausdruck k operations bezeichne die Menge aller in der Klasse k definierten Operatio nen F r eine Klasse k und eine Operation o schreiben wir falls
313. ons IEEE Soft ware Mai 1996 S 33 40 McDMcG94 Robert McDaniel John D McGregor Testing the Polymorphic Interactions between Classes Technical Report TR 94 103 Clemson University 1994 McGreKor94 John D McGregor Timothy D Korson Integrated Object Oriented Testing and Development Processes Communications of the ACM Jahrg 37 Nr 12 Sep 1994 S 59 77 McGregor97 John D McGregor Planning for Testing Journal of Object Oriented Pro gramming Feb 1997 McGregor99 John D McGregor If the Devil Is in the Details Then What Is in the Plan Journal of Object Oriented Programming Jan 1999 S 16 21 74 MCP 98 N Maiden M Cisse H Perez D Manuel CREWS Validation Frames Patterns for Validating System Requirements CREWS Report 98 29 1998 MGMS96 John D McGregor Brian A Malloy Rebecca L Siegmund A Comprehensive Program Representation of Object Oriented Software Annals of Software Engi neering Jahrg 2 1996 S 51 91 Meyer85 Bertrand Meyer On Formalism in Specifications IEEE Software Jahrg 2 Nr 1 Jan 1985 S 6 26 Meyer97 Bertrand Meyer Object Oriented Software Construction 2 Auflage Prentice Hall Upper Saddle River New Jersey 1997 MMB 96 E Macdonnald J Miller A Brooks M Roper M Wood Applying Inspection to Object Oriented Code Software Testing Verification and Reliability Jahrg 6 1996 S 61 82 MMM 97 N Maiden S Minocha K Manning M Ryan A Software Tool and Method for Scen
314. orderungsspezifikation 0 0 cece eee eee eee 198 Inhalt 20 2 Validieruns zz2 e 244H 102 erregen 203 Vernfikation aer EAR A 20 4 NEE VI Res mee und Ausblick 21 Res mee 21 1 Zusammenfassung und Ergebnisse 21 2 Erf hrungen orrori ssie Ee are Ee EE 22 Ausblick 22 1 Laufende Arbeiten 22 2 Zuk nftige Arbeiten und offene Fragen Literatur Anhang A Klassen Botschaftsdiagramme Anhang B Syntax der Test Skriptsprache Index Kurzbiographie des Autors 210 OEL 210 Ge e 214 215 RUE SEEN 215 eege Fee 216 219 236 252 255 259 Abbildungsverzeichnis Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb 1 1 12 2 1 2 2 2 3 2 4 2 3 2 6 2 7 2 8 2 9 3 1 3 2 3 3 4 1 4 2 4 3 4 4 4 5 5 1 5 2 5 3 5 4 5 5 5 6 5 7 5 8 5 9 6 1 6 2 6 3 6 4 6 5 6 6 Gebiete der Qualit tssicherung Fokus der Arbeit Grafik nach PagSix94 Der Rational Unified Process nach JBR99 Gesch ftsprozess WFMS und Anwendungen Die vier T tigkeiten der Anforderungsermittlung aus Poh96 Elemente des UML Use Case Diagramms Darstellung der drei Objektarten nach Jacobson Interaktionsdiagramm der Operation ArrayStack push Teilprozesse und Modelle in OOSE JCJ 92 Von der Anforderungsermittlung zum Entwurf OOSE nach
315. ordneten Objekte der Klasse UseCaseStep abgeleitet Letztendlich be inhaltet die Assoziationsklasse Assertion welche die Assoziation successors attributiert die Bedingung zur Auswahl eines Folgeschritts 5 4 Modellierungsregeln I Formale Definitionen allein K nnen nicht sicherstellen dass die ihnen gen genden Modelle auch sinnvoll sind Zus tzlich geben wir deshalb hier und in weiteren Abschnitten einige Re geln an welche zur Modellierung sinnvoller Use Case Schrittgraphen hilfreich sind Die Re geln k nnen z B als OCL Ausdr cke im Metamodell oder als Pr dikate ber den Modellierungselementen formuliert werden Wir beschr nken uns bei den Regeln auf letzte res und verwenden die OCL erst sp ter zu Formulierung der auf dem SCORES Metamodell aufbauenden Metriken vgl Kapitel 10 und 12 Nat rlich muss die Konstruktion tempor r bez glich der Regeln inkonsistenter Modelle er laubt sein bzw die Einhaltung der Regeln nur auf Anforderung gepr ft werden Auf eine dementsprechende Werkzeugunterst tzung gehen wir in Teil V ein Betrachten wir zun chst die Modellierung von Aktoren Wir erinnern uns daran dass Akto ren generalisiert werden k nnen und einigen uns auf folgende die Darstellung vereinfachen de Regel Regel 5 4 1 Use Case Aktoren Zu einem Use Case bzw Use Case Schritt werden immer nur die am h chsten in der Vererbungshierarchie stehenden Aktoren angegeben Da ein Kontextschritt nur von Aktoren bearbeitet wi
316. ox Test wieder verwenden k nnen Die prinzipielle Vorgehensweise umfasst folgende Punkte Q Aus den einzelnen Schritten eines Test Szenarios leiten wir Testf lle ab Diese kon zentrieren sich auf einzelne Operationen und stellen Aufrufe und als Testdaten 162 Black box Test Interaktionsparameter zur Verf gung Die Interaktionsparameter werden aus den Si gnaturen der Wurzeloperationen im Klassenmodell generiert Q Jedes Test Szenario wird zu einem Testskript Insbesondere die externen Abl ufe und der Kontext im Klassenmodell Objektkonstellationen sind hier durch die Vor und Nachbedingungen der Schritte und die Bedingungen der Kanten im Use Case Schritt graph betrachtet Testskripte k nnen hierarchisch strukturiert werden Q Zu jedem Use Case bzw Use Case Schrittgraph erstellen wir eine eigene Testsuite Diese dient lediglich als administratives Mittel zur Zuordnung einzelner Test Skripte zu Use Cases und hat dar ber hinaus keine weitere Test Semantik In der Test Suite sammeln wir auch die Protokolle bez glich der mit den Tests erzielten funktionalen und strukturellen berdeckung Wir betrachten die einzelnen Punkte im folgenden Abschnitt genauer Die resultierende Struktur der SCORES black box Tests zeigt Abb 15 1 15 2 Testfallermittlung Anhand der Aufgabenbeschreibung des Schritts ermitteln wir die vom Benutzer bzw Werk zeug auszuf hrende Aktion Das erwartete Ergebnis dieser Aktion ergibt sich aus der kon
317. pezifizieren wir dementsprechend die externe Funktionalit t bzw das extern be obachtbare Verhalten der Anwendung mit Use Case Schrittgraphen Dies entspricht einer seits dem oft verk ndeten Grundsatz Gesch fts Regeln und Prozesse nicht in den Objekten zu vergraben vgl JCJ 92 Maring96 und erh lt andererseits ber die Kopplung der Use Case Schrittgraphen zum Klassenmodell die notwendigen objektorientierten Anteile Wir haben im letzten Kapitel mit Test Szenarien konkrete extern beobachtbare Abl ufe bei der Bearbeitung der Aufgabe eines Use Cases simuliert bzw beschrieben Interaktions und kontextuelle Information Die oft nicht unmittelbar zu beobachtende interne Funktionalit t spiegelt sich in den Operationen und den internen Interaktionen zwischen Instanzen der Do m nenklassen des Klassenmodells wider systeminterne Information Nat rlich k nnen wir den internen Ablauf einzelner Operationen der Dom nenklassen nicht vollst ndig bzw all gemein angeben ohne die Operationen durch Angabe des Wie z B in Form von Pseudo Code berzuspezifizieren Wir konzentrieren uns daher auf einzelne konkrete Abl ufe von Operationen im Kontext eines Test Szenarios Dabei reichern wir sozusagen die Schritte des Test Szenarios um systeminterne Information an s auch Abb 4 5 1 Behringer s um Kontrollflusskonstrukte angereicherten Szenariendiagramme m nden in einer Notation hnlich der von Regnell RAB96 verwendeten
318. pt des Use Case Schrittgraphen mit Aktivit tsdiagrammen ausdr cken zu k n nen und somit SCORES ganz auf der UML basieren zu k nnen Dies k me insbesonde re der Forderung nach einer einheitlichen Modellierungssprache entgegen Testbarkeit Die Komplexit t der internen Interaktionen in objektorientierten Programmen sowie der Generierung von Objektkonstellationen als Testdaten gibt Anlass zu weiter gehenden Forschungen im Bereich der Testbarkeit objektorientierter Anwendungen Insbesondere die Relation der in dieser Arbeit angegebenen auf dem Klassen Bot schaftsdiagramm basierenden strukturellen berdeckungskriterien in Bezug auf zu standbezogene Test Endekriterien vgl Binder95 HKR 97 sowie die produkt und fehlererwartungsbezogene Generierung effektiver Teststrategien vgl Liggesmeyer96 wird untersucht 22 2 Zuk nftige Arbeiten und offene Fragen In diesem Abschnitt skizzieren wir einige geplante Arbeiten bzw offene Fragen Diese rich ten sich einerseits auf die weitergehende formale Unterst tzung insbesondere der Verifikati on und andererseits auf den objektorientierten Entwurf auf der Basis von Scores Anforderungsspezifikationen Daneben kommen wir auch auf einige eher Modellierungs technische Fragen zu sprechen Nebenl ufigkeit Dieser Arbeit liegt ein synchrones sequentielles Ablaufmodell zugrunde Zu betrachten ist noch wie sich SCORES zur Spezifikation nebenl ufiger Ausf hrun gen gleicher oder verschied
319. punkte f r die Verifikation Die Simulation der Episoden deckt fehlerhafte Klassenschnittstellen fehlende oder in der Multiplizit t fehlerhafte Beziehungen und Probleme der Vererbungsstruktur auf Unter An derem werden bei den Walk Throughs folgende Punkte beachtet Q Q Q Sind alle verwendeten Attribute auch initialisiert Bestehen Referenzen zu den Zielobjekten der von der Operation ausgesendeten Bot schaften Attribut bzw Parameter der die Operation ausl senden Botschaft Sind die aktuellen Parameter der von der Operation ausgesendeten Botschaften be kannt Stimmen Ihre Typen bzw verstehen die Zielobjekte die Botschaft Werden die R ckgabewerte benutzter Operationen ad quat weiterverarbeitet Abb 11 1 zeigt exemplarisch einige Checklistenpunkte f r die Verifikation Vollst ndiges Scores Metamodell 135 Episoden werden in SCORES mit UML Sequenzdiagrammen vgl OMG97 visualisiert die jeweils dem entsprechenden ausl senden Schritt des Test Szenarios zugeordnet sind Hier zu betrachten wir ein kleines Beispiel Beispiel 11 1 F r den Bankautomaten zeigt Abb 11 1 das Sequenzdiagramm einer Episode Transaktion Konto f hrePlanAus p read e modify Abb 11 1 Sequenzdiagramm Episode mit Wurzelklasse Transaktion und Wurzeloperation f hrePlanAus Dem zugeh rigen Use Case Schritt ist die Wurzelklasse Trans
320. r Tool A Grafisch interaktive Benutzungsoberflache rer Funktionaler Kern der Anwendung Ber Persistente Objekte Datenbank Abb 22 1 Vollst ndiger GUI basierter Systemtest 218 Ausblick ber die Benutzungsoberfl che eingebracht werden Eine Vorgehensweise zur kom binierten Ermittlung von Dom nen und Benutzungsschnittstellen Anforderungen IKSV96 wird zur Zeit in den Bereichen Software Entwurf und Spezifikation er weitert HomV0s97 Mit FLUID k nnten die sich an der Benutzungsoberfl che er gebenden Interaktionen f r ein Test Szenario abgebildet und die generierten Oberfl chenobjekte vom GUI Testwerkzeug stimuliert werden Wie in Abb 22 1 ge zeigt w rde so ein vollst ndig GUI basierter Test m glich Epilog Es verbleibt die Frage ob der Jungfernflug der Ariane 5 Rakete Flug 501 bei der Verwen dung z B von SCORES zu einem r hmlicheren Ende gekommen w re Nat rlich werden wir diese Frage niemals definitiv beantworten k nnen denn wie bei allen Katastrophen war das eigentliche Ungl ck das letzte Glied in einer Kette von Ereignissen beginnend mit der Wie derverwendung des alten Codes bis hin zur aus Kostengr nden getroffenen Entscheidung gegen entsprechende Tests Solche Ereignisketten sind schwierig zu durchbrechen und noch schwieriger vorherzusehen Wir glauben allerdings dass pr zise Anforderungsspezifikationen in Verbindung mit ad quaten Methoden zu
321. r Ableitung der Testf lle verwen deten Testkriterium bzw von der verwendeten Metrik Test Szenarien die auf die Use Case Schritt berdeckung co hin gerichtet sind k nnen nur Fehler in den einzelnen Schritten selbst nicht aber in allen m glichen Abl ufen entdecken Diese Tests zielen also auf die Hauptabl ufe und lassen alternative Abl ufe und Ausnahmebehandlungen oft unber cksich tigt Insofern handelt es sich um positive Pr fungen zum Nachweis der Funktionalit t Test Szenarien im Hinblick auf die Use Case Kanten Uberdeckung ch durchlaufen alle m glichen Verzweigungen im Use Case Schrittgraph mindestens einmal Sie testen also die bergangsbedingungen der Kanten und damit auch auf die m glichen Alternativen und Aus nahmen im Use Case so dass diese Tests auf die Robustheit der Anwendung abzielen Ber tolino und Marr geben ein Verfahren zur Generierung von Testf llen f r Kontrollflussgraphen an BerMar93 Nat rlich setzen solche Verfahren die automatische Auswertbarkeit der Bedingungen voraus Auch die Use Case Grenze Inneres Uberdeckung cg zielt auf iterativ durchzuf hrende Teil Aufgaben sowie bestimmte Ausnahmen im Use Case Insbesondere das Umgehen von Zyklen im Use Case Schrittgraph bedeutet oft dass z B keine Daten zu bearbeiten bzw vor handen sind Daneben werden jedoch auch die Hauptabl ufe bei sich wiederholenden Teil Aufgaben gepr ft Die zwei oder mehrmalige Ausf hrung der Zyklen ist als erster Sc
322. r Festlegung der Testf lle gehen wir iterativ vor indem wir in Szenarien die Schritte nacheinander abarbeiten bis der geforderte berdeckungsgrad f r jede Bedingung erreicht ist oder bei negativen Testf llen als nicht erreichbar erkannt ist Zun chst folgt aus der Vorbedingung des Use Cases Anmelden Abb 5 3 dass zu Beginn jedes Szenarios der Kartenleser betriebsbereit und das Bedienpult ge sperrt sein muss Jedes Szenario beginnt mit dem Startschritt hier also Karte Einf hren des sen Vorbedingung von der des Use Cases impliziert sein muss Interaktionsparameter des ersten Schritts sind die physikalische Karte bzw die auf dem Magnetstreifen oder Mikro chip gespeicherten Daten In Szenario A gehen wir von einer lesbaren zum Zugriff auf den Automaten berechtigenden Karte aus Nachdem diese im Kontextschritt Karte Einf hren vom Aktor Bankkunde richtig 1 Tab 12 1 kann als verk rzte Entscheidungstabelle vgl Beizer90 angesehen werden bei der Bedingungen direkt auf Aktionen Szenarien abgebildet werden In der vollst n digen Entscheidungstabelle werden alle Terme als Bedingungen und die Use Case Schritte als Aktionen eingetragen Eine Regel entspricht dann der Belegung aller Inter aktionsparameter der in einem Szenario ausgef hrten Schritte Vollst ndige und polymorphe Operations berdeckung 143 Schritt Bedingungen BE A B E arte Einf hren Vorbedingung artenleser betriebsbereit arte Einf
323. r Qualit tssicherung und durchg ngiger Verfolgbarkeit der Anforderun gen zu den sie implementierenden Teilen der Software die Wahrscheinlichkeit eines solchen Desasters drastisch verkleinern Dem steht jedoch entgegen dass Entwicklungsprozesse in ihrem Umfeld oder objektori entiert ausgedr ckt mit ihren geerbten Faktoren oft sehr schwer zu durchschauende Netz werke mit sehr gro er tr ger Masse bilden Die in der industriellen Praxis der Softwareentwicklung notwendigen und nach dem Stand der Forschung m glichen Innova tionen bei den verwendeten Methoden erfolgen zur Zeit und auch in absehbarer Zukunft auf grund dringlicher Reparaturarbeiten wie z B der Euro Umstellung und der L sung des Jahr 2000 Problems nicht Solange Software von Menschen unter Zeitdruck in unvollst ndig definierten Prozessen entwickelt wird muss mit Softwarefehlern gerechnet werden Literatur ABR 94 R D Acosta C L Burns W E Rzepka J L Sidoran A Case Study of Applying Rapid Prototyping Techniques in the Requirements Engineering Environment Proc ICRE 94 IEEE 1 Int Conf on Requirements Engineering Colorado Springs April 1994 S 66 73 Balzert98 Helmut Balzert Lehrbuch der Software Technik Bd II Spektrum Akademischer Verlag Heidelberg 1998 Barbey97 St phane Barbey Test Selection for Specification Based Unit Testing of Object Oriented Software based on Formal Specifications Dissertation Univ Lausanne 1997 Behring
324. r Wichtigkeit Die Anforderungen umfassen im Wesentlichen funktionale verhaltens und ablauforientierte sowie strukturelle Aspekte der Anwendung In der objektorientierten Anforderungsermitt lung werden funktionale Aspekte mit Hilfe von Use Cases formuliert Neben den Use Cases bildet das Dom nen Klassenmodell zur Beschreibung struktureller Aspekte den Kern jeder objektorientierten Anforderungsspezifikation Das Klassenmodell spielt eine wichtige Rolle im gesamten Entwicklungsprozess da es als gemeinsame Basis f r fast alle zentralen Ent wicklungsaktivit ten dient Jede einigerma en vollst ndige Anforderungsspezifikation ent h lt somit mindestens die relevanten Use Cases inkl ihrer Dynamikbeschreibungen und das Klassenmodell Da diese Modelle auf unterschiedlichen Techniken und Abstraktionsniveaus basieren ergeben sich erhebliche Konsistenzprobleme f r die Gesamtspezifikation In dieser Arbeit haben wir ein durchgehendes Konzept f r die Qualit tssicherung bei der ob jektorientierten Anforderungsermittlung bis hin zu entsprechenden Tests der Anwendung ge gen die objektorientierte Anforderungsspezifikation vorgestellt 21 1 Zusammenfassung und Ergebnisse Thema der Arbeit ist die Qualit tssicherung bei der objektorientierten Anforderungsermitt lung sowie der Test einer objektorientierten Anwendung gegen die objektorientierte Anfor derungsspezifikation Das Dilemma der Qualit tssicherung wird auch im Spektrum der vorliegenden
325. r auf entsprechende Elemente des Entwurfs und der Implementa tion abbilden Die am Anfang der Entwicklung grob abgesch tzten Profile der Use Cases werden dann im Laufe der Entwicklung verfeinert wobei auch die Komplexit t der entspre chenden Entwurfs und Implementations Klassen mit einflie t Beispiel 8 1 Das Gewicht des Use Cases Anmelden Abb 5 3 mit dem Profil F high C medium Ry high Rz high und Rp high ergibt sich zu _3 3 3 3 Wanmelden 7 3 3 2 3 18 8 6 Zwischenfazit Wir haben in diesem Teil das Use Case Konzept pr zisiert bzw verfeinert und in Use Case Schrittgraphen mit der Ablaufsicht verschmolzen Diese erm glichen den nahtlosen verfolg baren bergang von Use Cases zu Dom nenklassen Die SCORES Anforderungsspezifikation deckt die kontextuelle und die Interaktionsinformation ab und ber cksichtigt somit auch As pekte der umfassenden Gesch ftsprozesse Bei der Pr fung der Anforderungsspezifikation wird dann auch die bisher nur rudimant r erfasste systeminterne Information vervollst ndigt F r die Anforderungsspezifikation erm glicht uns die Syntax und Semantik der SCORES Ele mente Use Case Schritt Use Case Schrittgraph und Klassenbereich sowie Wurzelklasse und Wurzeloperation die Formulierung von Regeln die den Modellierungsraum einschr nken und zu aussagekr ftigeren Anforderungsspezifikationen f hren Dar ber hinaus k nnen wir f r den Grad der Kopplung des Use Case Modells mit dem Kla
326. r das Klassen Botschaftsdiagramm f r die Anforderungsspe zifikation KBD q nennen 1 Jeder im Klassenmodell deklarierten Operation entspricht ein Knoten des Graphen 2 Ist ein Episodenschritt s Folgeschritt eines Episodenschritts s4 d h So o s4 so f gen wir eine Benutzungskante zwischen den entsprechenden Knoten ein 3 berschreibt eine Operation eine andere Operation so f gen wir eine Vererbungskan te zwischen den entsprechenden Knoten ein Zus tzlich duplizieren wir in diesem Fall alle Kanten die in dem der berschriebenen Operation entsprechenden Knoten enden f r den der berschreibenden Operation entsprechenden Knoten Solche duplizierten und umgeleiteten Kanten stehen bzgl der urspr nglichen Kante in einer Relation P die explizit die Tatsache repr sentiert dass die entsprechende Benutzung an Objek te aller die Operation re definierender Klassen gerichtet sein k nnen Ein Algorithmus zur Generierung des KBD ist in Anhang A 1 angegeben F r die Darstel lung des KBD treffen wir folgende Vereinbarungen Q Wir stellen Operationen durch ein Rechteck mit abgerundeten Kanten dar Im Recht eck steht der Name der Operation mit abgesetzt wird diesem der Name der Klas se in der die Operation definiert ist vorangestellt m Vererbungskanten werden wie in der UML durch einen geschlossenen nicht ausge f llten Pfeil mit der Spitze zum Knoten der berschriebenen Operation gezeichnet
327. r den Schritt PIN Eingeben im Test Szenario Onli ne Anmeldung Die Wurzeloperation Transaktion pruefePIN erwartet als Eingabeparameter einen Wert vom Typ integer F r diesen Interaktionsparameter ermitteln wir die quivalenz klassen PIN und keinePIN F r eine Integer Gr e i bezeichne Chars i die Anzahl der Stellen in der Dezimaldarstellung von i ohne f hrende Nullen Damit erhalten wir die quivalenz klassen PIN i i gt 0 A Chars i 4 und keinePIN i i PIN i i lt 0 v Chars i 4 Die quivalenzklasse PIN verfeinern wir weiter in die beiden Klassen GueltigePIN und Un gueltigePIN Die Klasse GueltigePIN enth lt alle Eingaben zu denen ein entsprechendes Kon to existiert UngueltigePIN enth lt alle anderen Eingaben 1 Wir vernachl ssigen hier Eingaben die berhaupt keiner Integer Gr e entsprechen da diese ber entsprechend pr fende Felder der Benutzungsoberfl che abgefangen werden sollten 168 Black box Test TESTCASE AnmeldungOK USECASE Anmelden Bankleitzahl String 8 Kontonummer String 10 G ltigkeitsdatum Date Kartennummer Integer PIN Integer Der Bankkunde identifiziert sich durch Eingabe der Karte und der PIN PRECONDITION AccountCreatedOrExists Bankleitzahl Kontonummer AND CardNotLocked Bankleitzahl Kontonummer G ltigkeitsdatum Kartennummer AND ATMReadyAndOnline BEGIN Karte Eingeben KarteEinf hren Bankleitzahl Kontonummer G ltigkeitsdatum Kartennum
328. r die Validierungsmetriken Use Case Schritt Kanten Szenarien Grenze Inneres und Pfad berdeckung sowie die bei der Verifikation benutzte minimale Mehrfach Bedingungs berdeckung In den Systemtests sollte die 100 ige Use Case Kanten berdeckung angestrebt werden da erst so wichtige alternative Abl ufe eines Use Case gepr ft werden Strukturell ablaufbezogen In Analogie zu den kontrollflussbasierten Testkriterien geben wir f r objektorientierte An wendungen folgende auf dem Klassen Botschaftsdiagramm der Implementation aufbauende Hierarchie von ablaufbezogenen Testkriterien an Q C 0 Methoden berdeckung Alle Methoden der Anwendung m ssen mindestens einmal ausgef hrt werden Jeder Methodenknoten des KBD ist berdeckt Q C 1 Botschafts berdeckung Jede Botschaftsquelle muss mindestens einmal gefeu ert haben Bildet man quivalenzklassen der Botschaftskanten des KBD bez glich P so muss aus jeder Klasse mindestens eine Kante durchlaufen sein Q C 2 polymorphe Botschafts berdeckung Jede Botschaftsquelle muss f r jede m g liche dynamische Bindung mindestens einmal gefeuert haben Alle Botschaftskan ten des KBD sind mindestens einmal durchlaufen m C 3 polymorphe Grenze Inneres berdeckung Alle Zyklen im KBD die nur Bot schaftskanten enthalten werden 0 1 und 2 mal traversiert Q C n polymorphe Botschafts berdeckung Alle m glichen Abl ufe in der Anwen dung sind gepr ft worde
329. r elves 150 horizo t le Ae et ia 148 vertikale esse 148 Verfkanon n n aa anaana 5 104 125 E EE 137 Vollst ndigkeit Fachliche age 8 geg de SN 105 W Workflow EE 14 Wurzelklasse 2 40 4204 0822 90 Wurzeloperation 90 Z Zerlegung Funktionale 434 0 02 04 s4 ova CN 109 Funktionale de 64 Zustandsinteraktion 241 Kurzbiographie des Autors Dipl Inform Dipl Ing Mario Winter Fachbereich Informatik FernUniversit t Gesamt hochschule in Hagen Wissenschaftlicher Mitarbeiter am Lehrgebiet Praktische Informatik II von Prof Dr Hans Werner Six Mitglied der GI Fachgruppe 2 1 7 Testen Analysieren und Verifizieren von Software TAV dort Sprecher des Arbeitskreises Testen objektori entierter Programme TOOP Geboren am 22 M rz 1959 in Berlin als zweites Kind des Dipl Kaufmannes Manfred R Winter und der Helga I Winter geb Macke Seit dem 27 Mai 1987 verheiratet mit der Dipl Sozialarbeiterin Petra Winter geb Glebe Zwei Kinder Abitur 1978 Studium der Elektrotechnik Fachrichtung Informationsverarbeitung an der Universit t Gesamthochschule Siegen von Oktober 1979 bis M rz 1983 Abschluss mit dem Grad Diplom Ingenieur Studium der Informatik mit Nebenfach Elektrotechnik an der Fern Universit t Gesamthochschule in Hagen von Oktober 1986 bis August 1994 Abschluss mit dem Grad Diplom Informatiker Von Juli 1978 bis September 1979 Grundwehrdienst Von Jun
330. r wiederum mit Use Cases bzw Use Case Schrittgra phen modellieren Im Use Case Modell werden solche Abh ngigkeiten mit uses und ex tends Beziehungen ausgedr ckt deren Benutzung jedoch aufgrund der unklaren bzw fehlenden Semantik problematisch erscheint vgl Rumbaugh94 Cockburn97 Zur Pr zisierungung dieser Beziehungen haben wir das Konzept des Makroschritts einge f hrt Ein Makroschritt Smakro beschreibt eine Teil Aufgabe eines Use Cases indirekt in dem er auf einen anderen den benutzten Use Case Schrittgraphen RefUC s makro verweist Mit dem Makroschritt Konzept oder genauer mit der Inter Use Case Referenzfunktion und der Semantik von Use Case Schrittgraphen geben wir eine Semantik f r die von Jacobson vorgeschlagenen extends und uses Beziehungen zwischen Use Cases an Im Weiteren seien A und B Use Cases und AG bzw BG die A bzw B verfeinernden Use Case Schrittgraphen Definition 6 1 AG referenziert BG wenn f r alle Szenarien sz von AG gilt sz enth lt einen Makroschritt Ss akrohMit RefUC Smakro B Gilt A uses B dann muss gelten AG referenziert BG Abb 6 11 a LI Definition 6 2 BG erweitert AG wenn es ein Szenario sz von AG gibt f r das gilt sz enth lt einen Makroschritt s yakroMit RefUC Smakro B Gilt B extends A dann muss gelten BG er weitert AG Abb 6 11 b m Die Semantik von uses und extends ist somit ber Makroschritte und die von ihnen referen zierten Use Cases klar definie
331. r zun chst kurz Gesch ftsprozesse und Workflow Modelle und zeigen Ankn pfungspunkte f r die Anforderungsermittlung einzelner Anwendungen auf Hierbei lehnen wir uns an die Arbeiten von Scheer Jablonski und Sinz et al sowie an das WorkFlow Reference Model der WFMC Workflow Management Coalition an Scheer98a Jablonski95 FerSin95 WFMC97 Eine f r unsere Zwecke ausreichende Definition des Begriffes Gesch ftsprozess Business Process gibt Scheer Allgemein ist ein Gesch ftsprozess eine zusammengeh rige Abfolge von Unternehmensverrich tungen zum Zweck einer Leistungserstellung Ausgang und Ergebnis des Gesch ftsprozesses ist eine Leistung die von einem internen oder externen Kunden angefordert und abgenommen wird Scheer98a Gesch ftsprozesse sind somit direkter Gegenstand betriebswirtschaftlicher Betrachtungen f r die Ziele wie z B Optimierung des zeitlichen Aufwandes definiert werden und die der Kostenrechnung unterliegen Wichtig ist das tiefe Verst ndnis der Anwendungssituation was insbesondere eine gro e Anschaulichkeit der Modelle f r Gesch ftsprozesse bedingt Workflow Modelle dienen als Grundlage f r die Automatisierung von Gesch ftsprozessen Im Workflow Reference Model der WFMC finden wir die folgende Definition Workflow The computerized faciliation or automation of a business process in whole or part WFMC97 Workflow Modelle m ssen aufgrund ihrer Implementationsn he pr
332. ra Paech Peter Scholz Veronika Thurner Die Praxis der Softwareentwicklung Eine Erhebung Informatik Spektrum 22 Jahrg Nr 1 1999 S 24 36 Deutsch82 Michael S Deutsch Software Verification and Validation Realistic Project Approaches Prentice Hall Englewood Cliffs New Jersey 1982 DesObe96 J rg Desel Andreas Oberweis Petri Netze in der Angewandten Informatik Einfiihrung Grundlagen und Perspektiven Themenheft Wirtschaftsinformatik 38 Jahrg Nr 4 Juli 1996 Dijkstra76 Edsger W Dijkstra A Discipline of Programming Prentice Hall Englewood Cliffs New Jersey 1976 DKR 91 Roger Duke Paul King Gordon Rose Graeme Smith The Object Z Specification Language Version I Technischer Report TR 91 1 Universit t Queensland Australien 1991 Fagan76 Michael E Fagan Design and Code Inspections to Reduce Errors in Program Development IBM Systems Journal Jahrg 15 Nr 3 1976 S 182 211 222 Faulk97 S R Faulk Software Requirements A Tutorial in Software Engineering Hrsg M Dorfman u R Thayer IEEE Computer Society Press Los Alamitos 1997 S 82 103 FerSin95 Otto K Ferstl Elmar J Sinz Re engineering von Gesch ftsprozessen auf der Grundlage des SOM Ansatzes Bamberger Beitr ge zur Wirtschaftsinformatik Nr 26 Universit t Bamberg 1995 FMD97 Bob Fields Nick Merriam Andy Dearden DMVIS Design Modelling and Verifi cation of Interactive Systems Proc 4th Eurographics Workshop on Design Spec
333. rartige Beziehungen vorsieht zu einer einzigen Objektstruktur verkn pft wer den wobei der Generator die jeweils betroffenen Objekte eingeschr nkt durch eine Beziehungsschablone und ggf den Beziehungen zugeordnete Constraints ausw hlt Weitere Objektkonstellationen werden mit abstrakten Objektstrukturen generiert indem wir die bei der Validierung manuell erzeugten Objektkonstellationen variieren und nachfolgen de Konsistenz Checks gegen das Klassenmodell ausf hren Beispiel 17 1 Das in Abb 17 1 links dargestellte Klassenmodell erlaubt die Generierung von Objektkonstellationen aus jeweils zwei ber die Beziehung verheiratetMit verbundenen Ob jekten der Klasse Person In einer Objektkonstellation hat jede Person aus Terminierungs gr nden keine oder aber genau zwei Eltern Zu der manuell vorgegebenen konkreten Objektstruktur im gestrichelt gezeichneten Rahmen in Abb 17 1 rechts k nnen nach den Person g Person verheiratetMit a b gt NOT Geschlecht a Geschlecht b AND Martha Theo NOT kindVon a b OR kindVon b a AND 22 03 49 18 01 47 NOT exists x kindVon a x AND kindVon b x weiblich m nnlich kind kind F 5 verheiratetMit a Person b Person exklusiv or ES verheiratetMit Paul pe el 15 6 73 30 01 71 0 1 weiblich m nnl
334. rd erhalten wir die folgende Regel Regel 5 4 2 Kontextschritt Aktoren Ein Kontextschritt hat mindestens einen Aktor Y s e S uc SA s Kontext gt A s Umgekehrt liegt es im Ermessen des Modellierers ob er z B bei zeitabh ngigen Aufgaben die Systemuhr als Aktor modelliert oder aber als in die Anwendung integriert betrachtet und somit eine zeitabh ngige Aufgabe als Schritt ohne Aktor modelliert Interaktionsschritte sowie Makroschritte k nnen m ssen aber keine Aktoren haben 70 Grundlegende Konzepte Wir kommen nun zu einigen strukturellen Eigenschaften der Use Case Schrittgraphen Zu n chst sollen s mtliche Schritte des Use Case Schrittgraphen eng mit der Aufgabe des Use Cases zusammenh ngen also auch auf irgend einem Pfad vom Startschritt aus erreichbar sein Hierzu formulieren wir die zwei folgenden Modellierungsregeln Regel 5 4 3 Schrittgraph Wurzelschritte Jeder Use Case Schrittgraph muss eine nichtleere Menge von Schritten enthalten von denen aus mindestens alle anderen Schritte des Use Case Schrittgraphen erreichbar sind 3se S uc o s D gt S uc s Wir nennen jeden Schritt mit der in Regel 5 4 3 angegebenen Eigenschaft Wurzelschritt des Use Case Schrittgraphen Es folgt dass jeder Use Case Schrittgraph ein gerichteter Wurzel graph und damit insbesondere zusammenh ngend ist Da jedes Szenario also jeder Pfad durch den Use Case Schrittgraphen den Startschritt als erste Reaktion auf den
335. rdings implizit Beschr nkungen auf Objektkonstellationen getroffen worden in denen die jeweilige Episode ablaufen kann Diese Beschr nkungen ergeben sich aus den Bedingun gen der Schritte und Kanten im Use Case Schrittgraph den Klassenbereichen der Schritte in den Test Szenarien sowie aus Assoziationen und ihren Multiplizit ten des Klassenmodells Wir wollen nun diese Beschr nkungen dazu verwenden aus den manuell bei der Qualit tssi cherung f r die Anforderungsspezifikation erstellten Objektkonstellationen weitere Objekt konstellationen f r die Tests der Anwendung zu generieren Die grundlegenden Bausteine sind hierbei abstrakte Objektstrukturen s Rogotzki97 Eine abstrakte Objektstruktur schr nkt innerhalb eines Teilmodells die Attributwerte der Klassen Generierung von Objektkonstellationen 183 durch Wertebereiche und ihre Objektbeziehungen durch Schablonen so ein dass diese eine Menge semantisch sinnvoller Objekte definieren Mit Hilfe eines Generators werden nach Vorgabe der abstrakten Objektstruktur dann konkrete Objektstrukturen in beliebiger Anzahl erzeugt wobei die Attributwerte jedes einzelnen Objekts zuf llig aus den vordefinierten Wertebereichen ausgew hlt werden Zwei so erzeugte konkrete Objektstrukturen sind nur strukturell isomorph da die entsprechenden Objekte sich durch ihre Attributwerte unterschei den Weiterhin k nnen zwei Mengen konkreter Objektstrukturen falls das zugeh rige Klassen modell de
336. rements Proc 24 Int Conf on Requirements Engineering Colorado Springs 1996 S 307 33 KWR96 Anita Krabbel Ingrid Wetzel Sabine Ratuski Objektorientierte Analysetechniken f r bergreifende Aufgaben Proc Softwaretechnik 96 Koblenz in GI Software technik Trends 16 Jahrg Heft 3 Sep 1996 LamWil98 Axel van Lamsweerde L Willemet Inferring Declarative Requirements Speci fications from Operational Scenarios IEEE Transactions on Software Enginee ring Special Issue on Scenario Management Jahrg 24 Nr 12 Dez 1998 S 1089 114 Lauesen98 S ren Lauesen Real Life Object Oriented Systems IEEE Software M rz April 1998 S 76 83 Leveson95 Nancy G Leveson Safeware System Safety and Computers Addison Wesley Reading Mass 1995 Liggesmeyer96 Peter Liggesmeyer Quantitative Bewertung von Software Priifverfahren durch unscharfe Logik Proc Softwaretechnik 96 zugl Softwaretechnik Trends 16 Jahrg Heft 3 1996 S 81 88 Lions97 J L Lions ARIANE 5 Flight 501 Failure Report Paris 19 Juli 1996 http sspg1 bnsc rl ac uk Share ISTP arianeb5rep htm 227 LisZil75 Barbara H Liskov Stephen N Zilles Specification Techniques for Data Abstrac tions IEEE Transactions on Software Engineering Jahrg 1 Nr 1 1976 S 7 19 Lyu96 M R Lyu Hrsg Software Reliability Engineering IEEE Computer Society Press Mc Graw Hill New York 1996 Maring96 Blayne Maring Object Oriented Development of Large Applicati
337. rf lle behandeln In diesem Aufgabenbereich vervollst ndigen die Analytiker die feingranularen und nde rungsanf lligeren Spezifikationen der Operationen In vielen F llen deckt die Spezifikation einer komplexen Operation das Fehlen weiterer interner Operationen und funktionaler Ab h ngigkeiten auf Die Werte der im vorigen Abschnitt vorgestellten Metriken reflektieren den Stand der Mo dellierung Als Faustregel k nnen wir z B sagen dass mit der Validierung der Anforderungs spezifikation s Kapitel 9 nicht eher begonnen werden sollte bis die Klassen berdeckung c 1 1 ist also jede Klasse in zumindest einem Bereich eines Use Cases bzw Use Case Schritts enthalten ist 8 5 Administrative T tigkeiten In SCORES beinhalten die administrativen T tigkeiten insbesondere die Vorbereitung der Ressourcenplanung Hierzu bestimmen die Analytiker und Tester ein Profil f r jeden Use Ca ses z B nach folgenden Kriterien vgl Lyu96 McGregor97 Q Die Kritikalit t C repr sentiert die schlimmst m glichen Auswirkungen bei Ausfall oder fehlerhafter Bearbeitung des Use Cases Sie wird durch Technik Folgeabsch t zungen in Zusammenarbeit mit den Benutzern festgelegt Q Das technische Risiko Ry wie kompliziert wird die Realisierung des Use Case wird aus der Komplexit t des Schrittgraphen und des Klassenbereichs abgeleitet Q Das gesch ftliche Risiko Rg inwiefern ist der Absatz die Akzeptanz bei Nichterf l lung gef hrdet
338. rhindern d h Produkte wurden w hrend ihrer Fertigstellung gepr ft Bis dahin war das Ziel der Qualit tssicherung immer noch die Freiheit des Produkts von De fekten Anfang der neunziger Jahre trat die produktzentrierte Sicht zu Gunsten einer pro zesszentrierten Sicht in den Hintergrund Normen wie die ISO 9000 ISO9001 3 92 und standardisierte vergleichbare Prozess Evaluierungen wie im Prozess Reifegradmodell ca pability maturity model CMM Paulk91 beherrschten die Szene W hrend die ISO 9000 sich auf die Dokumentation innerhalb des Qualit tssicherungssystems konzentriert zielt das CMM auf Ma nahmen zur Prozessverbesserung vgl Paulk95 Zur Zeit werden die pro duktzentrierte und die prozesszentrierte Sicht in umfassenden qualit tszentrierten Software Entwicklungsprozessen vereinigt vgl JBR99 Zum momentanen Stand der Praxis in der Software Qualit tssicherung bemerken Cusumano und Selby Weder wir noch Microsoft glauben dass mittlerweile alle Probleme gel st seien und kein Produkt mehr versp tet oder fehlerfrei ausgeliefert w rde Dies kann ohnehin kein Software Hersteller von sich behaupten CusSel96 M ller und Wiegmann von der Universit t K ln untersuchten 1998 den Stand der Praxis der Pr f und Testprozesse in der Softwareentwicklung in Deutschland M lWie98 Bei der Auswertung ihrer Frageb gen trafen sie auf eine Reihe alarmierender Fakten Q Eine spezialisierte Testgruppe fehlt in den meis
339. rientierten Welt signifikant JCJ 92 Erstmals werden Anforderungen in Form des gew nschten extern beobachtba 20 Entwicklungst tigkeiten ren Verhaltens als prim res Element der Projektplanung verwendet an dem sich die einzel nen Entwicklungst tigkeiten orientieren Bez glich der organisatorischen Aspekte kategorisiert Jacobson menschliche oder maschi nelle Benutzer die mit der Anwendung interagieren in Form sogenannter Aktoren Actors model anything that needs information exchange with the system JCJ 92 Pr ziser als diese etwas kurze Beschreibung definiert die UML den Begriff des Aktors An actor is a role of object or objects outside of a system that interacts directly with it as part of a coherent work unit a use case An Actor element characterizes the role played by an outside ob ject one physical object may play several roles and therefore be modelled by several actors OMG97 Notation Guide Aktoren sind im Metamodell der UML Unterklasse der Metaklasse Classifier und k nnen so mit generalisiert werden Jeder Aktor kann mindestens die Rollen aller ihn generalisierenden Aktoren spielen Two or more actors may have commonalities i e communicate with the same set of use cases in the same way This commonality is expressed with generalizations to another possibly abstract actor which models the common role s An instance of an heir can always be used where an in stance of the ancestor is expected OM
340. ritt_j lt False Unabh n gig vom tats chlichen Ergebnis des Schritts muss nat rllich immer mindestens einer der Folgeschritte ausgew hlt werden k nnen d h es gilt c Schritt FolgeSchritt_1 v v c Schritt FolgeSchritt_n amp True Ist dies nach der Bearbeitung der Aufgabe nicht BEGIN Schritt Schritt Aufgabe CASE ma e Schritt FolgeSchritt_1 GOTO FolgeSchritt_1 Schritt c Schritt FolgeSchritt_n GOTO FolgeSchritt_n ELSE EN Folgeschritt 1 Folgeschritt n ERROR gt END END Schritt Abb 6 4 Semantik 4 kein Endschritt mehrere sich ausschliessende Folgeschritte der Fall d h keine der Bedingungen der vom Schritt ausgehenden Kanten ist erf llt ist entweder ein Spezifikationsfehler entdeckt worden oder der Use Case Schritt muss als Endschritt markiert werden Wir deuten diesen Sachverhalt wie in Abb 6 7 durch das Schl sselwort Error an Kontext oder Interaktionsschritt mehrere Folgeschritte bergangsbedingungen der ausgehenden Kanten schliessen sich nicht gegenseitig aus kein Endschritt Es gibt l1 lt iz j lt n mit c Schritt FolgeSchritt_i A c Schritt FolgeSchritt_j ist erf llbar Solche F lle weisen auf unabh ngige im Prinzip parallel bearbeitbare Aufgaben oder technisch gesehen nebenl ufige Prozesse hin Wir betrachten den Spezialfall dass f r 1 lt m lt n mehrere Folgeschritte Folgeschritt_1 bis Folgeschritt_m unabh ngig voneinander ausgew hlt aber allesamt vor weiteren Folgesch
341. ritten Folgeschritt_m 1 bis Folgeschritt_n ausgef hrt werden m ssen Es ergibt sich eine wie in Abb 6 5 a gezeigte Struktur In diesem Fall k nnen wir irgendeine willk rliche Reihenfolge der Schritte 1 bis m modellieren oder aber einen k nstlichen die Schritte Folgeschritt_1 bis Folgeschritt_m zusammenfassenden Schritt Schritt einf hren der die Schritte Folgeschritt_1 bis Folgeschritt_n als Folgeschritte hat und zu dem die Schritte 1 bis m wieder unbedingt zur ckverzweigen d h es gelte o Folgeschritt_i Schritt f r jeden der Schritte Folgeschritt_1 bis Folgeschritt_m und f r 1 lt i lt sm sei c FolgeSchritt_i Schritt True Da solche Ablaufstrukturen h ufig auftreten f hren wir als abk rzende grafische No tation die in Abb 6 5 b dargestellte Variante ein Der Synchronisationsbalken un ter dem Use Case Schritt Schritt deutet an dass die mit einer Linie mit Doppelpfeil verbundenen Schritte Folgeschritt_1 bis Folgeschritt_m unabh ngig voneinander alle ausgef hrt sein m ssen bevor einer der Schritte Folgeschritt_m 1 bis Folgeschritt_n 76 Semantik 5 Schritt gt Schritt Folgeschritt 1 Folgeschritt m Folgeschritt 1 Folgeschritt m Folgeschritt m 1 Folgeschritt n Folgeschritt m 1 a b Abb 6 5 a unabh ngige Folgeschritte b abk rzende Notation ausgef hrt wird Semantisch spiegelt sich dieser Sachverhalt darin wider dass be stimmte Kombinationen der Nachbedingungen der Use Cas
342. rozesses vgl Abschnitt 2 1 geben Hinweise zur Charakterisierung der Schritte in kontextuelle Schritte und Interaktionsschritte W hrend kontextuelle Schritte beliebig umfangreiche Aufgaben beschreiben die in ihrem Verlauf nicht die Benutzung der zu spezifizierenden Anwendung erfordern orientieren sich Interaktionsschritte in ihrer Granularit t an der Verantwortlichkeit einer bestimmten Klasse bzw einiger weniger eng gekoppelter Klassen im Klassenmodell benannte Dom nenob jekte vgl KSV96 Extern entspricht ein Interaktionsschritt in etwa einer Szene KSV96 also einem Fenster bzw einer Maske der Benutzungsoberfl che vgl VosNen98 Aus den durchgespielten bis jetzt textuell spezifizierten Geschaftsvorfallen extrahieren die Analytiker die grundlegende Ablaufstruktur also die Ubergangsbedingungen der Kanten in den Use Case Schrittgraphen Jeder Gesch ftsvorfall muss auf ein Szenario also einen Pfad in einem Use Case Schrittgraph abgebildet werden k nnen Vor und Nachbedingungen der Use Cases und Use Case Schritte bzw die bergangsbedingungen der Kanten werden zu n chst umgangssprachlich notiert und dann weiter formalisiert Teil Szenarien die in mehreren Use Case Schrittgraphen vorkommen k nnen zu Sub Use Cases zusammengefasst und mit dem Makroschritt Mechanismus wiederverwendet wer den Auf der anderen Seite bilden wir auch die im Use Case Modell spezifizierten extends und die uses Bezi
343. rreicht da der Zyklus aus den beiden unteren End Schritten prinzipiell unendlich viele Szenarien erm glicht W ren z B aufgrund einer Gesch ftsregel in jedem Szenario maximal 3 Ausf hrungen des oberen Endschritts erlaubt erg be sich eine Use Case Szenario berdeckung von e 2 23 08 da nun ber den linken Zweig 7 und ber den rechten Zweig 6 Pfade durch den Schrittgraphen m glich sind Q 10 4 Grenze Inneres und Pfad berdeckung Die Use Case Szenario berdeckung ist nur f r azyklische Use Case Schrittgraphen vollst n dig zu erf llen und muss in der Praxis geeignet eingeschr nkt werden Als praktisch relevan tere strukturelle Metrik definieren wir daher im Folgenden die Use Case Grenze Inneres berdeckung Cal Diese Metrik konzentriert sich gerade auf die Zyklen im Use Case Schritt graph und entspricht der schwachen cgr berdeckung des kontrollflussbezogenen Testens vgl Riedemann97 Wir ben tigen f r die Definition der Grenze Inneres berdeckung einige weitere Begriffe und Hilfsfunktionen zur Beschreibung und Verkn pfung von Pfaden und insbesondere von Zyklen im Use Case Schrittgraph die wir der eigentlichen Definition 10 18 voranstellen Ein Zyklus im Use Case Schrittgraph ist ein Pfad der an seinem Startschritt endet f r den also ucs ucs gilt Die Menge aller Zyklen in einem Use Case Schrittgraph uc berechnet Ope ration uc allCycles uc allCycles UCS UCS UCS uc allPaths ucs
344. rt Die Erweiterungspunkte eines Use Case vgl OMG97 1 Rekursive Makroschritte bzw Zyklen in der Inter Use Case Referenzfunktion schlie Den wir aus siehe Regel 5 4 6 Makroschritte extends uses und Generalisierung 83 Use Case Schrittgraph AG a y trace 7 S x A Use Case Schrittgraph AG A 7 d b ER 0 A trace extends 1 B CC t B Abb 6 11 Illustration der Semantik von uses a und extends b sind durch Makroschritte in seinem Schrittgraph repr sentiert Damit sind die in Kapitel 4 aufgezeigten Schw chen der beiden Beziehungen behoben Wir bertragen nun noch die Generalisierung von Use Cases auf die entsprechenden Use Case Schrittgraphen Neben der Konformit t der Vor und Nachbedingungen sollen im spe zialisierenden Schrittgraphen auch mindestens die Szenarien des generalisierten Use Case Schrittgraphen m glich sein Wir werden in dieser Arbeit keine weiteren Einschr nkungen bzgl der Generalisierung von Use Case Schrittgraphen machen und erhalten Definition 6 3 Es ist BG lt AG wenn f r alle Szenarien sz von AG gilt es gibt ein Szenario szg von BG welches von sz generalisiert wird Gilt B lt A dann muss gelten BG lt AG LI Die hnlichkeit der Generalisierung und der uses sowie der extends Beziehung ist unver kennbar da sie sozusagen erlaubte nderungen bzw Abwan
345. rt ei nen Use Case Schrittgraphen RefUC s makro Wir betrachten den Fall dass der Makroschritt kein Endschritt ist und mehrere Nachfolger hat Q Makroschritt mehrere Folgeschritte bergangsbedingungen der ausgehenden Kan ten schliessen sich gegenseitig aus kein Endschritt Abb 6 8 Den Aufruf bzw die Ausf hrung des referenzierten Use Cases deuten wir mit dem Schl sselwort DO an Im Sinne des Design by Contract s Meyer97 vereinbaren wir dass die Vorbedingung des referenzierten Use Cases von der des Makroschritts impliziert werden muss und umgekehrt die disjunktiv verkn pften Nachbedingungen der Endschritte des referenzierten Use Cases die Nachbedingung des Makroschritts implizieren es gelten also die beiden Implikationen Presmakro gt Pre REF Smakro und Post Post kr V SE REF S makro 78 Semantik BEGIN DO RefUC CASE c Schritt FolgeSchritt_l GOTO FolgeSchritt_1 RefUC KE Makroschritt ers l eege e schritt FolgeSchritt_n S B GOTO FolgeSchritt_n ELSE Folgeschritt 1 Folgeschritt n ERROR M END END Abb 6 8 Semantik 7 Makroschritt Somit gilt die f r Kontext und Interaktionsschritte definierte Semantik auch f r entspre chend im Schrittgraph eingebettete Makroschritte Wir werden weitergehende Nebenbedin gungen und Modellierungsregeln insbesondere zur Beleuchtung von Fragen wie z B Welche Abl ufe ergeben sich bei erfolgreicher nicht erfolgreicher Bearb
346. rte Starttrajektorie der Ariane 5 Ein besserer Test h tte diesen Fehler klar verhindert Der Projektmanager spricht von einem klaren Managementfehler So wurden z B zu den Reviews keine externen Spezialisten herangezogen und die Dokumentation war in konsistent Ein besseres Projektmanagement h tte diesen Fehler klar verhindert A Motivation und berblick Letztendlich ist jedes dieser Argumente richtig ohne ad quate Qualit tssicherung entsteht tehlerfreie Software nur aus fehlerfreien T tigkeiten Da der Mensch jedoch im Allge meinen dazu neigt Fehler zu machen ist die Qualit tssicherung bei allen T tigkeiten der Softwareentwicklung notwendig Nach diesem Beispiel eines Software Fehlers und seiner Auswirkungen pr zisieren wir eini ge Begriffe und betrachten die geschichtliche Entwicklung der Qualit tssicherung in der Softwareentwicklung Im letzten Abschnitt geben wir dann einen berblick ber die vorlie gende Arbeit 1 1 Begriffe und Gebiete der Qualit tssicherung Neben dem Standard Vokabular des Software Engineering vgl IEEE610 90 verwenden wir in dieser Arbeit spezielle Begriffe der Qualit tssicherung die wir im Folgenden kurz er l utern Hierbei lehnen wir uns an PagSix94 und Riedemann97 an Pr fgegenst nde sind die zugrundegelegten Betrachtungseinheiten Zu den Pr fgegenst n den bei der Softwareentwicklung geh ren z B die Anforderungsspezifikation die Software spezifikatio
347. rung einer einzelnen Operation und ist charakterisiert durch L einen Verweis es AK e K auf die Klasse des Objekts welches den Schritt es aus f hrt Q einen Verweis es WO e es AK allOperations auf die vom Schritt es ausgef hrte Operation im Klassenmodell und Q den Sichtbarkeitsbereich scope es SK c K LI Durch die Angabe der ausfiihrenden Klasse sind auch polymorphe bzw dynamisch gebun dene Aufrufe unver ndert geerbter bzw redefinierter Operationen ber cksichtigt Wir be schreiben den Sichtbarkeitsbereich weiter unten Die Benutzung bzw der Aufruf weiterer Operationen bei der Simulation einer Operations ausf hrung wird in der nachfolgenden Definition mit sog Folgeschritten modelliert Definition 11 2 Sei tsc ein Test Szenarioschritt mit SA ucs tsc Interaktion tsc verweist also auf einen Interaktionsschritt im Use Case Schrittgraph Die Episode zu tsc ist ein 3 Tu pel ep ES so o mit 1 ES ist eine nichtleere Menge von Episodenschritten 2 so ES ist der Startschritt der Episode 3 o ES 2 0 ist eine injektive Abbildung die jedem Episodenschritt eine Menge von Folgeschritten Operationsaufrufen zuordnet u Eine Episode ep zu einem Test Szenarioschritt tsc simuliert den Ablauf der Wurzeloperation des Interaktionsschritts auf den tsc verweist in einem bestimmten Kontext ep modelliert also einen Aufrufbaum oder Trace Daher darf jeder Episodenschritt be
348. s Verification 1 The process of evaluating a system or component to determine whether the prod ucts of a given development phase satisfy the conditions imposed at the start of that phase 2 Formal proof of program correctness IEEE610 90 Boehm bringt den Unterschied zwischen Validierung und Verifikation in den zwei folgen den oft zitierten Fragen auf den Punkt Informally we might define these terms via the following questions Verification Am I building the product right Validation Am I building the right product Boehm84 Wir kommen nun zu den Defekten die in der Validierung und Verifikation mit Reviews aufgesp rt werden sollen Die h ufigsten Fehler in Anforderungsspezifikationen lassen sich in drei Kategorien aufteilen vgl Boehm84 Meyer85 Poston87 IEEE830 93 IEEE1233 96 105 Q Die Vollst ndigkeit der Anforderungsspezifikation bedeutet dass jeder Anforderung mindestens ein Element der Anforderungsspezifikation zugeordnet ist fachliche Voll st ndigkeit Daneben stellen z B auch ungel ste Referenzen und l ckenhafte Num merierungen Unvollst ndigkeiten dar formale Vollst ndigkeit Q Bez glich der Konsistenz der Spezifikation in sich wird z B gepr ft ob zwei oder mehr Elemente der Spezifikation im Widerspruch zueinander stehen Hierzu z hlen auch Mehrdeutigkeiten ein Spezifikationselement l sst mindestens zwei Interpretati onen zu Formale Vollst ndigkeit und Konsistenz sind notwendig
349. s Modell sein Zu jedem Format existiert eine Menge wohldefinierter Transformationsregeln die jedes Primi tiv des SCORES Metamodells auf ein oder mehrere Primitive des Zielmodells trans formieren Unter Ber cksichtigung dieser Regeln interpretiert ein Generator die aktuellen SCORES Modelle und transformiert sie in das entsprechende Zielmodell In der zweiten Schicht befinden sich Komponenten auf die entweder nahezu alle Teilwerk zeuge der ersten Schicht zugreifen z B Metamodell Speichermanager oder Frameworks f r Editoren Browser und Generatoren die bestimmte generische Teilfunktionalit ten zur Verf gung stellen Analytiker Tester Werkzeuge Schnittstellen Editoren Validierung Testfallgenerator Browser Verifikation Codegenerator Dokumentation stat Analyse Objektgenerator Meta modell Generator Framework Editor Browser Manager f r persistente Daten speicherung DBMS Betriebssystem Abb 19 1 SCORESTOOL Grundlegender Aufbau vgl K sters97 Architektur 197 Metamodell Im Zentrum des Werkzeugs steht das SCORES Metamodell welches die Syntax und Semantik aller Primitive definiert und die vordefinierten Eigenschaften der Pri mitive dokumentiert Im bertragenen Sinne kann das Metamodell als m chtiges in tegriertes Datenlexikon angesehen werden welches eine wohldefinierte Basis f r alle Teilwerkzeuge darstellt M
350. s Objekts Intra Objekt Intra Klas se sondern erfasst gleichzeitig auch Aufrufe der Art Inter Objekt Intra Klasse und Inter Ob jekt Inter Klasse Die direkten Aufruf Interaktionen Tabelle 22 1 Nr 1 bis 6 sowie Nr 9 werden durch die Konstruktion des KBD ber cksichtigt Zeilen 7 bis 14 Die polymor phe direkte Aufruf Interaktion der Art I R Tabelle 22 1 Nr 8 wird durch die Funktion PolyKBD I ber cksichtigt Aufrufe der Art I N Tabelle 22 1 Nr 7 sind in Java nicht m g lich da aufgrund der statischen Typisierung Aufrufe undefinierter bzw noch nicht defi nierter Methoden zur Kompilierungszeit zur ckgewiesen werden Die direkten Daten Interaktionen 1 bis 6 sowie 9 werden durch die Konstruktion des KBD ber cksichtigt Zei len 15 bis 24 Aus der Konstruktion des KBD folgt so zun chst die berdeckung der direk ten Interaktionen Indirekte Interaktionen im KBD Abschlie end beleuchten wir wie sich indirekte Interaktionen Zustandsinteraktionen d h aufeinanderfolgende modifizierende und lesende Zugriffe auf Variablen im KBDI wieder finden Im Prinzip sind daf r Pfade im KBDI zu verfolgen die mit def bzw mit uses mar kierte Kanten zu bzw von verschiedenen Operationen beinhalten Da def bzw uses Kanten immer vom Variablen zum Methodenknoten bzw umgekehrt gerichtet sind enthalten die in direkten Interaktionen entsprechenden Pfade dabei immer gleichviele jeweils aufeinander folgende
351. s Rumbaugh sowie ab Ende 1995 auch Ivar Jacobson die Notationen ihrer Methoden OOA D OMT und OOSE Booch94 RBP 91 JCJ 92 Es entstand die Unified Mode ling Language UML deren Version 1 1 Ende 1997 von der Object Modeling Group stan dardisiert wurde OMG97 Zur Zeit wird die UML bez glich des Metamodells bzw der Semantik sowie f r die Modellierung von Gesch ftsprozessen berarbeitet OMG AT98 OMG99 Die Spezifikation der Anforderungen mit Use Cases bzw Use Case Diagrammen ist Gegen stand der Kapitel 2 und 4 Die dariiber hinaus in dieser Arbeit verwendeten Modellsichten bzw Diagramme der UML sind in OMG97 definiert Bei den im Rahmen dieser Arbeit ver wendeten deutschen Begriffen zur UML haben wir uns an die deutschsprachige Literatur zur UML orientiert vgl z B Kahlbrandt98 s auch BHJ 98 In manchen Fallen hat sich in zwischen die Situation eingestellt dass im Deutschen sowohl der englische Originalbegriff als auch ein deutsches Synonym verwendet wird Als Beispiel sei hier use case genannt was man mit Anwendungsfall bersetzt oder so wie in dieser Arbeit auch in anderen deutschsprachigen Ver ffentlichungen zu Use Case assimiliert Auch zur Benutzung des Wortes Akteur als bersetzung von Actor konnten wir uns nicht durchringen und verwenden als Kompromiss den Begriff Aktor 14 Entwicklungst tigkeiten 2 1 Gesch ftsprozesse und Anforderungsermittlung In diesem Abschnitt betrachten wi
352. s alle m glichen Interaktionen zwischen Objekten der Implementation unter Beachtung der Vererbungsstruktur erfasst Hierbei betrachten wir als Interaktionen den Botschaftsfluss sowie m gliche Zustands nderungen aufgrund einer Botschaft Zus tzlich zur formalen Definition geben wir einen Algorithmus zur Konstruktion des KBD aus den Java Quellcodes einer Anwendung sowie einige Darstellungskonventionen an und verdeutlichen die Definition an einem Beispiel Definition des KBD Wir erweitern zun chst Definition 22 1 KBD um die erforderlichen Elemente f r die Im plementation Definition 22 2 Seien K die Interfaces und Klassen Universum und OPS die Menge aller Operationen bzw Methoden im Quellcode einer Anwendung Das Klassen Botschaftsdia gramm KBD f r die Implementation ist ein gerichteter knoten und kantenmarkierter Mul tigraph V E P ber den Markenmengen Ly und L zusammen mit einer zweistelligen Relation P ber E m V COPS ist die Menge aller expliziten Methodendefinitionen im Universum K Q Ly class instance x method field ist die Menge aller Knotenmarkierungen mit der Bedeutung 243 e class Element existiert einmal f r alle Instanzen einer Klassen und e instance Element existiert f r jede Instanz e method Knoten entspricht einer Methode e field Knoten entspricht einer Variablen Li La Y this super new def uses inheritance message this super new def uses ist die M
353. s komplexeres Beispiel stellt Abb 17 3 vor Wir konstruieren aus einer L sung des GOK eine L sung der entsprechenden Instanz von SAT indem wir f r jedes Objekt der generierten Objektkonstellation den Wert des entspre chenden Literals zu w und den Wert aller anderen Literale zu f setzen F r jedes in a vorkom mende Literal Paar der Form u u grenzen 1 1 Beziehungen zwischen den entsprechenden V und L Klassen gerade solche L sungen des GOK aus deren zugeordnete Belegungen f r beide Literale u und u den gleichen Wahrheitswert ergeben also der Variablen u so wohl w als auch f zuordnen Umgekehrt ergibt jede L sung der Instanz von SAT eine L sung des GOK indem wir f r jedes mit true belegte Literal die zugeordnete Klasse instanzieren und dann die entsprechenden Verbindungen setzen Der vollst ndige Beweis findet sich in Winter99 m 186 Umgebungsaufbau und Testdatengenerierung a maa v b gt L sung Va a gt a w Bee a mav b iVb b Abb 17 3 Komplexeres Beispiel zur polynomialen Transformation von SAT auf GOK 17 3 Interaktionsdaten Zur Generierung von atomaren Interaktionsdaten existieren in der Literatur eine gro e An zahl von Verfahren s z B Beizer90 Beizer95 Myers79 Riedemann97 Poston96 Wir reissen die erforderlichen Schritte also nur kurz an Q Im Rahmen der black box und grey box Tests erzeugen wir die Interaktionsdaten z
354. s zentrales Modellierungskonzept von SCORES ein Use Case Schritt graphen verschmelzen funktionale Aspekte der Anforderungen mit ablaufbezogenen Aspekten wobei sich Szenarien nahtlos in die erhaltene kombinierte Sicht einf gen Diese Sicht wird dar ber hinaus mit den strukturellen Aspekten also dem Klassenmodell gekop pelt In Kapitel 8 geben wir methodische Hinweise zum Vorgehen bei der Anforderungser mittlung mit SCORES berblick ber die Arbeit 11 In Teil II befassen wir uns mit der Qualit tssicherung bei der Anforderungsermittlung mit SCORES Wir zeigen wie Analytiker und Tester mit Benutzern und Dom nen Experten zu n chst Use Cases bzw Schrittgraphen und wichtige Teile des Klassenmodells validieren Zus tzlich geben wir eine Methode zur rigorosen Pr fung bzw Verifikation des Klassen modells gegen Use Case Schrittgraphen und umgekehrt an Granularit t und Semantik der SCORES Anforderungsspezifikation erlauben die Formulierung von Testkriterien sowohl zur Bestimmung des Test Endes als auch zur Generierung von Testf llen Da sogenannte SCORES grey box Testf lle im Systemtest interne Interaktionen pr fen zeigen wir in Kapitel 13 wie die Anforderungsspezifikation und die bei ihrer Pr fung protokollierte Information ber den Entwurf in die Implementation hin nach verfolgt wird Nach der Implementation wird die Anwendung gegen die Anforderungsspezifikation getes tet Der dynamische Test der Anwendung gegen die SC
355. schen Use Cases f hrte zu nicht unerheblicher Konfusion sowohl bei Benut zern als auch Analytikern Rumbaugh merkt an I am not convinced that Jacobsons extends and uses relationships are fundamentally different Both can be treated as special cases of a directed adds relationship between a base case and an ad ditional case Rumbaugh94 Diese Uberzeugung hat jedoch nicht dazu gefiihrt dass die entsprechenden Definitionen in der UML ge ndert wurden Alternative Abl ufe sowie erfolgreiche und nicht erfolgreiche Szenarien sind weiterhin nur schwer in der Use Case Beschreibung identifizierbar vgl Cockburn97 Hurlbut98 Cockburn berichtet dementsprechend aus seiner Beratungspraxis von mehr als 18 verschiedenen Interpretationen bzw Arten von Use Case Modellierungen Cockburn97 Cockburns Fazit people are using whatever they think of as a use case to good effect Cockburn97 Das von Jacobson f r die Modellierung struktureller Anforderungen vorgeschlagene Analy semodell entspricht eher dem Entity Relationship Modell vgl z B Yourdon89 als denn einem voll ausgepr gten Klassenmodell Dadurch bleiben die Auswirkungen eines Use Cases unklar Im Extremfall wird f r jedes Interaktionsdiagramm eine andere Objektkonstellation zugrundegelegt was die Validierung des gesamten Use Cases verkompliziert Die Aufteilung der oft verkapselten komplexen Funktionalit t auf Schnittstellen Entit ts und Kontroll Ob jekte ist im Modell
356. schon bekannte Use Case Konzept um eine pr zise Aufgabenspezifikation Definition 5 1 Ein Use Case beschreibt die Ausf hrung einer wohldefinierten Aufgabe Wir charakterisieren jeden Use Case durch L einen im Anwendungskontext eindeutigen Namen Q eine informelle Beschreibung der Aufgabe L eine Menge A von Aktoren die bei der Bearbeitung des Use Cases mitwirken bzw am Ergebnis des Use Cases interessiert sind Q eine Vor und eine Nachbedingung welche die Annahmen bzw das Ergebnis der Auf gabe des Use Cases kennzeichnen LI F r die Menge der einem Use Case uc zugeordneten Aktoren schreiben wir auch A uc Als funktionales Konzept haben Use Cases kein Ged chtnis Wir entleihen daher das Ver tragskonzept der objektorientierten Programmierung s z B Meyer97 WBW 90 und spezifizieren die Aufgaben und insbesondere den Kontext bzw Zustand in dem sie ausge f hrt werden deskriptiv mit Vor und Nachbedingungen ber Dom nen Objekten bzw den Gegenst nden der Anwendung vgl Z llighoven98 wobei wir uns eng am Dom nen Klassenmodell anlehnen vgl Abschnitt 7 1 sowie OMG97 Die Vorbedingung gibt die minimalen Voraussetzungen an mit der die im Schritt beschriebene Aufgabe begonnen wer den kann Die Nachbedingung gibt m gliche Auswirkungen bzw das Ergebnis der Aufga benbearbeitung an Zu Beginn der Anforderungsermittlung spezifizieren wir diese Bedingungen informell in Hinblick auf eine automatisc
357. sdiagramme In diesem Anhang geben wir Algorithmen zur Generierung der in Teil IV der Arbeit informell eingef hrten Klassen Botschaftsdiagramme an Wir beginnen mit dem Klassen Botschafts diagramm f r die Anforderungsspezifikation KBD 4 A 1 Zur Motivation des Klassen Bot schaftsdiagramms f r die Implementation KBD diskutieren wir in Abschnitt A 2 die m glichen internen Interaktionen in objektorientierten Anwendungen und betrachten dann in Abschnitt A 3 die Generierung des KBD f r eine Implementation in der Programmierspra che Java Wir beenden diesen Anhang in Abschnitt A 4 mit einer kurzen Betrachtung zur Ausdrucksst rke des KBD A l Klassen Botschaftsdiagramme f r die Anforderungsspezifikation Im Fokus des Klassen Botschaftsdiagramms f r die Anforderungsspezifikation liegen die Operationen der Dom nenklassen sowie die Aufrufe bzw Benutzt Beziehungen zwischen ihnen Wir gehen davon aus dass insbesondere die komplexen Operationen der Dom nen klassen umfassend mit Episoden gepr ft wurden Kapitel 12 Wir treffen zun chst folgende Vereinbarungen Q Eine Benutzungsbeziehung manifestiert sich als Element der Nachfolgerschritt Re lation auf den Episodenschritten s Definition 11 2 wir nennen die dem Vorg nger schritt zugeordnete Operation die benutzende Operation Q Die im Kontext einer Instanz der ausf hrenden Klasse des Folgeschritts ausgef hrte Operation nennen wir die benutzte Operation Im Hinblic
358. se Anmelden Vorbedingung Karte im Kartenleser UND Kartenleser gesperrt Nachbedingung Karte angeboten UND Timer l uft END Karte Anbieten Kontextschritt Karte Entnehmen In Use Case Anmelden Vorbedingung Karte angeboten UND Kartenleser gesperrt UND Timer l uft Nachbedingung Karte entnommen UND Kartenleser betriebsbereit UND Timer gestoppt ODER Karte angeboten UND Timer gt 60 END Karte Entnehmen Interaktionsschritt Karte Einziehen In Use Case Anmelden Vorbedingung Karte angeboten UND Kartenleser gesperrt UND Timer gt 60 ODER Kartenleser gesperrt UND NICHT Karte lesbar Nachbedingung Karte eingezogen UND Timer gestoppt UND Kartenleser betriebsbereit END Karte Einziehen Abb 5 5 Bedingungen der Schritte im Use Case Schrittgraph Anmelden Bez glich der Kantenbedingungen ist anzumerken dass diese sich nicht auf Ereignisse wie z B bei Zustandsmaschinen Statecharts vgl HarNaa96 OMG97 beziehen sondern auf den Zustand der Anwendung bzw bestimmter Dom nenobjekte Abh ngig vom Stand der Aufgabenbearbeitung erm glichen sie die Auswahl der n chsten Teil Aufgabe Abb 5 6 zeigt die textuellen Spezifikationen der Kanten des Use Case Schrittgraphen Anmelden Kante Karte Einf hren Karte Lesen In Use Case Anmelden Bedingung Karte im Kartenleser END Karte Einf hren Karte Lesen Kante Karte Lesen PIN Anfordern In Use Case Anmelden Bedingung Karte lesbar UND Code g ltig END Karte Lesen PIN Anfordern Ka
359. ser betriebsbereit Nachbedingung Karte im Kartenleser Kartenleser gesperrt END Karte Einf hren Interaktionsschritt Karte Lesen In Use Case Anmelden Beschreibung Der Kartenleser liest den Magnetstreifen der Karte Aktoren Vorbedingung Karte im Kartenleser Kartenleser gesperrt Nachbedingung Kartenleser gesperrt Karte lesbar ODER Kartenleser gesperrt NICHT Karte lesbar END Karte Lesen Makroschritt Anmelden In Use Case Geld Abheben Beschreibung Der Bankkunde identifiziert sich gegen ber dem Bankautomaten Nach der Identifikation zeigt der Bankautomat die m glichen Transaktionen an Aktoren Bankkunde Zentralrechner Vorbedingung Kartenleser betriebsbereit Nachbedingung Karte im Kartenleser Kartenleser gesperrt Karte lesbar Code g ltig Bedienpult auswahlbereit ODER Karte ausgeworfen Kartenleser betriebsbereit ODER Karte eingezogen Kartenleser betriebsbereit END Anmelden Abb 5 4 Textuelle Spezifikation einiger Use Case Schritte 5 2 Use Case Schrittgraphen Die bis jetzt erreichte rein funktionale Zerlegung der Aufgabe eines Use Cases reicht zur Spe zifikation der m glichen Abl ufe bei der Bearbeitung dieser Aufgabe noch nicht aus Anstel le der bei der Aufgabenmodellierung blichen statischen Anordnung der Teil Aufgaben nach Benutzungsbeziehungen vgl KSV96 Rosson99 f hren wir nun eine die Abl ufe be leuchtende Relation auf den Use Case Schritten ein Diese gibt an in welchen m glichen Rei henfolgen die
360. sowie des funktionalen Testens von Programmen zur ckgreifen Wie bei den qualit tssichernden T tigkeiten in der Anforderungsermittlung unterteilen wir auch die Metriken in Validierungs und Verifikationsmetriken Validierungsmetriken messen in erster Linie die berdeckung der funktionalen Aspekte der Anforderungsspezifikation Sie geben also Antwort auf die Frage wie rigoros die Use Case Schrittgraphen validiert wur den Verifikationsmetriken beurteilen anhand funktionaler und struktureller Aspekte die Ve 116 Validierungsmetriken rifikation und geben damit Auskunft wie tief das Zusammenspiel von Use Case Schrittgraphen und Klassenmodell gepr ft ist Wie bei den Modellen f r den dynamischen Test von Anwendungen vgl Beizer90 Riedemann97 verwenden wir die Metriken so wohl zur Ableitung von Testf llen als auch in Form von Validierungs bzw Verifikations Endekriterien Wir beginnen mit einfachen auf dem Use Case Schrittgraphen aufbauenden strukturellen Metriken Use Case Schritt und Kanten berdeckung Als komplexere strukturelle Metriken definieren wir dann die Use Case Szenario Grenze Inneres und Pfad berdeckung Mit der Use Case Schritt berdeckung konzentrieren wir uns auf die Aufgaben und somit die funkti onale Zerlegung Die anderen berdeckungen zielen auf die bergangsbedingungen und so mit auf die Ablauflogik der Use Case Schrittgraphen Wir definieren die Metriken wieder mit OCL Operationen zur OCL s
361. spezifikation Ausgabe Ausf hrungsprotokolle Test Reihenfolge tre generieren FORALL uc e UC ORDERED BY tre DO FORALL ts e uc Test Szenarien DO REPEAT Datenbank einrichten Daten fiir die Interaktionsparameter der Schritte von ts generieren Testskript generieren und ausf hren UNTIL Test Endekriterium erf llt OR Test Resource f r Test Szenario ausgesch pft FORALL 9 Je nach Ressourcenstand weitere Testf lle ermitteln und ausf hren END Black box Test DJ Oo Om FWD Abb 15 3 Algorithmus Black box Test 166 Black box Test Fehleraufdeckungsrate basierender Test Endekriterien siehe z B Riedemann97 oder Siegel96 Offen blieb bisher die Frage wie die Klassenhierarchie bei der Ausfiihrung der Test Szena rien ber cksichtigt wird Prinzipiell sind f r die Interaktionsparameter alle Kombinationen von Klassen bzw Unterklassen zu testen Wenn dies zu einer kombinatorischen Explosion auszuf hrender Tests f hrt sollten wenigstens in gewissem Sinne repr sentative Kombi nationen selektiert werden So sollte jede Klasse mindestens einmal instanziiert und als Inter aktionsparameter verwendet werden Ein systematisches Auswahlverfahren auf der Grundlage des statistischen Entwurfs komplexer Experimente mit orthogonalen Feldern Or thogonal Array Test Support OATS Roy90 geben McDaniel und McGregor an McDMcG94 Den prinzipiellen technischen Ansatz des black box Tests der Anwendung zeigt Abb 15 4
362. sschritts deren anwendungsinterne Darstellung Wurzelklasse und Wurzeloperation 89 Wie wir in Kapitel 11 zeigen sind die Klassenbereiche bei der Simulation der Use Case Schrittgraphen w hrend der Verifikation der Anforderungsspezifikation Grundlage f r ein dem Sichtbarkeitsbereich bei Programmiersprachen vgl Poetzsch91 Meyer97 bzw den in einem Vertrag involvierten Klassen WBW 90 entsprechendes Konzept Wir geben noch zwei Regeln zur sinnvollen Gestaltung der Klassenbereiche an Die erste Regel gibt an dass die in den Vor und Nachbedingungen der Aufgabenbeschrei bungen verwendeten Klassen Element der jeweiligen Klassenbereiche sein m ssen Regel 7 2 1 Use Case Schritt Klassenbereich Der Klassenbereich eines Use Case Schritt graphen bzw Use Case Schritts muss alle in seiner Beschreibung und der Vor und Nachbedingung vorkommenden Klassen bzw Objekte enthalten F r die sinnvolle Modellierung der Klassenbereiche im Fall von Makroschritten geben wir die folgende unmittelbar einsichtige Regel an die eine notwendige Bedingung zur Ausf h rung der Aufgabe des Makroschritts durch den Aufruf des referenzierten Use Case Schritt graphen formuliert Regel 7 2 2 Makro Klassenbereich Der Klassenbereich des Makroschritts muss konform zu dem Klassenbereich des referenzierten Use Case Schrittgraphen sein Y s e S uc SA s Makro gt B s cy B REF s In konkreten Objektkonstellationen d rfen dementsprechend I
363. ssenmodell einige Vollst n digkeitsmetriken angeben Im n chsten Teil betrachten wir die qualit tssichernden T tigkeiten bei der Anforderungser mittlung Einerseits muss sichergestellt werden dass die Anforderungen und W nsche der Benutzer in der Anforderungsspezifikation fachlich vollst ndig und richtig ber cksichtigt wurden Analytiker und Benutzer validieren dazu das Use Case Modell Andererseits pr fen Analytiker und Tester ob die Anforderungsspezifikation konsistent und formal vollst n dig ist hierzu erm glicht SCORES insbesondere die Verifikation des Klassenmodells gegen die Use Cases In Teil IV zeigen wir dann wie sozusagen als Mehrwert der Qualit tssiche rung f r die SCORES Anforderungsspezifikation Testf lle f r den Test der Anwendung gegen die Anforderungsspezifikation abgeleitet und zum Teil generiert werden k nnen womit die entwicklungsbegleitende Qualit tssicherung als Hauptziel der Arbeit erreicht ist Teil II Validierung und Verifikation der Anforderungsspezifikation In diesem Teil befassen wir uns mit Qualit tssicherung bei der Anforderungsermittlung mit SCORES In den Kapiteln 9 und 10 zeigen wir wie Analytiker und Tester mit Benutzern und Dom nen Experten zun chst Use Cases bzw Use Case Schrittgraphen und Teile des Klassenmodells validieren Inhalt der darauf fol genden beiden Kapitel ist die rigorose Pr fung bzw Verifikati on des Klassenmodells gegen die Use Case Schrittgr
364. sspezifikation 33 36 48 159 161 169 E ENER 34 Massen sa net 35 SCORES grey box11 160 169 212 213 EE 34 EE 34 35 white bOX en ee 6 Test ausf hrung es us oS ote E 189 AUSWETIIDE u ea EN 190 dam eve een 6 endekriterium age ar essen 6 Falls ers ge 6 Kriterium 22 ne ee 6 management 42 cts ia enter 7 orakel 7 160 163 176 191 Prozess Geet suk ees eye eee Rhee RS 7 vorfallsbericht EE 190 Testmod ll at ee ie 5 RESUME OTIS et eet e 5 Testverfahren 22234328 EE 7 Testwerkzeug 3220 0 ve ee de AE 7 206 U Uberdeckung EE Gee wee ee are al eee ana fone 93 Bedingungs minimale Mehrfach 138 einfache Klassen 92 vollst ndige Klassen 93 vollst ndige Operations 140 bergangsbedingung 65 258 UR rs nun une 20 61 Diagramm 242224224 22a 21 Erweiterungspunkte 82 Generalisierung 83 Use Case Diagramm 42 Use Case Schritt ya 54 4454 Vesa ds 62 BIA oie ck bios race 66 81 Frida 82 Endsehritie 2 4 65 70 80 innerer ss sr dy sand 66 80 Interaktions 63 163 Kontext 63 163 E unsre te ees 63 163 Startschritt 65 70 80 82 Wurzelsehritt 9 4 Sien KE KN 70 Use Case Schrittgraph 65 EE 21 82 V Validierung 2 142 nr 5 104 Mein 115 Validierungseinheit 200 Vererbungskante oo 4 240004 172 Verfolebarkeit 2 See ta
365. stellung des KBD gel tende Vereinbarungen Q Knoten die Instanz und Klassen Variablen zugeordnet sind zeichnen wir als Paral lelogramm in das wir den qualifizierten Namen der Variablen schreiben LI Mit def und uses markierte Kanten stellen wir wie Botschaftskanten dar also durch einen offenen Pfeil Wir betrachten zur Illustration ein einfaches Beispiel 174 SCORES grey box Test Beispiel 16 2 Abb 16 2 a zeigt ein Java Code Fragment mit zwei Klassen A und B wobei B direkte Unterklasse von A ist Das KBD f r die Klassen A und B zeigt Abb 16 2 b Zu n chst sehen wir vier Methodenknoten anstelle von zwei da die Default Konstruktoren f r beide Klassen ber cksichtigt sind vgl GJS96 Eine mit def markierte Kante verbindet die Variablenknoten mit den jeweiligen Konstruktorknoten Mit der Vererbungskante wird die Redefinition der Methode opA in der Klasse B ber cksich tigt Die Botschaftskante von B opA zu Methode opA in Klasse A reflektiert den Gebrauch des Schl sselworts super in B opA und die m gliche polymorphen Bindungen der Bot schaftsquelle einA opA Die Anweisung einA opA in der Methode B opA f hrt dementspre chend auch zur selbst rekursiven Botschaftskante mit dem Ziel B opA Die mit def markierten Kanten vom Variablenknoten A a zu den drei Methodenknoten A A opA und B opA zeigen die m gliche Modifikation der Instanzvariablen a und damit di rekte Datenintera
366. t die Verkapselung von Daten und Operationen in abstrakten Datentypen ADT vgl LisZil75 GutHor78 Dieser Weg geht vom Geheimnisprinzip aus Parnas72 Realisie rungsdetails werden hinter wohldefinierten Schnittstellen verborgen die z B mit Vertr gen contracts also Vor und Nachbedingungen jeder Operation und Invarianten des ADT spe zifiziert wird vgl Meyer97 Von der Korrektheit der einzelnen Teile einer Anwendung wird dann auf die Korrektheit der vollst ndigen Anwendung geschlossen vgl Poetzsch97 Die Objektorientierung erweitert diese Konzepte um die Vererbung und den damit verbunde nen Polymorphismus so dass im Prinzip eine in Bezug auf die Anzahl von Operationen ex ponentielle Anzahl von internen Interaktionen m glich ist die beim Einsatz herk mmlicher Spezifikationsmethoden auch alle zu verifizieren bzw zu testen sind s Anhang A 2 Weg ner bemerkt hierzu Object oriented programs are more expressive than procedure oriented programs in providing cli ents with continuing services over time they are specified by marriage contracts that cannot be expressed by procedure oriented sales contracts Wegner97 Und weiter Object oriented programming is not compositional composite structures of interactive compo nents have emergent behavior such that the whole is greater than the sum of its parts WegGol99 Aus diesen Griinden werden in aktuellen Arbeiten formale Methoden bzw Verifikationskal k le fiir ob
367. t die kontextuelle Interaktions und systeminterne Information Abb 21 2 und ber cksichtigt die Qualit tssicherung bereits in den fr hen Phasen der Entwicklung objektorientierter Software da sie den nahtlosen verfolgbaren bergang von den umgeben den Gesch ftsprozessen ber Use Cases zum Dom nen Klassenmodell erm glicht Aufbauend auf der Verfeinerung und Pr zisierung des Use Case Konzepts mit Use Case Schrittgraphen werden sowohl die Validierung der Use Cases und wichtiger Teile des Klas senmodells als auch die Verifikation des Klassenmodells gegen das Use Case Modell und teilweise umgekehrt unterst tzt Hierbei erlaubt die Scores Anforderungsspezifikation die straktion Funktionale Q lt S Use Case T Use Casa Schritt Schrittgraph Gesch fts Tees Szenario Spezifikation Test Szenario en Qualit tssicherung 2 Beziehung Bekannte Konzepte g In dieser Arbeit ein 2 Operation gef hrte Konzepte Niedrig Geck Strukturelle Abstraktion Abb 21 1 SCORES bergang vom Use Case Modell zum Klassenmodell 212 Res mee 4 Interaktion nee Referenz Andere r Ziele Geschaefts Prozesse etc Interaktions schritt Anderes VU System Systeminterne Information Interaktions information Kontextuelle Information Abb 21 2 SCORES Abdeckung der drei Informationsarten nach PohHau97
368. t kann der Tester in diesem Fall sofort erkennen welche Interaktionen nicht ausf hrbar sind und diese nach Ausf hrung aller Tests manuell eliminieren Q F r Unterklassen im Klassenmodell der Anforderungsspezifiaktion wurden keine ei genen Test Szenarien bzw Episoden angegeben Mit dem in HMGF92 vorgestellten Algorithmus k nnen wir die notwendigen Erweiterungen der Test Szenarien berech nen bzw zumindest angeben f r welche Unterklassen neue Episoden durchgespielt und im grey box Test verwendet werden m ssen 16 4 Testfallerweiterung Im SCORES grey box Test erweitern wir die Testf lle des black box Tests Hierf r benutzen wir die bei der Simulation der Episoden operationalisierten Spezifikationen der Wurzelo perationen als Testorakel zur Spezifikation des erwarteten Ablaufs sowie der erwarteten nderungen an der Objektkonstellation Methodisches Vorgehen 177 Q F r jeden Testfall des black box Tests ermitteln wir aus den Episoden der Schritte des entsprechenden Test Szenarios die ber hrten Elemente des Dom nenklassendia gramms Q ber die Verfolgbarkeitsrelation ermitteln wir alle Elemente der Implementation welche zur ck zu den ber hrten Elementen verfolgbar sind Q Die von der Episode vorgegebene Reihenfolge bertragen wir auf die Elemente der Implementation und erhalten die bei der Ausf hrung der Testf lle in der Anwendung erwarteten Abl ufe Q Objekte die in der Anwendung vor
369. t wird Gesch ftsprozesse und Anforderungsermittlung 21 Scenario A specific sequence of actions that illustrates behaviours A scenario may be used to il lustrate an interaction OMG97 Semantics Guide Bei der Anforderungsermittlung k nnen prinzipiell zwei F lle eintreten die eine weitere Strukturierung des Use Case Modells notwendig machen 1 Die Vielzahl der Use Cases macht das Modell un berschaubar 2 Einzelne Use Cases werden sehr komplex Zun chst k nnen Use Cases ebenso wie Aktoren als Unterklasse der Metaklasse Classifier generalisiert werden Im Falle vieler kleinerer Use Cases k nnen in der UML Use Cases wie alle anderen Modellierungselemente auch zu Paketen zusammengefasst werden Dies verbessert zwar den berblick gibt aber keine Hilfe bei der Vermeidung von Redundanzen und bei der Darstellung von Abh ngigkeiten zwischen verschiedenen Use Cases Hierzu und f r den Fall komplexer Use Cases gibt Jacobson zwei als extends und uses bezeichnete spe zielle Generalisierungsbeziehungen zwischen Use Cases an Zwei Use Cases werden durch die extends Beziehung verkn pft wenn sie hnlich sind je doch einer der beiden Use Cases eine erweiterte Funktionalit t beschreibt An extends relationships from use case A to use case B indicates that an instance of use case B may include subject to specific conditions specified in the extension the behaviour specified by A OMG97 Notation Guide Die uses Beziehung w
370. tationen ermittelt werden Inwiefern m ssen geerbte Methoden in der Unterklasse erneut gepr ft werden K nnen Testf lle wiederverwendet werden Wie sind Polymorphismus und dynamische Methodenbindungen zu testen Q Q Q Q Wie werden objektorientierte Testf lle und Testdaten repr sentiert Vor diesem Hintergrund geben wir nach der Festlegung einiger Grundbegriffe in den n chs ten Abschnitten einen Uberblick dar ber welche Gebiete der Qualit tssicherung durch die Objektorientierung berhaupt ber hrt werden und die Entwicklung und den Einsatz von spe ziellen Verfahren erforderlich machen 3 1 Formale Methoden Wiederholt wird in der Literatur behauptet dass die einzelnen Operationen bei der objekto rientierten Programmierung wesentlich einfacher sind als in der herk mmlichen prozedura len Programmierung vgl Meyer85 PerKai90 Hatton98 Die Tatsache dass die heutzutage oft objektorientiert entwickelten Anwendungen ein Vielfaches der Komplexit t der noch vor zehn Jahren mit herk mmlichen Methoden durchgef hrten Projekte haben stellt uns somit vor die Frage wo sich die h here Komplexit t objektorientierter Anwendungen niederschl gt Die offensichtliche Antwort ist in den internen Interaktionen also der Kom munikation zwischen Objekten vgl Binder96a HKR 97 Winter98 s auch Anhang A 2 Formale Methoden 29 Ein schon seit Anfang der siebziger Jahre beschrittener Weg zur Komplexit tsbeherrschung is
371. tdeckt wird desto h her ist der Aufwand f r seine Behebung da eine rasch wachsende Zahl von Entwicklungsprodukten betroffen ist vgl Tab 2 1 S Seite 18 Es treten also Methoden und Verfahren zur Qualit tssicherung f r die fr hen Phasen wie z B die Anforderungsermitt lung in den Vordergrund 1 3 berblick ber die Arbeit In Kapitel 2 skizzieren wir die T tigkeiten bei der Entwicklung objektorientierter Software und stellen damit den Bezugsrahmen f r die Arbeit her Hierbei konzentrieren wir uns auf die fr hen T tigkeiten insbesondere auf die Anforderungsermittlung In Kapitel 3 wenden wir uns der Qualit tssicherung in der objektorientierten Softwareentwicklung zu Da die Kom plexit t hier in den Interaktionen zwischen Objekten liegt erweisen sich strukturelle white box Klassentests als wenig aussagekr ftig Aufgrund des z T sehr hohen Aufwandes ist ihr Einsatz nicht effektiv F r funktionale black box Tests der Anwendung gegen die Anforde rungsspezifikation sind im Falle objektorientierter Anforderungsspezifikationen neue Ver fahren notwendig In Kapitel 4 beleuchten wir daher als den diesbez glichen State of the Art die objektorientierte Anforderungsspezifikation mit Use Cases und Klassenmodellen Wir listen anhand eines Fallbeispiels Schwachpunkte auf welche die Qualit tssicherung bei 10 Motivation und berblick Abnahmetest Testf lle IR estf lle Test der Anforde
372. te Darstellungen transformiert werden die innerhalb der SEU weiter bearbeitet werden k nnen Modellierungswerkzeuge Zu den Modellierungswerkzeugen z hlen beispielsweise Edito ren Browser oder statische Analysatoren Ein graphischer Editor und unterschiedliche Spezifikationseditoren dienen zum Erzeugen ndern und zur Gestaltung des Layouts 1 GEOOOA ist eine objektorientierte Methode zur Anforderungsspezifikation f r geografi sche Informationssysteme KPS96 K sters97 196 Konzepte z B von Klassenmodellen Viele der SCORES Modellierungsregeln werden von den statischen Analysatoren bereits bei der Konstruktion der entsprechenden Teile der An forderungsspezifikation berpr ft Validierungs und Verifikationswerkzeuge Hierzu z hlen beispielsweise Animationswerk zeuge oder statische Analysatoren Erstere unterst tzen Analytiker und Tester bei der Eingabe und Editierung von Objektmodellen Test Szenarien und Episoden Letztere ermitteln z B die aktuellen Werte der verschiedenen Vollst ndigkeits Validierungs und Verifikationsmetriken Schnittstellen Um die Ergebnisse der Anforderungsermittlung und der Validierung und Ve rifikation der Anforderungsspezifikation auch in den nachfolgenden Entwicklungs schritten verf gbar zu machen k nnen die Modelle in unterschiedliche Formate bzw Modelle transformiert werden Abh ngig von der ausgew hlten Zielumgebung kann das Zielmodell zum Beispiel ein ER oder objektorientierte
373. tellende Softwareprodukt bereinstimmt Zusammenfassend halten wir fest viele Schwierigkeiten bei der Erstellung brauchbarer An forderungsspezifikationen sind in der Tatsache zu suchen dass die Anforderungsspezifikati on zwei Aufgaben mit gegens tzlichen Zielen erf llen soll Auf der einen Seite soll sie informell intuitiv und f r Nicht Informatiker verst ndlich sein damit Benutzer und Auftrag geber mit Analytikern und Testern validieren k nnen that we are building the right pro duct Boehm84 Auf der anderen Seite soll die Anforderungsspezifikation pr zise genug sein um Analytikern Testern und Entwicklern als Ausgangsbasis f r Pr fungen bez glich der Frage that we are building the product right Boehm84 dienen kann Anforderungsermittlung mit Use Cases Die Anforderungsspezifikation pr zisiert die sachlichen Aspekte eines Gesch ftsprozesses in Hinblick auf eine bestimmte Anwendung Strukturierte Methoden wie die Moderne Struk turierte Analyse MSA vgl Yourdon89 und mehr noch die ersten objektorientier ten Methoden wie die objektorientierte Analyse Object Oriented Analysis OOA CoaYou90 oder der objektorientierte Entwurf Object Oriented Design OOD WBW 90 betonen die strukturellen eher daten bzw informationsorientierten Aspekte das Klassenmodell Erst die von Ivar Jacobson Anfang der 90er Jahre eingef hrten Use Cases ndern den Stellenwert der funktionalen Sicht in der objekto
374. ten Use Case Schritte nicht die Nachbedingung des Use Cases impliziert Y sz Szenarien uc A are Post gt Poste Die n chste Regel ist notwendig f r die Ausf hrbarkeit bzw lifeness der Use Case Schrittgraphen vgl DesObe96 HOR98 Ist ein Use Case Schritt innerer Schritt hat also mindestens einen Folgeschritt so muss in jedem Fall nach der Bearbeitung seiner Aufgabe mindestens einer seiner Folgeschritte ausgew hlt werden k nnen Regel 6 3 3 Innerer Schritt Nachbedingung Die Nachbedingung jedes nicht als Endschritt markierten inneren Schritts s eines Use Case Schrittgraphen uc muss die Disjunktion der Bedingungen seiner ausgehenden Kanten implizieren Y se S uc SF uc Post gt Ve eme CE 1 Aufeinander folgende Zustands nderungen von Dom nenobjekten behandeln wir in Ab schnitt 11 3 Modellierungsregeln ID 81 Zum Schluss geben wir noch einige Modellierungsregeln zum sinnvollen Gebrauch von Ma kroschritten an Zun chst zwei Regeln ber erlaubte Aufrufe Use Case Schritte und Use Case Schrittgraphen entsprechen einer funktionalen Zerlegung wobei Makroschritte die Be nutzung eines Sub Use Cases durch einen oder mehrere Super Use Cases erm glichen Wir betrachten nun das Verh ltnis der Aktoren des Makroschritts zu denen des referenzierten Use Cases Die folgende Regel stellt sicher dass die Aktoren des referenzierten Use Cases die Aufgabe des Makroschritts bearbeiten k nn
375. ten Firmen berblick ber die Arbeit 9 Q Haupts chlich wird in den sp ten Phasen der Softwareentwicklung gepr ft die wichtigen fr hen Phasen wie Anforderungsermittlung und Entwurf werden in Be zug auf die Qualit tssicherung vernachl ssigt Q 12 von 74 Softwareh usern testen auch in der Realisierungsphase nicht oder nur teil weise Q Nur bei wenigen Firmen erfolgt eine detaillierte Zeit und Ressourcenplanung Daher kommt es zu Engp ssen durch die nur ein Teil der vorgesehenen Pr fungen durchge f hrt werden k nnen Q Nur ein Drittel der Firmen unterst tzen Schulungen im Bereich der Qualit tssicherung oder stellen Mitarbeiter der Fachabteilungen f r die Tests frei Q Bei ber zwei Dritteln der Firmen wird der Soll Ist Vergleich bei den Tests nicht re gelm ig durchgef hrt L Bez glich formaler Kriterien zur Messung des Testfortschritts wird die Funktionsab deckung am h ufigsten verwendet Insgesamt stellen M ller und Wiegmann fest dass in der Qualit tssicherung bei der Soft wareentwicklung die Schere zwischen Forschung und Praxis weit auseinanderklafft Eine wichtige Aufgabe ist es also an industrielle Erfordernisse angepasste Methoden und Verfah ren zur Qualit tssicherung bei der Softwareentwicklung anzugeben Hinzu kommen die berproportional mit der Zeit zwischen Fehlerentstehung und entde ckung steigenden Kosten der Fehlerentdeckung und behebung Je sp ter ein Fehler en
376. ten Klassen Botschaftsdiagramm f r die Anforderungsspezifikation zusammen Abschnitt 16 1 In den Abschnitten 16 2 und 16 3 zeigen wir dann wie diese z B mit den in Kapitel 13 vorgestellten Techniken zu Ge sch ftsobjekten oder Fachklassen vgl Z llighoven98 der Implementation nachver folgt werden k nnen In Abschnitt 16 4 verfeinern wir dann die rein funktionalen auf externe Interaktionen bezogenen black box Testf lle zu sogenannten grey box Testf llen die ana log zu entwurfsbasierten Systemtests vgl Hetzel88 interne Interaktionen ber cksichtigen und gezielt zur Erf llung struktureller Testkriterien beitragen 16 1 Klassen Botschaftsdiagramm der Anforderungsspezifikation Wesentlich f r unser Vorgehen ist dass die komplexen Operationen der Dom nenklassen umfassend mit Episoden gepr ft wurden Kapitel 12 und die hierbei explizit gemachte sys teminterne Information protokolliert ist Wir betrachten nun die Gesamtheit der internen In teraktionen zwischen Dom nenklassen Im Fokus liegen also deren Operationen sowie die Aufrufe bzw Benutzungs Beziehungen zwischen ihnen Jeder Episodenschritt repr sentiert die Ausf hrung einer bestimmten in einer Dom nen klasse deklarierten Operation Die Benutzungsbeziehungen zwischen den Operationen 170 SCORES grey box Test sind in der Folgeschrittfunktion der Episoden protokolliert Wie fassen diese Beziehungen in einem Graph zusammen den wi
377. terst tzung so dass zus tzlich zu fehlenden Verfahren f r den Test gegen objektorientierte Anforderungsspezifikationen auch ein Defizit bez glich der Qualit tssicherung bei der Anforderungsermittlung selbst besteht Wir be leuchten daher im n chsten Kapitel unter dem Gesichtspunkt der Testbarkeit den Stand der Technik bei der Anforderungsermittlung die Use Case Analyse Initialisieren Stimulieren Validieren d y Tester Tool A e Grafisch interaktive Benutzungsoberflache 1 3 rer Funktionaler Kern der Anwendung 9 e _ Persistente Objekte Datenbank Abb 3 3 Herk mmlicher black box Systemtest Kapitel 4 Probleme der Anforderungsermittlung mit Use Cases The hardest single part of building a system is deciding exactly what to build Brooks87 Wir interessieren uns im Rahmen dieser Arbeit f r die DV Unterst tzung bereits modellierter relativ stabiler Gesch ftsprozesse Unsere Betrachtungen zielen daher auf die Anforde rungsermittlung f r eine einzelne neu zu entwickelnde Anwendung ab envisioned applica tion Hierzu haben wir in Kapitel 2 bereits die Use Case Analyse nach Jacobson skizziert JCJ 92 Anhand eines Fallbeispiels listen wir in diesem Kapitel einige Schwachpunkte des Use Case Konzepts in Bezug auf den Test gegen die Anforderungsspezifikation auf und diskutieren relevante Arbeiten zu ihrer Behebung 4 1 Fallbeispiel
378. test f r Smalltalk 80 Programme SieNew94 R ppel entwickelt ein generisches Werkzeugkonzept f r den Klassentest R ppel96 Der Vorteil des Pr fens von Aufrufsequenzen besteht in dem geringeren Aufwand bei der Er stellung der Testumgebung sowie der Testf lle und Testdaten da ein Aufruf eine ganze Reihe von Operationen pr fen kann vgl JorEri94 Daneben werden nicht nur die einzel nen Operationen sondern direkt auch ihr Zusammenspiel gepr ft Als Nachteil sehen wir den aufgrund der vorgegebenen partiellen Reihenfolge der Operationen h heren Kommunika tionsaufwand verbunden mit dem geringeren Potential der Parallel Arbeit bei Entwick lungs und Test T tigkeiten Dar ber hinaus besteht die Gefahr der Fehlermaskierung d h nachfolgende Operationen in einem Test verhindern die Entdeckung eines Fehlers in einer Operation vgl Spillner90 Im Gegensatz zu modularer Software wo gr tenteils Baumstrukturen der Benutzungsbezie hungen auftreten sind in objektorientierten Anwendungen oft Graphen mit starken Zusam menhangskomponenten cluster und zyklischen Abh ngigkeiten zu beobachten vgl Overbeck94 Binder96a KHG98 s auch Anhang A 21 F r einen 30 Klassen umfassenden Ausschnitt der Container Klassen in der Smalltalk 80 Klassenbibliothek GolRob89 wur 1 Zyklische Abh ngigkeiten treten h ufig bei der Verwendung von Entwurfsmustern GHJ 94 auf vgl Winter98 Black box Test gegen die
379. tierte Anforderungsspezifikationen 37 relation zusammenfasst und zur Testfallableitung verwendet F r rigorose Tests in tegrity verification schl gt Binder vor die tats chlichen Abl ufe mit den in Interak tionsdiagrammen spezifizierten zu vergleichen thread coverage McGregor gibt methodische Hinweise zur Planung des Tests gegen die mit Use Cases spe zifizierten funktionalen Anforderungen McGregor97 Jedem Use Case werden ein Nutzungsprofil use profile sowie bestimmte Kritikalit ten zugeordnet mit denen die Zuteilung von Ressourcen gesteuert wird Konkrete Techniken zur Testfallermittlung werden nicht angegeben Poston beschreibt M glichkeiten zur Generierung funktionaler Tests aus Signaturen der Operationen in Klassenmodellen Poston94 sowie aus um Signaturen f r die Ein gabeparameter erweiterten Sequenzdiagrammen zu Use Cases Poston98 Beiden Ans tzen liegen Methoden des funktionalen Testens von Operationen zugrunde quivalenzklassenbildung Bedingungs berdeckung s Beizer90 Riedemann97 Balzert schreibt zum Systemtest Der Systemtest ist der abschlie ende Test der Software Entwickler und Qualit tssicherer in der realen Umgebung ohne den Auftraggeber Im Unterschied zum Integrationstest ist beim Systemtest nur das u ere des Systems sichtbar d h die Benutzungsoberfl che und ande re externe Schnittstellen des Systems Basis f r den Systemtest ist die Produktdefiniti
380. tierter Software a b Abb 22 2 Beziehungsgeflechte Modular a und Objektorientiert b 1 Der Aufrufgraph ist bei nicht rekursiver Operationen azyklisch 241 a Diese f hren aufgrund der Vererbung und der dynamischen Bindung sogar zu einem exponentiellen Wachstum der m glichen Interaktionen und lassen sich zudem nicht ohne gr eren Aufwand statisch ermitteln vgl PalSch94 Wir pr zisieren den Begriff der internen Interaktion in objektorientierten Anwendungen folgenderma en Q Sendet ein Objekt bei der Ausf hrung einer Methode eine Botschaft an ein nicht not wendigerweise verschiedenes Objekt bzw greift lesend oder schreibend auf eine Klassen oder Instanz Variable zu so sprechen wir von einer direkten Aufruf bzw Daten Interaktion LI Beeinflusst eine direkte Interaktion eine nachfolgende Methodenausf hrung so nen nen wir dies eine indirekte Interaktion Bei der hier betrachteten Klasse objektorien tierter Anwendungen sind indirekte Interaktionen nur ber die Manipulation von Klassen oder Instanz Variablen also durch direkte Dateninteraktionen m glich so dass wir auch von Zustandsinteraktionen reden Weiterhin unterscheiden wir ob die Interaktion stattfindet Q innerhalb eines Objekts Intra Klassen Intra Objekt Interaktion Q zwischen zwei Objekten der gleichen Klasse Intra Klassen Inter Objekt Interaktion L zwischen zwei Objekten verschiedener Klassen innerhalb einer Vererbungshierar
381. tionen der Anwendung mit Benutzern oder benachbarten Systemen externe Interaktionen und 4 Interaktion Referenz Andere T Be aoe Stakeholder Ziele E Gesch fts Systeminterne Prozess Information etc Interaktions information Kontextuelle Information Abb 4 5 Die drei Informationsarten bei der Anforderungsermittlung PohHau97 Offene Fragen und Kritik 47 oO systeminterne Information beschreibt Interna der Anwendung selbst Zust nde von Dom nenklassen interne Interaktionen zwischen Instanzen von Dom nenklassen Jacobsons Use Case Analyse beinhaltet im Wesentlichen Interaktionsinformation die in ers ter Linie das Zusammenspiel der Anwendung mit den Stakeholdern von der Anwendung be troffene Personen menschliche Aktoren und anderen Anwendungen maschinelle Aktoren beschreibt vgl PohHau97 Kontextuelle Information wie z B das Zusammen spiel der Stakeholder untereinander sowie mit anderen Anwendungen wird nicht in Use Ca ses erfasst A use case is manifested by sequences of messages exchanged among the system and one or more outside interactors called actors together with the actions performed by the system OMG99 Notation Guide Durch die Beschr nkung auf die Interaktionsinformation kann der Analytiker bei der Use Case Modellierung nach Jacobson Teile der Anforderungen wie z B die Einbettung der An wendung in ihren Kontext od
382. tionsmetriken in Form von Testkriterien geben wir in Kapitel 10 und 12 an Mit dem dreifachen Gleichheitszeichen kennzeichnen wir die Definitionsgleichung einer Funktion oder einer Metrik Wir definieren die Metriken ebenso wie die der in Kapitel 10 und 12 angef hrten Validierungs und Verifikationsmetriken mit mengentheoretischen bzw pr dikatenlogischen Ausdr cken sowie OCL Ausdr cken Wir beziehen uns in diesen Aus dr cken auf die SCORES Modellierungsprimitive und verweisen diesbez glich auf das parti elle Metamodell in Abb 7 2 Die OCL erm glicht es Anfragen an ein Modellierungselement zu richten F r die Elemente des Klassenmodells legen wir zus tzlich die UML Semantikdefinitionen zugrunde vgl OMG97 Mengen von Modellierungselementen zur ckgebende OCL Anfragen identifi zieren wir dabei mit den entsprechenden R ckgabemengen Dementsprechend verkn pfen wir solche OCL Ausdr cke auch mit mengentheoretischen Operatoren Beispiel 7 1 F r einen Use Case Schritt ucs liefert der OCL Ausdruck ucs Bereich den Klas senbereich des Schritts also eine Menge mit Elementen vom UML Typ Class Im Kontext eines bestimmten Modells ergibt der Ausdruck J e ValidationClassifier alllnstances y ClassScope die Menge aller Klassen die im Bereich Metassoziation ClassScope zumindest eines Use Cases oder Use Case Schritts enthalten sind Der Ausdruck ValidationClassifier alllnstances size ergibt die Anzahl aller im M
383. tkonstellationen f r welches wir in Abschnitt 17 2 gezeigt haben dass es zur Klasse der NP harten Probleme geh rt Erste Schritte zur heuristischen Er zeugung von Objektkonstellationen sind gegangen worden Abschlie end haben wir die im Rahmen der Arbeit prototypisch implementierte Werkzeugunterst tzung skizziert Zusammenfassung und Ergebnisse 213 Das methodische Vorgehen bei der Anforderungsermittlung mit SCORES sowie bei den ent sprechenden qualit tssichernden T tigkeiten ist an die meisten Entwicklungsprozesse adap tierbar und deckt folgende Anforderungen ab Abb 21 3 Q Die Testfalldefinition erfolgt ausgehend von der Anforderungsermittlung Use Cases Test Szenarien und die Elemente des Klassenmodells der Anforderungsspezifikation werden daf r ber den Entwurf hinweg bis in den Quellcode der Anwendung nach verfolgt Die Qualit tssicherung erfolgt risikogesteuert ber die Profile der Use Cases indem die in besonders hoch gewichteten bzw riskanten Use Cases bzw Test Szenarien be n tigten Klassen mit entsprechend hoher Priorit t implementiert und getestet wer den Die in dieser Arbeit entwickelten Klassen Botschaftsdiagramme f r die Anforde rungsspezifikation KBD 4 bzw die Implementation KB fassen die systeminter ne Information aller Episoden bzw die in der Implementation m glichen internen Interaktionen geeignet zusammen und erm glicht den SCORES grey box Test Zus tzlich unterst tzt das KBD
384. trierten aufzusp ren so sehen wir uns verschiedensten Argumenten gegen bergestellt Nach Nuseibeh97 poin tieren wir aus dem Blickwinkel verschiedener Projektbeteiligter m gliche Erkl rungen Der Programmierer spricht von einem klaren Programmierfehler Im Falle der Ariane 5 wurde eine Ausnahme in der SRI Software aufgrund einer Konvertierung einer 64 bit Real Zahl in eine 16 bit Integer Zahl nicht behandelt Eine bessere Programmierpra xis h tte diesen Fehler klar verhindert Der Entwurfsspezialist spricht von einem klaren Entwurfsfehler Die Entwurfsspezifikation ber cksichtigte lediglich Hardware Fehler so dass der Software Fehler nicht behan delt und infolgedessen die SRI 2 Einheit stillgelegt wurden Ebenso erging es der mit der gleichen Software ausgestatteten Ersatz Einheit SRI 1 Ein besserer Systement wurf h tte diesen Fehler klar verhindert Der Anforderungsermittler spricht von einem klaren Fehler bei der Anforderungsermittlung Die Anforderungen der Ariane 5 weichen erheblich von denen des Vorg ngermodells ab W ren die ge nderten Anforderungen bis zur Implementation nachverfolgbar ge wesen so h tte man erkennen k nnen dass bei der Ariane 5 die Funktionalit t der SRI nach dem Start berfl ssig ist Eine verfolgbare Anforderungsspezifikation h tte die sen Fehler klar verhindert Der Tester spricht von einem klaren Fehler im Testprozess So gab es z B keinen closed loop Test der SRI Einheiten gegen die ge nde
385. udieren und zu pr zisieren oder die technische Machbarkeit zu berpr fen Die brigen Funktionalit ten werden wieder nur insoweit implementiert dass die An wendung lauff hig ist W hrend die Klassifizierung in horizontale und vertikale Prototypen den modellierten Be reich der Anwendung und den Realisierungsgrad als Beschreibungsmerkmale verwendet geht es bei der Klassifikation in explorative experimentelle und evolution re Prototypen da rum auf welche Weise der Prototyp entsteht zu welchem Zweck er erstellt wird und was sp ter mit ihm geschieht Q Exploratives Prototyping dient dazu die grunds tzlichen Probleme und die wichtigs ten Anforderungen anhand einer lauff higen Anwendung zu erkunden Analytiker und Entwickler verschaffen sich Einblick in die Dom ne und lernen die Terminologie der Benutzer und deren W nsche kennen Im Mittelpunkt stehen also die Kl rung von Anforderungen sowie die Ausarbeitung von L sungsvorschl gen Q Experimentelles Prototyping sucht nicht nach L sungsvorschl gen sondern unter sucht eine bereits gefundene L sung auf ihre Angemessenheit und technische Mach barkeit Ein solcher Prototyp kann z B dazu dienen Spezifikationen zu erg nzen bzw zu verfeinern oder den Weg zur Implementation vorzuzeichnen Dabei kann man sich auf Aspekte wie z B das Layout der Benutzungsoberfl che die Architektur die Effi zienz eines Algorithmus oder die Anbindung einer externen Anwendung konzentrie ren
386. uf Opera toren wie den oben genannten sind die Elemente des Dom nen Klassenmodells jedoch ber den Entwurf hin bis zur Implementation nachverfolgbar falls das Dom nen Klassenmodell berhaupt im Entwurf ber cksichtigt wird Dies ist bei den vorherrschenden Entwurfsmetho den der Fall Wir wissen also was bei der Ausf hrung einer Operation im Dom nen Klas senmodell in der Implementation ber hrt werden sollte wenn auch nicht unbedingt in welcher Reihenfolge Auf letzteren Aspekt gehen wir in den n chsten Kapiteln noch weiter ein Teil IV Test gegen die Anforderungsspezifikation In diesem Teil stellen wir den Test objektorientierter Anwen dungen gegen objektorientierte Anforderungsspezifikationen vor dessen spezielle Probleme und Ziele wir zum besseren berblick in Kapitel 14 repetieren Zur Absch pfung des Mehrwerts der SCORES Anforderungs ermittlung leiten wir in Kapitel 15 black box Testf lle zur Pr fung der Anwendung gegen die Kontextuelle Information und die Interaktionsinformation der Anforderungsspezifikation ab SCORES erm glicht es dar ber hinaus die black box Testf lle zu sogenannten SCORES grey box Testf llen zu erweitern welche die internern Interaktionen der Anwendung gegen die bei der Verifikation der Anforderungs spezifikation protokollierte sys teminterne Information pr fen Interne Interaktionen fassen wir daf r in sogenannten Klassen Botschaftsdiagrammen zusam men Kapitel 16
387. um Szenarioschritt tsc und es ES ein Episodenschritt Wir definieren den Sichtbarkeitsbereich von es mit Hilfe der folgenden Abbildung SK ES gt 2K wobei wir es SK f r SK es schreiben 1 es AK e es SK Klasse des ausf hrenden Objekts 2 x e Kl ye es AK allAttributes x lt y class lt es SK Klassen der Attribute 3 Ist es WO die es zugeordnete Operation mit es WO signature Ko Kn dann ist xe Kl3ye ko kill x lt y ces SK Klassen der Parameter 132 Verifikation 4 Ist ze e o es und die dem Folgeschritt ze zugeordnete Operation ge WO eine der Stan dardoperationen x query und x iterate und verbindet die Beziehung x die diese Ope ration definierende Klasse mit der Klasse y so ist x e KIx lt y ces SK 5 Ist sp e o es und gilt f r die Signatur der ze zugeordneten Operation s WO signature Ko Kn dann ist x e KIx lt k lt es SK Klasse des R ckabewerts der aufge rufenen Operation 6 Keine andere Klasse aus K geh rt zu es SK Q Zu beachten ist dass die Episode ber die von den Schritten ausgef hrten Operationen zwar Manipulationen auf Instanz bzw Objektebene beschreibt sich selber jedoch aus schlie lich auf Elemente des Klassenmodells bezieht Die bei der Ausf hrung der Opera tion in der Episode sichtbaren Objekte und Beziehungen werden also auf entsprechende Elemente im Klassenmodell zur ckgef hrt 11 4 Simulationsregeln Analog zu den Modell
388. und anhand des Ma kroschritt Konzepts eine statische Aufgabenhierarchie generiert Zus tzlich k nnen wir aus den textuellen Beschreibungen der Use Cases und Use Case Schritte auch jeweils auf einen Aktor zugeschnittene Dokumente generieren die von Benutzern aus den entsprechenden Gruppen bzw von Dom nenexperten mit schrittweisen Inspektionen gepr ft werden Q Personalverantwortliche und Dom nenexperten inspizieren die Aktor Spezifikatio nen gegen die Organisationssicht der entsprechenden Gesch ftsprozesse Inspektions kriterien sind z B die vollst ndige Abbildung des von der Anwendung betroffenen Teils der Organisationsstruktur die richtige Zuteilung von Aktoren zu Benutzergrup pen und die vollst ndige Zuteilung von Aufgaben zu Aktoren 110 Validierung Q Dom nenexperten pr fen die statische Aufgaben bzw Use Case Hierarchie gegen die funktionalen Aspekte des Gesch ftsprozesses wobei m gliche Inspektionskriteri en z B die vollst ndige Abbildung des Prozesses in den Aufgaben oder die Vollst n digkeit der Use Case Beschreibungen bezogen auf den Gesch ftsbereich sind Q Einzelne Benutzer pr fen sozusagen als Instanzen von Aktoren die Beschreibung der Use Cases und Use Case Schritte an denen die entsprechenden Aktoren beteiligt sind Inspektionskriterien sind z B die Granularit t der einzelnen Use Case Schritte die richtige Aufteilung in Kontext und Interaktionsschritte und die Vollst ndigkeit und Korrektheit
389. ung Use Case Schritte 63 LI die Schrittart SA e Kontext Interaktion Makro Oo Bei der Abgrenzung der einzelnen Teilaufgaben interessiert uns inwiefern eine Teilaufgabe Anwendungsunterst tzung erhalten soll Die beiden Schrittarten Kontextschritt und Interak tionsschritt geben hierauf eine grobe Antwort Q Ein Kontextschritt beschreibt eine Teil Aufgabe die alleine von den Aktoren des Schritts bearbeitet wird also einem nicht von der Anwendung zu unterst tzenden Teil des umgebenden Gesch ftsprozesses entspricht Q Ein Interaktionsschritt beschreibt eine Teil Aufgabe die interaktiv von den Aktoren des Schritts und der Anwendung bearbeitet wird Interaktionsschritte spiegeln also die von der betrachteten Anwendung zu unterst tzenden Teile des umgebenden Ge sch ftsprozesses wider Ob eine Teilaufgabe kontextuelle Information oder Interaktionsinformation s Abb 4 5 be inhaltet geht also unmittelbar aus der Art des Schritts hervor denn Kontextschritte und In teraktionsschritte decken gerade die entsprechende Informationsart ab In Kapitel 7 zeigen wir dass Interaktionsschritte Ankn pfungspunkte f r die grobgranulare Modellierung der dritten systeminternen Information bieten Diese wird dann mit sogenannten Episoden die wir im Rahmen der Verifikation der Use Case Graphen und des Klassenmodells verwenden angereichert und verfeinert s Kapitel 11 Makroschritte Schrittart SA Makro erm glichen eine redunda
390. ung In diesem Teil stellen wir die Konzepte von SCORES vor Syste matic Coupling of Requirements Specifications unserer quali t tszentrierten Methode zur Anforderungsermittlung SCORES pr zisiert und verfeinert das Use Case Konzept und erm glicht die direkte Kopplung mit dem Klassenmodell In den Kapiteln 5 und 6 f hren wir die Konzepte und die Seman tik von Use Case Schrittgraphen ein Als zentrales Modellie rungskonzept von SCORES verschmelzen Use Case Schrittgraphen funktionale und ablaufbezogene Aspekte der An forderungen Szenarien f gen sich nahtlos in die resultierende kombinierte Sicht ein die dann in Kapitel 7 mit den strukturellen Aspekten der Anforderungen dem Klassenmodell gekop pelt wird In Kapitel 8 geben wir methodische Hinweise zum Vorgehen bei der Anforderungsermittlung mit SCORES Kapitel 5 Grundlegende Konzepte Wir stellen zu Beginn dieses Kapitels die Ziele zusammen die wir mit der in diesem Teil be schriebenen Pr zisierung und Verfeinerung des Use Case Konzepts erreichen wollen Zu n chst einmal formulieren wir einige Ziele bez glich der Ausdrucksst rke m Use Cases werden haupts chlich statisch funktional beschrieben Damit konkrete Szenarien hinl nglich spezifizierbar sind m ssen die Erweiterungen ablaufbezogene Kontrollflussaspekte abdecken vgl PTA94 RAB96 Zur Redundanzvermeidung wird eine hierarchische Strukturierung der Use Cases ge fordert vgl Cockburn
391. urchspielt und dabei die Werte von Variablen etc tabellarisch nachh lt oder das Pr fen von Dokumenten anhand pers nlicher Check und Fehlerlisten Mit gutem Erfolg k nnen die Mitarbeiter einer Projektgruppe ihre Produkte auch in gegenseitigen per s nlichen Reviews pr fen Q Als Walk Through wird eine Zusammenkunft mehrerer Personen mit meistens unter schiedlichen Aufgaben und Kenntnissen bezeichnet Der Entwickler stellt das Produkt vor und erkl rt es anhand einiger durchzuspielender Szenarien wof r einige nicht zu 1 Wir benutzen Review als Oberbegriff f r statische manuelle Pr fungen vgl PagSix94 Riedemann97 die anglo amerikanische Literatur verwendet hierf r eher den Begriff Inspektion vgl WBM96 108 Validierung komplizierte Testf lle vorbereitet werden Ziel ist die Diskussion der Entwurfsent scheidungen und die Vermittlung von Entwurfswissen zum tieferen Verst ndnis des Produkts Die Testf lle selbst spielen dabei keine kritische Rolle sie dienen eher dazu den Entwickler gezielt zu Entscheidungen z B zur Ablauflogik zu befragen In den meisten F llen werden mehr Defekte in der Diskussion mit dem Entwickler als durch die Testf lle selbst entdeckt Q Eine Inspektion ist eine von mehreren Personen nach reglementierten Schritten durch gef hrte dokumentierte Pr fung eines Produkts gegen eine begrenzte Menge von Kri terien s Fagan76 Das Inspektionsteam besteht gew hnlich aus vier
392. us nahme des Endschritts genau einen Folgeschritt zuordnet a Bei einem Makroschritt stehen wir vor der Wahl die Test Szenarien auf den referenzierten Use Case Schrittgraphen auszudehnen oder den Schritt im Kontext eines Test Szenarios als atomare Aufgabe zu betrachten Um die bersichtlichkeit und Machbarkeit des Ansatzes Scores Metamodell III 113 zu wahren bevorzugen wir die zweite M glichkeit und validieren einen Makroschritt ber seine Vor und Nachbedingung sowie die des referenzierten Use Case als Ganzes Nat rlich muss jedes Test Szenario auch tats chlich ein Szenario zu dem Use Case sein also einem Pfad durch den Use Case Schrittgraphen entsprechen welcher mit dem Startschritt be ginnt und in einem Endschritt endet Wir formulieren sogleich drei dementsprechende Vali dierungs Regeln Regel 9 3 1 Test Szenario Startschritt Der Startschritt sq eines Test Szenarios ts zum Use Case Schrittgraph uc muss dem Startschritt des Use Case Schrittgraphen zugeordnet sein ucs sg tS Sy UC Regel 9 3 2 Test Szenario Folgeschritt Die Folgeschrittfunktion eines Test Szenarios ts zum Use Case Schrittgraph uc muss vertr glich zur Folgeschrittfunktion des Use Case Schrittgraphen sein V ste ST ts s ucs O st O ucs st Regel 9 3 3 Test Szenario Endschritt Der Endschritt s eines Test Szenarios ts zum Use Case Schrittgraph uc muss einem Endschritt des Use Case Schrittgraphen zugeordnet sein ucs s
393. ut for structured design Instead of a system of interacting objects the analysis model specifies a matrix over data entities and global functions There is no modularisation Other concepts such as spe cialisation and aggregation are used for the object model but not for the scenario model Behringer97 W hrend Behringer diese Problematik mit einem Ein Modell Ansatz angeht welcher das globale Verhalten der Anwendung mit um Kontrollflusskonstrukte angereicherten Inter aktionsdiagrammen beschreibt spezifizieren wir in SCORES die Anforderungen mit mehreren Modellen Ma geblich f r diese Entscheidung sind die angestrebte Ausgewogenheit und Objektorientierung der Anforderungsspezifikation da rein verhaltensorientierte Modelle erfahrungsgem zu einer funktionalen Zerlegung und damit oft zu instabilen Strukturen f h ren vgl PagSix94 Auch Firesmith schreibt in Bezug auf rein funktionale z B nur auf Use Cases basierende Modellierungsans tze A major functional abstraction can cause the numerous problems with functional decomposition that object technology was to avoid Any decomposition based on use cases scatters the fea tures of the objects and classes among the individual use cases This scattering of objects to use cases leads to the Humpty Dumpty effect in which it is unlikely to put the objects and class es back together without a massive expenditure of time and effort Firesmith98 In SCORES s
394. wurf und Implementation eines Rahmenwerks f r persi stente Objekte Diplomarbeit Praktische Informatik II FernUniversit t Hagen erscheint vor 2000 RKW95 Bj rn Regnell Kristofer Kimbler Anders Wessl n Improving the Use Case Driven Approach to Requirements Engineering Proc 2 TEEE Int Symposium on Requirements Engineering York UK 1995 S 40 47 Rogotzki97 Jens Rogotzki Erzeugung von Anwendungsdaten aus GeoOOA Modellen Diplomarbeit Praktische Informatik III FernUniversit t Hagen 1997 RolAch98 Colette Rolland Camille Ben Achour Guiding the Construction of Textual Use Case Specifications Data amp Knowledge Engineering Jahrg 25 Nr 1 2 Marz 1998 S 125 160 Rosson99 M B Rosson Integrating Development of Task and Object Models Communica tions of the ACM Jahrg 42 Nr 1 Jan 1999 S 49 56 231 Roy90 R Roy A Primer on the Taguchi Method Van Nostrand Reinhold New York 1990 Rose98 Rational Rose 98 Rational Software Corporation Cupertino CA 1998 Rumbaugh94 James Rumbaugh Getting started using use cases to capture requirements Journal of Object Oriented Programming Jahrg 8 Nr 5 Sep 1994 S 8 12 23 Rumpe96 Bernhard Rumpe Formale Methodik des Entwurfs verteilter objektorientierter Systeme Herbert Utz Verlag Wissenschaft zug Dissertation Technische Univer sit t M nchen 1996 R ppel96 Peter R ppel Ein generisches Testwerkzeug f r den objektorientierten Software test Dissertati
395. wurfs auch Elemente der Anforderungsspezifikation ge ndert nderungen die aufgrund Elemente der SCORES Anforderungsspezifikation 153 von ge nderten Anforderungen bzw nderungen in der Realit t notwendig sind nehmen wir direkt in der Anforderungsspezifikation vor ber cksichtigen sie in den SCORES Elementen und reichen sie in den Entwurf durch Ist eine technische Klasse ohne Entsprechung in der Realit t bzw in der Anforderungsspezifikation von der nderung betroffen so sind zu n chst keine nderungen an den SCORES Elementen notwendig wir erinnern daran dass SCORES nur der Anforderungsermittlung angemessene Elemente enth lt Oft f hren aller dings nachtr glich noch die nderungen von Beziehungen und Operationen Erweiterungen Umleiten Aufrufe von Wurzel Operationen aus der Benutzungsschnittstelle zu ent sprechenden nderungen des in den Entwurf bernommenen Dom nen Klassenmodells Kurz gesagt sind von der nderung von Vererbungsbeziehungen und Wurzel Operationen die Klassenbereiche der Use Cases und Use Case Schritte sowie Episoden betroffen nde rungen von anderen Beziehungen oder Attributen betreffen nur die Episoden wobei wir in diesem Zusammenhang auch an die Standard Operationen f r Zugriffe auf Beziehungen und Attribute erinnern s Abschnitt 11 3 Im Prinzip lassen sich nderungen am Klassenmodell auf wenige verfeinernde verfolgbare Operatoren zur ckf hren vgl JCJ
396. x ganz rechts die auf dem ausgew hlten Element ausf hrbaren Operationen in kl der Standardoperationen angezeigt und k nnen dann zur Fortsetzung der Episode ausgew hlt werden Im Fenster links wird die Spezifikation der selektierten Operation angezeigt Signatur und Beschreibung und kann durch anklicken vom Analytiker F Message sequence Online Anmeldung Perform ZentralrechnerSchnittstelle pruefePIN Actual Scope Services A IN Objects PIN BR Integer A dasKonto B Konto Description Transaktion Zentralrechner Schnittstelle pruefePIN D Karte manipulate cope Zentralrechnerschnittstelle Konto A theAccounts Accounts meineTransaktion Beziehung 32 gibKonto B ZentralrechnerSc pruefePIN B Zentralrechners SI TH OUT Objects ReturnValue 8 Boolez Boolean LA f E E KR l Il T Al Ai K NI al x lt Abb 20 8 SCORESTOOL Episoden Editor Test 205 bzw Tester best tigt werden Die Darstellung der Episode orientiert sich an der Me tapher Aufrufbaum optional kann das UML Sequenzdiagramm verwendet werden Verifikationsmetriken hnlich wie bei den Validierungsmetriken k nnen auch die erreich ten Werte der Verifikationsmetriken direkt im Szenario Browser berechnet und ange zeigt werden Dar ber hinaus k nnen Analytiker und Tester einzelnen Spezifikationselementen einen Qualit tssicherungs Status QS
397. ystem und Abnahme Test gegen die Anforderungsspezifikation Abb 1 2 auf Seite 10 zeigt dies angelehnt an ein V Modell der Softwareentwicklung vgl PagSix94 So sollte im Idealfall z B die Qualit tssicherung der Anforderungsspezifikation zu Testf llen f r die Softwarespezifikation und den System und Abnahme Test f hren Abb 2 9 zeigt die verschiedenen Testt tigkeiten und ihren logischen Zusammenhang Testplanung Anforderungs Quellcode der en i Ae Anwendung lt gt Testfallermittlung gt Instrumentie rung H Testdaten generierung Sollwert A Testausf hrung Testdokumentation Testauswertung Testorganisation und Datenhaltung Abb 2 9 Testt tigkeiten nach Grimm95 Administrative T tigkeiten sind z B die Auslieferung das Konfigurationsmanagement das Projektmanagement und das Umgebungsmanagement Dem f r diese Arbeit wichtigen Kon zept der Nach Verfolgbarkeit der Anforderungsspezifikation ber den Entwurf in die Im plementation als Teilaspekt des Konfigurationsmanagements wenden wir uns am Ende von Teil III zu Einige Hinweise bzw Verfahren f r das Projekt bzw Testmanagement und spe ziell f r den Testumgebungsaufbau finden sich in den Teilen II Kapitel 8 II und IV 1 Oft wird ein Block zu einer Schnittstelle f r eine Menge von die Analyseklasse imple mentierenden Entwurfs bzw Implementationsklassen Hierf r gibt es
398. z aller Klassen in zumindest einem Klas senbereich eines Use Case Schritts enthalten ist Zuvor ermitteln wir wieder welche Klassen in den Klassenbereichen der Schritte eines Use Cases enthalten sind uc ClassScope J s classScope 7 3 se uc Steps Die vollst ndige Klassen berdeckung ergibt sich dann zu MK u ie e UseCase alllnstances uc ClassScope 1 Class alllnstances size 7 4 e KM K 3 d x 3 x Esist c 100 wenn jede Klasse in mindestens einem Klassenbereich eines Schritts der Use Case Schrittgraphen vorkommt MON SEN KM O Als weitere Metrik messen wir mit der einfachen Operations berdeckung c 0 welcher Prozentsatz der Operationen im Klassenmodell Wurzeloperationen von Use Case Schritten sind In einem ersten Schritt ermitteln wir fiir einen Use Case die Wurzeloperationen seiner Schritte uc rootOperations J s rootOperation se uc Steps N InteractionStep alllnstances 7 5 94 Kopplung von Use Cases und Klassenmodell Hiermit k nnen wir die einfache Operations berdeckung angeben zu uc rootOperations ae KE e UseCase alllnstances i 7 6 0 Operation alllnstances size Mit diesen und hnlichen Metriken k nnen wir die Belastbarkeit der Br cke zwischen Use Cases bzw deren Schrittgraphen und dem Klassenmodell zeigen Der Eingangs geforderte bergang zwischen den Modellen bzw den Sichten der Anforderungen ist somit geschaffen Beispiel 7 2 Zur Verdeutlichung d
399. zeprzojsue NId Hidsert ups e3zex3Tpery useqebebutgeqiey STp IqT6 epuny req en Spunyyued TeUySTTEIIUSZ Seege rsp ny xsus erys Buntyezmy DEE TeyonrpssTsq prepreg sqepsnepTss Jrndustpsq rn Kaes 5 Abb 4 4 Interaktionsdiagramm zum Use Case Geld Abheben 46 Probleme der Anforderungsermittlung mit Use Cases 4 2 Offene Fragen und Kritik Nach der begeisterten Aufnahme des Use Case Konzepts in der Fachwelt traten in der Praxis einige M ngel zutage die Meyer veranlassen zu behaupten Except with a very experienced design team having built several successful systems of several thousand classes each in a pure OO language do not rely on use cases as a tool for object orient ed analysis and design Meyer97 Wir listen diese M ngel getrennt bez glich der Ausdrucksst rke und Anwendbarkeit von Use Cases ihrer Struktur und ihrer Anwendbarkeit im Test gegen die Anforderungsspezifikation auf Ausdrucksst rke und Anwendbarkeit Modelle f r Anforderungsspezifikationen sollten die in Abb 4 5 gezeigten drei Informati onsarten erfassen k nnen vgl PohHau97 Paech98 Q kontextuelle Information beschreibt das Umfeld der Anwendung also z B Teilberei che von Unternehmen und Ankn pfungspunkte an Gesch ftsprozesse bzw Work flows Q Interaktionsinformation beschreibt die Interak
400. zt sozusagen fest verdrahtet durch entsprechende Standard Operationen im Sichtbarkeitsbereich der benutzenden Klasse bzw Operation ist Ist einer der bei den Beziehungspartner eine Dom nenklasse so k nnen ggf weitere Aufrufe zugeord net werden In allen anderen F llen sind SCORES Elemente nicht betroffen Entfernen einer Assoziations Aggregations oder Kompositionsbeziehung Abb 13 4 Haben beide Beziehungspartner Entsprechungen im Dom nen Klassenmo dell so m ssen alle Episoden gepr ft werden welche auf die Beziehung bzw eine ihr zugeordnete Standard Operation zugreifen Ggf sind die Signaturen von Operationen zu erweitern um die entsprechende Klasse weiterhin im Sichtbarkeitsbereich zu hal ten Ist einer der beiden Beziehungspartner eine Dom nenklasse so k nnen ggf wei tere Aufrufe zugeordnet werden In allen anderen F llen sind SCORES Elemente nicht betroffen Zus tzlich betrachten wir noch feingranulare die Operationen und Attribute betreffende n derungen m Das Einf gen von Attributen und Operationen wird nur dann ber cksichtigt wenn die ge nderten Elemente Entsprechungen in der Realwelt bzw in der Anforderungsspe zifikation haben Hierbei f hrt eine neue Wurzeloperation auch zu neuen Test Szena rien ansonsten m ssen wir ggf Episoden erweitern Entfernen von Attributen und Operationen Attribute sind nur zu beachten wenn sie in den Spezifikationen explizit angesprochen werden Wird eine
401. zur Anforderungsspezifikation auch formale Techniken oder spezielle Modelle verwendet bieten sich generierte Wegwerf Prototypen selbstverst ndlich zur Er g nzung und Illustration der Reviews an 9 1 Reviewtechniken In diesem Abschnitt skizzieren wir einige bekannte Reviewtechniken wobei wir uns eng an PagSix94 sowie diverse Artikel in WBM96 anlehnen Reviews leiten sich aus der Have a close look Vorgehensweise ab mit der normalerweise jeder Autor seine Dokumente ber pr fen sollte Aus der freiwilligen unstrukturierten Betrachtung von Dokumenten bzw Ent wicklungsprodukten wird ein pr zise definierter Vorgang bei dem der zeitliche und inhaltliche Ablauf sowie die Anzahl und Qualifikationen der beteiligten Personen genau fest gelegt sind und der nicht auf die Pr fung textueller Dokumente beschr nkt bleibt Reviews sollen Defekte im Entwicklungsprodukt aufzeigen In Abh ngigkeit von der betei ligten Personengruppe den Defekten die das Review aufdecken soll ihrer Kritikalit t sowie der Kritikalit t des zu pr fenden Produkts werden verschiedene Review Techniken einge setzt Am weitesten verbreitet sind das pers nliche Review der Walk Through und die In spektion Q Pers nliche Reviews werden im Laufe der Entwicklung mit dem Ziel der Validierung und Verbesserung des Produkts durchgef hrt M glichkeiten hierzu sind die Ausf h rung von Hand bei welcher der Entwickler ein Programm st ck auf dem Papier d

Qualitätssicherung für objektorientierte Software

Contents

Download Pdf Manuals

Related Search

Related Contents

Qualit&auml;tssicherung f&uuml;r objektorientierte Software

Contents

Download Pdf Manuals

Related Search

Related Contents

Qualitätssicherung für objektorientierte Software