WO2005076129A1 - Verfahren zur konfiguration eines computerprogramms - Google Patents

Verfahren zur konfiguration eines computerprogramms Download PDF

Info

Publication number
WO2005076129A1
WO2005076129A1 PCT/EP2005/050289 EP2005050289W WO2005076129A1 WO 2005076129 A1 WO2005076129 A1 WO 2005076129A1 EP 2005050289 W EP2005050289 W EP 2005050289W WO 2005076129 A1 WO2005076129 A1 WO 2005076129A1
Authority
WO
WIPO (PCT)
Prior art keywords
implementation
configuration
computer program
configuration data
configuration file
Prior art date
Application number
PCT/EP2005/050289
Other languages
English (en)
French (fr)
Inventor
Rene Schenk
Bjoern Beuter
Klaus Schneider
Bernd Illg
Original Assignee
Robert Bosch Gmbh
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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to US10/588,596 priority Critical patent/US8365163B2/en
Priority to JP2006551837A priority patent/JP5209209B2/ja
Priority to DE502005005190T priority patent/DE502005005190D1/de
Priority to EP05701596A priority patent/EP1723513B1/de
Publication of WO2005076129A1 publication Critical patent/WO2005076129A1/de
Priority to KR1020067015780A priority patent/KR101154730B1/ko

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/02—Digital function generators
    • G06F1/03—Digital function generators working, at least partly, by table look-up
    • G06F1/0307—Logarithmic or exponential functions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/12—Digital output to print unit, e.g. line printer, chain printer
    • G06F3/1201—Dedicated interfaces to print systems
    • G06F3/1223—Dedicated interfaces to print systems specifically adapted to use a particular technique
    • G06F3/1237—Print job management
    • G06F3/1253—Configuration of print job parameters, e.g. using UI at the client
    • G06F3/1254—Automatic configuration, e.g. by driver
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs

Definitions

  • the invention relates to a method for configuring a computer program comprising at least one functional unit.
  • the invention also relates to a software system for configuring a computer program comprising at least one functional unit.
  • the area of application is determined on the one hand by the functionalities provided, which in turn are intended to cover as many user requests as possible, and on the other hand by the underlying hardware on which the computer program is to run.
  • the underlying hardware here denotes different computer systems that are used in different areas, are made up of different components (for example processors or bus systems) and / or have different peripheral devices.
  • a configuration includes, for example, activating or deactivating individual functions of the
  • Computer programs are usually created in a so-called high-level language, for example C, C ++, Scheme or JAVA.
  • a computer program created in a high-level language is usually referred to as source code.
  • source code In order to be able to execute such a computer program on a computer, a so-called machine code must be generated from the source code, which contains instructions that can be executed by the processor of the computer. Machine code can be generated by interpreting or compiling the source code.
  • a computer program typically comprises a large number of functional units.
  • the source code of one or more functional units is stored in a file.
  • a header file is assigned to one or more such files.
  • a computer program typically consists of a large number of files.
  • Configuration of such a computer program which is carried out by changes within individual header files, is therefore very confusing and can often only be carried out by the creator of the source code.
  • documentation of all header files has to be created, which is very time-consuming, although even the documentation is usually very confusing.
  • the object of the invention is therefore to create a possibility that allows a computer program to be configured as clearly and flexibly as possible.
  • the object is achieved by a method of the type mentioned at the outset, which comprises the following steps: creating at least one implementation-independent configuration file and / or changing information stored in the at least one implementation-independent configuration file; automatic construction and / or automatic updating of configuration data stored in a configuration data container as a function of the information stored in the at least one implementation-independent configuration file; automatic generation of at least one implementation-dependent configuration file depending on the configuration data stored in the configuration data container; , .. automatic configuration of the at least one functional unit depending on information stored in the at least one implementation-dependent configuration file.
  • the data determining a configuration is therefore stored in one or more implementation-independent configuration files, regardless of an intended concrete implementation.
  • the implementation independence of this configuration file enables in particular an abstract description of the stored information. This enables the configuration of the computer program store relevant information in a particularly legible manner and thus simplify configuration significantly. Because this configuration file is implementation-independent, it is in particular possible to easily configure the computer program, so that the computer program can run, for example, on a new computer system, the exact parameters of which were not yet known when the computer program was created.
  • the configuration data container enables all data relevant for a configuration to be stored centrally.
  • At least one implementation-dependent configuration file is automatically generated by means of the configuration data stored in the configuration data container.
  • one or more parameter values are specified with respect to the implementation-independent configuration file. With such a specification, for example, relative values are replaced by absolute values. Certain data types or structures can also be assigned to individual values or data areas.
  • the implementation-dependent configuration file consequently takes into account implementation-dependent properties, such as, for example, one or more programming languages used in programming the source code or properties of the hardware on which the computer program is to run.
  • the configuration data container can be constructed or updated using the information stored in the implementation-independent configuration files, for example using so-called scripts.
  • a script is a sequence of commands issued by a special computer program can be executed.
  • Such special computer programs are, for example, AWK or Perl. These special computer programs can also be used to generate implementation-dependent configuration files from the configuration data stored in the configuration data container.
  • An essential part of the invention is the realization that the configuration of a computer program can be decisively improved by providing an abstract description of the configuration to be carried out in the implementation-independent configuration file between the user (configurator) and the computer program, which is used as the basis for the configuration.
  • an implementation-dependent configuration file is automatically created, which is then used to configure the computer program.
  • At least one dependency information item which describes a dependency on at least two configuration data contained in the configuration data container, is generated automatically.
  • the at least one implementation-dependent configuration file is generated as a function of the at least one dependency information.
  • Dependency information can describe, for example, whether the change in one configuration parameter affects another configuration parameter. If, for example, a resource is reserved exclusively for a functional unit, it is not available to other functional units during the execution of the functional unit.
  • Dependency information can be used to determine which functional units require a certain resource and therefore cannot run simultaneously.
  • Dependency information can therefore also be used for resource management.
  • each of the implementation-independent configuration files is assigned to at least one functional unit.
  • This enables a particularly simple configuration in that the configuration parameters stored as information in the implementation-independent configuration files can be found and changed particularly easily. For example, it is possible to arrange the information determining a configuration, that is to say the configuration parameters, according to the functionality or hardware influenced by them. This also enables a particularly simple adaptation of the implementation-independent configuration files to newly added functional units. In the simplest case, a newly added functional unit is assigned a special implementation-independent configuration file.
  • implementation-dependent configuration files are generated and at least each of the implementation-dependent configuration files assigned to a functional unit. Structuring the implementation-dependent configuration files in this way increases the clarity of the implementation-dependent configuration files generated. If the source code is structured in such a way that one or more functional units are located in different files, it can be achieved that each of the files of the source code is assigned an implementation-dependent configuration file. A particularly clear structuring can also be achieved by assigning an implementation-dependent configuration file to each implementation-independent configuration file.
  • the at least one implementation-dependent configuration file is preferably generated as a function of at least one property of hardware on which an installation of at least part of the configured computer program is to be made possible.
  • a hardware property can be, for example, the number of processors available or the type and number of sensors connected to the hardware. If such hardware properties are taken into account when generating the implementation-dependent configuration files, the computer program can be configured particularly precisely. This makes it possible, for example, to automatically create a configuration that is optimized with regard to the speed of execution, in particular with dependency information.
  • the at least one implementation-dependent configuration file is dependent on the result of a plausibility check generated.
  • a plausibility check can include, for example, checking whether a resource required by a functional unit is available at all.
  • the sensor Before the acquisition of measured values, it can be checked whether suitable sensors are available and whether they provide the requested measurement accuracy. In this case it is conceivable, for example, that the sensor is configured automatically.
  • documentation is created automatically.
  • the documentation describes the information stored within the at least one implementation-independent configuration file and / or the at least one implementation-dependent configuration file. Documentation generated automatically in this way increases the maintainability of the computer program on the one hand and on the other hand makes it particularly easy to understand a configuration that has been carried out.
  • the automatic generation of the documentation ensures that it matches the actual configuration. If a new configuration of the computer program is to be carried out, such documentation can be used to determine particularly easily which parameter values have to be changed.
  • the at least one implementation-independent configuration file is preferably created in an XML-based format.
  • XML Extensible Markup Language
  • At least one implementation-independent configuration file is created in an XML-compliant, structured language
  • configuration is made easier by the fact that such an implementation-independent configuration file is particularly easy to read.
  • Such a configuration file is also particularly easy to read by machine.
  • software tools tools
  • Functional unit is required by the computer program and this functional unit is only configured if the functional unit is required by the computer program. This enables a configuration to be carried out particularly quickly by actually configuring only those functional units which are actually required when the configured computer program is executed. Furthermore, it is achieved that the configured computer program takes up as little storage space as possible, since, for example, a translation of source code into machine code is only initiated for those functional units that are actually to be used.
  • the task is also solved by a software system of the type mentioned at the beginning.
  • the software system has:
  • a configuration data container comprising configuration data and / or means for creating a configuration data container as a function of information stored in the at least one implementation-independent configuration file; - Means for changing and / or reading configuration data from the configuration data container; Means for automatically generating at least one implementation-dependent configuration file in dependence on configuration data stored in the configuration data container; and means for automatically configuring the at least one functional unit as a function of information stored in the implementation-dependent configuration file.
  • the software system preferably has means for carrying out the method according to the invention.
  • the implementation of the invention in the form of a software system is of particular importance.
  • the software system can run on a computing device, in particular on a microprocessor, and is suitable for executing the method according to the invention.
  • the invention is thus implemented by the software system, so that the software system represents the invention in the same way as the method for which the software system is suitable.
  • the software system is preferably stored on a storage element.
  • the memory element can be designed as random access memory, read-only memory or flash memory.
  • the storage element can also be designed as a digital versatile disc (DVD), compact disc (CD) or as a hard disk (hard disc).
  • Figure 1 shows an embodiment of a software system for performing the method according to the invention.
  • Figure 2 is a schematic flow diagram of an embodiment of the method according to the invention.
  • the software system has several implementation-independent configuration files 1.
  • a file name is assigned to each configuration file 1.
  • the implementation-independent configuration files shown in Figure 1 carry for example the file names conf_l.xml, conf_2.xml, conf_3.xml to conf_n.xml.
  • the file extension .xml indicates that the implementation-independent configuration files 1 are in an XML-based format.
  • a text file in an XML-based format enables the text file to be structured according to predefinable rules. Such a structured text file can be read and processed particularly well manually and by machine.
  • Script 2 is designed, for example, as a so-called Perl script.
  • Perl is an interpreter language whose syntax is based on the C programming language and uses the utility programs provided by the respective operating system.
  • the implementation-independent configuration files 1 are read by means of the script 2 and the information stored therein is extracted and stored in a configuration data container 3. At the same time, any existing dependencies on the further configuration scripts 4 are also determined and stored.
  • Additional configuration scripts are shown with reference number 4. These are also designed as pearl scripts. It is also conceivable that one or more of the further configuration scripts 4 is an executable computer program (machine code) or is available in another script language, for example AWK.
  • the reference number 5 designates implementation-dependent configuration files.
  • the Implementation-dependent configuration files 5 are coded, for example, in the programming language in which the source code to be configured is also programmed. Such implementation-dependent configuration files can be processed by a compiler 6.
  • a computer program is shown at 7, which has a plurality of functional units 8.
  • Computer program starts in a step 100.
  • a step 101 implementation-independent configuration files 1 are created or changed.
  • the implementation-independent configuration files 1 are distinguished in particular by the fact that it is possible to use the information stored there to describe concrete configuration values or configuration parameters in an abstract manner. For example, specific configuration values can determine the measuring range of a sensor module for measuring an electrical voltage.
  • the implementation-dependent values of the measuring range to be generated therefrom, as expected by the functional unit 8 to be configured can, however, be between 10,000 and 20,000, for example.
  • a functional unit 8 of the computer program that controls the sensor module would have to be configured, for example, using the specific configuration values 10,000 and 20,000. to enable a measurement in a measuring range of 3 - 5 volts.
  • step 101 The implementation-independent created or modified in step 101
  • Configuration files 1 are created, for example, in an XML-based format. Such a format makes it particularly easy to achieve a clear structuring of the implementation-independent configuration files 1. This increases the readability of the implementation-independent configuration files 1 and simplifies the change in the implementation-independent configuration files 1, for example, in that configuration data to be changed can be found quickly. It is possible even for a particularly large one
  • a structuring of the information stored in the implementation-independent configuration file 1 can be achieved by suitable XML structures.
  • Each of these implementation-independent configuration files 1 can be assigned to one or more functional units 8, for example. This makes it possible to create or change the implementation-independent configuration files in a particularly clear manner. This also increases the reusability of individual implementation-independent configuration files. This is particularly advantageous for projects in which individual functional units 8 of the source code are also to be reused.
  • the configuration data container 3 is set up or updated. This is done by processing the instructions listed in Script 2.
  • Script 2 firstly causes the independent configuration files 1 to be read in. If the implementation-independent configuration files 1 are based on a structured format, for example an XML-based format, the script 2 can be used to perform a syntactic and / or semantic analysis of the content of the implementation-independent configuration files 1 particularly well. This can be used, for example, to detect errors when specifying configuration data.
  • the XML-based format of the implementation-independent configuration files 1 preferably has a hierarchical structure, which is advantageously based on the structure of the functional units 8 themselves, their dependencies and / or their thematic proximity. Using script 2, errors in the construction of this hierarchical structure and thus also in the construction of the source code itself can be recognized.
  • Step 102 advantageously has a treatment of the errors found. This can be done, for example, by outputting error information. It is also conceivable that stochastic methods are used to eliminate errors.
  • step 102 the script 2 extracts the configuration data present in the implementation-independent configuration files 1 and stores them in the
  • Configuration data container 3 can be designed, for example, as a database. It is also conceivable that the configuration data container 3 as in one Data structure stored in the memory area is implemented within the software system according to the invention, it being ensured that the script 2 has write and read access to the configuration data stored in the configuration data container 3.
  • Dependencies are determined in a step 103. Such a dependency can, for example, describe which functional units 8 of the computer program actually have to be processed in the present configuration. These dependencies can be used to decide whether an implementation-dependent configuration file has to be generated for a specific functional unit 8 in one of the following steps. Dependencies can also describe which specific configuration data depend on which abstract configuration data. It is conceivable that changing an abstract configuration date in an implementation-independent configuration file is a
  • Dependencies can also arise if the other scripts 4 in turn change the configuration container 3.
  • the correct call sequence (activation sequence) of scripts 4 must therefore be determined and stored.
  • Dependencies can also describe relationships between one or more hardware components and individual configuration data. This makes it possible, for example, to recognize whether a proposed configuration is actually executable on a specific hardware.
  • a plausibility check is carried out.
  • the dependencies determined in step 103 are used to check whether the configuration specified by means of the implementation-independent configuration files 1 has errors. If this is the case, the process branches back to step 101, in which a change to the implementation-independent configuration files 1 is carried out with the purpose of eliminating errors. If no errors are detected in step 104, a branch is made to step 105.
  • step 105 the implementation-dependent configuration files 5 are generated.
  • the configuration data stored in the configuration data container 3 are first retrieved using a script 4 or a plurality of scripts 4.
  • the scripts 4 are designed as pearl scripts.
  • Scripts 4 are used to convert, in particular, abstract configuration data stored in the configuration data container 3 into concrete configuration data, which are then stored in the implementation-dependent configuration files 5.
  • the dependencies determined in step 103 are preferably also used here.
  • implementation-dependent configuration files 5 may, for example, header files (file_.h, file_3.h file_2.h in Figure 1) be.
  • the implementation-dependent configuration files 5 generated can also contain source code (file_2.c, file_k.c in FIG. 1).
  • the concrete configuration data generated by the scripts 4 from the abstract configuration data is by value assignments for variables and / or function parameters and implemented as instructions in a programming language.
  • the programming language corresponds to the programming language in which the functional units 8 of the computer program 7 are encoded. If the functional units 8 of the computer program 7 are coded, for example, in the programming language C ++ , the specific configuration data can be implemented, for example, by so-called #define instructions or by defining constant variables.
  • scripts 4 it is also possible, depending on the configuration data stored in configuration data container 3, to generate functions that take on complex tasks - such as the initialization of hardware components or checking for the presence of individual software components or hardware components - and even as source code are realized in a higher programming language.
  • This source code can then be stored in one or more implementation-dependent configuration files (file_2.c, file_k.c in FIG. 1).
  • a script 4 can contain, for example, a so-called template, which, for example, consists of instructions in C ++ that are updated depending on the configuration data stored in the configuration data container 3 and are stored in an implementation-dependent configuration file 5.
  • a step 107 the functional units 8 of the computer program 7 are updated. This can be done, for example, by automatically calling a compiler 6 which has a source code
  • Functional units 8 translated into a machine code For this purpose, the compiler 6 reads the implementation-dependent configuration files 5 and controls the generation of the machine code in dependence on the in the implementation-dependent configuration files 5 stored concrete configuration data. It is also conceivable that one or more functional units 8 already exist in machine code. In this case, the compiler can, for example, translate the source code generated by the scripts 4 (file_2c, file_kc in FIG. 1) into machine code, taking into account the header files (file_l.h, file_2.h, file_3.h), and thus translate it Machine code by means of a so-called linker assigned to the compiler 6 with which the
  • the method ends in a step 108.
  • the computer program 7 is configured such that the specific configuration data stored in the implementation-independent configuration files are taken into account in the generated machine code.
  • script 2 and / or the scripts 4 are written in another script language or are designed as executable programs.
  • the execution steps shown in FIG. 2 can of course vary and the order of execution can be partially changed. It is conceivable that the plausibility check 104 is carried out by one or more of the scripts 4.
  • the method can also start from one or more implementation-independent configuration files, have one or more scripts 2, which are executed one after the other, for example, have one or more scripts 4, each of which has one or more Generate implementation-dependent configuration files 5 and of course the computer program 7 can have one or more functional units 8.
  • the method according to the invention it is in particular possible to recognize whether one or more of the functional units 8 are actually used in the configuration specified by the implementation-independent configuration files. If this is not the case, this can be recognized by a software tool, not shown, assigned to the configuration data container 3.
  • This makes it possible for such a functional unit 8 not to be configured and for the compiler 6, by means of the implementation-dependent configuration files 5, to not include the functional unit 8 in the machine code to be generated.
  • the machine code generated by a computer program that was configured by means of the method according to the invention can be particularly compact and thus save memory space.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Logic Circuits (AREA)
  • Input From Keyboards Or The Like (AREA)

Abstract

