DE10303054A1

DE10303054A1 - Verifizieren einer Programmversion

Info

Publication number: DE10303054A1
Application number: DE10303054A
Authority: DE
Inventors: John R Applin; Richard Ferreri
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 2002-02-14
Filing date: 2003-01-27
Publication date: 2003-09-04
Also published as: US20030154470A1; US7143395B2

Abstract

Eine Version für jede einer Mehrzahl von Objektdateien in einem Computerprogramm wird durch Identifizieren einer Version einer Objektdatei der Mehrzahl von Objektdateien in dem Computerprogramm und durch Vergleichen der identifizierten Version mit einer anfänglichen Version verifiziert. Ansprechend darauf, daß sich die identifizierte Version von der anfänglichen Version unterscheidet, wird ein Alarm erzeugt.

Description

Die Erfindung bezieht sich allgemein auf Computerprogramme. Insbesondere bezieht sich die Erfindung auf das Verifizieren einer Programmversion.
Es ist allgemein bekannt, daß Computer überall im Großteil der amerikanischen Gesellschaft und im Geschäftswesen vorhanden sind. Ferner ist bekannt, daß Computer üblicherweise Codes (d. h. Maschinencode) in der Form von Software oder Firmware verwenden, um Daten zu verarbeiten und eine Vielzahl von Funktionen auszuführen, für die Computer heute verwendet werden. Üblicherweise verwenden Computerprogrammierer eine Computersprache, um einen Code zu erzeugen. Heute ist eine Vielzahl von Computersprachen in einer Vielzahl von umfassend definierten Klassifizierungen verfügbar. Eine derartige Klassifizierung von Computersprachen sind objektorientierte Sprachen ("OOL" = Object-Oriented Languages) die verwendet werden, um objektorientierte Programme ("OOP" = Object-Oriented Programms) zu erzeugen.
Allgemein umfaßt das objektorientierte Programmieren einer Gruppe von Programmiersprachen und Techniken basierend auf dem Konzept eines "Objekts". Ein Objekt wird durch einen Satz von Routinen definiert, die "Verfahren" genannt werden. Ein Objekt einer bestimmen Klasse kann z. B. konfiguriert sein, um Aktionen durchzuführen, z. B. das Drucken von Daten, die durch das Objekt erzeugt werden, dass Erzeugen eines neuen Exemplars (instance) von sich selbst etc. Jedes Objekt wirkt als ein separates unabhängiges Stück oder Modul einer Anwendung. Zusätzlich dazu weist jedes Objekt seine eigenen Werte für die Variablen auf, die zu seiner Klasse gehören. Operationen, die auf die Variablen hin durchgeführt werden, können nur durch die Verfahren einer bestimmten Klasse von Objekten durchgeführt werden.
Somit ist die Schnittstelle zwischen Objekten gut definiert.
Die Verfahren dienen als eine Schnittstelle für eine Klasse oder eine Familie von Objekten. Klassen können durch eine Position in einer "Klassenhierarchie" definiert sein.
Verfahren oder Code in einer Klasse können nach unten in der Hierarchie zu einer Teilklasse weitergeleitet oder von einer Überklasse in einer Struktur genannt "Vererbung" vererbt werden. In dieser Hinsicht umfassen viele moderne OOLs eine umfassende Objektbibliothek von vorab hergestellten Klassen und eine Programmierumgebung, um den Anwendungsaufbau zu ermöglichen. Diese Folge von Anwendungen, Anfangsblockdateien, Objektbibliotheken etc. wird als Softwareentwicklerkit ("SDK") oder Programmentwicklerkit ("PDK") beschrieben.
Während die Struktur der OOLs und verschiedener strukturierter Sprachen, wie z. B. C, eine ausgezeichnete und elegante Steuerung von Daten und Speicherressourcen ermöglicht, weist dieselbe eine Anzahl von Nachteilen auf. Ein bestimmter Nachteil ist, daß, wenn eine Anwendung unter Verwendung von mehr als einer Version eines SDK erzeugt wird, die Anwendung Fehler erzeugen kann, die schwierig zu interpretieren sind. Wenn z. B. zwei Module einer Anwendung durch Programmierer unter Verwendung unterschiedlicher Versionen eines gegebenen SDK erzeugt werden, können relativ unbedeutende Störungen (z. B. Störungen, die keinen sofortigen Fehler erzeugen) von Daten auftreten. Diese "unbedeutenden" Probleme können sich über eine bestimmte Zeit ansammeln, bis dieselben einen Fehler verursachen oder anderweitig bemerkt werden.
Es ist die Aufgabe der vorliegenden Erfindung, Verfahren und Vorrichtungen für eine objektorientierte Programmierung zu schaffen, die wenig fehleranfällig sind.
Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1, ein computerlesbares Medium gemäß Anspruch 9, ein Softwareentwicklungskit gemäß Anspruch 17 und eine Vorrichtung gemäß Anspruch 18 gelöst.
In einer Hinsicht bezieht sich die Erfindung auf ein Verfahren zum Verifizieren einer Version für jede von einer Mehrzahl von Objektdateien in einem Computerprogramm. Bei diesem Verfahren wird eine Version einer Objektdatei der Mehrzahl von Objektdateien, die in dem Computerprogramm verwendet werden, identifiziert, und die identifizierte Version wird mit einer anfänglichen Version verglichen. Ansprechend darauf, daß sich die identifizierte Version von der anfänglichen Version unterscheidet, wird ein Alarm erzeugt.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
Fig. 1 ein exemplarisches Blockdiagramm eines SDK;
Fig. 2 ein Blockdiagramm, das eine exemplarische Rechenumgebung darstellt, in der ein Ausführungsbeispiel der Erfindung praktiziert werden kann;
Fig. 3 ein Flußdiagramm eines Verfahrens gemäß einem Ausführungsbeispiel der Erfindung; und
Fig. 4 ein Flußdiagramm eines Verfahrens gemäß einem Ausführungsbeispiel der Erfindung.
Der Einfachheit halber und zur darstellenden Zwecken werden die Prinzipien der Erfindung überwiegend durch Bezugnahme auf ein exemplarisches Ausführungsbeispiel derselben beschrieben, insbesondere Bezug nehmend auf ein System, um die jeweiligen Versionen einer Mehrzahl von Objekten innerhalb eines Computerprogramms zu verifizieren. Fachleute auf dem Gebiet werden jedoch erkennen, daß dieselben Prinzipien gleichermaßen auf ein System anwendbar sind, das in der Lage ist, eine Vielzahl von Aspekten zu verifizieren, die sich auf Computer-Software und/oder -Firmware beziehen, und in demselben implementiert sein können, und daß derartige Variationen innerhalb des Schutzbereichs der Erfindung liegen. Während in der nachfolgenden Beschreibung zahlreiche spezifische Details ausgeführt sind, um ein umfassendes Verständnis eines Ausführungsbeispiels der Erfindung zu liefern, wurden in anderen Fällen bekannte Verfahren und Strukturen nicht detailliert beschrieben, um die Erfindung nicht unverständlich zu machen.
Fig. 1 ist ein Blockdiagramm eines SDK 100 gemäß einem Ausführungsbeispiel der Erfindung. Das SDK 100 kann verschiedene Anwendungen und Module umfassen, wie z. B. Objektbibliotheken, Anfangsblockdateien und ähnliches, um die Erzeugung eines Computerprogramms zu ermöglichen. Diesbezüglich kann das SDK 100 ein Zeitstempelmodul 110 ("TS" Timestamp) und eine Mehrzahl von zusätzlichen Modulen 120-140 zum Durchführen verschiedener Aufgaben umfassen, die durch Programmierer bestimmt werden. Während in Fig. 1 vier Module dargestellt sind, ist es für Fachleute auf dem Gebiet offensichtlich, daß das SDK 100 jede geeignete Anzahl von Modulen umfassen kann. Bei einem Ausführungsbeispiel kann das SDK 100 eine objektorientierte Programmiermethodik verwenden, wie z. B. Java und C++ Sprachen. Fachleute auf dem Gebiet werden jedoch erkennen, daß ein Ausführungsbeispiel der Erfindung ferner unter Verwendung von anderen bekannten oder zukünftigen Programmiermethoden implementiert sein kann.
Das SDK 100 kann als eine Programmierschnittstelle dienen, die konfiguriert ist, um die Verwendung der verschiedenen Module 110-140 zu ermöglichen. Insbesondere kann das SDK 100 konfiguriert sein, um die Verwendung des TS-Moduls 110 zu ermöglichen. Das TS-Modul 110 kann konfiguriert sein, um einen Zeitstempel innerhalb von Objekten einzubetten, die durch das SDK 100 erzeugt werden. Wie nachfolgend detaillierter beschrieben wird, kann der Zeitstempel verwendet werden, um zu verifizieren, daß Objekte innerhalb einer Anwendung durch dieselbe Version des SDK 100 erzeugt wurden.
Bei einem Ausführungsbeispiel kann die Funktionalität des TS-Moduls 110 innerhalb einer Anfangsblockdatei umfaßt sein. Im allgemeinen kann eine Anfangsblockdatei verwendet werden, um Funktionen und Klassen zu definieren, und kann vorbestimmte Funktionen umfassen. Ein Verfahren zum Definieren eines Makro (das eine symbolische Konstante definiert) innerhalb einer Anfangsblockdatei soll eine Vorprozessor-Textmakrosubstitution unter Verwendung eines "# define"-Befehls auslösen. Der Vorprozessor ist ein Programm, der durch verschiedene Kompilierer aufgerufen wird, um einen Code vor der Kompilierung zu verarbeiten. Zusätzlich zu der Textmakrosubstitution führt der Vorprozessor eine bedingte Kompilierung und Einlagerung anderer Dateien durch.
Tabelle 1 ist eine exemplarische Anfangsblockdatei "TimeS- tamp.h" gemäß einem Ausführungsbeispiel der Erfindung. Tabelle 1 #ifndef TimeStamp_h
#define TimeStamp_h
#define PIKA_TIMESTAMP 1010382108
#define PIKA_HOWBUILT "hergestellt Mon. 7. Jan. 12 : 41 : 48 2002 von Jack Applin an Vorrichtung x"
#endif /* TimeStamp_h */
Wie in Tabelle 1 gezeigt ist, kann TimeStamp.h verwendet werden, um ein "PIKA_TIMESTAMP"-Makro zu definieren. Diesbezüglich, wie in Zeile 3 gezeigt ist (Zeilennummern sind der Klarheit halber hinzugefügt) ist PIKA_TIMESTAMP als der Wert "1010382108" definiert. Bei einem Ausführungsbeispiel stellt dieser Wert das Datum und die Zeit dar, zu der ein gegebenes SDK gebaut wurde, und wird verwendet, um eine bestimmte Version (z. B. Herstellungsdatum) für das gegebene SDK eindeutig zu identifizieren. Dieser SDK-Version- Identifizierer kann wiederum innerhalb jedes Objekts eingelagert sein, das durch das SDK erzeugt wird. Es sollte für Fachleute auf dem Gebiet offensichtlich sein, daß verschiedene andere Wege zum Identifizieren einer bestimmten Version verwendet werden können und somit innerhalb des Schutzbereichs der Erfindung liegen.
Zusätzlich dazu kann TimeStamp.h verwendet werden, um ein "PIKA_HOWBUILT"-Makro zu definieren. Diesbezüglich, wie in Zeile 4 gezeigt ist, ist PIKA_HOWBUILT als "hergestellt Mon. 7. Jan. 12 : 41 : 48 2002 durch Jack Applin an Vorrichtung x" definiert. Die Vorrichtung x ist der Name oder die identifizierende Adresse des Computers, der durch einen Programmierer des SDK verwendet wird (d. h. Jack Applin), um die gegebene Version des SDK herzustellen. Während es für dieses Ausführungsbeispiel der Erfindung nicht wesentlich ist, kann das PIKA-HOWBUILT-Makro verwendet werden, um eine benutzerfreundliche Nachricht im Hinblick auf die Ursache eines Fehlers zu erzeugen.
Ferner, um sicherzustellen, daß die Makros PIKA_TIMESTAMP und PIKA_HOWBUILT nur einmal während der Kompilierung einer bestimmten Objektdatei definiert werden, werden die Anmerkungen #define innerhalb eines Satzes von bedingter. Operatoren plaziert. Somit, während der Vorkompilierung, analysiert der Vorprozessor Zeile 1 syntaktisch, wenn "TIME- STAMP_h" definiert wurde, und der Vorprozessor ignoriert die Zeilen 2, 3 und 4. Wenn jedoch TimeStamp_h nicht definiert wurde, werden die folgenden Aktionen durchgeführt:
Der Vorprozessor analysiert Zeile 2 syntaktisch und definiert TimeStamp_h.
Der Vorprozessor analysiert Zeile 3 syntaktisch, definiert PIKA_TIMESTAMP als 1010382108 und ersetzt alle Exemplare von PIKA_TIMESTAMP durch 1010382108 innerhalb des gesamten Codes, der in der bestimmten Kompilierungssitzung umfaßt ist.
Der Vorprozessor analysiert Zeile 4 syntaktisch, definiert PIKA_HOWBUILT als "hergestellt Mon. 7. Jan. 12 : 41 : 48 2002 durch Jack Applin an Vorrichtung x" und ersetzt alle Exemplare von PIKA_HOWBUILT durch "hergestellt Mon. 7. Jan. 12 : 41 : 48 2002 durch Jack Applin an Vorrichtung x" innerhalb des gesamten Codes, der in der bestimmten Kompilierungssitzung umfaßt ist.
Zusätzlich dazu wird darauf hingewiesen, daß die Erfindung nicht auf die exemplarische Anfangsblockdatei beschränkt ist, die in Tabelle 1 aufgelistet ist, sondern daß die Erfindung eine angemessene Variation von Computercode und/oder Maschinensprache umfaßt, die in der Lage ist, einen ähnlichen Prozeß durchzuführen. Dementsprechend ist die Anfangsblockdatei, die in Tabelle 1 aufgelistet ist, ausschließlich zu darstellenden Zwecken vorgesehen und soll die vorliegende Erfindung in keinerlei Hinsicht einschränken. Während die Anfangsblockdatei, die in Tabelle 1 aufgelistet ist, z. B. die Verwendung von zwei Identifizierern beschreibt (z. B. PIKA_TIMESTAMP und PIKA_HOWBUILT), können verschiedene andere Ausführungsbeispiele der Erfindung einen einzigen Identifizierer oder mehrere Identifizierer verwenden und liegen somit innerhalb des Schutzbereichs der Erfindung.
Tabelle 2 ist eine exemplarische Anfangsblockdatei Pika.h gemäß einem Ausführungsbeispiel der Erfindung. Tabelle 2
Es wird darauf hingewiesen, daß das Wort "static" in Zeile 17 impliziert, daß "CheckVersion" für dieses Kompilierungsobjekt lokal ist, und somit können mehrere Exemplare dieses Objekts in anderen Kompilierungseinheiten existieren können. Auf diese Weise kann eine jeweilige Version für jedes Objekt beibehalten werden. Wie unten beschrieben ist, können diese jeweiligen Versionen verglichen und Versionsdiskrepanzen können erfaßt werden.
Die Pika.h-Datei kann verwendet werden, um eine Objektklasse zu definieren und zu instanziieren. Die Definition einer Klasse bezieht sich auf das Benennen und Definieren von Charakteristika dieser Klasse. Die Instanziierung eines Objekts bezieht sich auf die Initialisierung der Variablen und anderer Werte, die den Zustand des Objekts aufweisen.
Diesbezüglich ist ein Objekt "CheckVersion" in den Zeilen 10-16 definiert und wird in Zeile 17 instanziiert. Zusätzlich dazu wird darauf hingewiesen, daß die Erfindung nicht auf die exemplarische Anfangsblockdatei beschränkt ist, die in Tabelle 2 aufgelistet ist, sondern daß die Erfindung eine geeignete Variation eines Computercodes und/oder einer Maschinensprache umfassen kann, die in der Lage ist, einen ähnlichen Prozeß durchzuführen. Dementsprechend liegt die Anfangsblockdatei, die in Tabelle 2 aufgelistet ist, ausschließlich zu darstellenden Zwecken vor, und soll die vorliegende Erfindung in keinerlei Hinsicht einschränken. Während die Anfangsblockdatei, die in Tabelle 2 aufgelistet ist, z. B. die Verwendung von zwei Identifizierern (z. B. time_t und msg) beschreibt, verwenden verschiedene andere Ausführungsbeispiele der Erfindung einen einzelnen Identifizierer oder mehrere Identifizierer und befinden sich somit innerhalb des Schutzbereichs der Erfindung.
Tabelle 3 ist eine exemplarische Klassenkonstrukteurdatei Pika.cc gemäß einem Ausführungsbeispiel der Erfindung. Tabelle 3
Die Datei Pika.cc kann verwendet werden, um eine CheckVersion-Objektklasse aufzubauen. Bei einem Ausführungsbeispiel kann der CheckVersion-Konstrukteur zur Laufzeit für eine Anwendung initiiert werden, wie z. B. die Anwendung 240, die eine Mehrzahl von Objekten umfaßt. Diesbezüglich, wenn jedes der Mehrzahl von Objekten initiiert wird, werden die Befehle innerhalb der Datei Pika.cc ausgeführt. Wenn ein erstes Objekt initiiert wird, werden die Variablen saved_time (gespeicherte Zeit) und saved_msg (gespeicherte Meldung) mit einem Zeit- und einem Meldung-Wert aus dem ersten Objekt initiiert (z. B. die jeweilige Version des ersten Objekts). Wenn ein nachfolgendes CheckVersion-Objekt aufgebaut wird, kann der Zeitwert (z. B. die Version des nachfolgenden Objekts) des nachfolgenden Objektes mit dem Wert saved_time verglichen werden. Wenn diese Werte gleich sind (z. B. saved_time = time), kann die Anwendung fortgesetzt werden. Wenn der Wert von saved_time jedoch nicht gleich dem Wert von time ist, kann ein Fehlerzustand auftreten. Diesbezüglich, wie in den Zeilen 29 und 30 dargestellt ist, können die Werte von saved_msg und msg angezeigt werden, eine Fehlermeldung "Error: Version mismatch . . ." kann angezeigt werden, und die Anwendung 240 kann enden.
Zusätzlich dazu wird darauf hingewiesen, daß die Erfindung nicht auf die exemplarische Klassenkonstrukteurdatei beschränkt ist, die in Tabelle 3 aufgelistet ist, sondern daß die Erfindung eine angemessene Variation von Computercode und/oder Maschinensprache umfassen kann, die in der Lage ist, einen einfachen Prozeß durchzuführen. Dementsprechend liegt die Klassenkonstrukteurdatei, die in Tabelle 3 aufgelistet ist, ausschließlich zu darstellenden Zwecken vor und soll die vorliegende Erfindung in keinerlei Hinsicht einschränken. Während der Klassenkonstrukteur, der in Tabelle 3 aufgelistet ist, z. B. die Verwendung von zwei Identifizierern beschreibt (z. B. time_t und msg), können verschiedene andere Ausführungsbeispiele der Erfindung einen einzelnen Identifizierer oder mehrere Identifizierer verwenden, und liegen somit innerhalb des Schutzbereichs der Erfindung.
Fig. 2 ist ein Blockdiagramm, das eine exemplarische Umgebung 200 gemäß einem Ausführungsbeispiel der Erfindung darstellt. Wie in Fig. 2 gezeigt ist, kann die Umgebung 200eine Arbeitsstation ("WS" = Workstation) 210, einen Server 220 und ein Netzwerk 230 umfassen.
Die WS 210 kann konfiguriert sein, um zumindest die Fähigkeit bekannter Arbeitsstationen zu liefern. Diesbezüglich kann die WS 210 ein Computer sein, wie z. B. der HP Visualize C3600, HP vectra v1800, Apple Macintosh-Computer oder UNIX-basierte Arbeitsstation. Die WS 210 kann ferner konfiguriert sein, um das SDK 100 und eine Anwendung 240 zu betreiben. Die WS 210 kann ein Betriebssystem umfassen, wie z. B. das Microsoft Windows NT oder das Windows 2000- Betriebssystem ("OS" = Operating System), das IBM OS/2, das MAC OS oder das UNIX OS. Fachleute auf dem Gebiet werden erkennen, daß ein Ausführungsbeispiel der Erfindung ferner auf Plattformen und Betriebssystemen implementiert sein kann, die nicht erwähnt wurden.
Der Server 220 kann konfiguriert sein, um zumindest die Fähigkeit von bekannten Servern zu liefern. Diesbezüglich kann der Server 220 ein Computer sein, wie z. B. der HP lp2000r, der HP9000 und ähnliches. Der Server 220 kann ferner konfiguriert sein, um das SDK 100 und/oder die Anwendung 240 zu betreiben. Der Server 220 kann ein Betriebssystem umfassen, wie z. B. das Microsoft Windows NT oder Windows 2000 OS, das IBM OS/2, das MAC OS oder das UNIX OS. Fachleute auf dem Gebiet werden erkennen, daß ein Ausführungsbeispiel der Erfindung ferner auch auf Plattformen oder Betriebssystemen implementiert sein kann, die nicht erwähnt wurden.
Die Anwendung 240 kann unter Verwendung des SDK 100 erzeugt werden. Auf ähnliche Weise wie bei bekannten Anwendungen kann die Anwendung 240 einen Computercode umfassen, der in einer Vielzahl von Modulen oder Objekten konfiguriert ist. Bei einem Ausführungsbeispiel kann das SDK 100 und/oder die Anwendung 240, die auf dem Server 220 betrieben werden, unterschiedliche Exemplare desselben SDK 100 und/oder der Anwendung 240 sein, die auf der WS 210 betrieben werden.
Bei einem anderen Ausführungsbeispiel können das SDK 100 und/oder die Anwendung 240, die auf dem Server 220 betrieben werden, unterschiedliche Versionen des SDK 100 und/oder der Anwendung 240 sein, die auf der WS 210 betrieben wird. Bei einem wiederum anderen Ausführungsbeispiel kann die Funktionalität eines Exemplars des SDK 100 und/oder der Anwendung 240 über das Netzwerk 230 verteilt sein. Ferner soll der Ausdruck Anwendung keine Einschränkung sein, sondern beschreibt eine Computer-Software und/oder -Firmware, die in der Lage ist, Handhabungen von Computerdaten durchzuführen.
Obwohl dies nicht dargestellt ist, kann die Umgebung 200 ferner eine geeignete Anzahl von zusätzlichen Komponenten umfassen, z. B. Klienten, Arbeitsstationen, Server, Druckerspuler, Repeater, Hubs, Brücken, Router, etc. Das Netzwerk 230 kann konfiguriert sein, um einen Kommunikationsweg für eine oder mehrere Netzwerkvorrichtungen zu liefern, um mit einer oder mehreren anderen Netzwerkvorrichtungen zu kommunizieren. Das Netzwerk 230 kann konfiguriert sein, um über das Internet betrieben zu werden, über ein öffentliches Fernsprechnetz, ein lokales Netz oder ähnliches. Ferner liegt es innerhalb des Schutzbereichs der Erfindung, daß bestimmte oder alle Funktionalitäten der Umgebung 200 innerhalb einer einzelnen Vorrichtung zusammengefaßt sein können. Entsprechend dient die Umgebung 200, die beschrieben wurde, ausschließlich zu darstellenden Zwecken und soll die Erfindung in keinerlei Hinsicht einschränken.
Fig. 3 ist ein Flußdiagramm eines Verfahrens 300 zum Setzen und Einlagern einer Zeitstempelfunktion innerhalb einer Mehrzahl von Objekten in einem SDK gemäß einem Ausführungsbeispiel der Erfindung. Die nachfolgende Beschreibung von Fig. 3 wird unter besonderer Bezugnahme auf das SDK 100 durchgeführt, das in Fig. 1 beschrieben ist, und die Computerumgebung, die in Fig. 2 beschrieben ist. Dementsprechend können einer oder mehrere Aspekte des Verfahrens 300während der Entwicklung des SDK 100 initiiert werden. Wie in Fig. 3 gezeigt ist, kann bei Schritt 310 ein Zeitstempelwert ("TS"-Wert), wie z. B. PIKA_TIMESTAMP, der in Tabelle 1 beschrieben ist, für eine bestimmte Version des SDK 100 gesetzt werden. Bei einem Ausführungsbeispiel wird der TS- Wert zu der Zeit definiert, zu der das SDK 100 erzeugt wird. Diesbezüglich und wie in Tabelle 1 gezeigt ist, kann der TS-Wert gesetzt werden. Zusätzlich dazu kann ein howbuilt-Zeichenfolge ("HB"), wie z. B. die PIKA_HOWBUILT- Zeichenfolge, die in Tabelle 1 beschrieben ist, für die bestimmte Version des SDK 100 gesetzt werden. Die HB- Zeichenfolge kann verwendet werden, um das Anzeigen einer benutzerfreundlichen Fehlermeldung zu ermöglichen, wie nachfolgend detaillierter beschrieben wird. Auf eine Weise ähnlich zu dem TS-Wert kann die HB-Zeichenfolge bei einem Ausführungsbeispiel zu der Zeit bestimmt werden, zu der das SDK 100 erzeugt wird.
Bei Schritt 320 wird eine CheckVersion-Klasse ("CV"- Klasse), wie z. B. die in Tabelle 2 beschriebene CheckVersion-Klasse definiert. Im allgemeinen kann das Definieren der CV-Klasse verwendet werden, um eine oder mehrere Variablen und/oder Konstanten innerhalb der CV-Klasse zu konfigurieren. Bei einem Ausführungsbeispiel wird die CV-Klasse unter Verwendung einer vorbestimmten Anfangsblockdatei aus dem SDK 100 definiert. Zusätzlich dazu kann die vorbestimmte Anfangsblockdatei aus dem SDK 100 eine Anfangsblockdatei sein, auf die im wesentlichen durch jede Objektdatei Bezug genommen wird, die mit dem SDK 100 erzeugt wird.
Bei Schritt 330 können eine oder mehrere der Variablen und/oder Konstanten der CV-Klasse definiert werden. Bei einem Ausführungsbeispiel wird die Definition unter Verwendung der in Tabelle 1 beschriebenen Vorprozessor- Textmakrosubstitution durchgeführt. Zusätzlich dazu können eine oder mehrere der Variablen und/oder Konstanten der CV- Klasse mit dem HB-Wert auf eine Weise ähnlich zu dem TS- Wert definiert werden.
Zusätzlich dazu wird darauf hingewiesen, daß die Erfindung nicht auf das Verfahren 300 beschränkt ist, sondern daß die Erfindung jede geeignete Variation eines Computercodes und/oder einer Maschinensprache umfassen kann, die in der Lage ist, einen ähnlichen Prozeß durchzuführen. Dementsprechend liegt das Verfahren ausschließlich für darstellende Zwecke vor und soll die vorliegende Erfindung in keinerlei Hinsicht einschränken. Während das Verfahren 300 die Verwendung von zwei Identifizierern beschreibt (z. B. TS und HB), können verschiedene andere Ausführungsbeispiele der Erfindung einen einzelnen Identifizierer oder mehrere Identifizierer verwenden und liegen somit innerhalb des Schutzbereichs der Erfindung. Ferner, während das Verfahren 300 in Bezug auf die Codesprache C++ beschrieben wurde, können verschiedene andere Ausführungsbeispiele der Erfindung eine beliebige vorliegende oder zukünftige Computersprache verwenden.
Fig. 4 ist ein Flußdiagramm eines Verfahrens 400 zum Verifizieren, daß eine Mehrzahl von Objekten innerhalb einer Anwendung unter Verwendung einer einzelnen Version eines SDK gemäß einem Ausführungsbeispiel der Erfindung erzeugt wurden. Die nachfolgende Beschreibung von Fig. 4 wird unter besonderer Bezugnahme auf die Fig. 1 und 2 ausgeführt und auf die exemplarische Klassenkonstrukteurdatei Pika.cc, die in Tabelle 3 beschrieben ist. Entsprechend kann das Verfahren 400 ansprechend auf die Initiierung der Anwendung 240 initiiert werden.
Bei Schritt 410 wird SAVED_MSG implizit auf einen Wissen- Status initialisiert, z. B. 0, Null etc. Nach dem Schritt 410 wird eine Schleife 420 durchgeführt. Im allgemeinen wird ein Satz von Befehlen, wie z. B. die Befehle, die in Tabelle 3 beschrieben sind, während jedes Durchlaufs durch die Schleife 420 ausgeführt. Auf diese Weise wird ein Durchlauf durch die Schleife 420 für jedes Objekt durchgeführt, das eine Instanziierung von CheckVersion enthält, außer ein Fehler wird erfasst, oder bis alle derartigen Objekte verifiziert wurden.
Bei Schritt 430 wird auf ein Objekt Bezug genommen. Bei einem Ausführungsbeispiel des Verfahrens 400 wird eine Variable "time" und "msg" jeweils verwendet, um den TS-Wert und die HB-Zeichenfolge dieses Objekts (z. B. die jeweilige Version des Objekts) auf eine Weise ähnlich zu der in Zeile 22 aus Tabelle 3 zu speichern. Bei verschiedenen anderen Ausführungsbeispielen kann jedoch eine einzelne Zeitstempelvariable verwendet werden. Zusätzlich dazu, wie Fachleuten auf dem Gebiet bekannt ist, soll der Ausdruck "Zeitstempel" keine Einschränkung sein, sondern beschreibt die Weise, auf die ein eindeutiger Identifizierer für jede SDK- Version in jedem Objekt eingelagert sein kann, dass durch das SDK erzeugt wird.
Bei Schritt 440 wird bestimmt, ob das Objekt auf das bei Schritt 430 Bezug genommen wurde, das erste Objekt ist, auf das Bezug genommen wurde. Wenn z. B. SAVED_MSG = 0, dann kann bestimmt werden, daß das Objekt, auf das bei Schritt 430 Bezug genommen wurde das erste Bezug genommene Objekt ist und das Verfahren kann mit Schritt 450 fortfahren. Alternativ, wenn bestimmt wird, daß das Objekt auf das bei Schritt 430 Bezug genommen wurde nicht das erste Bezug genommene Objekt ist, kann das Verfahren mit Schritt 460 fortfahren.
Bei Schritt 450 wird der TS-Wert für das Objekt einer Referenzvariablen zugeordnet. In Zeile 24 von Tabelle 3 wird der Wert der Variablen "time'" z. B. der Variablen "saved_time" zugeordnet. Zusätzlich dazu kann die HB- Zeichenfolge für das Objekt einer Referenzvariablen auf ähnliche Weise zu dem TS-Wert zugeordnet werden. Nach Schritt 450 kann das Verfahren 400 zu Schritt 430 zurückkehren.
Bei Schritt 460 wird der Wert, der für die "time"-Variable gespeichert ist mit dem Wert verglichen, der für die "saved_time"-Variable gespeichert ist. In Zeile 27 aus Tabelle 3, kann wenn time nicht gleich saved_time ist in den Zeilen 28 bis 30 ein Fehlerprotokoll ausgeführt werden. Somit, wenn der Wert, der für die "time"-Variable gespeichert ist nicht gleich dem Wert ist, der für die "saved_time"- Variable gespeichert ist, fährt das Verfahren 400 mit Schritt 470 fort. Wenn der Wert, der für die "time"- Variable gespeichert ist jedoch gleich dem Wert ist, der für die "saved_time"-Variable gespeichert ist, fährt das Verfahren 400 mit Schritt 480 fort.
Bei Schritt 470, ansprechend auf die TS-Werte von zwei Objekten, die unterschiedlich sind, wird ein Alarm oder ein Fehlerzustand initiiert. Bei einem Ausführungsbeispiel kann eine informative Meldung, die die Ursache des Fehlerzustands erklärt, angezeigt werden, um die Korrektur des Problems zu ermöglichen. In Zeile 28 von Tabelle 3 zum Beispiel die Meldung "Fehler: Verwendung unterschiedlicher Versionen von Pika:" gefolgt durch die HB-Zeichenfolge des ersten Objekts und die HB-Zeichenfolge des zweiten Objekts, erzeugt mit unterschiedlichen Versionen von Pika. Nach der Anzeige der Fehlermeldung kann das Verfahren 400 enden.
Bei Schritt 480 kann bestimmt werden, ob das aktuelle Objekt das letzte Objekt ist. Wenn z. B. keine weiteren Objekte zum Verifizieren verbleiben, kann das Verfahren 400 enden. Alternativ, wenn zusätzliche Objekte verifiziert werden müssen, kann das Verfahren 400 zu Schritt 430 zurückkehren und eine weitere Schleife 420 kann durchgeführt werden.
Zusätzlich dazu wird darauf hingewiesen, daß die Erfindung nicht auf das Verfahren 400 beschränkt ist, sondern daß die Erfindung eine geeignete Variation eines Computercodes und/oder einer Maschinensprache umfassen kann, die in der Lage ist, einen ähnlichen Prozeß durchzuführen. Dementsprechend liegt das Verfahren ausschließlich zu darstellenden Zwecken vor und soll die vorliegende Erfindung in keinerlei Hinsicht einschränken. Während das Verfahren 400 z. B. die Verwendung von zwei Identifizierern beschreibt (z. B. TS und HB), können verschiedene andere Ausführungsbeispiele der Erfindung einen einzelnen Identifizierer oder mehrere Identifizierer verwenden, die somit innerhalb des Schutzbereichs der Erfindung liegen. Ferner, während das Verfahren 400 Bezug nehmend auf die C++-Codesprache beschrieben wurde, können verschiedene andere Ausführungsbeispiele der Erfindung jede vorliegende oder zukünftige Computersprache verwenden.
Die Verfahren 300 und 400 können in einer Vielzahl von Formen vorliegen, sowohl aktiv als auch inaktiv. Dieselben können z. B. als eines oder mehrere Softwareprogramme existieren, die aus Programmbefehlen in Quellcode, Objektcode, ausführbarem Code oder anderen Formaten bestehen. Einer der oben genannten kann auf einem computerlesbaren Medium verkörpert sein, das Speicherungsvorrichtungen und Signale umfaßt, in komprimierter oder nichtkomprimierter Form. Exemplarische, computerlesbare Speicherungsvorrichtungen umfassen einen herkömmlichen Computersystem-RAM (Random Access Memory = Direktzugriffsspeicher), ROM (Read Only Memory = Nur-Lese-Speicher), EPROM (löschbarer, programmierbarer ROM), EEPROM (elektrisch löschbarer, programmierbarer ROM), Flashspeicher und magnetische oder optische Platten oder Bänder. Exemplarische computerlesbare Signale, ob unter Verwendung eines Trägers moduliert oder nicht, sind Signale, daß ein Computersystem, das das Computerprogramm unterbringt oder betreibt konfiguriert sein kann, zuzugreifen, und Signale, die durch das Internet oder andere Netzwerke heruntergeladen werden. Konkrete Beispiele des vorangehenden umfassen die Verteilung des oder der Programme auf einer CD-ROM oder über einen Internet- Download. Einerseits ist das Internet selbst als eine abstrakte Entität ein computerlesbares Medium. Dasselbe gilt für Computernetzwerke im allgemeinen.

