WO2015185328A1 - 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 - Google Patents

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 Download PDF

Info

Publication number
WO2015185328A1
WO2015185328A1 PCT/EP2015/060259 EP2015060259W WO2015185328A1 WO 2015185328 A1 WO2015185328 A1 WO 2015185328A1 EP 2015060259 W EP2015060259 W EP 2015060259W WO 2015185328 A1 WO2015185328 A1 WO 2015185328A1
Authority
WO
WIPO (PCT)
Prior art keywords
template
installation
parameters
software
configuration
Prior art date
Application number
PCT/EP2015/060259
Other languages
English (en)
French (fr)
Inventor
Oliver RODE
Original Assignee
Rode Oliver
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 Rode Oliver filed Critical Rode Oliver
Publication of WO2015185328A1 publication Critical patent/WO2015185328A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming

Definitions

  • the invention relates to a computer-implemented method, a data carrier with data stored thereon or a data sequence suitable for the transmission via a data network, and a computer system for reusing executable software configurations for software systems in the process of developing new applications for computer systems or computer-aided systems, and a computer program with program code which performs the method steps when the computer program is executed on a computer or a computer network.
  • Building block-oriented software development can only be used if certain basic conditions are met, ensuring that all relevant settings for the implementation can be changed locally, without affecting the interfaces of the building blocks.
  • the reuse of building blocks requires the development process for a new application does not always be committed from scratch, but can leverage pre-engineered, validated and verified components to develop applications with less effort. Reusability is considered a property that can not be subsequently added to a component.
  • DE 698 38 139 T2 describes a method and system for creating database application software that requires minimal programming. It introduces a method for automatically creating complex software applications without in-depth traditional and detailed programming.
  • the target software is generated from a reusable universal software application from a suitably refined software description.
  • DE 690 31 078 T2 describes a computer-aided software development device, in which among other things an attention is paid to reusability.
  • the aspect of reusability is realized through the use of a higher standard language, in which the logic of a program can be defined in a highly modular form and thus promotes reusability.
  • the automated creation of the source code makes use of the reusable elements.
  • a common disadvantage of the prior art is that user-developed applications (software configurations) of the standard software can not be adequately considered as reusable components for the development of new applications because insufficient access to the entity model via API (Application Programming Interface) is offered.
  • API Application Programming Interface
  • the means for creating proprietary software libraries using the visual programming environment of this standard software is so limited that no or at least no sufficient set of components (templates) can be created for such proprietary libraries that allow for more complex, modular programming.
  • templates A sufficient amount of templates in the library enables rapid application development. Because a logical dependence of Subconfigurations of their templates, this can be used to implement continuous integration by automatically rebuilding subconfigurations when your templates have been reworked.
  • a computer system is to be made available, which is set up so that even with standard software reusable components can be used in the development of new applications.
  • a computer program with program code which performs the method steps when the computer program is executed on a computer or a computer network.
  • the program code can either be stored on a data medium containing the method as a machine-executable program or in one Computer network such.
  • the Internet may be made available to client-server systems that operate using the program.
  • a software system in this case represents a system of software components that are in communication with each other and can communicate with each other.
  • the interaction of software components of a software system enables the interaction of parts of a computer system consisting of hardware and software.
  • a software system consists, for example, of main and subroutines as well as configuration files and a sequence control which executes the software configuration.
  • a software configuration is a data model consisting of entities and their relationships, which describes how software is adapted to existing hardware and software, how it responds to events or otherwise behaves. In order to use a software under a certain system configuration, it must be set up accordingly.
  • a template library is created containing reusable templates of the configurations of standard applications of a software system. The templates are used to create software components that are assembled into new software configurations.
  • the templates must be created.
  • the software system must have at least one option for exporting subconfigurations.
  • a software configuration is created and a partial configuration by the user, i. H . selected a submodel of the configuration that, in his view, is suitable for duplication as a template and is exportable. This configuration part is then exported as a partial configuration to a new template within the template library.
  • each part of an application to be reused will then create at least one submodel of a configuration of that application that is suitable for reuse in another application.
  • the exported submodel may have dependencies ("interfaces") to other submodels of the configuration, and these templates can then be reused for a variety of applications if the elements and references contained in the template can be adapted to suit the new environment and attribute values of the entities are identified, parameterized, and instantiated.
  • the names and attribute values of the entities are found by an assembly automaton and suitably adapted to the new environment.
  • the assembly machine uses search rules to search for the names and attribute values of the entities which have been identified for it and replaces them with the aid of suitable substitution rules.
  • the instanable sub-configuration is thus instantiated by the assembly automaton to a partial configuration operable in the new application.
  • the visual programming environment of the software system must first be adapted such that the names of the entities, including their namespaces, as well as the properties by which the values of the attributes are meant, are determined via the graphical user interface (GU I ) can be parameterized.
  • GUI graphical user interface
  • Parameterization in the form of the insertion of parameters and functions, takes place in the visual programming environment via single- and multi-cell text input fields.
  • a formal language must be defined, which encodes the parameter and function names.
  • the existing input fields must then be changed so that they allow the input of parameters and functions in the text.
  • validation checks for the validity of the values must be disabled if parameterized entries are recognized using the formal language defined for them.
  • Other existing input types eg.
  • radio buttons and data types of the attribute values should be adapted to also allow parameterized inputs, e.g. For example, either by conversion to text input fields or by adding an option that allows the specification of a parameter.
  • the visual representation of the parameters and functions in the text input fields can be improved by highlighting.
  • Entities that have been parameterized or contain parameterized entities are abstract, and configurations in which they are contained can generally not be executed properly until the parameter values are assigned and the function values are determined.
  • the software system should therefore be adapted to inhibit the execution of configuration parts with entities that are abstract and also visually highlight this "abstract" state.
  • the assembly automaton thus interprets the signature of the function as a reference to a resource or an entity at a location of this type Content is imported during instantiation.
  • the assembly machine thus generates the content of the referenced file in the new partial configuration, so that even more complex adjustments can be carried out flexibly.
  • the signature of a function is set up so that it has at least one function parameter that is interpreted by the assembly automaton as a reference to a resource or entity.
  • entity values or entities that have exactly one entity value as "content” may also be truncated over the GU I as “abstract” or “overwritable”; H. be marked.
  • the function parameter name for the transclusion which would reference the file with the value for the content and otherwise specify, is then not arbitrary, but is explicitly specified by the software system and the assembly machine.
  • An abstract entity value is assigned the signature for the transclusion function and must be overridden.
  • overwrite entity value must be assigned a valid value for which a replacement rule is implicitly generated if a reference is assigned to the function parameter name.
  • overwritable Entity values are useful for Generic Programming when the template uses a generalized type that is used in the template in subroutines to use specialized types in derived building blocks.
  • data can be exchanged via XML, or even the interface itself can be defined using a description language based on the schema language, such. Eg WSDL.
  • the parameterization can thus be achieved so that all language elements such as XSD, XML and WSDL in the blocks can be set individually and matched.
  • the abstract functionality of a template has to cope with the parameterizations of the building blocks derived from it, which requires a semantics to be planned by the developer of the template.
  • the problem that a generic treatment limits are set and, if necessary, must be specific block specific, similar to the usual object orientation by delegation to a block-specific implementation of a subroutine, eg. XQuery or software library.
  • the material value of the template depends on the amount of functionality that can be implemented independently of the derivative.
  • each submodel is exported as part of a customizable template and saved to the template library
  • the templates can now be reused by other applications that need to be rebuilt.
  • an assembly machine is used in the creation of the new application, which uses the templates to be used according to the invention, copied out of the application library, the configurable strings of the templates parameterized and instantiated by instance variables to a functional component in the new application.
  • the instantiated components are then automatically assembled by the assembly automaton and usually supplemented with further application code. This creates a new and executable software configuration and application.
  • the invention is implemented by the manufacturer, he must also implement the assembly machine and make it available to the user as a tool.
  • An advantageous embodiment of the invention uses a formal language for encoding the names and attribute values of the entities, in which the use of the instance parameters and functions remains transparent. This is especially important if the reuse of a subconfiguration is not successful the manufacturer of the standard application underlying a template.
  • an unusual string of delimiter strings is to be selected from the alphabet as the word of the formal language. This can be determined by consideration or experimentally by exclusion. This creates strings that can be uniquely identified from the rest of the template contents, but are also interpreted as valid strings in the visual programming environment and are therefore easily processed. For example, if XXX is set as the delimiter string, the template name parameter can be written as XXX template nameXXX without the software (software system) being aware of the semantics of this modeling. A function call "Import (ReferenzA)" could analogously z. Eg as "XXXImportYYYReferenceAXXX".
  • Functions are modeled in such a way that their signature is designed as an n-tuple. At least one unique delimiter string delimits the function call from all other string sequences. As a result, the assembly machine can safely recognize that a function is called at this point. Within the function call, the function name and the parameters belonging to the function are named. In order for these to be recognized and assigned accordingly, they are clearly delimited from each other by at least one further subordinate string sequence.
  • function parameters of the function call can be instance parameters. This means that the parameters used in the called function can also be instantiated and thus occupied by the assembly automaton during the instantiation according to corresponding rules.
  • An inventive method for the production and use of a stencil can be done according to claim 3.
  • the following describes the path for the non-manufacturer user. If a manufacturer of the software system implements this advantageous embodiment of the invention, he can do so to make the process more transparent for users. The following can be said about the individual resources:
  • the assembly automaton needs a complete assignment of all instance parameters used in the template to a value for the instantiation. If a default exists in the template, this step may be omitted later for these instance parameters. Presets are used if the value is not explicitly specified for the block later (Fig. 1). It is best to have a full assignment for all instance parameters with commentary on the documentation; this also supports the software design paradigm "convention before configuration".
  • a useful file format for this is z. For example, a Java properties file.
  • the template has dependencies on entities outside its subconfiguration, it may no longer be able to load itself into the visual programming environment for itself if the visual programming environment detects inconsistencies. In this case, further development of the template requires the creation of a minimal, complementary sub-configuration that, together with the sub-configuration of the template, provides a valid configuration.
  • the assembly machine integrates these scripts as subroutines into the installation and uninstallation programs of the configuration in a run-time environment by placing them in the packaging next to the installer.
  • these installation scripts are executed by the installer iteratively, within a transaction.
  • An advantageous embodiment of the method makes it possible to adapt such strings or resources for reusability of the software, which are not parameterized in the underlying configuration of the standard application.
  • Such strings or resources are made parameterizable by defining manipulations in the templates for the non-parametrizable strings or resources in the form of instructions for executing search and replace rules by a text and / or binary stream editor. These instructions ensure that during the copying process by the assembly machine within the subconfiguration on the template internal files and / or parts found in it and replaced appropriately. For this purpose, new files or file contents are assigned to these files or parts of the files.
  • the search and replace rules used here contain regular expressions.
  • the regular expressions also contain the name of the instance parameter, which contains the reference to the file that replaces the searched content.
  • the files are based on a formal language, e.g. For example, a script based on the instruction set of the U nix tool "sed" (Stream EDitor). These files can be parameterized.
  • a formal language e.g. For example, a script based on the instruction set of the U nix tool "sed" (Stream EDitor).
  • installation scripts and installation parameters with separate namespace and own formal language are used. Because templates can be used multiple times, installation parameters must be made explicit by setting instances of instance parameters as part of the installation parameter names. Furthermore, appropriate templates for installation and deinstallation are created for the templates, in which the references required for a configuration to external entities and / or resources during the instantiation are automatically created and / or removed. Finally, it is necessary to adapt the configuration at the time of installation to the environment in which it will be installed.
  • the installation scripts use adaptation files for this, in which the parameterization of the instance parameters is resolved by the assembly automaton during the block alignment. During installation, the installation parameters are then resolved accordingly by replacing them with the actual values.
  • the configuration consists of a series of building blocks, each of which corresponds to an instruction to instantiate an existing template. These building blocks must all be captured and listed in a project configuration description.
  • the properties of the blocks are each described in specially created property files, which contain the names and values for the associated instance parameters used in the instantiation to override the default values. These values are used in the execution of the assembly machine to replace the placeholders present in the template.
  • the assembly machine then generates the blocks with the associated resources from the templates and stores them in the target directory of the project. All instance parameters and / or functions are set appropriately for the new partial configuration so that a composite, installable application (configuration) is created.
  • Claims 7 to 1 2 describe a data carrier with data stored thereon or a signal sequence representing data suitable for transmission via a data network, the data representing a program for execution on a data processing system, which implement the method claims described in claims 1 to 6, if the program is running on a computer, computer network or over the Internet.
  • a data carrier with data stored thereon or a signal sequence representing data suitable for transmission via a data network
  • the data representing a program for execution on a data processing system, which implement the method claims described in claims 1 to 6, if the program is running on a computer, computer network or over the Internet.
  • Claim 13 describes a computer program with program code for performing all method steps according to at least one of claims 1 to 6, when the computer program is executed on a computer, a computer network or via the Internet.
  • a computer program Under a computer program is a machine to understand readable and executable instruction sequence, which by storage, for. B. on a disk or in a volatile or nonvolatile memory module of a computer, or by signals that are sent via the Internet, is embodied.
  • the computer program does not need to be in an immediately executable form; it may also be in a form prepared for installation on a user's computer.
  • Claim 14 describes a computer system which is set up so that it uses a data carrier with data stored on it or a signal sequence suitable for the transmission via a data network, the data representing a computer program with program code according to claim 13 and the computer system the computer program according to the features described in claims 1 to 6 performs. Again, to avoid repetition, reference is essentially made to the previously described embodiments of the claims 1 to 6.
  • Figures 1 to 4 show flow diagrams of an exemplary embodiment of the invention
  • Figures 5 to 1 8 show explanatory screenshots from an associated visual programming environment.
  • FIG. 1 shows a flowchart which represents an exemplary project from the creation of a suitable environment for using the corresponding templates to the installation package of a new software composed of reused configuration components and thus describes the exemplary program sequence of the assembly machine in a project.
  • FIG. 2 shows a flow chart for the block instantiation mentioned in FIG. H . the replacement of the template parameters with appropriate content.
  • the flowchart in FIG. 1 continues from the point "Block b in the working directory”.
  • Fig. FIG. 3 shows a more detailed illustration of the first working step of the embodiment shown in FIG. 2 mentioned process of creating a working copy. After the working copy has been created, the flowchart in FIG. 2 continued from the point "Working copy of block b".
  • FIG. 4 shows a representation of the device shown in FIG. 1, the next-to-last step “Packaging” as a more detailed flowchart After the packaging has been carried out, the flowchart in Figure 1 is continued from the penultimate item "installation package of the application".
  • an inventive reuse of executable software configuration begins with a basic project designation. After parameterizing the program with the data storage locations for the project and the template library, the project configuration including the project parameters is loaded. Then, for each of the building blocks defined in the project configuration description, the instantiation is performed from the template assigned to it. At the end, the packaging of the finished components is carried out to form an installation package according to FIG. 4, which will be explained below.
  • a list of the instance parameters for the block is created from the template's default template file, the block configuration properties file, and the project and block properties of the project configuration description. Thereafter, the program sequence corresponding to FIG. 2 is performed, which begins with the creation of a working copy corresponding to FIG. 3.
  • the procedure for creating a working copy in FIG. 3 serves to create a structure that is used both in the instantiation of the block and in the packaging.
  • the structure consists of the unpacked part configuration, the replacement rules, customization files and install scripts, and other resources. How to implement the unpacking of the sub-configuration, as well as the later packing, depends on the export format, which is given by the software system; however, standard formats for archives are often used as the export format.
  • the process in Figure 2 continues with a search for parameters in the working copy to replace them with their value. These parameters are instance parameters and functions, but not installation parameters.
  • the search speed can be optimized by using binary files of known type, e.g.
  • the replacement rules are then executed on the part configuration in the working copy, whereby the components of the subconfiguration defined in the rules are replaced with the defined components of the files (resources) from the block configuration. If the replacement is complete, the block is ready for packaging. This takes place after this process has been completed for all blocks.
  • the packaging is described in FIG. 4 and describes the generation of an installation package for the generated building blocks.
  • the target directory has to be created, which is finally packed in an archive.
  • This also basic installation scripts are copied into, which are provided by the assembly machine. These scripts must be able to perform a general installation of building blocks in the software system, which are stored as follows.
  • This filing is done by placing the subconfigurations, installation scripts (module-specific) including customization files and other resources (if present) in the target directory so that they are found by the basic installation routines and the modules are installed in the software system during installation.
  • the software supports the development and the operation of integration routes in the business-to-business (B2B) or enterprise application integration (EAI) environment.
  • B2B business-to-business
  • EAI enterprise application integration
  • Such an integration path can, for example, receive data from an application A, then optionally filter, convert, modify, etc. and forward it to further applications B and C.
  • the software supports the parallel operation of such integration links (i.e., multiple applications / configurations).
  • the basic, common starting point in the development of software using templates lies in the recognition that such solutions (in this case integration paths), although technically different, are similar from a certain technical point of view. Abstraction can be used to find technical solution patterns that are suitable for developing templates. The more the behavior can be abstracted, the more universally applicable and therefore more valuable such templates are.
  • the instance parameter names are included in this example by the string XXX to make the method transparent to the visual programming environment.
  • the entries are made via text fields.
  • a directory "XXXprojectnameXXX" will be created, which will contain future integration links, and will be set later in the project, leaving each application with its own folder after installation and separated from other applications.
  • a directory "XXXcomponentnameXXX" is created, see Fig. 5, which later contains the building blocks (parts) of the respective application be separated from other building blocks of the application, even if they are based on the same template.
  • An assembly machine is created, which is set up in such a way that it summarizes and carries out all automatable to the creation of a new software automatable procedures.
  • the assembly machine is set up in such a way that it first predefines the values of the instance parameters "projectname” and "componentname” for each building block by the algorithm.
  • a template template directory is created for each template to allow the templates to be developed separately.
  • the example creates an input interface template for WSDL WebServices called "WSInboundAdapter.”
  • Another input interface template for file reception and two outbound interface templates for WSDL or file delivery are created (see Figure 6) For example, it will be possible to selectively couple one building block based on an input interface template to one building block based on one of the two exit interface templates.
  • a proxy service which includes the configuration of the input interface and the programming of the service functionality, and uses the previously mentioned WSDL file (see Fig. 7).
  • the transclusion is replaced by substitution rules, and only a wildcard is used in the subconfiguration, which is later exchanged by the assembly automaton using the substitution rules and transclusion when the module is generated.
  • transclusion could also be defined in an adaptation file or in an installation script placeholder file that responds to an API without departing from the invention.
  • the template After applying the replacement rules, the template includes the one shown in FIG. 9 entities shown.
  • the visual programming of the proxy service breaks down into 2 processes (pipelines) for the message flow, into the request and the response, s. Fig. 10.
  • the incoming page for these processes is determined by the choice of the technical protocol, here WSDL / SOAP / http, when the ProxyService is created (called “Service” in Figure 10) .
  • the outgoing side should communicate with the next device
  • the message flow at the end (see “RouteNodel” in FIG. 10) of the ProxyService is set up with "dynamic routing" in such a way that the next block is loosely coupled with the aid of its block name and the template name (see FIG. 1 1).
  • SOAP internal standard protocol
  • the customization file is now parameterized by including all values that are present in it and are environment-dependent or in the block
  • substitution rule file must now, as previously mentioned, have a rule to replace the WSDL wildcard.
  • the structure of the exported part configuration is taken into account and possibly analyzed.
  • it is available as a jar file, which technically corresponds to a ZIP archive.
  • the WSDL file is stored within "XXXprojectnameXXX ⁇ XXXcomponentnameXXX ⁇ WSInboundAdapter ⁇ InterfaceDefinition .WSDL".
  • Within this file is embedded the WSDL wildcard.
  • wsdlfilename definition.wsdl Since the instance parameter within the transclusion is used as a reference to a file name, the consequence of this is that this file is written in the block configuration described below.
  • the XMLFilterboundAdapter template solves the technical problem of the XML style "accept XML via file interface” integration style by configuring the ProxyService slightly differently and eliminating WSDL (see Figure 1 5).
  • the endpoint URI (Uniform Resource Identifier) references the directory from which the message files are read. This is parameterized in the customization file by the developer looking for and modifying the associated entry.
  • the customization file before editing is shown in FIG. 16, after the editing in FIG. 17.
  • the instance parameter "filepath” is set to a default in the property default file in this example.
  • the template can be used multiple times, there must be different value assignments in the property file of the block, otherwise the plausibility rules of the software will be violated. This is taken into account in the development of the templates by parametrizing the value assignment with "componentname”. At the same time, this value can also be extended to the installation parameter.
  • filepath @ XXX componentnameXXX. filepath®
  • the templates "WSOutboundAdapter” and “XMLFileOutboundAdapter” send messages. They are basically set up in the same way, whereby the outgoing protocol is configured in a resource "BusinessService” not shown here in the figures.
  • the ProxyService is used to receive messages from to receive the input interface templates under the name “Service” as shown in FIG. 18 configured.
  • Examplel The project, which in this example is called "Examplel", is to be used, for example, to generate software that accepts an XML message via WSDL and places it in the directory "/ transfer / out /".
  • a block A is created on the basis of the "WSInboundAdapter” and coupled with a block B based on the "XMLFileOutboundAdapter”.
  • the assembly machine is executed and according to the invention generates an installation package in which a wIst script is located, which is set up so that it installs the generated building block subconfigurations and the adaptation files, which are also in the installation package, within a transaction.
  • the wIst script is started with the Weblogic Scripting Tool of the Oracle Service Bus software system.
  • File - An inventory of mostly related data and software resources stored on a media or storage medium.
  • the chosen form of persistence plays a subordinate role and terms such as file, directory and resource are given for illustration purposes; it does not have to be a filing in directories of a file system, but could be z.
  • B. persisted in databases
  • Entity The software configurations of the software systems are based on a data model in which a concrete configuration to entities of the software system and their relationships to each other are described.
  • Creation Process A build process in IT is a process that automatically creates a finished application program. The assembly machine implements this process according to the invention in the context of standard application software.
  • Export - A process in which a software configuration is transformed, if necessary, and then stored in a file or repository to be re-imported at another time, or otherwise B. here in the assembly machine to use.
  • Formal language In this context, a suitable formal language is needed in which parameters and functions can be defined that governs a distinction to remaining strings and brings about a unique machine behavior of the visual programming environment and the assembly automaton. In the visual programming environment, validations must be turned off when parameters and functions are specified. From the assembly machine, the parameters and functions are evaluated.
  • Function - Functions in this context are parameterisable instructions for executing pre-defined routines of the assembly machine that return a value that can be used like an instance parameter.
  • Function Parameters - Function parameters are values, instance parameter names, or entity names that are used directly as the argument of a function.
  • Generic Programming - is a process for developing reusable software libraries.
  • functions are designed as general as possible in order to be used for different data types and data structures.
  • template names and all entities of the template are prepared for instantiation so that after instantiation and installation, different instances (subconfigurations) of a template can coexist without conflict. If this is the case, the template is considered to be instantiable.
  • Instance Parameters - Instance parameters are here called parameters of a template whose value is fixed when the instantiation is performed by the assembly automaton, whereby the resulting subconfigurations should be free of instance parameters. Instance parameters should also be used in the name of the template to instantiate subconfigurations.
  • Installation Parameters - Installation parameters are parameters that can be present both in templates and later, in the sub-configurations and associated resources generated by the assembly automaton. They are only set permanently during installation by the installation program. Installation parameter names can be parameterized by instance parameters and functions, so that also installation parameters are multiplied by the instantiation.
  • Loose coupling - in this context refers to a low degree of dependence of the blocks on each other, which is achieved by parametrization of the references to each other and the abstraction of the interface definitions by parameterization.
  • Namespace In this context, namespaces are relevant to entities of subconfigurations and parameters. These are clearly identifiable by path names and arranged in a hierarchy. Packing / Unpacking - If subconfigurations consist of file archives, it may be necessary to perform some special functionality, such as operation on individual files of the archive, which requires temporary unpacking of the file archive. Parameter parameters are used within the usual terminology. Linguistically, a distinction is made between instance parameters, function parameters and installation parameters.
  • Template - Templates in this context are pre-made components designed as design patterns for reuse of configurations. They serve as a concrete blueprint for the generation or instantiation of similar Partial configurations by means of an assembly machine. Templates can be in hierarchical relationships with each other and can be put together into complex structures. The concept therefore has a certain similarity to classes, but does not contain object orientation by itself. Templates consist of at least one exported sub-configuration and possibly further files / resources.
  • Template library template libraries correspond to a component palette, with the components of the library containing templates in the o.g. Senses are.
  • a sufficient amount of templates in the library enables rapid application development. Because there is a logical dependency of the subconfigurations on your templates, this can be used to implement continuous integration by automatically rebuilding subconfigurations when your templates have been reworked.
  • Schema Language A language for classifying XML documents, such as XSD, and standards based thereon, such as the interface standard WSDL or query languages such as XPath and Xquery.
  • this markup language is given as an example of any other existing or future markup language.
  • Software Configuration A program file that can be executed by the software system, much like a computer program. In addition, it must be possible to merge these into more complex configurations (aggregation) or to divide them back into their subconfigurations.
  • Software System By this is meant a collection of software products suitable for executing a software configuration, in particular cross-functional standard software and application servers.
  • Standard application and standard software - Standard software or standard applications are software systems that cover a clearly defined area of application and are acquired as prefabricated products and not specifically designed for use by a customer or company.
  • Text Stream Editor - A tool used to manipulate text files.
  • Text boxes and text panels - graphical user interface controls that can accept user input in the form of strings in single and multi-cell text boxes.
  • Separator Sequence One or more consecutive characters used as a separator in a syntax supported by the assembly machine and / or installer to define parameters and functions.
  • Transclusion - Function similar to an include preprocessor statement in programming languages, where content from other files is inserted. This process can be multi-level, d. H. the files that are inserted can themselves be parameterized in this extended form and contain transcription instructions.
  • Visual Programming Environment An integrated development environment with a visual development interface that can be used to program the software configuration, not considering any textual editor that may be present in which software is being created using a conventional textual language.
  • the focus is not on the visual representation in the form of the visual language, but on the associated presence of a graphical user interface, the complexity of which goes far beyond programming with a textual language.

