Computer-aided method for the automated generation and verification of a computer program

Abstract

A computer-aided method for generating a computer program is described, which comprises the following steps: a) Providing a functional system model (FM) for the computer program to be created, b) automated execution of a model-to-model transformation (fm2spc) so that a specific system model (SPC) in a domain-specific language (DSL) is generated from the functional system model (FM), c) automated execution of a model-to-text transformation (spc2txt) so that a source code (TXT) for the computer program is created from the specific system model (SPC), d) Implementation of the source code (TXT) into an executable computer program (SUT), e) Generation of a set of executable test cases (TC) based on the functional system model (FM) and / or an optionally underlying original system model (MD), wherein the generation is at least partially automated, as well as f) Verification of the source code (TXT) automatically generated in step c) based on an automated test series of the executable computer program (SUT) using the set of test cases (TC) generated in step e). Furthermore, a computer program product and a development system are specified by carrying out the procedure.

Description

[0001] The present invention relates to a computer-aided method for generating a computer program, in which a functional system model is provided for the computer program to be generated and at least one model transformation is performed to generate a source code for the computer program from the system model. Furthermore, the invention relates to a computer program product and a development system for implementing this method.

[0002] One problem with known computer programs of the type mentioned above, whose source code is automatically generated from the system model via one or more model transformations, is that it is often time-consuming to verify the automatically generated source code. Verification here refers to the proof of the correctness of the source code—in other words, the proof that the originally provided system model is correctly implemented by the automatically generated source code.

[0003] The provided system model generally requires a high level of detail to enable automatic code generation. The system model must contain all information relevant to the functionality of the computer program to be generated. The more complex and extensive such a system model is, the more efficient automatic code generation typically is compared to manual source code generation. However, verifying the automatically generated source code can then become one of the most time-consuming steps in software development, especially if the model is frequently adapted and the verification step must be repeated each time.

[0004] According to the state of the art, two main approaches are pursued to verify such automatically generated source code: First, the correctness of the model transformer can be verified separately. However, this can be very complex, especially for non-trivial transformations. A fundamental distinction must be made between model-to-model transformers and model-to-text transformers. Model-to-model transformers transform a functional system model into another functional system model, which may, for example, have a different level of abstraction. In contrast, a model-to-text transformation transforms a functional system model into source code. Independent verification of a model-to-text transformer is often possible with relatively reasonable effort and is therefore sometimes used in practice.If the level of abstraction is similar in a model-to-model transformation, independent verification may also be possible. However, the effort required is very high if, for example, a model-to-model transformation generates a specific system model in a domain-specific language from an abstract functional system model. In these cases, separate verification of the transformer is often omitted, as it would not be practically feasible with reasonable effort.

[0005] Therefore, the second verification variant is often used for such model-to-model transformations: verification using traditional software development methods. In other words, the automatically generated source code is treated similarly to manually generated source code during verification, and it is verified similarly, for example, using unit tests, code reviews, static analyses, and dynamic tests. However, the effort required for this is very high and is repeated every time, even for minor changes to the system model.

[0006] The object of the invention is therefore to provide a method for verifying automatically generated source code that overcomes the aforementioned disadvantages. In particular, a verification method is to be provided in which this development step is associated with comparatively low effort. The verification should nevertheless be reliable, in particular, it should be robust enough for safety-critical applications of the generated computer program. A further object is to provide a computer program product and a development system for performing such verification during the automated generation of a computer program.

[0007] These objects are achieved by the method described in claim 1, the computer program product described in claim 14 and the development system described in claim 15.

[0008] The method according to the invention is a computer-aided method for generating a computer program. It comprises the following steps: a) Providing a functional system model for the computer program to be generated, b) automated execution of a first model-to-model transformation so that a first specific system model in a domain-specific language is generated from the functional system model, c) automated execution of a model-to-text transformation so that a source code for the computer program is generated from the first specific system model, d) conversion of the source code into an executable computer program, e) generating a set of executable test cases based on the functional system model and / or an optional underlying original system model, wherein the generation is at least partially automated, and f) Verification of the source code automatically generated in step c) on the basis of an automated test suite of the executable computer program using the set of test cases generated in step e).

[0009] In step a), the functional system model can be created by a user (e.g., a software developer) in a development environment provided for this purpose. Alternatively, the functional system model can be generated from such a user-created model through a model-to-model transformation.