Claims

1. Verfahren (400) zum Verifizieren einer Version für jede einer Mehrzahl von Objektdateien in einem Computerprogramm (240), wobei das Verfahren (400) folgende Schritte aufweist:
Identifizieren einer Version einer Objektdatei der Mehrzahl von Objektdateien, die in dem Computerprogramm (240) umfaßt sind;
Vergleichen (460) der identifizierten Version mit einer anfänglichen Version; und
Erzeugen (470) eines Alarms ansprechend darauf, daß sich die identifizierte Version von der anfänglichen Version unterscheidet.

2. Verfahren (400) gemäß Anspruch 1, bei dem jede der Mehrzahl von Objektdateien eine jeweilige Version umfaßt und das ferner einen Schritt des Bestimmens (440) einer anfänglichen Version aufweist, wobei die anfänglichen Version die jeweilige Version von einer der Mehrzahl von Objektdateien in dem Computerprogramm umfaßt.

3. Verfahren (400) gemäß Anspruch 2, bei dem der Schritt des Bestimmens (440) der anfänglichen Version ferner das Speichern (450) der jeweiligen Version von einem der Mehrzahl von Objekten als die anfänglichen Version aufweist, ansprechend darauf, daß das Bestimmen (440) der anfänglichen Version einem Nullwert entspricht.