Abstract

Es werden Softwaresysteme betrachtet, die eine visuelle Programmierumgebung für die Programmierung von Softwarekonfigurationen beinhalten, Möglichkeiten des Exports von Teilkonfigurationen bieten und ferner sowohl Werkzeuge, um diese zu ablauffähigen Softwarekonfigurationen zusammenzubauen, als auch eine Ablaufumgebung für diese Softwarekonfigurationen beinhalten. Mithilfe einer visuellen Programmierumgebung wird eine Schablonenbibliothek erstellt, die wiederverwendbare Schablonen der Konfigurationen von Standardanwendungen eines Softwaresystems enthält. Die Schablonen dienen zum Erstellen von Software-Bausteinen, die zu neuen Softwarekonfigurationen zusammengefügt werden können. Zunächst wird eine Softwarekonfiguration erstellt und durch den Anwender eine Teilkonfiguration ausgewählt, welche sich zur Vervielfältigung als Schablone eignet und exportierbar ist. Dieser Konfigurationsteil wird dann als Teilkonfiguration in eine neue Schablone innerhalb der Schablonenbibliothek exportiert. Diese Schablonen können dann für vielfältige Anwendungen wiederverwendet werden, indem die in der Schablone enthaltenen Elemente und Verweise auf neue Umgebungen angepasst werden. Hierzu werden die Namen und Attributwerte der Entitäten identifiziert, parametrisiert und instanziierbar gemacht. Bei der Erstellung einer neuen Anwendung werden die Namen und Attributwerte der Entitäten von einem Zusammenbau-Automaten gefunden und geeignet an die neue Umgebung angepasst. Hierfür sucht der Zusammenbau-Automat mithilfe von Suchregeln die für ihn identifizierbar gemachten Namen und Attributwerte der Entitäten und ersetzt diese mithilfe von geeigneten Ersetzungsregeln.

Description