[0010] In any case, in step b), a model-to-model transformation takes place, which generates a more specific system model from the more general functional system model. This step of the model-to-model transformation is performed automatically on a computer. The transformer used for this purpose is therefore a computer program, which can be available, for example, as part of a larger software development environment or a development tool. In particular, the correctness of this automatic transformer is not independently verified.

[0011] In step c), the result of this model-to-model transformation is subjected to a further transformation, namely a model-to-text transformation. This further transformation is also carried out automatically on a computer. Here, too, the transformer used is a computer program, which can be available, for example, as part of a larger software development environment or a development tool. The source code obtained in step c) can therefore, in particular, be code in a text-based programming language such as Structured Text (ST) and / or Structured Control Language (SCL). In addition to the source code, one or more further text artifacts can optionally be generated within step c) in addition to the actual source code, for example test code and documentation.

[0012] In step d), a so-called software build is performed, i.e., an executable computer program is generated from the source code. This executable program can then be used, for example, to control a technical system. The executable computer program can be generated using a compiler and / or an interpreter, for example.

[0013] In step e), a set of executable test cases is generated with which the executable computer program can be tested. The generation of these test cases is at least partially automated and can be carried out in different ways, namely either on the basis of the functional system model or on the basis of an optionally underlying original system model. However, it is essential that the test cases are created on the basis of a system model, which forms the basis for the automatically generated source code and thus also for the executable computer program. Particularly advantageously, the generation of the test cases can also be fully automated, i.e., without manual input from a user. However, if manual input is carried out, the effort required can advantageously remain low. For example, such manual input can concern the definition of a test data model. If, for example,If the system model is adapted in several iterations during the development of the computer program and a new verification is carried out for each of these adaptations, then the test data model does not have to be completely redefined for each iteration, but the model once entered can either be adopted in its entirety or adapted to the changed system model with little maintenance effort.

[0014] In step f), the executable computer program is tested using these test cases. The test cases are designed in such a way that the executable computer program can be applied to them. The behavior of the executable computer program (e.g., in interaction with the technical system to be controlled) can thus be tested by applying it to these test cases. If this test is successful—i.e., if applying the computer program to the test cases does not generate an error—the generated computer program can be verified in step f).

[0015] A significant advantage of the method according to the invention compared to the prior art is that the described verification condition can be checked essentially automatically. Both the generation of the test cases in step e) and the execution of the test series in step f) can be computer-aided and largely automated. In contrast to the independent verification of the transformer and also the conventional verification of the source code, no manual interaction is required in method steps b), c), d), and f). In particular, no manual checking of source code or program functions is required in the entire verification step described here.As a result, this verification step can be carried out very efficiently overall, and the associated effort, at least the manual effort for the respective software developer, can be advantageously kept low by largely automating the verification.

[0016] It should be emphasized that the verification described in step f) using the automated test series may only represent a part of a higher-level verification process. In other words, there may be additional criteria and thus additional verification steps for the verification that are not described here and that may also require manual verification steps. The only essential aspect of the present invention is that the (necessary) criterion of a successful test series is verified automatically, thus verifying an essential verification criterion with comparatively low personnel effort and high reliability.

[0017] The computer program product according to the invention comprises instructions, which, when executed on a computer, cause the computer program product to execute the method according to the invention. The development system accordingly serves for the computer-aided generation of a computer program using the method according to the invention. The advantages of the computer program product and the development system arise analogously to the advantages of the method according to the invention described above.

[0018] Advantageous embodiments and further developments of the invention emerge from the claims dependent on claim 1 and the following description. The described embodiments of the method can also be implemented in the computer program product or the development system, and vice versa.

[0019] Thus, according to a generally advantageous embodiment, the computer program to be generated using the method can be a computer program for controlling a technical system. The technical system can be, for example, a vehicle or an industrial plant. In particular, the technical system can be a safety-relevant technical system. A safety-relevant technical system is understood here to be a system that has been linked to a so-called safety integrity level (SIL) as part of a risk assessment. Classification into one of the SIL levels 1, 2, 3 or 4 depends in particular on the extent to which the operation of the technical system potentially poses a risk to human health, the environment and / or goods.The higher the safety requirement level, the higher the requirements for the reliability of safety functions of the electrical, electronic, and programmable electronic (E / E / PE) components used in the operation of the technical system. Accordingly, a computer program used to control a technical system with a comparatively higher SIL level must be verified with comparatively strict requirements for reliability and the prevention of malfunctions. The invention can make a contribution to this, with further verification steps and / or other measures to ensure operational safety optionally being able to be added to the described verification step. For example, the safety-relevant technical system can be a rail vehicle or a system for operating rail vehicles.Accordingly, the computer program to be generated is then a program for controlling one or more rail vehicles. Alternatively, the technical system can be, for example, a motor vehicle, an aircraft, an industrial production facility, or a power plant. The computer program can also generally be used to control a so-called programmable logic controller, which is used in particular as a component in such a higher-level safety-relevant technical system. However, these are only a few relevant examples; there are numerous other applications in which the described advantages with regard to the verification of automatically generated software can be realized.

