AT501112A2 - Verfahren zum verwalten von konfigurationsdaten - Google Patents

Verfahren zum verwalten von konfigurationsdaten Download PDF

Info

Publication number
AT501112A2
AT501112A2 AT0209604A AT20962004A AT501112A2 AT 501112 A2 AT501112 A2 AT 501112A2 AT 0209604 A AT0209604 A AT 0209604A AT 20962004 A AT20962004 A AT 20962004A AT 501112 A2 AT501112 A2 AT 501112A2
Authority
AT
Austria
Prior art keywords
configuration
program
file
code
documentation
Prior art date
Application number
AT0209604A
Other languages
English (en)
Inventor
Rainer Ing Hochreiter
Martin Ing Hraby
Steffen Dipl Inform Jakob
Joerg Dipl Ing Mag Rainer
Wilhelm Mag Dr Zugaj
Michael Dipl Ing Zwettler
Original Assignee
Topcall Internat Ag
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 Topcall Internat Ag filed Critical Topcall Internat Ag
Priority to AT0209604A priority Critical patent/AT501112A2/de
Publication of AT501112A2 publication Critical patent/AT501112A2/de
Priority to AT0803808U priority patent/AT10304U1/de

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Stored Programmes (AREA)

Description


  > *
Die Erfindung betrifft ein Verfahren zum Vereinheitlichen von Konfigurationsbeschreibungen in Anwendungsprogrammen, der dazugehörigen Programmdokumentation sowie gegebenenfalls dem dazugehörigen Konfigurationsprogramm.
Die meisten Computerprogramme können vom Benutzer entsprechend den jeweiligen Bedürfnissen konfiguriert werden. Dies bedeutet, dass der Ablauf des Computerprogramms in Abhängigkeit von vom Benutzer ausgewählten Werten für einzelne Konfigurationsparameter beeinflusst werden kann. Der Programmierer muss zu diesem Zweck zunächst für jedes Computerprogramm gesondert eine Konfigurationsbeschreibung festlegen. Unter einer Konfigurationsbeschreibung versteht man hierbei die Auflistung aller Konfigurationsparameter dieses Programms sowie deren Eigenschaften und Gültigkeitsbedingungen.

   Eine derartige Konfigurationsbeschreibung ist unabhängig von einer konkreten Applikationsinstanz, sondern beschreibt Aussehen und Charakteristik der Konfigurationen aller Applikationsinstanzen desselben Typs und derselben Version. Sie enthält keine konkreten Konfigurationsdaten, das heisst sie enthält keine den Konfigurationsparametern zugeordneten Werte.
Der Programmierer muss somit zunächst die einzelnen Konfigurationsparameter definieren, d.h. diejenigen Parameter des Anwendungsprogramms, welche vom Benutzer beeinflusst werden können. Weiters müssen die Attribute der einzelnen Konfigurationsparameter festgelegt werden.

   Dazu zählen der jeweils zulässige Datentyp für die Konfigurationsparameter, die Information, ob für einen bestimmten Konfigurationsparameter ein Vorgabewert (Default-Wert) vorhanden sein soll sowie gegebenenfalls die Angabe eines derartigen Vorgabewerts, die Information, ob es sich um einen "read only"-Parameter handeln soll, die Information, ob es sich um einen "static" (von mehreren Programminstanzen geteilten) Parameter handelt und dgl. Weiters müssen Gültigkeitsbedingungen für die einzelnen Konfigurationsparameter definiert werden, d.h. Bedingungen die erfüllt sein müssen, damit ein vom Benutzer ausgewählter Wert des Parameters als gültig angesehen wird. Im einfachsten Fall erfordert dies die Angabe eines erlaubten Wertebereichs für den Konfigurationsparameter.

   In komplizierteren Fällen hängt die Gültigkeit des Wert eines Konfigurationsparameters von mehreren anderen Parametern ab. Es muss somit für jedes Computerprogramm vom Programmierer eine bestimmte Konfigurationsmöglichkeit vorgegeben und definiert werden, wobei ergänzend sichergestellt werden soll, dass die Konfigurationsbeschreibung einheitlich vorliegt.
