Modellbasierter Test mit der UML

Transkript

1 Modellbasierter Test mit der UML Hausarbeit zum Seminar Spezikationsbasierter Softwaretest am Institut für Informatik der Humboldt-Universität zu Berlin von Lars Westmeier Datum

2 1 Einleitung Die heutigen Software-Produkte werden immer gröÿer und komplexer. Ein hoher Anteil der Projekte kann Zeit- und Kostenvereinbarungen nicht einhalten. Je gröÿer die Projekte sind, einen desto gröÿeren prozentualen Anteil an der Gesamtzeit nimmt das Testen in Anspruch. Wünschenswert ist es, das Testen weitestgehend zu automatisieren, zum einen, damit Entwicklungszeit und Kosten verringert werden können, zum anderen, damit Fehler in den Testsuiten vermieden werden. Eine der wichtigsten Modellierungssprachen für Software ist heute die Unied Modeling Language (UML). Diese grasche Beschreibungssprache ist in vielen Unternehmen der Standard für den Softwareentwicklungsprozess. Ein Teil der Sprache beschreibt Zustandsdiagramme. Gerade diese sind für das sogenannte black-box-testen interessant, bei denen das System nur von auÿen betrachtet wird und überprüft werden soll, ob das System unter Test (SUT) den Spezikationen genügt. Es stellt sich nun die Frage, ob es Methoden gibt, die aus einer gegebenen Spezikation eines Systems in UML Testfälle bzw. ganze Testsuiten generieren können. Mit dieser Frage beschäftigt sich die vorliegende Arbeit. Im ersten Teil wird in wesentlichen Zügen die UML vorgestellt. Der zweite beschäftigt sich mit dem eigentlichen Thema der Testgenerierung. Es wird eine Methode vorgestellt, die mittels des Modelcheckers SMV und der Temporallogik CTL aus Zustandsdiagrammen gemäÿ vorher ausgewählter Überdeckungskriterien eine Testsuite erstellt. Die Arbeit schlieÿt im Fazit mit einer kurzen Zusammenfassung und Bewertung der vorgestellten Methode. Der Anhang ordnet die Methode noch in ein Klassikationsschema ein. 1

3 2 UML 2.1 Was ist die UML? Die Unied Modeling Language (UML) ist eine grasche Sprache zur Modellierung von Software und anderen Systemen. Für Begrie, die bei der Modellierung benötigt werden, sind Bezeichner deniert sowie die möglichen Beziehungen von Bezeichnern untereinander festgelegt. Die Bezeichner und Beziehungen werden grasch wiedergegeben. Sowohl die Modellierung von statischen Strukturen als auch die von dynamischen Aspekten von beliebigen Anwendungsgebieten werden durch die UML ermöglicht. Vorteile Einige wesentliche Vorzüge haben zur weiten Verbreitung der Sprache beigetragen. Neben der präzisen Semantik zählt mit Sicherheit auch die Verständlichkeit zu den Vorzügen. Unterschiedliche Diagramme erlauben es, das zu modellierende System dierenziert und aus verschiedenen Blickwinkeln zu betrachten. Teilaspekte des Systems können dabei bewusst betont oder vernachlässigt werden. Auch die breite Akzeptanz ist ein Pluspunkt: mittlerweile gehören über 800 Unternehmen der für die Spezikation verantwortlichen Object Management Group (OMG) an. UML ist plattform- und sprachunabhängig. Obwohl sie ihre Stärken in der Objektorientierung hat, kann man sie aber auch getrost für prozedurale Sprachen einsetzen. Geschichte Die Entwicklung der UML begann Anfang der Neunziger Jahre als Folge der Notwendigkeit einer vereinheitlichten Modellierungssprache. Zu diesem Zeitpunkt gab es mehrere verschiedenen Notationen mit unterschiedlichen Elementen, die inkompatibel zueinander waren. Grady Booch, der Entwickler der Booch-Methode, und Jim Rumbaugh, der die Object Modeling Technique (OMT) entworfen hatte, begannen die Arbeit an der sogenannten Unied Method. Ivar Jacobson steuerte 1996 das Object-Oriented Software Engineering hinzu. Fortan wurde die Bezeichnung Unied Modeling Language verwendet. Die drei gelten somit als die Urväter der UML. Vor etwa zwei Jahren wurde die immer weiter gewachsene Sprache generalüberholt, und sie machte den Entwicklungsprung zur derzeit aktuellen Version 2.0. Die OMG wacht über die Entwicklung und Spezikation. 2

