EP1609061A2 - Verfahren und anordnung zur veränderung von software oder quellcode - Google Patents

Verfahren und anordnung zur veränderung von software oder quellcode

Info

Publication number
EP1609061A2
EP1609061A2 EP04739074A EP04739074A EP1609061A2 EP 1609061 A2 EP1609061 A2 EP 1609061A2 EP 04739074 A EP04739074 A EP 04739074A EP 04739074 A EP04739074 A EP 04739074A EP 1609061 A2 EP1609061 A2 EP 1609061A2
Authority
EP
European Patent Office
Prior art keywords
code
formulated
language
codeml
transformation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04739074A
Other languages
English (en)
French (fr)
Inventor
Roy Oberhauser
Christian Reichel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens 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
Priority claimed from DE10314832A external-priority patent/DE10314832B3/de
Priority claimed from DE10314835A external-priority patent/DE10314835A1/de
Priority claimed from DE10314831A external-priority patent/DE10314831A1/de
Priority claimed from DE10314834A external-priority patent/DE10314834A1/de
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP1609061A2 publication Critical patent/EP1609061A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/51—Source to source

Definitions

  • the invention relates to a method and an arrangement for changing software or source code, in which software or source code is converted into a representation in a meta markup language, for example XML, transformed there, for example with XSLT, and then transformed transformed representation formulated in the meta markup language is converted back into modified software or into modified source code, for example the same source language.
  • a meta markup language for example XML
  • XSLT XSLT
  • Parameterization is one way of influencing software. Configuration files are typically used for parameterization and storage of application-specific “parameter data 1 *.
  • the structure and structure of these files is determined during the development phase and can never be changed after the software has been delivered.
  • plugins open up the possibility of “delivered”, compiled software to expand functionality. For this it is necessary that the structures for the integration and use of plugins are created or defined during the development phase (interfaces, ).
  • Code generators generate source or binary code with the help of templates / templates that are provided at predetermined locations, e.g. B. by means of passed parameters. In this way it becomes possible that e.g. B. different software is generated for different customers, which differs in precisely defined places. However, only special digits (and not any digits) can be changed in the code, which must be precisely specified when the template is created. Code generators are typically used by developers.
  • a Java source code transformation tool BeautyJ is known from the Internet at http: // beautyj .berlios.de /, in which a Java source code is converted into an XML representation, using the Sourclet API, for example by inserting spaces or changed comments certain places, "embellished and then the modified source code can be converted back to Java source code.
  • the invention essentially consists in that in a first variant, selected components of a software serve as points of variation by converting them into a first code formulated in a meta markup language, e.g. XLML, the software is now delivered in mixed form, and the first code is supplied by the customer by one or several transformations, e.g.
  • XSLT can only be converted depending on the transformation rules into a second code formulated in the meta markup language, that in a second variant a first code formulated in a meta markup language that contains at least one language extension depending on the transformation rules in a more easily verifiable second code formulated in the meta markup language is transferred without these language extensions, that in a third variant a source code transformed into a meta markup language is transformed in such a way that, after a conversion back into the original Pro programming language, a new source code is created, in which not only the representation, but also the actual program content or functionality has been changed, or that in a fourth variant, a source code transformed into a meta-markup language with, for example, initial states, code fragments to be exchanged and up the respective natural language of the user-tailored foreign language modules is mixed by transformation, whereby, after a conversion, a new source code is created in which not only the representation but also the actual one
  • FIG. 1 shows an overall block diagram to explain a first variant of the invention
  • FIG. 2 shows an overall block diagram to explain a second variant of the invention
  • FIG. 3 shows a block diagram to explain the transfer of pre-processing extensions according to the invention
  • FIG. 4 shows an overall block diagram to explain a third variant of the invention
  • FIG. 5 shows a block diagram to explain the modification according to the invention through the use of aspects
  • FIG. 6 shows a block diagram to explain the insertion of migrability functionality according to the invention
  • FIG. 7 shows a block diagram to explain the modification according to the invention through the use of templates, filters and patterns,
  • FIG. 8 overall block diagram to explain a fourth variant of the invention
  • FIG. 9 shows a block diagram to explain the exchange of code fragments according to the invention.
  • FIG. 10 shows a block diagram to explain the insertion of status data according to the invention
  • FIG. 11 is a block diagram to explain the
  • FIG. 12 shows a block diagram to explain the installation of foreign language modules according to the invention for the internationalization of the source code.
  • FIG. 1 shows an overall block diagram to explain the invention, in which software SW consisting of source text SCI, SC2 and SC is first converted into software SW * that can be delivered, with some parts of the software such as SCI now being binary code / byte code B1 are available, and other parts such as SC2 are converted by a converter COV into a first code CodeML formulated in a meta markup language, so that from now on they form variation points VP, for example VP1, in the executable software SW *.
  • software SW consisting of source text SCI, SC2 and SC is first converted into software SW * that can be delivered, with some parts of the software such as SCI now being binary code / byte code B1 are available, and other parts such as SC2 are converted by a converter COV into a first code CodeML formulated in a meta markup language, so that from now on they form variation points VP, for example VP1, in the executable software SW *.
  • This software SW * can be modified before / or at runtime in such a way that the code VP, for example VP2, shown in the meta markup language, with a transformation T and transformation rules TR, into a second code CodeML * formulated in the meta markup language is converted, which is now either available as a modified variation point, for example VP2 * in SW * or is converted by a converter RCONV after the transformation T into a source code SC * and then by means of COMP into a byte code / binary code VP2B *.
  • SW and SW * differ at the points of variation and can thus be adapted to specific requirements (e.g. Tookit exchange, updates, etc.).
  • CodeML and CodeML * or VP and VP * are formulated, for example, in the meta markup language XML, where “XML * stands for Extended Markup Language.
  • a software delivery to two different customers can use different toolkits, which differ in terms of performance, price, etc.
  • Customizing, updating, etc. required and not a number of different, partly proprietary tools.
  • the method is based on standards such as XML and XSLT and is subject to fewer restrictions in terms of convertibility into other programming languages than other methods for modifying source code.
  • This type of modification allows the creation of hierarchies, among other things. through the possibility of orderly, automated sequential execution (pipelines) of several transformations, e.g. patches.
  • the transformations can be saved for general reuse in XSLT files, so that libraries can be created for certain processes, for example.
  • An XML representation of the source code can be stored in an XML database and, if necessary, can be easily adapted to the respective customer needs using an XSLT (customization).
  • the code can be checked (validated) in advance (without compilation) for certain correctness aspects.
  • code reuse can be improved by better finding code or code fragments or templates.
  • FIG. 2 shows an overall block diagram to explain the invention, in which a first code CodeML formulated in a meta markup language, which contains a language extension LE and cannot be converted into valid source text SC * by RCONV, by means of a transformation T as a function of transformation rules TR, which contain a language converter LC, is converted into a second code CodeML * formulated in the meta-markup language, which does not contain these language extensions LE and can therefore be converted into a source code SC *, which in turn can be converted into valid binary code by means of a compiler COMP / ByteCode B * is convertible.
  • the modified source code SC * are, for example, in the Java programming language and the codes CodeML and CodeML * are, for example, in the meta-markup language XML, where “XML” stands for Extended Markup Language.
  • the transformation T e.g. B. an Extended Stylesheet Language Transformation or XSLT
  • transformation rules TR z. B. described within XSL (Extended Stylesheet Language) files, whereby e.g. the rules formulated in XSL include are used as Language Converter LC and describe how the XML-coded source code CodeML with a language extension LE can be transformed into a variant without language extension.
  • XSL Extended Stylesheet Language
  • FIG. 3 shows a first exemplary embodiment in which a first code CodeML formulated in a meta markup language contains a language extension for PreProcessing PPE (e.g. ⁇ define>, ⁇ ifdef>, etc.), and with the aid of a transformation T as a function of
  • PPE PreProcessing
  • Transformation rules TR which have a PreProcessing Language Converter PPLC that dissolves or applies the PPE, are transformed into a second code CodeML * formulated in the meta-markup language without language extension.
  • the language extension is typically designed in the form of elements for generic programming 1 and / or for pre-processing 2 and / or a customer-specific or developer-specific grammar 3 and / or for macros 4.
  • the programmer is given more freedom by the invention, since the grammar of the programming language used is based on the The wishes of the programmer can be coordinated and a re-transformation to the normal grammar of the programming language only has to take place at the end of program development.
  • Another major advantage is that the language extensions can be validated with a compiler intended for the normal programming language.
  • the method is based on standards such as XML and XSLT and is subject to fewer restrictions in terms of convertibility into other programming languages than other methods for modifying source code.
  • This type of modification allows the creation of hierarchies, among other things. through the possibility of orderly, automated sequential execution (pipelines) of several transformations, e.g. of language adjustments.
  • transformations can be saved for general reuse in XSLT files, so that libraries e.g. can arise for certain processes.
  • An XML representation of the source code can be stored in an XML database and, if necessary, with the help of a
  • XSTL can be easily adapted to the respective customer or developer needs (customization).
  • the code can be checked (validated) in advance (without compilation) for certain correctness aspects.
  • FIG. 4 shows an overall block diagram for explaining the invention, in which a source code SC is first converted by a converter CONV into a first code CodeML formulated in a meta markup language, the source code SC being immediately
  • Compilation would result in a byte code or binary code B.
  • the code CodeML shown in the meta markup language is now modified on the way of a transformation T exclusively by using transformation rules TR, which consist of conditions C and / or logic L and / or code fragments CF, which results in a second codeML *, also formulated in the meta-markup language .
  • Another converter RCONV converts the code CodeML * back into a source code SC * after the transformation, which is typically formulated in the same language as the source code SC.
  • the modified code SC * is finally converted into a modified byte code B * or else into an executable binary code by a compiler COMP. It is important here that the byte code B * differs in principle from the byte code B or that the source code has been changed not only in its representation but also in its program flow.
  • the source code SC and the modified source code SC * are, for example, in the Java programming language and the codes CodeML and CodeML * are, for example, in the meta-markup language XML, where “XML * for Extended
  • the transformation T e.g. B. an Extended Stylesheet Language Transformation or XSLT
  • transformation rules TR z. B. described within XSL (Extended Stylesheet Language) files, whereby e.g. the rules TR formulated in XSL and others describe how the XML-coded source code CodeML is combined with the code fragment CF to form a new modified source code CodeML * with integrated CF, or a modification thereof, which can now contain additional logging functionality, for example.
  • FIG. 5 shows a first exemplary embodiment in which the transformation rules TR correspond specifically to aspect rules AR according to aspect-oriented programming (AOP) which expressed in the AspectJ language, contain at least one Pointcut PC and / or at least one Advice-Type AT and / or at least one Advice-Body AB and can be assigned in their order to the components from Figure 5.
  • AOP aspect-oriented programming
  • an aspect is a unit that contains crosscutting concerns, e.g. logging, modularized and encapsulated in one place.
  • the corresponding code which has hitherto passed through several modules, is brought together using a single aspect.
  • LoggingAspect .xsl which contains all the necessary transformation rules and ensures that every method with a "cal * in its name is found and at the beginning of the execution of this method a print command System.out.printin (" calculate begin ⁇ ) and at the end of executing this method
  • FIG. 6 relates to a second application example of the invention, in which CodeML is also used from a source code the transformation T generates a transformed code CodeML *, which now contains a mechanism for securing (OLD) or determining (NEW) at least one state for the desired (version) migration.
  • the transformation rules TR are designed in such a way that they can be referred to as migration rules MR and, in addition to C and L, at least one fragment, so-called checkpoints CP, for generating (CP write) or reading in (CP read) states ( CP Data), which enable migration from an older version B * OLD to a newer version B * NEW.
  • the format conversions of the system states to be transferred, which are required for a migration can also be taken into account here. This means that future migrations do not need to be taken into account in advance, which means that the test effort and related potential program errors in early program versions are avoided. Automating the migration avoids human errors, since the migration is much more systematic.
  • FIG. 7 shows a third exemplary embodiment in several sub-variants, in which a source code CodeML encoded in XML is also converted into a modified CodeML * by a transformation T.
  • transformation T is effected here by transformation rules TR, which in each variant consist of at least C and L and, like in the implementation of templates TP, additionally contain at least one template fragment TPF, for example for the conversion into an EJB (Enterprise Java Bean) and have at least one pattern fragment PF when converting patterns P, for example for the use of proxy, factory or singleton patterns.
  • TPF template fragment
  • P for example for the use of proxy, factory or singleton patterns.
  • C and L are sufficient, since only code is removed here, and unnecessary output statements or comments, for example, can be eliminated.
  • proxy patterns appropriately, local calls can be converted into remote calls or, similarly, local classes into EJB classes (Enterprise Java Beans).
  • a valid template TP which can be used as a template for other source code, can also be generated from the XML-coded source code JavaML or a fragment of this code.
  • the method is based on standards such as XML and XSLT and is subject to fewer restrictions with regard to convertibility into other programming languages than other methods for modifying source code.
  • transformations can be saved as general transformations for reuse in XSLT files, so that libraries e.g. can arise for certain processes.
  • An XML representation of the source code can be stored in an XML database and, if necessary, can be easily adapted to the respective customer needs using an XSLT.
  • the code can be checked (validated) in advance (without compilation) for certain correctness aspects.
  • Permanent XML-based program libraries that support XPath requests can improve the reuse of code by better finding code or code fragments or templates.
  • FIG. 8 shows an overall block diagram to explain the invention, in which a source code SC is converted by a converter CONV into a first code CodeML formulated in a meta markup language, the source code SC being able to produce a byte code or binary code B when compiled immediately. Additional information INFO is now added to the code CodeML or ultimately the source code SC to the code CodeML shown in the meta-markup language by means of a transformation T described by transformation rules TR, which results in a second code also formulated in the meta-markup language CodeML * results.
  • Another converter RCONV converts the code CodeML * back into a source code SC * after the transformation, which is typically formulated in the same language as the source code SC.
  • the modified code SC * is finally converted into a modified byte code B * or else into an executable binary code by a compiler COMP. It is important here that the byte code B * differs from the byte code B or that the source code has been changed not only in its representation but also in its program flow.
  • the source code SC and the modified source code SC * are, for example, in the Java programming language and the codes CodeML and CodeML * are, for example, in the meta-markup language XML, where “XML * stands for Extended Markup Language.
  • FIG. 10 shows a first exemplary embodiment in which the additional information INFO in the form of data D, for example initialization states SSDb, state data SDa, database data De, any data x, is mixed into the CodeML, these data being, for example, fixed states or values for constants and variables.
  • the source code SC can be supplied with fixed states and transformed so that a required state is immediately available at runtime of the program, for example as initialization state SSDb can no longer be determined separately.
  • object states can also be introduced into the code, which enable the recovery of an interrupted program at the same location with the same states, without having to take additional complex program-technical precautions for this.
  • transformation T e.g. B.- an Extended Stylesheet Language Transformation, or XSLT
  • transformation rules TR e.g. B. described within XSL (Extended Stylesheet Language) files, whereby e.g. the rules formulated in XSL include describe how the XML-coded source code CodeML is combined with the status data from D to form a new modified source code CodeML * with SSDb, SDa and De.
  • the rules of a transformation T can be such that the information is mixed in its original form but also in a form changed by rules.
  • the rules of a transformation T can also be such that the transformation T, e.g. with the help of if conditions that influence information or data.
  • FIG. 9 shows a second exemplary embodiment in which a code fragment CFb coded in XML with an original source code CodeML coded in XML, which contains a code fragment CFa, is transformed by the transformation T such that the coded XML is modified Source code CodeML * contains a code fragment CFb instead of the previously existing fragment CFa.
  • the transformation T is also controlled by transformation rules TR.
  • Such an exchange of code fragments can e.g. be referred to as "patching *.
  • patching can be achieved in a consistent manner with a maximum degree of freedom for the software developer, this being possible, for example, automatically and taking mutual dependencies into account.
  • Listing 1A For this exemplary embodiment, a specific case is shown by the listings 1A to 6A of the program listings located in Appendix 5. From the Java source code TestOutput. java in turn becomes a text output. java generated.
  • Listing 3A shows the CodeFragment.xml file, which provides a code fragment.
  • listing 5A is the content of the file TestOutput.xjava (*) with the modified XML source code and in listing 6A in the file TestOutput. java (*) the modified Java source code.
  • Figure 11 relates to a third application example of the
  • the transformation XSLT is determined here by transformation rules TR, which specify the places of the source code to be changed and the respective selected natural language, for example German or English.
  • the method according to the invention thus enables the source code to be localized and internationalized in an efficient and economical manner, while minimizing the additional runtime required for this.
  • the method is based on standards such as XML and XSLT and is subject to fewer restrictions with regard to convertibility into other programming languages than other methods for modifying source code.
  • Reuse can be saved in XSLT files, so that libraries e.g. can arise for certain processes.
  • An XML representation of the source code can be stored in an XML database and, if necessary, with the help of a
  • XSTL can be easily adapted to the respective customer needs (customization).
  • the code can be checked (validated) in advance (without compilation) for certain correctness aspects.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Die Erfindung besteht im Wesentlichen darin, dass in einer ersten Variante ausgewählte Bestandteile einer Software als Variationspunkte dienen, indem diese in einen in einen ersten XML-Code umgewandelt werden, die Software nun in Mischform, ausgeliefert wird, und der erste Code kundenseitig durch eine oder mehrere Transformationen, bspw. XSLT, nur in Abhängigkeit von Transformationsregeln in einen in einen zweiten XML-Code umgewandelt werden, dass in einer zweiten Variante ein erster XML-Code, der mindestens eine Spracherweiterung enthält in Abhängigkeit von Transformationsregeln in einen leichter verifizierbaren zweiten XML-Code ohne diese Spracherweiterungen überführt wird, dass in einer dritten Variante ein in XML formulierter Quellcode derart transformiert wird, dass, nach einer Rückkonvertierung in die ursprüngliche Programmiersprache, ein neuer Quellcode entsteht, bei dem nicht nur die Darstellung, sondern auch der eigentliche Programminhalt bzw. die Funktionalität verändert wurde, oder dass in einer vierten Variante ein in XML formulierter Quellcode mit beispielsweise Ausgangszuständen, auszutauschenden Code-Fragmenten und auf die jeweilige natürliche Sprache des Anwenders zugeschnittenen Fremdsprachenmodulen durch Transformation vermischt wird, wodurch, nach einer Rückkonvertierung ein neuer Quellcode entsteht, bei dem nicht nur die Darstellung, sondern auch der eigentliche Programminhalt bzw. die Funktionalität verändert wurde.