4. Verfahren (400) gemäß Anspruch 3, bei dem der Schritt des Vergleichens (460) ferner das Vergleichen der identifizierten Version mit der anfänglichen Version aufweist, ansprechend darauf, daß ein Wert für die anfängliche Version gespeichert wird.

5. Verfahren gemäß einem der Ansprüche 1 bis 4, bei dem der Schritt des Erzeugens (470) eines Alarms ferner das Anzeigen einer Nachricht an einen Benutzer aufweist, die den Benutzer über eine Versionsfehlanpassung informiert.

6. Verfahren gemäß einem der Ansprüche 1 bis 5, bei dem die Version zumindest entweder eine Codeversion, ein Datum oder einen Zeitstempel aufweist.

7. Verfahren (400) gemäß einem der Ansprüche 1 bis 6, bei dem jede der Mehrzahl von Objektdateien eine jeweilige Textnachricht umfaßt und das Verfahren ferner folgenden Schritt aufweist:
Anzeigen der Textnachricht für die Objektdatei ansprechend darauf, daß sich die identifizierte Version von der anfänglichen Version unterscheidet.

8. Verfahren (400) gemäß Anspruch 7, das ferner folgende Schritte aufweist:
Speichern (450) der jeweiligen Textnachricht von einer der Mehrzahl von Objektdateien als eine anfängliche Textnachricht ansprechend auf das Bestimmen (440), daß die Textnachricht einem Nullwert entspricht; und
Anzeigen der anfänglichen Textnachricht ansprechend darauf, daß sich die identifizierte Version von der anfänglichen Version unterscheidet.