Um ein mindestens eine Funktionseinheit umfassendes Computerprogramm besonders einfach und flexibel zu konfigurieren wird ein Verfahren vorgeschlagen, das die folgenden Schritte umfasst: Erstellen mindestens einer implementierungsunabhängigen Konfigurationsdatei und/oder Änderung von in der mindestens einen implementierungsunabhängigen Konfigurationsdatei abgelegten Informationen; Automatischer Aufbau und/oder automatische Aktualisierung von in einem Konfigurationsdatencontainer abgelegten Konfigurationsdaten in Abhängigkeit von den in der mindestens einen implementierungsunabhängigen Konfigurationsdatei abgelegten Informationen; Automatisches Erzeugen mindestens einer implementierungsabhängigen Konfigurationsdatei in Abhängigkeit von den in dem Konfigurationsdatencontainer abgespeicherten Konfigurationsdaten; Automatische Konfiguration der mindestens einen Funktionseinheit in Abhängigkeit von in der mindestens einen implementierungsabhängigen Konfigurationsdatei abgelegten Informationen.

Description

Verfahren zur Konfiguration eines Computerprogramms
Die Erfindung betrifft ein Verfahren zur Konfiguration eines mindestens eine Funktionseinheit umfassenden Computerprogramms .
Die Erfindung betrifft auch ein Softwaresystem zur Konfiguration eines mindestens eine Funktionseinheit umfassenden Computerprogramms.
Stand der Technik
Moderne Computerprogramme werden überwiegend so programmiert, dass sie in einem möglichst breiten Anwendungsbereich einsetzbar sind. Der Anwendungsbereich wird einerseits durch die zur Verfügung gestellten Funktionalitäten, die wiederum möglichst viele Benutzerwünsche abdecken sollen, und andererseits durch die zugrunde liegende Hardware, auf der das Computerprogramm ablaufen soll, bestimmt. Die zugrunde liegende Hardware bezeichnet hierbei unterschiedliche Computersysteme, die in unterschiedlichen Bereichen eingesetzt werden, aus unterschiedlichen Komponenten (beispielsweise Prozessoren oder Bussystemen) aufgebaut sind und/oder über unterschiedliche Peripheriegeräte verfügen.
Unterschiedliche Funktionalitäten können sich aus unterschiedlichen Gegebenheiten der zugrunde liegenden Hardware ergeben oder aus unterschiedlichen Benutzerwünschen. Eine Anpassung und damit eine Spezialisierung eines Computerprogramms an eine zugrunde liegende Hardware und an bestimmte Benutzerwünsche umfasst eine sogenannte Konfiguration des Computerprogramms .
Eine Konfiguration umfasst beispielsweise das Aktivieren oder Deaktivieren einzelner Funktionen des
Computerprogramms, das Setzen von Startwerten für bestimmte Variablen oder das Vorgeben und Spezifizieren bestimmter Variablentypen .
Es ist bekannt, die in einem Computerprogramm verwendeten Variablen und Funktionen in einer sogenannten Header-Datei zu deklarieren und eine Konfiguration des Computerprogramms durchzuführen, indem einzelne Variablen oder Funktionsbezeichner in der Header-Datei verändert werden. Beispielsweise ist es möglich, einem in dem Computerprogramm verwendeten und in der Header-Datei deklarierten Funktionsbezeichner in Abhängigkeit von einer bestimmten Konfiguration eine spezielle Funktion zuzuweisen.
Üblicherweise werden Computerprogramme in einer sogenannten Hochsprache, beispielsweise C, C++, Scheme oder JAVA, erstellt. Üblicherweise wird ein in einer Hochsprache erstelltes Computerprogramm als Source-Code bezeichnet. Um ein derartiges Computerprogramm auf einem Computer ausführen zu können, muss aus dem Source-Code ein sogenannter Maschinencode erzeugt werden, der Anweisungen enthält, die von dem Prozessor des Computers ausführbar sind. Maschinencode kann durch sogenanntes Interpretieren oder Kompilieren des Source-Codes erzeugt werden.
Typischerweise umfasst ein Computerprogramm eine Vielzahl von Funktionseinheiten. Der Source-Code einer oder mehrerer Funktionseinheiten ist dabei in einer Datei abgespeichert. Einer oder mehrerer derartiger Dateien ist eine Header- Datei zugeordnet. Somit besteht ein Computerprogramm typischerweise aus einer Vielzahl von Dateien. Eine
Konfiguration eines derartigen Computerprogramms, die durch Änderungen innerhalb einzelner Header-Dateien durchgeführt wird, ist deshalb sehr unübersichtlich und kann häufig nur von dem Ersteller des Source-Codes durchgeführt werden. Zudem muss eine Dokumentation aller Header-Dateien erstellt werden, was sehr aufwendig ist, wobei selbst die Dokumentation meist sehr unübersichtlich ist.
Es ist auch bekannt, zur Konfiguration eines Computerprogramms diesem eine spezielle Funktionseinheit zuzuordnen, mittels der eine Konfiguration des gesamten Computerprogramms beispielsweise durch Änderung der Werte von vorgegebenen Parametern möglich ist. Die Funktionseinheit kann beispielsweise aus dem ablaufenden Computerprogramm heraus aufgerufen und zur Konfiguration des Computerprogramms ausgeführt werden. Eine derartige für die Konfiguration des Computerprogramms vorgesehene Funktionseinheit erlaubt jedoch nur eine Konfiguration innerhalb vorgegebener Bereichsgrenzen. Eine Konfiguration des Computerprogramms beispielsweise zur Anpassung des
Computerprogramms auf eine neue Hardware oder zur Anpassung des Computerprogramms an neue Benutzerwünsche ist mit einer derartigen Funktionseinheit nicht möglich. Ferner muss die zur Konfiguration verwendete Funktionseinheit speziell für das betreffende Computerprogramm entwickelt werden und kann nicht für andere Computerprogramme verwendet werden.
Aufgabe der Erfindung ist es daher, eine Möglichkeit zu schaffen, die eine möglichst übersichtliche und flexible Konfiguration eines Computerprogramms erlaubt. Die Aufgabe wird durch ein Verfahren der eingangs genannten Art gelöst, das die folgenden Schritte umfasst: - Erstellen mindestens einer implementierungsunabhängigen Konfigurationsdatei und/oder Änderung von in der mindestens einen implementierungsunabhängigen Konfigurationsdatei abgelegten Informationen; - automatischer Aufbau und/oder automatische Aktualisierung von in einem Konfigurationsdatencontainer abgelegten Konfigurationsdaten in Abhängigkeit von den in der mindestens einen implementierungsunabhängigen Konfigurationsdatei abgelegten Informationen; - automatisches Erzeugen mindestens einer implementierungsabhängigen Konfigurationsdatei in Abhängigkeit von den in dem Konfigurationsdatencontainer abgespeicherten Konfiguralpionsdaten; . .. automatische Konfiguration der mindestens einen Funktionseinheit in Abhängigkeit von in der mindestens einen implementierungsabhängigen Konfigurationsdatei abgelegten Informationen.
Vorteile der Erfindung
Die eine Konfiguration bestimmenden Daten werden also unabhängig von einer beabsichtigten konkreten Implementierung in einer oder mehreren implementierungsunabhängigen Konfigurationsdateien abgelegt. Die Implementierungsunabhängigkeit dieser Konfigurationdatei ermöglicht insbesondere eine abstrakte Beschreibung der abgelegten Informationen. Dies ermöglicht es, die für die Konfiguration des Computerprogramms relevanten Informationen besonders gut lesbar abzulegen und damit die Konfiguration deutlich zu vereinfachen. Dadurch, dass diese Konfigurationdatei implementierungsunabhängig ist, ist es insbesondere möglich, auf einfache Weise eine Konfiguration des Computerprogramms zu realisieren, so dass das Computerprogramm beispielsweise auf einem neuen Computersystem ablauffähig ist, dessen genaue Parameter bei der Erstellung des Computerprogramms noch gar nicht bekannt waren .
Der Konfigurationsdatencontainer ermöglicht es, alle für eine Konfiguration relevanten Daten zentral vorzuhalten. Mittels der in dem Konfigurationdatencontainer abgelegten Konfigurationsdaten wird automatisch mindestens eine implementierungsabhängige Konfigurationsdatei erzeugt. In der implementierungsabhängigen Konfigurationsdatei findet bezüglich der implementierungsunabhängigen Konfigurationsdatei eine Konkretisierung einzelner oder mehrere Parameterwerte statt. Bei einer derartigen Konkretisierung werden beispielsweise relative Werte durch absolute Werte ersetzt. Ebenso können einzelnen Werten oder Datenbereichen bestimmte Datentypen oder -Strukturen zugeordnet werden. Die implementierungsabhängige Konfigurationsdatei berücksichtigt folglich implementierungsabhängige Eigenschaften, wie beispielsweise eine oder mehrere bei der Programmierung des Source-Codes verwendeten Programmiersprachen oder Eigenschaften der Hardware, auf der das Computerprogramm ablaufen soll.
Der Aufbau beziehungsweise die Aktualisierung des Konfigurationsdatencontainers mittels der in den implementierungsunabhängigen Konfigurationsdateien abgelegten Informationen kann beispielsweise mittels sogenannter Scripte durchgeführt werden. Dabei bezeichnet ein Script eine Sequenz von Befehlen, die von einem speziellen Computerprogramm ausgeführt werden können. Derartige spezielle Computerprogramme sind beispielsweise AWK oder Perl. Diese speziellen Computerprogramme können auch eingesetzt werden, um aus den in dem Konfigurationsdatencontainer abgelegten Konfigurationsdaten implementierungsabhängige Konfigurationsdateien zu erzeugen.
Ein wesentlicher Bestandteil der Erfindung ist also die Erkenntnis, dass die Konfiguration eines Computerprogramms entscheidend verbessert werden kann, indem zwischen einen Benutzer (Konfigurator) und dem Computerprogramm eine abstrakte Beschreibung der auszuführenden Konfiguration in der implementierungsunabhängigen Konfigurationsdatei vorgesehen ist, die der Konfiguration zugrunde gelegt wird. Anhand der implementierungsunabhängigen Konfigurationsdatei wird automatisch eine implementierungsabhängige Konfigurationsdatei erstellt, die dann zur Konfiguration des Computerprogramms herangezogen wird. Das erfindungsgemäße Verfahren ermöglicht es also, die eine Konfiguration beschreibenden Informationen abstrakt und damit besonders gut lesbar anzugeben. Durch die Unabhängigkeit jeglicher Implementierungsdetails wird ferner eine besonders hohe Flexibilität erreicht.
In einer vorteilhaften Weiterbildung des Verfahrens wird mindestens eine Abhängigkeitsinformation, die eine Abhängigkeit von mindestens zwei in dem Konfigurationsdatencontainer vorliegenden Konfigurationsdaten beschreibt, automatisch erzeugt. Die mindestens eine implementierungsabhängige Konfigurationsdatei wird in Abhängigkeit der mindestens einen Abhängigkeitsinformation erzeugt. Abhängigkeitsinformationen können beispielsweise beschreiben, ob sich die Änderung eines Konfigurationsparameters auf einen anderen Konfigurationsparameter auswirkt. Wird zum Beispiel für eine Funktionseinheit eine Resource ausschließlich reserviert, so steht sie während der Ausführung der Funktionseinheit anderen Funktionseinheiten nicht zur Verfügung. Mit Abhängigkeitsinformationen kann ermittelt werden, welche Funktionseinheiten eine bestimmte Resource benötigen und damit nicht gleichzeitig ablaufen können. Abhängigkeitsinformationen können folglich auch zur Resourcenverwaltung verwendet werden.
In einer bevorzugten Ausführungsform des Verfahrens werden mehrere implementierungsunabhängige Konfigurationsdateien erstellt und jede der implementierungsunabhängigen Konfigurationsdateien wird mindesten einer Funktionseinheit zugeordnet. Dies ermöglicht eine besonders einfache Konfiguration dadurch, dass die als Informationen in den implementierungsunabhängigen Konfigurationsdateien abgelegten Konfigurationsparameter besonders einfach aufgefunden und verändert werden können. Beispielsweise ist es möglich, die eine Konfiguration bestimmenden Informationen, also die Konfigurationsparameter, nach der von diesen beeinflussten Funktionalität oder Hardware zu ordnen. Ferner wird dadurch eine besonders einfache Anpassung der implementierungsunabhängigen Konfigurationsdateien an neu hinzugekommene Funktionseinheiten ermöglicht. Im einfachsten Fall wird einer neu hinzugekommenen Funktionseinheit eine spezielle implementierungsunabhängige Konfigurationsdatei zugeordnet.
Vorteilhafterweise werden mehrere implementierungsabhängige Konfigurationsdateien erzeugt und es wird jede der implementierungsabhängigen Konfigurationsdatei mindestens einer Funktionseinheit zugeordnet. Eine derartige Strukturierung der implementierungsabhängigen Konfigurationsdateien erhöht die Übersichtlichkeit der erzeugten implementierungsabhängigen Konfigurationsdateien. Ist der Source-Code derartig strukturiert, dass sich eine oder mehrere Funktionseinheiten in unterschiedlichen Dateien befinden, so kann erreicht werden, dass jeder der Dateien des Source-Codes eine implementierungsabhängige Konfigurationsdatei zugeordnet ist. Eine besonders übersichtliche Strukturierung kann auch dadurch erreicht werden, dass jeder implementierungsunabhängigen Konfigurationsdatei je eine implementierungsabhängige Konfigurationsdatei zugeordnet ist.
Vorzugsweise wird die mindestens eine implementierungsabhängige Konfigurationsdatei in Abhängigkeit von mindestens einer Eigenschaft einer Hardware, auf der eine Installation zumindest eines Teils des konfigurierten Computerprogramms ermöglicht werden soll, erzeugt. Eine derartige Hardwareeigenschaft kann beispielsweise die Anzahl von zur Verfügung stehenden Prozessoren oder Art und Anzahl von an die Hardware angeschlossenen Sensoren sein. Werden derartige Hardwareeigenschaften bei der Erzeugung der implementierungsabhängigen Konfigurationsdateien berücksichtigt, so kann eine besonders präzise Konfiguration des Computerprogramms erfolgen. Damit ist es beispielsweise möglich, insbesondere mit Abhängigkeitsinformationen eine hinsichtlich der Ausführungsgeschwindigkeit optimierte Konfiguration automatisch zu erstellen.
In einer bevorzugten Ausführungsform wird die mindestens eine implementierungsabhängige Konfigurationsdatei in Abhängigkeit von dem Ergebnis einer Plausibilitätsprüfung erzeugt. Eine Plausibilitätsprüfung kann beispielsweise die Prüfung umfassen, ob eine von einer Funktionseinheit benötigte Resource überhaupt zur Verfügung steht.
Vorzugsweise wird zur Durchführung der
Plausibilitätsprüfung die mindestens eine Hardwareeigenschaft verwendet. Dadurch kann der Automatisierungsgrad besonders gut erhöht werden und eine zuverlässige Konfiguration des Computerprogramms erreicht werden. Sieht eine Funktionseinheit beispielsweise eine
Erfassung von Messwerten vor, so kann überprüft werden, ob geeignete Sensoren vorhanden sind und ob diese die angeforderte Messgenauigkeit zur Verfügung stellen. In diesem Fall ist es beispielsweise vorstellbar, dass automatisch eine Konfiguration des Sensors durchgeführt wird.
In einer weiteren bevorzugten Ausführungsform wird automatisch eine Dokumentation erstellt. Die Dokumentation beschreibt die innerhalb der mindestens einen ., implementierungsunabhängigen Konfigurationsdatei und/oder der mindestens einen implementierungsabhängigen Konfigurationsdatei abgelegten Informationen. Derartig automatisch erzeugte Dokumentationen erhöhen die Wartbarkeit des Computerprogramms einerseits und ermöglichen es andererseits besonders einfach, eine durchgeführte Konfiguration nachzuvollziehen. Durch die automatische Erzeugung der Dokumentation ist sichergestellt, dass diese mit der tatsächlichen Konfiguration übereinstimmt. Soll eine neue Konfiguration des Computerprogramms durchgeführt werden, so kann anhand einer derartigen Dokumentation besonders einfach festgestellt werden, welche Parameterwerte geändert werden müssen. Vorzugsweise wird die mindestens eine implementierungsunabhängige Konfigurationsdatei in einem XML-basierten Format erstellt. XML (Extensible Markup Language) ist eine standardisierte Metasprache, die es ermöglicht, strukturierte Sprachen zu erzeugen. Ist die mindestens eine implementierungsunabhängige Konfigurationsdatei in einer XML-konformen, strukturierten Sprache erstellt, so wird eine Konfiguration dadurch erleichtert, dass eine derartige implementierungsunabhängige Konfigurationdatei besonders gut lesbar ist. Ferner ist eine derartige Konfigurationsdatei auch besonders gut maschinenlesbar. Insbesondere existiert eine Vielzahl von teilweise ebenfalls standardisierten Software-Werkzeugen (Tools) , mittels derer eine Bearbeitung und Verarbeitung von in einem XML-basierten Format erstellten Dateien möglich ist.
In einer bevorzugten Ausführungsform des Verfahrens wird in Abhängigkeit von den Konfigurationsdaten automatisch ermittelt, ob..eine von dem Computerprogramm umfasste
Funktionseinheit von dem Computerprogramm benötigt wird und eine Konfiguration dieser Funktionseinheit nur durchgeführt, falls die Funktionseinheit von dem Computerprogramm benötigt wird. Dies ermöglicht es, eine Konfiguration besonders schnell durchzuführen dadurch, dass nur derartige Funktionseinheiten tatsächlich konfiguriert werden, die bei einer Ausführung des konfigurierten Computerprogramms tatsächlich benötigt werden. Des Weiteren wird dadurch erreicht, dass das konfigurierte Computerprogramm möglichst wenig Speicherplatz in Anspruch nimmt, da beispielsweise eine Übersetzung von Source-Code in Maschinencode nur für derartige Funktionseinheiten veranlasst wird, die tatsächlich angewendet werden sollen. Die Aufgabe wird auch durch ein Softwaresystem der eingangs genannten Art gelöst. Dabei weist das Softwaresystem auf:
- mindestens eine implementierungsunabhängige Konfigurationsdatei; einen Konfigurationsdaten umfassenden Konfigurationsdatencontainer und/oder Mittel zum Erstellen eines Konfigurationsdatencontainers in Abhängigkeit von in der mindestens einen implementierungsunabhängigen Konfigurationsdatei abgelegten Informationen; - Mittel zum Ändern und/oder Auslesen von Konfigurationsdaten aus dem Konfigurationsdatencontainer; - Mittel zum automatischen Erzeugen mindestens einer implementierungsabhängigen Konfigurationsdatei in Abhängigkeit von in dem Konfigurationsdatencontainer abgespeicherten Konfigurationsdaten; und - Mittel zum automatischen Konfigurieren der mindestens einen Funktionseinheit in Abhängigkeit von in der implementierungsabhängigen Konfigurationsdatei abgelegten Informationen.
Vorzugsweise weist das Softwaresystem Mittel zur Durchführung des erfindungsgemäßen Verfahrens auf.
Die Realisierung der Erfindung in Form eines Softwaresystems ist hierbei von besonderer Bedeutung. Dabei ist das Softwaresystem auf einem Rechengerät, insbesondere auf einem Mikroprozessor ablauffähig und zur Ausführung des erfindungsgemäßen Verfahrens geeignet. In diesem Fall wird also die Erfindung durch das Softwaresystem realisiert, so dass das Softwaresystem in gleicher Weise die Erfindung darstellt wie das Verfahren, zu dessen Ausführung das Softwaresystem geeignet ist. Das Softwaresystem ist vorzugsweise auf einem Speicherelement abgespeichert. Das Speicherelement kann als Random-Access-Memory, Read-Only- Memory oder Flash-Memory ausgebildet sein. Das Speicherelement kann auch als Digital Versatile Disc (DVD) , Compact Disc (CD) oder als Festplatte (Hard Disc) ausgebildet sein.
Zeichnungen
Weitere Merkmale, Anwendungsmöglichkeiten und Vorteile der Erfindung ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen der Erfindung, die in der Zeichnung dargestellt sind. Dabei bilden alle beschriebenen oder dargestellten Merkmale für sich oder in beliebiger Kombination den Gegenstand der Erfindung, unabhängig von ihrer Zusammenfassung in den Patentansprüchen oder deren Rückbeziehung sowie unabhängig von ihrer Formulierung beziehungsweise Darstellung in der Beschreibung beziehungsweise in der Zeichnung. Es zeigen: .
Figur 1 eine Ausführungsform eines Softwaresystems zur Durchführung des erfindungsgemäßen Verfahrens; und
Figur 2 ein schematisiertes Ablaufdiagramm einer Ausführungsform des erfindungsgemäßen Verfahrens.
Beschreibung der Ausführungsbeispiele
In Figur 1 ist ein Softwaresystem zur Durchführung des erfindungsgemäßen Verfahrens dargestellt. Das Softwaresystem weist mehrere implementierungsunabhängige Konfigurationsdateien 1 auf. Jeder Konfigurationsdatei 1 ist ein Dateiname zugeordnet. Die in Figur 1 dargestellten implementierungsunabhängigen Konfigurationsdateien tragen beispielsweise die Dateinamen conf_l.xml, conf_2.xml, conf_3.xml bis conf_n.xml. Die Dateiendung .xml weist darauf hin, dass die implementierungsunabhängigen Konfigurationsdateien 1 in einem XML-basierten Format vorliegen. Eine in einem XML-basierten Format vorliegende Text-Datei ermöglicht es, die Text-Datei nach vorgebbaren Regeln zu strukturieren. Eine derartig strukturierte Text- Datei kann besonders gut manuell und maschinell gelesen und verarbeitet werden.
Die implementierungsunabhängigen Konfigurationsdateien 1 werden einem Script 2 zugeführt. Das Script 2 ist beispielsweise als sogenanntes Perl-Script ausgebildet. Perl ist eine Interpretersprache, deren Syntax auf der Programmiersprache C basiert und die von dem jeweiligen Betriebssystem zur Verfügung gestellte Dienstprogramme verwendet.
Mittels des Scripts 2 werden die implementierungsunabhängigen Konfigurationsdateien 1 gelesen und die darin abgelegten Informationen extrahiert und in einem Konfigurationsdatencontainer 3 abgelegt. Gleichzeitig werden auch eventuell vorhandene Abhängigkeiten zu den weiteren Konfigurationsscripten 4 bestimmt und abgelegt.
Mit dem Bezugszeichen 4 sind weitere Konfigurationsscripte dargestellt. Diese sind ebenfalls als Pearl-Scripte ausgebildet. Es ist ebenso vorstellbar, dass eines oder mehrere der weiteren Konfigurationsscripte 4 ein ausführbares Computerprogramm (Maschinencode) ist oder in einer anderen Scriptsprache, beispielsweise AWK, vorliegt.
Mit dem Bezugszeichen 5 sind implementierungsabhängige Konfigurationsdateien bezeichnet. Die implementierungsabhängigen Konfigurationsdateien 5 sind beispielsweise in der Programmiersprache codiert, in der auch der zu konfigurierende Source-Code programmiert ist. Derartige implementierungsabhängige Konfigurationsdateien können von einem Compiler 6 verarbeitet werden.
Mit dem Bezugszeichen 7 ist ein Computerprogramm dargestellt, das mehrere Funktionseinheiten 8 aufweist.
Die Funktionsweise des erfindungsgemäßen Softwaresystems wird anhand des in Figur 2 dargestellten Ablaufdiagramms beschrieben.
Das in Figur 2 dargestellte Ablaufdiagramm eines erfindungsgemäßen Verfahrens zur Konfiguration eines
Computerprogramms startet in einem Schritt 100. In einem Schritt 101 werden implementierungsunabhängige Konfigurationsdateien 1 erstellt beziehungsweise geändert. Die implementierungsunabhängigen Konfigurationsdateien 1 zeichnen sich insbesondere dadurch aus, dass es möglich ist, mittels der dort abgelegten Informationen konkrete Konfigurationswerte beziehungsweise Konfigurationsparameter abstrakt zu beschreiben. Konkrete Konfigurationswerte können beispielsweise den Messbereich eines Sensormoduls zur Messung einer elektrischen Spannung bestimmen.
Beispielsweise ist es möglich, einen Messbereich abstrakt mit den Werten 3 - 5 Volt anzugeben. Die daraus zu » erzeugenden, implementierungsabhängigen Werte des Messbereichs so, wie es die zu konfigurierende Funktionseinheit 8 erwartet, können jedoch beispielsweise zwischen 10.000 und 20.000 liegen. Eine das Sensormodul steuernde Funktionseinheit 8 des Computerprogramm müsste in diesem Fall beispielsweise mittels der konkreten Konfigurationswerte 10.000 und 20.000 konfiguriert werden , um eine Messung in einem Messbereich von 3 - 5 Volt zu ermöglichen .
Die in dem Schritt 101 erstellten beziehungsweise geänderten implementierungsunabhängigen
Konfigurationsdateien 1 sind beispielsweise in einem XML- basierten Format erstellt. Ein derartiges Format ermöglicht es besonders gut, eine übersichtliche Strukturierung der implementierungsunabhängigen Konfigurationsdateien 1 zu erreichen. Dies erhöht die Lesbarkeit der implementierungsunabhängigen Konfigurationsdateien 1 und vereinfacht die Änderung der implementierungsunabhängigen Konfigurationsdateien 1 beispielsweise dadurch dass zu ändernde Konfigurationsdaten schnell aufgefunden werden können. Es ist möglich, auch für ein besonders großes
Computerprogramm, für dessen Konfiguration eine Vielzahl von Konfigurationsdaten notwendig sind, nur eine einzige implementierungsunabhängige Konfigurationsdatei vorzusehen. Eine Strukturierung der in der implementierungsunabhängigen .Konfigurationsdatei 1 abgelegten Informationen kann dabei durch geeignete XML-Strukturen erreicht werden. Besonders vorteilhaft jedoch ist es, mehrere implementierungsunabhängige Konfigurationsdateien vorzusehen. Jede dieser implementierungsunabhängigen Konfigurationsdateien 1 kann beispielsweise einer oder mehrerer Funktionseinheiten 8 zugeordnet sein. Dadurch ist es möglich, das Erstellen beziehungsweise Ändern der implementierungsunabhängigen Konfigurationsdateien besonders übersichtlich durchzuführen. Des Weiteren wird dadurch eine Wiederverwendbarkeit einzelner implementierungsunabhängiger Konfigurationsdateien erhöht. Dies ist insbesondere für Projekte vorteilhaft, bei denen auch einzelne Funktionseinheiten 8 des Source-Codes wiederverwendet werden sollen. In einem Schritt 102 wird der Konfigurationsdatencontainer 3 aufgebaut, beziehungsweise aktualisiert. Dies geschieht durch Abarbeiten der in dem Script 2 aufgelisteten Anweisungen. Das Script 2 veranlasst zunächst, dass die unabhängigen Konfigurationsdateien 1 eingelesen werden. Liegt den implementierungsunabhängigen Konfigurationsdateien 1 ein strukturiertes Format, beispielsweise ein XML-basiertes Format zugrunde, so kann mittels des Scripts 2 besonders gut eine syntaktische und/oder semantische Analyse des Inhalts der implementierungsunabhängigen Konfigurationsdateien 1 durchgeführt werden. Damit können beispielsweise Fehler bei der Angabe von Konfigurationsdaten erkannt werden. Vorzugsweise weist das XML-basierte Format der implementierungsunabhängigen Konfigurationsdateien 1 eine hierarchische Struktur auf, die sich vorteilhafterweise an der Struktur der Funktionseinheiten 8 selbst, deren Abhängigkeiten und/oder deren thematische Nähe orientiert. Mittels des Scripts 2 können Fehler beim Aufbau dieser hierarchischen Struktur und damit auch beim Aufbau des Source-Codes selbst erkannt werden.
Vorteilhafterweise weist der Schritt 102 eine Behandlung der aufgefundenen Fehler auf. Dies kann beispielsweise durch die Ausgabe von Fehlerinformationen geschehen. Es ist ebenso vorstellbar, dass stochastische Verfahren zur Beseitigung von Fehlern eingesetzt werden.
Das Script 2 extrahiert in dem Schritt 102 die in den implementierungsunabhängigen Konfigurationsdateien 1 vorhandenen Konfigurationsdaten und speichert diese in dem
Konfigurationsdatencontainer 3 ab. Der
Konfigurationsdatencontainer 3 kann dabei beispielsweise als Datenbank ausgebildet sein. Es ist ebenso vorstellbar, dass der Konfigurationsdatencontainer 3 als in einem Speicherbereich vorgehaltene Datenstruktur innerhalb des erfindungsgemäßen Softwaresystems realisiert ist, wobei gewährleistet ist, dass das Script 2 schreibenden und lesenden Zugriff auf die in dem Konfigurationsdatencontainer 3 abgelegten Konfigurationsdaten hat.
In einem Schritt 103 werden Abhängigkeiten ermittelt. Eine derartige Abhängigkeit kann beispielsweise beschreiben, welche Funktionseinheiten 8 des Computerprogramms bei der vorliegenden Konfiguration tatsächlich abgearbeitet werden müssen. Mittels dieser Abhängigkeiten kann entschieden werden, ob in einem der folgenden Schritte für eine bestimmte Funktionseinheit 8 überhaupt eine implementierungsabhängige Konfigurationsdatei erzeugt werden muss. Abhängigkeiten können ferner beschreiben, welche konkreten Konfigurationsdaten von welchen abstrakten Konfigurationsdaten abhängen. So ist es vorstellbar, dass die Änderung eines abstrakten Konfigurationsdatums in einer implementierungsunabhängigen Konfigurationsdatei eine
Änderung einer Mehrzahl von konkreten Konfigurationsdaten bewirkt .
Abhängigkeiten können sich auch ergeben, wenn die weiteren Scripte 4 ihrerseits den Konfigurationscontainer 3 verändern. Somit muss die richtige Aufrufreihenfolge (Aktivierungssequenz) der Scripte 4 ermittelt und abgelegt werden. Abhängigkeiten können auch Beziehungen zwischen einer oder mehrerer Hardwarekomponenten und einzelner Konfigurationsdaten beschreiben. Dies ermöglicht es beispielsweise zu erkennen, ob eine vorgesehene Konfiguration auf einer bestimmten Hardware tatsächlich ablauffähig ist. In einem Schritt 104 wird eine Plausibilitätsprüfung durchgeführt. Dabei wird insbesondere anhand der in Schritt 103 ermittelten Abhängigkeiten überprüft, ob die mittels der implementierungsunabhängigen Konfigurationsdateien 1 vorgegebene Konfiguration Fehler aufweist. Ist dies der Fall, so wird in den Schritt 101 zurückverzweigt, in welchem eine Änderung der implementierungsunabhängigen Konfigurationsdateien 1 mit dem Zwecke einer Fehlerbeseitigung durchgeführt wird. Werden in dem Schritt 104 keine Fehler erkannt, so wird zu einem Schritt 105 verzweigt.
In dem Schritt 105 werden die implementierungsabhängigen Konfigurationsdateien 5 erzeugt. Dazu werden mittels eines Scripts 4 oder einer Mehrzahl von Scripten 4 zunächst die in dem Konfigurationsdatencontainer 3 abgelegten Konfigurationsdaten abgerufen. In dem vorliegenden Ausführungsbeispiel sind die Scripte 4 als Pearl-Scripte ausgebildet. Mittels der Scripte 4 werden insbesondere in dem, .Konfigurationsdatencontainer 3 abgelegte abstrakte Konfigurationsdaten in konkrete Konfigurationsdaten umgewandelt, die dann in den implementierungsabhängigen Konfigurationsdateien 5 abgelegt werden. Vorzugsweise werden dabei auch die in dem Schritt 103 ermittelten Abhängigkeiten verwendet.
Die : in dem Schritt 105 erzeugten implementierungsabhängigen Konfigurationsdateien 5 können beispielsweise Header- Dateien (file_.h, file_2.h, file_3.h in Figur 1) sein. Ebenso können die erzeugten implementierungsabhängigen Konfigurationsdateien 5 auch Source-Code enthalten (file_2.c, file_k.c in Figur 1). Typischerweise sind die von den Scripten 4 aus den abstrakten Konfigurationsdaten erzeugten konkreten Konfigurationsdaten durch Wertzuweisungen für Variablen und/oder Funktionsparameter sowie als Anweisungen in einer Programmiersprache realisiert. Dabei entspricht die Programmiersprache der Programmiersprache, in der die Funktionseinheiten 8 des Computerprogramms 7 codiert sind. Sind die Funktionseinheiten 8 des Computerprogramm 7 beispielsweise in der Programmiersprache C++ codiert, so können die konkreten Konfigurationsdaten beispielsweise durch sogenannte #Define-Anweisungen oder durch die Definition konstanter Variablen realisiert werden. Mittels der Scripte 4 ist es auch möglich, in Abhängigkeit der in dem Konfigurationsdatencontainer 3 abgespeicherten Konfigurationsdaten Funktionen zu erzeugen, die komplexe Aufgaben - wie beispielsweise die Initialisierung von Hardwarekomponenten oder die Prüfung auf das Vorhandensein einzelner Softwarekomponenten oder Hardwarekomponenten - übernehmen und selbst als Source-Code in einer höheren Programmiersprache realisiert sind. Dieser Source-Code kann dann in einer oder mehreren implementierungsabhängigen Konfigurationsdateien (file_2.c, file_k.c in Figur 1) abgelegt werden. Dazu kann ein Script 4 beispielsweise ein... sogenanntes Template enthalten, das beispielsweise aus Anweisungen in C++ besteht, die in Abhängigkeit der in dem Konfigurationsdatencontainer 3 abgespeicherten Konfigurationsdaten aktualisiert werden und in einer implementierungsabhängigen Konfigurationsdatei 5 abgelegt werden.
In einem Schritt 107 werden die Funktionseinheiten 8 des Computerprogramms 7 aktualisiert. Dies kann beispielsweise durch den automatischen Aufruf eines Compilers 6 geschehen, der die in einem Source-Code vorliegenden
Funktionseinheiten 8 in einen Maschinencode übersetzt. Dazu liest der Compiler 6 die implementierungsabhängigen Konfigurationsdateien 5 ein und steuert die Erzeugung des Maschinencodes in Abhängigkeit der in den implementierungsabhängigen Konfigurationsdateien 5 abgelegten konkreten Konfigurationsdaten. Es ist auch vorstellbar, dass eine oder mehrere Funktionseinheiten 8 bereits in Maschinencode vorliegen. In diesem Fall kann der Compiler beispielsweise den von den Scripten 4 erzeugten Source-Code (file_2c, file_kc in Figur 1) unter Berücksichtigung der Header-Dateien (file_l.h, file_2.h, file_3.h) in Maschinencode übersetzen und den so übersetzten Maschinencode mittels eines dem Compiler 6 zugeordneten sogenannten Linkers mit dem die
Funktionseinheiten 8 repräsentierenden Maschinencode verbinden .
In einem Schritt 108 endet das Verfahren. In diesem Schritt ist das Computerprogramm 7 derart konfiguriert, dass die in den implementierungsunabhängigen Konfigurationsdateien abgelegten konkreten Konfigurationsdaten in dem erzeugten Maschinencode berücksichtigt werden.
Selbstverständlich ist es möglich, dass das Script 2 und/oder die Scripte 4 in einer anderen Scriptsprache geschrieben sind oder als ausführbare Programme ausgestaltet sind.
Die in Figur 2 dargestellten Ausführungsschritte können selbstverständlich variieren und die Reihenfolge der Abarbeitung kann teilweise verändert werden. So ist es vorstellbar, dass die Plausibilitätsprüfung 104 durch eines oder mehrere der Scripte 4 durchgeführt wird.
Das Verfahren kann insbesondere auch von einer oder mehreren implementierungsunabhängigen Konfigurationsdateien ausgehen, ein oder mehrere Scripte 2 aufweisen, die beispielsweise hintereinander ausgeführt werden, ein oder mehrere Scripte 4 aufweisen, die jeweils ein oder mehrere implementierungsabhängige Konfigurationsdateien 5 erzeugen und selbstverständlich kann das Computerprogramm 7 ein oder mehrere Funktionseinheiten 8 aufweisen. Mit dem erfindungsgemäßen Verfahren ist es insbesondere möglich zu erkennen, ob eine oder mehrere der Funktionseinheiten 8 bei der durch die implementierungsunabhängigen Konfigurationsdateien vorgegebenen Konfiguration tatsächlich zur Anwendung kommen. Ist dies nicht der Fall, kann dies durch ein dem Konfigurationsdatencontainer 3 zugeordnetes, nicht dargestelltes Softwaretool erkannt werden. Dies ermöglicht es, dass eine derartige Funktionseinheit 8 nicht konfiguriert wird und mittels der implementierungsabhängigen Konfigurationsdateien 5 der Compiler 6 veranlasst wird, die Funktionseinheit 8 nicht mit in den zu erzeugenden Maschinencode zu übernehmen. Dadurch kann das erfindungsgemäße Verfahren besonders schnell durchgeführt werden. Der von einem Computerprogramm, das mittels des erfindungsgemäßen Verfahrens konfiguriert wurde, erzeugte Maschinencode kann dabei besonders kompakt sein und somit Speicherplatz einsparen.
Es ist möglich, dass das Script 2 selbst bereits die
Erzeugung einer oder einer Mehrzahl von implementierungsabhängigen Konfigurationsdateien 5 veranlasst. Dadurch kann das erfindungsgemäße Verfahren besonders schnell durchgeführt werden. Dies kann beispielsweise vorteilhaft für abstrakte
Konfigurationsdaten sein, die keine Abhängigkeiten aufweisen und sich von den konkreten Konfigurationsdaten unterscheiden .

