MXPA00006512A - Program flow method and method for expanding a program component system - Google Patents

Abstract

The invention relates to a program flow method in a program component system which has a running time system (14) and a number of components (20, 20', ...). The inventive method comprises a data acquisition of data pertaining to a second component (20') in the first component (20) independent of programming-defined interfaces in the second component (20'), said data acquisition being conveyed by the running time system (14). The inventive method also comprises a data acquisition of data pertaining to the first component (20) in the second component (20') independent of programming-defined interfaces in the second component (20'). In a method for expanding a program component system around an additional component, the invention provides that docking points are to be searched for the additional component, and the respective components (20, 20',...) of the program component system in which at least one docking point has been found are to be changed by registering call information on each docking point which has been found. The invention permits an especially flexible and extensive expansion of a program component system.

Description

PROCEDURE OF PROGRAM SEQUENCES AND PROCEDURE FOR THE EXTENSION OF A SYSTEM OF PROGRAM COMPONENTS The invention relates to a program sequence as well as the expansion of a system of program components, which is also referred to as "Componentware". In particular, the invention relates to a method for executing program sequences in a system of program components as well as to a method for extending such a system.

US Pat. No. 5.63,124 (Khoyi et al.) Discloses a method for integrating data through object management, in which a multitude of object managers and ur are employed. -administ ador "" .3 link In the article "Componentenware" - von der Komponente zur Applikation "by Michael Stal, published in the journal OBJEKTspektrum, No. 3, 1997, pages 86 to 89, the principles of systems components of programs are described. Creation of very expensive software of time, necessary until now, by a simple "wiring" of predetermined components.These components must be able to be used in different contexts, without the manufacturer of the components having to know details of the source code on which it is based a component For the production of ccrryonentware, several complementary technologies are available, including distribution platforms, container platforms and composite document technology.