[0020] According to an advantageous embodiment for step a), this step may comprise the following substeps: a1) Creating an original system model within a development tool, a2) automated execution of an abstracting model-to-model transformation, whereby the functional system model is generated from the original system model.

[0021] In other words, the functional system model is preceded by another system model, which may in particular have been created by a software developer in a development environment suitable for this purpose. An example of such a commercially available development environment is MagicDraw, although numerous other similar development environments can also be used, including those that are not commercially available but are created by a development team for a specific application. In any case, in sub-step a1), an original system model can be created in a simple manner by input from the developer, which is then transformed into the functional system model in the subsequent step a2), from which the source code of the computer program is then generated and at least partially verified according to the inventive method in the further steps b) to e).The model-to-model transformation in step a2) can, in particular, be an abstracting model transformation, whereby certain information or parameters can be omitted compared to the original system model. For example, layout instructions that are relevant within the development tool but not in the abstracted functional system model can be omitted in this step. In general, the model-to-model transformation in step a) can again be a computer-aided, fully automated transformation, similar to the transformations described above.

[0022] In this embodiment, the source system model can advantageously be created using a universal modeling language. This can be, for example, the Unified Modeling Language (UML) and / or the Systems Modeling Language (SysML). Such universal modeling languages ​​are particularly suitable for creating system models at a comparatively abstract level and thus domain-independently with manageable development effort.

[0023] Generally advantageously, the modeling language used can be a graphical modeling language or a graphically represented or graphically representable programming language. In particular, the functional system model and / or the optionally underlying original system model can comprise one or more state machines and / or one or more activity diagrams.

[0024] A state machine is understood here as a model of behavior consisting of states, state transitions, and actions. The relevant system model can be defined, in particular, using one or more finite automata, where the set of states the automaton can assume is finite. Such state machines can be used to easily represent system models graphically. In contrast, an activity diagram is a behavior diagram in the UML modeling language, which can be used to graphically represent the networking of elementary actions and their connections to control and data flows. Typically, this describes the sequence of a use case. However, activity diagrams are generally suitable for graphically modeling all activities within a system.

[0025] According to a generally advantageous implementation variant, the verification of the source code in step e) is only successfully completed if no errors occur in the test suite performed in step f). In other words, the test suite must be successful with respect to all generated test cases.

[0026] According to a first advantageous embodiment for generating the executable test cases, these can be created based on the original system model. In particular, they can be generated from this original system model without using the functional system model generated from the original system model for their generation. In other words, in this variant, the two generation paths—the first path for generating the executable computer program and the second path for generating the executable test cases—branch before the abstracting model-to-model transformation, by means of which the functional system model is generated from the original system model. An advantage of this embodiment is that the early separation of these two paths in the case of a successful test series also provides an indication of the correctness of the abstracting model-to-model transformation.This advantage is even more pronounced the more independent the implementation of the two paths is. It is particularly advantageous if both paths are implemented diversely along their entire length, as explained in more detail below. Therefore, in this variant with early branching of the paths, this abstracting model-to-model transformation may not need to be independently verified. However, it can optionally be independently verified. In this case, a diverse implementation for the first part of the second path is not required.

[0027] According to an alternative, second implementation variant for generating executable test cases, these can be created based on the functional system model. In other words, in this variant, the two generation paths only branch after the abstracting model-to-model transformation, if the functional system model is preceded by an original system model and, accordingly, also by an abstracting model-to-model transformation. In this implementation variant, it is generally advantageous if such an upstream model-to-model transformation is performed with an independently verified transformation tool. This is useful because the subsequent branching of the two generation paths from a successful test series does not allow any conclusions to be drawn about the correctness of the upstream abstracting model-to-model transformation.

