DE69024515T2 - Gerät zur Streckenmessung und -analyse zur Leistungsabschätzung von Software-Entwürfen - Google Patents

Description

• Die vorliegende Erfindung bezieht sich allgemein auf die Entwicklung von Softwareprogrammen und ist insbesondere auf ein neues Programmierwerkzeug gerichtet, welches einen Softwareingenieur in die Lage versetzt, das erwartete Verhalten eines Programms auszuwerten und potentielle Probleme im Verhalten während einer frühen Stufe der Progammentwicklung zu isolieren.
• Ein typischer Lebenszyklus bei der Entwicklung eines Computerprogramms weist die anfänglichen Schritte des Analysierens des Problems, das durch das Programm gelöst werden soll, und des Entwerfens der Gesamtstruktur des Programms auf. Nachdem die allgemeine Struktur des Programms entworfen worden ist, wird es dann aufgebaut oder codiert, wonach es einer Periode des Testens und Fehlerbeseitigens unterzogen wird. Nachdem das Programm erfolgreich getestet wurde, wird es schließlich zur allgemeinen Verwendung freigegeben. Eine Schwierigkeit, die zu diesem herkömmlichen Lösungsansatz für die Softwareentwicklung gehört, ist die Tatsache, daß derselbe es nicht leicht ermöglicht, Entwurfsfehler zu erkennen, bis im wesentlichen die gesamte Arbeit, die zur Programmerzeugung notwendig ist, vollendet wurde. In anderen Worten war es in der Vergangenheit immer notwendig, den Code für das Programm aufzubauen, bevor es auf den Wirkungsgrad des Betriebs desselben getestet werden konnte. Wenn ein unbefriedigendes Verhalten erfaßt wurde, sobald der Code geschrieben war und das Programm während der Testphase gelaufen war, war es somit notwendig, in die Entwurfsphase zurückzukehren, um das Programm neu zu strukturieren, und daraufhin den Code neu zu schreiben, um die Entwurfsänderungen zu implementieren.
• Oft sind die Fehlerarten, deren Korrektur den größten Aufwand bedeutet, die, die in der Analyse- und Entwurfsphase des Programmentwicklungszyklus auftreten. In dieser Hinsicht ist einer der Faktoren, die das Verhalten eines Programms bedeutsam beeinflussen, die Weglängen in der Struktur des Programms, denen gefolgt wird, um eine bestimmte Aufgabe durchzuführen. Die Weglänge ist typischerweise hinsichtlich der Anzahl der Übergänge von Modul zu Modul definiert, welche auftreten, während das Programm von einem Anfangsmodul zu dem Endknoten in dem Weg fortschreitet, welcher die Vollendung der Aufgabe darstellt. Indem eine Weglänge länger wird, benötigt das Programm typischerweise länger, um die Aufgabe durchzuführen, wodurch der Wirkungsgrad des Programms reduziert wird. Ein weiterer Faktor, welcher das Verhalten des Programms beeinflußt, ist der Wirkungsgrad eines bestimmten Moduls, das oft durchgeführt werden kann, indem es viele Male aufgerufen wird.
• In dieser Hinsicht ist eine gebräuchliche Methodologie, die bei der Softwareentwicklung verwendet wird, als "Strukturierter Entwurf" bekannt. Grundsätzlich umfaßt diese Methodologie das Zerlegen einer Aufgabe in immer kleinere Funktionseinheiten. Durch diesen Lösungsansatz können wiederholbare und voraussagbarere Ergebnisse bei der Softwareentwicklung erhalten werden. Da der Lösungsansatz des Strukturieren Entwurfs jedoch eine Funktionsaufspaltung und kleine Modulgrößen fördert, kann dies längere Weglängen zur Folge haben. Als Ergebnis könnte das Verhalten des Programms nicht optimal sein, wenn diese Entwurfsmethodologie verwendet wird.
• In "Software Performance Analysis Using a Graphic Modeling Technique", Proceedings of the Eighth Annual International Phoenix Conference on Computers and Communications, 24. März 1989, Scottsdale, Arizona, schlagen J. Wang u.a. ein Graphisches Verhaltensanalysesystem ("GPAS"; GPAS = Graphic Performance Analysis System) vor. Ein Softentwickler verwendet GPAS, um ein Berechnungs-Strukturmodell während des Entwurf sverfahrens zu bauen. Dieses Modell kann lediglich einen Startknoten, einen Endknoten und drei weitere Knotenarten aufweisen. Der Entwickler verwendet das Modell zum Verhaltens- und Funktions-Entwurf.
• Obwohl Wang u.a. ein Verfahren zum Entwerfen von Software schaffen, das einen definierten Startknoten und einen definierten Endknoten in einem Programm mit vielen Modulen aufweist, ist es oft schwierig, kritische Flußwege durch die verschiedenen Module zu identifizieren. Dies ist besonders der Fall, wenn das gesamte Programm einem beliebigen von vielen verschiedenen Wegen folgen könnte, wobei jeder mit einem unterschiedlichen Modul endet. Somit muß bei großen und komplexen Programmen das Programm codiert und getestet werden, bevor lange Wege, die das Verhalten ungünstig beeinflussen, erkannt werden können. Als Ergebnis ist es offensichtlich, daß bedeutsame und aufwendige Anstrengungen notwendig sind, um das Programm neu zu entwerfen und dasselbe dann neu zu codieren, sobald die Verhaltenseinschränkungen erfaßt wurden. Demgemäß würde es wünschenswert sein, ein Softwareentwicklungswerkzeug zu schaffen, welches mögliche Verhaltensprobleme früh in dem Softwareentwicklungszyklus isoliert, bevor codiert wird, um dadurch die notwendige Anstrengung zur Korrektur derartiger Probleme zu minimieren.
• Die Merkmale der Erfindung sind in Anspruch 1 definiert.
• Die Erfindung ermöglicht es, den erwarteten Wirkungsgrad und das Verhalten eines Programmentwurfs vor dem Codieren aus zuwerten. Dieselbe ist besonders entworfen, um mit den Ergebnissen des Strukturierter-Entwurf-Lösungsansatzes zur Softwareentwicklung zusammenzuarbeiten. Grundsätzlich schafft herkömmliche Software, die bei der Implementierung des Strukturierter-Entwurf-Lösungsansatzes verwendet ist, eine Datenbank, die sowohl eine Spezifikation für jedes Modul (Funktionselement) in dem Entwurf als auch die Gesamtbeziehung der Module untereinander aufweist. Unter Verwendung dieser Informationen bestimmt die Erfindung jeden möglichen Weg, dem von der Implementation des Programms gefolgt werden kann. Aus diesen Ermittlungen werden Berichte erzeugt, die die längsten Wege in dem Programm und daher die Quellen von potentiellen "Flaschenhälsen" in dem Verhalten des Programm identifizieren.
• Bei einem bevorzugten Ausführungsbeispiel der Erfindung kann die Zeit, die erforderlich ist, um jedem Weg zu folgen, auf der Basis von Gewichtungsfaktoren, die den verschiedenen Modulen zugewiesen sind, bestimmt werden. Die Module, die bei der Implementierung des Programms am öftesten aufgerufen werden, können identifiziert und in die Aufmerksamkeit des Programmentwicklers als Programmelemente gerufen werden, welche am eingehendsten auf eine mögliche Optimierung hin überprüft werden müssen. Der Benutzer kann ferner verschiedene hypothetische Situationen erzeugen und die Auswirkung derselben auf den Wirkungsgrad des Programms auswerten.
• Die Erfindung versetzt den Programmentwickler in die Lage, einige Typen von Entwurfsfehlern zu identifizieren und zu korrigieren, bevor jemals ein beliebiges Codieren des Programms stattgefunden hat, wodurch die Kosten und der Aufwand, die zum Herstellen eines Programms erforderlich sind, welches mit optimalem Wirkungsgrad arbeitet, bedeutsam reduziert werden.
• Weitere Eigenschaften der vorliegenden Erfindung und die dadurch gebotenen Vorteile werden nachfolgend bezugnehmend auf die in den beigefügten Zeichnungen dargestellten Beispiele detaillierter erklärt.
Kurze Beschreibung der Zeichnungen
• Fig. 1 ist ein Flußdiagramm in Blockdiagrammform des bekannten Lösungsansatzes zur Softwareentwicklung;
• Fig. 2 ist ein Flußdiagramm in Blockdiagrammform, das einen Softwareentwicklungs-Lebenszyklus zeigt, welcher die Prinzipien der vorliegenden Erfindung verwendet;
• Fig. 3 ist ein allgemeines Blockdiagramm, das den Funktionsbetrieb der vorliegenden Erfindung zeigt;
• Fig. 4 ist ein Beispiel eines Strukturdiagramms, das durch den Strukturierter-Entwurf-Lösungsansatz zur Softwareentwicklung erzeugt werden kann;
• Fig. 5 ist ein Beispiel einer Tabelle ("spreadsheet"), die durch das Entwurfs-Auswertungswerkzeug erzeugt werden kann;
• Fig. 6 ist ein allgemeines Strukturdiagramm, das den Gesamtbetrieb der vorliegenden Erfindung zeigt; und
• Fig. 7 ist ein spezifischeres Flußdiagramm, das die Analyse der Informationen in der Strukturierter-Entwurf-Datenbank darstellt, um eine interne Wegstrukturdatei zu erzeugen.
Beschreibung der bevorzugten Ausführungsbeispiele
• Der typischer Lebenszyklus, der bei der Softwareentwicklung üblicherweise verwendet wird, wird zuerst bezugnehmend auf Fig. 1 kurz beschrieben. Bei einem Entwurfslösungsansatz für strukturierte Systeme umfaßt der erste Schritt eine "Strukturierte Analyse" 10 der Grundziele der Software. Im allgemeinen resultiert diese Phase in einem Überblick der Anforderungen des Programmbenutzers an das Programm. Sobald diese Anforderungen identifiziert sind, wird ein Strukturierter- Entwurf-Lösungsansatz 12 verwendet, um die durch die Software durchzuführenden Aufgaben zu definieren. Wenn diese Aufgaben mit ausreichender Genauigkeit entworfen sind, findet das tatsächliche Codieren des Programms bei einem Schritt 14 statt. Nach der Codierphase durchläuft das Programm eine Test- und Auswertungs-Phase 16.
• Als ein Ergebnis der Testphase werden Einschränkungen in dem Verhalten des Programms erkannt. Es werden beispielsweise Aufgaben identifiziert, die in einer spezifizierten Zeitdauer nicht vollendet werden. An diesem Punkt kehrt das Softwareentwicklungsverfahren in die Entwurfsphase 12 zurück, in der der Entwurf überarbeitet wird, um die Verhaltens-Flaschenhälse zu reduzieren oder zu beseitigen. Als ein Ergebnis dieser Entwurfsänderungen muß ein zusätzliches Codieren 14 stattfinden, welchem weitere Test- und Auswertungsschritte 16 folgen. Der geschlossene Schleifenprozeß des Entwerfens, Codierens und Testens könnte einige Wiederholungen durchlaufen, bevor das Programm schließlich auf einer befriedigenden Ebene arbeitet. Sobald dieser Punkt erreicht ist, wird das Programm bei Schritt 18 zur Verteilung freigegeben.
• Gemäß der vorliegenden Erfindung kann viel von der Zeit, die während der Test-, Neuentwurfs- und Neucodier-Phasen des Softwareentwicklungszyklus verbraucht wird, bedeutsam verringert werden, indem der Wirkungsgrad des Entwurfs vor dem Zeitpunkt, zu dem eine Codierung des Programms stattfindet, ausgewertet wird. Bezugnehmend auf Fig. 2 beginnt ein Softwareentwicklungszyklus, der die Techniken der vorliegenden Erfindung verwendet, mit einer Analyse der von dem Programm durchzuführenden Funktionen, vorzugsweise unter Verwendung des Strukturierte-Analyse-Lösungsansatzes. Dieser Phase folgt die Entwurfsphase 12 für das Programm, wieder vorzugsweise unter Verwendung einer Strukturierter-Entwurf-Technik. Die Softwarewerkzeuge, die gemäß dieser Technik verwendet werden, erzeugen eine Datenbank, die Informationen enthält, die verwendet werden können, um gemäß der vorliegenden Erfindung den Gesamtwirkungsgrad des Entwurfs auszuwerten. Der Strukturierte Entwurf ist ein wohlbekanntes Verfahren, das üblicherweise von Softwareingenieuren verwendet wird, weswegen es hier nicht beschrieben wird. Für eine detaillierte Beschreibung dieses Entwurfslösungsansatzes wird auf "The Practical Guide to Structured Systems Design" von Meilir Page-Jones, veröffentlicht von Yourdon Press, New York, 1980, verwiesen.
• Unter Verwendung der Informationen, die als ein Ergebnis des Strukturierten Designs vorhanden sind, findet eine Auswertung 20 des Entwurfs sofort nach der Vollendung. des Entwurfsschritts 12 und vor der Codierphase 14 statt. Als ein Ergebnis dieser Auswertung können verschiedene Unzulänglichkeiten in dem Programm erfaßt und in die Aufmerksamkeit des Softwareingenieurs gebracht werden. Wie vorher erörtert wurde, ist beispielsweise ein Faktor, der bedeutsam zu dem Wirkungsgrad eines Programms beiträgt, die Längen der Wege, denen gefolgt werden muß, um eine spezielle Aufgabe durchzuführen. Der Auswertungsschritt 20 kann die Längen der Wege bestimmen, denen während des Betriebs des Programms, das sich in der Entwicklung befindet, gefolgt werden muß. Zusätzlich kann die Auswertungsphase 20 sowohl wirksam sein, um Module (Funktionselemente) in dem Programm, welche am häufigsten verwendet werden, zu identifizieren und diese Module in die Aufmerksamkeit des Entwicklers als wahrscheinliche Kandidaten zur Optimierung zu rufen, als auch weitere Informationen schaffen, welche hilfreich sind, um mögliche Verhaltenseinschränkungen zu isolieren.
• Mit der von dem Entwurfsauswertungsschritt 20 geschaffenen Informationen kann der Softwareingenieur das Programm neu entwerfen, um die möglichen Unzulänglichkeiten zu reduzieren oder zu beseitigen. Nachdem das Programm neu entworfen ist, kann es wieder gemäß der vorliegenden Erfindung ausgewertet und nach Notwendigkeit weiter verfeinert werden. Sobald der Entwurfsauswertungsschritt 20 ein Anzeichen schafft, daß die Programmstruktur eine befriedigende Verhaltensebene erfüllt, kann der Entwurf einem Programmierer für die herkömmlichen Schritte des Codierens 15 und Testens 16 überreicht werden. Da die Entwurfsauswertung hilft, um Entwurfsunzulänglichkeiten vor dem Codieren zu identifizieren und zu reduzieren, ist die Testphase 16 eher auf spezielle Codierfehler und das Fehlerbeseitigen dieser Fehler konzentriert. Codierfehler sind viel leichter und weniger aufwendig als Entwurfsfehler zu korrigieren, wodurch der gesamte Aufwand und die gesamte Zeit, die benötigt werden, um das Programm in die Form für eine endgültige Freigabe 18 zu bringen, insbesondere bei großen und hochkomplexen Programmen bedeutsam reduziert werden können.
• Die allgemeine Architektur eines Systems zum Durchführen der Entwurfsauswertungsphase 20 ist in Blockdiagrammform in Fig. 3 dargestellt. Gemäß Fig. 3 schaffen die Werkzeuge, welche verwendet werden, um den Strukturierter-Entwurf-Lösungsansatz zum Softwareentwickeln durchzuführen, eine Datenbank 22, welche Informationen enthält, die sowohl die Gesamtstruktur des Programms als auch die Funktionalität der einzelnen Module desselben beschreiben. Die Gesamtstruktur des Programms wird typischerweise mittels eines Strukturdiagramms dargestellt, wobei ein Beispiel desselben in Fig. 4 gezeigt ist. Das spezielle Beispiel, das in Fig. 4 dargestellt ist, steht für ein relativ einfaches Programm, um ein Verständnis der Erfindung und der Anwendung derselben zu erleichtern. Es ist jedoch offensichtlich, daß die vorliegende Erfindung besonders in Verbindung mit großen und hochkomplexen Programmentwürfen nützlich ist, deren Strukturdiagramme sich typischerweise über eine Anzahl von Blättern ausbreiten, und daher manuell schwierig zu begreifen sind.
• Bei dem Strukturdiagramm stellt jeder Block, der mit einem Buchstaben bezeichnet ist, ein Modul in dem Programm dar. Die Linien, die die Module untereinander verbinden, identifizieren die hierarchischen Beziehungen der Module untereinander und dienen zur Definition der Wege, denen bei dem Betrieb des Programms gefolgt wird, um spezielle Aufgaben durchzuführen. Zusätzlich zu Informationen, die das Struk-£urdiagramm beschreiben, enthält die Datenbank 22 (in Fig. 3 gezeigt) ebenfalls eine Spezifikation für jedes einzelne Modul. Diese Spezifikation beschreibt grundsätzlich die Eingaben eines Moduls, die in dem Modul durchgeführte Funktion und die Ausgaben des Moduls.
• Auf die in der Datenbank 22 enthaltenen Funktionen wird durch ein Entwurfsauswertungswerkzeug 24 zugegriffen, welches gemäß der vorliegenden Erfindung arbeitet. In einem Betriebsmodus bestimmt das Auswertungswerkzeug 24 die Länge jedes möglichen Weges, dem während des Programmlaufs gefolgt werden kann. Grundsätzlich ist eine Weglänge hinsichtlich der Anzahl der Übergänge von einem Anfangsmodul zu dem Endknoten in dem Weg definiert. Bezugnehmend auf das Strukturdiagramm, das in Fig. 4 gezeigt ist, enthält der Weg von dem Anfangsmodul A zu dem Endmodul M zwei Übergänge, vom Modul A zu C und dann von dem Modul C zu M. Somit weist dieser Weg eine Länge von Zwei auf.
• Im Betrieb spezifiziert der Benutzer ein spezielles interessierendes Modul, welches das Anfangsmodul in einem Weg zum Durchführen einer Aufgabe sein kann. Jeder mögliche Weg, dem von diesem Anfangsmodul gefolgt werden kann, wird dann bestimmt und die Länge desselben gemessen. Nachdem alle möglichen Wege ausgewertet worden sind, erzeugt das Werkzeug 24 auf einem Drucker oder einer Videoanzeige Berichte 26, die die derartige Auswertung anzeigen. Ein derartiger Bericht kann alle möglichen Wege von dem spezifizierten Modul, wie z.B. dem Grundmodul A, und die entsprechenden Längen derselben auflisten. Für das Programm von Fig. 4 würde ein derartiger Bericht wie in Tabelle 1 aussehen: ALLE WEGE Weg Weglänge Tabelle 1
• Wenn es erwünscht ist, können die Wege in der Reihenfolge absteigender Weglänge aufgelistet werden. Zusätzlich kann der Benutzer auswählen, ob diese Module, die asynchron aktiviert werden, wie z.B. das Modul Q in dem Beispiel von Fig. 4 (wie durch die gestrichelte Linie von dem Modul N zu dem Modul Q dargestellt ist), während der Entwurfsauswertung ignoriert werden sollen. In einem derartigen Fall würden die Wege zu diesen Modulen (Weg A/C/N/Q in dem Beispiel von Fig. 4 ist ein derartiger Weg) in dem Bericht, der in Tabelle 1 gezeigt ist, nicht aufgelistet werden.
• Der Bericht kann ferner Wege identifizieren, die rekursiv sind, d.h. diese, die in Endlosschleifen resultieren könnten. Der letzte Weg, der in Tabelle 1 aufgelistet ist, ist ein rekursiver Weg, da er sich von dem Modul T bis zu dem Modul U erstreckt und dann von dem Modul U zurück zu dem Modul T eine Schleife bildet. Dieser Weg ist als ein rekursiver Weg durch die Wiederholung des Buchstabens, der das erste Modul in dem rekursiven Weg identifiziert, durch Auslassungen in der Wegauflistung und durch einen Stern statt einer begrenzten Zahl in der Spalte "Weglänge" der Tabelle identifiziert.
• Als weitere Eigenschaft läßt der Bericht beliebige lexikalisch eingeschlossene Module zu, die das Strukturdiagramm aufweist. Ein lexikalisch eingeschlossenes Modul ist tatsächlich ein Teil eines anderen Moduls und trägt daher nicht zur Weglänge bei. Es ist jedoch zweckmäßig, dasselbe in dem Strukturdiagramm darzustellen. In Fig. 4 ist das Modul D beispielsweise ein lexikal eingeschlossenes Modul, welches tatsächlich ein Teil des Moduls A ist. Dies ist in Fig. 4 durch ein stilisiertes Karat oben auf dem Modul D bezeichnet. Lediglich ein Weg weist das Modul D auf, wobei sich dieser Weg von dem Modul A bis D, von dem Modul D bis K und von dem Modul K bis R erstreckt. Es ist gezeigt, daß dieser Weg, welcher der vorletzte Weg in der Tabelle 1 ist, eine Weglänge von Zwei aufweist, da das lexikalisch eingeschlossene Modul D nicht zu der Weglänge beiträgt. Dies ist in Tabelle 1 durch ein Karat zwischen den Buchstaben A und D in der Wegbeschreibung angezeigt.
• Ein weiterer Berichtstyp kann alle übermäßigen Wege und Weglängen auflisten. Bei der Erzeugung dieses Berichts spezifiziert der Softwareingenieur eine Längengrenze, die bei dem Entwurf nicht überschritten werden sollte, wobei der Bericht lediglich diese Wege auflistet, die eine Länge aufweisen, die größer als die spezifizierte ist. Wenn der Softwareingenieur beispielsweise eine maximale Weglänge von Vier für das in Fig. 4 dargestellte Programm spezifiziert hat, würde der Bericht der übermäßigen Weglängen zusammengesetzt sein, wie es in der folgenden Tabelle 2 gezeigt ist: ÜBERMÄßIGE WEGE Weg Weglänge Tabelle 2
• Ein dritter Berichtstyp kann Abschnitte des Entwurfs und des Programms identifizieren, welche der Ingenieur zu optimieren wünschen könnte. Bei der Erzeugung dieses Berichts spezifiziert der Benutzer eine Zahl, die die einzigartige Zahl von Aufrufen eines beliebigen Moduls oder Teilwegs anzeigt. Der Zweck dieser Zahl besteht darin, die Module und Teilwege zu identifizieren, die am häufigsten von anderen Modulen aufgerufen werden. Wenn der Benutzer beispielsweise die Zahl Drei spezifiziert, erzeugt das Entwurfsauswertungswerkzeug 24 einen Bericht, der alle Teilwege identifiziert, die mindestens drei einzigartige aufrufende Module aufweisen. Für das Beispiel, das in Fig. 4 gezeigt ist, würde ein derartiger Bericht aussehen, wie in der folgenden Tabelle 3 gezeigt ist: OPTIMIERUNG Weg # Aufrufe Aufrufende Module Tabelle 3
• Zusätzlich zu Berichten, die auf den Weglängen in dem Strukturierten Entwurf basieren, kann das Auswertungswerkzeug 24 ferner Berichte schaffen, die auf der voraussichtlichen Zeit basieren, die erforderlich sein würde, um bestimmte Aufgaben zu vollenden. In diesem Betriebsmodus weist der Benutzer jedem Modul in der Programmstruktur eine relative Gewichtung zu. Die Gewichtung, die einem Modul zugewiesen ist, ist eine Zahl, die beispielsweise die relative Komplexität des Moduls oder die voraussichtliche Durchführungszeit des Moduls darstellt. Diese Gewichtungen können während der Entwurfsphase 12 des Programms eingegeben und in der Strukturierter-Entwurf-Datenbank 22 als Teil der Modulspezifikation gespeichert werden. Alternativ können die Gewichtungen durch den Benutzer während der Entwurfsauswertungsphase 20 eingegeben und beispielsweise in einer Arbeitsblattdatei 28 gespeichert werden.
• Das Werkzeug 24 wird die Gewichtungen von der Arbeitsblattdatei lesen und die Modulspezifikationen in der Entwurfsdatenbank 22 automatisch aktualisieren. Eine Gewichtung von Eins kann beispielsweise zu einem relativ einfachen Modul gehören, wobei jedem anderen Modul ein Gewichtungswert zugewiesen werden kann, welcher die Komplexität dieses Moduls bezüglich der des einfachen Moduls anzeigt. Somit würde erwartet werden, daß ein Modul mit einer Gewichtung von Drei dreimal länger zur Durchführung braucht, als das einfache Modul mit einer Gewichtung von Eins. Wenn es der Benutzer versäumt, eine Gewichtung für ein gegebenes Modul zu spezifizieren, kann das Werkzeug 24 eine vorgegebene Gewichtung (beispielsweise eine Gewichtung von Eins) einem derartigen Modul zuweisen.
• In diesem Betriebsmodus kann ein Zeitbericht erzeugt werden, welcher jeden Weg mit der Zeitgewichtung desselben identifiziert. Die Zeitgewichtung für einen Weg würde die Summe der Gewichtungen für jedes Modul in dem Weg sein. Als ein Teilsatz dieses Berichts kann der Benutzer abrufen, daß nur die Wege mit einer Zeitgewichtung, die größer als ein spezifizierter Schwellenwert ist, identifiziert werden.
• Als Alternative zum Zuweisen spezieller Gewichtungen für jedes Modul kann der Softwareingenieur jedes Modul identifizieren, als ob es von einem speziellen Typ wäre, und diese Identifikation als Teil der Modulspezifikation in der Strukturierter-Entwurf-Datenbank 22 speichern. Der Benutzer kann ferner eine Datei schaffen, welche eine Liste von Modultypen und eine Verhaltensgewichtung für jeden Typ aufweist. Das Auswertungswerkzeug 24 kann sich dann auf diese Datei beziehen und basierend auf dem Typ des Moduls demselben die geeignete Verhaltensgewichtung zuweisen.
• Zusätzlich zum Gewichten jedes einzelnen Moduls, kann ferner jedem Aufrufweg, der bedingt aktiviert wird (nicht immer aufgerufen wird), eine Wahrscheinlichkeit zugewiesen werden. Bei dem in Fig. 4 dargestellten Beispiel sind die Wege von dem Modul N zu jedem der Module O, P und Q bedingt. Dieser Zustand ist durch das Diamantensymbol an dem Ausgang des Moduls N angezeigt. Für jeden dieser bedingten Wege kann eine Wahrscheinlichkeit der Wahrscheinlichkeit desselben, aufgerufen zu werden, durch den Benutzer zugewiesen werden. Wenn ein Bericht der Wege erzeugt wird, die am häufigsten aufgerufen werden, können die Gewichtungungsinformationen in das erwartete Verhalten des Programms als Faktoren eingefügt werden.
• Ein besonders nützlicher Bericht, der mit dem Entwurfsauswertungswerkzeug der vorliegenden Erfindung erzeugt werden kann, ist ein Verhaltensbericht, welcher Wege identifiziert, die aus dem Standpunkt möglicher Verhaltensprobleme dem Softwareingenieur besonders wichtig sein sollten. Dieser Berichtstyp berücksichtigt sowohl Weglängen als auch Weggewichtungen und weist drei Abschnitte auf, wie es nachfolgend in Tabelle 4 gezeigt ist: ABSTEIGENDE WEGLÄNGEN Weg Länge Schleifen Bedingungen ABSTEIGENDE WEGGEWICHTUNGEN Gewichtung ABSTEIGENDE WEGLÄNGEN UND GEWICHTUNGEN Tabelle 4
• Bei der Erzeugung dieses Berichts spezifiziert der Benutzer, wie viele Wege aufgelistet werden sollen. Diese Menge wird vorzugsweise als ein Prozentsatz von allen Wegen in dem Programm ausgedrückt. Wenn es in einem Programm beispielsweise 40 Wege gibt, und ein Benutzer spezifiziert, daß 10% der Wege aufgelistet werden sollen, wird der Bericht vier Wege auflisten.
• Der erste Abschnitt des Berichts listet in der Reihenfolge absteigender Länge die Wege auf, die die größten Längen aufweisen, bis die gewünschte Anzahl von Wegen aufgelistet ist. Derselbe listet ferner die Anzahl von Schleifen und Bedingungen für jeden Weg auf und sortiert die Wege mit gleicher Länge in absteigender Reihenfolge der Schleifen bzw. Bedingungen.
• Der zweite Abschnitt listet in der Reihenfolge absteigender Weggewichtungen die Wege auf, welche die größten Gewichtungen aufweisen, bis die gewünschte Anzahl von Wegen aufgelistet ist. Wieder können die Anzahl von Schleifen und von Bedingungen als zweites und drittes Sortierkriterium verwendet werden, wenn zwei oder mehr Wege dieselbe Gewichtung aufweisen.
• Der dritte Abschnitt stellt eine Kombination der ersten zwei Abschnitte dar. Sowohl Länge als auch Gewichtung sind aufgelistet. Das Sortieren der Wege in diesem Abschnitt wird in Übereinstimmung mit Kriterien durchgeführt, die durch den Softwareingenieur ausgewählt werden. In Tabelle 4 sind die Wege, die in dem dritten Abschnitt aufgelistet sind, in ansteigender Reihenfolge der Summen ihrer Ordnungspositionen in den ersten zwei Abschnitten aufgelistet.
• Die Ordnungsposition des Wegs A/B/E/H/K/R in dem ersten Abschnitt ist beispielsweise Zwei, während dieselbe in dem zweiten Abschnitt Eins beträgt. Die Ordnungssumme desselben beträgt daher Drei. Auf ähnliche Weise ist die Ordnungsposition des Pfads A/B/E/H/J/L in dem ersten Abschnitt Eins, während dieselbe in dem zweiten Abschnitt Drei beträgt. Die Ordnungssumme desselben beträgt daher Vier, wobei derselbe demgemäß in dem dritten Abschnitt der Tabelle unter dem Weg A/B/E/H/K/R aufgelistet ist.
• Wenn es erwünscht ist, kann der Benutzer entscheiden, ob Wege, welche externe Bibliotheksaufrufe enthalten, wie z.B. das Modul L in dem Beispiel von Fig. 4, bei der Erzeugung des Verhaltensberichts berücksichtigt oder ignoriert werden sollen. Ebenso kann der Benutzer entscheiden, ob asynchron aktivierte Module, wie z.B. das Modul Q in Fig. 4, enthalten sein sollen.
• Als eine weitere Eigenschaft kann das Entwurfsauswertungswerkzeug 24 eine Möglichkeit aufweisen, welche ein Tabellenkalkulationsprogramm 30 aktiviert, um die in der Arbeitsblattdatei 28 enthaltenen Informationen zu verwenden. Ein Beispiel einer derartigen Tabelle ist in Fig. 5 für einen Abschnitt des Programms, dessen Struktur in Fig. 4 gezeigt ist, dargestellt. An der linken Seite des Diagramms ist das Grundmodul A identifiziert. Unmittelbar rechts von der Modulidentifikation ist die Gewichtung, die diesem Modul zugewiesen wurde, aufgelistet. In diesem Fall beträgt die Gewichtung des Grundmoduls Eins. Unter der Gewichtung sind die anderen Module aufgelistet, die von dem Grundmodul aufgerufen werden. Bei dem dargestellten Beispiel sind lediglich die Module B und C aufgelistet. Wieder ist die Gewichtung für jedes dieser Module unmittelbar rechts von der Modulidentifikation gezeigt. Unter der Gewichtung für jedes dieser zwei Module sind weitere Module zusammen mit den zugewiesenen Gewichtungen derselben aufgelistet, welche von diesen Modulen aufgerufen werden können. Für jedes Modul, welches das Endmodul in einem Weg ist, ist die aufsummierte Gewichtung für den Weg bis zu diesem Modul ebenfalls aufgelistet. Somit sind die Gesamtgewichtungen der Wege A/C/M und A/B/F (4,8 bzw. 3,25) ganz rechts in dem Beispiel von Fig. 5 gezeigt.
• Ein Vorteil, der zu der Darstellung dieser Informationen in einer Tabelle gehört, besteht darin, daß der Benutzer in die Lage versetzt wird, hypothetische Situationen zu erzeugen, von welchen er das Gesamtverhalten des Programms einschätzen kann. Insbesondere kann der Benutzer die Gewichtungen der einzelnen Module innerhalb der Tabelle verändern. Wenn die Tabelle neu berechnet wird, wird der Benutzer mit aktualisierten Informationen versehen, die zeigen, wie die neue Modulgewichtung das Gesamtverhalten des Programms beeinflußt. In dieser Hinsicht kann das Werkzeug 24 einen Bericht erzeugen, welcher die ursprüngliche Gewichtung eines Moduls, die neu durch den Benutzer zugewiesene Gewichtung und ein "Delta" oder den Unterschied zwischen den zwei Gewichtungen auflistet. Dieses Delta kann als ein Prozentsatz der ursprünglichen Gewichtung ausgedrückt werden. Der Bericht kann ferner den Prozentsatzunterschied identifizieren, welchen die Gewichtungsänderung bei der Durchführungszeit jedes Wegs zur Folge hat, in welchem das geänderte Modul positioniert ist. Aus diesen Informationen kann der Benutzer bestimmen, ob eine Optimierung eines speziellen Moduls, beispielsweise um die Komplexität desselben zu reduzieren, eine lohnende Anstrengung darstellt. Wenn es erwünscht ist, kann der Benutzer das Auswertungswerkzeug 24 anweisen, die Softwareentwurf-Datenbank 22 mit den überarbeiteten Gewichtungen, die in die Tabelle 30 eingegeben sind, zu aktualisieren.
• Ein allgemeines Strukturdiagramm für die Gesamtoperation des Entwurfsauswertungswerkzeugs 24 ist in Fig. 6 dargestellt. Das Werkzeug beginnt den Betrieb in einer Hauptroutine 32, welche eine Initialisierung und verschiedene weitere Systemverwaltungsarbeiten handhabt und den Gesamtfluß des Programms steuert. Sobald diese allgemeinen Operationen ausgeführt worden sind, verzweigt sich das Programm zum Bauen einer internen Wegstrukturdatei zu einer Routine 34. In diesem Prozeß wird die Strukturierter-Entwurf-Datenbank 22 innerhalb einer weiteren Routine 36 analysiert und es wird eine Datei gebaut, welche alle Wege, die Längen und Gewichtungen derselben und zugeordnete Schleifen- und Bedingungsinformationen beschreibt. Nachdem die interne Datei aufgebaut worden ist, verzweigt das Programm zu einer Routine 38, um Berichte zu erzeugen. Als Teil dieser Funktion liest das Programm die in der internen Datei gespeicherten Daten und formatiert diese Daten, um die entsprechenden Berichte mittels einer Routine 39 zu erzeugen.
• Danach kann das Entwurfsauswertungsprogramm zu der Tabellenkalkulations-Schnittstellenroutine 40 verzweigen. Innerhalb dieser Routine werden wieder die entsprechenden Daten von der internen Datei gelesen (Unterroutine 40A) und eine Arbeitsblattdatei wird gebaut (Unterroutine 40B). Ein geeignetes Tabellenkalkulationsanwendungsprogramm wird dann aufgerufen (Unterroutine 4ºC) und die Tabelle wird angezeigt. Wenn der Benutzer irgendeinen der Gewichtungswerte für das Modul modifiziert, werden die aktualisierten Informationen gelesen (Unterroutine 40D) und verwendet, um die Datenbank 22 zu aktualisieren (Unterroutine 40E). Die aktualisierten Daten werden ferner verwendet, um die Delta-Berichte zu erzeugen (Unterroutine 40F).
• Ein spezielleres Flußdiagramm, welches den Betrieb der Datenbank-Analyseroutine 36 darstellt, ist in Fig. 7 gezeigt. Grundsätzlich verfährt die Auswertung des Entwurfs, der getestet wird, als eine Serie von verschachtelten Schleifen, in denen jeder mögliche Weg in der Struktur des Entwurfs identifiziert und die Länge desselben gemessen wird.
• Am Anfang beginnt das Werkzeug mit einem Startmodul, das durch den Benutzer gewählt wird. Wenn der Benutzer kein Startmodul wählt, startet das Werkzeug mit dem Grundmodul (Modul A in dem Beispiel von Fig. 4). Die Gewichtung des Startmoduls ist gespeichert, wie es durch einen Block 101 in Fig. 7 angezeigt ist. Das Startmodul definiert eine oberste oder erste Modulebene.
• Eine Variable "i" wird verwendet, um beliebige Zweite-Ebene-Module zu identifizieren, welche von dem Startmodul aufgerufen werden. Diese Variable wird zu Beginn gleich Eins gesetzt, wie es durch einen Block 103 gezeigt ist. Ein Ebenenzähler "c" wird verwendet, um zu verfolgen, wieviele Ebenen sich zwischen dem Startmodul und einem Endmodul befinden, wobei diese Variable anfangs ebenfalls zu Eins gesetzt wird, wie es durch einen Block 105 gezeigt ist.
• Bezugnehmend auf die Modulspezifikation, die in der Datenbank 22 gespeichert ist, findet und speichert das Werkzeug 24 die Gewichtung des i-ten Zweite-Ebene-Moduls, welches von dem Grundmodul aufgerufen wird, wie es durch einen Block 107 gezeigt ist. Das Werkzeug findet ferner heraus, ob Dritte- Ebene-Module von dem i-ten Zweite-Ebene-Modul aufgerufen werden, wie es durch einen Entscheidungsblock 109 gezeigt ist. Wenn dies eintritt, wird eine Variable "j" verwendet, um derartige Dritte-Ebene-Module zu identifizieren. Diese Variable ist anfangs zu Eins gesetzt, wie es durch einen Block 111 gezeigt ist, wobei der Ebenenzähler "c" gleich Zwei gesetzt wird, wie es durch einen Block 113 gezeigt ist, um zu zeigen, daß sich zwei Ebenen zwischen dem Startmodul und dem j-ten Dritte-Ebene-Modul befinden. Dann wird die Gewichtung des j-ten Dritte-Ebene-Moduls gespeichert, wie es durch einen Block 115 gezeigt ist.
• Auf ähnliche Weise findet das Werkzeug heraus, ob irgendwelche Vierte-Ebene-Module von dem j-ten Dritte-Ebene-Modul aufgerufen werden, wie es durch einen Entscheidungsblock 117 gezeigt ist. Eine Variable "k" wird verwendet, um derartige Vierte-Ebene-Module zu identifizieren, wobei dieselbe anfänglich zu Eins gesetzt wird, wie es durch einen Block 119 gezeigt ist, während der Ebenenzähler "c" zu Drei gesetzt wird, wie es durch einen Block 121 gezeigt ist. Dann wird die Gewichtung des k-ten Vierte-Ebene-Moduls gespeichert, wie es durch einen Block 123 gezeigt ist.
• Der Prozeß setzt sich mit beliebigen Fünfte-Ebene-Modulen fort, die von dem k-ten Vierte-Ebene-Modul aufgerufen werden, wie es durch einen Entscheidungsblock 125 gezeigt ist, usw..
• Schließlich wird ein Endmodul (ein Modul, welches keine Module niedrigerer Ebene aufruft) erreicht. Wenn dies eintritt, wird eine Beschreibung des Wegs, dem von dem Startmodul zu diesem Endmodul gefolgt wurde, gespeichert. Wenn das Endmodul beispielsweise das i-te Zweite-Ebene-Modul ist, tritt dies als Reaktion auf eine negative Antwort von dem Entscheidungsblock 109 auf (ob irgendwelche Dritte-Ebene-Module von dem Zweite-Ebene-Modul aufgerufen werden), wie es durch einen Block 127 gezeigt ist.
• Auf ähnliche Weise wird die Wegbeschreibung als Reaktion auf eine negative Antwort von dem Entscheidungsblock 117, wie es durch einen Block 129 gezeigt ist, gespeichert, wenn das Endmodul das j-te Dritte-Ebene-Modul ist, während die Wegbeschreibung als Reaktion auf eine negative Antwort von dem Entscheidungsblock 125 gespeichert wird, wie es durch einen Block 131 gezeigt ist, wenn das Endmodul das k-te Vierte- Ebene-Modul ist.
• Die Wegbeschreibung weist den Wert des Ebenenzählers "c" auf, welche die Weglänge, die Identifikation und Gewichtung jedes Moduls in dem Weg, die Summe der Gewichtungen der Module, und beliebige anwendbare Schleifen und Bedingungsinformationen, die den Weg betreffen, anzeigt.
• Nach dem Speichern der Wegbeschreibung kehrt das Werkzeug zu der nächsthöheren Ebene zurück und fährt mit allen weiteren möglichen Modulen fort, auf die von dem Modul, welches das Endmodul aufgerufen hat, zugegriffen werden kann. Dieses Verfahren setzt sich fort, bis alle möglichen Wege identifiziert und ihre Beschreibungen gespeichert sind. Wenn das k-te Vierte-Ebene-Modul beispielsweise ein Endmodul ist, bestimmt das Werkzeug, ob es irgendwelche weiteren Vierte- Ebene-Module gibt, die durch das j-te Dritte-Ebene-Modul aufgerufen werden, wie es durch einen Entscheidungsblock 133 gezeigt ist. Wenn dies zutrifft, wird k inkrementiert, wie es durch einen Block 135 gezeigt ist, und das Werkzeug kehrt zu dem Block 121 zurück.
• Wenn keine weiteren Vierte-Ebene-Module existieren, bestimmt das Werkzeug, ob irgendwelche weiteren Dritte-Ebene-Module durch das i-te Zweite-Ebene-Modul aufgerufen werden, wie es durch einen Entscheidungsblock 137 gezeigt ist. Wenn dies zutrifft, wird j inkrementiert, wie es durch einen Block 139 angezeigt ist, wobei das Werkzeug zu dem Block 113 zurückkehrt. Wenn keine Dritte-Ebene-Module mehr existieren, bestimmt das Werkzeug auf ähnliche Weise, ob irgendwelche weiteren Zweite-Ebene-Module durch das Startmodul aufgerufen werden, wie es durch einen Entscheidungsblock 141 gezeigt ist. Wenn dies zutrifft, wird i inkrementiert, wie es durch einen Block 143 gezeigt ist, und das Werkzeug kehrt zu dem Block 105 zurück. Wenn keine weiteren Module übrig sind, wird die Analyseroutine 36 beendet, wie es durch einen Block 145 gezeigt ist.
• Aus dem Vorhergehenden ist es offensichtlich, daß die vorliegende Erfindung den Softwareingenieur mit einem Werkzeug versieht, um den Wirkungsgrad eines Programmentwurfs und mögliche Verhaltensnachteile früh in dem Entwicklungs-Lebenszyklus des Programms auszuwerten. Indem dem Softwareingenieur diese Art von Informationen in einer derart frühen Stufe geliefert werden, wird dadurch die Notwendigkeit vermieden, Programmcode und Testabschnitte des Programms zu schreiben, die hinterher neu entworfen werden müssen. Ferner können Entwürfe vor dem Codieren optimiert werden, indem der Entwickler in die Lage versetzt wird, mit verschiedenen Verhaltens-Gewichtungen für jedes Modul zu experimentieren und die Wirkung dieser unterschiedlichen Gewichtungen auf das Gesamtverhalten zu messen.
• Das durch die vorliegende Erfindung geschaffene Werkzeug wird besonders wertvoll für einen Softwareingenieur sein, der ein großes und komplexes Softwaresystem entwirft. Ein derartiges System kann eine große Anzahl von Ebenen, viele Module auf jeder Ebene und viele Hunderte von möglichen Wegen unter diesen Modulen aufweisen. Die Struktur vieler derartiger Systeme ist derart komplex, daß sie sich jedem Analyseversuch mittels existierender Möglichkeiten widersetzt. Die vorliegende Erfindung versetzt den Ingenieur in die Lage, einen derartigen Entwurf auszuwerten, potentielle Störungsstellen zu finden und dieselben zu korrigieren, und zwar bevor irgendeine Codierung stattgefunden hat.
• Verwendungen für die vorliegende Erfindung sind nicht auf die Entwicklung von völlig neuen Programmen begrenzt. Dieselbe kann ebenfalls verwendet werden, um potentielle Problembereiche immer dann zu analysieren, wenn eine bestehende Software verbessert wird.
• Für Fachleute ist es offensichtlich, daß die vorliegende Erfindung auf andere Weisen implementiert und in anderen speziellen Formen ausgeführt werden kann, ohne von wesentlichen Charakteristika derselben abzuweichen. Die gegenwärtig offenbarten Ausführungsbeispiele werden daher in jeder Hinsicht illustrativ und nicht restriktiv betrachtet. Der Bereich der Erfindung ist durch die beigefügten Ansprüche und nicht durch die vorhergehende Beschreibung angezeigt, wobei beabsichtigt ist, daß alle Veränderungen, die innerhalb der Bedeutung und dem Bereich von Äquivalenten derselben liegen, in demselben enthalten sind.