4 Abbildung 1: Diagrammarten in UML Diagramme der UML 2 Die Diagramme der UML 2 können in grob in Struktur- und Verhaltensdiagramme unterteilt werden. Erstere Diagrammgruppe modelliert statische, zeitunabhängige Elemente. Letztere Gruppe ermöglicht das Modellieren dynamischer Aspekte und des Verhaltens eines Systems. Abbildung 1 zeigt eine Übersicht über alle Diagrammarten. Die für das modellbasierte Testen wichtigen Diagrammarten nden sich in der Gruppe der Verhaltensdiagramme. Insbesondere sind Aktivitäts- und Zustandsdiagramme bedeutende. Aktivitätsdiagramme werden verwendet, um das Verhalten einer Komponente zu beschreiben. Zustandsdiagramme modellieren mögliche Zustände, Übergänge, Ereignisse und Aktionen eines Systems. Sie bauen auf das Konzept der deterministischen, endlichen Automaten (DFA) auf. Formal werden DFAs durch folgendes 5-Tupel deniert: A = (Σ, S, s 0, δ, F ) 3

5 mit dem Eingabealphabet Σ, der Zustandsmenge S, dem Startzustand s 0, der Menge der akzeptierenden Zustände (Endzustände) F und der Übergangsfunktion δ : S Σ S. Diese einfache formale Denition wird von UML um die folgenden besonderen Merkmale erweitert: Hierarchie, die Möglichkeit zur Vererbung, Parallelität und die Historisierung. Eine vereinfachte Denition der UML-Zustandsdiagramme zeigt Abb. 2. Abbildung 2: Denition der UML-Zustandsdiagramme Die UML-Notation soll das einfache Zustandsdiagramm in Abb. 3 zeigen. Der Name des Diagramms steht abgesetzt vom Rest des Diagramms oben links. Zustände werden durch abgerundete Rechtecke dargestellt, Zustandübergänge durch Pfeile. Ein scharzer Kreis steht für den Startzustand, umrandete für Endzustände (hier nicht vorhanden). Parallelität wird durch die gestrichelte Linie ausgedrückt. 4

6 Abbildung 3: Notation eines UML-Zustandsdiagramms 5

7 3 Testgenerierung Um zu testen, ob ein bereits implementiertes System den Spezikationen entspricht, werden sogenannte Konformitätstests durchgeführt. Gerade für groÿe Systeme ist es aus Ezienzgründen sehr wünschenswert, geeignete Testfälle nicht manuell zu erzeugen, sondern nach Möglichkeit automatisch direkt aus der Spezikation. In der Literatur nden sich verschiedene Ansätze um aus einer UML-Spezikation automatisch eine Testsuite zu generieren. Zwei seien hier genannt: zum einen wird der Weg über input enabled transition systems (IOLTS) genommen, zum anderen wird Model-Checking verwendet. Auf das erstere soll im Rahmen der vorliegenden Hausarbeit nicht näher eingegangen werden, da es mir wichtig erscheint eine Methode ausführlich zu erläutern und eine zweite Methode den Rahmen dieser Arbeit sprengen würde. 3.1 Model-Checking Model-Checking ist eine Technik, die verwendet wird, um zu verizieren, dass ein System einer gegebenen Spezikation entspricht. Als Spezikationssprachen dienen temporale Logiken wie die linear temporal logic (LTL) oder die computation tree logic (CTL) bzw. Kripke-Strukturen. Die groÿe Herausforderung besteht vor allem darin, dass die Menge der Zustände riesig werden kann - man spricht hier von einer Zustandsexplosion. Im Artikel Automatic Test Generation from Statecharts Using Model Checking beschreiben Hong u. a. (2001) eine Methode, um automatisch Tests aus Zustandsdiagrammen zu erzeugen. Zwar verwenden sie als Semantik der Zustandsdiagramme die STATE- MATE-Semantik (vgl. Harel u. Naamad 1996), betonen aber auch ausdrücklich, dass sich ihr Ansatz ebenso für UML-Zustandsdiagramme eignet (vgl. Hong u. a. 2001, 1). Ihren Ansatz verdeutlicht Abbildung 4. Zuerst wird die Semantik eines Zustandsdiagramms formal durch eine Kripke-Struktur deniert, da die verwendete Logik CPL nur für diese deniert ist. Es werden Überdeckungskriterien festgelegt, die für das jeweilige Zustandsdiagramm angepasst werden. Das Zustandsdiagramm wird in ein SMV-Programm übersetzt. Beides, die Formeln für die Überdeckungskriterien und das Programm, dienen dem symbolischen Modelchecker SMV als Eingabe. SMV liefert als Ausgabe dann eine 6

