DE4326472A1 - Method and device for reprogramming existing applications using object-oriented technology - Google Patents

Description

The invention relates to a reprogrammer according to the Preamble of claim 1.

The object-oriented programming approach is increasingly being used by Software developers used since he was developing, building of prototypes, code reuse and maintenance of programs significantly simplified. The best would be discard all existing programs and write new ones, to take full advantage of this approach. Unfortunately it is this because of the number of programs and the associated Investments not possible. So there is a need for one System that can analyze the existing programs around the Convert code into a form that is object-oriented Compilers can be used.

Such a system is from the article "Class and Object Extraction from Imperative Code "by C.L. Ong and W.T. Tsai in the J. Object Oriented Program, Vol. 6, No. 1, March / April 1993, pp. 58-60, 62-68 known. Here an "extractor" is described, the Classes and objects from one written in Fortran 77 Program pulls it out and into object-oriented C ++ code converts.

Also known from the article "Domain Model-Driven Software Reengineering and Maintenance "by S. Jarzabek in J. Syst. Softw., Vol. 20, No. 1, January 1993, pp. 37-51, is a process for Decompilation of economic systems to a library of manufacture reusable software components.

Decompilation or "reverse engineering" as a means of Improve maintenance and development of software products is in an article "Reverse Engineering and Design Recovery: a  Taxonomy "by E.J. Chikofsky and J.H. Cross in IEEE Softw., Vol. 7, No. 1, January 1990, pp. 13-17 in general.

The underlying object of the invention is a improved system to develop the existing code into one Form converts so that he can build new products can be reused. In addition to converting to Object-oriented program structures should also include old ones User interfaces in modern graphic User interfaces are converted, and client / server Structures are supported.

This object is achieved according to the invention by a device the characterizing part of claim 1 and a method the claim 5 solved.

Show it

Fig. 1 shows an overview of the Umprogrammierers according to the invention,

Fig. 2 shows the structure of an object, which stores the information from the existing code,

Fig. 3A, the representation of a display content to a mainframe (starting point for a conversion)

Fig. 3B, the illustration of a window on a graphical display (result of the conversion)

FIG. 4A is a CICS BMS MAP for the displayed screen image,

FIG. 4B is a PL / 1 declaration for further information on a mainframe, which describes the mainframe application,

Fig. 5 is a flowchart for the inventive method,

Fig. 6 is a definition of the abstract object specification,

Fig. 7 is a definition for the data object specification,

Fig. 8 is a view definition for the specification object,

Fig. 9 is a definition for the presentation specification object.

Fig. 1 represents an overview of the inventive system for reprogramming of existing code. Code 10 which is converting in object oriented form, is stored in a memory or on a disk. This code 10 consists, for example, of data declarations written in an imperative language such as PL / 1 (see FIG. 4A), of user interfaces UI (see FIG. 4B), of a module written in a job control language JCL of an operating system, of a " entity-relationship "- (entity-attribute) model E / R, or from other parts of a program.

The code 10 is read out of the memory by means of an ordinary method and fed to a reprogrammer 20 running in a processor, where it is analyzed. As explained in more detail below, an object specification is created from this. The object specifications created in this way are then stored in a memory 30 . The reprogrammer 20 has the function of accessing the object specifications stored in the memory 30 in order to generate object-oriented code 40 which is also stored in a memory or on a data carrier. Object-oriented code 40 may include, for example, user interfaces UI, programs written in C ++, or other object specifications, e.g. B. Specification according to the CORBA architecture (Common Object Request Broker Architecture). This architecture is described in a publication "Common Object Request Broker: Architecture and Specification", which is published by the Object Management Group and X / Open (document No. 92.12.1). After generation, the object-oriented code 40 can either be compiled immediately thereafter or combined with another code written by a programmer and only then compiled. Such compilation steps are already known in the prior art.

FIG. 2 shows an overview of the object structure that the reprogrammer 20 creates from the existing code 10 . The object specification itself is stored as an object and is called the object specification object (OSO) 100 . The structure consists of a bundle of four object classes, namely an abstract specification object 105 , a data specification object 110 , view specification objects 120 and one or more presentation specification objects 130 .

The abstract specification object 105 describes in an abstract manner the interface for the outside world to the functions that the code 10 to be converted offers and the properties of these functions.

The data specification object 110 describes the methods of accessing the data of the existing code 10 . It shows the type of data storage, e.g. B. Repository, SQL database, and also the detailed parameters that are necessary to access the data.

The view specification object 120 determines a logical view for the user interface. To enable this, it contains references to the information contained in the abstract specification object 105 .

The presentation specification object 130 defines a concrete user interface for an interface technology.

There is a separate presentation specification object 130 for each interface technology, that is, there is one presentation specification object 130 for command mode, another for graphical displays on a screen, and another for voice input mode. The presentation specification object 130 also determines what type of presentations are shown, e.g. B. icons, setting sifting, etc. The presentation specification object 130 refers to the information in the abstract object specification 105 and in the inspection object specification 130th

The input codes 10 contribute to the creation of abstract specifications, data specifications, view specifications and presentation specifications to different extents.