[0028] In general, and regardless of the basis on which the test cases are generated, according to an advantageous variant in step e), at least one automated transformation can be used during the generation of the test cases, by means of which a test model is generated from the underlying system model. The underlying system model can therefore be either the functional system model or an optionally precedented original system model.

[0029] A test model is understood here, in particular, to be an extended model in which the underlying system model for the computer program to be created is extended by a model for the environment that interacts with the computer program. Furthermore, the parameters of test scenarios can be described in such a model, with such test scenarios typically involving an interaction between the system and the environment. Accordingly, the generated test model can advantageously also comprise at least one state machine and / or at least one activity diagram.

[0030] The transformation from the underlying system model to the test model can be performed, for example, using a model-based testing tool. Such tools are available for some commercial development platforms. A model-based testing tool can typically generate abstract test cases with their associated test data.

[0031] In addition to such a tool for model-based testing (or within such a tool), a test generator can also be used. With such a test generator, the above-mentioned abstract test cases can be converted into executable test cases. These executable test cases can be executed in an execution environment of the executable computer program created in step d), together with the executable computer program, or the executable computer program can be directly applied to these test cases during its execution. Accordingly, a test suite can be performed through the interaction of the executable computer program with the executable test cases. The generation of the abstract test cases in the tool for model-based testing and the generation of the executable test cases with the test generator can be carried out according to user-defined requirements for coverage and test depth.

[0032] Using a model-based testing tool makes it possible to generate optimized test suites that ensure that the state transitions present in the test model are sufficiently covered according to defined coverage criteria, while simultaneously ensuring coverage of the parameter selection options defined in the test data model. For example, with regard to the control flow, all transitions and / or all edges can be covered. Alternatively or additionally, the possible parameters can be fully covered individually or in pairs. The latter variant corresponds to the so-called "pairwise testing method." The coverage or test depth should be adapted to the desired security level. This allows the risk of systematic errors remaining undetected in the system to be sufficiently reduced according to the respective system requirements.

[0033] In the embodiments in which a transformation into a test model is used, it is generally advantageous if the automated transformation into the test model differs from the model-to-model transformation carried out in step c) and / or the abstracting model-to-model transformation optionally carried out in step a2) with regard to at least one of the following features: - a language of the target model generated during the transformation, - a programming language with which the transformation tool was created, - libraries used in the transformation, - algorithms used in the transformation, - Format of state diagrams used to describe the model.

[0034] In general, the respective transformations can be implemented using different tools. These can be, in particular, different development environments, even marketed by different vendors. Alternatively, a commercially available development environment can be used, while a tool created by the developers of the computer program themselves can be used. If these tools were created using different programming languages, then, for example, one tool could be programmed using an object-based or object-oriented programming language, and the other could be programmed using a functional programming language. According to another advantageous embodiment, the implementation using both development methods can be carried out by different developers or development teams.

[0035] What's essential with this implementation variant is that there is sufficient diversity between the two generation paths, meaning that the first path for generating the executable computer program and the second path for generating the executable test cases differ in their methodology. The goal is to prevent the same systematic errors from being introduced into both paths.

[0036] Then, a successful test suite can be used to conclude with a high degree of probability that the source code generation was correct, because a programming error in the first generation method would not be compensated for by the corresponding error in the second generation method. Rather, such a programming error would lead to an error in the test suite, which could reveal the programming error.

[0037] According to an alternative embodiment for step e), the test cases can also be generated directly from the system model used, i.e., again either from the original system model or the functional system model (possibly abstracted from it). Such "direct generation" should be understood here to mean that no further transformation into another model takes place as an intermediate stage. In particular, no test model is generated from the underlying system model; rather, the executable test cases are generated directly from the system model. Therefore, with this variant, no additional tool for model-based testing is required. Instead, a test generator can generate the executable test cases directly from the underlying system model. Compared to the use of an intermediate test model, such direct generation typically uses a lower test depth and / or coverage.In cases where a high test depth and / or coverage is not required, directly generating the executable test cases may be simpler and more efficient.

[0038] Even when generating executable test cases directly from the respective system model, it is generally advantageous if the test case generation path differs methodologically from the computer program generation path. Such a difference can be caused, for example, by one or more of the following aspects: - programming language used to create the tools used in the creation path, - libraries used in the build path, - algorithms and / or methods used in the generation.

