Advertisement

Statische Analyse und symbolische Ausführung

  • Eike Hagen Riedemann
Part of the Leitfäden der Informatik book series (XLINF)

Zusammenfassung

Die statische Analyse (auch statischer Test genannt) und die symbolische Ausführung eines Programms sind Vorgänge, die ein Programm nicht mit konkreten Eingabewerten, sondern „konzeptuell“ ausführen. Folgende Dokumente kommen für die statische Analyse in Betracht, da nicht erst das fertige Programm, sondern auch andere Produkte und Dokumente, die bei der Programmentwicklung in früheren Phasen anfallen, analysiert werden sollten:
  1. 1.

    Anforderungsspezifikation und Systemspezifikation

     
  2. 2.

    Entwurfsspezifikation (Grobentwurf und Feinentwurf)

     
  3. 3.

    Programm in Quellsprache (Quellcode)

     
  4. 4.

    Programm in Zielsprache (Objektcode)

     

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 1.
    frühe Korrekturen sind 10 bis 100mal billiger; s. Kapitel 2.5Google Scholar
  2. 2.
    Wie im Vorwort angekündigt, wird in diesem Kapitel bei Personen- und Berufsbezeichnungen nur die weibliche oder eine neutrale Form verwendet.Google Scholar
  3. 3.
    3Nach einer neuen Studie von Porter et al. finden Inspektionsgruppen mit zwei Personen ebensoviele Fehler wie Gruppen mit vier Personen — sind also kostengünstiger und ebenso effektiv (s. [Po and 95]).Google Scholar
  4. 4.
    Die folgenden Bemerkungen beziehen sich auf Il-und I2-Inspektionen, andere Inspektionen (IT1, IT2, sowie die Dokumentations-Inspektionen PIO bis PI2) haben im wesentlichen gleiche Eigenschaften, unterscheiden sich aber im Inspektionsmaterial und der Zahl der Teilnehmerinnen.Google Scholar
  5. 5.
    Aus Effizienzgrnnden soll die Gruppe nur ein Ziel (Fehler finden) verfolgen.Google Scholar
  6. 6.
    6siehe Definition 7.2.5 auf S. 198Google Scholar
  7. 7.
    7Angaben darüber, worauf zu achten ist; siehe Checklisten bei Schritt 2 obenGoogle Scholar
  8. 8.
    Normalerweise gibt es immer Zeitdruck am Ende eines Projektes, so daß die Gefahr besteht, daß die Inspektionen wegfallen bzw. nur oberflächlich durchgeführt werden.Google Scholar
  9. 9.
    Nach [Fag 76] liegt der Wert bei 130 Codezeilen, nach [Sch 88b] bei 100 und nach [Hau 83] zwischen 100 und 200 Codezeilen — bei IO zwischen 220 und 300.Google Scholar
  10. 10.
    Nach [Sch 88b] liegt der Wert bei 90 Codezeilen, nach [Hau 83] und [Fag 86] nur zwischen 90 und 125, nach [Fag 76] bei 150 Codezeilen.Google Scholar
  11. 11.
    Nach Hausen bei II 18% (vgl. Fußnote 18 auf S. 310).Google Scholar
  12. 12.
    Man soll die Gans nicht schlachten, die goldene Eier legt.Google Scholar
  13. 13.
    Einsparungen bei der Codierzeit abzüglich erhöhtem Aufwand für Inspektions-und ÜberarbeitungszeitenGoogle Scholar
  14. 14.
    da pro Jahr ca. 3.000 bis 5.000 Zeilen von einer Person geschrieben werden könnenGoogle Scholar
  15. 15.
    Bis zu einem Zeitpunkt „7 (Test-)Monate nach Abschluß des Modul-Tests" gemessen. Bei IBM ergab sich seit 1976 sogar eine Fehlerreduktion um ca. 66% (D; siehe [Fag 86].Google Scholar
  16. 16.
    ohne genaue Rollen für Teilnehmerinnen, insbesondere ohne Moderation; ohne Checklisten, Fehlerlisten; ohne Überprüfung der Korrekturen und FehlerauswertungGoogle Scholar
  17. 17.
    bei einem Programm mit ca. 6.000 Zeilen sogar 93% aller überhaupt gefundenen Fehler, generell 60-90% aller Fehler (nach [Fag 86])Google Scholar
  18. 18.
    Nach Hausen werden 12%, 18% und 25 bis 30% aller Fehler bei der Inspektion von Grob-und Feinentwurf und Programmen (I0-, Il-, I2-Inspektionen) gefunden und die restlichen 40 bis 45% erst durch Testen (siehe [Hau 83]).Google Scholar
  19. 19.
    pro Unterprogramm/Modul bzw. Modul/SegmentGoogle Scholar
  20. 20.
    Einige komplizierte Schnittstellen-Routinen wurden vorsichtshalber (nach Änderungen) immer wieder geprüft, so daß es schon hieß: „déja re-vu“ (statt „déja vu“ = schon mal gesehen).Google Scholar
  21. 21.
    Wegen der Unentscheidbarkeit des „Halteproblems" ist dies natürlich nur z.T. (in einfachen Fâllen) entscheidbar.Google Scholar
  22. 22.
    genaueres dazu siehe Kap. 16.1Google Scholar
  23. 23.
    Dieser Kontrollflußgraph wird für die Kriterien von Kap. 7 benötigt.Google Scholar
  24. 24.
    Genaueres zu Definition und Verwendung der Maße siehe in Kap. 16.1 und 16.2.Google Scholar
  25. 25.
    Prozeduren und Funktionen sind Operationen.Google Scholar
  26. 26.
    Auch die leere Folge ist erlaubt; formal gilt also, daß a und ß aus {r, d,u}' sind.Google Scholar
  27. 27.
    Dies ist nur die Idee, der Korrektheitsbeweis findet sich bei Hecht und Kildall (s. [HeU 75], [Kil 73]).Google Scholar
  28. 28.
    Dabei bezeichnen S(j) und P(j) die Menge der Nachfolgerknoten (successor) bzw. Vorgängerknoten (predecessor) eines Knotens j.Google Scholar
  29. 29.
    Bei geschachtelten Prozeduren oder Blöcken gilt an deren Anfang für den entsprechenden Knoten j: undef(j) = kill(j) = L,wobei L die Menge der lokalen Variablen ist. Bei Prozeduren mit Parametern ist für den Anfangsknoten 0 die Menge def(0) bzw. generate(0) die Menge der Parameter und globalen Variablen mit definierten Werten.Google Scholar
  30. 30.
    Dies entspricht der Bestimmung der erkannten regulären Wortmenge zu einem erkennenden, endlichen Automaten, ist also formal berechenbar (s. [Bra 84], Satz 5.3.7 (von Kleene); [Weg 93], Satz 5.3.3 bzw. [Weg 96], Kap. 5.5).Google Scholar
  31. 31.
    Unter dem Gesichtspunkt der Erhaltung von Arbeitsplätzen ist dies sogar ein Vorteil.Google Scholar
  32. 32.
    Eine for-Schleife „for i:= 1 to 10" erzeugt dagegen wieder nur endlich viele Wege endlicher Länge.Google Scholar
  33. 33.
    siehe Definition 7.2.1 auf 195 34siehe Definition 7.2.1Google Scholar
  34. 35.
    bzw. der Semantik des Compilers, die davon abweichen kannGoogle Scholar
  35. 36.
    Druckt man arithmetische Ausdrücke durch ein Werkzeug in der (in der Mathematik üblichen) zweidimensionalen Form aus, fallen Klammerungsfehler doch auf: Ausdruck MERKE(I)-1/10 + 1 [statt richtig (MERKE(I)-1)/10+1] würde in folgender Form dargestellt: MERKE(I)-1/10 +1 [statt MERKE(I)/10+1] Google Scholar
  36. 37.
    und — bei Eingabevariablen — ihren AnfangswertenGoogle Scholar
  37. 38.
    11icht unbedingt verschieden von der erstenGoogle Scholar
  38. 39.
    Ein zu kleiner Stack bzw. die falsche Behandlung des Stack-Überlaufs war die Ursache für den zweitägigen Ausfall des neuen Bundesbahnstellwerks in Hamburg-Altona im März 1995 (s. SEN,Vol. 20, No. 3, Juli 1995, S. 8).Google Scholar

Copyright information

© Springer Fachmedien Wiesbaden 1997

Authors and Affiliations

  • Eike Hagen Riedemann
    • 1
  1. 1.Universität DortmundDortmundDeutschland

Personalised recommendations