Im Rahmen der Erstellung eines Computerprogramms sind im Wesentlichen 3 Komponenten zu berücksichtigen, die mit Konfigurationsbeschreibungen zu tun haben. a) Das Anwendungsprogramm, um deren Konfiguration es sich handelt. Das Anwendungsprogramm liest die Konfigurationsdaten ein und berücksichtigt sie bei der Abarbeitung seiner Aufgaben.

   Findet das Programm bestimmte Konfigurationsdaten nicht, so nimmt es in der Regel einen in seinem Programmcode eincodierten Defaultwert an. b) Das Programm, das die Konfigurationsdaten in das Anwendungsprogramm schreibt. Dies kann ein gesondertes SetupProgramm sein, welches in der Regel beim erstmaligen Start des Anwendungsprogramms und somit beim erstmaligen Schreiben der Konfigurationsdaten zum Einsatz kommt oder eine eigene Applikation, die für das Anzeigen und Schreiben der Konfigurationsdaten zuständig ist. Es kann jedoch auch das Anwendungsprogramm selbst sein, in welchem eine Setup-Funktion integriert ist. c) Die Programmdokumentation, in der in der Regel alle Konfigurationsparameter, ihre Eigenschaften, Defaultwerte und Abhängigkeiten aufgelistet werden.

   Die Programmdokumentation kann als Programmhandbuch in Papierform oder auch als Onlinedokumentation in elektronischer Form vorliegen.
Dabei ist es wesentlich, dass die Konfigurationsbeschreibung in allen 3 Komponenten einheitlich vorliegt, damit es nicht zu Inkonsistenzen kommt. Ob allerdings tatsächlich beispielsweise die im Anwendungsprogramm definierten Konfigurationsmöglichkeiten mit den in der Programmdokumentation angegebenen Informationen übereinstimmen, hängt sehr vom Entwicklungsprozess und von der Genauigkeit des Erstellers des Anwendungsprogramms bzw. der Programmdokumentation ab.

   Oft ist es ab einer gewissen kritischen Grösse und Komplexität des Anwen dungsprogramms , selbst bei sehr gut durchdachten und organisierten Entwicklungsprozessen, nicht mehr möglich jede Eigenschaft und Abhängigkeit einzelner Konfigurationsparameter in der Programmdokumentation aktuell zu halten. Dieses Problem wird zusätzlich durch die oftmalige Überarbeitung von Computerprogrammen bei der Erstellung neuer Programmversionen erschwert.
Die Folgen einer Inkongruenz zwischen der Konfigurationsbeschreibung im Anwendungsprogramm und im Setup-Programm können anhand des folgenden Beispiels dargelegt werden.

   Bei einer Client-Applikation, die eine Verbindung zu einem Server herstellt und aufrecht erhalten kann, ist üblicher Weise ein Time-out zu konfigurieren, d.h. ein Wert der angibt, innerhalb welcher Zeitspanne ein Signal vom Server kommen muss, damit die Verbindung als aufrecht gilt. Im Programmcode der ClientApplikation kann beispielsweise ein Defaultwert von 2 min. angegeben sein. Die Installation der Client-Applikation wird von einem Setup-Programm durchgeführt. Dabei wird der Benutzer gefragt, ob er einen bestimmten Wert für den Time-out setzen will. Tut er dies nicht, so wird der Defaultwert in die Applikation geschrieben.

   Wenn nun aber im Setup-Programm im Unterschied zur Client-Applikation nicht 2 min. sondern beispielsweise 5 min. als Defaultwert implementiert sind, so wird ein Defaultwert von 5 in die Applikation geschrieben und es wird der Defaultwert der Applikation überlagert. Derartige Inkonsistenzen sind unerwünscht und sind insbesondere dann zu beobachten, wenn die Konfigurationsbeschreibung, wie oben beschrieben, an mehreren Quellen redundant vorliegt, nämlich beispielsweise im Anwendungsprogramm selbst, in einem Konfigurationsprogramm (Setup-Programm) und in der Programmdokumentation.