8 entsprechende Testsuite. Abbildung 4: Übersicht: Testgenerierung Der Hauptwert des Artikels liegt in der formalen Denition der Zustandsdiagramme. Deswegen soll auch in der vorliegenden Arbeit hauptsächlich auf die formale Denition der Semantik eingegangen werden und nur kurz auf das Modelchecking. Als Beispiel dient den Autoren ein einfaches Zustandsdiagramm das einen Kaee-Automat (vgl. Abbildung 5) abbildet. Abbildung 5: Zustandsdiagramm eines Kaeeautomaten 7

9 3.1.1 STATEMATE-Zustandsdiagramme Die Zustandsdiagramme kann man durch folgendes Tupel beschreiben: Z = (Σ, Π, V, Θ, T ), mit Σ als Zustandsmenge, Π als Ereignismenge, V als Menge der Variablen und T der Übergänge. Θ ist eine Interpretation von V, d. h. jeder Variable wird ein Anfangswert zugewiesen. Im Beispiel (Abb. 5) wird die einzige Variable m mit 0 initialisiert (Θ(m) = 0). Eine Konguration (engl. conguration) ist die maximale Menge der Zustände, in denen sich das System gleichzeitig benden kann: C S ist eine Konguration, wenn (1.) der root-zustand in C ist, (2.) für jeden UND- Zustand s gilt, dass entweder sowohl s als auch alle Unterzustände in C oder alle nicht in C sind; (3.) wenn für jeden ODER-Zustand s gilt, dass entweder s und genau ein Unterzustand oder gar keiner in C ist. Im Beispiel des Kaeeautomaten kommt man demnach zu folgenden Kongurationen: {OFF}, {IDLE, EMPTY}, {IDLE, NOTEMPTY}, {BUSY, EMPTY}, {BUSY, NOTEMPTY}. Die Menge Π der Ereignisse wird in drei disjunkte Teilmengen unterteilt, die Ein-, Ausgabe- und lokale Ereignisse umfassen: Π I, Π L und Π O. Lokale Ereignisse sind für die Umwelt unsichtbar und werden für die interne Kommunikation verwendet. Eingabe- Ereignisse werden durch die Umwelt ausgelöst, während für lokale und Ausgabe-Ereignisse das System verantwortlich ist. Ein- und Ausgabe-Ereignisse sind durch die Umwelt beobachtbar und werden demnach als observable bezeichnet. Der Beispielautomat weist die folgenden Mengen auf: Π I = {power on, power off, coffee, done, inc}, Π O = {light on, light off, start, stop} und Π L = {dec}. Ein Zustandsübergang t T wird durch ein 5-Tupel bestimmt: (source(t), trigger(t), guard(t), action(t), target(t)). Für jede Transition t wird Enter(t) (bzw. Exit(t) als die Zustandsmenge deniert, die betreten (bzw. verlassen) wird wenn es zu diesem Übergang kommt. Im Beispiel wäre Enter(t 1 ) = ON, COF F EE, IDLE, MONEY, EMP T Y. 8

10 3.1.2 Eine formale Denition der STATEMATE-Semantik Da die Temporallogik CTL für das Modelchecking nur in Bezug auf Kripke-Strukturen und nicht in Bezug auf Zustandsdiagramme deniert sind, formalisieren Hong u. a. (2001) zuerst die Semantik des Zustandsdiagramms als Kripke-Struktur. Eine Kripke-Struktur deniert sich durch folgendes Tupel: K = (Q, Q 0, L, R), mit der Zustandmenge Q, der Startkonguration Q 0, der Labelmenge L und der Zustandsübergangsmenge R. Zur Unterscheidung von den Zustandsdiagrammen werden die Zustände in Q von K als globale Zustände und die Übergange in R als globale Übergänge bezeichnet. Der Hauptbegri der STATEMATE-Semantik ist ein Schritt (engl. step), der das Verhalten des Systems auf ein Ereignis hin repräsentiert. Die STATEMATE-Semantik kennt zwei unterschiedliche Zeit-Modelle asynchrone und synchrone Zeit (hierfür wird die Menge der natürlichen Zahlen verwendet). Das synchrone Zeit-Modell sei hier vernachlässigt. Im asynchronen Modell können mehrere Schritte zu einem Zeitpunkt stattnden und die Zeit wird erst inkrementiert, wenn das sich das System wieder in einem stabilen Zustand bendet, d. h. dass für weitere Schritte neue Eingabe-Ereignisse notwendig sind. Der Zustandsraum Der Zustandsraum des Zustandsdiagramms Z soll durch Q = Config Σ(V ) 2 Π 2 T IT dargestellt werden. Conf ig ist dabei die Menge aller Kongurationen von Z, Σ die Menge aller Interpretationen von V und IT die Menge aller impliziten Übergänge. Zusammengefasst wird durch Q nun festgehalten in welchem Zustand sich Z bendet, welchen Wert die Variablen haben, welche Ereignisse generiert werden und welche Übergänge es gibt. Die Menge Q 0 der globalen Anfangszustände wird folgendermaÿen deniert: Es gilt (C 0, σ 0, E 0, τ 0 ) Q 0, wenn C 0 eine Anfangskonguration ist, σ 0 = Θ, E 0 = Π I und τ 0 =. 9

11 Es bleibt lediglich die Denition der Label der globalen Zustände. Die Autoren kommen zu folgender: L ((C, σ, E, τ)) = in (C) {v = σ(v) v V } E τ Die Menge in(c) wird dabei durch in(s) s C deniert. Zustandsübergänge Nachdem die Zustände und deren Labels formal deniert wurden, muss nun zuletzt noch die Übergangsrelation des Zustandsdiagramms durch die globalen Übergänge dargestellt werden. Dies erfordert jedoch vorher eine Denition der oben erwähnten stabilen Zustände. Ein globaler Zustand (C, σ, E, τ) ist stabil, wenn E (Π I Π L ) =, d. h. es keine Eingabe- oder lokalen Ereignisse gibt, und wenn es keinen Übergang gibt der in in diesem Zustand auftreten kann. Es werden zwei verschiedene Übergangsarten unterschieden: tick- und step-übergänge. Seien nun (C, σ, E, τ) und (C, σ, E, τ ) globale Zustände. ((C, σ, E, τ), (C, σ, E, τ )) ist ein step-übergang gdw. (1.) (C, σ, E, τ) nicht stabil ist; (2.) C = (C t τ Exits(t)) t τ Enters(t); (3.) E = t τ generated(t); (4.) σ = a(σ) mit a = t τ assignments(t); (5.1) (mayoccur) jeder Übergang t τ ist aktiv in (C, σ) und wird durch E ausgelöst; (5.2) keine zwei Übergänge in τ stehen in Konikt zueinander; (5.3) τ ist maximal. Vereinfacht kann man sagen, dass der step-übergang ((C, σ, E, τ), (C, σ, E, τ )) der Ausführung der Übergänge in τ entspricht. Hingegen ist ((C, σ, E, τ), (C, σ, E, τ )) ein tick-übergang gdw. (1.) (C, σ, E, τ) stabil ist; (2.) C = C; (3.) E Π I ; (4.) σ = σ; (5.) τ = ; 10

12 Dieser Übergang entspricht vereinfacht dem Einleiten von Eingabe-Ereignissen Überdeckungskriterien Im vorigen Abschnitt wurde die STATEMATE-Semantik mittels Kripke-Strukturen formal deniert. Dies war notwendig weil die CTL Kripke-Strukturen benötigt. Um konkrete CTL-Formeln zu erstellen, benötigt man neben der Kripke-Struktur auch gewisse Überdeckungskriterien. Normalerweise erlaubt ein Zustandsdiagramm unendlich viele Ausführungen. Ein umfassendes Testen, das alle möglichen Ausführungen abdeckt, ist deswegen im Allgemeinen nicht möglich. In der Praxis beschränkt man sich daher auf wichtige Testfälle, die anhand von Überdeckungskriterien ausgewählt werden. Hong u. a. (2001) schlagen nun zwei verschiedene Gruppen von Überdeckungskriterien vor. Die eine Gruppe orientiert sich am Kontrolluss, die andere am Datenuss. Kontrolluss-orientierte Überdeckungskriterien Zu dieser Gruppe gehören drei verschiedene Kriterien. Bei der Zustandsüberdeckung muss jeder Zustand von einem Test der Testsuite abgedeckt werden. Die stärkere Kongurationsüberdeckung verlangt analog, dass jede Konguration von einem Test in der Testsuite abgedeckt wird. Eine Testsuite genügt der Transitionsüberdeckung, wenn jede Transition von einem der Tests abgedeckt wird. Somit kommt man zu den folgenden CTL-Formeln: { EF (in(s) EF exit) s BS} bzw. { EF (in(c) EF exit) c Config} bwz. { EF (t EF exit) t T )}. Datenuss-orientierte Überdeckungskriterien Die beiden Kriterien in dieser Gruppe konzentrieren sich auf die Verwendung der Variablen. Das all-def -Kriterium umfasst alle Transitionen, in denen Variablen deniert werden. Das all-use-kriterium verlangt die Überdeckung aller Transitionen, in denen Variablen für eine Berechnung oder einen Vergleich verwendet werden. Mit diesen Kriterien kommt man zu folgenden CTL-Formeln: { EF (t EXE[ d(v)u(u(v) EF exit)]) v V, t def(v)} bzw. { EF (t EXE[ d(v)u(t EF exit)]) v V, t def(v), t use(v)}. 11