In the distribution platforms, conventions and tools are prepared for the distribution of components beyond the limits of the computers as well as for the communication between the components. As industrial standards, so to speak, the following distribution platforms have been implemented: DCOM (Distributed Component Object Model) from Microsoft, CORBA (Common Object Request Broker Architecture) from OMG (Object Management Group), JAVA-RMI (Remote Method Invocation) ) of JavaSoft. Container platforms contain a number of solution-oriented software components to cover at least partially a certain area of tasks (eg, storage, financial accounting, ...) and custom standardized logical units ("Middleware") (such as , for example, a graphical user interface) to enable interaction between the components and the user. The technology of composite documents allows an integration of different applications. A composite document comprises several components (for example, tables, graphs, texts, ...), each of which is responsible for an application. Known architectures for composite documents are, for example, Microsoft ActiveX, OpenDoc from CILab and Java Beans from JavaSoft. However, in the available procedures there is a problem that the functionality of a component can only be used exclusively through interfaces, which have been previously defined by the manufacturer of the components. These interfaces are especially the methods or parameters previously defined by the manufacturer of the components. There is no possibility of extending the functionality of a component independently of the manufacturer of the components, since the source code of the component is not, in general, available. A simple possibility of creating parameters, as it may be provided, if necessary, does not represent an extension of the functionality of a component, since all possible functions must already be originally planned by the manufacturer of the components. Accordingly, the invention has the task of enabling, in a system of program components, a possibility of especially flexible and extensive expansion. In particular, it must be possible to modify and / or extend the functionality of a component, without this knowledge of the source code of the component to be expanded being necessary. According to the invention, this task is solved by means of a procedure for executing program sequences in a system of components of the program with the features of claim 1 as well as by means of a procedure for expanding the system of components of the program with the characteristics of claim 10. Next, the component to be expanded is designated as "base component" and the new component to be added as "extension component". The invention starts from the basic idea of achieving a possibility of almost discretional expansion of the base component, dispensing with the need for an expansion interface, defined by the programmer, in the base component. Instead, the manufacturer of the extension component establishes how the extension component should cooperate with the base component. This basic idea represents an inversion of the usual principles up to now in computing (encapsulation, information concealment, ...). However, it is surprising that, precisely through this separation from the established principles, relatively large software systems can be realized in a surprisingly short time also by non-programmers. The consideration according to the invention of not letting the expansion interfaces be established by the programmer of the base component but by that of the extension component, conditions an inversion of the habitual way of thinking during the program sequence as well as during the incorporation of a component of expansion in an existing component system. These two cases are the subject of independent claims 1 and 10. During the program sequence, the components normally require mutual data to process them and generate results. It is known that a calling position provides data to a called position and returns the results with a backward jump. However, this procedure assumes that the call interface is previously defined by the programmer of the calling procedure. Instead, according to the invention it is provided that the called component acquires the necessary data by itself - through a system of its own execution time. This process is referred to below as "data provision". In the component, for which the data is provided, no special interfaces should have been established by the programmer. Accordingly, a task of the named component is to store the results in suitable places of other components. This process is designated as "data evacuation". Here, too, it is not necessary for the programmer to provide special interfaces for data evacuation. In this context, the simple definition or declaration of a data field or a variable (if applicable, including an indication of the type and other parameters) should not be considered as an "interface". Instead, it would be an interface, for example, procedural instructions, which must be inserted by the programmer explicitly into a component registration to induce or enable a data transfer at runtime. During the incorporation of an extension component into a system of components of the existing program, the known principles are reversed in a corresponding manner. Normally, it would be expected that the previous components of the program component system would remain unaltered through the extension. On the other hand, according to the invention, provision is made for searching in the program component system for attachment points for the extension component, and for those components of the program component system, in which at least one point has been found, to be modified. of mooring, being recorded at each mooring point found a call information on the new component. Therefore, each component of the entire system of program components is potentially modified. By means of the solution according to the invention, it is possible to make extensive extensions of the functionality of a system of program components, without such possibilities having to be already planned, planned or preconceived by the programmer. This represents an essential advance over the systems of program components known up to now. By the term "runtime system", all generic routines are understood in the terminology of this application; therefore, those routines that are not explicitly predetermined by the programmer. In this regard, the runtime system may also have portions that are contained in the components. For example, that part of the runtime system, which performs the data transfer, may be shifted to the individual components. The data transmitted during the provision and evacuation of data are not, preferably, accessible in general, but are associated with that component, by which the data is provided or to which they are evacuated. These data are transmitted, in preferred embodiments, while the mentioned component is inactive. In particular, this component can be evicted from the regular working memory at the time of the provision and evacuation of data. Preferably, during the provision and / or evacuation of data, local and / or non-persistent data are transmitted, therefore, they are not transmitted, in particular data available globally. Preferably, the provision and / or evacuation of data is done without the cooperation of the component by which the data is supplied or to which the data is evacuated. For example, it can be provided that, during a data evacuation, only the component carrying out the evacuation as well as the execution time system participate. That component, in which the data are deposited, has no possibility of influencing preferred embodiments. Preferably, during the execution, a component is previously notified to those data fields for which a data evacuation is necessary.

These can be especially data fields, whose contents were determined through a provision of data and on which a write access is made.