Die Erfindung zielt nun darauf ab, ein Verfahren anzugeben, das es dem Programmentwickler ermöglicht eine Konsistenz der an verschiedenen Orten gespeicherten Konfigurationsbeschreibungen zu erreichen.
Zur Lösung dieser Aufgabe besteht das erfindungsgemässe Verfahren im Wesentlichen darin,

   dass die Konfigurationsbeschreibung in standardisierter Form erfasst und in einer Datei gespeichert wird, dass die Konfigurationsbeschreibung einem Interpreter zugeführt wird und in einem Programmcodegenerator ein konfigurationsspezifischer Programmcode erstellt wird, welcher in den Programmcode des Anwendungsprogramms eingefügt wird und dass die in der Datei enthaltene Konfigurationsbeschreibung einem Dokumentationsgenerator zugeführt wird, in welchem die Programmdokumentation erstellt wird. Dadurch, dass die Konfiguration in standardisierter Form erfasst wird und die auf diese Weise erhaltene Konfigurationsbeschreibung in einer Datei gespeichert wird, wird sichergestellt, dass lediglich eine einzige Basis für die Konfigurationsbeschreibung vorhanden ist.

   Unter Datei ist in diesem Zusammenhang jede Form der Abspeicherung von Daten zu verstehen, wobei insbesondere die Abspeicherung in einer Datenbank, in einer sogenannten "Registry" oder dgl. in Frage kommt. Diese Datei dient hierbei als zentrale Konfigurationsbasis und enthält die Beschreibung der Konfiguration, welche in der Folge dem betreffenden Anwendungsprogramm, welches die entsprechenden Konfigurationsmöglichkeiten aufweisen soll, der Programmdokumentation und gegebenenfalls dem Konfigurationsprogramm zur Verfügung gestellt wird. Auf diese Art und Weise ist sichergestellt, dass alle die miteinander in Zusammenhang stehenden Komponenten, nämlich das Anwendungsprogramm, die Programmdokumentation und gegebenenfalls das Konfigurationsprogramm, auf dieselbe Konfigurationsbeschreibung zurückgreifen, sodass ausgeschlossen ist, dass Inkonsistenzen auftreten.

   Dadurch wird die Programmierung von Anwendungsprogrammen und Konfigurationsprogrammen sowie die Erstellung von Programmdokumentationen erheblich vereinfacht, wobei erfindungsgemäss vorgesehen ist, dass die konfigurationsspezifischen Teile des Anwendungsprogramms und der Programmdokumentation automatisiert auf Basis der oben genannten Datei generiert werden. Zu diesem Zweck ist erfindungsgemäss vorgesehen, dass die in der Datei enthaltene Konfigurationsbeschreibung einem Interpreter zugeführt wird und in einem Programmcodegenerator ein konfigurationsspezifischer Programmcode erstellt wird, welcher in den Programmcode des Anwendungsprogramms eingefügt wird.

   Der Programmierer muss beim Erstellen eines Computerprogramms somit lediglich zu al ler erst die Konfigurationsbeschreibung festlegen und in einer Datei abspeichern, wobei in der Folge der die Konfigurationsbeschreibung betreffende Teil des Anwendungsprogramms und die Programmdokumentation automatisiert erstellt werden, wodurch Fehlerquellen unterdrückt werden.

   Die Vorgabe an den Programmierer, zuerst die Konfigurationsbeschreibung festzulegen, führt zu einer zusätzlichen Verbesserung der Qualität des Computerprogramms .