13 3.1.4 SMV-Programme Nachdem nun Überdeckungskriterien und entsprechende CTL-Formeln kurz vorgestellt wurden, steht als nächster Schritt im Ansatz von Hong u. a. (2001) an, das Zustandsdiagramm in ein SMV-Programm zu übersetzen. Zustände Jeder globale Zustand (C, σ, E, τ) wird durch Boolesche Variablen ausgedrückt: für jeden ODER-Zustand s, V ARs : children(s); INIT s = default(s), für jede Variable v, V ARv : range(v); INIT v = Θ(v), für jedes Eingabe-Ereignis e, V ARe : boolean; INIT 1, für jedes lokale oder Ausgabe-Ereignis e, V ARe : boolean; INIT 0, für jeden expliziten Übergang t, V ARt : boolean; INIT t = 0, für jeden impliziten Übergang it, V ARit : boolean; INIT it = 0. Übergänge Es wurden bereits zwei verschiedene globale Zustandübergänge deniert: tick- und step-übergänge. Ihre Übersetzung in ein SMV-Programm geschieht wie folgt: Step := StepExplicit StepImplicit StepConf ig StepV ariable StepEvent T ick := t T (t = 0) it IT (it = 0) s OS(s = s) v V (v = v) T ickevent Die Übergangsrelation T rans des SMV-Programms wird wie folgt deniert: T rans := [ Stable Step] [Stable T ick] Stable := e Π I Π L (e = 0) t T mayoccur(t) Für einen Beweis der Korrektheit der Übersetzung sei auf (Hong u. a. 2001, 14f) verwiesen. 12

