Debugging-Funktion für PS-Explore-Datenmasken und -Makros
Für diejenigen Anwender, die PS-Explore als Softwareentwicklungswerkzeug nutzen um betriebs- und organisationseigene Anwendungen aufzubauen, war es bisher nicht immer unbedingt einfach im Falle eigenentwickelter komplexerer Datenmasken schnell und möglichst nebenbei Fehler in den selbstdefinierten Rechenfunktionen und Plausibilitätskontrollen zu finden.
Da in der letzten Zeit die Forderung von PS-Explore-„Hardcore“-Anwendern immer lauter wurde, ein adäquates Werkzeug zum Aufspüren und Bereinigen von Programmierfehlern insbesondere in Datenerfassungsmasken bereitzustellen, freuen wir uns umso mehr, hier nun Abhilfe bieten zu können.
Im Rahmen des intern so benannten Projektes „Marlowe“ wurde ein Debugging-Werkzeug fertig gestellt, das hervorragend geeignet ist, insbesondere Datenmasken mit umfangreichem Formelapparat unter Kontrolle zu halten.
Unser Entwicklungsprojekt wurde Marlowe getauft in Anlehnung an die Romanfigur Philip Marlowe aus den Kurzgeschichten und Romanen von Raymond Chandler. Mit Philip Marlowe schuf Chandler den Prototyp des Privatdetektivs, den viele spätere Schriftsteller als Vorbild für ihre Figuren nahmen. Und wahrhaft kann die Fehlersuche in Programmen sehr schnell zur Detektivarbeit werden.
Der Begriff „debugging“ (dt.: entwanzen) geht vermutlich auf die US-amerikanische Informatikerin und Computerpionierin Grace Hopper zurück. 1947 hatte sie während der Arbeiten am Computer Mark II eine Motte als Ursache für den Ausfall eines Relais identifiziert. Grace Hopper hat die (tote) Motte in das Logbuch geklebt und mit dem Satz „First actual case of bug being found.“ („Das erste Mal, dass tatsächlich ein Bug gefunden wurde.“) kommentiert. So wurde der „Bug“ ein Synonym für Fehlfunktionen im Computerbereich.
Dies jedoch nur episodisch am Rande.
Der Debugger „Marlowe“ kann an zwei Stellen im PS-Explore-System zum Einsatz gebracht werden: im Designmodus der Datenmasken via dem Formular „Feldattribute“ oder in der Registerkarte „Makroanwendungen“ des Autopiloten.
Die nachstehenden Beispiele wurden einer Anwendung entnommen, die bei der Stadt Stuttgart mit PS-Explore DBMSys entwickelt wurde. Die hier demonstrierten Fehler wurden beispielhalber in die Anwendung „eingebaut“.
Zur Stuttgarter Anwendung selbst siehe: http://www.gutachterausschuss.net/2008/1_VGSPS_Anwenderforum_2008_KPS_1.pdf
als auch http://www.gutachterausschuss.net/2008/2_VGSPS_Anwenderforum_2008_WA_1.pdf)
Der Debugger in den Datenmasken
Hauptfunktionen
Nach Aufruf einer Datenmaske klickt man zunächst in das Feld, welches man im Hinblick auf die mit diesem in Zusammenhang stehenden Formeln untersuchen möchte. Sodann aktiviert man den Designmodus und dort dann das Formular Feldattribute. Der Debug-Prozess wird durch Klick auf die neue Schaltfläche „Tracing“ angestoßen:
Nach einem kurzen Augenblick öffnet sich das Debugging-Fenster, in welchem man ein Baumdiagramm angezeigt bekommt:
Die Wurzel des Baumdiagramms ist benannt nach der Datenmaske, in welcher es aktiviert wurde. Auf Stufe 1 des Diagramms werden alle Felder der Datenmaske angeführt, die in einer dort hinterlegten Formel Bezug auf das aktuelle Feld nehmen. Alle diejenigen Felder, welche fehlerhafte Formeln enthalten, sind direkt auf Stufe 1 mit einer Fehlermeldung versehen.
Klickt man mit der Maus nun auf das entsprechende +-Zeichen vor dem Feldnamen, öffnet sich eine weitere Liste mit Knoten des Baumdiagramms, welche die für das jeweilige Feld hinterlegten Formeln enthält. Im Beispiel des Syntaxfehlers im vorstehenden Bild ist nur eine Formel hinterlegt, die aus einer relativ umfangreichen Recode-Funktion besteht. (Zur Benutzung der Recode-Funktion siehe den gesonderten Übersichtsartikel hierzu in den Online-News vom Januar 2009!)
Der Fehler wird bei Anlistung des Knotens bzw. des Recode-Befehls direkt angezeigt (rote Ellipse). Man sieht unmittelbar, dass hier im Beispiel offenbar im markierten Zweig des Recode-Befehls eine logische Funktion nicht vollständig angegeben ist. Statt „9900)“ zu Beginn der Zeile müsste es etwa „eq(GGebTyp_Art,9900)“ heißen.
Wir fahren nun mit dem Mauszeiger, der jetzt als Hand dargestellt wird, zum als fehlerhaft markierten Befehlszweig des Recode-Befehls. Die fehlerhafte Zeile wird dann unterstrichen dargestellt:
Durch einen Doppelklick auf die fragliche Zeile springt die Anzeige im Fenster „Feldattribute“ direkt zum Profil des betreffenden Feldes „EW_Z_Gesch_5“:
Hier kann man nun über die Schaltfläche mit dem Summenzeichen direkt in den Editiermodus für die zu korrigierende Formel springen und den Fehler beseitigen:
Nach der Korrektur des Fehlers schließt man die Formeldefinition und klickt auf die blaue Kopfleiste des hinter dem Feldattribute-Fenster liegenden Debugging-Formulars. Dieses wird hierdurch wieder aktiviert und nach vorne geholt.
Nun aktiviert man mit der rechten Maustaste das Popup-Menü des Debugging-Formulars:
Das Popup-Menü enthält als ersten Punkt die Option zur Wiederholung der Fehlersuche. Die restlichen Menüpunkte sind selbsterklärend, können hier und da nützlich sein, sind jedoch nicht von Bedeutung für den eigentlichen Prozess der Fehlersuche. Es handelt sich hierbei um die Funktionen zum kompletten Aufklappen des Baumdiagramms, vice versa zum kompletten Zusammenklappen, ferner um eine Funktion zum Kopieren des gesamten aufgeklappten Baumdiagramms in die Zwischenablage und um die Funktion zur Ausgabe des Diagramms auf dem Drucker. Ferner Steht auch eine Funktion zur Verfügung, die es erlaubt zusätzlich zu Fehlermeldungen auch Warnungen anzuzeigen (s.u.).
Der Klick auf „Tracing wiederholen“ führt den Debugging-Prozess erneut durch. Das Ergebnis zeigt, dass der Fehler im Recode-Befehl des Feldes „EW_Z_Gesch_5“ erfolgreich beseitigt wurde:
In der gleichen oben beschriebenen Weise lassen sich nun alle weiteren Fehler eliminieren.
Weitere Funktionen
Das Baumdiagramm erlaubt es natürlich auch, die einzelnen Befehle auf ihren verschiedenen Ausführungsstufen anzuschauen.
Stufe 1 (roter Kasten) zeigt die eigentliche Definition der Formel mit den Feldnamen und Konstanten. Stufe 2 (blauer Kasten) zeigt denselben Befehl, allerdings nun hinsichtlich der Feldnamen bestückt mit den Werten des aktuellen Falles, der in der Maske angezeigt wird. Hiermit lassen sich dann ggf. noch individuelle Realisierungen des Befehls nachverfolgen:
Stufe 3 (grüner Kasten) zeigt dann schließlich den durch Auswertung der hier logischen Funktionen der einzelnen Zweige des Recode-Befehls geschrumpften Befehl:
Im hier gewählten Beispiel sieht die Sache nun recht trivial aus, da logische Funktionen nur 0 und 1 als Ergebnis ausweisen. Die letzte Zeile des Diagrammzweiges gibt das berechnete Ergebnis des jeweiligen Befehls an. Hier war kein Ergebnis berechenbar. Im Klartext: alle logischen Funktionen erbrachten als Ergebnis 0 (falsch). Somit wurde keiner der rechts vom Gleichheitszeichen angegebenen Werte zugewiesen.
Das „Hauptergebnis“, also das Resultat aus allen sequentiell durchgerechneten Berechnungsschritten wird im Baumdiagramm mit dem Feldnamen auf Stufe 1 ausgegeben (siehe oben braune Ellipse!). Nicht notwendigerweise muss das Endresultat mit dem Ergebnis des letzten Rechenschrittes identisch sein. Hier im Beispiel des Recode-Befehls erscheint der Hinweis „Es ist kein Ergebnis berechenbar.“. Trotzdem wird aber beim Feldnamen als Ergebnis „0“ angegeben. Dies hängt damit zusammen, dass etwa durch Feldformatierungen oder andere Einstellungen in den Feldattributen hier abweichende Ausgaben erscheinen können.
Schauen wir uns noch ein weiteres interessantes Beispiel an, eine Iteration mittels der Funktion $itera. Hierbei sind in der Formeldefinition des Feldes „BE_LiegZinserm“ zwei Rechenbefehle hinterlegt. Einmal die Iterationsanweisung selbst, welche den so genannten Liegenschaftszins berechnet und anschließend dann noch die Multiplikation des errechneten Wertes mit 100 um einen Prozentwert zu erhalten:
Als Ergebnis des Debugging durch Klick auf die Schaltfläche „Tracing“, wobei der Bildschirmcursor im dementsprechenden Feld für den Liegenschaftszinssatz stehen muss, erhält man wieder das Debugging-Fenster mit dem Baumdiagramm für den Formelapparat angezeigt. Per rechtem Mausklick aktiviert man das Popup-Menü und wählt den Punkt „Diagramm aufklappen“. Als Ergebnis erhält man die volle Sicht auf die Rechenoperationen des Feldes „BE_LiegZinserm“:
Sehr übersichtlich sieht man nun untereinander die ursprüngliche Formeldefinition zu $itera und die hieran anschließenden einzelnen Iterationsschritte. Dabei wird jeweils die Formel im Einzelschritt und hierunter das Ergebnis angezeigt. Nach 5 Iterationsschritten stoppt das Verfahren, da die vorgegebene Genauigkeit erreicht wurde. Das Ergebnis 0,02680503762 wird nun in der nachfolgenden Berechnung noch mit 100 multipliziert und man erhält 2,681.
Man beachte auch hier, dass das oben beim Feldnamen ausgewiesene Endresultat 2,68100 lautet, was darauf zurückzuführen ist, dass dem Ausgabefeld auf dem Bildschirm im Formular „Feldattribute“ ein gesondertes Ausgabeformat zugewiesen ist.
Da die hier zugrunde liegende Iterationsformel recht lang ist, erscheint sie im Baumdiagramm nicht vollständig dargestellt. Klickt man jedoch mit dem Mauszeiger die Formelzeile an, dann erscheint über dem Baumdiagramm ein entsprechendes Hinweisfeld in Hellblau mit der Anzeige der formatierten vollständigen Formel:
Warnungs- und Fehlerstatistik
Schlussendlich sei noch darauf hingewiesen, dass es möglich ist, neben den entdeckten Fehlern im Formelapparat auch Warnungen zu möglichen Inkonsistenzen anzeigen zu lassen. Dies geschieht über das Popup-Menü und den Punkt „Warnungen nicht anzeigen“. Ist diese Option mit einem Häkchen versehen (Voreinstellung), dann werden Warnungen unterdrückt. Anderenfalls erfolgt eine Hinweismeldung auf Stufe 1 des Baumdiagramms direkt beim jeweiligen Feldnamen.
Programmwarnungen beziehen sich meist auf das errechnete Ergebnis einer Formel. Kommt kein Ergebnis zustande, kann es hierfür mehrere Gründe geben. Zum einen kann es sein, dass für den jeweils betrachteten Fall bestimmte Felder nicht gefüllt sind (Fehlwerte). Schwerwiegender ist es, wenn Feldnamen benutzt werden, die gar nicht in der Datenbank vorhanden sind. Klappt man den entsprechenden Knoten auf Stufe 1 auf, so sieht man sehr schnell, wo etwas im Argen liegt. So tauchen dann in den Formeln „?“ oder das Fehlwertsymbol „-“ auf (siehe vorstehende Abbildung). Benutzte aber nicht vorhandene Feldnamen werden auf Stufe 4 angezeigt und fallen ebenfalls sofort ins Auge.
Überprüfung von Plausibilitätschecks
Neben der Kontrolle des Formelapparates bietet der Debugger auch eine automatische Kontrolle der so genannten Plausibilitätschecks von Datenmasken.
Plausibilitätschecks dienen hierbei der Überprüfung der logischen Konsistenz von Eingaben in Felder einer Datenmaske. Mit diesen Checks wird überprüfbar, ob die Eingabe in einem Feld mit den Eingaben in anderen Feldern der Maske logisch wie inhaltlich übereinstimmt.
Die nachstehende Abbildung macht die Anwendungszusammenhänge deutlich. Oben rechts im Bild wurde das Formular „Feldattribute“ aktiviert. Von dort wurde über die Schaltfläche „Tracing“ der Debugger aufgerufen, nachdem zuvor das zu überprüfende Feld „Eigentumsart“ angeklickt worden war. Das Baumdiagramm des Debuggers zeigt alle logischen Abfragen (hier 3 Stück) an, einmal die Logik daselbst, darunter die mit den aktuellen Maskeninhalten befüllte Formel und sodann die berechneten Wahrheitswerte mit deren und/oder Verknüpfungen:
Der Debugger in den Makroanwendungen
Das Auffinden von Fehlern in Makros ist im Allgemeinen einiges einfacher als in Datenmasken, da hier von jeher gute Möglichkeiten zur Verfügung stehen. Ein Makro stoppt im Standardfall an der Stelle, wo ein Fehler auftaucht. Ferner kann man mit Hilfe des Halt-Befehls (Seite 215 im Handbuch) an beliebigen Stellen eines Makros einen temporären Programmstop veranlassen um Zwischenresultate zu verfolgen und anschließend den Makrolauf fortzusetzen.
Der Makroagent wird in der Registerkarte „Makroanwendungen“ aktiviert und die entsprechende Schaltfläche findet an der im nachstehenden Bild mit rotem Kreis bezeichneten Stelle. Klickt man das Symbol an, so wird es versenkt dargestellt um zu symbolisieren, dass der Agent aktiv ist. Umgekehrt wird der Agent zum „Schläfer“, wenn die Schaltfläche erhoben dargestellt ist:
Es sei hier nur kurz ein kleines Beispiel an Hand des rechne-Befehls von PS-Explore gegeben. Benutzt wird eine iterative Formel zur Berechnung des Liegenschaftzinssatzes. Das zugehörige Makro greift auf die Datei LSZ.SSD zu, welche lediglich, der übersichtlichen Demonstration wegen, nur einen Datensatz enthält:
Man startet nun das folgende Makro:
In der Registerkarte „Ergebnisse/Reports“ findet man sodann das folgende Resultat:
Im Prinzip findet man hier außer der ursprünglichen Formel nur die Substitutionszeile und 3 Zeilen mit Iterationsschritten. Das sieht, da hier keine Fehler in der Formel enthalten sind, nicht viel anders aus, als bei der sonst üblichen Ausgabe dieses Befehls zur Iteration (siehe hierzu die News vom letzten Dezember: http://www.vgsps.de/html/Iterationsfunktion/Iterationsformel.html)
Interessant wird es erst, wenn man in der Formel einen Fehler einbaut, etwa eine Klammer entfernt, so dass die Klammern in der Formel nicht mehr ausbalanciert sind:
Man sieht auch bei der Makroprogrammierung ist Detektiv Marlowe durchaus zu gebrauchen, wenngleich der wirkliche Mehrnutzen der neuen Debugging-Funktion sicherlich im Bereich der Entwicklung von Formularen und Datenmasken im Bereich der Anwendungsentwicklung zu sehen sein wird.