Der Vorteil des erfindungsgemässen Verfahrens kommt insbesondere dann zum Tragen, wenn ein Anwendungsprogramm durch laufende Aktualisierungen in unterschiedlichen Programmversionen vorliegt, wobei, was den konfigurationsspezifischen Teil der Aktualisierung betrifft, lediglich die zentrale, die Konfigurationsbeschreibung enthaltende Datei aktualisiert werden muss, worauf die aktualisierte Konfigurationsbeschreibung dem Anwendungsprogramm der Programmdokumentation und gegebenenfalls dem Konfigurationsprogramm zur Verfügung gestellt werden, sodass alle relevanten Komponenten die gleiche Konfigurationsbeschreibung aufweisen.

   Aus den einzelnen Versionen der zentralen, die Konfigurationsbeschreibung enthaltenden Datei kann hierbei eine Historie der Konfigurationen erstellt werden, sodass die Fehlersuche vereinfacht und die Erstellung neuer Versionen erleichtert wird.
Wie bereits erwähnt, muss die Konfiguration zunächst in standardisierter Form erfasst werden, sodass die auf diese Weise erhaltene Konfigurationsbeschreibung in der Folge automatisiert weiter bearbeitet werden kann. Dabei kann bevorzugt vorgesehen sein, dass die in der Datei enthaltene Konfigurationsbeschreibung Angaben über Konfigurationsparameter sowie deren Attribute, Angaben über Bedingungen für die Gültigkeit von Werten für die Konfigurationsparameter, sowie Angaben über Abhängigkeiten zwischen einzelnen Konfigura ionsparametern umfassen.

   Zur Standardisierung wird hierbei bevorzugt wenigstens ein Teil der Konfigurationsbeschreibung in der Datei als XMLCode, d.h. in einer XML basierten Sprache gespeichert, wobei der XML-Code von einem XML-Parser interpretiert wird, worauf von einem Codegenerator ein konfigurationsspezifischer Programmcode erstellt und in den Programmcode des Anwendungspro 
- 6 -
gramms eingefügt wird. Der genannte konfigurationsspezifische Programmcode erlaubt dem Anwendungsprogramm in der Folge den Zugriff auf die Konfiguration. Der konfigurationsspezifische Programmcode kann hierbei bevorzugt dem Anwendungsprogramm in Form von Codebibliotheken zur Verfügung gestellt werden, welche in das zu erstellende Anwendungsprogramm eingebunden werden.

   Um diesen Code zu erstellen ist es jedoch notwendig die Konfigurationsbeschreibung aus der Datei zunächst auszulesen und zu interpretieren, wobei verschiedene inhaltliche Aspekte der Beschreibung interpretiert werden. Zunächst ist zu prüfen, ob es sich bei der vom Programmierer erstellten XML-Datei überhaupt um "well formed XML" handelt. Danach muss sichergestellt werden, dass die Struktur des XML-Inhalts der Datei der für Konfigurationsbeschreibung spezifizierten Standardisierung bzw. Struktur entspricht. Es ist daher zu prüfen, ob eine gegebene XML-Datei bezüglich dieser Standardisierung gültig ist oder nicht.

   Zu diesem Zweck kann ein XML-Parser in den Codegenerator eingebunden werden, welchem das standardisierte XMLSchema zur Verfügung steht, sodass er die vorliegende Konfigurationsbeschreibung überprüfen kann.
Wie bereits erwähnt, umfasst die Konfigurationsbeschreibung aber auch komplexere Inhalte, wie beispielsweise Gültigkeitsbedingungen für Konfigurationsparameterwerte und Abhängigkeiten zwischen den einzelnen Konfigurationsparametern. Derartige komplexere Zusammenhänge zwischen Parametern können aber nur durch einen entsprechenden Scriptcode dargestellt werden, wofür eine geeignete Scriptsprache verwendet werden soll. Der entsprechende Scriptcode wird vom Programmierer hierbei direkt in die XML-Datei eingebunden, wobei es Aufgabe des Programmcodegenerators ist diesen Scriptcode zu interpretieren.

   Zu diesem Zweck ist bevorzugt ein entsprechender Scripinterpreter für die gewählte Sprache vorgesehen, welcher die Einhaltung der einzelnen Gültigkeitsbedingungen und/oder Abhängigkeiten überprüft.