14 3.1.5 Generierung der Testsuites Aus dem SMV-Programm 1 und den Überdeckungskriterien bzw. den konkreten CTL- Formeln kann der Modelchecker nun Testsuites erzeugen. Jede der erzeugten Formeln beschreibt einen Test so, dass die Formel nur genau dann wahr werden kann, wenn die Spezikation des Zustandsdiagramms diesen Test nicht erfüllt. Kann der Test ausgeführt werden, schlägt das Modelchecking fehl und SMV gibt ein Gegenbeispiel aus, das zeigt, warum die Formel nicht erfüllt werden konnte. Dieses Gegenbeispiel wird auf beobachtbare Ereignisse abgebildet und dann in die Testsuite aufgenommen. Eine Testsuite für das Kriterium der Zustandsüberdeckung zeigt Tabelle 1. Zustand {OFF} {IDLE, EMPTY} {IDLE, NOTEMPTY} {BUSY, EMPTY} {BUSY, NOTEMPTY} Ergebnis / {power-on}/{light-on} {power-on},{inc},{inc} / {light-on},, {power-on},{inc},{coee}/ {light-on},,{start} {power-on},{inc},{coee}/ {light-on},,{start} Tabelle 1: Kongurationsüberdeckung 1 Ein vollständiges Programm für das Beispiel des Kaeeautomaten ndet sich bei Hong u. a. (2001) im Anhang A. 13