9. Computerlesbares Medium, auf dem ein Programm eingebettet ist, wobei das Programm ein Verfahren zum Verifizieren einer Version für jede einer Mehrzahl von Objektdateien in einem Computerprogramm ausführt, wobei das Verfahren (400) folgende Schritte aufweist:
Identifizieren einer Version einer Objektdatei aus der Mehrzahl von Objektdateien, die in dem Computerprogramm (240) umfaßt sind;
Vergleichen (460) der identifizierten Version mit einer anfänglichen Version; und
Erzeugen (470) eines Alarms ansprechend darauf, daß sich die identifizierte Version von der anfänglichen Version unterscheidet.

10. Computerlesbares Medium gemäß Anspruch 9, bei dem jede der Mehrzahl von Objektdateien eine jeweilige Version umfaßt und ferner einen Schritt des Bestimmens einer anfänglichen Version aufweist, wobei die anfängliche Version die jeweilige Version von einer der Mehrzahl von Objektdateien in dem Computerprogramm umfaßt.

11. Computerlesbares Medium gemäß Anspruch 10, bei dem der Schritt des Bestimmens (440) der anfänglichen Version ferner das Speichern der jeweiligen Version von einem der Mehrzahl von Objekten als die anfängliche Version aufweist, ansprechend auf das Bestimmen, daß die anfängliche Version einem Nullwert gleicht.