Preferably, it is further provided that a called component can directly access, for reading and writing, data fields defined and / or available in the calling component. This makes possible an exchange of data, so to speak, without interface, between the two mentioned components. The call of a component is preferably activated by means of a call information or message contained in a mooring point of the calling component. The use of tie-down points, which can receive call information, enables a particularly flexible extension of the functionality. All potential interaction interfaces of a component are predefined as preferential binding points. Such interaction interfaces can be fields of the interaction screen, for example input fields or switching areas. In addition, all output fields of a print mask and / or all persistent data access operations (e.g., opening, reading and writing a file or a database) may be provided as interaction interfaces. Interaction interfaces may also be provided, in preferred embodiments, by the one-component programmer. Preferably, during the incorporation of another component into the program component system, all possible tie points are automatically identified (and without knowledge of the source code of the existing components). In this way an extension with reduced programming expense is possible. In addition, preferably, all suitable call information is recorded in at least one tie-down point. In preferred embodiments, the method for extending components comprises the additional step of generating at least one component as a binary object. Especially, for each mooring point found, a binary object can be generated exactly or at most. In this binary object, the memory allocation of the system components of the program can be taken into account in the subsequent execution time. Other preferred embodiments are subject of the dependent claims. An exemplary embodiment of the invention and several embodiments are explained more exactly below with the help of the schematic drawings. Figure 1 shows a principle representation of the system of program components during the execution time. Figure 2 shows a principle representation of a binary object. Figure 3 shows a flow diagram of component instantiation. Figures 4a to 4c show a flowchart of the calculation sequence at runtime, including a change of components. Figure 1 illustrates the structure of the system components system during the execution time. An operating system 10, for example a conventional window operating system, expanded pole with a distribution platform layer 12, for example DCOM or CORBA. A runtime system 14 is installed on the distribution platform layer 12, which is also referred to as "Middleware" (custom standard logical units). The operating system 10 prepares a working memory area 16, which is managed and used by the runtime system 14. In a variant embodiment, the distribution platform layer 12 is omitted, and the runtime system 14 is installed directly on the operating system 10. The component system of the program is made by a commercially available computer, for example by a compatible PC computer. In addition to the runtime system 14, the program component system has a container environment 18, which contains several components 20, 20 ', 20", 20"' in the form of binary objects. The components 20, 20 ', 20", 20"' determine the behavior of the system of program components. These components are called by the runtime system 14 - for example, according to events that are caused by the user. A component 20 in the binary object format has, as shown in Figure 2, several sections, and in particular a program section 22, a section of tables 24, a directory section 26 and a memory box section 28 The section of the program 22 contains an interpretable code, which is interpreted at the runtime by the runtime system 14 and determines the behavior of the component 20. The code contained in the section of the program 22 is in an intermediate format, that allows an efficient execution in the execution time of the program. In alternative embodiments, an adequate compilation of the code for immediate execution is provided under the control of the operating system 10. In the section of tables 24, the tables of the execution time for the configurable properties and parameters of the code are stored. These are, for example, information on window sizes and colors for the representation on the screen or information for the representation of the printing. In addition, the runtime tables contain management information for memory allocation. Directory section 26 contains the directory of mooring references, a memory directory, a data transfer directory and a directory of methods. The memory directory contains the designations available in the component for memory fields, information on memory fields as well as references (more exactly, offset values or offset values). The methods directory contains a list of the methods prepared by the component. These two directories are contained in the binary object, so that it is possible, also without the knowledge of the source code of a component (registration of components), an extension of the functionality of a component. All the fields of the memory contained in the memory directory are accessible from other discretionary components by means of data provision and data evacuation operations, and can be read, modified and described. In the embodiment described here, the programmer has no possibility to protect individual fields of the memory from external access. The information, which is needed during the execution time for the provision and evacuation of data, is contained in the data transfer directory. In the section of the memory frame 28, three related data areas 30, 32, 34 are provided, whose limits are indicated by the administration information in the execution time tables. The first data area is designated below as access data area 30. It is reserved for data that comes from a higher order component within the call hierarchy. The called component can read, process and write this data, without requiring a programmable data transfer. The transmission to a procedure programming language corresponds approximately to the possibility of directly accessing variables that are defined in a statically higher order procedure. The size of the access data area 30 is set during the instantiation of a component 20. This is possible because each component 20 is associated, in the binary object format, exactly only to a possible call station (a tie-down point) . The size of the access data area 30 of a component 20 is the sum of the sizes of the access data area and the local data area (yet to be described) of the calling component. As a second data area in the frame section of the memory 28 of a component 20, a local data area 32 is provided. This data area is directly connected to the access data area 30. It contains those data that are defined again in component 20. A definition of this type can be made directly in the component or indirectly - for example, by means of a reference to a screen mask or a printing format. Transmitted to a procedure programming language, the local data area 32 contains approximately the local variables of a procedure. Finally, as a third data area in the memory box section 28, a transfer data area 34 is provided. The transfer data area is reserved for the intermediate storage of data, which are provided during the execution time. of the program by another component according to the principle of provision of data and that are evacuated to it in accordance with the principle of data evacuation. When a component 20 is installed, that is, when it is transferred from a component inscription to at least one binary object, the access data area 30 and the transfer data area 34 do not have to be occupied with defined data, because these areas are overwritten anyway at runtime. The local data area 32 is filled with predetermined standard values for the individual data types. During the execution time of a system of components of the program, the three data areas 30, 32 and 34 of a component 20 serve for interim storage of the respective current state of the system during each call of another component and for the partial restoration of This state (relative to the local data area 32 and the data transfer area 34) during a backward jump. For the generation of a component, the programmer creates an inscription of the component, which is suitable for automatic transfer by means of a generator system. This transfer process, also referred to as instantiation of a component, is described more exactly below. The inscription of the component represents the definition of the component to be generated. Contains instruction lines, which are transferred as component's interpretable code. The programming language used is known per se and is based on principle object-oriented. In addition, the inscription of the component may contain instruction lines, which determine pre-conceived tie-down points by the programmer for extensions. Optionally, data and parameters can also be contained in a component inscription, for example parameters for visual representation of data or an enumeration of admissible input values. In addition, instructions for calling "external programs" may be contained in the component registration. During the execution time, the corresponding program is started, for example a COBOL program. This program can now use, for its part, system interfaces of system components and, for example, start other components. In addition, the registration of the components may contain references to masks and screen formats as well as printing formats to be used. Such screen masks or printing formats are previously developed by means of a suitable graphic tool. The tool ("Trainer-GUI") generates several global directories, which are accessed during each process of instantiation of a component. It is first of all a global directory of screen masks and printing formats available, secondly of a directory of predetermined mooring points by means of these masks and formats, and third of a directory of designators. and types of expected data in the input fields or print fields defined. In the event that the component registration is the definition of an extension component, therefore, of a component that must extend an existing component (base component), then the component's registration also contains a provenance parameter , which specifies the desired tie points for the extension of the component. The origin parameter can define, as already explained, more than one base component or more than one mooring point. As mooring points serve generic points of the base component or points indicated by the programmer, in which you can insert a call information for an extension component. The tie points of a component in binary object format can be identified automatically, so that an extension of components is possible without knowledge of the source code of the base component. In the embodiment described here, four types of lashing points are provided. In the first place, all the input fields and other control elements (buttons, switching areas, ...) are provided as mooring points in the screen masks, accessed by the base component. In this way it is possible, for example, to call extensions of components whenever the user performs an interaction with an input field of the base component, for example enter a value or activate the input field or move with the mouse pointer. The base component programmer does not need to explicitly foresee this possibility. In the same way, all the input fields of the printing masks serve as lashing points, so that, for example, by means of a component extension, the output values of a table to be printed can be modified. All the operations of the base component on persistent data (for example, access to files or databases) are also provided as tie points. Here, too, expansion components can be "temporarily connected", without the programmer of the base component having to expressly indicate it. Finally, as already mentioned, a component may also contain tie-down points determined by the programmer at discretionary places in the program sequence. In alternative embodiments, more tie-down points or other tie-down points are possible.