Claims

Ansprüche
1. Verfahren zur Konfiguration mindestens eine Funktionseinheit umfassenden Computerprogramms, gekennzeichnet: durch die folgenden Schritte: - Erstellen mindestens einer implementierungsunabhängigen Konfigurationsdatei (1) und/oder Änderung von in der mindestens einen implementierungsunabhängigen Konfigurationsdatei (1) abgelegten Informationen; - Automatischer Aufbau und/oder automatische Aktualisierung von in einem Konfigurationsdatencontainer (3) abgelegten Konfigurationsdaten in Abhängigkeit von den in der mindestens einen implementierungsunabhängigen Konfigurationsdatei (1) abgelegten Informationen;
Automatisches Erzeugen mindestens einer implementierungsabhängigen Konfigurationsdatei (5) in Abhängigkeit von den in dem Konfigurationsdatencontainer (3) abgespeicherten Konfigurationsdaten;
Automatische Konfiguration der mindestens einen Funktionseinheit in Abhängigkeit von in der mindestens einen implementierungsabhängigen Konfigurationsdatei abgelegten Informationen.
2. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass mindestens eine Abhängigkeitsinformation automatisch erzeugt wird, die eine Abhängigkeit von mindestens zwei in dem Konfigurationsdatencontainer vorliegenden Konfigurationsdaten beschreibt, und dass die mindestens eine implementierungsabhängige Konfigurationsdatei in Abhängigkeit der mindestens einen Abhängigkeitsinformation erzeugt wird.
3. Verfahren nach einem der vorangehenden Ansprüche, wobei das Computerprogramm mehrere Funktionseinheiten aufweist, dadurch gekennzeichnet, dass mehrere implementierungsunabhängige Konfigurationsdateien erstellt werden und jede der implementierungsunabhängigen
Konfigurationsdateien mindestens einer Funktionseinheit zugeordnet wird.
4. Verfahren nach einem der vorangehenden Ansprüche, wobei das Computerprogramm mehrere Funktionseinheiten aufweist, dadurch gekennzeichnet, dass mehrere implementierungsabhängige Konfigurationsdateien erzeugt werden und jede der implementierungsabhängigen Konfigurationsdateien mindestens einer Funktionseinheit zugeordnet wird.
5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die mindestens eine implementierungsabhängige Konfigurationsdatei in Abhängigkeit von mindestens einer Eigenschaft einer Hardware, auf der eine Installation zumindest eines Teils des konfigurierten Computerprogramms ermöglicht werden soll, erzeugt wird.
6. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die mindestens eine implementierungsabhängige Konfigurationsdatei in Abhängigkeit von dem Ergebnis einer Plausibilitätsprüfung erzeugt wird.
7. Verfahren nach Anspruch 5 und 6, dadurch gekennzeichnet, dass zur Durchführung der Plausibilitätsprüfung die mindestens eine Hardware- Eigenschaft verwendet wird.
8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass automatisch eine Dokumentation erstellt wird und die Dokumentation die innerhalb der mindestens einen implementierungsunabhängigen Konfigurationsdatei und/oder der mindestens einen implementierungsabhängigen Konfigurationsdatei abgelegten Informationen beschreibt.
9. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die mindestens eine . implementierungsunabhängige Konfigurationsdatei in einem XML-basierten Format erstellt wird.
10. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass in Abhängigkeit von den Konfigurationsdaten automatisch ermittelt wird, ob eine von dem Computerprogramm umfasste Funktionseinheit von dem Computerprogramm benötigt wird und eine Konfiguration dieser Funktionseinheit nur durchgeführt wird, falls die Funktionseinheit von dem Computerprogramm benötigt wird.
11. Softwaresystem zur Konfiguration eines mindestens eine Funktionseinheit umfassenden Computerprogramms, dadurch gekennzeichnet, dass das Softwaresystem aufweist: mindestens eine implementierungsunabhängige Konfigurationsdatei; einen Konfigurationsdaten umfassenden Konfigurationsdatencontainer und/oder Mittel zum Erstellen eines Konfigurationsdatencontainers in Abhängigkeit von in der mindestens einen implementierunsunabhängigen Konfigurationsdatei abgelegten Informationen;
- Mittel zum Ändern und/oder Auslesen von Konfigurationsdaten aus dem Konfigurationsdatencontainer;
Mittel zum automatischen Erzeugen mindestens einer implementierungsabhängigen Konfigurationsdatei in Abhängigkeit von in dem Konfigurationsdatencontainer abgespeicherten Konfigurationsdaten; und
Mittel zum automatischen Konfigurieren der mindestens einen Funktionseinheit in Abhängigkeit von in der implementierungsabhängigen Konfigurationsdatei abgelegten Informationen.
12. Softwaresystem nach Anspruch 11, dadurch gekennzeichnet, dass das Softwaresystem Mittel zur Durchführung eines Verfahrens nach einem der Ansprüche 2 bis 11 aufweist.
13. Softwaresystem nach Anspruch 11 oder 12, dadurch gekennzeichnet, dass das Softwaresystem auf einem Speichermedium abgespeichert wird.
14. Softwaresystem nach Anspruch 13, dadurch gekennzeichnet, dass das Softwaresystem auf einem Random- Access-Memory, auf einem Read-Only-Memory oder auf einem Flash-Memory abgespeichert ist.
15. Softwaresystem nach Anspruch 13, dadurch gekennzeichnet, dass das Softwaresystem auf einer Digital Versatile Disk (DVD) , einer Compact Disc (CD) oder auf eine Festplatte (Hard Disc) abgespeichert ist.
16. Rechengerät, insbesondere Steuergerät, das einen Mikroprozessor aufweist, dadurch gekennzeichnet, dass das Rechengerät zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 10 programmiert ist.
PCT/EP2005/050289 2004-02-05 2005-01-24 Verfahren zur konfiguration eines computerprogramms WO2005076129A1 (de)