Computerimplementiertes Verfahren und Signalfolge für ein Programm zur Wiederverwendung von ausführbaren Softwarekonfigurationen für Software- Systeme sowie Rechneranlage und ein Computerprogramm mit Programmcode zur Durchführung des Verfahrens
Die Erfindung betrifft ein computerimplementiertes Verfahren, einen Datenträger mit darauf gespeicherten Daten oder eine für die Übersend ung über ein Datennetz geeignete, Daten repräsentierende Signalfolge sowie eine Rechneranlage zur Wiederverwendung von ausführbaren Softwarekonfigurationen für Softwaresysteme im Prozess der Entwicklung neuer Anwendungen für Rechneranlagen oder rechnergestützte Systeme, und ein Computerprogramm mit Programmcode, welches die Verfahrensschritte durchführt, wenn das Computerprogramm auf einem Computer oder einem Computernetzwerk ausgeführt wird .
Es werden Softwaresysteme betrachtet, die eine visuelle Programmierumgebung für die Programmierung von Softwarekonfigurationen beinhalten , Möglichkeiten des Exports von Teilkonfigurationen bieten , und ferner sowohl Werkzeuge um diese zu ablauffähigen Softwarekonfigurationen zusammenzubauen , als auch eine Ablaufumgebung für diese Softwarekonfigurationen beinhalten.
Bei der Entwicklung von Software stellt sich zunehmend das Problem , dass Anwendungen in kürzeren Entwicklungszeiten und zu geringeren Kosten bei gleichbleibend hoher Qualität zur Verfügung gestellt werden sollen .
Eine Möglichkeit diese Ziele zu erreichen liegt darin , bereits als qualitativ hochwertig bekannte Anwendungsbestandteile in anderen Projekten wieder zu verwen- den . Die „bausteinorientierte Softwareentwicklung" ist nur dann einsetzbar, wenn bestimmte Rahmenbedingungen eingehalten werden . So muss gewährleistet sein , dass alle für die Implementierung relevanten Einstellungen, ohne Auswirkung auf die Schnittstellen der Bausteine, lokal verändert werden können . Durch die Wiederverwendung der Bausteine muss der Entwicklungsprozess für eine neue Anwendung nicht immer wieder von vorne begangen werden, sondern kann auf bereits entwickelte, validierte und verifizierte Komponenten zurückgreifen , so dass Anwendungen mit weniger Aufwand entwickelt werden können. Wiederverwendbarkeit wird als eine Eigenschaft angesehen, die nicht nachträglich einer Komponente hinzugefügt werden kann.
Der Hintergrund dieser Problemstellung ist beispielsweise beschrieben in „Wissensmanagement und Software Engineering - Wiederverwendbarkeit" (www.communitv-of-knowledqe.de/beitraq/wissensmanaqement-und-software- enqineerinq-wiederverwendbarkeit/) oder in „Software nach dem Baukastenprin- zip" (Prof. Dieter Rombach , Fraunhofer Magazin 1 .2003) .
Aufgrund der Schwierigkeiten , Software-Bausteine für die Wiederverwendbarkeit heranzuziehen , muss man im Stand der Technik davon ausgehen , dass nur solche Anwendungen für die Wiederverwendung geeignet sind , die bereits bei der Konzeption für eine spätere Wiederverwendung ausgelegt wurden. Die Ansprüche an die Adaptierungsmöglichkeiten , Funktionalität, Schnittstellen etc. sowie die Verwaltung der wiederverwendbaren Komponenten in entsprechenden Software- Bibliotheken , können bei dieser Sichtweise nur dann erfüllt werden, wenn die Komponenten z. B. in einem objektorientierten Rahmen erstellt und entsprechend organisiert zur Verfügung gestellt werden . Eine weitere Variante wäre das Proto- typing aus dem Rapid Application Development (RAD) -Ansatz, wo z. B. vorgefertigte Prototypen als Bibliothek in einem RAD Tool bereitgestellt werden .
Der grundlegende, übliche Ansatzpunkt bei der Entwicklung einer Software unter Verwendung von Schablonen liegt in der Erkenntnis, dass sich Lösungen zwar fachlich unterscheiden , jedoch unter gewissen technischen Gesichtspunkten ähneln . Durch Abstraktion können technische Lösungsmuster gefunden werden , die sich zur Entwicklung von Schablonen eignen. Je mehr sich das Verhalten abstrahieren lässt, desto allgemeiner einsetzbar und somit wertvoller sind solche Schablonen . Solche Lösungsmuster auf dem Gebiet der Enterprise Application Integration (EAI) wurden z. B. durch Gregor Hohpe, Bobby Woolf veröffentlicht in „Enterprise Integration Patterns. Designing , Building , and Deploying Messaging Solutions", Addison Wesley, 20. Oktober 2003, ISBN 978-0321200686. Im Gegensatz zu solchen , nach dem Baukastenprinzip erstellten Komponenten , werden Konfigurationen für Standardsoftware im Stand der Technik nicht als geeignet für die Wiederverwendung bei der Anwendungsentwicklung angesehen . Im Stand der Technik sind zahlreiche Methoden entwickelt worden, um die Erstellung von Software zu beschleunigen und zu vereinfachen.
So beschreibt beispielsweise die DE 698 38 139 T2 ein Verfahren und ein System zur Schaffung von Datenbankanwendungssoftware, die minimales Programmieren benötigen. Dabei wird eine Methode zum automatischen Erzeugen von komplexen Softwareanwendungen ohne eingehende traditionelle und detaillierte Programmierung vorgestellt. Hierbei wird aus einer geeignet verfeinerten Softwarebeschreibung die Zielsoftware aus einer wiederverwendbaren universellen Softwareanwendung erzeugt.
Die DE 690 31 078 T2 beschreibt eine rechnergestützte Softwareentwicklungseinrichtung , bei der unter anderem auch ein Augenmerk auf Wiederverwendbarkeit gerichtet ist. Der Aspekt der Wiederverwendbarkeit wird durch die Verwendung einer höheren Regelsprache realisiert, in der die Logik eines Programms in hochmodularer Form festgelegt werden kann und somit die Wiederverwendbarkeit fördert. Bei der automatisierten Erstellung des Quellcodes wird auf die wiederverwendbaren Elemente zurückgegriffen .
Gemeinsamer Nachteil des Stands der Technik ist, dass durch den Anwender selbst entwickelte Anwendungen (Softwarekonfigurationen) der Standardsoftware nicht als wiederverwendbare Komponenten für die Entwicklung neuer Anwendungen angemessen berücksichtigt werden können , da kein ausreichender Zugriff auf das Entitäten-Modell per API (Application Programming Interface) angeboten wird. Dadurch sind die Mittel zur Erstellung eigener Software-Bibliotheken mit Hilfe der visuellen Programmierumgebung dieser Standardsoftware dermaßen begrenzt, dass keine oder zumindest keine hinreichende Menge an Komponenten (Schablonen) für solche eigenen Bibliotheken erstellt werden kann , die eine komplexere Programmierung nach dem Baukastenprinzip ermöglicht. Durch eine hinreichende Menge an Schablonen in der Bibliothek wird Rapid Application Development ermöglicht. Weil eine logische Abhängigkeit der Teilkonfigurationen von ihren Schablonen existiert, kann dies zur Umsetzung von kontinuierlicher Integration genutzt werden, indem Teilkonfigurationen automatisch neu erzeugt werden, wenn Ihre Schablonen überarbeitet wurden . Lediglich einfachere Bausteinschnittstellen mit Parameterlisten wären mit dem im Stand der Technik üblichen Mittel, dem Suchen und Ersetzen, möglich . Komplexere Schnittstellen und Parametrisierungen jedoch , wie sie z. B. mit Hilfe von XML Schemas (XSD) erstellt werden können, sind damit nicht realisierbar. Die Generische Programmierung erfordert jedoch eine gewisse Abstraktion von Datentypen, beziehungsweise die Möglichkeit diese zu spezialisieren . XML Schemas würden diese Möglichkeit z. B. durch Neudefinition von Datentypen bieten.
Es ist daher Aufgabe der Erfindung , diesen Nachteil zu überwinden und ein Verfahren zur Verfügung zu stellen , mit dem auch bei Standardsoftware wiederverwendbare Bausteine in der Entwicklung neuer Anwendungen verwendet werden können, wobei die Unterstützung generischer Programmierung die wesentlichste Herausforderung ist. Hierbei soll es möglich sein, die einzelnen Bausteine in der visuellen Programmierumgebung weiter zu entwickeln .
Es ist auch Aufgabe der Erfindung , einen Datenträger mit darauf gespeicherten Daten oder eine für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge bereitzustellen , die es ermöglicht, auch bei Standardsoftware wiederverwendbare Bausteine in der Entwicklung neuer Anwendun- gen zu verwenden .
Weiterhin soll eine Rechneranlage zur Verfügung gestellt werden , die so eingerichtet ist, dass damit auch bei Standardsoftware wiederverwendbare Bausteine in der Entwicklung neuer Anwendungen verwendet werden können .
Weiterhin soll ein Computerprogramm mit Programmcode zur Verfügung gestellt werden , welches die Verfahrensschritte durchführt, wenn das Computerprogramm auf einem Computer oder einem Computernetzwerk ausgeführt wird. Der Programmcode kann entweder auf einem Datenträger gespeichert sein , der das Verfahren als maschinenies- und ausführbares Programm enthält oder in einem Computernetzwerk wie z. B. das Internet für Client-Server-Systeme zur Verfügung gestellt werden, die mithilfe des Programms betrieben werden .
Diese Aufgaben werden durch das erfindungsgemäße Verfahren gemäß Anspruch 1 , einen Datenträger mit darauf gespeicherten Daten oder eine für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge gemäß Anspruch 7, ein Computerprogramm mit Programmcode gemäß Anspruch 13 und eine Rechneranlage, eingerichtet als Client-Server-System gemäß Anspruch 14 gelöst. Vorteilhafte Weiterbildungen und Ausgestaltungen sind Gegenstände der abhängigen Ansprüche.
Es entsteht eine neue Funktionsfähigkeit für Anwender, durch einen neuartigen Aufbau des Softwaresystems, insbesondere auch der Benutzerschnittstelle, welcher Anwender-übergreifend den Gebrauch des Systems erweitert, da Wiederverwendbarkeit ein Anwender-übergreifendes Verfahren darstellt. Zudem wird erstmals der technische Prozess der kontinuierlichen Integration, ein automatischer Vorgang , der im Hintergrund oder auf einem anderen Computer in einem Computernetzwerk abläuft, für Bausteine, die mit visueller Programmierung (4GL) erstellt wurden, ermöglicht.
Erfindungsgemäß wird auf ausführbare Softwarekonfigurationen für Softwaresysteme mit einer visuellen Programmierumgebung zurückgegriffen . Ein Softwaresystem stellt hierbei ein System von Software-Bausteinen dar, die miteinander in Verbindung stehen und untereinander kommunizieren können . Aus dem Zusam- menwirken der Software-Bausteine eines Softwaresystems wird das Zusammenwirken von Teilen eines Computer-Systems, das aus Hardware und Software besteht, ermöglicht. Ein Softwaresystem besteht beispielsweise aus Haupt- und Unterprogrammen sowie Konfigurationsdateien und einer Ablaufsteuerung , welche die Software-Konfiguration ausführt. Eine Software-Konfiguration ist ein Datenmo- dell, bestehend aus Entitäten und deren Beziehungen , das beschreibt, wie eine Software an die vorhandene Hard- und Software angepasst ist, auf Ereignisse reagiert oder sich anderweitig verhalten soll. Um eine Software unter einer bestimmten System-Konfiguration einsetzen zu können, muss diese entsprechend eingerichtet werden. Erfindungsgemäß wird eine Schablonenbibliothek erstellt, die wiederverwendbare Schablonen der Konfigurationen von Standardanwendungen eines Softwaresystems enthält. Die Schablonen dienen zum Erstellen von Software-Bausteinen , die zu neuen Softwarekonfigurationen zusammengefügt werden .
Zunächst müssen die Schablonen erstellt werden . Hierfür muss das Softwaresystem wenigstens eine Möglichkeit zum Exportieren von Teilkonfigurationen aufweisen . Zunächst wird eine Softwarekonfiguration erstellt und durch den Anwender eine Teilkonfiguration, d. h . ein Teilmodell der Konfiguration ausgewählt, das sich aus seiner Sicht zur Vervielfältigung als Schablone eignet und exportierbar ist. Dieser Konfigurationsteil wird dann als Teilkonfiguration in eine neue Schablone innerhalb der Schablonenbibliothek exportiert.
Beim Export einer Teilkonfiguration wird somit aus jedem wieder zu verwenden- den Teil einer Anwendung mindestens ein Teilmodell einer Konfiguration dieser Anwendung erstellt, das für die Wiederverwendung in einer anderen Anwendung geeignet ist. Das exportierte Teilmodell darf Abhängigkeiten („Schnittstellen") zu anderen Teilmodellen der Konfiguration aufweisen . Diese Schablonen können dann für vielfältige Anwendungen wiederverwendet werden , wenn die in der Schablone enthaltenen Elemente und Verweise auf die entsprechende neue Umgebung angepasst werden können . H ierzu müssen die Namen und Attributwerte der Entitäten identifiziert, parametrisiert und instanziier- bar gemacht werden.
Bei der Erstellung einer neuen Anwendung werden die Namen und Attributwerte der Entitäten von einem Zusammenbau-Automaten gefunden und geeignet an die neue Umgebung angepasst. Hierfür sucht der Zusammenbau-Automat mithilfe von Suchregeln die für ihn identifizierbar gemachten Namen und Attributwerte der Entitäten und ersetzt diese mithilfe von geeigneten Ersetzungsregeln. Die instan- ziierbare Teilkonfiguration wird somit durch den Zusammenbau-Automaten zu einer in der neuen Anwendung funktionsfähigen Teilkonfiguration instanziiert.
Im Folgenden wird beschrieben , wie die exportierte Teilkonfiguration erfindungs- gemäß instanziierbar gemacht wird : Um die zuvor genannten Beschränkungen im Stand der Technik zu überwinden, ist zunächst die visuelle Programmierumgebung des Softwaresystems so anzupassen , dass die Namen der Entitäten, inklusive deren Namensraum sowie die Eigenschaften, womit die Werte der Attribute gemeint sind, über die graphische Benutzeroberfläche (GU I) parametrisiert werden können.
Die Parametrisierung , in Form des Einfügens von Parametern und Funktionen , erfolgt in der visuellen Programmierumgebung über ein- und mehrzellige Textein- gabefelder. Für die Verwendung von Parametern und Funktionen ist eine formale Sprache zu definieren, über die die Parameter- und Funktionsnamen kodiert werden . Die vorhandenen Eingabefelder müssen dann so verändert werden, dass sie die Eingabe von Parametern und Funktionen im Text zulassen . Hierzu sind vorhandene Validierungsprüfungen für die Gültigkeit der Werte abzuschalten, wenn parametrisierte Eingaben anhand der dafür definierten formalen Sprache erkannt werden. Andere vorhandene Eingabetypen , z. B. Optionsfelder (engl. : Radio buttons) und Datentypen der Attributwerte, sind so anzupassen , dass sie ebenfalls parametrisierte Eingaben erlauben , z. B. entweder durch Umwandlung in Texteingabefelder oder durch Ergänzung einer Option, welche die Angabe eines Parameters ermöglicht. Die visuelle Darstellung der Parameter und Funktionen in den Texteingabefeldern kann durch Hervorhebung verbessert werden.
Entitäten , die parametrisiert wurden oder parametrisierte Entitäten enthalten, sind abstrakt, und Konfigurationen , in denen sie enthalten sind , können i.A. nicht fehlerfrei ausgeführt werden , bis die Parameterwerte zugewiesen und die Funktionswerte bestimmt sind . Das Softwaresystem sollte daher so angepasst werden , dass es die Ausführung von Konfigurationsteilen mit Entitäten, die abstrakt sind , unterbindet und diesen "abstrakten" Zustand ebenfalls visuell hervorhebt. Um die Flexibilität des Verfahrens zu erhöhen, ist es weiterhin möglich , bei der Parametrisierung der auf den Schablonen basierenden Teilkonfigurationen innerhalb der visuellen Programmierumgebung anstatt eines Instanz-Parameters mit Hilfe der formalen Sprache auch eine Funktion als Anweisung an den Zusammenbau-Automaten zur Durchführung einer Transklusion anzugeben . Vom Zusammenbau-Automaten wird an einer solchen Stelle also die Signatur der Funktion als Referenz auf eine Ressource bzw. eine Entität interpretiert, deren Inhalt bei der Instanziierung eingelesen wird. Der Zusammenbau-Automat erzeugt also in der neuen Teilkonfiguration an dieser Stelle den Inhalt der referenzierten Datei, so dass auch komplexere Anpassungen flexibel durchführbar sind . Damit der Zusammenbau-Automat einen solchen Verweis erkennt, wird die Signatur einer Funktion so eingerichtet, dass sie mindestens einen Funktionsparameter besitzt, der vom Zusammenbau-Automaten als Referenz auf eine Ressource bzw. Entität interpretiert wird .
Maximale Flexibilität wird erreicht, indem der Inhalt der Ressource bzw. Entität, auf die verwiesen wird, seinerseits durch Instanz-Parameter und Funktionen parametrisiert sein kann . Nach dem Einlesen des Inhalts der Entität bzw. der Ressource können in diesem Fall weitere Instanz-Parameter und Funktionen vorhanden sein, die zusätzlich durch den Zusammenbau-Automaten instanziiert werden . Erst nach Auflösung aller enthaltenen Instanz-Parameter und untergeord- neten Funktionen wird der Wert der Funktion schließlich , analog einem Parameterwert, verwendet. Dies ist insbesondere da von Vorteil, wo der Inhalt auf einer Schemasprache basiert. Anstelle einfacher Parameter, die auf primitiven Datentypen wie String , Integer, etc. basieren , kann man damit nun komplexe Datentypen und Inhalte (z. B. XSD, XML) und ganze Schnittstellendefinitionen (z. B. WSDL) parametrisieren . Durch eine solche Abstraktion wird Generische Programmierung möglich.
Anstatt der Angabe einer Funktionen zur Durchführung einer Transklusion können Entitätswerte oder Entitäten , die genau einen Entitätswert als "Inhalt" haben, auch verkürzt über die GU I als "abstrakt" oder "überschreibbar" markiert, d. h. gekennzeichnet werden. Der Funktionsparametername für die Transklusion, der die Datei mit dem Wert für den Inhalt referenziert und ansonsten anzugeben wäre, ist dann nicht frei wählbar, sondern wird explizit durch das Softwaresystem und den Zusammenbau-Automaten vorgegeben .
Einem abstrakten Entitätswert ist die Signatur für die Transklusionsfunktion zugewiesen und er muss überschrieben werden.
Für einen überschreibbaren Entitätswert muss ein gültiger Wert zugewiesen werden , für den implizit eine Ersetzungsregel erzeugt wird, falls dem Funktionsparameternamen eine Referenz zugewiesen wird. Insbesondere überschreibbare Entitätswerte eignen sich für die Generische Programmierung , wenn in der Schablone ein generalisierter Typ verwendet wird , der in der Schablone in Unterroutinen verwendet wird, um dann in abgeleiteten Bausteinen spezialisierte Typen einzusetzen .
Um zu sin nvollen Schablonen zu kommen empfiehlt es sich, den wiederzuverwen- den Teil der Konfiguration für die Instanziierung vorzubereiten. Damit Schablonen dupliziert werden können , müssen sich bei zwei Duplikaten die Namen aller Entitäten im Teilmodell unterscheiden . Namensräume sind in der Regel hierar- chisch in einer Ordnerbaumstruktur aufgebaut. Sie sollten sich in einem Ordner befinden , in dem keine Entitäten enthalten sind , die nicht zu dieser Schablone gehören. a) Alle zugehörigen Entitäten einer Schablone sind im Namensraum der Konfigu- ration unter einem für diese Schablone vorbehaltenen Pfad mit Hilfe der visuellen
Programmierumgebung zu vereinen . Der Name des letzten Elements in diesem Pfad muss dann parametrisiert werden (Parameter: Bausteinname), um eine Vervielfältigung zu ermöglichen . Sollen mehrfache Installationen in Form von Projekten unterstützt werden, sollte das vorherige Pfad-Element ebenfalls para- metrisiert werden (Parameter: Projektname). b) Referenzen (Attributwerte, die eine Pfadangabe darstellen) und Schnittstellen zwischen Schablonen außerhalb des Namensraums der Schablone und externen Komponenten (außerhalb des Systemkontextes) müssen parametrisiert werden , um eine "lose Kopplung" zu erreichen. Das Verfahren ermöglicht eine Generische Programmierung , indem Schemasprachen wie XSD zur Definition von Datentypen verwendet werden können , die mittels parametrischer Polymorphie generisch behandelt werden können. Die Kommunikation und der Datenaustausch über diese Schnittstellen basieren auf diesen Schemasprachen . So können Daten per XML ausgetauscht werden, oder sogar die Schnittstelle selbst über eine Beschreibungssprache auf Basis der Schemasprache definiert werden, wie z. B. WSDL. Über die Parametrisierung kann somit erreicht werden, dass alle Sprachelemente wie XSD, XML und WSDL in den Bausteinen individuell eingestellt und aufeinander abgestimmt werden können . c) Ähnlich wie bei Superklassen in Objekt-orientierten Sprachen , muss die abstrakte Funktionalität einer Schablone mit den Parametrisierungen der Bausteine, die von ihr abgeleitet werden, zurechtkommen , was einer Semantik bedarf, die durch den Entwickler der Schablone zu planen ist. Das Problem, dass einer generischen Behandlung Grenzen gesetzt sind und man ggf. Baustein-spezifisch konkretisieren muss, kann ähnlich wie in der Objekt-Orientierung üblich durch Delegation an eine Baustein-spezifische Implementierung einer Unterroutine, z. B. XQuery oder Softwarebibliothek, gelöst werden. Der materielle Wert der Schablone ist abhängig von der Menge an Funktionalität, welche unabhängig von der Ableitung implementiert werden kann.
Nachdem jedes Teilmodell als Teil einer kopierfähigen Schablone exportiert und in der Schablonenbibliothek gespeichert wird , können die Schablonen nun von anderen , neu zu erstellenden Anwendungen wiederverwendet werden . Hierzu wird bei der Erstellung der neuen Anwendung ein Zusammenbau-Automat verwendet, der die zu verwendenden Schablonen erfindungsgemäß verwendet, aus der Anwendungsbibliothek herauskopiert, die konfigurierbaren Zeichenketten der Schablonen parametrisiert und durch Instanz-Variablen zu einem in der neuen Anwendung funktionsfähigen Baustein instanziiert. Die instanziierten Bausteine werden dann durch den Zusammenbau-Automaten automatisiert zusammengefügt und in der Regel mit weiterem Anwendungscode ergänzt. Dabei entsteht eine neue und ablauffähige Softwarekonfiguration und Anwendung .
Wird die Erfindung durch den Hersteller umgesetzt, so ist von ihm auch der Zusammenbau-Automat umzusetzen und dem Nutzer als Werkzeug bereitzustel- len.
Eine vorteilhafte Ausgestaltung der Erfindung verwendet eine formale Sprache zur Kodierung der Namen und Attributwerte der Entitäten , bei der die Verwendung der Instanzparameter und Funktionen transparent bleibt. Dies ist insbesondere dann von Bedeutung , wenn die Wiederverwendung einer Teilkonfiguration nicht durch den Hersteller der einer Schablone zugrundeliegenden Standard-Anwendung erfolgt.
Um Probleme bei Syntaxprüfungen zu vermeiden , ist dabei eine ungewöhnliche Trennzeichenkettenfolge, ohne Verwendung von Sonderzeichen, aus dem Alphabet als Wort der formalen Sprache zu wählen . Diese kann durch Überlegung oder experimentell per Ausschlussverfahren ermittelt werden . Dadurch werden Zeichenketten gebildet, die zwar eindeutig vom Rest des Schabloneninhalts getrennt identifiziert werden können , aber gleichzeitig in der visuellen Programmierumge- bung als gültige Zeichenketten interpretiert und somit problemlos verarbeitet werden . Wenn beispielsweise XXX als Trennzeichenkette festgelegt wird , kann der Parameter "Schablonenname" als "XXXSchablonennameXXX" geschrieben werden , ohne dass die Software (das Softwaresystem) von der Semantik dieser Modellierung etwas mitbekommen würde. Ein Funktionsaufruf "Import(ReferenzA)" könnte analog z. B. als "XXXImportYYYReferenzAXXX" geschrieben werden.
Funktionen werden in der Form modelliert, dass ihre Signatur als n-Tupel ausgestaltet ist. Mindestens eine eindeutige Trennzeichenkettenfolge grenzt den Funktionsaufruf von allen anderen Zeichenkettenfolgen ab. Dadurch kann der Zusammenbau-Automat sicher erkennen , dass an dieser Stelle eine Funktion aufgerufen wird . Innerhalb des Funktionsaufrufs werden der Funktionsname und die zur Funktion gehörenden Parameter benannt. Damit diese entsprechend erkannt und zugeordnet werden können , werden sie von mindestens einer weiteren , untergeordneten Trennzeichenkettenfolge jeweils eindeutig voneinander abgegrenzt.
Weiterhin können Funktionsparameter des Funktionsaufrufs Instanzparameter sein . Das heißt, dass auch die in der aufgerufenen Funktion verwendeten Parameter instanziierbar sein können und somit vom Zusammenbau-Automaten bei der Instanziierung gemäß entsprechender Regeln belegt werden.
Ein erfindungsgemäßes Verfahren zur Erzeugung und Verwendung einer Schablone kann gemäß Anspruch 3 erfolgen. Im Folgenden wird der Weg für den Nutzer, der nicht Hersteller ist, beschrieben. Wenn ein Hersteller des Software- Systems diese vorteilhafte Ausführung der Erfindung umsetzt, kann er dies abwandeln und das Verfahren für Nutzer transparenter gestalten . Zu den einzelnen Ressourcen ist folgendes zu sagen:
a) Datei mit Vorbelegungen der Werte der Instanzparameter:
Der Zusammenbau-Automat braucht für die Instanziierung eine vollständige Zuweisung aller in der Schablone verwendeten Instanzparameter zu einem Wert. Wenn eine Vorbelegung in der Schablone existiert, so kann dieser Schritt später für diese Instanzparameter entfallen . Vorbelegungen werden verwendet, wenn der Wert später nicht explizit für den Baustein angegeben wird (Fig. 1 ). Am besten sollte eine vollständige Zuweisung für alle Instanzparameter mit Kommentar zur Dokumentation erfolgen; dies unterstützt auch das Softwaredesign-Paradigma "Konvention vor Konfiguration". Ein sinnvolles Datei-Format hierfür ist z. B. eine Java-Properties-Datei.
b) komplementäre Teilkonfiguration :
Wenn die Schablone Abhängigkeiten zu Entitäten außerhalb deren Teilkonfiguration besitzt, kann diese ggf. nicht mehr alleine für sich in die visuelle Programmierumgebung geladen werden, wenn die visuelle Programmierumgebung Inkonsistenzen feststellt. In diesem Fall ist es für die Weiterentwicklung der Schablone erforderlich, eine minimale, komplementäre Teilkonfiguration zu erstellen, die zusammen mit der Teilkonfiguration der Schablone eine gültige Konfiguration ergibt.
c) Ersetzungsregeln :
Diese Dateien enthalten Anweisungen, insbesondere zur Textmanipulation . Der Zusammenbau-Automat liest diese Anweisungen aus und verwendet sie, um bestimmte Zeichenketten in der aus der Schablone exportierten und gegebenenfalls ausgepackten Teilkonfiguration zu suchen und diese zu ersetzen . Dadurch wird die Transklusions-Funktion auch dort einsetzbar, wo es aufgrund der Bauart der visuellen Programmierumgebung ansonsten nicht möglich wäre. Die Suche erfolgt in den innerhalb der Teilkonfiguration in den Ersetzungsregeln festgelegten Ressourcen gemäß den in den Ersetzungsregeln definierten Textmustern . Diese Textmuster werden dann durch ebenfalls in den Ersetzungsregeln definierte parametrisierte Texte ausgetauscht, was in der visuellen Programmierumgebung nicht möglich wäre. d) Anpassungsdateien :
Dateien in produktspezifischen oder selbstdefinierten Formaten , in welchen Ersetzungsregeln für Werte von ausgewählten Attributen von ausgewählten Entitäten der Teilkonfiguration beschrieben werden. Die Namen der Entitä- ten und die Werte der Attribute können durch Instanz- und Installationsparameter parametrisiert werden . Falls Anpassungsdateien aus der visuellen Programmierumgebung heraus erzeugt werden , wird diese Parametrisie- rung mit exportiert. Darüber hinaus kann die Parametrisierung auch direkt in den Anpassungsdateien der Schablone erfolgen. In den Installationsskripten werden die Anpassungsdateien schließlich verwendet, um die Konfiguration der Anwendung an die umgebungsspezifischen Parameter anzupassen ; wie dies geschehen muss, hängt von den vorhandenen APIs des Softwaresystems ab. Auch hier werden die Dateien vom Zusammenbau- Automaten ausgelesen und die Anweisungen verwendet, um gezielt nach vorgegebenen Zeichenketten zu suchen und diese geeignet zu ersetzen . e) Installationsskripte:
Der Zusammenbau-Automat bindet diese Skripte als Unterroutinen in die Installations- und Deinstallationsprogramme der Konfiguration in einer Ab- laufumgebung ein , indem er diese bei der Paketierung neben dem Installationsprogramm ablegt. Bei der Installation einer neuen Anwendung werden diese Installationsskripte vom Installationsprogramm iterativ, innerhalb einer Transaktion, ausgeführt.
f) weitere Ressourcen :
Weitere, optionale Dateien , die einen logischen Bezug zu den Schablonen haben . Sie werden inklusive ihres Dateinamens parametrisiert, um durch den Zusammenbau-Automaten Kopien in einem Zielordner zu erzeugen . Damit können z. B. Dokumentationsbausteine für Handbücher für die Schablonen automatisiert erzeugt werden. Auch auf diesen Dateien werden vom Zusammenbau-Automaten entsprechende Ersetzungsregeln angewendet, um die Dateien auf die neue Konfiguration anzupassen.
Eine vorteilhafte Ausführung des Verfahrens ermöglicht es, auch solche Zeichenketten bzw. Ressourcen für eine Wiederverwendbarkeit der Software anzupassen , die in der zugrunde liegenden Konfiguration der Standardanwendung nicht parametrisierbar angelegt sind. Solche Zeichenketten oder Ressourcen werden parametrisierbar gemacht, indem in den Schablonen für die nichtparametrisierba- ren Zeichenketten bzw. Ressourcen Manipulationen in Form von Anweisungen zur Durchführung von Such- und Ersetzungsregeln durch einen Text und/oder Binär- Datenstrom-Editor definiert werden . Diese Anweisungen sorgen dafür, dass beim Kopiervorgang durch den Zusammenbau-Automaten innerhalb der Teilkonfigurati- on der Schablone interne Dateien und/oder Teile darin gefunden und passend ersetzt werden. Hierfür werden diesen Dateien bzw. Teilen der Dateien neue Dateien bzw. Dateiinhalte zugewiesen . Die hierbei verwendeten Such- und Ersetzungsregeln enthalten reguläre Ausdrücke. Darin ist der Ort der bei der Instanziierung gegebenenfalls zu ersetzenden Datei genauso enthalten wie die Suchregel für eine gegebenenfalls zu ersetzende Text- oder Binärpassage bzw. für eine Komplettersetzung der ganzen Datei, falls dies erforderlich ist. Weiterhin enthalten die regulären Ausdrücke auch den Namens des Instanzparameters, welcher die Referenz auf die Datei enthält, die den gesuchten Inhalt ersetzt.
Die Dateien basieren auf einer formalen Sprache, z. B. einem Skript auf Basis des Befehlssatzes des U nix-Werkzeugs "sed" (Stream EDitor) . Diese Dateien können parametrisiert werden . Um die Softwarekonfiguration effizient wiederverwenden zu können ist es vorteilhaft, wenn erfindungsgemäß auch die Installation und Deinstallation zugehöriger Komponenten bereits vorbereitet wird .
Hierfür werden Installationsskripte und Installationsparameter mit separatem Namensraum und eigener formaler Sprache verwendet. Da Schablonen mehrfach verwendet werden können , müssen Installationsparameter eindeutig gemacht werden , indem Werte von Instanzparametern einen Teil der Installationsparameternamen bestimmen . Weiterhin werden zu den Schablonen passende Installations- und Deinstallationsskripte erstellt, in denen die für eine Konfiguration erforderlichen Referenzen zu externen Entitäten und/oder Ressourcen bei der Instanziierung automatisiert angelegt und/oder entfernt werden. Schließlich ist es erforderlich , die Konfiguration zum I nstallationszeitpunkt an die Umgebung, in die installiert wird , anzupassen. Die Installationsskripte verwenden hierfür Anpassungsdateien , in denen die Parametrisierung der Instanzparameter durch den Zusammenbau-Automaten während der Baustein-I nstanziierung aufgelöst wird . Bei der Installation werden die Installationsparameter dann entsprechend aufgelöst, indem sie durch die konkreten Werte ersetzt werden . Besonders vorteilhaft ist es, wenn bei der Erstellung einer neuen Anwendung für den Zusammenbau-Automaten ein Projekt mit einer Projektkonfiguration angelegt wird . Die Konfiguration besteht aus einer Reihe von Bausteinen , die jeweils einer Anweisung zur Instanziierung einer vorhandenen Schablone entspricht. Diese Bausteine müssen alle erfasst und in einer Projektkonfigurationsbeschreibung aufgelistet werden . Die Eigenschaften der Bausteine werden jeweils in eigens angelegten Eigenschaftsdateien beschrieben , welche die Namen und Werte für die zugehörigen Instanzparameter enthalten , die bei der Instanziierung verwendet werden , um die vorbelegten Werte zu überschreiben. Diese Werte werden bei der Ausführung des Zusammenbau-Automaten verwendet, um die in der Schablone vorhandenen Platzhalter zu ersetzen.
Um die Bausteine geeignet zu organisieren wird zu jedem Baustein ein eigenes Verzeichnis angelegt, in das die Dateien bzw. Ressourcen abgelegt werden, die in den Ersetzungsregeln der Schablonen verlangt werden .
Von dem Zusammenbau-Automaten werden dann die Bausteine mit den zugehörigen Ressourcen aus den Schablonen erzeugt und im Zielverzeichnis des Projekts abgelegt. Dabei werden alle Instanzparameter und/oder Funktionen für die neue Teilkonfiguration geeignet gesetzt, so dass eine zusammengesetzte, installationsfähige Anwendung (Konfiguration) entsteht.
Ansprüche 7 bis 1 2 beschreiben einen Datenträger mit darauf gespeicherten Daten oder eine für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge, wobei die Daten ein Programm zum Ablauf auf einer Datenverarbeitungsanlage darstellen , welches die in den Ansprüchen 1 bis 6 beschriebenen Verfahrensansprüche umsetzen, wenn das Programm auf einem Computer, Computernetzwerk oder über das Internet ausgeführt wird . Zur Vermeidung von Wiederholungen wird hinsichtlich dieser Anspruchsgegenstände im Wesentlichen auf die zuvor beschriebenen Ausführungen zu den Ansprüchen 1 bis 6 verwiesen.
Anspruch 13 beschreibt ein Computerprogramm mit Programmcode zur Durchführung aller Verfahrensschritte nach mindestens einem der Ansprüche 1 bis 6, wenn das Computerprogramm auf einem Computer, einem Computernetzwerk oder über das Internet ausgeführt wird . Unter einem Computerprogramm ist eine maschinen- les- und ausführbare Befehlsfolge zu verstehen, welche durch Speicherung , z. B. auf einem Datenträger oder in einem flüchtigen oder nichtflüchtigen Speicherbaustein eines Computers, oder durch Signale, die über das Internet versendet werden , verkörpert ist. Dabei braucht das Computerprogramm nicht in einer unmittelbar ausführbaren Form vorzuliegen ; es kann auch in einer für die Installation auf einem Benutzerrechner vorbereiteten Form vorliegen.
Anspruch 14 beschreibt eine Rechneranlage, die so eingerichtet ist, dass sie einen Datenträger mit darauf gespeicherten Daten oder eine für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge verwendet, wobei die Daten ein Computerprogramm mit Programmcode gemäß Anspruch 13 darstellen und die Rechneranlage das Computerprogramm gemäß den in den Ansprüchen 1 bis 6 beschriebenen Merkmalen ausführt. Auch hier wird zur Vermeidung von Wiederholungen im Wesentlichen auf die zuvor beschriebenen Ausführungen zu den Ansprüchen 1 bis 6 verwiesen .
Die Erfindung wird im Folgenden anhand mehrerer Figuren und einem Ausführungsbeispiel näher erläutert. Die Figuren 1 bis 4 zeigen Ablaufdiagramme einer beispielhaften Ausgestaltung der Erfindung , während die Figuren 5 bis 1 8 erläuternde Screenshots aus einer zugehörigen visuellen Programmierumgebung zeigen .
Die Figur 1 zeigt ein Ablaufdiagramm , welches ein beispielhaftes Projekt vom Erstellen einer geeigneten Umgebung zur Verwendung der entsprechenden Schablonen bis hin zum Installationspaket einer neuen , aus wiederverwendeten Konfigurationskomponenten zusammengesetzten Software darstellt und somit den beispielhaften Programmablauf des Zusammenbauautomaten in einem Projekt beschreibt.
Fig . 2 zeigt ein Ablaufdiagramm für die in Figur 1 genannte Baustein- Instanziierung , d. h . die Ersetzung der Parameter der Schablonen mit geeigneten Inhalten . Nach Durchführung der Instanziierung wird das Ablaufdiagramm in Fig . 1 ab dem Punkt„Baustein b im Arbeitsverzeichnis" fortgesetzt. Fig . 3 zeigt eine detailliertere Darstellung des ersten Arbeitsschritts des in Fig . 2 genannten Vorgangs der Erstellung einer Arbeitskopie. Nachdem die Arbeitskopie erstellt wurde, wird das Ablaufdiagramm in Fig . 2 ab dem Punkt„Arbeitskopie des Bausteins b" fortgesetzt.
Fig . 4 zeigt eine Darstellung des in Fig . 1 genannten vorletzten Arbeitsschritts „Paketierung" als detaillierteres Ablaufdiagramm . Nachdem die Paketierung durchgeführt wurde, wird das Ablaufdiagramm in Figur 1 ab dem vorletzten Punkt „Installationspaket der Anwendung" fortgesetzt.
Wie in Fig . 1 dargestellt, beginnt eine erfindungsgemäße Wiederverwendung einer ausführbaren Softwarekonfiguration mit einer grundlegenden Projektfestlegung . Nach der Parametrisierung des Programms mit den Datenablageorten für das Projekt und der Schablonenbibliothek wird die Projektkonfiguration inklusive der Projektparameter geladen . Danach wird für jeden der in der Projektkonfigurationsbeschreibung definierten Bausteine die Instanziierung aus der ihm zugewiesenen Schablone durchgeführt. Am Ende wird die Paketierung der fertigen Bausteine zu einem Installationspaket entsprechend Figur 4 durchgeführt, was weiter unter erläutert wird .
Um die Instanziierung für einen Baustein jeweils durchzuführen, wird eine Liste der Instanzparameter für den Baustein aus der Eigenschaftsvorbelegungs-Datei der Schablone, der Eigenschaftsdatei der Bausteinkonfiguration und den Projekt- und Baustein-Eigenschaften der Projektkonfigurationsbeschreibung gebildet. Danach wird jeweils der Programmablauf entsprechend Figur 2 durchgeführt, welches mit der Erstellung einer Arbeitskopie entsprechend Figur 3 beginnt.
Der Ablauf zur Erstellung einer Arbeitskopie in Figur 3 dient dazu eine Struktur anzulegen, die sowohl bei der Instanziierung des Bausteins als auch in der Paketierung genutzt wird . Die Struktur besteht aus der ausgepackten Teilkonfiguration, den Ersetzungsregeln , Anpassungsdateien und Installationsskripten sowie weiteren Ressourcen . Wie das Auspacken der Teilkonfiguration, genauso wie das spätere Einpacken , umzusetzen ist, hängt vom Exportformat ab, welches durch das Softwaresystem vorgegeben ist; oft werden jedoch Standardformate für Archive als Exportformat verwendet. Nachdem die Arbeitskopie erstellt ist, wird der Ablauf in Figur 2 damit fortgesetzt, dass in der Arbeitskopie eine Suche nach Parametern durchgeführt wird, um sie durch Ihren Wert zu ersetzen . Diese Parameter sind Instanzparameter und Funktionen , aber keine Installationsparameter. Die Suchgeschwindigkeit kann optimiert werden , indem Binär-Dateien mit bekanntem Typ, der z. B. am Suffix des Dateinamens erkannt wird , übersprungen werden , wenn bekannt ist, dass dort keine Ersetzungen vorgenommen werden . Konnte die Ersetzung nicht vollständig durchgeführt werden , so dass in der Arbeitskopie noch Instanzparameter vorkommen , welche nicht in der Liste der Instanzparameter vorhanden sind oder Funktio- nen mit unbekanntem Funktionsnamen oder unbekannter Signatur vorhanden sind oder deren Auswertung fehl schlägt, so ist eine Fehlermeldung für den Softwareentwickler auszugeben und das Programm zu beenden . Ist die Funktion eine Transklusion, so erfolgt die Auswertung rekursiv. Andere Funktionen können verwendet werden , müssen aber durch den Zusammenbau-Automaten angeboten und an dieser Stelle vollständig aufgelöst d . h. durch Ihren Wert ersetzt werden. Anschließend werden die Ersetzungsregeln auf der Teilkonfiguration in der Arbeitskopie ausgeführt, wobei die in den Regeln definierten Bestandteile der Teilkonfiguration mit den definierten Bestandteilen der Dateien (Ressourcen) aus der Bausteinkonfiguration ersetzt werden. Ist die Ersetzung vollständig , so ist der Baustein bereit für die Paketierung . Diese erfolgt nachdem dieser Ablauf für alle Bausteine abgeschlossen ist.
Die Paketierung wird in Figur 4 beschrieben , und beschreibt die Erzeugung eines Installationspakets für die erzeugten Bausteine. Dafür ist zunächst das Zielver- zeichnis zu erstellen, welches am Ende in einem Archiv verpackt wird . Dabei werden auch Basisinstallationsskripte hineinkopiert, welche vom Zusammenbau- Automaten bereitzustellen sind . Diese Skripte müssen in der Lage sein , eine generelle Installation von Bausteinen im Softwaresystem durchzuführen, die wie folgt beschrieben abgelegt werden. Diese Ablage erfolgt indem die Teilkonfigura- tionen, Installationsskripte (Baustein-spezifisch) inklusive Anpassungsdateien und weitere Ressourcen (insofern vorhanden) im Zielverzeichnis so abgelegt werden, dass sie von den Basisinstallationsroutinen gefunden und die Bausteine bei der Installation im Softwaresystem installiert werden Im folgenden Beispiel ist eine erfindungsgemäße Umsetzung mit der Software Oracle Service Bus beschrieben . Die Software unterstützt die Entwicklung und den Betrieb von Integrationsstrecken im Business-to-Business (B2B) oder Enterprise Application Integration (EAI)-Umfeld.
Eine solche Integrationsstrecke (Datenübertragung) kann zum Beispiel Daten von einer Anwendung A entgegennehmen, danach ggf. filtern, umwandeln, modifizieren , etc. und an weitere Anwendungen B und C weiterleiten . Die Software unterstützt den Parallel-Betrieb solcher Integrationsstrecken (d. h. mehrere Anwendungen/Konfigurationen) . Der grundlegende, übliche Ansatzpunkt bei der Entwicklung einer Software unter Verwendung von Schablonen liegt in der Erkenntnis, dass sich solche Lösungen (hier Integrationsstrecken) zwar fachlich unterscheiden , jedoch unter gewissen technischen Gesichtspunkten ähneln. Durch Abstraktion können technische Lösungsmuster gefunden werden , die sich zur Entwicklung von Schablonen eignen. Je mehr sich das Verhalten abstrahieren lässt, desto allgemeiner einsetzbar und somit wertvoller sind solche Schablonen.
Hat man beispielsweise mehrere Integrationsstrecken, die Ihre Daten per WSDL- WebService entgegennehmen sollen, so kann man für das technische Problem des Integrationsstils „XML Nachrichten per WSDL WebService entgegennehmen" ein abstraktes technisches Lösungsmuster als Schablone verwenden:
1 . Programmierung einer Schablone In der visuellen Programmierumgebung wird zunächst eine Struktur angelegt.
Die Instanzparameternamen werden in diesem Beispiel durch die Zeichenkette XXX eingeschlossen, um das Verfahren transparent für die visuelle Programmierumgebung zu gestalten . Die Eingaben erfolgen über Textfelder. Auf der obersten Ebene wird ein Verzeichnis „XXXprojectnameXXX" angelegt, in dem künftige Integrationsstrecken liegen werden . Der Wert wird später im Projekt festgelegt. Jede Anwendung wird dadurch nach der Installation ihren eigenen Ordner bekommen und von anderen Anwendungen getrennt.
Auf der zweiten Ebene wird ein Verzeichnis „XXXcomponentnameXXX" angelegt, s. Fig. 5, in welcher später die Bausteine (Teile) der jeweiligen Anwendung liegen werden und von anderen Bausteinen der Anwendung getrennt werden, selbst wenn sie auf der gleichen Schablone beruhen .
Es wird ein Zusammenbau-Automat erstellt, der so eingerichtet ist, dass er alle zur Erstellung einer neuen Software automatisierbaren Vorgänge zusammenfasst und durchführt.
Der Zusammenbau-Automat wird so eingerichtet, dass er zunächst die Werte der Instanzparameter "projectname" und "componentname" für jeden Baustein durch den Algorithmus vordefiniert festlegt.
Auf der dritten Ebene wird für jede Schablone ein Verzeichnis mit dem Schablonennamen angelegt, um die Schablonen getrennt voneinander entwickeln zu können. Im Beispiel wird eine Eingangsschnittstellen-Schablone für WSDL- WebServices unter dem Namen „WSInboundAdapter" erstellt. Eine weitere Eingangsschnittstellen-Schablone für Dateiempfang und zwei Ausgangsschnittstellen-Schablonen für den Versand per WSDL oder Datei werden erstellt (s. Fig . 6). Am Ende wird es möglich sein, jeweils einen Baustein basierend auf einer Eingangsschnittstellen-Schablone wahlweise mit einem Baustein basierend auf einer der beiden Ausgangsschnittstellen-Schablonen zu koppeln .
Nun werden unter diesen Verzeichnissen die wesentlichen Entitäten angelegt.
Bei WSInboundAdapter:
Eine WSDL-Datei mit einer Schnittstellenspezifikation und
- Ein ProxyService, welcher die Konfiguration der Eingangsschnittstelle und die Programmierung der Servicefunktionalität beinhaltet, und die zuvor genannte WSDL-Datei verwendet (s. Fig. 7).
Die Eingabe der eben erwähnten WSDL-Festlegungen erfolgt über die visuelle Programmierumgebung , s. Fig. 8.
Da die Eingabe für jeden Baustein individuell festgelegt werden soll, ist nun an Stelle der WSDL-Datei eine Transklusionsfunktion, z. B: "XXXimportYYYwsdl- filenameXXX", zu parametrisieren. Hierfür ist es erforderlich, dass die visuelle Programmierumgebung die Parametri- sierung unterstützt. In unserem Beispiel sei dies jedoch nicht der Fall.
Hier wird die Transklusion nun ersatzweise mit Hilfe von Ersetzungsregeln umgesetzt und in der Teilkonfiguration nur ein Platzhalter verwendet, welche dann später bei der Erzeugung des Bausteins durch den Zusammenbau-Automaten durch Anwendung der Ersetzungsregeln und Transklusion ausgetauscht wird .
Die Transklusion könnte alternativ auch in einer Anpassungsdatei oder in einer Platzhalterdatei für ein Installationsskript definiert werden , welches ein API anspricht, ohne die Erfindung zu verlassen .
Nach der Anwendung der Ersetzungsregeln beinhaltet die Schablone die in Fig . 9 dargestellten Entitäten.
Die visuelle Programmierung des Proxy-Service zerfällt in 2 Abläufe (Pipelines) für den Nachrichtenfluss, in die Anforderung (request) und die Antwort (response), s. Fig . 10. Die eingehende Seite für diese Abläufe wird durch die Wahl des technischen Protokolls, hier WSDL/SOAP/http, bei der Erzeugung des ProxyService festgelegt (in Fig . 1 0 „Service" genannt) . Die ausgehende Seite soll mit dem nächsten Baustein kommunizieren. Hierfür wird der Nachrichtenfluss am Ende (s. „Rou- teNodel " in Fig 1 0) des ProxyService mit "Dynamischem Routing" so eingerichtet, dass der nächste Baustein mit H ilfe seines Bausteinnamens und des Schablonennamens lose angekoppelt wird (s. Fig . 1 1 ).
Der Name wird daher durch die Instanzparameter "outboundcomponent" und "outboundtemplate" parametrisiert (s. Fig . 1 2).
Zur Vereinfachung wird hier das interne Standardprotokoll (SOAP) verwendet. Innerhalb der beiden oben beschriebenen Nachrichtenfluss-Pipelines könnten z. B. noch generalisierbare Aktionen, wie Protokollierung , Normalisierung , Validierung etc. eingerichtet werden .
2. Anlegen der Schablonen in der Schablonenbibliothek Nun wird ein Verzeichnis für die Schablonenbibliothek erstellt. Darunter wird ein Verzeichnis mit dem Schablonennamen„WSInboundAdapter" erstellt.
a) In der visuellen Programmierumgebung werden nun ohne Abhängigkeiten die Ressourcen der Schablone in dieses Verzeichnis unter dem vorgegeben Dateinamen „sbconfig .jar" exportiert (s. Fig . 13), einem Standardformat für Archive als Exportformat. b) Anschließend wird für die exportierten Ressourcen unter dem vorgegeben Dateinamen „ALSBCustomizationFile.xml" im gleichen Verzeich nis eine Anpassungsdatei erzeugt (s. Fig . 14).
Die Anpassungsdatei wird nun noch parametrisiert, indem alle Werte, die darin vorkommen und umgebungsabhängig sind oder im Baustein
individuell konfiguriert werden sollen, editiert werden .
Bei der hier beispielhaft verwendeten Schablone ist dies nicht notwendig . Ein Beispiel hierfür folgt jedoch weiter unten . c) Die "Ersetzungsregel"-Datei muss nun , wie zuvor erwähnt, eine Regel enthalten, den WSDL-Platzhalter zu ersetzen . Hierzu wird die Struktur der exportierten Teilkonfiguration berücksichtigt und ggf. analysiert. Sie liegt im Beispiel als jar-Datei vor, welches technisch einem ZIP-Archiv entspricht. Innerhalb dieses Archivs ist die WSDL-Datei abgelegt innerhalb von "XXXprojectnameXXX\XXXcomponentnameXXX\WSInboundAdapter\ InterfaceDefinition .WSDL". Innerhalb dieser Datei ist der WSDL-Platzhalter eingebettet. Die Regel wird nun so aufgestellt, dass der Zusammenbau- Automat den Platzhalter (per Mustersuche, z. B. nach : "<wsdl:definitions *</wsdl:definitions> ") findet und durch die Transklusionsfunktion "XXXim- portYYYwsdlfilenameXXX" ersetzt. d) Eigenschafts-Vorbelegungs-Datei
In der Schablone wurde die Variable wsdlfilename eingeführt. Diese wird in die Eigenschafts-Vorbelegungs-Datei (im Java Properties Format) aufgenommen und ihr ein Standard-Wert zugeordnet: wsdlfilename=definition.wsdl Da der Instanzparameter innerhalb der Transklusion als Referenz auf einen Dateinamen verwendet wird , hat das zur Konsequenz, dass diese Datei in der Bausteinkonfiguration , die weiter unten beschrieben wird,
bereitzustellen ist.
Die anderen Schablonen werden analog angelegt.
Die Schablone XMLFilelnboundAdapter löst das technische Problem des Integrationsstils „XML Nachrichten per Dateischnittstelle entgegennehmen". Dazu wird der ProxyService etwas anders konfiguriert, und die WSDL entfällt (s. Fig. 1 5) .
Der Endpunkt-URI (Uniform Resource Identifier) referenziert das Verzeichnis, aus dem die Nachrichtendateien eingelesen werden. Dieses wird in der Anpassungsdatei parametrisiert, indem der zugehörige Eintrag vom Entwickler gesucht und verändert wird.
Die Anpassungsdatei vor der Editierung ist in Fig . 16 dargestellt, nach der Editierung in Fig . 17. Der Instanzparameter "filepath" wird in diesem Beispiel in der Eigenschafts- Vorbelegungs-Datei auf eine Vorbelegung eingestellt. Da die Schablone aber mehrfach verwendet werden kann , muss es in der Eigenschafts-Datei des Bausteins verschiedene Wertzuweisungen geben, da ansonsten Plausibilitätsregeln der Software verletzt werden . Das wird hier bei der Entwicklung der Schablonen berücksichtigt, indem die Wertzuweisung durch "componentname" parametrisieriert wird. Zugleich kann dieser Wert auch noch zum I nstallationsparameter erweitert werden . Folgender Eintrag in der Eigenschafts-Vorbelegungs-Datei wird in diesem Beispiel als Zuweisung verwendet: filepath =@XXX componentnameXXX. filepath®
Die Schablonen "WSOutboundAdapter" und "XMLFileOutboundAdapter" versenden Nachrichten. Sie werden grundsätzlich analog eingerichtet, wobei das ausgehende Protokoll in einer hier nicht in den Figuren dargestellten Ressource "BusinessService" konfiguriert wird. Der ProxyService wird, um Nachrichten von den Eingangsschnittstellen-Schablonen empfangen zu können, unter dem Namen "Service" wie in Fig . 18 dargestellt konfiguriert.
3. Erstellen eines Projekts
Zur Steuerung des Zusammenbau-Automaten wird ein Projekt mit einer Projektkonfiguration erstellt.
Mit dem Projekt, das in diesem Beispiel " Examplel " genannt wird , soll beispiel- haft eine Software erzeugt werden, die eine XML-Nachricht per WSDL entgegennimmt und im Verzeichnis "/transfer/out/" ablegt. Hierzu wird ein Baustein A auf Basis des "WSInboundAdapter" erstellt und mit einem Baustein B auf Basis des "XMLFileOutboundAdapter" gekoppelt. Es ist ein Projektverzeichnis "Example l " anzulegen ; danach folgen weitere Arbeitsschritte: a) Im Projektverzeichnis wird eine Projektkonfigurationsbeschreibung unter dem Namen project.xml angelegt. Es handelt sich hierbei um eine beispiel- hafte, fiktive Syntax, die vom Zusammenbau-Automaten verstanden wird :
<project: Project xmlns: module="project.xsd" projectname="Example 1 "> <component componentname="A">
<template>WSInboundAdapter</template>
</component>
<component componentname="B">
<template>XMLFileOutboundAdapter</template>
</component>
</project> b) Im Projektverzeichnis wird eine Eigenschafts-Datei für jeden Baustein angelegt, z. B. für Baustein A als "A. properties": outboundcomponent=B # Name des Folgebausteins outboundtemplate=XMLFileOutboundAdapter # Typ (Schablone) wsdlfilename=definition.wsdl # Name der WSDL Datei c) Im Projektverzeichnis werden Verzeichnisse mit zu importierenden Ressourcen angelegt; z. B. für Baustein A ein Verzeichnis "A" in dem die WSDL-Datei definition .wsdl liegt.
4. Ausführen des Zusammenbau-Automaten
Der Zusammenbau-Automat wird ausgeführt und erzeugt erfindungsgemäß ein Installationspaket, in dem ein wIst-Script liegt, welches so eingerichtet ist, dass es die erzeugten Baustein-Teilkonfigurationen und die Anpassungsdateien , welche ebenfalls im Installationspaket liegen, innerhalb einer Transaktion installiert.
Das wIst-Script wird mit dem Weblogic Scripting Tool des Softwaresystems Oracle Service Bus gestartet.
Glossar
Datei - Ein Bestand meist inhaltlich zusammengehöriger Daten und Software- Ressourcen , der auf einem Datenträger oder Speichermedium gespeichert ist. In diesem Kontext spielt die gewählte Form der Persistenz eine untergeordnete Rolle und Begriffe wie Datei, Verzeichnis und Ressource werden zur Veranschaulichung gewäh lt; es muss sich nicht um eine Ablage in Verzeichnissen eines Dateisystem handeln, sondern könnte z. B. auch in Datenbanken persistiert werden .
Entität - Den Softwarekonfigurationen der Softwaresysteme liegt ein Datenmodell zugrunde, in denen eine konkrete Konfiguration an Entitäten des Softwaresystems und deren Beziehungen zueinander beschrieben werden. Erstellungsprozess - Ein Erstellungsprozess bezeichnet in der IT einen Vorgang , durch den ein fertiges Anwendungsprogramm automatisch erzeugt wird. Der Zusammenbau-Automat setzt diesen Vorgang erfindungsgemäß im Kontext von Standardanwendungssoftware um. Exportieren - Vorgang, bei dem eine Softwarekonfiguration ggf. transformiert und danach in einer Datei oder einem Repository abgespeichert wird , um diese zu einem anderen Zeitpunkt wieder zu importieren oder anderweitig , z. B. hier im Zusammenbau-Automaten , zu verwenden. Formale Sprache - In diesem Kontext wird eine geeignete formale Sprache benötigt, in der Parameter und Funktionen definiert werden können, die eine Unterscheidung zu restlichen Zeichenketten regelt und ein eindeutiges Maschinenverhalten der visuellen Programmierumgebung und des Zusammenbau- Automaten herbeiführt. In der visuellen Programmierumgebung müssen Validie- rungen bei Angabe von Parametern und Funktionen abgeschaltet werden. Vom Zusammenbau-Automaten werden die Parameter und Funktionen ausgewertet.
Funktion - Funktionen in diesem Kontext sind parametrisierbare Anweisungen zur Ausführung vordefinierter Routinen des Zusammenbau-Automaten , die einen Wert zurück liefern , der wie ein Instanzparameter verwendet werden kann. Funktionsparameter - Funktionsparameter sind Werte, Instanzparameternamen oder Entitätsnamen, die als Argument einer Funktion direkt verwendet werden.
Generische Programmierung - ist ein Verfahren zur Entwicklung wiederverwend- barer Software-Bibliotheken . Dabei werden Funktionen möglichst allgemein entworfen, um für unterschiedliche Datentypen und Datenstrukturen verwendet werden zu können .
Wesentlich bei der generischen Programmierung ist, dass die Algorithmen nicht für einen bestimmten Datentyp geschrieben werden , sondern nur bestimmte Anforderungen an die Typen stellen . Das Prinzip wird auch parametrische Polymorphie genannt.
Die Implementierung erfolgt normalerweise durch das Konzept generischer Typen bzw. Templates. In diesem Kontext wird dies jedoch durch Transklusion mit Schemasprachen erreicht.
Instanziierung - In Anlehnung an die objektorientierte Programmierung wird in diesem Kontext unter Instanziierung die Erzeugung einer konkreten Teilkonfiguration aus einer bestimmten Schablone verstanden. Diese Form der Instanziierung wird zunächst durch den Programmierer über die visuelle Programmierumgebung des Softwaresystems gedanklich und handwerklich vorbereitet und später durch den Zusammenbau-Automaten physikalisch durchgeführt. Die Konkretisierung erfolgt durch Übergabe einer Konfiguration der Instanzparameter und die verwendeten Schablonen, die dem Zusammenbau- Automaten übergeben werden .
Bei der Vorbereitung der Instanziierung durch den Entwickler ist zu beachten, dass Schablonennamen und alle Entitäten der Schablone so auf die Instanziierung vorbereitet werden , dass nach der Durchführung der Instanziierung und der Installation verschiedene Instanzen (Teilkonfigurationen) einer Schablone konfliktfrei koexistieren können . Ist dies der Fall, gilt die Schablone als instanzi- ierbar.
Das Entitätenmodell und der Namensraum des Softwaresystems müssen diese Vorgänge grundsätzlich hergeben . Das Softwaresystem soll so gestaltet werden können, dass der Entwickler diese Vorbereitung durch die visuelle Programmierumgebung vornimmt, welche dies entweder direkt unterstützt, zumindest aber indirekt zulässt. Instanzparameter - Instanzparameter werden hier Parameter einer Schablone bezeichnet, deren Wert bei Durchführung der Instanziierung durch den Zusammenbau-Automaten fest eingestellt werden , wodurch die daraus resultierenden Teilkonfigurationen frei von Instanzparametern werden sollen . Instanzparameter sollen auch im Namen der Schablone verwendet werden , um Teilkonfigurationen instanziierbar zu machen .
Installationsparameter - Installationsparameter sind Parameter, die sowohl in Schablonen als auch noch später, in den durch den Zusammenbau-Automaten erzeugten Teilkonfigurationen und zugehörigen Ressourcen, vorhanden sein können. Sie werden erst bei der Installation durch das Installationsprogramm fest eingestellt. Installationsparameternamen können durch Instanzparameter und Funktionen ihrerseits parametrisiert werden , so dass auch Installationsparameter durch die Instanziierung vervielfältigt werden.
Lose Kopplung - bezeichnet in diesem Kontext einen geringen Grad der Abhängigkeit der Bausteine voneinander, der durch Parametrisierung der Referenzen untereinander und die Abstraktion der Schnittstellendefinitionen durch Parametrisierung erreicht wird .
Namensraum - In diesem Kontext sind Namensräume für Entitäten der Teilkonfigurationen und Parameter relevant. Diese sind über Pfadnamen eindeutig identifizierbar und in eine H ierarchie eingeordnet. Packen/Auspacken - Falls Teilkonfigurationen aus Dateiarchiven bestehen , kann die Durchführung einiger besonderer Funktionalitäten wie die Operation auf Einzeldateien des Archivs erfordern , was ein vorübergehendes Auspacken des Dateiarchives erfordert. Parameter - Parameter werden im Rahmen der üblichen Begrifflichkeit verwendet. Sprachlich wird hier unterschieden zwischen Instanzparameter, Funktionsparameter und Installationsparameter.
Schablone - Schablonen in diesem Kontext sind vorgefertigte Komponenten, die als Entwurfsmuster für Wiederverwendung von Konfigurationen ausgelegt werden. Sie dienen als konkreter Bauplan für die Erzeugung bzw. Instanziierung ähnlicher Teilkonfigurationen mittels eines Zusammenbau-Automaten . Schablonen können miteinander in hierarchischen Beziehungen stehen und zu komplexen Strukturen zusammengesetzt werden. Das Konzept hat daher eine gewisse Ähnlichkeit zu Klassen, beinhaltet aber von sich aus keine Objektorientierung . Schablonen bestehen mindestens aus jeweils einer exportierten Teilkonfiguration und ggf. weiteren Dateien/Ressourcen .
Schablonenbibliothek -Schablonenbibliotheken entsprechen einer Komponentenpalette, wobei die Komponenten der Bibliothek Schablonen im o.g . Sinne sind. Durch eine hinreichende Menge an Schablonen in der Bibliothek wird Rapid Application Development ermöglicht. Weil eine logische Abhängigkeit der Teilkonfigurationen von Ihren Schablonen existiert, kann dies zur Umsetzung von kontinuierlicher Integration genutzt werden, indem Teilkonfigurationen automatisch neu erzeugt werden, wenn Ihre Schablonen überarbeitet wurden .
Schemasprache - Eine Sprache zur Klassifizierung von XML-Dokumenten, wie XSD, und darauf basierenden Standards, wie dem Schnittstellenstandard WSDL oder Abfragesprachen wie XPath und Xquery. In diesem Kontext wird diese Auszeichnungssprache als Beispiel für jede andere existierende oder künftige Auszeichnungssprache genannt.
Signatur - Schnittstelle einer Funktion, gekennzeichnet durch den Funktionsnamen , gefolgt von den Funktionsparametern . Softwarekonfiguration - Eine Programmdatei, die durch das Softwaresystem , ähnlich wie ein Computerprogramm, ausgeführt werden kann . Außerdem muss es möglich sein, diese zu komplexeren Konfiguration zusammenzufügen (Aggregation) , bzw. wieder in ihre Teilkonfigurationen zu zerlegen. Softwaresystem - Hiermit ist eine Sammlung von Softwareprodukten gemeint, welche zur Ausführung einer Softwarekonfiguration geeignet sind, insbesondere funktionsübergreifende Standardsoftware und Anwendungsserver.
Standardanwendung und Standardsoftware - Als Standardsoftware bzw. Standar- danwendungen werden Softwaresysteme verstanden, die einen klar definierten Anwendungsbereich abdecken und als vorgefertigte Produkte erworben werden können und nicht gezielt für den Einsatz bei einem Kunden bzw. Unternehmen entwickelt wurden.
Text-Datenstrom-Editor - Ein Werkzeug das zur Manipulation von Textdateien eingesetzt wird .
Textfelder und Textbereiche - Steuerelemente einer grafischen Benutzeroberfläche, die Benutzereingaben in Form von Zeichenketten in ein- und mehrzelligen Textfeldern aufnehmen können.
Trennzeichenkettenfolge - Ein oder mehrere aufeinanderfolgende Zeichen , die als Separator in einer Syntax verwendet werden , welche vom Zusammenbau- Automaten und/oder Installationsprogramm unterstützt wird, um Parameter und Funktionen zu definieren.
Transklusion - Funktion ähnlich einer Include-Präprozessor-Anweisung in Programmiersprachen, wo Inhalte aus anderen Dateien eingefügt werden. Dieser Vorgang kann mehrstufig sein , d . h. die Dateien , die eingefügt werden, können selbst wiederum in dieser erweiterten Form parametrisiert sein und Transklusi- onsanweisungen enthalten.
Visuelle Programmierumgebung - Eine integrierte Entwicklungsumgebung mit einer visuellen Entwicklungsoberfläche, mit der die Softwarekonfiguration programmiert werden kann , wobei nicht ein gegebenenfalls vorhandener textueller Editor betrachtet wird, in dem das Erstellen von Software mit einer herkömmlichen textuellen Sprache erfolgt. Die visuelle Darstellung in Form der visuellen Sprache steht dabei nicht im Fokus, sondern das damit verbundene Vorhandensein einer Graphischen Benutzeroberfläche, deren Komplexität über die Programmierung mit einer textuellen Sprache deutlich hinaus geht.