Description

Beschreibung
Verfahren und Anordnung zur Veränderung von Software oder Quellcode
Die Erfindung betrifft ein Verfahren und eine Anordnung zur Veränderung von Software oder Quellcode, bei dem/der eine Software bzw. ein Quellcode, in eine Darstellung in einer Meta-Auszeichnungssprache, beispielsweise XML, übergeführt, dort, beispielsweise mit XSLT, transformiert und dann diese in der Meta-Auszeichnungssprache formulierte transformierte Darstellung in eine modifizierte Software oder in einen modifizierten Quellcode, beispielsweise derselben Ausgangssprache, zurückverwandelt wird.
Aus dem Stand der Technik sind zwar einige Möglichkeiten zur nachträglichen Veränderung bzw. Modifikationen von Software bekannt, die jedoch alle einige Nachteile gegenüber der Erfindung aufweisen:
Eine Möglichkeit der Einflussnahme auf Software erfolgt mit Hilfe einer Parametrisierung. Konfigurationsdateien werden typischerweise zur Parametrisierung und Speicherung anwendungsspezifischer „Parameterdaten1* verwendet. Die
Struktur und der Aufbau dieser Dateien wird dabei während der Entwicklungsphase festgelegt, und ist in keinem Fall nach der Auslieferung der Software veränderbar.
Plugins eröffnen die Möglichkeit schon „ausgelieferte"', kompilierte Software um Funktionalitätseigenschaften zu erweitern. Hierfür ist es notwendig, dass die Strukturen zur Einbindung und Nutzung von Plugins bereits während der Entwicklungsphase erstellt bzw. festgelegt werden (Schnittstellen, ... ) .
Code-Generatoren erzeugen Quell- oder Binärcode mit Hilfe von Templates/Vorlagen, die an vorgegebenen Stellen, z. B. mittels übergebener Parameter, vervollständigt werden. Auf diese Weise wird es möglich, dass z. B. für verschiede Kunden unterschiedliche Software erzeugt wird, die sich an genau definierten Stellen unterscheidet. Hierbei sind aber nur spezielle Stellen (und nicht beliebige Stellen) im Code veränderbar, welche mit der Erstellung des Templates genau spezifiziert werden müssen. Code-Generatoren werden typischer Weise auf Entwicklerseite eingesetzt.
US-Patentanmeldung US 6052531A1 ist eine spezielle
Anwendungsmöglichkeit von Variationspunkten in Form von Updates/Patches bekannt.
Aus dem Internet ist unter http: //beautyj .berlios.de/ ein Java Source Code Transformation Tool BeautyJ bekannt, bei dem ein Java Quellcode in eine XML-Darstellung umgewandelt wird, mittels Sourclet API, beispielsweise durch Einfügen von Leerzeichen oder geänderten Kommentaren an bestimmten Stellen, „verschönert und anschließend der modifizierte Quellcode in Java Quellcode zurück konvertiert werden kann.
Eine Transformation mittels XSLT wird hier, für diesen Zweck, nur vorgeschlagen, aber nicht umgesetzt.
Die der Erfindung zugrunde liegende Aufgabe liegt nun darin, ein Verfahren und eine Anordnung zur Modifikation von
Quellcode anzugeben, bei dem/der eine weitergehende noch flexiblere und effizientere Modifikation der Software bzw. des Quellcodes erreicht wird.
Diese Aufgabe wird hinsichtlich des Verfahrens durch die
Merkmale der Patentansprüche 1, 6, 8 und 13 und hinsichtlich der Anordnung durch die Merkmale der Patentansprüche 22 bis 26 erfindungsgemäß gelöst. Die weiteren Ansprüche betreffen bevorzugte Ausgestaltungen der Erfindung.
Die Erfindung besteht im Wesentlichen darin, dass in einer ersten Variante ausgewählte Bestandteile einer Software als Variationspunkte dienen, indem diese in einen in einer Meta-Auszeichnungssprache, bspw. XLML, formulierten ersten Code umgewandelt werden, die Software nun in Mischform, ausgeliefert wird, und der erste Code kundenseitig durch eine oder mehrere Transformationen, bspw. XSLT, nur in Abhängigkeit von Transformationsregeln in einen in der Meta- Auszeichnungssprache formulierten zweiten Code umgewandelt werden, dass in einer zweiten Variante ein in einer Meta- Auszeichnungssprache formulierter erster Code, der mindestens eine Spracherweiterung enthält in Abhängigkeit von Transformationsregeln in einen in der Meta- Auszeichnungssprache formulierten leichter verifizierbaren zweiten Code ohne diese Spracherweiterungen überführt wird, dass in einer dritten Variante ein in eine Meta- Auszeichnungssprache transformierter Quellcode derart transformiert wird, dass, nach einer Rückkonvertierung in die ursprüngliche Programmiersprache, ei neuer Quellcode entsteht, bei dem nicht nur die Darstellung, sondern auch der eigentliche Programminhalt bzw. die Funktionalität verändert wurde, oder dass in einer vierten Variante ein in eine Meta- Auszeichnungssprache transformierter Quellcode mit beispielsweise Ausgangszuständen, auszutauschenden Code- Fragmenten und auf die jeweilige natürliche Sprache des Anwenders zugeschnittenen Fremdsprachenmodulen durch Transformation vermischt wird, wodurch, nach einer Rückkonvertierung ein neuer Quellcode entsteht, bei dem nicht nur die Darstellung, sondern auch der eigentliche
Programminhalt bzw. die Funktionalität verändert wurde.
Die Erfindung wird im Folgenden anhand der in den Zeichnungen dargestellten Beispiele näher erläutert. Dabei zeigt Figur 1 ein Gesamtblockdiagramm zur Erläuterung einer ersten Erfindungsvariante,
Figur 2 ein Gesamtblockdiagramm zur Erläuterung einer zweiten Erfindungsvariante,
Figur 3 ein Blockschaltbild zur Erläuterung der erfindungsgemäßen Überführung von PreProcessing- Erweiterungen,
Figur 4 ein Gesamtblockdiagramm zur Erläuterung einer dritten Erfindungsvariante,
Figur 5 ein Blockschaltbild zur Erläuterung der erfindungsgemäßen Modifikation durch die Verwendung von Aspekten,
Figur 6 ein Blockschaltbild zur Erläuterung des erfindungsgemäßen Einfügens von Migrierbarkeits- Funktionalität,
Figur 7 ein Blockschaltbild zur Erläuterung der erfindungsgemäßen Modifikation durch den Einsatz von Templates, Filtern und Patterns,
Figur 8 Gesamtblockdiagramm zur Erläuterung einer vierten ErfindungsVariante,
Figur 9 ein Blockschaltbild zur Erläuterung des erfindungsgemäßen Austauschens von Code-Fragmenten,
Figur 10 ein Blockschaltbild zur Erläuterung des erfindungsgemäßen Einfügens von Zustandsdaten,
Figur 11 ein Blockschaltbild zur Erläuterung der
Variationsmöglichkeiten des erfindungsgemäßen Einbaus von Informationen und Figur 12 ein Blockschaltbild zur Erläuterung des erfindungsgemäßen Einbaus von Fremdsprachmodulen zur Internationalisierung des Quellcodes.
1. Erfindungsvariante
In Figur 1 ist ein Gesamtblockdiagramm zur Erläuterung der Erfindung dargestellt, bei dem zunächst eine Software SW bestehend aus Quelltext SCI, SC2 und SC in eine auslieferungsfähige Software SW* umgewandelt wird, wobei einige Teile der Software wie bspw. SCI nun als Binärcode/Byte Code Bl zur Verfügung stehen, und andere Teile wie bspw. SC2 durch einen Konverter COV in einen in einer Meta-Auszeichnungssprache formulierten ersten Code CodeML umgewandelt werden, so daß sie in der lauffähigen Software SW* fortan Variationspunkte VP bspw. VP1 bilden. Diese Software SW* kann vor/oder zur Laufzeit auf eine Weise modifiziert werden, das der in der Meta-Auszeichnungssprache dargestellte Code VP, bspw. VP2 , mit einer Transformation T und Transformationsregeln TR in einen zweiten in der Meta- Auszeichnungssprache formulierten Code CodeML* umgewandelt wird, welcher nun entweder als geänderter Variationspunkt bspw. VP2* in SW* vorhanden ist oder durch einen Konverter RCONV nach der Transformation T in einen Quellcode SC* und danach mittels COMP in einen ByteCode/Binärcode VP2B* überführt wird. In beiden Fällen unterscheiden sich SW und SW* an den Stellen der Variationspunkte und können auf diese Weise an spezifische Anforderungen (bspw. Tookit-Austausch, Updates, usw. ) angepasst werden.
Die Codes CodeML und CodeML* bzw. VP und VP* sind beispielsweise in der Meta-Auszeichnungssprache XML formuliert, wobei „XML* für Extended Markup Language steht.
Von besonderem Vorteil ist hierbei, dass dies nicht vom Programmentwickler durchgeführt werden muss, sondern vom entsprechend ausgestatteten und informierten Kunden selbst erledigt werden kann. Hierzu braucht ein Operator oder Administrator auf der Kundenseite nur eine entsprechende Transformation T mit den benötigten Ersetzungs-, Modifikations- und Entfernungsregeln TR anzuwenden, um die
Software auf seine speziellen Bedürfnisse anzupassen bzw. ein Update oder Patching durchzuführen. Beim Update oder Patching von kundenspezifisch angepasster treten bislang häufig Probleme wegen Inkonsistenzen auf, die durch diese Erfindung und die Möglichkeit der Pipelineanwendung bzw. geordnete Hintereinanderausführung von Anfang an vermieden werden können.
Die im Anhang 1 befindlichen Programmauflistungen Listing 1 bis Listing 5 zeigen dies an einem konkreten Beispiel:
Typischerweise kann eine Software-Auslieferung an zwei unterschiedliche Kunden unterschiedliche Toolkits verwenden, die sich hinsichtlich Performance, Preis usw. unterscheiden.
So soll hier ein Code der ursprünglich eine
Registrierungsklasse
Import electrie.registry.Registry aus einem Glue-Toolkit verwendet, beim zweiten Kunden nun zwei neue "Registrierungsklassen" import org.apache.axis .client.Call und import org.apache.axis .dient. Service aus einem Axis-Tookit verwenden .
In XSL kann dies z.B. mittels
<xsl: template match="import">
<xsl : if test="dot/name= "Registry"^ <import> <dot> <dot><dot><dot><name>org</name><name>apache</name></dot><name>axis</name></dot>
<name>client</name></dot><name>Call</name> </dot> </import> <import> <dot>
<dot><dot><dot><name>org</name><name>apache</name></dot><name>axis</narae></dot> <name>client</name></dot><name>Service</name> </dot> </import> </xsl:if> <xsl : if test="dot/name ! = ' Registry' ">
<xsl:copy-of select="."/> </xsl:if>
</xsl:template>
geschehen. Schablonen bzw. Templates werden in XSL auf das in match definierte Muster angewendet. Das import-Template im Listing-Beispiel also auf alle ursprünglichen import- Anweisungen. Im konkreten Beispiel ignoriert es einfach alle ursprünglichen GIUE-Registry-Imports, und fügt stattdessen die zwei Axis-spezifischen imports ein.
Durch das erfindungsgemäße Verfahren ergeben sich noch eine Reihe von zusätzlichen Vorteilen, wie beispielsweise:
1. Es ist nur ein System für Problemstellungen wie Patching,
Customizing, Updating, etc. erforderlich und nicht eine Reihe verschiedener teilweise proprietärer Werkzeuge.
2. Das Verfahren basiert auf Standards wie XML und XSLT und ist hinsichtlich der Konvertierbarkeit in andere Programmiersprachen geringeren Beschränkungen unterworfen als andere Verfahren zur Modifikation von Quellcode.
3. Selbst für spezielle und komplizierte Quellcode- Modifikationen sind keine proprietären Speziallösungen erforderlich, sondern es können hierfür existierende Standards wie XSLT, XPath und XQuery genutzt werden.
4. Diese Art der Modifikation erlaubt die Erstellung von Hierarchien u.a. durch die Möglichkeit zur geordneten, automatisierten Hintereinanderausführung (Pipelines) mehrerer Transformationen, bspw. von Patches.
5. Die Transformationen können für eine allgemeine Wiederverwendung in XSLT-Dateien gespeichert werden, so daß Bibliotheken z.B. für bestimmte Abläufe entstehen können. 6. Es kann eine XML-Repräsentation des Quellcodes in einer XML-Datenbasis gespeichert und bei Bedarf mit Hilfe einer XSLT in einfacher Weise an die jeweiligen Kundenbedürfnisse angepasst werden (Customization) .
7. Durch die Verwendung der Standards XMLSchema oder DTD oder entsprechende XSLTs kann der Code vorab (ohne Kompilierung) , auf bestimmte Korrektheitsaspekte hin, überprüft (validiert) werden.
8. Übliche XML-Tools können zur einfachen Bearbeitung bzw. Visualisierung und Bestimmung von Beziehungen im Code verwendet werden.
9. Dauerhafte XML-basierte Programmbibliotheken, die XPath-
Anfragen unterstützen, können die Wiederverwendung von Code durch besseres Auffinden eines Codes bzw. von Code-Fragmenten oder Templates verbessert werden.
2. Erfindungsvariante
In Figur 2 ist ein Gesamtblockdiagramm zur Erläuterung der Erfindung dargestellt, bei dem ein in einer Meta- Auszeichnungsprache formulierter erster Code CodeML, der eine Spracherweiterung LE enthält und durch RCONV nicht in gültigen Quelltext SC* überführbar ist, durch eine Transformation T in Abhängigkeit von Transformationsregeln TR, welche einen Sprachkonverter LC enthalten, in einen in der Meta-Auszeichnungssprache formulierten zweiter Code CodeML* ohne überführt wird, welcher keine diese Spracherweiterungen LE enthält und deshalb in einen Quellcode SC* verwandelt werden kann, welcher mittels eines Compilers COMP wiederum in gültigen Binärcode/ByteCode B* überführbar ist. Der modifizierte Quellcode SC* sind beispielsweise in der Programmiersprache Java und die Codes CodeML und CodeML* sind beispielsweise in der Meta-Auszeichnungssprache XML formuliert, wobei „XML' für Extended Markup Language steht.
Die Transformation T, z. B. eine Extended Stylesheet Language Transformation oder XSLT, wird durch Transformationsregeln TR, z. B. innerhalb von XSL (Extended Stylesheet Language) Dateien beschrieben, wobei bspw. die in XSL formulierten Regeln u.a. als Language Converter LC verwendet werden und beschreiben wie der in XML-codierte Quellcode CodeML mit einer Spracherweiterung LE in eine Variante ohne Spracherweiterung transformierbar ist.
In Figur 3 ist ein erstes Ausführungsbeispiel dargestellt, bei dem ein in einer Meta-Auszeichnungssprache formulierter erster Code CodeML eine Spracherweiterung für PreProcessing PPE (z.B. <define>, <ifdef>, usw.) enthält, und mit Hilfe einer Transformtion T in Abhängigkeit von
Transformationsregeln TR, welche einen PreProcessing Language Converter PPLC besitzen der PPE auflöst bzw. anwendet, in einen in der Meta-Auszeichnungssprache formulierten zweiten Code CodeML* ohne Spracherweiterung transformiert wird.
Die Ausgestaltung der Spracherweiterung erfolgt typischerweise in Form von Elementen für die generische Programmierung 1 , und/oder für PreProcessing 2 und/oder eine künden- bzw. entwicklerspezifische Grammatik 3 und/oder für Makros 4.
Alle Spracherweiterung bzw. der CodeML selbst kann jederzeit durch den Einsatz von DTDs (document type definitions) bzw. XMLSchema validiert werden.
Der Programmierer erhält durch die Erfindung mehr Freiheiten, da die Grammatik der verwendeten Programmiersprache auf die Wünsche des Programmierers abgestimmt werden kann und eine Rücktransformation auf die normale Grammatik der Programmiersprache erst am Ende der Programmentwicklung erfolgen muss. Ein wesentlicher Vorteil besteht auch darin, dass eine Validierung der Spracherweiterungen mit einem für die normale Programmiersprache vorgesehenen Compiler erfolgen kann.
Die im Anhang 2 befindlichen Programmauflistungen Listing 1 bis Listing 3 zeigen die Auflösung der PreProcessing-
Erweiterungen PPE an einem konkreten Beispiel, bei dem die in Listing 1 dargestellte Klasse Testoutput. java eine PPE in Form von <define name="m" value="private"> enthält, welche Einfluß auf die Werte der <m>-Elemente nimmt, und durch eine Transformation T in Abhängigkeit von Transformationsregeln TR (hier: PPLC) nun in die in Listing 2 dargestellte XML- basierte Form Testoutput.xjava* überführt wird, bei der alle <m>-Eleιtιente durch ein über value-'private" bestimmtes <private/>- Ele ent ersetzt werden. Hiermit wird es möglich TestOutput.xjava* in den in Listing 3 aufgezeigten Quellcode TestOutput. java zu überführen.
Durch das erfindungsgemäße Verfahren ergibt sich noch eine Reihe von weiteren Vorteilen, wie beispielsweise:
1. Es ist nur ein System für Problemstellungen wie Customizing von Programmiersprachen, usw. erforderlich und nicht eine Reihe verschiedener teilweise proprietärer Werkzeuge .
2. Das Verfahren basiert auf Standards wie XML und XSLT und ist hinsichtlich der Konvertierbarkeit in andere Programmiersprachen geringeren Beschränkungen unterworfen als andere Verfahren zur Modifikation von Quellcode.
3. Selbst für spezielle und komplizierte Quellcode- Modifikationen sind keine proprietären Speziallösungen erforderlich, sondern es können hierfür existierende Standards wie XSLT, XPath und XQuery genutzt werden.
4. Diese Art der Modifikation erlaubt die Erstellung von Hierarchien u.a. durch die Möglichkeit zur geordneten, automatisierten Hintereinanderausführung (Pipelines) mehrerer Transformationen, bspw. von Sprachanpassungen.
5. Die Transformationen können für eine allgemeine Wiederverwendung in XSLT-Dateien gespeichert werden, so daß Bibliotheken z.B. für bestimmte Abläufe entstehen können.
6. Es kann eine XML-Repräsentation des Quellcodes in einer XML-Datenbasis gespeichert und bei Bedarf mit Hilfe einer
XSTL in einfacher Weise an die jeweiligen Kunden- bzw. Entwicklerbedürfnisse angepasst werden (Customization) .
7. Durch die Verwendung der Standards X LSchema oder DTD oder entsprechende XSLTs kann der Code vorab (ohne Kompilierung) , auf bestimmte Korrektheitsaspekte hin, überprüft (validiert) werden.
8. Übliche XML-Tools können zur einfachen Bearbeitung bzw. Visualisierung und Bestimmung von Beziehungen im Code verwendet werden.
3. Erfindungsvariante
In Figur 4 ist ein Gesamtblockdiagramm zur Erläuterung der Erfindung dargestellt, bei dem zunächst ein Quellcode SC durch einen Konverter CONV in einen in einer Meta- Auszeichnungssprache formulierten ersten Code CodeML umwandelt wird, wobei der Quellcode SC bei sofortiger
Kompilierung einen Byte Code bzw. Binärcode B ergeben würde. Der in der Meta-Auszeichnungssprache dargestellte Code CodeML wird nun auf dem Wege einer Transformation T ausschließlich durch die Verwendung von Transformationsregeln TR modifiziert, welche aus Bedingungen C und/oder Logik L und/oder Code-Fragmenten CF bestehen, wodurch sich ein zweiter ebenfalls in der Meta-Auszeichnungssprache formulierten Code CodeML* ergibt. Ein weiterer Konverter RCONV wandelt nach der Transformation den Code CodeML* in einen Quellcode SC* zurück, der typischerweise in derselben Sprache wie der Quellcode SC formuliert ist. Durch einen Compiler COMP wird schließlich der modifizierte Code SC* in einen modifizierten Byte Code B* oder aber gleich in einen ausführbaren Binärcode umgewandelt. Wesentlich ist hierbei, dass sich der Byte-Code B* prinzipiell vom Byte-Code B unterscheidet bzw. dass der Quellcode nicht nur in seiner Darstellung, sondern auch in seinem Programmablauf geändert wurde .
Der Quellcode SC und der modifizierte Quellcode SC* sind beispielsweise in der Programmiersprache Java und die Codes CodeML und CodeML* sind beispielsweise in der Meta- Auszeichnungssprache XML formuliert, wobei „XML* für Extended
Markup Language steht.
Die Transformation T, z. B. eine Extended Stylesheet Language Transformation oder XSLT, wird durch Transformationsregeln TR, z. B. innerhalb von XSL (Extended Stylesheet Language) Dateien beschrieben, wobei bspw. die in XSL formulierten Regeln TR u.a. beschreiben wie der in XML-codierte Quellcode CodeML mit dem Code-Fragment CF kombiniert wird, um einen neuen modifizierten Quellcode CodeML* mit integriertem CF, oder eine Abwandlung davon, zu bilden, welcher nun beispielsweise zusätzliche Logging-Funktionalität enthalten kann.
In Figur 5 ist ein erstes Ausführungsbeispiel dargestellt, bei dem die Transformationsregeln TR speziell Aspektregeln AR nach Aspektorientierter Programmierung (AOP) entsprechen, die in der AspectJ-Sprache ausgedrückt mindestens einen Pointcut PC und/oder mindestens einen Advice-Type AT und/oder mindestens ein Advice-Body AB enthalten und in ihrer Reihenfolge den Bestandteilen aus Figure 5 zugeordnet werden können.
Auf diese Weise kann eine (werkzeugunabhängige) sogenannte AOP realisiert werden, die im Vergleich zu anderen Lösungsvarianten, beispielsweise AspectJ, keinen zusätzlichen Overhead im generierten Code CodeML* erzeugt und nicht den üblichen Einschränkungen (extra Ko piler, Syntax, usw.) existierender Aspektsprachen unterliegt.
Als Aspekt bezeichnet man in AOP eine Einheit, die überkreuzende Anliegen (crosscutting concerns) z.B. ein Logging, modularisiert und an einer Stelle kapselt. Der entsprechende Code, der bisher mehrere Module durchzog, wird hierbei mit Hilfe eines einzigen Aspekts zusammengeführt.
Die im Anhang 3 befindlichen Programmauflistungen Listing 1 bis Listing 5 zeigen dies an einem konkreten Beispiel, bei dem zunächst die in Listing 1 enthaltene Datei TestCalculator . java in eine XML-Darstellung TestCalculator .xjava konvertiert wird. In Listing 3 erfolgt die Beschreibung eines Aspektes in Form einer Datei
LoggingAspect .xsl, die alle notwendigen Transformationsregeln enthält und dafür sorgt, dass jede Methode, die ein „cal* in ihrem Namen trägt, gefunden wird und zu Beginn der Ausführung dieser Methode ein Druckbefehl System.out.printin („calculate beginΛλ) und am Ende der Ausführung dieser Methode ein
Druckbefehl System.out.printin („calculate end") eingesetzt wird.
Sollen z.B. in allen 151 Klassen eines Projektes, alle Methoden die dem Muster „cal" entsprechen, also z.B. public String calcValues() o. ä., dazu veranlasst werden, eine System-Ausgabe beim Eintritt und Austritt zu tätigen, so werden zunächst mit
match="* [ (narrte () ='curly' ) and(ancestor: :method[contains (name, 'cal ')])]"
alle Methoden mit dem „calΛX- Muster ausgewählt, mit
<expr> <paren> <dot><dot><name>System</name><name>out</name></dot><name>println</name></dot> <exprs> <expr>
<xsl:text>"</xsl:text><xsl:value-of select=" .. /name"/xxsl : text> begin"</xsl :text> </expr> </exprs> </paren> </expr>
ein Statement "System. out.println( Name der Methode% + " begin")", Z.B. System, out. printin ("calculate eπd") , eingefügt, mit
<xsl:copy-of select="*" />
der ursprünglichen Code der Methode eingefügt und mit
<expr> <paren> <dot><dot><name>System</name><name>out</nameX/dot><name>println</name></dot> <exprs> <expr>
<xsl:text>"</xsl:text><xsl:value-of select=" .. /name"/Xχsl: text> end"</xsl :text> </expr> </exprs> </paren> </expr>
ein Statement "System, out. println(%Name der Methode% + " end")", Z.B. System, out. printin ("calculate end") eingefügt.
Anstatt also in allen 151 Klassen eine entsprechende Logging- Ausgabe zu veranlassen, kann dies hier innerhalb eines Logging-Aspektes an einer Stelle erfolgen. Änderungen müssen so auch nur an einer Stelle vorgenommen werden.
Figur 6 betrifft ein zweites Anwendungsbeispiel der Erfindung, bei dem ebenfalls aus einem Quellcode CodeML durch die Transformation T ein transformierter Code CodeML* erzeugt wird, welcher nun einen Mechanismus zur Sicherung (OLD) bzw. Ermittlung (NEW) mindestens eines Zustandes für die gewünschte (Versions)Migration enthält. Die Transformationsregeln TR sind in diesem Fall derart ausgebildet, dass sie als Migrationsregeln MR bezeichnet werden können und neben C und L zusätzlich mind. ein Fragment, sogenannte Checkpoints CP, zur Generierung (CP Write) bzw. zum Einlesen (CP Read) von Zuständen (CP Data) enthalten, die eine Migration von einer älteren Version B*OLD auf eine neuere Version B*NEW ermöglichen. Die für eine Migration erforderliche Formatkonvertierungen der zu übergebenden Systemzustände können hiermit ebenfalls berücksichtigt werden. Zukünftige Migrationen brauchen hierdurch nicht schon im Vorfeld berücksichtigt zu werden, wodurch der Testaufwand und diesbezügliche potenzielle Programmfehler in frühen Programmversionen vermieden werden. Durch eine Automatisierung der Migration werden menschliche Fehler vermieden, da die Migration wesentlich systematischer erfolgt.
In Figur 7 ist ein drittes Ausführungsbeispiel in mehreren Untervarianten dargestellt, bei dem ebenfalls ein in XML- codierter Quellcode CodeML durch eine Transformation T in einen modifizierten CodeML* umgewandelt wird. Die
Transformation T wird hier jedoch durch Transformationsregeln TR bewirkt, die in jeder Variante aus mindestens C und L bestehen und wie bei der Umsetzung von Templates TP zusätzlich mindestens ein Template-Fragment TPF enthalten, bspw. für die Umwandlung in eine EJB (Enterprise Java Bean) und bei der Umsetzung von Patterns P mindestens ein Pattern- Fragment PF besitzen, bspw. für die Anwendung von Proxy, Factory oder Singleton Patterns . Bei der Realisierung von Filtern FI genügen C und L, da hier nur Code entfernt wird und so bspw. überflüssige Output-Statements oder Kommentare beseitigt werden können. Durch die entsprechende Anwendung von proxy patterns können local calls in remote calls oder in ähnlicher Weise local classes in EJB-classes (Enterprise Java Beans) umgewandelt werden.
Umgekehrt kann mit Hilfe einer Transformation T und entsprechenden Regeln TR aus dem XML-codierten Quellcode JavaML oder einem Fragment dieses Codes auch ein gültiges Template TP generiert werden, das als Vorlage für anderen Quellcode anwendbar ist.
Die oben genannten Ausprägungen des erfindungsgemäßen Verfahrens können einzeln und in beliebiger Reihenfolge nacheinander erfolgen.
Durch das erfindungsgemäße Verfahren ergeben sich noch eine Reihe von zusätzlichen Vorteilen, wie beispielsweise:
1. Es können schnelle und flexible Änderungen im Quellcode vorgenommen werden.
2. Es ist nur ein System für Problemstellungen wie Patternanwendung, Migration, AOP, Filtering, etc. erforderlich und nicht eine Reihe verschiedener teilweise proprietärer Werkzeuge.
3. Das Verfahren basiert auf Standards wie XML und XSLT und ist hinsichtlich der Konvertierbarkeit in andere Programmiersprachen geringeren Beschränkungen unterworfen als andere Verfahren zur Modifikation von Quellcode.
4. Selbst für spezielle und komplizierte Quellcode- Modifikationen sind keine proprietären Speziallösungen erforderlich, sondern es können hierfür existierende Standards wie XSLT, XPath und Xquery genutzt werden. 5. Diese Art der Modifikation erlaubt die Erstellung von Hierarchien u.a. durch die Möglichkeit der Hintereinanderausführung (Pipelines) mehrerer Transformationen.
7. Die Transformationen können als allgemeine Transformationen für eine Wiederverwendung in XSLT-Dateien gespeichert werden, so daß Bibliotheken z.B. für bestimmte Abläufe entstehen können.
8. Es kann eine XML-Repräsentation des Quellcodes in einer XML-Datenbasis gespeichert und bei Bedarf mit Hilfe einer XSLT in einfacher Weise an die jeweiligen Kundenbedürfnisse angepasst werden.
9. Durch die Verwendung der Standards XmlSchema oder DTD oder entsprechende XSLTs kann der Code vorab (ohne Kompilierung) , auf bestimmte Korrektheitsaspekte hin, überprüft (validiert) werden.
10. Übliche XML-Visualisierungstools Tools können zur einfachen Bearbeitung bzw. Visualisierung und Bestimmung von Beziehungen im Code verwendet werden.
11. Dauerhafte XML-basierte Programmbibliotheken, die XPath- Anfragen unterstützen, können die Wiederverwendung von Code durch besseres Auffinden eines Codes bzw. von Code-Fragmenten oder Templates verbessert werden.
4. Erfindungsvariante
In Figur 8 ist ein Gesamtblockdiagramm zur Erläuterung der Erfindung dargestellt, bei dem zunächst ein Quellcode SC durch einen Konverter CONV in einen in einer Meta- Auszeichnungssprache formulierten ersten Code CodeML umwandelt wird, wobei der Quellcode SC bei sofortiger Kompilierung einen Byte Code bzw. Binärcode B ergeben kann. Zu dem in der Meta-Auszeichnungssprache dargestellten Code CodeML wird nun eine zusätzliche Information INFO auf dem Wege einer durch Transformationsregeln TR beschriebenen Transformation T dem Code CodeML bzw. dem letztlich dem Quellcode SC hinzugefügt, wodurch sich ein zweiter ebenfalls in der Meta-Auszeichnungssprache formulierten Code CodeML* ergibt. Ein weiterer Konverter RCONV wandelt nach der Transformation den Code CodeML* in einen Quellcode SC* zurück, der typischerweise in derselben Sprache wie der Quellcode SC formuliert ist. Durch einen Compiler COMP wird schließlich der modifizierte Code SC* in einen modifizierten Byte Code B* oder aber gleich in einen ausführbaren Binärcode umgewandelt. Wesentlich ist hierbei, dass sich der Byte-Code B* vom Byte-Code B unterscheidet bzw. dass der Quellcode nicht nur in seiner Darstellung, sondern auch in seinem Programmablauf geändert wurde.
Der Quellcode SC und der modifizierte Quellcode SC* sind beispielsweise in der Programmiersprache Java und die Codes CodeML und CodeML* sind beispielsweise in der Meta- Auszeichnungssprache XML formuliert, wobei „XML* für Extended Markup Language steht.
In Figur 10 ist ein erstes Ausführungsbeispiel dargestellt, bei dem die zusätzliche Information INFO in Form von Daten D, bspw. Initialisierungszuständen SSDb, Zustandsdaten SDa, Datenbankdaten De, beliebige Daten x, dem CodeML hinzugemischt werden, wobei diese Daten beispielsweise feste Zustände bzw. Werte für Konstanten und Variablen darstellen. Auf diese Weise kann der Quellcode SC mit festen Zuständen versorgt und transformiert werden, so dass ein benötigter Zustand zur Laufzeit des Programms, z.B. als Initialisierungszustand SSDb, sofort zur Verfügung steht und nicht mehr gesondert ermittelt werden uss. Auf diese Weise können auch Objekt-Zustände in den Code eingebracht werden, die ein Wiederaufsetzen (Recovery) eines unterbrochenen Programms am selben Ort mit denselben Zuständen ermöglichen, ohne dass zusätzliche aufwändige programmtechnische Vorkehrungen hierfür getroffen werden müssen.
Die Transformation T, z. B.- eine Extended Stylesheet Language Transformation oder XSLT, wird durch Transformationsregeln TR, z. B. innerhalb von XSL (Extended Stylesheet Language) Dateien beschrieben, wobei bspw. die in XSL formulierten Regeln u.a. beschreiben wie der in XML-codierte Quellcode CodeML mit den Zustandsdaten aus D kombiniert wird, um einen neuen modifizierten Quellcode CodeML* mit SSDb, SDa und De zu bilden.
Die Regeln einer Transformation T können dabei so geartet sein, dass die Informationen in ihrer ursprünglichen Form aber auch in einer durch Regeln geänderten Form hinzugemischt werden.
Die Regeln einer Transformation T können dabei auch so geartet sein, dass die Transformation T, z.B. mit Hilfe von if-conditions, durch die Informationen bzw. Daten beeinflusst werden.
Die im Anhang 4 befindlichen Programmauflistungen Listing 1 bis Listing 6 zeigen dies an einem konkreten Beispiel, bei dem in einer Testklasse des Quellcodes die nicht initialisierte Variable String m_sWelcome in eine initialisierte Form String m_sWelcome = "hello"; transformiert wird. Hierbei zeigt das Listing 1 das entsprechende Java-Programm TestOutput .java, dass in eine XML-Darstellung TestOutput .xjava konvertiert wird. In Listing 3 ist die XML-Datei State.XML mit dem Zustandswert "hello" dargestellt. In Listing 4 folgt dann die Transformationsanweisung zum Vermischen Mixing.xsl, die mit Anweisungen wie template match = und apply-templates dafür sorgen, dass der Code an der richtigen Stelle modifiziert wird.
In Figur 9 ist ein zweites Ausführungsbeispiel dargestellt, bei dem ein in XML codiertes Code-Fragment CFb mit einem ursprünglichen in XML codierten Quellcode CodeML, der ein Code-Fragment CFa enthält, durch die Transformation T derart transformiert wird, dass im modifizierten XML-codierten Quellcode CodeML* anstelle des bisher vorhandenen Fragments CFa ein Code-Fragment CFb enthalten ist. Die Transformation T wird hierbei auch von Transformationsregeln TR gesteuert. Ein derartiger Austausch von Code-Fragmenten kann unter bestimmten Umständen z.B. als „Patching* bezeichnet werden. Durch das erfindungsgemäße Verfahren kann ein Patching in konsistenter Weise mit einem maximalen Grad an Freiheit für den Softwareentwickler erreicht werden, wobei dies beispielsweise automatisch und unter Berücksichtigung gegenseitiger Abhängigkeiten erfolgen kann.
Für dieses Ausführungsbeispiel ist ein konkreter Fall durch die Listings 1A bis 6A der im Anhang 5 befindlichen Programmauflistungen gezeigt. Aus dem Java-Source-Code TestOutput. java wird wiederum ein TextOutput. java erzeugt. In Listing 3A kan man die Datei CodeFragment.xml erkennen, die ein Code-Fragment bereitstellt. Das Listing 4A enthält nun in der Datei Patching. sl die Regeln für die Transformation T, wobei wiederum die Befehle template match = und apply-templates zum Einsatz kommen. Im Listing 5A ist dann der Inhalt der Datei TestOutput.xjava(*) mit dem modifizierten XML Quellcode und in Listing 6A in der Datei TestOutput. java (*) der modifizierte Java Quellcode dargestellt. Bei diesem Beispiel wird in der öffentlichen Testklasse die Stringzuweisung String _sWelcome = "hello"; durch eine Stringzuweisung String m_sWelcome =
System.getPropertyC'WELCOME") ; ersetzt, wobei hier also der feste Wert "hello" durch die vom System angeforderte Eigenschaft "WELCOME" ersetzt wird, und die beispielsweise irrtümlich „hardcodierte* Wertzuweisung nun „gepatched* werden kann.
Figur 11 betrifft ein drittes Anwendungsbeispiel der
Erfindung, bei dem die Informationen INFO von Zeichnung 1 nicht nur in der oben angegebenen Weise in Form von Informationen INFOl, sondern auch zusätzlich Form von in den Transformationsregeln eingebetteten Informationen INF02 bzw. Fragmenten hinzugemischt werden.
Figur 12 betrifft ein viertes Anwendungsbeispiel der Erfindung, bei dem XML-Quellcode CodeML mit dem Codefragment CF, das die Fremdsprachenfragmente LFl und LF2 enthält, durch die Transformation T kombiniert wird, um einen modifizierten Code CodeML*, beispielsweise angepasst an die natürliche Sprache des Benutzers (Ll=german) , zu erhalten. Die Transformation XSLT wird hierbei von Transformationsregeln TR bestimmt, die die zu ändernden Stellen des Quellcodes sowie die jeweilige ausgewählte natürliche Sprache, also beispielsweise german oder english, spezifiziert. Durch das erfindungsgemäße Verfahren wird so eine Lokalisierung und Internationalisierung des Quellcodes auf effiziente und ökonomische Weise, bei einer Minimierung der hierfür erforderlichen zusätzlichen Laufzeit, erreicht.
Die oben genannten Ausprägungen des erfindungsgemäßen Verfahrens können einzeln und in beliebiger Reihenfolge nacheinander erfolgen.
Durch das erfindungsgemäße Verfahren ergeben sich eine Reihe von Vorteilen, wie beispielsweise:
1. Es können schnelle und flexible Änderungen im Quellcode vorgenommen werden. 2. Es ist nur ein System für Problemstellungen wie Patching, Customizing, Updating, etc. erforderlich und nicht eine Reihe verschiedener teilweise proprietärer Werkzeuge.
3. Das Verfahren basiert auf Standards wie XML und XSLT und ist hinsichtlich der Konvertierbarkeit in andere Programmiersprachen geringeren Beschränkungen unterworfen als andere Verfahren zur Modifikation von Quellcode.
4. Selbst für spezielle und komplizierte Quellcode- Modifikationen sind keine proprietären Speziallösungen erforderlich, sondern es können hierfür existierende Standards wie XSLT, XPath und XQuery genutzt werden.
5. Diese Art der Modifikation erlaubt die Erstellung von
Hierarchien u.a. durch die Möglichkeit zur geordneten, automatisierten Hintereinanderausführung (Pipelines) mehrerer Transformationen, bspw. von Patches.
7. Die Transformationen können für eine allgemeine
Wiederverwendung in XSLT-Dateien gespeichert werden, so daß Bibliotheken z.B. für bestimmte Abläufe entstehen können.
8. Es kann eine XML-Repräsentation des Quellcodes in einer XML-Datenbasis gespeichert und bei Bedarf mit Hilfe einer
XSTL in einfacher Weise an die jeweiligen Kundenbedürfnisse angepasst werden (Customization) .
9. Durch die Verwendung der Standards XMLSchema oder DTD oder entsprechende XSLTs kann der Code vorab (ohne Kompilierung) , auf bestimmte Korrektheitsaspekte hin, überprüft (validiert) werden.
10. Übliche XML-Tools können zur einfachen Bearbeitung bzw. Visualisierung und Bestimmung von Beziehungen im Code verwendet werden. 11. Dauerhafte XML-basierte Programmbibliotheken, die XPath- Anfragen unterstützen, können die Wiederverwendung von Code durch besseres Auffinden eines Codes bzw. von Code-Fragmenten oder Templates verbessert werden.
Anhang 1 :
Listing 1: TestRegistry. java
import electπc.registry. Registry; public class TestRegistry
{
. //weiterer Quellcode in dem etwas geändert werden muss }
Listing 2: TestRegistry.xjava
<?xml versιon="1.0" encodmg="UTF-8"?> <3ava>
<ιmport>
<dotXdotXname>electrιc</nameXname>regιstry</nameX/dotXname>Regιstry</name></dot> </ιmport> <class> <modιfιersXpublιc/X/modιfιers>
<name>TestRegιstry</name> <block>
<block> </class>
</]ava>
Listing 3 : VariationPointTl . s∑sl
<xsl:stylesheet versιon="l .0" xmlns:xsl="http: //www.w3.org/1999/XSL/Transform"> < i *********************************
*** copy template ** ii *ÜAii &****„■' *i J ***•*• J--1 ****ά*** ^5.
<xsl:template match-"J'"> <xsl : copyXxsl : apply-templates/X/xsl : copy>
</xsl : template>
*** Variotion Point Transformation 1 ** ***********************************************—> <xsl :template match="ιmport">
<xsl:ιf test="dot/name='Registry' "> <import> <dot>
<dotXdotXdotXname>org</nameXname>apache</nameX/dotXname>axιs</nameX/dot> <name>clιent</nameX/dot><name>Call</name>
</dot> </ιmport> <ιmρort>
<dot> <dotXdotXdotXname>org</nameXname>apache</nameX/dotXname>axιs</nameX/dot>
<name>clιent</nameX/dotXname>Serv ce</name> </dot> </ιmport> </xsl:if> <xsl:ιf test="dot/name'='Regιstry'">
<xsl:copy-of select="."/> </xsl:ιf>
</xsl : template> </xsl:stylesheet> Listing 4 : TestRegistry. java ( *)
<?xml version="1.0" enσoding="UTF-8"?> <j ava> <import> <dot>
<dotXdot><dot><name>org</nameXname>apache</nameX/dot><name>axis</nameX/dot> <name>client</name></dotXname>Call</name> </dot> </import> <import> <dot>
<dot><dotXdot><name>org</nameXname>apache</nameX/dot><name>axis</nameX/dot> <name>client</nameX/dotXname>Service</name> </dot> </import> <class>
<modifiersXpublic/X/modifiers> <name>TestRegistry</name> <block>
<block> </class> </java>
Listing 5: TestRegistry.java (*) import org. apache. axis .dient .Call; //Axis import org. apache. axis .client. Service; public class TestRegistry {
... //weiterer Quellcode in dem etwas geändert wurde }
Anhang 2
Listing 1: TestOutput.xjava
<?xml version="1.0" encoding="UTF-8"?> <j ava>
<define name=" " value="private"> <class>
< odifiers><m/x/modifiers> <name>Testθutput</name> <block> <var>
<type><name>String</name></type> <name>m_s elcome</name> </var> </block> </class> </java>
Listing 2: TestOutpu xjava *
<?xml version="1.0" encoding="UTF-8"?> <j ava> <class>
<modifiers><private/x/modifiers> <name>Testθutput</name> <block> <var> <type><name>String</name></type>
<name>m_sWelcome</na e> </var> </block> </class> </java>
Listing 3: TestOutputjava
private class Testoutput {
String m_sWelcome;
} Anhang 3
Listing 1: TestCalculator.java public class TestCalculator{ private int z; public void calculate (int x, int y) { z = x+y; }
Listing 2: TestCalcuIator.xjava <?xml version="1. 0" encoding="UTF-8" ?>
<j ava> <class>
<modifiersXpublic/X/modifiers> <name>TestCalculator</name> <block>
<var>
<modifiersXprivate/X/modifiers><typeXint/X/typeXname>z</name> </var> <method> <modifiers><public/X/modifiers>
<type><void/X/type> <name>calculate</name> <params>
<param><type><int/></type><name>x</name></param> <paramxtype><int/x/type><name>y</name></param>
</params> <curly> <expr> <a> <name>z</name>
<plusXname>x</nameXname>y</nameX/plus> </a> </expr> </curly> </method>
</block> </class> </java>
Listing 3: LoggingAspectxsI
<xsl : stylesheet version="l .0" xmlns :xsl="http: //www. 3. org/1999/XSL/Transform"> <j *********************************
*** copy template ** ********************************* >
<xsl: template match="*">
<xsl : copyXxsl : apply-templates/X/xsl : copy> </xsl : template>
< 1 * *** *** * ** ** *** ***** * ** ** *** * * * **
*** logging aspect ** <xsl: template matσh="*[ (name( ) ='curly' ) and (ancestor : rmethod [contains (name, 'cal' ) ] ) ] "> <xsl : copy> <expr> <paren> <dotXdotXname>System</nameXname>out</nameX/dotXname>println</nameX/dot> <exprs> <expr> <xsl:text>"</xsl:text><xsl:value-of select=".. /name"/Xχsl : text> begin"</xsl : text> </expr> </exprs> </paren> </expr>
<xsl:copy-of select="*" /> <expr> <paren> <dot><dotXname>System</nameXname>out</nameX/dot><name>println</nameX/dot> <exprs> <expr>
<xsl :text>"</xsl : textXxsl :value-of select=" .. /name"/Xxsl : text> end"</xsl : text> </expr> </exprs> </paren> </expr> </xsl : copy> </xsl : template> </xsl : stylesheet>
Listing 4: TestCaIculator*.xjava
<?xml version="1.0" encoding="UTF-8" ?> <j ava>
<class>
<modifiersXpublic/X/modifiers> <name>TestCalculator</name> <block> <var>
<modifiersXprivate/X/modifierΞ><typeXint/X/type><name>z</name> </var> <method>
<modifiersXpublic/X/modifiers> <typeXvoid/x/type>
<name>calculate</name> <params>
<paramXtypeXint/X/type><name>x</nameX/param> <paramXtypeXint/X/typeXname>y</nameX/param> </params>
<curly> <paren>
<dot><dot><name>System</name><na ne>out</name></dot><naιne>println</name></dot> <e3φrs e3φ >" calculata begin"</axprX/exprs>
</paren> </expr> <expr> <a> <name>z</name>
<plusXname>x</name><name>y</nameX/plus> </a> </expr> <expr> <paren>
<dotx:dotXname>System</nameXname>out</nameX/dotXname>println</naπιeX/dot> <exprsXexpr>" calculate end"</exprX/exprs> </paren> </expr> </curly>
</method> </block> </class> </ ava>
Listing 5: TestCalculator*.java public class TestCalculator' private int z; public void calculate (int x, int y) ■ System. out. println ("calculate begin") ; z = x+y;
System. out. println ("calculate end") ;
Anhang 4
Listing 1: TestOutput. java
public class Testoutput {
String m_sWelcome;
}
Listing 2: TestOutputxjava
<?xml version="1.0" encoding="UTF-8"?> <java> <class> <modifiersXpublic/x/modifiers> <name>Testθutput</name> <block> <var>
<typeXname>String</nameX/type> <name>m_sWelcome</name>
</var> </block> </class> </java>
Listing 3: State. ml
<?xml version="1.0" encoding="UTF-8"?> <state name="m_s elcome"> <value>"hello"</value> </state>
Listing 4: Mixing.xsl
<xsl: stylesheet version="1.0" xmlns :xsl="http: //www. 3.org/1999/XSL/Transform">
< j *********************************
*** copy template ** *********************************—>
<xsl: template match="*">
<xsl : copyXxsl : apply-templates/X/xsl : copy> </xsl : template> <; ********************************* *** mixing template **
*********************************—>
<xsl: emplate match="*[ (name ()=' var ' ) and (name='m_sWelcome ' ) ] "> <xsl :copy> <xsl:copy-of select="*"/> <a>
<expr><xsl:value-of select="//state [@name='m_s elcome' ] /value" /></expr> </a> </xsl:copy> </xsl : template> </xsl : stylesheet>
Listing 5: TestOutput. xjava (*)
<?xml version="1.0" encoding="UTF-8"?> <java> <class>
<modifiers><public/x/modifiers> <name>Testθutput</name> <block> <var>
<typeXname>String</name></type> <name>m_s elcome</narae> <a> <expr>"hello"</expr>
</__> </var> </block> </class> </java>
Listing 6: TestOutput. java (*)
public class Testoutput {
String m_sWelcome="hello" ;
}
Anhang 5
Listing 1A: TestOutputjava
public class TestOutput {
String m_s elcome=" ello" ;
}
Listing 2A: TestOutputxjava
<?xml version="1.0" encoding="UTF-8"?> <j ava> <class> <modifiersXpublic/x/modifiers> <name>Testθutput</name> <block> <var>
<typeXname>String</name></type> <name>m_sWelcome</name>
<a>
<expr>"hello"</expr> </a> </var> </block> </class> </java>
Listing 3A: CodeFragment . xml
<?xml version="1.0" encoding="UTF-8"?> <fragment name="m_sWelcome"> <expr> <paren> <dot><name>System</name><name>getProperty</nameX/dot> <exprs><expr>" ELC0ME"</exprX/exprs> </paren> </expr> </fragment>
Listing 4A: Patching. sl
<xsl: stylesheet version="1.0" xmlns :xsl="http: //www.w3.org/1999/XSL/Transform">
< j *********************************
*** copy template ** ********************************* >
<xsl: template match="*"> <xsl : copyXxsl : apply-templates/x/xsl : copy>
</xsl : template>
< ι *********************************
*** patching template *"*
********************************* — > <xsl : template match="* [ (name ( ) = ' a ' ) and ( ancestor : : var/name= ' m_sWelcome ' ) ] "> <xsl : copy>
<xsl:copy-of select="//fragment[@name='m_sWelcome' ] /expr" /> </xsl:copy> </xsl : template> </xsl:stylesheet>
Listing 5A: TestOutput. xjava (*)
<?xml version="1.0" encoding="UTF-8"?> < j ava>
<class>
<modifiers><public/X/modifiers> <name >Te s tθutput< /name> <block> <var>
<type><name>String</nameX/type>
<name>m_s elcome</name>
<a>
<expr> <paren>
<dot><name>System</name><name>getProperty</nameX/dot> <exprsxexpr>" ELC0 E"</expr></exprs> </paren> </expr> </a>
</var> </block> </class> </java>
Listing 6A: TestOutput . java (*)
public class Testoutput
{ String m_sWelcome=System.getPropert (" ELCOME"
}

Claims

Patentansprüche
1. Verfahren zur Veränderung von Software, - bei dem vorab herstellerseitig aus einer nur aus Quelltext (SCI, SC2, SC) bestehenden ursprünglichen Software eine Mischform der ursprünglichen Software derart gebildet wird, dass mindestens ein Teil (SCI) des Quelltexts in einen Byteoder Binärcode (B1,..,B) compiliert und mindestens ein weiterer Teil (SC2) des Quelltexts in einen in einer Meta- Auszeichnungssprache formulierten Code (CodeML) für mindestens einen Variationspunkt (VP2, ..VP) konvertiert wird,
- bei dem dann kundenseitig nach Bedarf nur mindestens ein Variationspunkt (VP2) der Mischform (SW) der ursprünglichen Software durch eine Transformation (T) in Abhängigkeit von Transformationsregeln (TR) in mindestens einen in der Meta- Auszeichnungssprache formulierten anderen Code (CodeML*) umgewandelt wird und
- bei dem der andere Code (CodeML*) direkt einen veränderten Variationspunkt (VP2*) einer angepassten Software (SW*) bildet oder aus dem anderen Code (CodeML*) durch einen Konverter (RCONV) ein Quellcode (SC*) und dann mittels eines Kompilers (COMP) ein Binär- oder ByteCode (B*) des veränderten Variationspunkts (VPB2) einer angepassten Software (SW*) gebildet wird, wobei sich die ursprüngliche (SW) und die angepasste Software (SW*) in ihrem Programmablauf bzw. Programminhalt unterscheiden.
2. Verfahren nach Anspruch 1, bei dem die Transformationsregeln (TR) mindestens eine Modifikationsregel für einen Variationspunkt aufweisen.
3. Verfahren nach Anspruch 1 oder 2, bei dem der Modifikationsregel ein Update auf eine neuere Softwareversion bzw. ein Patching anstößt.
4. Verfahren nach Anspruch 1 oder 2, bei dem die Modifikation mindestens eines Variationspunktes (VP) durch die Transformation zur Laufzeit erfolgt.
5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Programmiersprache des Quellcodes Java und die Meta-Auszeichnungssprache der Variationspunkte XML ist und bei dem die Transformation und die Regelbeschreibung mittels XSLT und XSL erfolgt.
6. Verfahren zur Veränderung von Quellcode, - bei dem ein in einer Meta-Auszeichnungsprache formulierter erster Code (CodeML) mit mindestens in einer Meta- Auszeichnungssprache formulierten Spracherweiterungen (LE) als Ausgangscode zur Verfügung steht,
- bei dem der Ausgangscode durch eine Transformation (T) in Abhängigkeit von Transformationsregeln (TR) in einen in der
Meta-Auszeichnungssprache formulierter zweiten Code (CodeML*) ohne die in der Meta-Auszeichnungssprache formulierten Spracherweiterungen (LE) überführt wird,
- bei dem die Transformationsregeln einen Sprachkonverter (LC) bilden, der die Spracherweiterungen (LE) des ersten
Codes so auflöst bzw. anwendet, dass sie durch einen Rückkonverter (RCONV) der keine entsprechende Spracherweiterung aufweist verarbeitbar sind, und
- bei dem dieser zweite Code in einen in der ersten Programmiersprache oder einer anderen Programmiersprache formulierten zweiten Quellcode (SC*) umwandelbar ist, und einen gültigen Binärcode/ByteCode (B*) ergibt.
7. Verfahren nach Anspruch 6, bei dem im zweiten Code (CodeML*) mindestens eine Spracherweiterung (LE*) neu erzeugt oder aus dem ersten Code (CodeML) übernommen wird, und diese Erzeugung oder Übernahme der Sprachkonverter (LC) vornimmt.
8. Verfahren zur Veränderung von Quellcode,
- bei dem ein in einer ersten Programmiersprache formulierter Quellcode (SC) in einen in einer Meta-Auszeichnungssprache formulierten ersten Code (CodeML) umgewandelt wird,
- bei dem eine Transformation (T) nur in Abhängigkeit von Transformationsregeln TR in einen in der Meta- Auszeichnungssprache formulierten zweiten Code (CodeML*) erfolgt und - bei dem dieser zweite Code in einen in der ersten
Programmiersprache oder einer anderen Programmiersprache formulierten zweiten Quellcode (SC*) verwandelt wird, wobei sich der erste und der zweite Quellcode in ihrer Funktionalität (B,B*) unterscheiden.
9. Verfahren nach Anspruch 8, bei dem die Transformationsregeln (TR) mindestens eine Bedingung C und einen Logikbestandteil L und/oder Codefragment CF selbst enthalten.
10. Verfahren nach Anspruch 8 oder 9, bei dem die Transformationsregeln (TR) mindestens ein Fragment in Form eines Templates (TPF) und/oder mindestens eines Patterns (PF) entalten, bei denen mit Hilfe der Transformation T mindestens eine Codeveränderung bewirkt.
11. Verfahren nach Anspruch 10, bei dem TR derart ausgebildet ist, dass mit Hilfe der Transformationen T ein Mechanismus zur Sicherung mindestens eines Systemzustandes in den zweiten Quellcode (CodeML*) eingebracht wird, um eine Migration in andere Versionen zu ermöglichen.
12. Verfahren nach Anspruch 8 oder 9, bei dem mit Hilfe der Transformation T aus dem ersten Code oder einem Fragment des ersten Codes mindestens ein Template (TP) gebildet wird.
13. Verfahren zur Veränderung von Quellcode,
- bei dem ein in einer ersten Programmiersprache formulierter Quellcode (SC) in einen in einer Meta-Auszeichnungssprache formulierten ersten Code (CodeML) umgewandelt wird,
- bei dem eine in der Meta-Auszeichnungssprache formulierte, den späteren Programmablauf (B*) beeinflussende Information (INFO) durch eine Transformation (T) zu diesem ersten Code ersetzend oder nichtersetzend hinzugefügt und so der ebenfalls in der Meta-Auszeichnungssprache formulierte zweiten Code (CodeML*) gebildet wird, wobei die Transformation in Abhängigkeit von in einer Transforrαationsbeschreibungsspräche formulierten Transformationsregeln (TR) erfolgt, und - bei dem dieser zweite Code in einen in der ersten
Programmiersprache oder einer anderen Programmiersprache formulierten zweiten Quellcode (SC*) verwandelt wird, wobei sich der Programminhalt bzw. Programmablauf (B) des ersten Quellcodes (SC) vom Programminhalt bzw. Programmablauf (B*) des zweiten Quellcodes (SC*) unterscheidet.
14. Verfahren nach Anspruch 13, bei dem diese Information (INFO) mindestens ein Code-Fragment
(CFb) enthält und bei dem der zweite Quellcode dadurch gebildet wird, dass mindestens ein im ersten Quellcode enthaltenes Code-Fragment
(CFa) mit Hilfe der Transformation durch das mindestens eine im Fragment enthaltene Code-Fragment (CFb) ersetzt wird.
15. Verfahren nach Anspruch 13, bei dem die Information (INFO) speziell Daten (D) in Form von Initialisierungszuständen (SSDb) oder Zustandsdaten (SDa) oder Datenbankdaten (De) enthalten.
16. Verfahren nach Anspruch 15, bei die Transformationsregeln (TR) von diesen Daten (D) beeinflusst werden.
17. Verfahren nach einem der Ansprüche 13 bis 16, bei dem Daten (D) und/oder Code-Fragmente (CF) zusätzlich in den Transformationsregeln eingebettet sind.
18. Verfahren nach einem der Ansprüche 13 bis 17, bei dem von Checkpoints generierte Daten mittels einer Transformation so hinzugefügt werden, das der interne Zustand des ursprünglichen Programms beim Neustart des Programms zur Verfügung steht bzw. von diesem genutzt werden kann.
19. Verfahren nach einem der Ansprüche 13 bis 17, bei dem Informationen (INFO) Updates oder Patches enthalten.
20. Verfahren nach Anspruch 13 bis 17, bei dem Fragmente (LFl, LF2) Informationen zur Internationalisierung enthalten, die der Anpassung an unterschiedliche natürliche Sprachen dienen.
21. Verfahren nach einem der Ansprüche 13 bis 17, bei dem Daten und/oder Code-Fragmente aus einer Bibliothek entstammen und auf Kunden oder Kundengruppen abgestimmte Informationen tragen.
22. Anordnung zur Veränderung von Software,
- bei der eine Mischform einer ursprünglichen Software derart vorhanden ist, dass mindestens ein Teil (SCI) eines
Quelltexts in einen Byte- oder Binärcode (B1,..,B) compiliert und mindestens ein weiterer Teil (SC2) des Quelltexts in einen in einer Meta-Auszeichnungssprache formulierten Code (CodeML) für mindestens einen Variationspunkt (VP2, ..VP) konvertiert ist,
- bei der eine Einrichtung zur Transformation (T) derart vorhanden ist, dass nach Bedarf nur mindestens ein
Variationspunkt (VP2) der Mischform (SW) der ursprünglichen Software durch die Transformation (T) in Abhängigkeit von Transformationsregeln (TR) in mindestens einen in der Meta- Auszeichnungssprache formulierten anderen Code (CodeML*) umwandelbar ist, wobei der andere Code (CodeML*) direkt einen veränderten Variationspunkt (VP2*) einer angepassten Software (SW*) bildet oder aus dem anderen Code (CodeML*) durch einen Konverter (RCONV) ein Quellcode (SC*) und dann mittels eines Compilers (COMP) ein Binär- oder ByteCode (B*) des veränderten Variationspunkts (VPB2) einer angepassten Software (SW*) bildbar ist und wobei sich die ursprüngliche (SW) und die angepasste Software (SW*) in ihrem Programmablauf bzw. Programminhalt unterscheiden.
23. Anordnung zur Veränderung von Quellcode,
- bei der ein Prozessor derart vorhanden ist, dass eine Transformation (T) des Ausgangscodes (CodeML) in Abhängigkeit von in einer erweiterten Stilbeschreibungssprache formulierten Transformationsregeln (TR) und einen darin enthaltenen Sprachkonverter (LC) so durchgeführt wird, dass entweder ein in der Meta-Auszeichnungssprache formulierter zweiter Code (CodeML*) ohne die in der Meta- Auszeichnungssprache formulierten Spracherweiterungen (LE) des ersten Codes (CodeML) , oder ein in der Meta-Auszeichnungssprache formulierter zweiter Code (CodeML*) mit neuen und/oder den ursprünglichen in der Meta-Auszeichnungssprache formulierten Spracherweiterungen (LE) erzeugt wird, und
- bei der ein Rückkonverter (RCONV) derart vorhanden ist, dass dieser zweite Code in einen in der ersten Programmiersprache oder einer anderen Programmiersprache formulierten Quellcode (SC*) verwandelt wird.
24. Anordnung zur Veränderung von Quellcode,
- bei der ein erster Konverter (CONV) derart vorhanden ist, dass ein in einer ersten Programmiersprache formulierter Quellcode (SC) in einen in einer Meta-Auszeichnungssprache formulierten ersten Code (CodeML) umgewandelt wird, - bei der ein Prozessor derart vorhanden ist, dass der CodeML durch eine Transformation (T) nur in Abhängigkeit von Transformationsregeln (TR) in einen in der Meta- Auszeichnungssprache formulierten zweiten Code (CodeML*) umgewandelt wird und - bei der ein zweiter Konverter (RCONV) derart vorhanden ist, dass dieser zweite Code in einen in der ersten Programmiersprache oder einer anderen Programmiersprache formulierten zweiten Quellcode (CodeML*) verwandelt wird, wobei sich der erste und der zweite Quellcode in ihrer Funktionalität bzw. Inhalt (B,B*) unterscheiden.
25. Anordnung zur Veränderung von Quellcode,
- bei der ein erster Konverter (CONV) derart vorhanden ist, dass ein in einer ersten Programmiersprache formulierter
Quellcode (SC) in einen in einer Meta-Auszeichnungssprache formulierten ersten Code (CodeML) umgewandelt wird,
- bei der ein Prozessor derart vorhanden ist, dass eine in der Meta-Auszeichnungssprache formulierte, den späteren Programmablauf (B*) beeinflussende Information (INFO) durch eine Transformation (T) zu diesem ersten Code ersetzend oder nichtersetzend hinzugefügt und so der ebenfalls in der Meta- Auszeichnungssprache formulierte zweiten Code (CodeML*) gebildet wird, wobei die Transformation in Abhängigkeit von in einer Transformationsbeschreibungssprache formulierten Transformationsregeln (TR) erfolgt, und - bei der ein zweiter Konverter (RCONV) derart vorhanden ist, dass dieser zweite Code in einen in der ersten Programmiersprache oder einer anderen Programmiersprache formulierten zweiten Quellcode (SC*) verwandelt wird, wobei sich der Programminhalt bzw. Programmablauf (B) des ersten Quellcodes (SC) vom Programminhalt bzw. Programmablauf (B*) des zweiten Quellcodes (SC*) unterscheidet.
EP04739074A 2003-04-01 2004-03-29 Verfahren und anordnung zur veränderung von software oder quellcode Withdrawn EP1609061A2 (de)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
DE10314832A DE10314832B3 (de) 2003-04-01 2003-04-01 Verfahren und Anordnung zur kundenseitigen Anpassung von Software
DE10314834 2003-04-01
DE10314835A DE10314835A1 (de) 2003-04-01 2003-04-01 Verfahren und Anordnung zur Erzeugung und Verarbeitung eines Quellcodes mit Spracherweiterungen
DE10314831 2003-04-01
DE10314835 2003-04-01
DE10314831A DE10314831A1 (de) 2003-04-01 2003-04-01 Verfahren und Anordnung zur Transformation von Quellcode
DE10314832 2003-04-01
DE10314834A DE10314834A1 (de) 2003-04-01 2003-04-01 Verfahren Anordnung zur Modifikation von Quellcode unter Einbeziehung zusätzlicher Informationen
PCT/EP2004/003301 WO2004088549A2 (de) 2003-04-01 2004-03-29 Verfahren und anordnung zur veränderung von software oder quellcode

Publications (1)

Publication Number Publication Date
EP1609061A2 true EP1609061A2 (de) 2005-12-28

Family

ID=33136033

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04739074A Withdrawn EP1609061A2 (de) 2003-04-01 2004-03-29 Verfahren und anordnung zur veränderung von software oder quellcode

Country Status (3)

Country Link
US (1) US8473937B2 (de)
EP (1) EP1609061A2 (de)
WO (1) WO2004088549A2 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7650196B2 (en) * 2005-09-30 2010-01-19 Rockwell Automation Technologies, Inc. Production monitoring and control system having organizational structure-based presentation layer
US20070240040A1 (en) * 2006-04-05 2007-10-11 Christopher Peters Non-compiled portable algorithm
US8079027B2 (en) * 2006-09-08 2011-12-13 Via Technologies, Inc. Programming language translation systems and methods
JP5664237B2 (ja) * 2008-05-13 2015-02-04 日本電気株式会社 Ｘｍｌ処理装置、ｘｍｌ処理方法およびｘｍｌ処理プログラム
CN101650648A (zh) * 2008-08-14 2010-02-17 鸿富锦精密工业（深圳）有限公司 动态调用功能模块的系统及方法
US8984165B2 (en) * 2008-10-08 2015-03-17 Red Hat, Inc. Data transformation
US9965453B2 (en) * 2009-10-15 2018-05-08 Microsoft Technology Licensing, Llc Document transformation
US9223570B2 (en) * 2013-03-14 2015-12-29 Red Hat, Inc. Migration assistance using compiler metadata
CN112306497B (zh) * 2020-11-03 2024-04-26 高炼 一种将自然语言转化为程序代码的方法及系统

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6052531A (en) * 1998-03-25 2000-04-18 Symantec Corporation Multi-tiered incremental software updating
US6981212B1 (en) * 1999-09-30 2005-12-27 International Business Machines Corporation Extensible markup language (XML) server pages having custom document object model (DOM) tags
US7188332B2 (en) * 1999-10-05 2007-03-06 Borland Software Corporation Methods and systems for relating a data definition file and a data model for distributed computing
DE10121790B4 (de) * 2000-06-03 2006-11-23 International Business Machines Corp. Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem
US7000230B1 (en) * 2000-06-21 2006-02-14 Microsoft Corporation Network-based software extensions
US7219332B2 (en) * 2000-07-07 2007-05-15 Microsoft Corporation Configuring software components(merge) with transformation component using configurable and non-configurable data elements
US20020057837A1 (en) * 2000-08-14 2002-05-16 Tim Wilkinson Portable operating environment for information devices
US7739308B2 (en) * 2000-09-08 2010-06-15 Oracle International Corporation Techniques for automatically provisioning a database over a wide area network
JP2002182915A (ja) * 2000-12-19 2002-06-28 Tokio Marine & Fire Insurance Co Ltd ソース・プログラム保管方法及びシステム、ソース・プログラム復元方法及びシステム、並びにコンパイル方法及び装置
US20020143816A1 (en) * 2001-03-06 2002-10-03 Geiger Michael P. Method and system for using a generalized execution engine to transform a document written in a markup-based declarative template language into specified output formats
US7310653B2 (en) * 2001-04-02 2007-12-18 Siebel Systems, Inc. Method, system, and product for maintaining software objects during database upgrade
US7703009B2 (en) * 2001-04-09 2010-04-20 Huang Evan S Extensible stylesheet designs using meta-tag information
US20040015890A1 (en) * 2001-05-11 2004-01-22 Windriver Systems, Inc. System and method for adapting files for backward compatibility
US20040015832A1 (en) * 2001-05-25 2004-01-22 Michael Stapp Method and apparatus for generating source code
AU2003238815A1 (en) * 2002-05-29 2003-12-19 Globespan Virata Incorporated Method and system for providing a command-line interface syntax from an xml specification
US7721202B2 (en) * 2002-08-16 2010-05-18 Open Invention Network, Llc XML streaming transformer
US7069504B2 (en) * 2002-09-19 2006-06-27 International Business Machines Corporation Conversion processing for XML to XML document transformation
CA2409079A1 (en) * 2002-10-21 2004-04-21 Ibm Canada Limited-Ibm Canada Limitee Creating multiple and cascading business interpretations from raw application data using transformation layering
US7346897B2 (en) * 2002-11-20 2008-03-18 Purenative Software Corporation System for translating programming languages

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2004088549A2 *

Also Published As

Publication number Publication date
US8473937B2 (en) 2013-06-25
WO2004088549A2 (de) 2004-10-14
WO2004088549A3 (de) 2005-02-24
US20090210864A1 (en) 2009-08-20

Similar Documents

Publication Publication Date Title
EP1723513B1 (de) Verfahren zur konfiguration eines computerprogramms
DE69516891T2 (de) Verfahren zum übersetzen von quellkode aus einer computer-hochsprache in eine andere
WO2010040597A2 (de) Verfahren und vorrichtung zum austauschen einer komponente eines computersystems
EP0432802A2 (de) Verfahren für die automatische Syntaxanalyse (Parsen) des Textes von Computer-Programmen in Kompilierern
WO2015185328A1 (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
EP1904923A1 (de) Verfahren und softwaresystem zur konfiguration eines modularen systems
EP1609061A2 (de) Verfahren und anordnung zur veränderung von software oder quellcode
DE102004009676A1 (de) Verfahren und Systeme zum Erzeugen von Unterstützungsdateien für Befehle
DE10041072A1 (de) Verfahren zur automatischen Erzeugung von Programmcode
DE10357831A1 (de) System und Verfahren zum Reengineering von Objektmodell-Komponenten zur Generierung von Web-Services
DE10314832B3 (de) Verfahren und Anordnung zur kundenseitigen Anpassung von Software
DE10314831A1 (de) Verfahren und Anordnung zur Transformation von Quellcode
EP1668494B1 (de) Verfahren und system zur sprachkonfigurierung eines computerprogramms
EP1343078B1 (de) System zur Modellierung und Generierung von Softwaregenerierungssystemen
DE102020118832B3 (de) Verfahren zum Bereitstellen sicherheitsrelevanter Daten mittels eines Serversystems, Serversystem und Computerprogrammprodukt
DE10314835A1 (de) Verfahren und Anordnung zur Erzeugung und Verarbeitung eines Quellcodes mit Spracherweiterungen
DE19924610B4 (de) Setup-Verfahren
DE102004022183B4 (de) Verfahren zum Ändern von Programmobjektcode bei Quelltextänderungen
DE10300541A1 (de) Erzeugen einer ausführbaren Datei
DE10314834A1 (de) Verfahren Anordnung zur Modifikation von Quellcode unter Einbeziehung zusätzlicher Informationen
EP0560342B1 (de) Verfahren zum Untersuchen des Ablaufs eines in einer Hardware-Beschreibungssprache geschriebenen Programms
EP3079148A1 (de) Verfahren zum bereitstellen von anzeigedaten als klartext in mehreren sprachen und schriftsystemen mittels einer anzeigeeinrichtung eines haushaltsgerätes
DE19617719C2 (de) Verfahren zur Programmübersetzung eines in der Programmiersprache C++ geschriebenen Programms
EP2175331A1 (de) Steuerbares Gerät mit einem Steuerprogramm und Verfahren zum Steuern des Geräts
DE102004039200A1 (de) Versionskontrolle

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050909

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

RIN1 Information on inventor provided before grant (corrected)

Inventor name: REICHEL, CHRISTIAN

Inventor name: OBERHAUSER, ROY

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

17Q First examination report despatched

Effective date: 20100629

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20161001