Der Programmcodegenerator, welcher aus den ausgelesenen und interpretierten Konfigurationsdaten einen konfigurationsspezifischen Programmcode erstellt, muss derart ausgebildet sein, dass er alle Konfigurationsparameter und deren Eigen -
- 7 -
Schäften versteht, Zugriffsfunktionen entsprechend der Eigenschaften der Konfigurationsparameter generiert und komplexe Konfigurationsparameter durch Generierung geeigneter Datentypen und Zugriffsfunktionen unterstützt. Der Codegenerator liefert einen Programmcode für den Zugriff auf die verwalteten Konfigurationen.

   Dieser Code kann in Form einer Codebibliothek zur Verfügung stehen, wobei standardmässig der Codegenerator 3 Zielsprachen unterstützen kann, nämlich beispielsweise C, C++ und Visual Basic 6. Daneben kommen auch noch andere Sprachen, wie beispielsweise Java und .NET in Frage. Im Falle von C und C++ generiert der Programmcodegenerator entsprechende "header files", in denen die angebotenen Zugriffsfunktionen deklariert sind. Der Zugriffscode selbst wird in Form einer Bibliothek angeboten, die statisch zum Anwendungsprogramm gelinkt wird.

   Im Falle von Visual Basic 6 wird ein "COM-Objekt" mit einer zugehörigen "Type Library" erstellt.
Damit das Anwendungsprogramm bzw. die Codebibliothek auf die tatsächlichen Konfigurationsdaten zugreifen kann ist bevorzugt vorgesehen, dass in dem Programmcodegenerator eine Datei für Konfigurationsdaten, wie beispielsweise eine Datenbank, sowie ein transaktionales Interface und eine Zugriffsschicht erstellt werden, sodass das Anwendungsprogramm bzw. die Codebibliothek über das transaktionales Interface und die Zugriffsschicht auf die in der Datei gespeicherten Konfigurationsdaten zugreifen können.
Die vom Programmcodegenerator generierten Funktionen können Zugriff sowohl auf die eigene Konfiguration als auch auf die anderer Applikationen bieten, sofern sie ebenfalls unter Anwendung des erfindungsgemässen Verfahrens erstellt wurden.

   Im Codegenerator müssen hierbei lediglich die entsprechenden Konfigurationsbeschreibungen vorliegen. Um einzelnen Anwendungsprogrammen die Möglichkeit zu geben auf Konfigurationsänderungen zu reagieren, kann ein geeigneter Notifikationsmechanismus vorgesehen sein. Das Anwendungsprogramm, bei welchem die Konfiguration geändert wurde, kann hierbei andere Anwendungsprogramme benachrichtigen, welche Parameter geändert wurden, sodass bei den anderen Anwendungsprogrammen nicht alle Konfigurationen neu eingelesen werden müssen sondern lediglich die 
- 8 von der Änderung betroffenen Konfigurationsparameter.
Wie bereits erwähnt, ist erfindungsgemäss ein Dokumentationsgenerator vorgesehen, in welchem die Programmdokumentation erstellt wird.

   Aufgabe des Dokumentationsgenerators ist es hierbei aus der in der Datei vorhandenen zentralen Konfigurationsbeschreibung eine vollständige, korrekte, sowohl online verfügbare als auch druckbare Dokumentation zu generieren. Der Dokumentationsgenerator parst die zentrale Datei, um sämtliche Parameter sowie deren Eigenschaften und Abhängigkeiten zu erfassen.

   Auf diese Weise wird sichergestellt, dass die Dokumentation der Konfigurationsmöglichkeiten eines Anwendungsprogramms immer auf aktuellem Stand ist, und dass z.B. die dokumentierten Defaultwerte immer mit den von dem Anwendungsprogramm tatsächlich angewandten Werten übereinstimmen.