Claims (7)

1. Ein Verfahren zum Auswerten des Entwurfs eines Programms während einer Programmentwicklung mittels eines strukturierten Entwurfsverfahrens, bei dem: eine Datenbank (22), die jedes Funktionsmodul in dem Programm und die hierarchischen Beziehungen der Module untereinander identifiziert, erzeugt und gespeichert wird; ein Modul, welches einen Startpunkt für eine durch das Programm auszuführende Aufgabe bildet, identifiziert wird; und ein Bericht (26), der ein Ergebnis der Auswertung liefert, durch ein Entwurfsauswertungswerkzeug (24) bereitgestellt wird, wobei das Verfahren durch das Entwurfsauswertungswerkzeug (24) gekennzeichnet ist, welches die folgenden Schritte durchführt:

- Zugreifen auf die Datenbank (22), um mögliche Wege von dem identifizierten Startpunkt-Modul zu weiteren Modulen in der hierarchischen Beziehung zu identifizieren, denen durch das Programm beim Ausführen der Aufgabe gefolgt werden kann;

- Messen der relativen Längen der verschiedenen möglichen Wege, wobei die Weglänge hinsichtlich der Anzahl von Übergängen in dem Weg von einem anfänglichen Modul zu dem Endmodul definiert ist; und

- Abschätzen von relativen Ausführungszeiten gemäß den relativen Weglängen.