Each lashing point has, in the embodiment described here, several mooring places ("slots"). In this way, several extensions of components can be connected in a single mooring point. In the case of a mooring point, which is associated with an entry field, there are provided, for example, a main mooring place and five secondary mooring places. An extension of components possibly registered in the main mooring place is called whenever the user activates the entry field. Optionally, this component can also be called in each indication of the input field, therefore already before a user action. On the other hand, the secondary mooring places can be associated, for example, with the activation of certain function keys or other user actions. In the output fields of the printing masks, the activation of the tie-down locations of a tie point can be determined, for example, by means of a user input at the time of the start of the printing process. In alternative embodiments, other call strategies or other amounts of mooring sites are possible (eg, only one for each mooring point). The instantiation of components with reference to Figure 3 is described in more detail below. As already mentioned, instantiation means the transfer of an inscription of a component to at least one binary object. In the embodiment described here, during the instantiation, a component is generated as a binary object for each mooring point found. The instantiation process, which is performed automatically by the generator system, begins with the registration of the component registration (step 40). In step 42, a first tie point is now sought. When the inscription of the component to be transferred contains only the identifier of the container as the origin parameter, a generic tie-down point is assumed in the environment of the container 18 (figure 1). This allows an instantiation of "root components", therefore, of components that do not represent extensions of components. On the other hand, if the inscription of the component to be transferred contains a parameter of "authentic" origin, then it defines the mooring points provided for the extension of the components. To this end, there are several possibilities. When, for example, an input field of a screen mask must serve as a tie-down point, then the source parameter can both indicate the name of the field and the desired tie-down point within the tie-down point (number of "slots"). ") as you can also specify the base component. Alternatively, it is also possible to record only the name of the field and, if necessary, the number of the slots in the origin parameter. All the places in the binary objects, which currently exist in the system of program components, in which a screen format is referenced, which uses the aforementioned field as the input field, are then used as tie points. If a first tie-down point has been found (query 44), then a suitable call information is first recorded. ", Eg a message (" message ") that is used for component call? & , in the base component containing the tie-down point (step 46) The base component is read for that purpose in the binary object format, the reference to the extension component is registered in the base component and the modified binary object of this In this case, the parameter • of origin determines in this case the place of mooring ("slot") inside the mooring point in which the call information must be recorded and the action that the user must carry out to make a call of the extension component After the modification of the base component containing the attachment point found, the extension component associated with this mooring point is formed as a binary object (box 48). First, the attachment points of the extension component are determined and recorded in the corresponding directory in section 26 of the directory of component 20 (step 50). For this purpose, all screen masks and all printing formats are investigated, to which the registration of the extension component refers. In addition, an access to the global directory of the tie points defined by these masks and formats is carried out. The information contained there is received as mooring references in section 26 of the directory. In addition to the name of a built-in screen or print field there are, for example, information about the field type, the memory space requirement of the corresponding data value, and so on. In addition, the inscription of the component is investigated to locate mooring references, which were indicated by the programmer (construction INTERFAZ-ES <; Name > ). These mooring references are also received in section 26 of the directory. Finally, section 26 of the directory also records all relevant tie-down references for all persistent data access operations (for example, READ <Entity Name> construction) found in the component entry. In step 52 below, the organization of the runtime memory is instantiated. To this end, first determine field designations in the screen masks and in the print formats referenced by the extension component, which are not already defined in the base component. These field designations - if they do not match records in the access data area 30 - are considered as local variables of the extension component. All field designations are registered in the memory directory in section 26 of the directory. In addition, a transfer list is placed to transmit, during the execution time, the screen data and the print data from a buffer to the memory area of the extension component (access data area 30 or storage area). local data 32 or transfer data area 34). This function is performed automatically at runtime, without requiring explicit programming. As another part of step 52, the static definitions of the memory contained in the component registration are now processed. Since the base component is clearly established, the sizes of the three data areas 30, 32, 34 of the binary object 20 can already be determined in the instantiation time. In addition, the directory of the memory in the section can be created entirely 26 of the directory. In the first place, all the static definitions of the memory (construction INHERIT-DATA <Name>), which are already defined in the base component, are searched in the component registration. The corresponding data values are found during the execution time in the access data area 30 in the same place (the offset or offset value) as in the base component, since the area of the working memory 16 , which is occupied by the access data area 30 of the base component, is used again during the call of the extension component. In the directory of the memory of the extension component, therefore, registers corresponding to those of the base component are received. These records contain the name and type of the data value as well as the length of the field and the offset value. Finally, those static definitions of the memory of the inscription of components that are associated with the local data area 32 are processed. First, there are definitions of memory fields, which are not defined in the base component, and in second place of memory definitions, in which a local storage has been expressly indicated (construction INHERIT-DATA-LOCAL <Name>). For such memory definitions, a free address is determined and reserved in the area of local memory 32. Said more exactly, the next free address is used in relation to the current level of memory (which depends on memory occupancy). of the base component and possibly of already assigned local fields of the extension component Also for these definitions of the memory corresponding registers are received in the memory directory of the extension component As step 54 below, the provision and evacuation of data of the extension component, which takes place at the time of execution, applying the directory of data transfer in section 26 of the directory.To this end, the definitions of the provision and evacuation of data in the registration of the These definitions have the following form, in which INH stands for "inherit" and "IME" stands for "Import". n / export "INH-DATA-IME < Identification of the component, with which the provision and evacuation of data takes place > INTERFACE = < Name of the field_l > < Name of field_2 > < Name of the field__n > END OF THE TRANSFER After locating a definition of this type, the address directory of the addressed component is evaluated. At the time of execution, information is recorded on the data fields to be exchanged (field type, field length, address or offset) in the area of the work memory 16. In addition, a corresponding field of the memory in the memory is reserved. transfer data area 34, if the addressed field is not contained in the area of the access data 30. From this information a corresponding record is generated in the data transfer directory of section 26 of the directory of the data component. extension. This register therefore contains the association of the memory field of the component addressed to the memory field in the transfer data area 34 of the currently instantiated component. The addressed component does not need to be the base component, and the address field of the memory in this component can be in one of the three areas 30, 32 and 34. Consequently, provision and evacuation of all the data, which is available, is possible. available in another discretionary component. Now the code generation is done (stage 56), in which the instruction lines contained in the inscription of the component are converted into an appropriate intermediate code, which can be interpreted by the runtime system 11. The generation of the code is done according to principles known per se . The component is now combined in the format of the binary object from the components that have been generated in the stages described so far. The resulting binary object has the structure shown in Figure 2 and already described above. In another step, it is stored (step 58). In this way the generation of a binary object for a mooring point is completed. In the instantiation procedure, a next tie point is now sought (step 60). In case there is a mooring point of this type in the component system of the program, another binary object is generated; in another case, the instantiation is terminated. The binary objects generated from an inscription of the components differ at the most in relation to the occupation of the memory defined in the memory directory. However, if several tie points have been found in a base component, then this occupation of the memory is in the general case identical. This case can also appear when several tie-down points have been found in different base components. Therefore, in an alternative embodiment it is provided, for optimization, to generate only once in each case identical binary objects. For the realization of the sievema of components of the program the structure represented in figure 1 is formed. To this end, the system of execution time 14 and the environment of the container are loaded first. 18. The environment of the container 18 contains a catalog of the menu records visible at startup. This catalog is defined by the components 18. Save from start a root component, which was generated autonomously by the generator system in the stay process described above. The runtime system now awaits an event triggered by the user, for example a menu selection, through which the call of a "own" component of the program component system is indicated. Figures 4a to 4c show the program sequence procedure, which is carried out with the call of components as well as with the execution of the called component. In the exemplary embodiment considered here, one component is always active at the execution time. Immediately after the system boot, this is the root component described above. Only the active component in each case is in the area of the working memory 16. In this case, the component has the binary object structure shown in FIG. 2. In alternative embodiments, it is also possible to carry out an almost parallel sequence of several components (for example, through "multi-threading"). The control is then performed through the operating system 10 that serves as the basis. When a new component is to be called, for example in reaction to a user input or action, the state of the precisely active component is first assured (step 70). This means at least that part of the area of the working memory 16, in which the section of the frame of the memory 28 of the component is located, is transmitted to a file or to another security area. In the embodiment described here, even the whole binary object is ensured, because its remaining sections are not taken account in relation to the memory requirement. In addition, all the data evacuation processes that have been announced during the cycle of the active component up to now are carried out (step 72). Indeed, in order to increase the efficiency, it is foreseen in the embodiment described here, to transmit only those fields of the memory of the data transfer area 34, to which a write access takes place, again from the current component to the component referenced by means of data evacuation. In alternative embodiments, no prior announcement of the modified data is carried out, but, every time a change of components occurs, all the data fields contained in the transfer data area 34 are transmitted to the components referenced in each case. During each data evacuation process, the data transfer directory of the current component is used to determine the referenced component (s) and the corresponding data field (the corresponding data fields) in its (s) section (s) of the memory 28 and transmit the data there.Therefore, a binary object of a currently inactive component is modified through each data evacuation.At the time of execution, a component may have been called several times and may have been partially executed, in this case, several versions of the component are secured.The data evacuation takes place in this case in that secured version of the component that is closest to the call chain of this component. it leads to the active component at the moment In alternatives of realization, another selection or a selection determined by the programmer of the version of the component is made In the following step 74, the new component called as binary object is now loaded in the area of the working memory 16. In this respect, the part of the area of the working memory 16, which has been used for the sections of the program, tables and directory 22, 24, 26 of the old component. Also the local data area 32 of the frame section of the image 28 of the new component is loaded in the area of the working memory 16. In this way, during the start of the new component, all the local data is previously occupied with standard values defined. However, that section of the area of the working memory 16, which corresponds to the area of the access data 30 of the called component, is not overwritten. In this way, the data values stored there are not lost in the case of a component change. The new component can access, instead, through the access data area 30, directly to memory fields that are defined in the calling component. The size of the area of the access data 30 is determined according to the distribution of the memory calculated in the instantiation phase. In case the calling component accesses totally different values than the component called, then the access data area 30 has the size zero. After the called component has been loaded as a binary object, the code contained in section 22 of the program is interpreted instruction by instruction. During the execution of an instruction (step 76) some special cases must be taken into account. If. the instruction is a memory operation, whose destination is the area of the transfer data 34 (query 78), then the respective field of the memory is pre-marked for a further evacuation of the data (step 80). A pre-mark of this type is also possible through an express instruction. If the current instruction is an instruction that causes a provision of data from a referenced component (query 82), then the steps shown in Figure 4b are executed. An instruction of this type is, for example, the INH-DATA-IME construction described above, which is written, in the embodiment described here, both as a statement of provisioning and data evacuation relationship as well as a instruction for the provision of data. In implementation alternatives, all the data referenced by a component are already supplied during the start-up of this component. In the data provisioning procedure according to FIG. 4b, it is first verified whether the referenced component has already been executed (at least partially) (query 84). If it is not, then valid data can not be supplied, and a runtime error is triggered. In contrast, if a secured version of the referenced component is present, then the necessary data is loaded from it and written to the transfer data area 34 of the currently active component. The respective spaces of the memory in the referenced component and in the active component are deduced from the data transfer directory of the active component. Aguí (in a similar way to step 72) it may happen that several versions of the referenced component are stored. Then that version is used for the provision of data, which has been carried out last in the call chain that leads to the active component. In alternative embodiments, other planned or programmable selection strategies are possible. At the end of the data provision, the sequence of the program continues in step 76 (Figure 4a). In query 88 (figure 4a), it is verified whether the currently interpreted instruction is an instruction for the component change, that is, to call a new component. An instruction of this type can be especially a call information (message) stored in a tie-down point. As already described, a call information of this type leads, according to the type of the tie point, either through its simple presence or previous predetermined action of the user, to the call of the component indicated in the call information. When a call of this type takes place, the current level of the instruction counter is secured in a stacking memory and a new instance of the procedure represented in FIG. 4a is initiated. The query 90 refers, finally, to the case in which the realization of the current component is completed on a regular basis. If this is not the case, the execution of the program continues with step 76. On the other hand, if the end of the program is reached, the procedure shown in FIG. 4c is executed. In a manner similar to step 72, all previously marked data provisions are executed first (step 92). Next, in the area of the working memory 16, the state of that component that has called the current component (step 94) is reset. This affects sections 22, 24 and 26 as well as local data area 32. In contrast, the section of the working memory area 16, which corresponds to the area of access data 30 of the calling component, is not reset., so that a return of the values of the access data area 30 from the current component to the calling component is possible. After restoration of the calling component, the present instance of the procedure shown in Figures 4a to 4c has ended. The execution of the program continues in the previous instance at the place where the call of the original component was caused (step 76). By means of the methods described herein, an extension of the functionality of the components is possible in a relatively simple manner. For example, a base component is assumed, which performs a price location procedure, which is based on an individual price to be entered by the user (through an entry field). By means of an appropriate extension component, this base component can be expanded with an individual price location procedure related to the application. The call information for the extension component is written for that purpose at a tie-down point, which is associated with the entry field for the individual price. The individual price calculated by the extension component is inscribed in the base component through the data evacuation procedure. Other data values, which the extension component needs to locate the price, are called by means of the procedure of provision of data from other components. It is not necessary that during the programming of the base component or of the other components the possibility of an extension of the functionality of this type be taken into account. The programming of larger software systems can be simplified in different ways. For example, it is possible to define the so-called "adaptation components". An adaptation component is an extension component that refers directly to another component. In this way, the other component can be used several times with different names.