12. Computerlesbares Medium gemäß Anspruch 11, bei dem der Schritt des Vergleichens (460) ferner das Vergleichen der identifizieren Version mit der anfänglichen. Version aufweist, ansprechend darauf, daß ein Wert für die anfängliche Version gespeichert wird.

13. Computerlesbares Medium gemäß einem der Ansprüche 9 bis 12, bei dem der Schritt des Erzeugens (470) eines Alarms ferner das Anzeigen einer Nachricht an einen Benutzer aufweist, die den Benutzer über eine Versionsfehlanpassung informiert.

14. Computerlesbares Medium gemäß einem der Ansprüche 9 bis 13, bei dem die Version zumindest entweder eine Codeversion, ein Datum oder einen Zeitstempel aufweist.

15. Computerlesbares Medium gemäß einem der Ansprüche 9 bis 14, bei dem jede der Mehrzahl von Objektdateien eine jeweilige Textnachricht umfaßt und das Verfahren ferner folgenden Schritt aufweist:
Anzeigen der Textnachricht für die Objektdatei ansprechend darauf, daß sich die identifizierte Version von der anfänglichen Version unterscheidet.

16. Computerlesbares Medium gemäß einem der Ansprüche 9 bis 15, das ferner folgende Schritte aufweist:
Speichern der jeweiligen Textnachricht von einer der Mehrzahl von Objektdateien als eine anfängliche Textnachricht, ansprechend auf das Bestimmen, daß eine anfängliche Textnachricht gleich einem Nullwert ist; und
Anzeigen der anfänglichen Textnachricht ansprechend darauf, daß sich die identifizierte Version von der anfänglichen Version unterscheidet.

