Digitale Hardware/ Software-Systeme- P20 doc

374 7 Software-Verifikation Wird nun die Instruktion 1 aus Programm 1 und die Instruktion 3 aus Programm 2 symbolisch simuliert, erh ¨ alt man: E 1 := {b 0,1 ,b 0,2 ,tmp1 0,2 } E 2 := {c 0,1 ,c 0,2 ,tmp2 0,2 } E 3 := {a 0,1 ,b 0,1 + c 0,1 } E 4 := {a 0,2 ,tmp1 0,2 +tmp2 0,2 } Mit den ¨ Aquivalenzklassen E 1 und E 2 kann die ¨ Aquivalenz von E 3 und E 4 gezeigt werden. Aus diesem Grund werden ¨ Aquivalenzklassen E 3 und E 4 vereinigt: E 3  := {a 0,1 ,a 0,2 ,b 0,1 + c 0,1 ,tmp1 0,2 +tmp2 0,2 } Da dadurch a 0,1 und a 0,2 in der selben ¨ Aquivalenzklasse sind, sind die beiden Pro- gramme in der Tat ¨ aquivalent. ¨ Aquivalenzpr ¨ ufung mittels Programmabh ¨ angigkeitsgraphen F ¨ ur große C-Programme st ¨ oßt die symbolische Simulation schnell an ihre Grenzen. Aus diesem Grund bietet es sich an, zun ¨ achst diejenigen Stellen in den Program- men zu identifizieren, bei denen es sich lohnt die ¨ Aquivalenz bzw. Nicht ¨ aquiva- lenz von Variablen zu zeigen. Hierzu wird in [315] ein Verfahren vorgestellt, bei dem zun ¨ achst Unterschiede in den Quelltexten der C-Programme identifiziert wer- den. Diese Quelltext-Unterschiede definieren die sog. Verifikationsbereiche.Nurf ¨ ur die Verifikationsbereiche wird versucht, deren ¨ Aquivalenz zu zeigen. Ist dies nicht m ¨ oglich, wird versucht, den Verifikationsbereich zu erweitern. Gelingt auch dieses nicht, sind die Programme nicht ¨ aquivalent. Wird hingegen f ¨ ur alle Verifikationsbe- reiche gezeigt, dass diese ¨ aquivalent sind, so sind die beiden C-Programme ¨ aquiva- lent. Der gesamte Ablauf ist in Abb. 7.4 zu sehen. Es kann aufgrund von Optimierungen vorkommen, dass die beiden zu verglei- chenden Programme an manchen Stellen keine zeilenweise Korrespondenz zeigen, was f ¨ ur die im Folgenden vorgestellte Bestimmung der Verifikationsbereiche aller- dings notwendig ist. Wird dies bei der Bestimmung der Quelltext-Unterschiede fest- gestellt, werden in den Programmen neutrale Erweiterungen vorgenommen, also Er- weiterungen, die keinen Einfluss auf das Ergebnis der Verifikation haben: Handelt es sich bei einem festgestellten Unterschied um eine Zuweisung an die Variable x,so kann in dem Programm, das diese Zuweisung nicht enth ¨ alt, die Anweisung x := x hinzugef ¨ ugt werden. Dies wird an einem Beispiel verdeutlicht. Beispiel 7.1.7. Gegeben sind die beiden Ausschnitte aus zwei Programmen: Programm 1 Programm 2 1 x=a+c; x=a; 2 y=b-c; y=b-c; 3 x=x; x=x+c; Hierbei wurde in Programm 1 die dritte Zeile hinzugef ¨ ugt, um eine zeilenweise Kor- respondenz zwischen den Programmen zu schaffen. 7.1 Formale ¨ Aquivalenzpr ¨ ufung eingebetteter Software 375 Programm 1 Programm 2 Nein ¨ aquivalent? Ja Ja erweiterbar? Bereich Ja Nein Nein nicht ¨ aquivalent Programme ¨ aquivalent Bereichs- erweiterung symbolische Simulation Bestimung Quell- text-Unterschiede Unterschiede? Verifikationsbe- reichsbestimmung Abb. 7.4. ¨ Aquivalenzpr ¨ ufung von C-Programmen basierend auf Quelltext-Unterschieden [315] Fehlen in einem Programm Kontrollanweisungen, so kann es um diese Anwei- sung erweitert werden. In jedem der beiden folgenden Ausf ¨ uhrungszweige werden dann zum anderen Programm korrespondierende Zuweisungen von Variablen an sich selbst vorgenommen. Basierend auf den so erweiterten Programmen, k ¨ onnen nun die Verifikationsbereiche bestimmt werden. F ¨ ur die Bestimmung der Verifikationsbereiche bietet sich eine spezielle Da- tenstruktur an, der sog. Programmabh ¨ angigkeitsgraph (engl. Program Dependence Graph, PDG) [226]. Definition 7.1.1 (Programmabh ¨ angigkeitsgraph (PDG)). Ein Programmabh ¨ angig- keitsgraph (PDG) ist ein gerichteter Graph G P (V,E), wobei die Knoten v ∈ V Zu- weisungen oder Pr ¨ adikate von konditionalen Spr ¨ ungen repr ¨ asentieren. Es existiert 376 7 Software-Verifikation ein ausgezeichneter Startknoten v 0 ∈ V . Die Menge der Kanten E = V ×V ist bipar- titioniert, d. h. E = E C ∪ E D mit E C ∩ E D = ∅. Die Kontrollflusskanten e ∈ E C stellen Kontrollabh ¨ angigkeiten dar und sind mit dem Wert F oder T beschriftet. Kontrollflusskanten e =(v i ,v j ) ∈ E C beginnen entwe- der bei einem Knoten v i , der ein Pr ¨ adikat repr ¨ asentiert, oder dem ausgezeichneten Startknoten v i = v 0 . Eine Kontrollflusskante, die mit T (F) beschriftet ist, stellt den Kontrollfluss f ¨ ur den Fall dar, dass das Pr ¨ adikat, das durch v i repr ¨ asentiert ist, erf ¨ ullt (nicht erf ¨ ullt) ist. Die Datenflusskanten e ∈ E D stellen Datenabh ¨ angigkeiten dar. Eine Datenflusskante e =(v i ,v j ) zwischen Knoten v i und v j existiert genau dann, wenn: • In der Zuweisung, die durch v i repr ¨ asentiert wird, die Variable x geschrieben wird, • in der Anweisung, die durch v j repr ¨ asentiert wird, die Variable x gelesen wird und • ein Ausf ¨ uhrungspfad von v i nach v j existiert, d. h. ein Pfad im Kontrollflussgraph des Programms existiert, auf dem x nicht ein weiteres Mal geschrieben wird. Ein PDG kann zu einem Systemabh ¨ angigkeitsgraph (engl. System Dependence Graph, SDG) erweitert werden, in dem Funktionen und Prozeduren ebenfalls als PDG dargestellt werden und Kontroll- und Datenflusskanten die PDGs der Funktio- nen und Prozeduren geeignet mit dem Programmabh ¨ angigkeitsgraph des Programms verkn ¨ upft [226]. Beispiel 7.1.8. Gegeben ist das folgende C-Programm mit Eingaben f ¨ ur die Varia- blen x und y [315]: 1 if(x>=y) 2 z=x-y; 3 else 4 z = y -x; 5 return z; Der zugeh ¨ orige Programmabh ¨ angigkeitsgraph ist in Abb. 7.5 zu sehen. Kontroll- flusskanten sind gestrichelt dargestellt. Die Eingaben f ¨ ur x bzw. y sind x in bzw. y in. Mit Hilfe der PDGs und den Quelltext-Unterschieden zweier C-Programme las- sen sich nun die Verifikationsbereiche definieren. Ein Verifikationsbereich umfasst den Graphen, der durch die Knoten der PDGs, bei denen Unterschiede aufgetreten sind, induziert wird. F ¨ ur solche Verifikationsbereiche k ¨ onnen nun Eingabe- und Aus- gabevariablen definiert werden: • Eingabevariablen eines Verifikationsbereichs sind durch die in den Verifikations- bereich eingehende Datenflusskanten repr ¨ asentiert. • Ausgabevariablen eines Verifikationsbereichs sind durch die aus dem Verifikati- onsbereich ausgehende Datenflusskanten repr ¨ asentiert. Lediglich f ¨ ur die Ausgabevariablen des Verifikationsbereichs, die in beiden Pro- grammen vorkommen, muss ¨ Aquivalenz gezeigt werden. Kann f ¨ ur alle Ausgabe- variablen deren ¨ Aquivalenz gezeigt werden, so sind auch die beiden Programmab- schnitte des Verifikationsbereichs ¨ aquivalent. Kann die ¨ Aquivalenz allerdings nicht 7.1 Formale ¨ Aquivalenzpr ¨ ufung eingebetteter Software 377 TT T T F T return z z := y-x y:=y inx:=xin z := x-y x>=y Start Abb. 7.5. Programmabh ¨ angigkeitsgraph [226] gezeigt werden, so muss der Verifikationsbereich erweitert werden. Hierbei gibt es prinzipiell drei M ¨ oglichkeiten: 1. R ¨ uckw ¨ artserweiterung: Bei der R ¨ uckw ¨ artserweiterung wird ein Vorg ¨ angerkno- ten im PDG, der ¨ uber eine eingehende Datenflusskante verbunden ist, zu dem Verifikationsbereich hinzugenommen. Wenn verschiedene Zuweisungen f ¨ ur den Vo r g ¨ angerknoten auf unterschiedlichen Kontrollflusspfaden existieren, so m ¨ us- sen alle Knoten, die diese Zuweisungen repr ¨ asentieren, inklusive des kontrollie- renden Knoten mit dem zugeh ¨ origen Pr ¨ adikat, dem Verifikationsbereich zuge- ordnet werden. 2. Vor w ¨ artserweiterung ¨ uber eine Datenabh ¨ angigkeit: Hierbei wird ein direkter Nachfolgerknoten, der ¨ uber eine ausgehende Datenflusskante verbunden ist, zu dem Verifikationsbereich hinzugenommen. 3. Vor w ¨ artserweiterung ¨ uber eine Kontrollflusskante: Hierbei werden alle direkten Nachfolgerknoten, die ¨ uber eine ausgehende Kontrollflusskante eines Knoten im Verifikationsbereich verbunden sind, zu dem Verifikationsbereich hinzugenom- men. Die Frage, welche Erweiterung am sinnvollsten ist, h ¨ angt stark von dem gege- benen Programm ab. Allerdings lassen sich Terminierungskriterien spezifizieren, die eine weitere Erweiterung des Verifikationsbereichs ¨ uberfl ¨ ussig machen: • Falls die ¨ Aquivalenz der neu zugef ¨ ugten Knoten bereits gezeigt wurde, so ist eine R ¨ uckw ¨ artserweiterung nicht mehr sinnvoll. • Falls die zugef ¨ ugten Knoten den Anfang oder das Ende des Programms beschrei- ben, ist eine Erweiterung ¨ uber diese Knoten hinaus nicht m ¨ oglich. Der erste Fall trifft auch f ¨ ur Eingabevariablen des Verifikationsbereichs zu. Zwei Eingabevariablen sind ¨ aquivalent, wenn diese nicht von anderen Verifikationsberei- 378 7 Software-Verifikation chen abh ¨ angen, f ¨ ur welche die ¨ Aquivalenz noch nicht gezeigt wurde, oder f ¨ ur die beiden Variablen wurde bereits ¨ Aquivalenz gezeigt. Die ¨ Aquivalenzpr ¨ ufung mittels Programmabh ¨ angigkeitsgraphen wird an einem Beispiel gezeigt [315]. Beispiel 7.1.9. Gegeben sind die beiden Programme: Programm 1 Programm 2 1 if (in1 > in2) { if (in1 > in2) { 2 a = in1 + in2; a = in1 + in2; 3 b = in1 * 3; b = in1 * 3; 4 c = in2 * 5; c = in2 * 5; 5 } else { } else { 6 a = in2 - in1; a = in2 - in1; 7 b = in1 * 5; b = in1 * 5; 8 c = in2 * 3; c = in2 * 3; 9} } 10 x=a+c; x=a; 11 y=b-c; y=b-c; 12 x=x; x=x+c; 13 out=x+y; out=x+y; 14 return out; return out; Die Eingabevariablen der beiden C-Programmen sind in1 und in2. Die Ausgabeva- riable in beiden Programmen heißt out. Man beachte, dass das Programm 1 in Zeile 12 um die Anweisung x=xerweitert wurde, um eine zeilenweise Korrespondenz zwischen den Programmen zu erreichen. Die beiden Programmabh ¨ angigkeitsgraphen sind in Abb. 7.6 zu sehen. Der erste Quelltext-Unterschied ist in Zeile 10 der beiden C-Programme. Entsprechend wird der Verifikationsbereich A in Abb. 7.6 als erstes betrachtet. Da f ¨ ur die Eingabevaria- blen des Verifikationsbereichs keine ¨ Aquivalenzen bekannt sind, kann auch nicht die ¨ Aquivalenz der Variablen x gezeigt werden. F T F T in1 in1 in2 c A B C c in2 in1 > in2 in1 > in2 a:=in1+in2 a:=in2-in1 x:=a+c x:=x x:=x+c x:=a a:=in1+in2 a:=in2-in1 Abb. 7.6. Programmabh ¨ angigkeitsgraphen und Verifikationsbereiche [315] 7.1 Formale ¨ Aquivalenzpr ¨ ufung eingebetteter Software 379 Die entsprechenden ¨ Aquivalenzklassen lauten: E 1 := {a 0,1 } E 2 := {a 0,2 ,x 0,2 } E 3 := {c 0,1 } E 4 := {x 0,1 ,a 0,1 + c 0,1 } Um den Verifikationsbereich zu erweitern, bietet sich ein R ¨ uckw ¨ artserweiterung f ¨ ur die Variable a an. Da a in einem konditionalen Kontrollpfad berechnet wird, muss auch die Zuweisung im alternativen Pfad sowie das Pr ¨ adikat selbst mit zur Erweite- rung geh ¨ oren. Somit ist der neue Verifikationsbereich der Bereich B. Die Eingabe- variablen f ¨ ur Verifikationsbereich B sind in1, in2 und c. Die Eingabevariable in1 bzw. in2 in Programm 1 ist ¨ aquivalent mit in1 bzw. in2 in Programm 2. Dennoch kann aufgrund der Unterschiede in der Zuweisung keine ¨ Aquivalenz der Programme f ¨ ur den Verifikationsbereich B gezeigt werden. Die entsprechenden ¨ Aquivalenzklas- sen lauten: E 1 := {in1 0,1 ,in1 0,2 } E 1 := {in2 0,1 ,in2 0,2 } E 1 := {a 0,1 ,a 0,2 ,x 0,2 } E 3 := {c 0,1 } E 4 := {x 0,1 ,a 0,1 + c 0,1 } Es folgt schließlich eine Vorw ¨ artserweiterung ¨ uber die Datenabh ¨ angigkeit von x. Der neue Verifikationsbereich ist der Bereich C in Abb. 7.6. In diesem Fall wird auch die Variable c in Programm 2 ber ¨ ucksichtigt. Außerdem ist bekannt, dass die Variable c in Programm 1 ¨ aquivalent zu Variable c in Programm 2 ist. Somit kann auch die ¨ Aquivalenz der Variable x in Programm 1 und Programm 2 gezeigt werden. Damit ist gleichzeitig auch gezeigt, dass die beiden Programme ¨ aquivalent sind. Die abschließenden ¨ Aquivalenzklassen lauten: E 1 := {in1 0,1 ,in1 0,2 } E 1 := {in2 0,1 ,in2 0,2 } E 1 := {a 0,1 ,a 0,2 } E 3 := {c 0,1 ,c 0,2 } E 4 := {x 1,1 ,x 1,2 ,a 0,1 + c 0,1 ,a 0,2 + c 0,2 } ¨ Aquivalenzpr ¨ ufung ohne Abrollen der Schleifen Die bis jetzt vorgestellten Verfahren zur ¨ Aquivalenzpr ¨ ufung f ¨ ur C-Programme setzen Einschr ¨ ankungen voraus, die sich teilweise lockern lassen. In [395] wird beispiels- weise eine ¨ Aquivalenzpr ¨ ufung vorgestellt, welches das Abrollen der Schleifen nicht verlangt. Gepr ¨ uft werden zwei Programme, die durch Transformationen auseinander 380 7 Software-Verifikation hervorgegangen sind. Dabei werden im Folgenden nur Transformationen betrachtet, die zum Ziel haben, die Speicherzugriffe zu minimieren. Im Wesentlichen lassen sich zwei Transformationen aus diesem Bereich unterscheiden: • Globale Schleifentransformationen werden verwendet, um for-Schleifen umzu- ordnen und neu zu strukturieren, wodurch sich die temporale und r ¨ aumliche Lo- kalit ¨ at der Daten verbessert. Hierdurch werden Zugriffe auf den Hauptspeicher minimiert. • Globale Datenflusstransformationen werden verwendet, um beispielsweise wie- derholte Berechnungen zu entfernen oder einen Flaschenhals, der durch die Be- rechnung von Datenabh ¨ angigkeiten hervorgerufen wird, aufzul ¨ osen. Die Transformationen basieren dabei auf dem Propagieren von Ausdr ¨ ucken (engl. expression propagation), was tempor ¨ are Variablen erzeugt oder eliminiert. Daneben wurden globale algebraische Transformationen eingesetzt, die auf algebraischen Ei- genschaften beruhen. Da diese Transformationen fehleranf ¨ allige ¨ Anderungen an den Berechnungen der Variablenindizes durchf ¨ uhren k ¨ onnen, ist hier eine Unterst ¨ utzung durch eine formale ¨ Aquivalenzpr ¨ ufung besonders hilfreich. Beispiel 7.1.10. Betrachtet wird das folgende C-Programm [396]: 1 Programm 1 2 void prog1(int a[], int b[], int c[]) { 3 int k, tmp1[256], tmp2[256], tmp3[256]; 4 5 for (k=0; k<256; k++) 6 s1: tmp1[k] = a[2*k] + f(B[k+1]); 7 for (k=10; k<138; k++) 8 s2: tmp2[k] = b[k-8]; 9 for (k=10; k<266; k++) { 10 if (k >= 138) 11 s3: tmp2[k] = b[k-8]; 12 s4: tmp3[k-10] = f(a[2*k - 19]) + tmp2[k]; 13 } 14 for (k=255; k>=0; k ) 15 s5: c[3*k] = tmp1[k] + tmp3[k]; 16 } Ferner ist das folgende C-Programm gegeben, welches durch Propagieren von Aus- dr ¨ ucken, Schleifen- und algebraischen Transformation aus Programm 1 erhalten wurde [396]: 1 Programm 2 2 void prog2(int a[], int b[], int c[]) { 3 int k, tmp4[256], tmp5[256]; 4 5 for (k=0; k<256; k++) { 6 t1: tmp4[k] = f(a[2*k+1]) + a[2*k]; 7 t2: tmp5[k] = b[k+2] + tmp4[k]; 7.1 Formale ¨ Aquivalenzpr ¨ ufung eingebetteter Software 381 8 t3: c[3*k] = f(b[k+1]) + tmp5[k]; 9} 10 } Vernachl ¨ assigt man potentielle Wertebereichs ¨ uberl ¨ aufe, berechnen die beiden Funk- tionen die selben Ausgaben f ¨ ur die selben Eingaben, d. h. sie sind Eingabe/Ausgabe- ¨ aquivalent. Es werden Programme mit den folgenden Eigenschaften betrachtet: • Dynamische Einmalzuweisung (engl. dynamic single assignment, DSA): Das Pro- gramm ist in dynamischer Einmalzuweisung geschrieben. Hierbei wird jede Va- riable lediglich einmal geschrieben. Im Gegensatz zur statischen Einmalzuwei- sung (engl. static single assignment, SSA) [125], welche lediglich auf dem Um- benennen einzelner Variablen basiert, wird bei DSA auch der dynamische Kon- trollfluss mit ber ¨ ucksichtigt, so dass auch in Schleifenr ¨ umpfen Variablen ledig- lich einmal geschrieben werden [158]. • St ¨ uckweise affine Ausdr ¨ ucke: Indizes f ¨ ur Arrays innerhalb von Schleifenr ¨ umpfen sind st ¨ uckweise affin. Auch sind die Operatoren mod, div, min, max, floor und ceil zugelassen. Hierdurch k ¨ onnen die Relationen zwischen Arrayvariablen als affine Ungleichungen beschrieben werden. • Statischer Kontrollfluss: Die Programme enthalten keine datenabh ¨ angigen Schlei- fen. Es wird angenommen, dass datenabh ¨ angige Schleifen durch Schleifen mit konstanten Grenzen und einer if-Anweisung im Schleifenrumpf zum daten- abh ¨ angigen Abbruch der Schleife ersetzt werden. • Zeiger und Rekursionen: Zeiger und Rekursionen sind in den Programmen nicht gestattet. ADDGs Array-Datenabh ¨ angigkeitsgraphen (engl. Array Data Dependency Graph, ADDG) werden im Folgenden verwendet, um die Datenabh ¨ angigkeiten in Programmen mit den obigen Eigenschaften zu erfassen. Skalare Variablen k ¨ onnen als einelementige Arrays angesehen werden. Der Index einer zu schreibenden Variablen in einer An- weisung sowie die Indizes der dabei gelesenen Variablen k ¨ onnen von Schleifenva- riablen abh ¨ angen. Diese Abh ¨ angigkeiten k ¨ onnen als Punkte i n einem ganzzahligen mehrdimensionalen Raum angesehen werden. Man erh ¨ alt somit eine geometrische Repr ¨ asentation. Zur Definition eines ADDG wird von der folgenden Anweisung s ausgegangen: s : v[ f i 1 ([k 1 , ,k d ])], ,[ f i n ([k 1 , ,k d ])] = exp( ,u[ f j 1 ([k 1 , ,k d ])], ,u[ f j m ([k 1 , ,k d ])], ); Die Anweisung s wird f ¨ ur verschiedene Iterationen berechnet, wobei diese durch Elemente in dem sog. Iterationsbereich D gegeben sind. Der Iterationsbereich D := {k =[k 1 , ,k d ]} definiert, f ¨ ur welche Belegungen von Schleifenvariablen k 1 , ,k d die Anweisung ausgef ¨ uhrt wird. Aus dem Iterationsbereich l ¨ asst sich der sog. Defi- nitionsbereich W v einer Arrayvariablen v definieren: 382 7 Software-Verifikation Definition 7.1.2 (Definitionsbereich). Der Definitionsbereich W v einer Variable v in der Anweisung s mit Iterationsbereich D ist die Menge der Belegungen der Indizes [i 1 , ,i n ],d.h. W v :=  [i 1 , ,i n ] |  n  r=1 i r = f i r ([k 1 , ,k d ])  ∧ [k 1 , ,k d ] ∈ D  Analog l ¨ asst sich der sog. Operandenbereich R u einer in Anweisung s verwendeten Variablen u definieren. Definition 7.1.3 (Operandenbereich). Der Operandenbereich R u einer Variablen u in der Anweisung s mit Iterationsbereich D ist die Menge der Belegungen der Indizes [ j 1 , , j m ],d.h. R u :=  [ j 1 , , j m ] |  n  r=1 j r = f j r ([k 1 , ,k d ])  ∧ [k 1 , ,k d ] ∈ D  Schließlich kann mit Hilfe der Iterations-, Definitions- und Operandenbereiche eine sog. Abh ¨ angigkeitsabbildung M v,u der Variablen v und u in Anweisung s definiert werden: Definition 7.1.4 (Abh ¨ angigkeitsabbildung). F ¨ ur eine Anweisung s l ¨ asst sich eine Abh ¨ angigkeitsabbildung M v,u ,welchedieAbh ¨ angigkeit der Variable v von der Va- riablen u beschreibt, wie folgt berechnen: M v,u :=  [i 1 , ,i n ] → [ j 1 , , j m ] |  n  r=1 i r = f i r ([k 1 , ,k d ])  ∧  n  r=1 j r = f j r ([k 1 , ,k d ])  ∧ [k 1 , ,k d ] ∈ D  Beispiel 7.1.11. F ¨ ur die Anweisung s4 in Programm Programm 1 aus dem Beispiel 7.1.10 ergibt sich der Iterationsbereich D zu: D = {[k] | 10 ≤ k < 266 ∧ k ∈ Z} Der Definitionsbereich f ¨ ur Variable tmp3 und die Operandenbereiche f ¨ ur die Varia- blen a und tmp2 ergeben sich zu: W tmp3 = {[d] | d = k − 10 ∧ k ∈ D} R a = {[d] | d = 2 · k − 19 ∧ k ∈ D} R tmp2 = {[d] | d = k ∧ k ∈ D} Hieraus ergeben sich die Abh ¨ angigkeitsabbildungen M tmp3,a und M tmp3,tmp2 zu: M tmp3,a = {[d 1 ] → [d 2 ] | d 1 = k −10 ∧ d 2 = 2 · k −19 ∧ k ∈ D} M tmp3,tmp2 = {[d 1 ] → [d 2 ] | d 1 = k −10 ∧ d 2 = k ∧k ∈ D} 7.1 Formale ¨ Aquivalenzpr ¨ ufung eingebetteter Software 383 Eine Datenabh ¨ angigkeit zwischen Anweisung s 1 und s 2 besteht, wenn s 1 Va- riablenwerte schreibt, die in Anweisung s 2 gelesen werden, d. h., wenn s 1 den De- finitionsbereich W v besitzt und Anweisung s 2 den Operandenbereich R v und gilt: W v ∩ R v = ∅. Die Menge an Datenabh ¨ angigkeiten kann als Array-Datenabh ¨ angig- keitsgraph (ADDG) repr ¨ asentiert werden. Definition 7.1.5 (ADDG). Ein ADDG ist ein gerichteter Graph G =(V,E), wobei die Knoten die Variablen und Operationen eines Programms repr ¨ asentieren. Die Kanten e ∈ E stellen Datenabh ¨ angigkeiten dar. Kanten mit Operationen als Quell- knoten werden mit der Position des jeweiligen Operanden (Senke) und Kanten mit Variablen als Quellknoten werden mit der jeweiliger Anweisung im Programm be- schriftet. W ¨ ahrend Datenabh ¨ angigkeitsgraphen in Compilern verwendet werden, um Da- tenabh ¨ angigkeiten von Operationen zu modellieren, werden in ADDGs die Abh ¨ an- gigkeiten von vielen Werten, die in einem Array gespeichert sind, modelliert. Die Datenabh ¨ angigkeitskanten in ADDGs sind dabei r ¨ uckw ¨ arts gerichtet. F ¨ ur die beiden Programme aus Beispiel 7.1.10, sind die ADDGs in Abb. 7.7 zu sehen. Man sieht, dass die Funktion f nicht interpretiert wird. Eine Variable v heißt im Folgenden • interne Variable, falls  W v =  R v gilt, d. h. jeder produzierte Wert auch konsu- miert wurde. • Eingabevariable, falls  W v = ∅ ist, d. h. kein Element produziert wurde. • Ausgabevariable, falls  R v ⊂ W v gilt, d. h. nicht alle produzierten Werte auch konsumiert wurden. Beispiel 7.1.12. Es wird wiederum das Programm 1 aus Beispiel 7.1.10 betrachtet. Die Variablen a und b sind Eingabevariablen und Variable c ist eine Ausgabevariable. Die Variablen tmp1, tmp2 und tmp3 sind interne Variablen. Neben der Abh ¨ angigkeitsabbildung aus Definition 7.1.4, die sich direkt aus den Anweisungen ablesen l ¨ asst, k ¨ onnen Datenabh ¨ angigkeiten auch ¨ uber mehrere Varia- blen hinweg als sog. transitive Abh ¨ angigkeitsabbildung definiert werden. Definition 7.1.6 (Transitive Abh ¨ angigkeitsabbildung). Sei v 0 ,v 1 , ,v n  ein Pfad im ADDG beginnend an Variablenknoten v 0 und endend in Variablenknoten v n mit n ≥ 0.Dietransitive Abh ¨ angigkeitsabbildung M ∗ v 0 ,v n ergibt sich zu: M ∗ v 0 ,v n := ⎧ ⎨ ⎩ I (Die Identit ¨ at) f ¨ ur n = 0 M v 0 ,v 1 f ¨ ur n = 1 M v 0 ,v 1 ◦ M v 1 ,v 2 ◦···◦M v n−1 ,v n sonst Dabei ist ◦ die Konkatenation f ¨ ur zwei Relationen, d. h. x → z ∈ F ◦ G ⇔∃y : x → y ∈ F ∧ y → z ∈ G. Die transitive Abh ¨ angigkeitsabbildung von einer Ausgabevariable zu einer Ein- gabevariable wird als Ausgabe-zu-Eingabe-Abbildung bezeichnet. Die Menge der Ausgabe-zu-Eingabe-Abbildungen definiert den Datenfluss des Programms. [...]... jeweilige a Pfad angegeben ¨ 7.2 Testfallgenerierung zur simulativen Eigenschaftsprufung ¨ F¨ r allgemeine Programme ist das Problem der Aquivalenzpr¨ fung nicht entscheidu u bar Per Simulation kann jedoch ein Programm mit einem Referenzprogramm vergli¨ chen werden Dabei ist das Ziel nicht, die Aquivalenz der Programme zu zeigen, sondern deren unterschiedliches Verhalten aufzudecken Dies kann, wie in . Programme ist das Problem der ¨ Aquivalenzpr ¨ ufung nicht entscheid- bar. Per Simulation kann jedoch ein Programm mit einem Referenzprogramm vergli- chen werden. Dabei ist das Ziel nicht, die ¨ Aquivalenz