[0039] In particular, the method or algorithm for translating abstract test cases generated as intermediate results into executable test cases may differ from the method or algorithm for the model-to-text transformation during source code generation in step c). If individual substeps in at least one of the generation paths can be independently verified, a diverse implementation of the two paths is less relevant for these substeps.

[0040] The invention is described below using some preferred embodiments with reference to the attached drawings, in which: Fig. 1 shows a schematic representation of selected process steps in the generation of a computer program and Fig. 2 to 5 show extensions of this process according to four different embodiments of the invention.

[0041] In the figures, identical or functionally identical elements are provided with the same reference symbols.

[0042] In Fig. Figure 1 shows a schematic representation of several method steps that can be used in the computer-aided generation of a computer program. The illustrated process includes, in particular, steps a), b), and c) mentioned in claim 1.

[0043] First, a functional system model FM is provided, which in this example is created from an original system model MD using a model-to-model transformation md2fm. The original system model MD may have been created by a software developer within a development tool such as MagicDraw, as indicated by the lettering. However, there are also numerous other development environments with which such system models can be easily created using user input, particularly using a graphical input environment. The original system model MD created in this way may have been verified, in particular, through a review process, as indicated here by the check mark to the right of it.

[0044] The md2fm transformation in the example shown is an abstracting model-to-model transformation, in which the system model can be freed, in particular, of tool-specific information from the development environment to create the original system model MD. For example, this abstraction of the system model can eliminate layout information that is only relevant in this development environment. The md2fm model-to-model transformation can be automated and, in particular, performed with a independently verified development tool. Due to the comparatively low complexity of the transformation to be performed here, the effort required for such independent verification of the transformation tool used is comparatively low.Accordingly, the combination of the review process for the original system model MD and the verification of the transformation tool md2fm also provides a verification of the intermediate result FM, as indicated by the respective check marks.

[0045] However, the sequence shown, in which an original system model MD is first created and from this, a more abstract functional system model FM is generated using a transformation md2fm, is not mandatory. In the context of the invention, it is only essential that a functional system model FM is provided in some way, from which a computer program can be created in subsequent steps in a computer-aided and automated manner.

[0046] In a subsequent step b), a specific system model SPC is generated from the functional system model FM through a further automated model-to-model transformation fm2spc. This is a system model in a domain-specific language, a so-called DSL (domain-specific language). A domain-specific language or application-specific language is a formal language designed and implemented for the interaction between humans and computers for a specific problem area (the so-called domain). When designing a DSL, the typical attempt is to achieve a high degree of problem specificity: The language should be able to represent all problems in the domain and, ideally, should not be able to represent anything that lies outside the domain. This allows it to be used by domain specialists without any special additional knowledge.

[0047] An example of a domain is the control of a specific class of technical systems, such as the control of rail vehicles or the operation of a production plant. This can be achieved, for example, by automation devices such as those sold by Siemens AG under the product name SIMATIC. For the development of software for such SIMATIC controllers in the field of railway automation, a dedicated domain-specific XML-based modeling language, known as SPCS, is available.

[0048] The transformation fm2spc into the specific system model SPC can also be automated using a transformation tool developed for this purpose. However, in contrast to the preceding model-to-model transformation md2fm, a separate verification of such a tool is considerably more difficult and complex, since it involves a much greater change in the level of abstraction (from general functionality to a very specific application). Accordingly, Fig. 1 neither the transformation fm2spc nor the specific system model SPC generated with it are checked, since this is initially an unverified result.

[0049] In the subsequent step c), a TXT source code, particularly in a text-based programming language, such as source code in the SCL programming language, is generated from the specific SPC system model using an automated model-to-text transformation (spc2txt). Unlike this text-based programming language, the programming languages ​​of the preceding MD, FM, and SPC system models are graphical programming languages, or at least graphically represented and graphically inputtable programming languages. In addition to the actual TXT source code, further text artifacts, such as documentation and code for test cases, can be generated in this step c). This model-to-text transformation (spc2txt), like the previously described md2fm transformation, can be independently verified with relatively little effort, as indicated by the check mark in parentheses.However, this does not initially lead to a verified source code TXT, since the previous specific system model SPC has not yet been verified by the steps described so far.

[0050] In a subsequent step not shown separately here, an executable program can be generated from the text-based source code TXT, which can be used to control a technical system such as a rail vehicle or a production plant.