Priority Applications (5)

Application Number Priority Date Filing Date Title
US10/588,596 US8365163B2 (en) 2004-02-05 2005-01-24 Method for configuring a computer program
JP2006551837A JP5209209B2 (ja) 2004-02-05 2005-01-24 コンピュータプログラムを構成する方法
DE502005005190T DE502005005190D1 (de) 2004-02-05 2005-01-24 Verfahren zur konfiguration eines computerprogramms
EP05701596A EP1723513B1 (de) 2004-02-05 2005-01-24 Verfahren zur konfiguration eines computerprogramms
KR1020067015780A KR101154730B1 (ko) 2004-02-05 2006-08-04 컴퓨터 프로그램의 구성 방법

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004005730A DE102004005730A1 (de) 2004-02-05 2004-02-05 Verfahren zur Konfiguration eines Computerprogramms
DE102004005730.3 2004-02-05

Publications (1)

Publication Number Publication Date
WO2005076129A1 true WO2005076129A1 (de) 2005-08-18

Family

ID=34801630

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/050289 WO2005076129A1 (de) 2004-02-05 2005-01-24 Verfahren zur konfiguration eines computerprogramms

Country Status (9)

Country Link
US (1) US8365163B2 (de)
EP (1) EP1723513B1 (de)
JP (1) JP5209209B2 (de)
KR (1) KR101154730B1 (de)
CN (1) CN100478877C (de)
AT (1) ATE406610T1 (de)
DE (2) DE102004005730A1 (de)
ES (1) ES2309706T3 (de)
WO (1) WO2005076129A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220350587A1 (en) * 2021-04-29 2022-11-03 Salesforce.Com, Inc. Methods and systems for deployment of services

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005032944A1 (de) * 2005-07-14 2007-01-18 Robert Bosch Gmbh Verfahren und Softwaresystem zur Konfiguration eines modularen Systems
DE102005060161A1 (de) * 2005-12-14 2007-06-21 Robert Bosch Gmbh Verfahren zur Verarbeitung und Erzeugung von Diagnosedaten in einem Softwareentwicklungsprozess
KR101484680B1 (ko) * 2007-10-04 2015-01-21 삼성전자 주식회사 컴포넌트 기반 소프트웨어 제품 관리 시스템 및 방법
US8627306B2 (en) * 2008-08-06 2014-01-07 Caterpillar Inc. Method and system for updating an information management system configuration
DE102008043374A1 (de) 2008-10-31 2010-05-06 Robert Bosch Gmbh Vorrichtung und Verfahren zur Generierung redundanter, aber unterschiedlicher Maschinencodes aus einem Quellcode zur Verifizierung für ein sicherheitskritisches System
WO2010148239A1 (en) * 2009-06-19 2010-12-23 Dolby Laboratories Licensing Corporation Hierarchy and processing order control of downloadable and upgradeable media processing applications
US9223617B2 (en) * 2010-05-06 2015-12-29 Nec Laboratories America, Inc. Methods and systems for migrating networked systems across administrative domains
JP5969875B2 (ja) * 2012-09-28 2016-08-17 株式会社Ｓｃｒｅｅｎホールディングス データ生成システムおよびデータ生成方法
US9135000B2 (en) * 2012-11-06 2015-09-15 Rockwell Automation Technologies, Inc. Runtime process diagnostics
US9031975B2 (en) 2012-11-06 2015-05-12 Rockwell Automation Technologies, Inc. Content management
US9563861B2 (en) 2012-11-06 2017-02-07 Rockwell Automation Technologies, Inc. Integration of workflow and library modules
US8898634B2 (en) 2012-11-06 2014-11-25 Rockwell Automation Technologies, Inc. Customized object design for industrial automation application
US9355193B2 (en) 2012-11-06 2016-05-31 Rockwell Automation Technologies, Inc. Object design data model
US20140330691A1 (en) * 2013-05-01 2014-11-06 Life Dreams, Inc. Devices, methods and systems related to automation that provides financial planning advice
CN104090780A (zh) * 2014-07-31 2014-10-08 广州视源电子科技股份有限公司 自动配置方法以及云编译系统
CN107291532A (zh) * 2016-03-31 2017-10-24 富士施乐实业发展（中国）有限公司 应用程序的自动化执行方法及装置
RU2675188C1 (ru) * 2017-12-27 2018-12-17 Федеральное государственное бюджетное учреждение науки Институт физики прочности и материаловедения Сибирского отделения Российской академии наук (ИФПМ СО РАН) Устройство и способ для получения порошковых материалов на основе нано- и микрочастиц путем электрического взрыва проволоки
RU2699886C1 (ru) * 2018-12-13 2019-09-11 Федеральное государственное бюджетное учреждение науки Институт физики прочности и матероиаловедения Сибирского отделения Российской академии наук (ИФПМ СО РАН) Способ получения металлического порошка и устройство для его осуществления

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5872977A (en) * 1997-08-08 1999-02-16 International Business Machines Corporation Object-oriented method and apparatus for creating a makefile
US20020040469A1 (en) * 2000-06-03 2002-04-04 International Business Machines Corporation System and method for the configuration of software products
US20020199170A1 (en) * 2001-06-21 2002-12-26 Jameson Kevin Wade Collection makefile generator

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5005136A (en) * 1988-02-16 1991-04-02 U.S. Philips Corporation Silicon-compiler method and arrangement
JPH0455938A (ja) 1990-06-25 1992-02-24 Fujitsu Ltd プログラム仕様書自動生成方式
JPH06195214A (ja) 1992-12-25 1994-07-15 Toshiba Corp プログラム設計図およびソースプログラムの複写装置
US6295561B1 (en) * 1998-06-30 2001-09-25 At&T Corp System for translating native data structures and specific message structures by using template represented data structures on communication media and host machines
US6370682B1 (en) * 1999-09-15 2002-04-09 Siemens Atkiengesellschaft System and method for developing reusable flexible and platform independent software using components
EP1168163A1 (de) * 2000-06-19 2002-01-02 Hewlett-Packard Company, A Delaware Corporation Verfahren um ein Softwarepaket in einem Benutzerrechner zu installieren
US6681391B1 (en) * 2000-06-21 2004-01-20 Microsoft Corporation Method and system for installing software on a computer system
JP2002060727A (ja) 2000-08-21 2002-02-26 Nippon Polyurethane Ind Co Ltd 天蓋パッキン用組成物及び該組成物を用いた天蓋パッキンの製造方法
US6877035B2 (en) * 2001-01-29 2005-04-05 International Business Machines Corporation System for optimal resource allocation and planning for hosting computing services
US20030033588A1 (en) * 2001-01-29 2003-02-13 John Alexander System, method and article of manufacture for using a library map to create and maintain IP cores effectively
JP2002229783A (ja) * 2001-01-31 2002-08-16 Toshiba Corp ソフトウェア構築支援システム、その方法およびソフトウェア構築支援プログラム
JP2002366352A (ja) * 2001-06-11 2002-12-20 It Forest Corp Ｗｅｂアプリケーション開発支援装置
US6865733B2 (en) * 2001-06-21 2005-03-08 International Business Machines Corp. Standardized interface between Java virtual machine classes and a host operating environment
US6789254B2 (en) * 2001-06-21 2004-09-07 International Business Machines Corp. Java classes comprising an application program interface for platform integration derived from a common codebase
DE10131944A1 (de) * 2001-07-02 2003-01-16 Siemens Ag Verfahren zur Verarbeitung von Daten
US7774772B2 (en) * 2001-09-28 2010-08-10 Siebel Systems, Inc. Method and apparatus to perform an application software migration
US7266810B2 (en) * 2002-04-09 2007-09-04 Hewlett-Packard Development Company, Lp. Runtime profiling of platform-independent software applications
US7150003B2 (en) * 2002-11-25 2006-12-12 Matsushita Electric Industrial Co., Ltd. Class coalescence for obfuscation of object-oriented software
TWI222576B (en) * 2003-03-19 2004-10-21 Taiwan Semiconductor Mfg System and method for defining interface of manufacture execution system
US7350191B1 (en) * 2003-04-22 2008-03-25 Noetix, Inc. Computer implemented system and method for the generation of data access applications
JP2004015838A (ja) 2003-10-06 2004-01-15 Toshiba Corp 仮想的転送路形成方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5872977A (en) * 1997-08-08 1999-02-16 International Business Machines Corporation Object-oriented method and apparatus for creating a makefile
US20020040469A1 (en) * 2000-06-03 2002-04-04 International Business Machines Corporation System and method for the configuration of software products
US20020199170A1 (en) * 2001-06-21 2002-12-26 Jameson Kevin Wade Collection makefile generator

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220350587A1 (en) * 2021-04-29 2022-11-03 Salesforce.Com, Inc. Methods and systems for deployment of services