As shown in FIG. 2, the data view and presentation specification objects are all associated with an abstract specification object 105 and they all have access to the information contained in the abstract specification object 105 . This association is necessary for the further development of the object-oriented code.

The abstract, data, view and presentation specification objects 105 , 110 , 120 , 130 each consist of certain sub-specifications. The sub-specifications for the presentation specification object 130 can be, for example, input fields, radio buttons, push buttons, check boxes, menu items, windows, etc. The partial specifications for the data specification object 110 describe where or under which name certain data can be found in a database. The partial specifications for the view specification object 120 primarily specify whether certain object parts are displayed in a certain view. The partial specifications for the abstract specification object 105 define the abstract, ie the view and presentation-independent attributes such as. B. Names, data types and lengths.

Just as the data, view and presentation objects 110 , 120 , 230 as a whole are associated with the abstract specification object 105 , the same also applies to the respective sub-specifications. The related partial specifications can only be deleted or moved together, and only certain types of partial specifications can be associated with each other.

An example of the reprogramming of an existing mainframe application using the object specification object 100 now follows. Fig. 3A shows a screen image 200 on a screen for the input of parameters 210, 220, 230, 240, which are necessary for the order of a table. The screen content 200 is to be converted into the form of a window 300 on a graphic screen. The window is defined using a "CICS BMS Maps", a specification language that is very common in mainframes. The definition for the screen shown in Fig. 3A has a form shown in Fig. 4A.

The use of the screen content 200 shown in FIG. 3A also includes the definition of a data structure in which the information entered about the table ordered is stored. The definition of the data structure in the programming language PL / 1 is shown in Fig. 4B.

The reprogrammer 20 can examine the definitions shown in FIGS. 4A and 4B and create the object specification object 100 therefrom. Fig. 5 illustrates a flow chart describing the operation of the Umprogrammierverfahrens.

In a first step 500, reprogrammer 20 examines the definitions of screen window 200 and the data structure. First, the abstract specification object 105 must be created. The created specification for the abstract specification object 105 is shown in FIG. 6. As listed above, the abstract specification object 105 describes in an abstract manner the interface for the outside world to the functions that offer the definition to be converted and the properties of these functions.

In step 510, the object classes are identified. An object class in the object-oriented programming approach is a data structure in which the individual members of the object class, the so-called instances, have common properties. In this simple example, there are three object classes: "table", "table top" and "table legs". All members or copies of the data structures "table", "table top" and "table legs" have the same properties and therefore each form an object class. The object classes "table top" and "table legs" are included in the main class "table". The definition of the object classes can often be recognized from the input codes 10 (in this example from the PL / 1 declaration shown in FIG. 4B), but in some cases additional information from the user of the reprogrammer is also required. In general, each of the steps shown in Fig. 5 may require user interaction in more complicated examples.

In the next step 520, the methods in the definitions that act on the classes are identified. Methods in the object-oriented programming approach are procedures with which one can change the class or the individual members of the class. There are two types of methods: class methods affect all members of the class, whereas instance methods only affect individual members of the class. The methods are communicated to the reprogrammer by naming the assigned function programs and / or via the assigned screen window ( FIG. 3A).

The example shown in FIG. 3 leads to the "create" class method, ie new members (so-called copies) of the class can be created. Two copy methods can be identified: delete and copy. You can use the delete instance method to delete an instance of the class and the copy instance method lets you copy an instance.

Every method needs certain parameters for its effect. These parameters can also be seen from the definitions and are recorded in step 530. The create class method needs all the parameters shown on the screen, ie order no. 210 , table type 220 , price 230 and material 240 . The delete instance method takes no parameters. The copy copy method only needs the parameters table type 220 , price 230 and material 240 .

It can also be seen from the definitions that the table can only consist of three types of material: wood, metal or glass. These types of materials must also be considered in the definition of the abstract specification object 105 .

At the end of steps 510-530, a definition for the abstract specification object 105 can be written. This definition is shown in Fig. 6. The definition language used is fictitious.

Fig. 6 shows the definitions of the classes "table", "table top" and "table legs" by the declarations "CLASS: table", "CLASS: table top" and "CLASS: table legs". The classes have class methods that are defined using the "CLASS_METHOD:" declaration and instance methods that are defined using the "INSTANCE_METHOD:" declaration. The individual methods are defined by the "METHOD:" declaration and the associated parameters are specified using the "PARAMETERS:" and "ELEMENT:" declarations. Each parameter has its own name, which is generated from the definition shown in FIGS. 4A and 4B.

Some parameters require more complex sub-specifications. Of the The "LINK" parameter refers to such subspecifications.

The value of the parameter "material" 240 can be selected from only three values as shown in Fig. 3A and Fig. 4 is shown. This selection is described by the declaration "SELECT:" with the alternatives "ALT:".

In this example the object class "table" has further subclasses "table legs" and "table top". These subclasses can be seen in the definition shown in FIG. 4B and their dependence on the main class is shown by a declaration "CONSISTS_OF:" in the declaration shown in FIG. 6. Each subclass then has its own definition, as can be seen in FIG. 6. In order to simplify this figure, some declarations are not given in detail. These are replaced by dots in the figure.