Claims

Patentansprüche
1 . Computerimplementiertes Verfahren zur Wiederverwendung von ausführbaren Softwarekonfigurationen für Softwaresysteme im Prozess der Entwicklung neuer Anwendungen für Rechneranlagen oder rechnergestützte Systeme, wobei ein Softwaresystem wenigstens eine Möglichkeit zum Exportieren und Importieren von Teilen seiner Konfiguration aufweist, wobei zu jedem wieder zu verwendenden Teil einer Anwendung mindestens eine Teilkonfiguration erstellt wird, welche sich für die Wiederverwendung in neuen Anwendungen eignet, wobei diese Teilkonfiguration als Bestandteil einer kopierfähigen Schablone exportiert wird , die vor dem Export mithilfe einer visuellen Programmierumgebung des Softwaresystems durch Einfügen von Instanzparametern instanziierbar gemacht wird und nach dem Export in mindestens einer Schablonen-Bibliothek aufbewahrt wird und bei der Erstellung einer neuen Anwendung von einem Zusammenbau-Automaten mit Hilfe von Such- und Ersetzungsregeln zu einer in der neuen Anwendung funktionsfähigen Teilkonfiguration instanziiert wird und mit anderen Teilkonfigurationen bzw. weiterem Anwendungscode automatisiert zusammengefügt wird , wodurch eine neue, ablauffähige Softwarekonfiguration und Anwendung entsteht, dadurch gekennzeichnet, dass in der visuellen Programmierumgebung mithilfe einer formalen Sprache die Namen und Attributwerte von Entitäten durch Parameterangaben mittels Eingaben in Textfeldern und Textbereichen bestimmt werden, wobei bei der Parametrisie- rung der auf den Schablonen basierenden Teilkonfigurationen innerhalb der visuellen Programmierumgebung anstatt eines Instanz-Parameters mit Hilfe der formalen Sprache auch Funktionsaufrufe angegeben wird, darunter mindestens eine Funktion als Anweisung an den Zusammenbau-Automaten zur Durchführung einer Transklusion angegeben wird , wobei die Signatur einer Funktion mindestens einen Funktionsparameter besitzt, der vom Zusammenbau-Automaten als Referenz auf eine Ressource und/oder Entität interpretiert wird, deren Inhalt bei der Instanziierung eingelesen wird , wobei der Inhalt der Ressource und/oder Entität seinerseits durch Instanz- Parameter und Funktionen parametrisiert sein kann, und nach Auflösung aller enthaltenen Instanz-Parameter und untergeordneten Funktionen schließlich als Wert der Funktion, analog einem Parameterwert, verwendet wird, und/oder eine Transklusion durch verkürzte Notation in Form einer Markierung von Entitäten und/oder Entitätswerten angewiesen wird , wobei durch die Markierung dem Benutzer über die visuelle Programmierumgebung angezeigt wird , ob die Entitätswerte mittels Parameter überschrieben werden müssen oder können .
Computerimplementiertes Verfahren zur Wiederverwendung von Softwarekonfigurationen für Softwaresysteme gemäß Anspruch 1 , wobei die formale Sprache so gewählt wird , dass dem Softwaresystem, inkl. der visuellen Programmierumgebung , die Verwendung der Instanzparameter und Funktionen transparent bleibt, indem
a. die Instanzparameter in der visuellen Programmierumgebung als gültige Zeichenketten modelliert werden, indem die Parameternamen mit Hilfe mindestens einer eindeutigen Trennzeichenkettenfolge von allen anderen Zeichenkettenfolgen unterschieden werden ,
b. die Funktionen in der Form modelliert werden, dass ihre Signatur als n-Tupel ausgestaltet ist, wobei mindestens eine eindeutige Trennzeichenkettenfolge den Funktionsaufruf von allen anderen Zeichenkettenfolgen abgrenzt und innerhalb des Funktionsaufrufs mindestens eine weitere, untergeordnete Trennzeichenkettenfolge den Funktionsnamen und die nachfolgenden Funktionsparameter jeweils eindeutig voneinander abgrenzt,
c. die Funktionsparameter des Funktionsaufrufs Instanzparameter sein können.
Computerimplementiertes Verfahren zur Wiederverwendung von Softwarekonfigurationen für Softwaresysteme gemäß einem der zuvor genannten Ansprüche, wobei innerhalb der Schablone, die ihrerseits innerhalb einer Schablonenbibliothek abgelegt wird, neben der Teilkonfiguration weitere Ressourcen abgelegt werden können , die somit Teil der Schablone sind, wobei diese Ressourcen bestehen können aus:
a. einer Eigenschafts-Vorbelegungs-Datei mit Vorbelegungen der Werte für die Instanzparameter, die vom Zusammenbau-Automaten in den Suche-/ Ersetzungsregeln alternativ verwendet werden , wenn entsprechende Werte in einer Eigenschafts-Datei nicht angegeben wurden , b. "Anpassungs"-Dateien , mit welchen umgebungsabhängige Installationsparameter konfiguriert werden können und vom Installationsprogramm bei der Installation verwendet werden , welche zuvor in der Schablone inklusive der Installationsparameter durch Instanzparameter parametrisiert werden können, worauf das Suchen/Ersetzen vom Zusammenbau-Automaten angewendet wird ,
c. einer "Ersetzungsregel"-Datei, welche Anweisungen zu Textmanipulationen enthält um die Funktion zur Durchführung einer Transklusion außerhalb der visuellen Programmierumgebung zu definieren, indem Suchen/Ersetzen auf der Teilkonfiguration vom Zusammenbau- Automaten angewendet wird , und die Anweisungen zur Textmanipulation auf der exportierten und gegebenenfalls ausgepackten Teilkonfiguration ausgeführt werden,
d . Installationsskripten für Installation und Deinstallation der Bausteine, auf welche vom Zusammenbau-Automaten Suchen/Ersetzen angewendet wird, wobei die Bausteine vom Installationsprogramm bei der Installation verwendet werden ,
e. optionalen Mustern weiterer Ressourcen mit logischem Bezug zu den Schablonen , auf welche vom Zusammenbau-Automaten Suchen/Ersetzen angewendet wird ,
f. einer komplementären Teilkonfiguration, welche die Weiterentwicklung der Teilkonfiguration der Schablone in der visuellen Programmierumgebung des Softwaresystems unterstützt, wobei diese auch Schablonen-übergreifend abgelegt werden kann.
Computerimplementiertes Verfahren zur Wiederverwendung von Softwarekonfigurationen für Softwaresysteme gemäß einem der zuvor genannten Ansprüche, wobei nichtparametrisierbare Zeichenketten und/oder Ressourcen der Standardanwendung parametrisierbar gemacht werden, indem in den Schablonen für die nichtparametrisierbaren Zeichenketten und/oder Ressourcen Manipulationen in Form von Anweisungen zur Durchführung von Such- und Ersetzungsregeln durch einen Text und/oder einen Binär- Datenstrom-Editor definiert werden , die dafür sorgen , dass beim Kopiervorgang durch den Zusammenbau-Automaten, innerhalb der Teilkonfiguration der Schablone interne Dateien und/oder Teile darin durch dem neuen Bau- stein zugewiesene Dateien und/oder Dateiinhalte ersetzt werden , wobei die Such- und Ersetzungsregeln reguläre Ausdrücke enthalten, bezüglich
a. des Orts der bei der Instanziierung zu ersetzenden Datei und/oder b. der Suchregel für eine zu ersetzende Text- oder Binärpassage oder für eine Komplettersetzung und
c. des Namens des Instanzparameters, welcher die Referenz auf die Datei enthält, die den gesuchten Inhalt ersetzt.
5. Computerimplementiertes Verfahren zur Wiederverwendung von Softwarekonfigurationen für Softwaresysteme gemäß einem der zuvor genannten Ansprüche, wobei die Installation und Deinstallation vorbereitet wird , indem :
a. Installationsskripte und Installationsparameter mit separatem Namensraum und eigener formaler Sprache verwendet werden, und der Wert eines Instanzparameters einen Teil eines Installationsparameternamens bestimmen kann, und
b. zu den Schablonen passende Installations- und Deinstallationsskripte erstellt werden, in denen die für eine Konfiguration erforderlichen Referenzen zu externen Entitäten und/oder Ressourcen bei der I nstanziierung automatisiert angelegt und/oder entfernt werden , und c. Anpassungsdateien über die Installationsskripte zur Anpassung der Konfiguration zum Installationszeitpunkt verwendet werden , wobei die Parametrisierung der Instanzparameter in den Anpassungsdateien beim Kopiervorgang über den Zusammenbau-Automaten aufgelöst wird , und bei der Installation die Installationsparameter aufgelöst werden .
6. Computerimplementiertes Verfahren zur Wiederverwendung von Softwarekonfigurationen für Softwaresysteme gemäß einem der zuvor genannten Ansprüche, wobei für den Zusammenbau-Automaten für die Erstellung einer neuen Anwendung ein Projekt mit einer Projektkonfiguration angelegt wird , wobei
a. das Projekt eine Projektkonfigurationsbeschreibung enthält, in der die Bausteine aufgelistet werden, aus denen die neue Konfiguration erstellt werden soll, wobei jeder Baustein einer Anweisung zur I n- stanziierung einer vorhandenen Schablone entspricht, und Projekt- Eigenschaften gelistet werden , die so gehandhabt werden, als würden die Einträge in der Eigenschafts-Datei jedes Bausteins stehen, und Baustein-Eigenschaften bei den Bausteinen gelistet werden, die so gehandhabt werden , als würden die Einträge in der Eigenschafts- Datei des jeweiligen Bausteins stehen,
b. zu jedem Baustein eine Eigenschafts-Datei mit Werten für die Instanzparameter als Teil der Anweisung angelegt wird, in der die Namen und Werte der zugehörigen Instanzparameter beschrieben werden , welche zuzüglich den Werten der Vorbelegungen verwendet werden und diese überschreiben, und durch Ausführung des Zusammenbau-Automaten die entsprechenden Platzhalter der Schablone ersetzen,
c. zu jedem Baustein bei Bedarf ein Verzeichnis angelegt wird , in dem sich Dateien (Ressourcen) befinden , die in Ersetzungsregeln der Schablonen verlangt werden,
wobei bei Ausführung des Zusammenbau-Automaten im Projekt- Zielverzeichnis die Bausteine mit den zugehörigen Ressourcen von dem Zusammenbau-Automaten aus den Schablonen erzeugt werden und alle Instanzparameter und/oder Funktionen für die neue Teilkonfiguration geeignet gesetzt werden , und somit eine zusammengesetzte, installationsfähige Anwendung (Konfiguration) entsteht.
Datenträger mit darauf gespeicherten Daten oder für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge, wobei die Daten ein Programm zur Wiederverwendung von ausführbaren Softwarekonfigurationen für Softwaresysteme im Prozess der Entwicklung neuer Anwendungen für Rechneranlagen oder rechnergestützte Systeme darstellen, wobei ein Softwaresystem wenigstens eine Möglichkeit zum Exportieren und Importieren von Teilen seiner Konfiguration aufweist, wobei ein Benutzer mithilfe des Programms zu jedem wieder zu verwendenden Teil einer Anwendung mindestens eine Teilkonfiguration erstellt, welche sich für die Wiederverwendung in neuen Anwendungen eignet, wobei das Programm diese Teilkonfiguration als Bestandteil einer kopierfähigen Schablone exportiert, und das Programm vor dem Export eine visuelle Programmierumgebung des Softwaresystems verwendet und die Schablone durch Einfügen von Instanzparametern instanziierbar macht und nach dem Export in mindestens einer Schablonen-Bibliothek aufbewahrt, und bei der Erstellung einer neuen Anwendung ein Zusammenbau-Automat als Bestandteil des Programms die Schablone mit H ilfe von Such- und Ersetzungsregeln zu einer in der neuen Anwendung funktionsfähigen Teilkonfiguration instanzi- iert und mit anderen Teilkonfigurationen bzw. weiterem Anwendungscode automatisiert zusammenfügt, wodurch eine neue, ablauffähige Softwarekonfiguration und Anwendung entsteht, dadurch gekennzeichnet, dass das Programm so ausgebildet ist, dass es in der visuellen Programmierumgebung eine formale Sprache verwendet, mit der ein Benutzer die Namen und Attributwerte von Entitäten durch Parameterangaben mittels Eingaben in Textfelder und Textbereiche bestimmt, wobei das Programm bei der Pa- rametrisierung der auf den Schablonen basierenden Teilkonfigurationen innerhalb der visuellen Programmierumgebung anstatt eines Instanz- Parameters auch mit Hilfe der formalen Sprache Funktionsaufrufe verwendet, darunter mindestens eine Funktion als Anweisung an den Zusammenbau-Automaten zur Durchführung einer Transklusion , wobei die Signatur einer Funktion mindestens einen Funktionsparameter besitzt, den der Zusammenbau-Automat als Referenz auf eine Ressource und/oder Entität interpretiert, deren Inhalt der Zusammenbau-Automat bei der Instanziierung einliest, wobei der Inhalt der Ressource und/oder Entität seinerseits durch Instanz-Parameter und Funktionen parametrisiert sein kann , und der Zusammenbau-Automat den Inhalt nach Auflösung aller enthaltenen Instanz- Parameter und untergeordneten Funktionen schließlich als Wert der Funktion, analog einem Parameterwert, verwendet und/oder eine verkürzte Notation in Form einer Markierung von Entitäten und/oder Entitätswerten eine Transklusion anweisen kann, wobei die Markierung dem Benutzer über die visuelle Programmierumgebung anzeigt, ob die Entitätswerte mittels Parameter überschrieben werden müssen oder können.
8. Datenträger mit darauf gespeicherten Daten oder für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge gemäß Anspruch 7, wobei die formale Sprache in der visuellen Programmierumgebung des Programms so ausgebildet ist, dass dem Softwaresystem , inkl. der visuellen Programmierumgebung, die Verwendung der Instanzparameter und Funktionen transparent bleibt, indem die Instanzparameter in der visuellen Programmierumgebung als gültige Zeichenketten modellierbar sind, indem die Parameternamen mindestens eine eindeutige Trennzeichenkettenfolge verwenden , die sich von allen anderen Zeichenkettenfolgen unterscheidet, die Funktionen in der Form modellierbar sind , dass ihre Signatur als n-Tupel ausgestaltet ist, wobei mindestens eine eindeutige Trennzeichenkettenfolge den Funktionsaufruf von allen anderen Zeichenkettenfolgen abgrenzt und innerhalb des Funktionsaufrufs mindestens eine weitere, untergeordnete Trennzeichenkettenfolge den Funktionsnamen und die nachfolgenden Funktionsparameter jeweils eindeutig voneinander abgrenzt,
die Funktionsparameter des Funktionsaufrufs Instanzparameter sein können.
Figure imgf000039_0001
Datenträger mit darauf gespeicherten Daten oder für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge gemäß einem der zuvor genannten Ansprüche 7 bis 8, wobei das Programm so ausgelegt ist, dass innerhalb der Schablone, die ihrerseits innerhalb einer Schablonenbibliothek abgelegt ist, neben der Teilkonfiguration weitere Ressourcen ablegbar sind, die somit Teil der Schablone sind, wobei diese Ressourcen bestehen können aus:
a. einer Eigenschafts-Vorbelegungs-Datei mit Vorbelegungen der Werte für die Instanzparameter, die der Zusammenbau-Automaten in den Suche-/ Ersetzungsregeln alternativ verwendet, wenn entsprechende Werte in einer Eigenschafts-Datei nicht angegeben sind ,
b. "Anpassungs"-Dateien , mit welchen umgebungsabhängige Installationsparameter konfigurierbar sind , und das Installationsprogramm diese Anpassungs-Dateien bei der Installation verwendet, welche zuvor in der Schablone inklusive der Installationsparameter durch Instanzparameter parametrisierbar sind, worauf der Zusammenbau- Automaten das Suchen/Ersetzen angewendet,
c. einer "Ersetzungsregel"-Datei, welche Anweisungen zu Textmanipulationen enthält um die Funktion zur Durchführung einer Transklusion außerhalb der visuellen Programmierumgebung zu definieren, wobei der Zusammenbau-Automat Suchen/Ersetzen auf der Teilkon- figuration anwendet und die Anweisungen zur Textmanipulation auf der exportierten und gegebenenfalls ausgepackten Teilkonfiguration ausführt,
d . Installationsskripten für Installation und Deinstallation der Bausteine, auf welche der Zusammenbau-Automaten Suchen/Ersetzen anwendet, wobei das Installationsprogramm die Bausteine bei der Installation verwendet,
e. optionalen Mustern weiterer Ressourcen mit logischem Bezug zu den Schablonen, auf welche der Zusammenbau-Automat Suchen/Ersetzen anwendet,
f. einer komplementären Teilkonfiguration, welche die Weiterentwicklung der Teilkonfiguration der Schablone in der visuellen Programmierumgebung des Softwaresystems unterstützt, wobei diese auch Schablonen-übergreifend ablegbar ist.
Datenträger mit darauf gespeicherten Daten oder für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge gemäß einem der zuvor genannten Ansprüche 7 bis 9, wobei das Programm so ausgelegt ist, dass nichtparametrisierbare Zeichenketten und/oder Ressourcen der Standardanwendung parametrisierbar gemacht werden, indem in den Schablonen für die nichtparametrisierbaren Zeichenketten und/oder Ressourcen Manipulationen in Form von Anweisungen zur Durchführung von Such- und Ersetzungsregeln durch einen Text und/oder einen Binär- Datenstrom-Editor definiert sind , die dafür sorgen, dass beim Kopiervorgang der Zusammenbau-Automat innerhalb der Teilkonfiguration der Schablone interne Dateien und/oder Teile darin durch dem neuen Baustein zugewiesene Dateien und/oder Dateiinhalte ersetzt, wobei die Such- und Ersetzungsregeln reguläre Ausdrücke enthalten, bezüglich
a. des Orts der bei der Instanziierung zu ersetzenden Datei und/oder b. der Suchregel für eine zu ersetzende Text- oder Binärpassage oder für eine Komplettersetzung und
c. des Namens des Instanzparameters, welcher die Referenz auf die Datei enthält, die den gesuchten Inhalt ersetzt.
Datenträger mit darauf gespeicherten Daten oder für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge gemäß einem der zuvor genannten Ansprüche 7 bis 10, wobei das Programm so ausgelegt ist, dass es die Installation und Deinstallation vorbereitet, indem es: a. Installationsskripte und Installationsparameter mit separatem Namensraum und eigener formaler Sprache verwendet, und der Wert eines Instanzparameters einen Teil eines Installationsparameternamens bestimmen kann, und
b. zu den Schablonen passende Installations- und Deinstallationsskripte erstellt, in denen das Programm die für eine Konfiguration erforderlichen Referenzen zu externen Entitäten und/oder Ressourcen bei der Instanziierung automatisiert anlegt und/oder entfernt, und c. Anpassungsdateien über die Installationsskripte zur Anpassung der Konfiguration zum Installationszeitpunkt verwendet, wobei der Zusammenbau-Automat die Parametrisierung der Instanzparameter in den Anpassungsdateien beim Kopiervorgang über auflöst und das Programm bei der Installation die Installationsparameter auflöst.
Datenträger mit darauf gespeicherten Daten oder für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge gemäß einem der zuvor genannten Ansprüche 7 bis 1 1 , wobei das Programm so ausgelegt ist, dass der Benutzer für den Zusammenbau-Automaten für die Erstellung einer neuen Anwendung ein Projekt mit einer Projektkonfiguration anlegt, wobei
a. das Projekt eine Projektkonfigurationsbeschreibung enthält, in der die Bausteine aufgelistet sind, aus denen die neue Konfiguration erstellt werden soll, wobei jeder Baustein einer Anweisung zur Instanziierung einer vorhandenen Schablone entspricht, und Projekt- Eigenschaften gelistet sind, die das Programm so handhabt, als würden die Einträge in der Eigenschafts-Datei jedes Bausteins stehen , und Baustein-Eigenschaften bei den Bausteinen gelistet sind, die das Programm so handhabt, als würden die Einträge in der Eigenschafts-Datei des jeweiligen Bausteins stehen,
b. der Benutzer zu jedem Baustein eine Eigenschafts-Datei mit Werten für die Instanzparameter als Teil der Anweisung anlegt, in der die Namen und Werte der zugehörigen Instanzparameter beschrieben sind , welche der Zusammenbau-Automat zuzüglich der Werte der Vorbelegungen verwendet und diese überschreibt und die entsprechenden Platzhalter der Schablone ersetzt,
c. der Benutzer zu jedem Baustein bei Bedarf ein Verzeichnis an legt, in dem sich Dateien (Ressourcen) befinden, die in den Ersetzungsregeln der Schablonen verlangt werden,
wobei der Zusammenbau-Automat im Projekt-Zielverzeichnis d ie Bausteine mit den zugehörigen Ressourcen aus den Schablonen erzeugt u nd alle Instanzparameter und/oder Funktionen für die neue Teilkonfiguration geeignet setzt, und somit eine zusammengesetzte, installationsfähige Anwendung (Konfiguration) entsteht.
1 3. Computerprogramm mit Programmcode zur Durchführung aller Verfahrensschritte nach mindestens einem der Ansprüche 1 bis 6, wenn das Computerprogramm auf einem Computer oder einem Computernetzwerk ausgeführt wird .
14. Rechneranlage zur Wiederverwendung von ausführbaren Softwarekonfigurationen für Softwaresysteme im Prozess der Entwicklung neuer Anwendungen für Rechneranlagen oder rechnergestützte Systeme, dadurch gekennzeichnet, dass die Rechneranlage so eingerichtet ist, dass sie einen Datenträger mit darauf gespeicherten Daten oder eine für die Übersendung über ein Datennetz geeignete, Daten repräsentierende Signalfolge verwendet, wobei die Daten ein Computerprogramm mit Programmcode gemäß Anspruch 1 3 darstellen, und die Rechneranlage das Computerprogramm ausführt.
PCT/EP2015/060259 2014-06-06 2015-05-08 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 WO2015185328A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102014210854.3 2014-06-06
DE102014210854.3A DE102014210854A1 (de) 2014-06-06 2014-06-06 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