Claims (16)

Claims

1. Procedure of sequences of programs in a system of components of the program, which has a system of execution time (14) and several components (20, 20 ', ...) with a respective section of the program (22), are the following steps during the execution of the program section (22) of a first component (20): a) provision of data, switched through the runtime system (14), from a second component (20 ') to the first component (20) independently of the interfaces defined by the programmer in the second component (20 '), b) data evacuation, switched by the runtime system (14), from the first component (20) to the second component (20) '), independently of interfaces defined by the programmer in the second component (20').

2. Method according to claim 1, characterized in that the data transmitted during the provision of data is transmitted from a section of the memory frame (28) of the second component (20 ') to a transfer data area (34) of the first component (20) and / or because the data transmitted during the data evacuation is transmitted from a transfer data area (34) of the first component (20) to a frame section of the memory (28) of the second component (20). ').

3. Method according to claims 1 or 2, characterized in that the provision and / or evacuation of data are carried out without the cooperation of the second component (20 ')

4. Method according to one of claims 1 to 3, characterized in that the second component (20 ') is inactive during the provision and / or evacuation of data.

5. Method according to one of claims 1 to 4, characterized in that the transfer data area (34) of the second component (20 ') is located, during the provision and / or evacuation of data, in a security area.

6. Method according to one of claims 1 to 5, characterized in that during the provision and / or evacuation of data, local and / or non-persistent data of the second component (20 ') is transmitted.

7. Method according to one of claims 1 to 6, characterized in that during the execution of the program section (22) of the first component (20) it is previously announced for which data of the first component (20) a data evacuation is necessary.

8. Method according to one of claims 1 to 7, characterized in that a called component (20, 20 ', ...) can directly access an access data area (30) containing the defined data fields and / or available in the calling component (20, 20 ', ...).

9. Method according to one of claims 1 to 8, characterized in that the call of a component (20, 20 ', ...) is activated through a call information, which is contained in a tie-down point of the component that call.

10. Procedure for the expansion of a system of components of the program, which has several components (20, 20 ', ...), with an additional component, with the steps: a) find tie-down points for the other component, corresponding to a provenance parameter determined by means of a definition of the other component, in the system of components of the program, and b) modify those components (20, 20 ', ...) of the system of components of the program, in which it has been found at least one tie-off point, registering at each tie-down point found a call information to the other component.

11. Method according to claim 10, characterized in that all interaction interfaces of the above components (20, 20 ', ...) are predefined as potential tie points.

12. Method according to claim 10, characterized in that all the fields of the interaction screen and / or all the output fields of the printing masks and / or all the persistent data access operations, referenced by the previous components (20, 20 ', ...) are predefined as potential tie points.

The method according to one of claims 10 to 12, characterized in that by means of the registration of the call information at a tie-down point, a call is made of the other component from the component, in which the call information has been registered. .

14. Method according to one of claims 10 to 13, characterized by the additional step: c) generating at least one binary object from the definition of the other component.

15. Method according to claim 14, characterized in that a binary object is generated for each mooring point found.

16. Method according to claim 15, characterized in that during the generation of each binary object, the memory allocation in that component (20, 20 ', ...) of the system of components of the program, which has the mooring point, is taken into account. base.