Was die Darstellung der Gültigkeitsbedingungen für die Parameterwerte und die Abhängigkeiten zwischen einzelnen Konfigurationsparametern betrifft, wird unterschieden, ob es sich um einfache in XML abbildbare Abhängigkeiten handelt oder nicht. Im ersteren Fall wird die generierte Dokumentation vom Dokumentationsgenerator ohne Probleme in graphisch ansprechender Form ausgegeben. Im anderen Fall, in welchem die Abhängigkeiten lediglich durch Scripts dargestellt werden können, wird der entsprechende Scriptcode in der Programmdokumentation angezeigt.

   Jedoch besteht ergänzend die Möglichkeit auch Bemerkungen und Erklärungen, die der Entwickler in Form von Kommentaren angegeben hat, ebenfalls anzuzeigen.
Der Output des Dokumentationsgenerators kann in Form einer Mehrzahl von html-Files erfolgen. Diese können dann relativ leicht in eine Konfigurationsmaske eingebunden werden und damit als Online-Hilfe verwendet werden. Da das html-Format zum Ausdrucken weniger geeignet erscheint, kann zusätzlich die Dokumentation in bevorzugter Weise im pdf-Format ausgegeben werden.
Die Erfindung wird nachfolgend anhand eines in der Zeichnung schematisch dargestellten Beispieles näher erläutert. In dieser ist ein Blockschaltbild der einzelnen entwicklerseitigen Komponenten 1 und der anwenderseitigen Komponenten 2 dargestellt.

   Als Ausgangspunkt dient auf der Entwicklerseite bei - 9 -
der Entwicklung eines Anwendungsprogramms der Applikationscode 3 sowie die in standardisierter Form zu erfassende Konfigurationsbeschreibung, welche in einer Datei 4 abgelegt wird. Die Konfigurationsbeschreibung 4 wird einem Programmcodegenerator 5 übergeben, welcher sowohl einen Interpreter 6 für die in der Datei 4 in XML-Format abgespeicherte Konfigurationsbeschreibung als auch einen Interpreter 7 für die in der Datei 4 als Scriptcode vorliegende Konfigurationsbeschreibung auf. Der Applikationscodegenerator 5 soll nun einen Programmcode liefern, welcher den Zugriff auf die Konfigurationsdaten erlaubt. Im Fall, dass der Programmcode in C bzw.

   C++ vorliegen soll, generiert der Programmcodegenerator 5 entsprechende "header files" 8, welche in einem C/C++ Compiler 9 gemeinsam mit dem Applikationscode 3 verarbeitet und an diesen angefügt werden, wobei Objektcode 10 ausgegeben wird. Der Objektcode 10 wird in einem Linker 11 mit den ebenfalls vom Applikationsgenerator 5 erzeugten Codebibliotheken 12 verknüpft. Auf diese Weise wird das Anwendungsprogramm 13 erstellt, welches unter anderem die Codebibliothek 12 sowie den konfigurationsspezifischen Programmcode umfasst.

   Die Konfigurationsdaten selbst können hierbei ebenfalls in dem Anwendungsprogramm 13 abgespeichert werden. Üblicherweise steht hierfür aber eine gesonderte Datei, wie beispielsweise die Datenbank 19 zur Verfügung, auf welche das Anwendungsprogramm 13 bzw. die Codebibliothek 12 über ein transaktionales Interface 20 und eine Zugriffsschicht 21 zugreifen kann, welche ebenfalls vom Codegenerator bereitgestellt werden.
Entwicklerseitig ist auch ein Dokumentationsgenerator 14 vorgesehen, welcher einen XSLT-Prozessor 15 aufweist, der unter Verwendung der entsprechenden XSLT für pdf 22 und XSLT für html 23 die Programmdokumentation als Entwicklerhandbuch 16, PDF-Dokumentation 17 und HTML-Dokumentation 18 erstellt.