2. Ein Verfahren gemäß Anspruch 1, bei dem das Bestimmen relativer Ausführungszeiten das Zuweisen eines Gewichtungsfaktors zu jedem Modul in den bestimmten Wegen und das Summieren der Gewichtungsfaktoren für alle Module in jedem der bestimmten Wege aufweist.

3. Ein Verfahren gemäß Anspruch 2, bei dem der Schritt des Zuweisens eines Gewichtungsfaktors zu einem Modul das Identifizieren des Moduls, daß dasselbe von einem speziellen Typ ist, das Errichten einer Tabelle, welche jedem Modultyp einen Gewichtungsfaktor zuordnet, und das Zugreifen auf die Tabelle aufweist, um den Gewichtungsfaktor für ein spezielles Modul auf der Basis des Typs desselben zu bestimmen.

4. Ein Verfahren gemäß Anspruch 2, bei dem der Schritt des Zuweisens eines Gewichtungsfaktors zu einem Modul das manuelle Eingeben eines Gewichtungsfaktors für dieses Modul aufweist.

5. Ein Verfahren gemäß den Ansprüchen 2, 3 oder 4, bei dem der Bericht eine Tabelle aufweist, in der ein Benutzer einen Gewichtungsfaktor modifizieren kann, und wodurch er eine Anzeige der Auswirkung erhalten kann, welche ein modifizierter Gewichtungsfaktor auf die geschätzten relativen Ausführungszeiten der bestimmten Wege haben würde.

6. Ein Verfahren gemäß einem beliebigen der vorhergehenden Ansprüche, das ferner folgende Schritte aufweist:

Auswählen einer Schwellenaufrufzahl:

Identifizieren jedes Moduls, das während der Ausführung einer Aufgabe durch eine Zahl von anderen Modulen, die gleich oder größer als die Schwellenaufrufzahl ist, aufgerufen werden kann; und

Erzeugen eines Optimierungsberichts, welcher die identifizierten Module auflistet.

7. Ein Verfahren gemäß Anspruch 6, bei dem der Optimierungsbericht anzeigt, welche Module jedes identifizierte Modul aufrufen können.