Publications (1)

Publication Number Publication Date
WO2015185328A1 true WO2015185328A1 (de) 2015-12-10

Family

ID=53189031

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/060259 WO2015185328A1 (de) 2014-06-06 2015-05-08 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

Country Status (2)

Country Link
DE (1) DE102014210854A1 (de)
WO (1) WO2015185328A1 (de)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110389753A (zh) * 2019-06-06 2019-10-29 五八有限公司 原生应用的链式调用方法、装置、电子设备及存储介质
CN110489174A (zh) * 2019-08-20 2019-11-22 上海航空工业(集团)有限公司 一种用于机载软硬件匹配性加载系统实现的方法
CN110673874A (zh) * 2019-09-11 2020-01-10 苏州德创测控科技有限公司 用于向导式编程软件的变更配置的方法、存储介质、设备
CN110956025A (zh) * 2018-09-27 2020-04-03 长沙博为软件技术股份有限公司 一种基于流程模板复用的方法
CN111124376A (zh) * 2020-01-20 2020-05-08 众能联合数字技术有限公司 codeCli脚手架搭建项目系统
CN111190586A (zh) * 2019-12-16 2020-05-22 腾讯科技（深圳）有限公司 软件开发框架的搭建及使用方法、计算设备和存储介质
CN111448547A (zh) * 2018-03-01 2020-07-24 卡尔蔡司显微镜有限责任公司 计算机网络中执行和转换计算机程序的方法，特别是控制显微镜的方法
CN112099780A (zh) * 2020-07-31 2020-12-18 山东浪潮通软信息科技有限公司 一种基于erp系统的可视化应用开发方法、设备及介质
CN112905164A (zh) * 2019-12-04 2021-06-04 北京沃东天骏信息技术有限公司 一种项目代码处理方法和装置
CN113254017A (zh) * 2021-05-27 2021-08-13 平安普惠企业管理有限公司 基于Vue框架生成开发模板文件方法、装置、设备及介质
WO2022252040A1 (zh) * 2021-05-31 2022-12-08 京东方科技集团股份有限公司 配置数据包及文件的生成方法、处理方法、设备和介质

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106843881A (zh) * 2017-01-23 2017-06-13 上海鹰谷信息科技有限公司 化合物管理信息的可配置模板的创建方法
DE102017201156A1 (de) * 2017-01-25 2018-07-26 Brixxbox GmbH Erzeugung und Ausführung von Software-Modulen

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69031078T2 (de) 1989-11-30 1998-01-15 Seer Technologies Inc Rechnerunterstützte softwareentwicklungseinrichtung
DE69838139T2 (de) 1997-09-17 2008-05-08 Tenfold Corp., Draper Verfahren und system zur schaffung von datenbankanwendungssoftware,die minimales programmieren benötigen
US20080256509A1 (en) * 2007-04-11 2008-10-16 Daniele Mazzeranghi Pattern-based programming system for automatic code generation
WO2009029531A1 (en) * 2007-08-27 2009-03-05 Adobe Systems Incorporated Reusing components in a running application

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69031078T2 (de) 1989-11-30 1998-01-15 Seer Technologies Inc Rechnerunterstützte softwareentwicklungseinrichtung
DE69838139T2 (de) 1997-09-17 2008-05-08 Tenfold Corp., Draper Verfahren und system zur schaffung von datenbankanwendungssoftware,die minimales programmieren benötigen
US20080256509A1 (en) * 2007-04-11 2008-10-16 Daniele Mazzeranghi Pattern-based programming system for automatic code generation
WO2009029531A1 (en) * 2007-08-27 2009-03-05 Adobe Systems Incorporated Reusing components in a running application

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Enterprise Integration Patterns. Designing, Building, and Deploying Messaging Solutions", 20 October 2003, ADDISON WESLEY
DIETER ROMBACH: "Wis-sensmanagement und Software Engineering - Wiederverwendbarkeit", SOFTWARE NACH DEM BAUKASTENPRINZIP, January 2003 (2003-01-01), Retrieved from the Internet <URL:www.community of knowledge.de/beitrag/wissensmanagement-und-software-oder>

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111448547A (zh) * 2018-03-01 2020-07-24 卡尔蔡司显微镜有限责任公司 计算机网络中执行和转换计算机程序的方法，特别是控制显微镜的方法
CN110956025A (zh) * 2018-09-27 2020-04-03 长沙博为软件技术股份有限公司 一种基于流程模板复用的方法
CN110389753A (zh) * 2019-06-06 2019-10-29 五八有限公司 原生应用的链式调用方法、装置、电子设备及存储介质
CN110389753B (zh) * 2019-06-06 2024-01-23 五八有限公司 原生应用的链式调用方法、装置、电子设备及存储介质
CN110489174A (zh) * 2019-08-20 2019-11-22 上海航空工业(集团)有限公司 一种用于机载软硬件匹配性加载系统实现的方法
CN110673874A (zh) * 2019-09-11 2020-01-10 苏州德创测控科技有限公司 用于向导式编程软件的变更配置的方法、存储介质、设备
CN112905164A (zh) * 2019-12-04 2021-06-04 北京沃东天骏信息技术有限公司 一种项目代码处理方法和装置
CN111190586A (zh) * 2019-12-16 2020-05-22 腾讯科技（深圳）有限公司 软件开发框架的搭建及使用方法、计算设备和存储介质
CN111124376A (zh) * 2020-01-20 2020-05-08 众能联合数字技术有限公司 codeCli脚手架搭建项目系统
CN111124376B (zh) * 2020-01-20 2023-08-11 众能联合数字技术有限公司 codeCli脚手架搭建项目系统
CN112099780A (zh) * 2020-07-31 2020-12-18 山东浪潮通软信息科技有限公司 一种基于erp系统的可视化应用开发方法、设备及介质
CN112099780B (zh) * 2020-07-31 2024-04-12 浪潮通用软件有限公司 一种基于erp系统的可视化应用开发方法、设备及介质
CN113254017A (zh) * 2021-05-27 2021-08-13 平安普惠企业管理有限公司 基于Vue框架生成开发模板文件方法、装置、设备及介质
WO2022252040A1 (zh) * 2021-05-31 2022-12-08 京东方科技集团股份有限公司 配置数据包及文件的生成方法、处理方法、设备和介质