[0051] The Fig. The transformations md2fm, fm2spc, and spc2txt shown in Figure 1 can all be performed automatically by a CGEN code generator. This code generator can be a software development tool, which can be available as a plug-in for another development environment, such as the MagicDraw development environment, with which the original system model MD is created based on input from the developer. With the CGEN plug-in, all subsequent steps can then be performed computer-aided and automatically, without any further interaction from the developer.

[0052] In Fig. 2 is an extension of the Fig. 1 according to a first embodiment of the invention. The process steps a) to c) are analogous to Fig. 1. The following step d) is also shown, in which the source code TXT is compiled, thus generating an executable computer program. The executable computer program is referred to here as SUT (System Under Test). This step completes the first path A, through which the executable computer program SUT is generated with computer support.

[0053] In addition, in an additional step e), a data set with a large number of executable test cases TC is generated. In this example, the test cases TC are generated based on the original system model MD. This second path, on which the test cases TC are generated, is shown in Fig. 2 is designated B. Step e) can generally occur before, after, or parallel to steps a) to d). Here, it occurs in a two-stage process, with a test model TM being created in an intermediate step. The test model TM is created using a model-to-model transformation md2tm from the original system model MD. In the process, the system model MD is extended to include a description of the interaction with the environment and relevant test parameters for this interaction. Furthermore, similar to the transformation md2fm, an abstraction can be performed here, so that the resulting test model TM can be at a similar level of abstraction to the functional system model FM. However, this is not necessarily the case, and the test model can also be more specific or abstract than the functional system model.In any case, it is advantageous if the test model TM also includes state machines and / or activity diagrams to model the system and its interaction with the environment.

[0054] In a subsequent sub-step, a dataset containing numerous executable test cases (TC) is generated from the test model (TM). In the example shown, this is done using a tool (mbt) for model-based testing and a test generator (tgen). In a further intermediate step, a dataset containing abstract test cases and additional test data can be generated, and the executable test cases can then be generated from the abstract test cases. This optional intermediate step is not described separately here. If used, the abstract test cases are generated within the (mbt) tool, with the test generator then generating the executable test cases (TC) from the abstract test cases.

[0055] In a subsequent process step f), the executable computer program SUT is finally executed together with the set of test cases TC. The computer program SUT is thus tested against these test cases TC, with the execution of this test series again being computer-aided and automated. If no errors occur, the test series is classified as successful, which is indicated by the check mark in the right-hand part of the figure. Such a successful test series can be used as a necessary condition for verifying the computer program SUT generated along the first path A. If, on the other hand, an error occurs, this is interpreted as an indication of an error in one of the transformations md2fm, fm2spc, or spc2txt within the first path. Alternatively, the error can of course also be due to an error in the second path B, i.e., in the generation of the test cases.In any case, an error within the test suite indicates an error in one of the two paths A or B. Therefore, if such an error occurs, a successful verification according to step f) does not occur.

[0056] If no errors occur within the entire test sequence, it can be assumed with sufficient probability that the generation path A is correct. This is especially true if the two paths A and B have been implemented diversely. For example, the two transformations md2fm and md2tm can differ with regard to the tool used, in particular with regard to the programming language used to create the tool, with regard to the language of the target model generated during the transformation, with regard to the libraries or algorithms used, and / or with regard to the format of the state diagrams used to describe the model. For safety-relevant applications, a diverse implementation of the two paths is particularly relevant in order to rule out the presence of corresponding systematic errors.

[0057] In Fig. 3 is an extension of the Fig. 1 according to an alternative, second embodiment of the invention. The process steps a) to d) and f) are analogous to Fig. 2. Similar to Fig. 2, in step e), a data set with test cases TC is generated based on the original system model MD. In contrast to the previous example, however, no intermediate test model is used to generate the test cases TC; instead, the executable test cases TC are automatically generated directly from the original system model using a test generator tgen designed for this purpose. Here, too, it is advantageous if the first path A and the second path B differ methodically from each other, e.g., with regard to the programming languages ​​or programming concepts used, libraries used, and / or algorithms used.

[0058] In Fig. 4 shows a corresponding process according to a third embodiment of the invention. Here, too, the process steps a) to d) and f) are analogous to the Fig. 2 and Fig. 3. The main difference to the example of the Fig. 2 is that in step e), the generation of the test cases TC is not based on the original system model MD, but on the basis of the functional system model FM. In other words, the two paths A and B in this example only separate after the transformation md2fm, and the test model is accordingly generated by a transformation fm2tm from the already abstracted functional system model FM. Apart from this difference, step e) is analogous to the example of the Fig. 2, namely via the intermediate stage of a test model TM and using a tool mbt for model-based testing and a test generator tgen.