Claims (9)

aa> - 10 - P a t e n t a n s p r ü c h e
1. Verfahren zum Vereinheitlichen von Konfigurationsbeschreibungen in Anwendungsprogrammen, der dazugehörigen Programmdokumentation sowie gegebenenfalls dem dazugehörigen Konfigurationsprogramm, dadurch gekennzeichnet, dass die Konfigurationsbeschreibung in standardisierter Form erfasst und in einer Datei gespeichert wird, dass die in der Datei enthaltene Konfigurationsbeschreibung einem Interpreter zugeführt wird und in einem Programmcodegenerator ein konfigurationsspezifischer Programmcode erstellt wird, welcher in den Programmcode des Anwendungsprogramms eingefügt wird und dass die in der Datei enthaltene Konfigurationsbeschreibung einem Dokumentationsgenerator zugeführt wird, in welchem die Programmdokumentation erstellt wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die in der Datei enthaltene Konfigurationsbeschreibung Angaben über Konfigurationsparameter sowie deren Attribute, Angaben über Bedingungen für die Gültigkeit von Werten für die Konfigurationsparameter, sowie Angaben über Abhängigkeiten zwischen einzelnen Konfigurationsparametern umfassen.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass wenigstens ein Teil der Konfigurationsbeschreibung in der Datei als XML-Code gespeichert wird und dass der Interpreter einen XML-Parser aufweist.
4. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass wenigstens ein Teil der Konfigurationsbeschreibung in der Datei als Scriptcode gespeichert wird und dass der Interpreter einen Scriptinterpreter umfasst.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass der konfigurationsspezifische Programmcode dem Programmcode des Anwendungsprogramms in Form von Codebibliotheken zur Verfügung gestellt wird.
6. Verfahren nach einem er Ansprüche 1 bis 5 , dadurch gekennzeichnet, dass in dem Programmcodegenerator eine Datei für Konfigurationsdaten, wie beispielsweise eine Datenbank, sowie ein transaktionales Interface und eine Zugriffsschicht - 11 -
erstellt werden, sodass das Anwendungsprogramm bzw. die Codebibliothek über das transaktionales Interface und die Zugriffsschicht auf die in der Datei gespeicherten Konfigurationsdaten zugreifen können.
7. Verfahren nach einem der Ansprüche 1 bis 6 , dadurch gekennzeichnet, dass in wenigstens einer Datei Konfigurationsbeschreibungen für eine Mehrzahl von Anwendungsprogrammen gespeichert werden und der konfigurationsspezifische Programmcode erstellt wird, sodass die Mehrzahl von Anwendungsprogrammen auf die jeweils eigenen Konfigurationsdaten als auch auf die jeweils anderen Konfigurationsdaten zugreifen können.
8. Verfahren nach einem der Ansprüche 1 bis 7 , dadurch gekennzeichnet, dass der Dokumentationsgenerator zur Ausgabe der Dokumentation im pdf-Format oder html-Format ausgebildet ist.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass der Dokumentationsgenerator Mittel zum Auslesen der Konfigurationsdaten, wie beispielsweise der Konfigurationsparameter, Gültigkeitsbedingungen und dgl., aus der Datei aufweist.
Wien, am 14. Dezember 2004 International AG i
Dr. Haffner <EMI ID=11.1>
AT0209604A 2004-12-14 2004-12-14 Verfahren zum verwalten von konfigurationsdaten AT501112A2 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AT0209604A AT501112A2 (de) 2004-12-14 2004-12-14 Verfahren zum verwalten von konfigurationsdaten
AT0803808U AT10304U1 (de) 2004-12-14 2008-04-28 Verfahren zum verwalten von konfigurationsdaten

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
AT0209604A AT501112A2 (de) 2004-12-14 2004-12-14 Verfahren zum verwalten von konfigurationsdaten

Publications (1)

Publication Number Publication Date
AT501112A2 true AT501112A2 (de) 2006-06-15