Also Published As

Publication number Publication date
DE102014210854A1 (de) 2015-12-17

Similar Documents

Publication Publication Date Title
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
EP1176482B1 (de) Verfahren und Computerprogramm zum Herstellen einer Regelung oder Steuerung
DE60011479T2 (de) Xml-roboter
EP1723513B1 (de) Verfahren zur konfiguration eines computerprogramms
EP3049920A1 (de) Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung
DE10121790A1 (de) System und Verfahren zur Konfiguration von Softwareprodukten
DE19705955A1 (de) Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung
DE102007040823A1 (de) Editier- und Berichts-Tool für Grafische Programmiersprachenobjekte
DE102005055133A1 (de) System für den maschinengestützten Entwurf technischer Vorrichtungen
EP3217236B1 (de) Verfahren und system zur generierung eines bedienprogramms in form einer auf einem mobilen gerät lauffähigen mobilen applikation
EP2332042A1 (de) Verfahren und vorrichtung zum austauschen einer komponente eines computersystems
DE10244685A1 (de) Produktkonfigurationsverfahren und -system
DE102010008889A1 (de) Plattformunabhängiges Verfahren und System für den Einsatz einer Steuerlogikprogrammierung
DE10333087A1 (de) Verfahren zum automatischen Zerlegen von dynamischen Systemmodellen in Teilmodelle
DE69907714T2 (de) Komponentbasiertes quellcodegeneratorverfahren
DE10015114A1 (de) Verfahren und Vorrichtung zur Modellierung eines mechatronischen Systems in einem Kraftfahrzeug
EP1920357A1 (de) Migration und transformation von datenstrukturen
DE102021116315A1 (de) Verfahren zum Zusammenführen von Architekturinformationen
DE102004009676A1 (de) Verfahren und Systeme zum Erzeugen von Unterstützungsdateien für Befehle
EP1202167B1 (de) Verfahren zur modellbasierten objektorientierten Entwicklung von externen Schnittstellen für verteilte Softwaresysteme
DE10357831A1 (de) System und Verfahren zum Reengineering von Objektmodell-Komponenten zur Generierung von Web-Services
DE102019008598A1 (de) Identifikation und Visualisierung von Assoziationen zwischen Code, der von einem Modell generiert ist, und Quellen, welche die Codegeneration beeinflussen
DE202014006343U1 (de) Rechneranlage, Datenträger sowie Signalfolge für ein Programm zur Wiederverwendung von ausführbaren Softwarekonfigurationen für Softwaresysteme
EP1609061A2 (de) Verfahren und anordnung zur veränderung von software oder quellcode
DE4310615C2 (de) Entwurf elektrischer Vorrichtungen mit mehreren Entwurfswerkzeugen, die zumindest teilweise untereinander inkompatibel sind

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15723191

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15723191

Country of ref document: EP

Kind code of ref document: A1