DE69636141T2 - Rechnerimplementiertes Verfahren zur Bestimmung eines Minimalcodesets für ein ausführbares Programm in einem Datenverarbeitungssystem - Google Patents

Rechnerimplementiertes Verfahren zur Bestimmung eines Minimalcodesets für ein ausführbares Programm in einem Datenverarbeitungssystem Download PDF

Info

Publication number
DE69636141T2
DE69636141T2 DE69636141T DE69636141T DE69636141T2 DE 69636141 T2 DE69636141 T2 DE 69636141T2 DE 69636141 T DE69636141 T DE 69636141T DE 69636141 T DE69636141 T DE 69636141T DE 69636141 T2 DE69636141 T2 DE 69636141T2
Authority
DE
Germany
Prior art keywords
list
classes
class
application
procedure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69636141T
Other languages
English (en)
Other versions
DE69636141D1 (de
Inventor
Martin Paul Raleigh Nally
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Application granted granted Critical
Publication of DE69636141D1 publication Critical patent/DE69636141D1/de
Publication of DE69636141T2 publication Critical patent/DE69636141T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/61Installation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44557Code layout in executable memory

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)
  • Devices For Executing Special Programs (AREA)

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft Verbesserungen in Datenverarbeitungssystemen und insbesondere einen Prozess (oder Packalgorithmus) zum Ermitteln des zum Ausführen einer Anwendung in einem solchen System erforderlichen Minimalcodesets.
  • HINTERGRUND DER ERFINDUNG
  • Das Interesse an der Verwendung von objektorientierten Sprachen zum Schreiben oder Entwickeln von Softwareanwendungen hat in letzter Zeit zugenommen. Die objektorientierte Technologie weist gegenüber der Technologie mit Prozedursprechen mehrere Vorteile auf, so zum Beispiel die relative leichte Anwendbarkeit, das einfache Vornehmen von Änderungen, die ausgezeichnete Wiederverwendungsmöglichkeit von Komponenten von Anwendung zu Anwendung usw. Objektorientierte Softwareanwendungen werden durch einen Softwareentwickler normalerweise unter Verwendung einer objektorientierten Entwicklungsumgebung entwickelt. Eine objektorientierte Entwicklungsumgebung (wie beispielsweise „VisualAge for Smalltalk" von IBM Corporation) beinhaltet üblicherweise die objektorientierte Sprache, zum Beispiel Smalltalk oder C++, eine Vielzahl von Entwicklungswerkzeugen, zum Beispiel Browser, Versionsverwaltungsfunktionen und Fehlersuchroutinen (debuggers), und einen Satz von wiederverwendbaren objektorientierten Klassen, Komponenten, Teilen und/oder Strukturen, die einem Entwickler für eine Anwendung verschiedene wünschenswerte Funktionen bieten. Der Sprache Smalltalk liegen eine als virtuelle Maschine bekannte Routine, die eine Grundfunktionalität beinhaltet, welche zum Ausführen von fertigen Anwendungen auf einem Computer benötigt wird (und normalerweise mit den Anwendungen verknüpft ist), sowie ein umfangreicher Satz von wiederverwendbaren objektorientierten Klassen, Komponenten, Teilen und Strukturen zugrunde. Ein Entwickler wählt im Grunde Exemplare (Instanzen) gewünschter Klassen (Objekten) aus den verfügbaren Klassen aus und verknüpft diese Klassen, Komponenten, Teile und Strukturen miteinander, um eine Anwendung mit einer gewünschten Funktion zu erzeugen.
  • Ein Aspekt objektorientierter Sprachen besteht darin, dass die Klassen normalerweise abhängig voneinander sind und eine Eigenschaft aufweisen können, die als Vererbung (inheritance) bekannt ist. Ferner wird eine Funktion in Form desjenigen Teils eines Objekts bereitgestellt, das als Verfahren bekannt ist. Somit kann ein Verfahren für ein bestimmtes Objekt auf ein Verfahren in einem anderen Objekt oder einer anderen Klasse zurückgreifen, um die Funktion bereitzustellen.
  • Diese Besonderheit der objektorientierten Sprachen stellt eine Herausforderung an die Leistungssteigerung von Packprogrammen dar.
  • Das Packen von fertigen Anwendungen war bisher keinen strengen Regeln unterworfen. Um sicherzugehen, werden Anwendungen mit kompletten Bibliotheken von nur geringfügig voneinander verschiedenen Standardklassen versehen und zusammen mit der zugrunde liegenden Routine gepackt, um eine Laufzeitversion der Anwendung zu erzeugen, die durch die Rechner der Endbenutzer ausgeführt werden kann. Ein Nachteil der objektorientierten Sprachen bestand bisher darin, dass es bei Packalgorithmen nach dem Stand der Technik zur Sicherstellung einer ordnungsgemäßen Ausführung der Anwendung nicht sehr gut möglich war zu unterscheiden, auf welche Klassen der Bibliotheken von wiederverwendbaren Klassen in der Entwicklungsumgebung sie sich beziehen. Demzufolge waren die gepackten objektorientierten Anwendungen ziemlich groß und nahmen auf dem Rechner des Endbenutzers viel Speicherplatz in Anspruch. Außerdem kann der relativ große Umfang der Anwendungen bei ihrer Ausführung zu einer geringeren Verarbeitungsgeschwindigkeit führen, als es wünschenswert ist.
  • Somit besteht ein Bedarf an einem Packalgorithmus zur Verwendung in Werkzeugen zur Anwendungsentwicklung, der die in gepackte Anwendungen einzubindenden Klassen mit größerer Genauigkeit aus der Entwicklungsumgebung auswählt, damit die Speicheranforderungen verringert und die Leistung gesteigert wird.
  • In der US-Patentschrift US 4 330 822 wird ein Verfahren zum Verknüpfen von vorkompilierten Teilroutinen beschrieben, um einen kompletten Objektcode für eine Hostrechnerprozedur zu erzeugen. Jede der Teilroutinen und die Hostrechnerprozedur sind mit einem Segmentwörterbuch oder einer Liste von Teilroutinen ausgestattet, welche die Routine benötigt. Das System und das Verfahren sind insofern rekursiv, als das System das Segmentwörterbuch einer Routine durchsucht und sich wieder für jede darin aufgefundene Routine selbst aufruft.
  • BESCHREIBUNG DER ERFINDUNG
  • Zur Lösung der obigen Aufgaben wird gemäß der vorliegenden Erfindung ein Prozess nach dem Hauptanspruch 1 bereitgestellt.
  • Der Prozess der vorliegenden Erfindung bietet einen verbesserten Packalgorithmus, der die Speicheranforderungen von Anwendungen verringert und zur Leistungssteigerung von Anwendungen führt. In Umgebungen zur Anwendungsentwicklung brauchen nur diejenigen Verfahren und Klassen einbezogen zu werden, die zur Ausführung der Anwendung erforderlich sind.
  • Im Folgenden wird die vorliegende Erfindung unter Bezug auf die beiliegenden Zeichnungen beschrieben, in welchen gleiche Bezugsnummern stets dieselben Elemente bezeichnen.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Blockschaltbild einer repräsentativen Hardwareumgebung, in welcher die vorliegende Erfindung angewendet werden kann;
  • 2 ist ein Schaubild der Architektur einer objektorientierten Umgebung zur Anwendungsentwicklung;
  • 3 stellt ein objektorientiertes Objekt dar;
  • 4 ist ein Schaubild eines typischen hierarchischen Beziehung zwischen entsprechenden Klasseen einer objektorientierten Sprache; und
  • 5 ist ein Flussdiagramm, welches die Logikschritte eines Prozesses gemäß der vorliegenden Erfindung darstellt.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Die vorliegende Erfindung kann in ihrer beschriebenen Form in einer Vielfalt von objektorientierten Entwicklungssprachen eingesetzt werden, zum Beispiel in Smalltalk, C++, ScriptX usw. 1 zeigt eine repräsentative Hardwareumgebung, in welcher die vorliegende Erfindung realisiert werden kann. Die Umgebung von 1 ist für einen normalen Einzelbenutzer eines Arbeitsplatzrechners repräsentativ, zum Beispiel eines Personal Computers und der zugehörigen Peripherie. Die Umgebung beinhaltet einen Mikroprozessor 10 und einen Bus 12, der den Mikroprozessor 10 und die Komponenten des Arbeitsplatzrechners gemäß bekannten technischen Verfahren miteinander verbindet und die Kommunikation zwischen ihnen herstellt. Der Arbeitsplatzrechner beinhaltet üblicherweise einen Benutzerschnittstellenadapter 14, der den Mikroprozessor 10 über den Bus 12 mit einer oder mehreren Schnittstelleneinheiten verbindet, zum Beispiel einer Tastatur 16, einer Maus 18 und/oder anderen Schnittstelleneinheiten 20, bei denen es sich beliebige Benutzerschnittstelleneinheiten handeln kann, zum Beispiel einen berührungsempfindlichen Bildschirm (touchscreen), ein digitales Stifteingabegerät usw. Der Bus 12 verbindet über einen Bildschirmadapter 24 auch eine Anzeigevorrichtung 22, zum Beispiel einen LCD-Bildschirm oder -Monitor mit dem Mikroprozessor 10. Der Bus 12 verbindet den Mikroprozessor 10 auch mit dem Speicher 26, bei dem es sich um einen ROM, einen RAM usw. handeln kann.
  • Der Softwareprogrammiercode, welcher die vorliegende Erfindung nutzt, ist üblicherweise im Speicher 26 der Umgebung des eigenständigen Arbeitsplatzrechners gespeichert. In einer Client-/Serverumgebung kann das Softwareprogramm im Speicher des Server gespeichert sein. Der Programmcode der Software kann auf einem aus einer Vielfalt von bekannten Medien gespeichert sein, die in einem Datenverarbeitungssystem verwendet werden, zum Beispiel einer Diskette oder einer CD-ROM. Der Programmcode der Software kann entweder auf solchen Medien oder vom Speicher eines Computersystems über ein beliebiges Netzwerk an Benutzer anderer Computersysteme verteilt werden, damit die Benutzer solcher anderen Computersysteme davon Gebrauch machen können. Solche Techniken und Verfahren zum Speichern von Softwarecode auf physischen Medien oder zum verteilen von Softwarecode über Netzwerke sind wohlbekannt und werden im Folgenden nicht weiter erörtert.
  • Im Folgenden wird die vorliegende Erfindung in ihrer bevorzugten Ausführungsart beschrieben, welche Teil einer Smalltalk-Entwicklungsumgebung ist. Die Smalltalk-Entwicklungsumgebung kann auf einer Vielzahl von Verknüpfungen von Betriebssystemen und Hardware betrieben werden und wird unabhängig von einem bestimmten Betriebssystem und unabhängig von einer bestimmten Hardware beschrieben. Smalltalk ist eine dynamische objektorientierte Sprache und wird als rein objektorientierte Sprache bezeichnet, da sie alle Grunddefinitionen für eine objektorientierte Sprache erfüllt, zum Beispiel Vererbung, Polymorphie usw. Diese Begriffe werden im Folgenden nicht erörtert. Andere objektorientierte Sprachen wie beispielsweise C++ weisen eine etwas andere Architektur auf. Bei den meisten anderen objektorientierten Sprachen tritt jedoch dasselbe hier beschriebene Packproblem auf und die hier beschriebene Lösung kann auch auf diese anderen objektorientierten Sprachen direkt angewendet werden.
  • 2 zeigt die Grundarchitektur einer objektorientierten Smalltalk-Entwicklungsumgebung wie beispielsweise VisualAge for Smalltalk von IBM. Die objektorientierte Entwicklungsumgebung 40 selbst ist eine Anwendung, die auf einem zugrunde liegenden Betriebssystem 42 läuft. Der als virtuelle Maschine 44 bezeichnete Teil der Entwicklungsumgebung 40 arbeitet mit dem Betriebssystem 42 zusammen. Die Smalltalk-Entwicklungsumgebung ist hierarchisch aufgebaut, wobei ein Abbildungsteil 46 der Entwicklungsumgebung 40 die Hierarchien der in die virtuelle Maschine 44 eingebundenen Klassen fortführt und als logisch oberhalb der virtuellen Maschine 44 laufend angesehen werden kann. Der Abbildungsteil 46 ist derjenige Teil der Entwicklungsumgebung 40, mit welchem ein Entwickler in Verbindung tritt, um eine objektorientierte Anwendung zu entwickeln. Der Abbildungsteil 46 der Entwicklungsumgebung 40 beinhaltet eine Vielfalt von Klassen innerhalb verschiedener Hierarchien, welche Funktionen auf unterschiedlichen Ebenen bereitstellen. Auf einer oberen Ebene kann ein ganzer Satz von Klassen eine Struktur umfassen, die dem Entwickler eine im Wesentlichen vollständige gewünschte Funktion bietet, die ein Entwickler in die gerade in der Entwicklung befindliche Anwendung überführen kann. Andererseits kann die Funktion durch die Entwicklungsumgebung nicht in einer sehr elegant gepackten Form als Rahmen bereitgestellt werden, sodass der Entwickler Klassen auf relativ niedriger Ebene oder Einzelklassen miteinander verknüpfen oder neue Klassen erzeugen muss, um für die gerade in der Entwicklung befindliche Anwendung die gewünschte Funktion zu erzeugen.
  • Der Abbildungsteil 46 beinhaltet auch Entwicklungswerkzeuge für die Anwendung, die in unterschiedlichen Umgebungen verschieden sind. Die Werkzeuge können einen Klassenbrowser zum Suchen nach Klassen und Verfahren, Versionsverwaltungssysteme zum Ermöglichen einer schrittweisen Entwicklung und zum Speichern der gerade in der Entwicklung befindlichen Anwendungen, Fehlersuchroutinen zur Fehlersuche in den mittels der Entwicklungsumgebung 40 erzeugten Anwendungen usw. beinhalten. Die Entwicklungsumgebung beinhaltet auch einen Smalltalk-Compiler, der Teile der Anwendung verknüpft und kompiliert. Da Smalltalk eine übersetzte Sprache ist, bleiben Teile der Anwendung in Byteform codiert, die während der Ausführung durch die Laufzeitroutine übersetzt werden.
  • 3 ist eine Darstellung eines Objekts 50 nach dem Industriestandard. Die Verfahren 52 des Objekts 50 stellen eine Funktion bereit, während ein Datenteil 54 auf das Objekt 50 bezogene Daten enthält. Ein Objekt ist eine Verkörperung einer Klasse aus der Klassenhierarchie, die ein Entwickler zur Verwendung in einer Anwendung ausgewählt hat. Dieselbe Klasse kann in einer Anwendung mehrmals verwendet werden.
  • 4 zeigt eine Hierarchie 60 von Klassen 62. Objektorientierte Hierarchien bedienen sich der Kategorien Superklasse und Unterklasse. Eine Klasse vererbt alle Variablen und Verfahren von Klassen, die in der Klassenhierarchie über ihr stehen (Superklassen). Die übernehmende Klasse wird als Unterklasse in Bezug auf ihre Superklassen bezeichnet.
  • Angesichts dieser Architektur sind Packalgorithmen nach dem Stand der Technik beim Packen relativ zurückhaltend vorgegangen. Algorithmen nach dem Stand der Technik gehen eher willkürlich vor, wenn es darum geht, welche Klassen sie beim Packen von Anwendungen einbeziehen. Zwar werden bei dem Ansatz die notwendigen Klassen nur selten nicht berücksichtigt, aber das Bestreben, unbedingt sichergehen zu wollen, führt zu übermäßig großen Anwendungen, damit zu größerem Speicherbedarf und mitunter zu nicht optimaler Leistung.
  • Wenn ein Entwickler beim Verfahren nach dem Stand der Technik mit der Entwicklung einer Anwendung in der Entwicklungsumgebung fertig ist, führt er die Packfunktion im Rahmen der Entwicklungsumgebung aus. Der Packalgorithmus ermittelt, welche Klassen in die Laufzeitroutine der ausführbaren Anwendung einbezogen werden sollen. Im Folgenden wie der Packalgorithmus der vorliegenden Erfindung anhand des Flussdiagramms von 5 beschrieben.
  • Der Packalgorithmus der vorliegenden Erfindung analysiert den Code in der Anwendung und deren zugehörigen wiederverwendbaren Codebibliotheken, um daraus einen minimalen Codeteilset zu ermitteln, der für die Ausführung der Anwendung erforderlich ist. Der Algorithmus wird beim Schritt des Verbindens oder Packens verwendet und ermittelt einen definierten minimalen Satz von Klassen und/oder Verfahren, die für die Ausführung der Anwendung erforderlich sind. Der definierte minimale Satz von Klassen und Verfahren wird in der folgenden Beschreibung als „benötigte Klassen" und „benötigte Verfahren" bezeichnet.
  • Die vorliegende Erfindung nutzt die Tatsache, dass eine objektorientierte Anwendung so ausgeführt wird, dass die Exemplare der Klassen (Objekte) einander Nachrichten zusenden. Dadurch stehen viele der benötigten Klassen und Verfahren untereinander in Wechselbeziehung. Die gepackte Anwendung beinhaltet die benötigten Klassen und Verfahren aus der Entwicklungsumgebung, welche sich auf die virtuelle Maschine, den Abbildungsteil und Klassenbibliotheken sowie Code aus der virtuellen Maschine erstrecken, der zum Ausführen der Anwendung während der Laufzeit erforderlich ist. Der zum Ausführen benötigte Code aus der virtuellen Maschine bleibt üblicherweise für alle Smalltalk-Anwendungen unverändert.
  • Je nach Ausführung und Sprache muss durch den Entwickler möglicherweise ein einleitendes „Startverfahren" aus dem Abbildungsteil der zu packenden Anwendung definiert werden. Vom Startverfahren aus durchsucht der Algorithmus alle Bezüge auf Klassen und andere Verfahren in der Anwendung und den wiederverwendbaren Klassenbibliotheken, um den Satz der benötigten Verfahren und Klassen zu ermitteln.
  • Wenn ein Entwickler mit dem Entwickeln der Anwendung fertig ist, gibt er daher einen Befehl an die Entwicklungsumgebung ein, um das Packen auszulösen (Schritt 100). Anschließend erzeugt das Programm eine Anzahl Variablen, einschließlich eines Satzes Benötigte Verfahren, eines Satzes Benötigte Klassen, eines Satzes Bekannte Verfahren und eines Verzeichnisses Prüfverfahren. Alle diese Elemente sind zu Anfang leer (Schritt 104). Da der Algorithmus ermittelt, dass Verfahren und Klassen aus der Entwicklungsumgebung für die Ausführung der Anwendung erforderlich sind, werden diese in den Satz Benötigte Verfahren bzw. den Satz Benötigte Klassen aufgenommen. Anschließend wird die Anwendung nur mit den in diesen Sätzen definierten Verfahren und Klassen gepackt. Die im Satz Bekannte Verfahren enthaltenen Verfahren werden in den Satz Benötigte Verfahren aufgenommen (wenn sie noch nicht darin enthalten sein sollten) und gemäß dem Algorithmus verarbeitet, um Klassen und andere Verfahren zu ermitteln, die ebenfalls erforderlich sind und/oder selbst verarbeitet werden müssen, um andere benötigte Klassen und Verfahren zu ermitteln. Das Verzeichnis Prüfverfahren wird zur Ermittlung benötigter Verfahren herangezogen. Im Folgenden wird erörtert, dass der Algorithmus auch andere Variablen verwendet.
  • In den Satz Bekannte Verfahren werden ein Startverfahren oder durch einen Benutzer oder das Programm selbst in einer automatischen Abfrage ermittelte Verfahren aufgenommen (Schritt 106). Gemäß der obigen Erörterung ist in Smalltalk bei jeder Anwendung zum Ausführen des Anwendungscodes ein bekannter Teil der virtuellen Maschine und des Abbildungsteils erforderlich. Im Allgemeinen sind die zum Ausführen der Laufzeitanwendung benötigten Verfahren und Klassen bekannt. Daher werden die benötigten Laufzeitverfahren in den Satz Bekannte Verfahren (Schritt 108) und die für die Laufzeitausführung benötigten Klassen in den Satz Benötigte Klassen aufgenommen (Schritt 110).
  • In manchen Fällen sind bestimmte vom Anwendungscode benötigte Klassen im Rahmen der Entwicklungsumgebung der Anwendung selbst nicht vorhanden und können nicht aus dem Namen eines Verfahrens ermittelt werden. Solche Klassen können zum Beispiel in einem Festspeicher vorliegen, den die Anwendung während der Ausführung lesen kann. Ohne einen bestimmten Verweis auf die Verfahren im Festspeicher sucht der Algorithmus jedoch nicht nach Verfahren oder Klassen und kann sie somit nicht für das Packen ermitteln. Daher werden zu diesem Zeitpunkt alle solchen benötigten Klassen in den Satz Benötigte Klassen aufgenommen (Schritt 112). In den meisten Fällen gibt der Anwendungsentwickler den Speicherplatz dieser Klassen an; während des Packschrittes kann jedoch eine automatische Abfrage durchgeführt werden, sodass der Speicherplatz solcher Klassen ermittelt werden kann und diese automatisch in den Satz Benötigte Klassen aufgenommen werden.
  • Der Algorithmus geht bei der Suche nach dem definierten minimalen Satz von Klassen und Verfahren vom Inhalt des Satzes Bekannte Verfahren aus. Wenn schließlich in Schritt 114 ermittelt wird, dass der Satz Bekannte Verfahren leer ist, wird der definierte minimale Satz von Klassen und Verfahren festgelegt, und die Anwendung kann allein unter Einbeziehung der Verfahren und Klassen aus dem Satz Benötigte Verfahren und dem Satz Benötigte Klassen gepackt werden (Schritt 116). Wenn jedoch zu Anfang in Schritt 106 durch den Benutzer oder automatisch Startverfahren in den Satz Bekannte Verfahren aufgenommen worden sind, ist der Satz Bekannte Verfahren nicht leer, und die Verarbeitung geht weiter zu Schritt 118. In Schritt 118 wird aus den Verfahren im Satz Bekannte Verfahren ein Verfahren ausgewählt und in diesem Satz gelöscht. Das Verfahren kann aus dem Satz Bekannte Verfahren entweder nach dem Zufallsprinzip oder als erstes darin eingetragenes Verfahren ausgewählt werden. Dann wird der Satz Benötigte Verfahren geprüft, um zu ermitteln, ob dieser bereits das ausgewählte Verfahren enthält (Schritt 120). Wenn dies der Fall ist, geht die Verarbeitung wieder zurück zu Schritt 114. Wenn in Schritt 120 ermittelt wird, dass das ausgewählte Verfahren noch nicht im Satz Benötigte Verfahren enthalten ist, geht die Verarbeitung weiter zu Schritt 122, wo das ausgewählte Verfahren in den Satz Benötigte Verfahren aufgenommen wird. Als Nächstes wird eine Liste aller Verfahren erzeugt, die durch das ausgewählte Verfahren aufgerufen werden können (Schritt 124). Entsprechend den Eigenschaften von Smalltalk sendet ein typisches Verfahren Nachrichten an ein oder mehrere andere Verfahren, um die Verarbeitung während der Ausführung durchzuführen. Die in Schritt 124 erzeugte Liste besteht aus diesen anderen Verfahren. In den Fällen, da das ausgewählte Verfahren kein anderes Verfahren aufruft oder sich nach der Verarbeitung der gesamten Liste der Verfahren in Schritt 126 zeigt, dass die Liste leer ist, springt die Verarbeitung zu Schritt 140. Solange in Schritt 126 jedoch noch nicht ermittelt ist, dass die Liste wirklich leer ist, wird das erste oder nächste Verfahren in der Liste einer Variablen Benanntes Verfahren zugewiesen und aus der Liste entfernt (Schritt 128). Dann wird in Schritt 130 ermittelt, ob der Satz Benötigte Klassen schon die Klasse enthält, mit der das in der Variablen Benanntes Verfahren enthaltene Verfahren arbeitet. Wenn dies der Fall ist, wird das benannte Verfahren in den Satz Bekannte Verfahren aufgenommen und aus der Variablen Benanntes Verfahren entfernt (Schritt 138). Dann geht die Verarbeitung zurück zu Schritt 126, um das nächste Verfahren in der Liste zu verarbeiten, falls noch ein Verfahren enthalten sein sollte.
  • Wenn in Schritt 130 ermittelt wird, dass der Satz Benötigte Klassen die Klasse, die das benannte Verfahren ausführt, nicht enthält, wird anschließend ermittelt, ob das Verzeichnis Prüfverfahren einen Eintrag enthält, welcher der ausführenden Klasse entspricht (Schritt 132). Wenn in Schritt 132 ermittelt wird, dass es keinen solchen Eintrag gibt, wird in Schritt 134 für die ausführende Klasse ein leerer Satz in das Verzeichnis Prüfverfahren aufgenommen. Wenn in Schritt 132 ermittelt wird, dass es für die ausführende Klasse wirklich einen Eintrag gibt, oder nach dem Erzeugen eines Eintrags für die ausführende Klasse in Schritt 134 wird das benannte Verfahren in den Eintrag des Verzeichnisses Prüfverfahren für die ausführende Klasse aufgenommen (Schritt 136). Das benannte Verfahren wird aus der Variablen entfernt und die Verarbeitung geht wieder zurück zu Schritt 126, um die restlichen Verfahren in der Liste zu verarbeiten, falls sich noch welche darin befinden sollten.
  • Wenn in Schritt 126 ermittelt wird, dass die Liste leer ist, geht die Verarbeitung weiter zu Schritt 140, in welchem eine Liste aller durch das ausgewählte Verfahren (in Schritt 118) benannten Klassen erzeugt wird. In Smalltalk kann ein Verfahren nicht nur andere Verfahren (die durch die Schritte 124 bis 138 verarbeitet werden), sondern auch eine Anzahl von Klassen aufrufen. Die im Folgenden beschriebene Verarbeitung ermittelt diese benannten Klassen und ihre Eltern- oder Superklassen, die noch nicht in den Satz Benötigte Klassen aufgenommen worden sind.
  • Zuerst wird in Schritt 142 ermittelt, ob das ausgewählte Verfahren irgendwelche Klassen aufruft (oder ob die Liste durch die Verarbeitung inzwischen leer ist). Wenn dies der Fall ist, geht die Verarbeitung zurück zu Schritt 114, um das nächste Verfahren im Satz Bekannte Verfahren zu verarbeiten. Wenn die Liste einen Aufruf für mindestens eine Klasse enthält, wird eine der Klassen in der Liste einer Variablen Benannte Klasse zugewiesen und aus der Liste entfernt (Schritt 144). Als Nächstes wird die Variable Benannte Klasse aktualisiert, damit sie die benannte Klasse und alle ihrer Superklassen enthält. Das Verfahren zur Ermittlung von Superklassen für eine bestimmte Klasse ist wohlbekannt und braucht hier nicht erörtert zu werden.
  • Dann werden die in der Variablen Benannte Klasse aufgeführten Klassen in den Schritten 148 bis 160 verarbeitet. Nach der Verarbeitung in den Schritten 150 bis 160 ist die Liste leer, und die Verarbeitung geht von Schritt 148 wieder zurück zu Schritt 142. Während die Liste der Klassen in der Variablen Benannte Klasse immer noch Klassen enthält, geht die Verarbeitung weiter zu Schritt 150, in welchem das nächste Element oder die nächste Klasse in der Variablen Benannte Klasse einer Variablen aBenannte Klasse zugewiesen und aus der Variablen Benannte Klasse entfernt wird (Schritt 150). Dann wird in Schritt 152 ermittelt, ob die Klasse in der Variablen aBenannte Klasse bereits im Satz Benötigte Klassen enthalten ist. Wenn dies der Fall ist, geht die Verarbeitung wieder zurück zu Schritt 148, um die nächste Klasse in der Variablen Benannte Klasse zu verarbeiten, falls noch eine darin enthalten sein sollte. Wenn in Schritt 152 ermittelt wird, dass die Klasse noch nicht im Satz Benötigte Klassen enthalten ist, wird die Klasse in den Satz Benötigte Klassen aufgenommen (Schritt 154). Dann wird in Schritt 156 ermittelt, ob es für die Klasse in der Variablen aBenannte Klasse im Verzeichnis Prüfverfahren einen Eintrag gibt (Schritt 156). Wenn es keinen solchen Eintrag gibt, geht die Verarbeitung wieder zurück zu Schritt 148. Wenn in Schritt 156 ermittelt wird, dass es im Verzeichnis Prüfverfahren wirklich einen solchen Eintrag gibt, geht die Verarbeitung weiter zu Schritt 158, wo alle Verfahren im entsprechenden Eintrag im Verzeichnis Prüfverfahren in den Satz Bekannte Verfahren aufgenommen werden. Der Eintrag, welcher der Klasse in der Variablen aBenannte Klasse und ihren Verfahren entspricht, wird dann aus dem Verzeichnis Prüfverfahren und die Klasse aus der Variablen aBenannte Klasse entfernt (Schritt 160). Dann geht die Verarbeitung wieder zurück zu Schritt 148, um noch verbliebene Klassen in der Variablen Benannte Klasse zu verarbeiten.
  • Wenn in Schritt 148 ermittelt wird, dass in der Variablen Benannte Klasse keine Klassen mehr enthalten sind, geht die Verarbeitung wieder zurück zu Schritt 142, um die verbliebenen Klassen in der Liste der durch das ausgewählte Verfahren aufgerufenen Klassen zu verarbeiten. Wenn in Schritt 142 ermittelt wird, dass die Liste leer ist, geht die Verarbeitung wieder zurück zu Schritt 114, um die Verarbeitung für das nächste Verfahren im Satz Bekannte Verfahren fortzusetzen. Wenn die Verarbeitung wieder zu Schritt 114 zurück geht und im Satz Bekannte Verfahren keine weiteren Verfahren enthalten sind, hat der Algorithmus den benötigten Minimalsatz an Klassen und Verfahren ermittelt. Diese Klassen und Verfahren werden in den Satz Benötigte Klassen bzw. den Satz Benötigte Verfahren eingetragen. Dann wird die Anwendung in Schritt 116 gemäß bekannten verfahren so gepackt, dass in die gepackte Anwendung nur diejenigen Verfahren und Klassen einbezogen sind, die im Satz Benötigte Verfahren und im Satz Benötigte Klassen enthalten sind. Die speziellen Verfahrensweisen zum Packen einer Anwendung werden im vorliegenden Dokument nicht erörtert, da sie wohlbekannt sind und in der Technik gegenwärtig verwendet werden.
  • Obwohl der Algorithmus speziell für Smalltalk beschrieben wurde, kann er ganz allgemein auf den Schritt des Packens in anderen Sprachen angewendet werden, in welchen Prozeduren oder Routinen durch ihren Namen aufgerufen werden. Es ist zwar klar, dass der Algorithmus auf andere objektorientierte Sprachen, wie beispielsweise C++ und ScriptX, angewendet werden kann, jedoch kann er auch auf das Packen von Codeverzeichnissen in C oder Ähnliches angewendet werden.

Claims (6)

  1. Computerausführbarer Prozess zum Ermitteln eines Codesets aus einer Entwicklungsumgebung, das zum Ausführen einer Anwendung benötigt wird, wobei der Prozess Folgendes umfasst: Aussuchen eines zum Ausführen der Anwendung benötigten Verfahrens; Eintragen des Verfahrens in eine Liste bekannter Verfahren; Auswählen eines Verfahrens aus der Liste der bekannten Verfahren und Löschen des ausgewählten Verfahrens aus der Liste der bekannten Verfahren; Ermitteln, ob das ausgewählte Verfahren in einer Liste benötigter verfahren enthalten ist und, wenn dies der Fall ist, Wiederholen des Auswahlschrittes; Eintragen des ausgewählten Verfahrens in die Liste der benötigten Verfahren und Erzeugen einer Liste von Verfahren, welche durch das ausgewählte Verfahren benannt werden; Ermitteln für jedes benannte Verfahren, ob sich in einer Liste benötigter Klassen eine Ausführungsklasse befindet; Eintragen jedes benannten Verfahrens in die Liste der bekannten Verfahren, wenn ermittelt wird, dass sich seine Ausführungsklasse nicht in der Liste der benötigten Klassen befindet; Suchen nach einem Eintrag in einer Liste von Prüfverfahren, der jeder Ausführungsklasse entspricht, wenn ermittelt wird, dass die Ausführungsklasse eine benötigte Klasse ist, Erzeugen eines Eintrags in der Liste der Prüfverfahren, wenn es keinen Eintrag gibt, und Hinzufügen des Ausführungsverfahrens zum Eintrag für seine Ausführungsklasse in der Liste der Prüfverfahren; Erzeugen einer Liste erster Klassen für Klassen, die durch das ausgewählte Verfahren benannt wurden; Erzeugen einer Liste zweiter Klassen, welche die benannte Klasse und alle Superklassen der benannten Klasse enthält, für jede in der Liste erster Klassen benannte Klasse; Ermitteln für jede Klasse in der Liste zweiter Klassen, ob die Klasse in der Liste der benötigten Klassen enthalten ist, und wenn dies nicht der Fall ist, Eintragen der Klasse in die Liste der benötigten Klassen, Suchen nach einem Eintrag, welcher der Klasse in der Liste der Prüfverfahren entspricht, und wenn ein Eintrag vorhanden ist, Eintragen jedes im Eintrag enthaltenen Verfahrens in die Liste der bekannten Verfahren und Löschen des Eintrags aus der Liste der Prüfverfahren; und bei Bedarf Wiederholen der Schritte beginnend mit dem Auswahlschritt, bis die Liste der bekannten Verfahren leer ist.
  2. Prozess nach Anspruch 1, bei welchem der Schritt des Aussuchens eines Verfahrens einem Benutzer das Aussuchen eines Verfahren gestattet, welches zum Ausführen der Anwendung benötigt wird.
  3. Prozess nach Anspruch 1, welcher das Abfragen einer Komponente der Anwendung umfasst, damit diese sich selbst erkennen kann, und Verwenden der erkannten Komponente als das zur Ausführung der Anwendung benötigte Verfahren.
  4. Verfahren nach einem der vorangehenden Ansprüche, bei welchem die Anwendung eine im Entwicklungsprozess befindliche objektorientierte Anwendung ist und das Verfahren ferner das Packen der Anwendung in der Weise umfasst, dass diese nur das zum Ausführen der Anwendung benötigte Verfahren und die erkannten Verfahren und Klassen enthält.
  5. Prozess nach Anspruch 4, bei welchem sich in der gepackten Anwendung nur ein Exemplar der erkannten Verfahren und Klassen befindet.
  6. Verfahren nach Anspruch 4 oder Anspruch 5, welches ferner das Erkennen gemeinsamer Verfahren und Klassen umfasst, die zum Ausführen einer beliebigen Anwendung benötigt werden.
DE69636141T 1995-12-21 1996-12-13 Rechnerimplementiertes Verfahren zur Bestimmung eines Minimalcodesets für ein ausführbares Programm in einem Datenverarbeitungssystem Expired - Lifetime DE69636141T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US576730 1995-12-21
US08/576,730 US6526565B1 (en) 1995-12-21 1995-12-21 Packaging algorithm for providing object oriented applications having reduced footprints

Publications (2)

Publication Number Publication Date
DE69636141D1 DE69636141D1 (de) 2006-06-22
DE69636141T2 true DE69636141T2 (de) 2006-12-21

Family

ID=24305742

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69636141T Expired - Lifetime DE69636141T2 (de) 1995-12-21 1996-12-13 Rechnerimplementiertes Verfahren zur Bestimmung eines Minimalcodesets für ein ausführbares Programm in einem Datenverarbeitungssystem

Country Status (4)

Country Link
US (1) US6526565B1 (de)
EP (1) EP0784264B1 (de)
JP (1) JPH09204300A (de)
DE (1) DE69636141T2 (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69714752C5 (de) * 1996-10-25 2015-08-13 Gemalto Sa Verwendung einer hohen programmiersprache in einem mikrokontroller
US8079086B1 (en) 1997-11-06 2011-12-13 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
US7058822B2 (en) 2000-03-30 2006-06-06 Finjan Software, Ltd. Malicious mobile code runtime monitoring system and methods
US9219755B2 (en) 1996-11-08 2015-12-22 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
US6199196B1 (en) * 1998-03-20 2001-03-06 Sun Microsystems, Inc. Methods and apparatus for linking a program for remote execution
US6658492B1 (en) * 1998-03-20 2003-12-02 Sun Microsystems, Inc. System and method for reducing the footprint of preloaded classes
US6493870B1 (en) * 1998-03-20 2002-12-10 Sun Microsystems, Inc. Methods and apparatus for packaging a program for remote execution
US6526571B1 (en) * 1999-03-16 2003-02-25 International Business Machines Corporation Method for identifying calls in java packages whose targets are guaranteed to belong to the same package
US7089242B1 (en) * 2000-02-29 2006-08-08 International Business Machines Corporation Method, system, program, and data structure for controlling access to sensitive functions
US7036113B1 (en) * 2000-10-26 2006-04-25 International Business Machines Corporation Detection of resource exceptions
KR100426312B1 (ko) 2001-12-28 2004-04-08 한국전자통신연구원 컴포넌트 기반 소프트웨어 개발 시스템의 컴포넌트식별장치 및 그 방법과 이에 관련된 프로그램의 기록매체
US9378002B2 (en) * 2006-12-22 2016-06-28 Core Wireless Licensing S.A.R.L. System, method, apparatus and computer program product for providing memory footprint reduction
DE112009005351T8 (de) * 2009-11-09 2013-03-28 Mitsubishi Electric Corporation Softwarebibliothek-Rekonstruktionsvorrichtung, Softwarebibliothek-Rekonstruktionsverfahren und Navigationsvorrichtung, die dieses Softwarebibliothek-Rekonstruktionsverfahren verwendet
CA2753626C (en) * 2011-09-30 2019-05-07 Ibm Canada Limited - Ibm Canada Limitee Packed data objects
JP2016170515A (ja) * 2015-03-11 2016-09-23 日本電気株式会社 ソフトウェア自動構成装置、ソフトウェア自動構成方法およびソフトウェア自動構成プログラム
US10073974B2 (en) * 2016-07-21 2018-09-11 International Business Machines Corporation Generating containers for applications utilizing reduced sets of libraries based on risk analysis

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4330822A (en) * 1971-09-02 1982-05-18 Burroughs Corporation Recursive system and method for binding compiled routines
US5062039A (en) * 1988-09-07 1991-10-29 International Business Machines Corp. Sharing of workspaces in interactive processing using workspace name tables for linking of workspaces
US5361351A (en) * 1990-09-21 1994-11-01 Hewlett-Packard Company System and method for supporting run-time data type identification of objects within a computer program
US5404525A (en) * 1992-09-30 1995-04-04 International Business Machines Corporation Efficient method router that supports multiple simultaneous object versions
US5369766A (en) * 1993-03-25 1994-11-29 Taligent, Inc. Object-oriented loader system with support for different load formats
US5414854A (en) * 1993-04-05 1995-05-09 Taligent, Inc. Object-oriental system for managing shared libraries
US5519866A (en) * 1993-06-28 1996-05-21 Taligent, Inc. Method and apparatus of incrementally linking components of a modeled computer program
US5758160A (en) * 1993-06-28 1998-05-26 Object Technology Licensing Corporation Method and apparatus for building a software program using dependencies derived from software component interfaces
US5668992A (en) * 1994-08-01 1997-09-16 International Business Machines Corporation Self-configuring computer system
US5613120A (en) * 1994-10-20 1997-03-18 Silicon Graphics, Inc. System and method for enabling, without recompilation, modification of class definitions and implementations in an object-oriented computer program
US5659735A (en) * 1994-12-09 1997-08-19 Object Technology Licensing Corp. Object-oriented system for program version and history database management system for various program components
US5640558A (en) * 1995-05-31 1997-06-17 International Business Machines Corporation Identifying and analyzing multiple level class relationships in an object oriented system by parsing source code without compilation

Also Published As

Publication number Publication date
US6526565B1 (en) 2003-02-25
EP0784264B1 (de) 2006-05-17
EP0784264A2 (de) 1997-07-16
JPH09204300A (ja) 1997-08-05
EP0784264A3 (de) 2004-06-30
DE69636141D1 (de) 2006-06-22

Similar Documents

Publication Publication Date Title
DE69636141T2 (de) Rechnerimplementiertes Verfahren zur Bestimmung eines Minimalcodesets für ein ausführbares Programm in einem Datenverarbeitungssystem
DE69636887T2 (de) System und Verfahren,um verschiedenen Anbietern von Namen zu ermöglichen,sich dynamisch einer Namensföderation anzuschliessen
DE60001916T2 (de) Plattformunabhängige speicherabbild analysearchitektur zur programmfehlerbeseitigung
DE69735343T2 (de) System, Verfahren und Vorrichtung zum direkten Ausführen eines architekturunabhängigen binären Programms
DE69921474T2 (de) Methode-referenzierung in objektbasierter programmierung
EP0502857B1 (de) Verfahren zur dynamischen bindung von definierbaren programmelementen eines interaktiven datenverarbeitungssystems
DE69938218T2 (de) Vorrichtung und Verfahren zum Laden eines Java Anwendungsprogramms
DE60208710T2 (de) Plattformunabhängige im-voraus-kompilierung
DE10135445B4 (de) Integriertes Verfahren für das Schaffen einer aktualisierbaren Netzabfrage
DE60319229T2 (de) Verfahren und system zur erweiterung der api eines dateisystems
DE69724322T2 (de) Verfahren und Anordnung zum frühzeitigen Einfügen von Assemblercode zwecks Optimierung
DE60103521T2 (de) Vorladen von klassen in einer datenverarbeitungseinrichtung ohne virtueller speicherverwalter
DE69722652T2 (de) System und verfahren zum ferngruppieren des inhalts eines historischen kellerspeichers
EP2517105B1 (de) Verfahren zum komprimieren von bezeichnern
DE102005045852A1 (de) Verfahren und System zum Schutz von Quellcode
DE19705955A1 (de) Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung
DE19922796A1 (de) Bestimmen der tatsächlichen Klasse eines Objekts zur Laufzeit
DE19959758A1 (de) Bestimmung der Art und der Genauigkeit von lokalen Variablen bei vorhandenen Subroutinen
DE69931685T2 (de) Verfahren und Gerät zum Implementieren von schnellen Subclass- und Subtyp-Überprüfungen
DE60102694T2 (de) Modulares computersystem und -verfahren
WO1994014117A1 (de) Verfahren zum testen mindestens einer klasse eines objektorientierten programmes auf einem rechner
DE10101346A1 (de) Dateikennzeichung und automatische Umsetzung von Daten oder Dateien
DE69907714T2 (de) Komponentbasiertes quellcodegeneratorverfahren
DE112009001892T5 (de) Datensatz basierte Codestruktur
DE102005018112A1 (de) Dynamisch konfigurierbare, aufgabenorientierte Kommunikation zwischen Benutzer und Anwendung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8320 Willingness to grant licences declared (paragraph 23)