17. Softwareentwicklungskit (100), das konfiguriert ist, um eine Entwicklung einer Anwendung (240) zu ermöglichen, die eine Mehrzahl von Objektdateien aufweist, wobei das Softwareentwicklungskit (100) folgende Merkmale aufweist:
eine Mehrzahl von Modulen (110-130);
einen Zeitstempel, der verwendet wird, um eine entsprechende Version des Softwareentwicklungskits für jede der Mehrzahl von Objektdateien zu identifizieren; und
zumindest ein Modul (110), das konfiguriert ist, um den Zeitstempel in zumindest eine der Mehrzahl von Objektdateien einzubetten, wobei die Anwendung (240), die mit dem Softwareentwicklungskit (100) entwickelt wurde, konfiguriert ist, um einen Fehler ansprechend darauf zu erzeugen (470), daß zwei der Objektdateien unterschiedliche Zeitstempel aufweisen.

18. Vorrichtung, die folgende Merkmale aufweist:
eine Einrichtung zum Identifizieren einer Version einer Objektdatei einer Mehrzahl von Objektdateien, die in einem Computerprogramm (240) umfaßt sind;
eine Einrichtung zum Vergleichen (460) der identifizierten Version mit einer anfänglichen Version; und
eine Einrichtung zum Erzeugen (470) eines Alarms ansprechend darauf, daß sich die identifizierte Version von der anfänglichen Version unterscheidet.

19. Vorrichtung gemäß Anspruch 18, bei der jede der Mehrzahl von Objektdateien eine jeweilige Version umfaßt und die Vorrichtung ferner eine Einrichtung zum Bestimmen einer anfänglichen Version aufweist, wobei die anfängliche Version die jeweilige Version von einer der Mehrzahl von Objektdateien in dem Computerprogramm (240) umfaßt.

20. Vorrichtung gemäß Anspruch 18 oder 19, die ferner eine Einrichtung zum Anzeigen einer Nachricht an einen Benutzer aufweist, die den Benutzer über eine Versionsfehlanpassung informiert, ansprechend darauf, daß sich die identifizierte Version von der anfänglichen Version unterscheidet.

21. Vorrichtung gemäß einem der Ansprüche 18 bis 20, die ferner eine Einrichtung zum Kodieren einer jeweiligen Version innerhalb jeder der Mehrzahl von Objektdateien aufweist, wobei die jeweilige Version zumindest entweder eine Codeversion, ein Datum und einen Zeitstempel umfaßt.