After creating the definition ( FIG. 6) that represents the abstract specification object 105 , the definitions for the data specification object 110 must be created. This is shown in step 540 on FIG. 5. For this purpose (very generally) information from the input codes 10 (eg from database definitions or E / R definitions) can be used or the assignment to a storage medium can be provided by the user of the reprogrammer. In the example shown here it is assumed that the user has named an MVS QSAM file as the storage medium. To fully describe the data specification object 110 , one only needs a declaration of the form shown in FIG. 7. The existing MVS utilities then take on all the other functions you need for file management.

The view specification objects 120 determine the logical views for the user interface. The screen window 300 of FIGS. 3A and 3B is an example of a view for the creation of a new member of the object class "table". This is found by examining the definition shown in FIG. 4A (step 550). The associated "CREATE" method was already defined in step 520 during the creation of a definition of the abstract specification object 105 . The necessary information about this method, in particular the required parameters, can be queried from the definition of the abstract specification object 105 and copied into the definition of the view specification object 120 .

The result of these investigations leads to a definition which is shown in FIG. 8. The declaration "VIEW_NAME =" assigns a name "VIEW_1" to the view. The view type is specified by the declaration "VIEW_TYPE =". In this example, a certain type of "PARMVIEW" is selected. This view type shows the parameters defined by the declaration "SHOW =". The declarations "CLASS =" and "METHOD =" indicate which methods (which object classes) are represented based on this view.

The definition of the view specification object 120 only provides information about the object classes, methods and parameters that appear in the screen window 300 . It contains no information about their arrangement on the screen 300 . This information is contained in presentation specification object 130 . The presentation specification object 130 is determined by further examination of the CICS BMS map defined in FIG. 4A (step 570 in FIG. 5). The definition established therefrom for the presentation specification object 130 is shown in FIG. 9.

The declarations "PRESENTATION" in FIG. 9 indicate how the views or parameters entered between brackets are to be represented in the screen window 300 . The view with the name VIEW_1 is defined as a window of the size 600 × 400 (defined by the "SIZE" declaration). The window cannot be moved as the declaration "NONSCROLLABLE" indicates and has a title "Parameter input for table" as the declaration "TITLE =" indicates. The standard pushbuttons "Enter", "Help" and "Exit" are available in window 300 . Their functions are defined by the declarations "ENTER", "HELP" and "CANCEL". The parameters "Order No.". "Table type" and "Price" are presented as input fields on the screen 300 within the window, as can be seen from the declaration "ENTRYFIELD". The input fields have a certain size, which is defined by the declaration "SIZE =", and contain a text given by the declaration "TEXT".

One of the parameters (material 340 ) is presented in the form of a radio button group. In this case, the "material" parameter 340 can only have one of three values, the selectable values being offered as radio buttons within the screen window 300 .

At the end of the flow of the flow chart shown in FIG. 5, definitions of all partial specifications for the use of the object specification object 100 in other programs have been generated. The reprogrammer can use it to generate the components of a new application 40 using the partial specifications in connection with newly written code (step 580).

Claims (10)

1. Device for reprogramming an existing program code ( 10 )
with a reprogrammer ( 20 ) who examines the program code ( 10 ) and uses it to generate object specifications for one or more objects,
marked by
a generated abstract specification object ( 105 ), which describes an interface for the outside world to the functions offered by the program code ( 10 ). 2. Device according to claim 1, characterized by a data specification object ( 110 ) which describes the access methods to the data required by the abstract specification object ( 105 ). 3. Device according to one of the preceding claims, characterized by a view specification object ( 120 ) which describes a logical view for the interface. 4. Device according to one of the preceding claims, characterized by a presentation specification object ( 130 ) which, in connection with the view specification object ( 120 ), generates a graphic representation ( 300 ) of the interface on a screen. 5. Method for reprogramming an existing program code ( 10 ) into code ( 40 ) which is written in an object-oriented form, the method comprising the following steps:
Step 1 (500, 510): identify the objects in code to be reprogrammed ( 10 ),
Step 2 (500, 520): identify the methods in the code to be reprogrammed ( 10 ), and
Step 3 Create an abstract specification object ( 105 ) that describes the identified objects and methods. 6. The method according to claim 5, with an additional step (540): creating a data specification object ( 110 ) that describes the access methods to the data required by the abstract specification object ( 105 ). 7. The method according to any one of claims 5 or 6, with an additional step (550): creating a view specification object ( 120 ) that describes a logical view for the methods contained in the abstract specification object ( 105 ). 8. The method according to any one of claims 5, 6 or 7, with an additional step (570): creating a presentation specification object ( 130 ) that generates a graphical representation of the methods on a screen ( 300 ) in connection with the view specification object ( 120 ). 9. The method according to any one of claims 5 to 8, with an additional step (580): generating a new application ( 40 ) by using the created abstract, data, view or presentation specification objects ( 105 , 110 , 120 , 130 ). 10. Use of the device according to one of claims 1 to 5 for reprogramming a screen content ( 200 ) on a mainframe in a window ( 300 ) on a graphic screen.