Also Published As

Publication number Publication date
JP5209209B2 (ja) 2013-06-12
CN100478877C (zh) 2009-04-15
KR20060123513A (ko) 2006-12-01
EP1723513B1 (de) 2008-08-27
KR101154730B1 (ko) 2012-06-08
JP2007523407A (ja) 2007-08-16
DE502005005190D1 (de) 2008-10-09
DE102004005730A1 (de) 2005-08-25
US8365163B2 (en) 2013-01-29
EP1723513A1 (de) 2006-11-22
CN1918545A (zh) 2007-02-21
ES2309706T3 (es) 2008-12-16
ATE406610T1 (de) 2008-09-15
US20070261028A1 (en) 2007-11-08

Similar Documents

Publication Publication Date Title
EP1723513B1 (de) Verfahren zur konfiguration eines computerprogramms
EP1904923A1 (de) Verfahren und softwaresystem zur konfiguration eines modularen systems
DE69604347T2 (de) Bestimmung der dynamischen Eigenschaften von Programmen
DE102018003142A1 (de) Automatische Einstellung von Multitasking-Konfigurationen für ein Codeprüfsystem
WO2004077305A1 (de) System und verfahren zum verwalten und zum austausch von daten eines technischen projektes, einer technischen anlage sowie einzelner anlagenkomponenten
DE10243781A1 (de) Elektronische Vorrichtung für ein Bussystem
DE102014210854A1 (de) Computerimplementiertes Verfahren und Signalfolge für ein Programm zur Wiederverwendung von ausführbaren Softwarekonfigurationen für Softwaresysteme sowie Rechneranlage und ein Computerprogramm mit Programmcode zur Durchführung des Verfahrens
DE102011014831A1 (de) Verfahren und vorrichtung zum analysieren vonsoftware mit einem kalibrierten wert
EP2363809B1 (de) Verfahren zur Optimierung eines Steuerprogramms für Aktuatoren
DE112009001892T5 (de) Datensatz basierte Codestruktur
DE102020127824A1 (de) Integrierte Simulationscode- und Produktionscodegenerierung
EP3719632A1 (de) Verfahren und vorrichtung zur verwaltung von softwaremodulen und von objekten
WO2004088549A2 (de) Verfahren und anordnung zur veränderung von software oder quellcode
DE69322800T2 (de) Verfahren zur Leistungsverbesserung in einem automatischen Testsystem
DE102008048862A1 (de) Testmodul und Verfahren zum Testen einer O/R-Abbildungs-Middleware
DE10300541A1 (de) Erzeugen einer ausführbaren Datei
EP1343078B1 (de) System zur Modellierung und Generierung von Softwaregenerierungssystemen
DE102018130729B3 (de) Verfahren zum Erzeugen einer grafischen Darstellung einer Signalverarbeitungsfunktionalität
EP2175331A1 (de) Steuerbares Gerät mit einem Steuerprogramm und Verfahren zum Steuern des Geräts
EP1621945B1 (de) Konsistenzsicherung in einem Automatisierungssystem
WO2006094966A2 (de) Verfahren zum erstellen einer dokumentation
EP0560342B1 (de) Verfahren zum Untersuchen des Ablaufs eines in einer Hardware-Beschreibungssprache geschriebenen Programms
DE102021128101A1 (de) Verfahren zum Erzeugen von Programmcode, Verfahren zum Konfigurieren eines Steuergeräts und Computersystem
WO2020099524A1 (de) Verfahren und systeme zur bereitstellung von leistungsdaten eines steuergerätes im fahrbetrieb
DE102004039200A1 (de) Versionskontrolle

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2005701596

Country of ref document: EP

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 200580004153.2

Country of ref document: CN

Ref document number: 1020067015780

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2006551837

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 2005701596

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1020067015780

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 10588596

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10588596

Country of ref document: US

WWG Wipo information: grant in national office

Ref document number: 2005701596

Country of ref document: EP