Family

ID=36578721

Family Applications (2)

Application Number Title Priority Date Filing Date
AT0209604A AT501112A2 (de) 2004-12-14 2004-12-14 Verfahren zum verwalten von konfigurationsdaten
AT0803808U AT10304U1 (de) 2004-12-14 2008-04-28 Verfahren zum verwalten von konfigurationsdaten

Family Applications After (1)

Application Number Title Priority Date Filing Date
AT0803808U AT10304U1 (de) 2004-12-14 2008-04-28 Verfahren zum verwalten von konfigurationsdaten

Country Status (1)

Country Link
AT (2) AT501112A2 (de)

Also Published As

Publication number Publication date
AT10304U1 (de) 2008-12-15

Similar Documents

Publication Publication Date Title
DE10051645B4 (de) Prozesssteuersystem und Verfahren zum Kontrollieren eines Prozesses
DE10121790B4 (de) Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem
EP1723513B1 (de) Verfahren zur konfiguration eines computerprogramms
DE102005028675A1 (de) Aktualisierungs- und Transformationssystem für strukturierte Daten
DE102004009676A1 (de) Verfahren und Systeme zum Erzeugen von Unterstützungsdateien für Befehle
DE69907714T2 (de) Komponentbasiertes quellcodegeneratorverfahren
DE102005025401A1 (de) Datentransformationssystem
DE102010011652A1 (de) Applikationsplattform und Verfahren zum Betrieb einer Datenverarbeitungseinrichtung mit einer solchen
AT501112A2 (de) Verfahren zum verwalten von konfigurationsdaten
EP1609061A2 (de) Verfahren und anordnung zur veränderung von software oder quellcode
DE60010078T2 (de) System zur analyse von daten für den elektronischen handel
WO2001086402A2 (de) Anzeigesteuerung mit aktiven hypertextdokumenten
DE10233971A1 (de) Verfahren und Vorrichtung zur Erzeugung von Software
EP1343078B1 (de) System zur Modellierung und Generierung von Softwaregenerierungssystemen
EP1691275B1 (de) Verfahren und Vorrichtung zum rechnergestützten Erzeugen einer graphischen Benutzeroberfläche
EP1388785A1 (de) Verfahren und Vorrichtung zur Transformation von Software- und Hardwaremodellen
EP1044409B1 (de) Programmablaufverfahren und verfahren zur erweiterung eines programmkomponentensystems
EP2093663A1 (de) Engineering-System für die Entwicklung eines Projektes und Verfahren
EP3940553A1 (de) Verfahren zum bereitstellen sicherheitsrelevanter daten mittels eines serversystems, serversystem und computerprogrammprodukt
EP1691274B1 (de) Verfahren und Vorrichtung zum rechnergestützten Erzeugen einer graphischen Benutzeroberfläche auf einem Anzeigemittel
DE202013003793U1 (de) Datenträger mit darauf gespeicherten Daten sowie eine Daten repräsentierende Signalfolge zur Gewährleistung der Funktionsfähigkeit eines technischen Systems im Hinblick auf dessen Konfiguration im Rahmen einer Installation bzw. Beseitigung von Komponenten
WO2014173505A1 (de) Verfahren zur gewährleistung der funktionsfähigkeit eines technischen systems im hinblick auf dessen konfiguration im rahmen einer installation bzw. beseitigung von komponenten
DE10129147B4 (de) Verfahren und Datenverarbeitungs-System zum Entwicklen von Software im Internet-, Netzwerk- und/oder Anwendungssoftware-Bereich für einen Webserver
EP2175331A1 (de) Steuerbares Gerät mit einem Steuerprogramm und Verfahren zum Steuern des Geräts
DE102005058218A1 (de) Verfahren und Vorrichtung zur Erzeugung von Dialogen für ein Bedien- und Beobachtungssystem

Legal Events

Date Code Title Description
UW Change of intellectual property right

Effective date: 20160515