[0059] In Fig. Figure 5 shows a corresponding process according to a fourth embodiment of the invention. Here, too, the process steps a) to d) and f) are analogous to the Fig. 2, Fig. 3 and Fig. 4. Similar to the example of Fig. 4, the test cases are also generated in step e) based on the functional system model FM. In contrast, the test cases are not generated via a test model, but rather directly from the functional system model FM using a corresponding test generator tgen. In this respect, this is a modification of the example of Fig. 3 with a modified starting point for the test generator tgen.

[0060] The applicant points out at this point that, regardless of the grammatical gender of a particular personal term, it should always include persons with male, female and other gender identities.

Claims

[1] Computer-aided method for generating a computer program, comprising the following steps: a) Providing a functional system model (FM) for the computer program to be generated, b) automated execution of a model-to-model transformation (fm2spc) so that a specific system model (SPC) in a domain-specific language (DSL) is generated from the functional system model (FM), c) automated execution of a model-to-text transformation (spc2txt) so that a source code (TXT) for the computer program is created from the specific system model (SPC), d) Conversion of the source code (TXT) into an executable computer program (SUT), e) Generation of a set of executable test cases (TC) based on the functional system model (FM) and / or an optional underlying original system model (MD), wherein the generation is at least partially automated, and f) Verification of the source code (TXT) automatically generated in step c) on the basis of an automated test suite of the executable computer program (SUT) using the set of test cases (TC) generated in step e). [2] Method according to claim 1, wherein the computer program to be generated is a control program for controlling a technical system, in particular a safety-relevant technical system and / or an industrial technical system. [3] Method according to claim 1 or 2, wherein step a) comprises the following sub-steps: a1) Creating an original system model (MD) within a development tool, a2) automated execution of an abstracting model-to-model transformation (md2fm), whereby the functional system model (FM) is generated from the original system model (MD). [4] Method according to claim 3, wherein the original system model is created using a universal modeling language, in particular using the Unified Modeling Language (UML) and / or the Systems Modeling Language (SysML). [5] Method according to claim 3 or 4, wherein the generation of the test cases (TC) in step e) is carried out on the basis of the original system model (MD). [6] Method according to claim 3, 4 or 5, wherein the generation of the test cases (TC) in step e) is carried out on the basis of the functional system model (FM), wherein the abstracting model-to-model transformation (md2fm) carried out in step a2) is carried out by means of an independently verified transformation tool. [7] Method according to one of claims 1 to 5, wherein the generation of the test cases (TC) in step e) is carried out on the basis of the functional system model (FM). [8] Method according to one of the preceding claims, wherein in step f) the verification of the source code (TEXT) is only successfully completed if no error occurs in the test series carried out in step f). [9] Method according to one of the preceding claims, in which the functional system model (FM) and / or an optionally underlying original system model (MD) comprises a state machine and / or an activity diagram. [10] Method according to one of claims 1 to 9, wherein in step e) at least one automated transformation (md2tm, fm2tm) from a system model (FM, MD) into a test model (TM) is carried out for the generation of the test cases (TC). [11] Method according to claim 10, wherein the automated transformation in step e) leads to the generation of a test model (TM) comprising at least one state machine and / or at least one activity diagram. [12] Method according to one of claims 10 or 11, wherein the automated transformation (md2tm, fm2tm) in step e) differs from the model-to-model transformation (fm2spc) carried out in step c) and / or the abstracting model-to-model transformation (md2fm) optionally carried out in step a2) with respect to at least one of the following features: - Language of the target model generated during the transformation (TM, SPC, FM), - Programming language used to create the transformation tool, - libraries used in the transformation, - algorithms used in the transformation, - Format of state diagrams used to describe the model. [13] Method according to one of claims 1 to 9, in which the test cases (TC) are generated directly from the system model (MD, FM) used. [14] A computer program product comprising instructions, wherein the instructions, when the computer program product is executed on a computer, cause the computer to carry out the method according to any one of claims 1 to 13. [15] Development system for the computer-aided generation of a computer program using the method according to one of claims 1 to 13.

Images