15 4 Fazit Nach einer kurzen Einführung in die sehr weitverbreitete Modellierungssprache UML wurde in der vorliegenden Arbeit eine Methode vorgestellt, wie man aus einer Zustandsdiagrammspezikation Testfälle generieren kann. Die behandelte Methode verwendet zwar die STATEMATE-Semantik, die einzelnen Schritte und auch die gesamte Methode sind aber auch ohne weiteres auf UML-Diagramme anwendbar. Zuerst wurde die Semantik formal durch Kripke-Strukturen formal deniert, worin auch die Hauptleistung der Arbeit von Hong u. a. (2001) besteht. Da nicht alle Ausführungen des Systems getestet werden können beschränkt man sich auf Tests, die einfacheren Überdeckungskriterien genügen. Die entsprechenden Überdeckungskriterien werden in computation tree logic- Formeln abgebildet. Das Zustandsdiagramm wird in ein Programm für den symbolischen Modellchecker SMV übersetzt. Aus den CTL-Formeln und dem Programm generiert der Modelchecker dann Testfälle, die zu einer Testsuite zusammengefasst werden. Doch der hier gezeigte Ansatz berücksichtigt noch nicht den vollen Umfang der Möglichkeiten von Zustandsdiagrammen. Behandelt wurden etwa keine Aktionen, die zu Zuständen gehören, und auch keine Zustände mit mehreren Quell- und Zielzuständen. Weiterhin fehlen Historisierung als auch Echtzeit-Ereignisse. Es mag sein, dass der Ansatz auf diese Eigenschaften erweiterbar ist dies ist aber noch zu zeigen. Ein bekanntes Problem bei der Testgenerierung ist die Zustandsexplosion. Die Autoren räumen ein, dass auch bei ihrem Ansatz dieses Problem auftritt, meinen aber, es kontrollieren zu können. Auf welche Weise genau dies geschehen soll, wird nicht wirklich klar. Alles in allem scheint der vorgestellte Ansatz vielversprechender Ansatz, auch wenn noch einige weiter Forschungsarbeit notwendig ist. 14

16 Literatur Booch u. a Booch ; Rumbaugh ; Jacobson: Das UML-Benutzerhandbuch. Addison-Wesley, 2006 Gnesi u. a Gnesi ; Latella ; Massink: Formal Test-case Generation for UML-Statecharts. In: 9th IEEE International Conference on Engineering of Complex Computer Systems (ICECSS'04), IEEE, 2004, S Harel u. Naamad 1996 Harel, David ; Naamad, Amnon: The STATEMATE semantics of statecharts. In: ACM Transactions on Software Engineering and Methodology 5 (1996), Nr. 4, S Hong u. a Hong, H. ; Lee, I. ; Sokolsky, O. ; Cha, S.: Automatic Test Generation from Statecharts Using Model Checking. ftp://ftp.cis.upenn.edu/pub/rtg/paper/ Full_Postscript/MS-CIS pdf. Version: 2001, Abruf: 4. September 2006 Weilkiens 2005 Weilkiens: UML 2 Zertizierung. Intermediate-Stufe. Dpunkt Verlag,

17 Anhang: Klassikationschema 16