DESCRIPTION

This invention relates to a method and system for developing software.

Large and complex software systems such as transaction processing software are composed of many thousands of separate programs. These make use of many thousands of data structures. A data structure is a description of data to be found in memory that is designed as a way of storing and organizing data in a computer so that the data can be used efficiently. A transaction processing system such as the IBM® CICS® transaction processing system will generally provide data structures that are declared in, for example, assembler, and resolve to a dummy section that maps the structure of the data areas used by the programs. In the CICS example, data structures are also provided in other languages such as COBOL and C. (IBM and CICS are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide.)

Often there is the need to declare the same data structure mapping in more than one programming language, since the data structure may be referenced at run-time by programs written in a variety of languages. Again, the typical requirement in the CICS example is to declare data structures in two languages including assembler. There is an obvious requirement for the two structures to match, and resolve to the same field names, at the same offsets, for the same lengths of each field. If the data structures are not directly equivalent, unpredictable results may well occur at run-time, and the code will almost certainly not function correctly.

One approach to this problem is to generate bilingual copybooks. These declare the structure in one language. At compilation time, part of the compilation pre-processing stage takes this file as an input, and builds the corresponding assembler equivalent file as an output. In this way, the generated assembler data structure is made to match a hand-written data structure, and the two are kept in step. The problem with this approach is that not all data structures are written in a bilingual manner. There are a great many existing data structures that were hand- written in various languages, and need to be manually kept in step whenever they are changed or extended.

There exists the issue of disparate data structures written in the same language, which are intended to map the same structures, but which have been defined inconsistently to each other. It is possible that data structures are declared several times within part of a product. In the CICS case, parts of the product known as domains may have several data structures that are declared in a variety of places. These data structures may all map to the same underlying structures. Again, these all have to remain in an equivalent state when changes are made to the structures.

It is therefore an object of the invention to improve upon the known art.

According to a first aspect of the present invention, there is provided a method of developing software, the software comprising a plurality of programs, the method comprising the steps of:

receiving a change to a program,

invoking a data structure checking procedure,

parsing the changed program for reference to a data structure,

locating other instances of a referenced data structure in other programs within the software,

comparing the referenced data structure to the located other instances of the data structure,

performing a predefined action in response to any detected differences between a referenced data structure and the located other instances of the data structure, and

repeating steps c) to f) for all data structures within the changed program.

According to a second aspect of the present invention, there is provided a system for developing software, the software comprising a plurality of programs, the system comprising a processing component arranged to:

receive a change to a program,

invoke a data structure checking procedure, parse the changed program for reference to a data structure,

locate other instances of a referenced data structure in other programs within the software,

compare the referenced data structure to the located other instances of the data structure,

perform a predefined action in response to any detected differences between a referenced data structure and the located other instances of the data structure, and

repeat operations c) to f) for all data structures within the changed program. According to a third aspect of the present invention, there is provided a computer program product on a computer readable medium for developing software, the software comprising a plurality of programs, the product comprising instructions for:

receiving a change to a program,

invoking a data structure checking procedure,

parsing the changed program for reference to a data structure,

locating other instances of a referenced data structure in other programs within the software,

comparing the referenced data structure to the located other instances of the data structure,

performing a predefined action in response to any detected differences between a referenced data structure and the located other instances of the data structure, and

repeating instructions c) to f) for all data structures within the changed program.

Owing to the invention, it is possible to provide an automated means of comparing disparate but matching data structures to ensure that their structures remain comparable after any changes have been made to them. This avoids the problem of manual errors occurring after changes have been made and data structures being changed in an inconsistent manner. By automating the comparison between data structures, run-time programming errors can be avoided which would otherwise lead to application or system failures. Unpredictable results could be for example, storage overlays, abends, program checks or potentially system failures in the worst case. The method and system provides a validation checking mechanism to be included within the code generation tooling, as (for example) a compiler plug-in. The checking mechanism could just as easily be provided as a function of an integrated development environment (IDE). Whatever the implementation used, the mechanism would parse the source code as part of the processing, and check the various data structures being changed by the developer or coder. The mechanism would validate that different (but equivalent) data structures were still functionally declared in an equivalent manner.

Preferably, the step of performing a predefined action comprises outputting a report detailing the detected differences between a referenced data structure and any other instance of the data structure. Once another instance of the data structure under examination has been found not to match the referenced data structure, then a report can be generated and outputted to the programmer, either in real-time or as a saved report that can be accessed as and when desired. This report will inform the programmer of the existence of the other instance of the data structure, its location and the details of the detected difference between the two instances of the data structure.

Advantageously, the step of performing a predefined action comprises changing each of the other instances of the data structure to match the referenced data structure. Additionally or alternatively to the generation of a report, the mechanism can perform an auto-correction of the other instances of the data structure that have been located elsewhere within the software product. This provides an effective and efficient method by which the overall software product can be kept consistent, in terms of the data structures that are located in different programs throughout the product. Once a program has been changed to change a data structure, then any further data structures that are found by the mechanism will be automatically brought into line with the changed data structure.

Ideally, the step of locating other instances of a referenced data structure comprises locating data structures with the same name as the referenced data structure. The mechanism has to have a way of identifying those other data structures that are indeed other instances of the actual data structure that is being checked. In its simplest form, this operation could be to look for other data structures that carry the same name as the data structure that is being looked at. This can be assumed to mean that any other data structure with the same name is therefore another instance of the same data structure. Other methods could be used in addition. For example the search could be based upon structural features of the located data structures to see if they are purporting to the same data structure.

Preferably, the method further comprises detecting a data structure similar to the referenced data structure and generating a notification detailing the detected similar data structure. In addition to locating data structures that are indeed other instances of the actual data structure that is being looked at, it can be advantageous to notify the programmer if there is located any other data structures that are considered to be "similar" to the data structure that has been changed. The test of similarity could be based on specific percentage of field numbers and lengths that are identical, for example. This will allow a programmer to review other data structures that located in this manner, to see if indeed these "similar" data structures are actually supposed to be the same as the one that is currently under examination. This will allow the programmer to change these other "similar" data structures manually, if need be.

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: -

Figures 1 and 2 are schematic diagrams of a software product and an integrated development environment,

Figure 3 is a schematic diagram of a display device showing a GUI for the integrated development environment, and

Figure 4 is a flowchart of a method of performing software development.

An integrated development environment (IDE) 10 is shown schematically in Figure 1. The IDE 10 is being used by a programmer in relation to a software product 12, which is comprised of individual programs 14. The software product 12 could be a transaction processing system, for example, which is designed to handle a large number of transactions per second, while maintaining a high level of integrity and accuracy. Such a transaction processing system might be used by a financial institution such as a bank in relation to a website that allows users to access their accounts online. The programmer uses the IDE 10 to create, delete and amend the individual programs 14. The IDE 10 is one example of an implementation of the invention, another being as a compiler or plug-in environment.

The IDE 10 also includes a plug-in 16, which performs a specific purpose in relation to the work carried out by the programmer. In reality, the IDE 10 may have multiple plug-ins all performing different purposes, but a single plug-in 16 is shown in order to illustrate the present invention in this embodiment. The IDE 10 is itself a piece of software and the plug- in 16 is a further piece of code that has been created specifically to work with the IDE 10. As the programmer interacts with the IDE 10, then the plug-in 16 works in the background, with the programmer being aware of the tasks being carried out by the plug-in 16.

The programs 14 may be written in the same programming language or may be written in different languages. Software products such as transaction processing systems will usually have programs written in different languages. The IDE 10 will normally be specific to one particular language, and the programmer will be able to create and amend programs 14 that are written in that language. The complexity of the software product 12 means that there could easily be hundreds of individual programs 14 making up the software product 12, often with a large number of different programmers contributing to the product 12. This makes the tracking of elements within the different programs 14 a non-trivial task.

The purpose of the plug-in 16 is to maintain consistency amongst data structures that are referenced within different programs 14 that are written in the same programming language. When a programmer creates a new program 14 or amends an existing program 14, then it is important that all instances of the same data structure are consistent with each other. Since the programs 14 have been written by different programmers at different times, it is very easy for individual programmers to be unaware of the existence of all of the instances of a specific data structure. Once a programmer has created or amended a data structure, then the plug-in 16 will operate. The plug-in 16 within the IDE 10 needs to have access to any changed data structures. This could occur during development of code, or during the servicing of existing code. Either way, as changes are made to equivalent data structures, so the plug-in 16 would compare the resulting structures to ensure that they were matching. This would cater for the case of duplicated data structures that have been hand-written in different parts of a product 12. In this example environment, the programs 14 are written in the same language and map to the same underlying data structure. Figure 2 shows two different programs 14a and 14b within the software product 12 that both reference the same data structure 18.

The plug-in 16 could compare the two data structures 18, validating that their structures have remained consistent. This checking could include validating the field names match in each case, validating the declared lengths of each field and validating the overall length of the control block. In this way, the IDE 10, through the plug-in 16, is able automatically to detect if a change has been made to a data structure 18 that will render that changed data structure 18 inconsistent with any other instances of that data structure 18 in other programs 14 within the overall software product 12. The plug-in 16 locates other instances of the data structure 18 and compares the instances to the changed data structure 18.

The plug-in 16 can report, via the IDE 10, a mismatch message such as:

»> INVENTION MESSAGE xxxx. Note that the data structure yyyy is declared in multiple places, within modules 1111, 2222 (etc). These declarations are not consistent and represent different mappings over the same area of storage. You should review the declarations and validate the reason for this inconsistency.

The IDE 10 can also potentially break down the mismatches with subsequent messages such as:

»> INVENTION MESSAGE zzzz. Field qqqq is declared as a 4 byte unsigned field in its structure declaration in module 1111, and as an 8 byte unsigned field in module 2222. The data structure does not define a consistent mapping to the storage for this data. Figure 3 illustrates a display device 20, which is showing a GUI 22 for the IDE 10. The operation of the plug-in 16 has resulted in the detection of a mismatch between two different instances of the same data structure 18. As a result, an error message 24 has been generated detailing the detected differences between the two instances of the data structure 18. This error message or report 24 is a defined action that is taken in response to the detected differences between the instances of the data structure 18. The programmer can decide on the course of action that should be correctly taken in response to the message 24.

The plug-in 16 or IDE 10 could also potentially take action to correct the duplicated but incorrect structures 18 to be the same as the new, altered one. This would be optional, since changing the code to automatically maintain consistency is something which different development organisations may have different views upon. At minimum, plug-in 16 or IDE 10 could map out the differences and suggest what changes could be made to restore consistent mappings from the different versions of the data structures 18. The plug-in 16 and IDE 10 are providing an automated validation (and potentially correction) of disparate inconsistent data structures 18 that are present in different programs 14.

Detailed below are two examples of data structures 18 (storage area mappings) which should match but which have become out of step due to some development or service-related change. These two data structures 18 are present in different programs 14 within the software product 12 and both generated in the same programming language. In order for the finished software product 12 to function properly at runtime, it is essential that all instances of the same data structure 18 are the same. The plug-in 16 within the IDE 10 is designed to locate other instances of the same data structure 18 and detect any difference between them, in order that the programmer can correct this inconsistency.

Example 1

DFHDEMOl DSECT

DFHDEMO 1 S TART DS 0CL40 Demo record

DEMO RESTART KEY DS CL28

DEMO RESTART COUNTS DS 0CL12 DEMO RE S T ART COUNT S @DEMO_T YPE 1 DS FL4 Count 1

DEMO RE S T ART COUNT S @DEMO_T YPE2 DS FL4 Count 2

DEMO RE S T ART COUNT S @DEMO_T YPE3 DS FL4 Count 3

DFHDEMO 1 LEN EQU * -DFFIDEMO 1 S TART Structure length

Example 2

DFHDEMO 1 DSECT

DFHDEMO 1_START DS 0CL44 Demo record

DEMO RESTART KEY DS CL28

DEMO RESTART COUNTS DS 0CL16

DEMO RE S T ART C OUNT S @DEMO_T YPE 1 DS FL4 Count 1

DEMO_RESTART_COUNTS@DEMO_TYPE2 DS FL4 Count 2

DEMO_RESTART_COUNTS@DEMO_TYPE2A DS FL4 Count 2A

DEMO_RESTART_COUNTS@DEMO_TYPE3 DS FL4 Count 3

DFHDEMO 1_LEN EQU * -DFHDEMO 1_S TART Structure length

It is assumed that a first program 14 refers to the first DFHDEMOl structure 18 (example 1), and a second program 14 refers to the second data structure 18 (example 2). In the second example, a programmer has added a new four character field midway into the structure, which is DEMO TYPE2A. This has meant DEMO TYPE3 is now four characters further into the data structure 18. Additionally, this change has also meant that the length of the data structure 18 has increased by four characters, from forty to forty- four characters in length. If the first program and the second program both need to reference a piece of memory that was mapped by DEMO TYPE3 in these data structures 18, they would think the fields were at different places, and the structure length was different. Unpredictable runtime errors would result because of this inconsistency between the two instances of the data structure 18.

Figure 4 is a flowchart summarising the method of developing the software product. The first step a) comprises receiving a change to a program 14, whereby the programmer has used an IDE 10 or editor to change an existing program 14. The next step b) comprises invoking a data structure checking procedure. Here a compiler plug-in, editor plug-in or IDE plug-in 16 would invoke the mechanism for checking any data structures 18 within the changed program 14. This is followed by step c) which comprises parsing the amended program 14 for a reference to a data structure 18. The mechanism operated by the plug-in 16 would parse the program 14, looking for references to data structures 18.

At step d), the mechanism will locate other instances of a referenced data structure 18 in other programs 14 within the software product 12. When such a data structure 18 is found, logic operated by the plug-in 16 will validate the format of the data structure 18 with respect to other instances of the same structure 18 within the other programs 14 comprising the software product 12 being developed or changed. Other instances of the structures could be predefined to the plug-in 16, or the plug-in 16 could search for them within the software product 12 under development/support. There then follows step e) which comprises comparing the referenced data structure 18 to the located other instances of the data structure 18. If corresponding equivalent data structures 18 are found, their layout, length, field names, field lengths and field types etc. would be compared.

After comparing the data structures 18, there is then executed step f) which comprises performing a predefined action in response to any detected differences between a referenced data structure 18 and the located other instances of the data structure 18. If differences are found, the mechanism would, for example, notify the user via editor messages, compiler messages or information output to a pane within the IDE 10. If similar structures with different names were found, the mechanism could notify the programmer of these too, in case they were valid instances of comparable structures. Finally, the method completes by repeating steps c) to f) for all data structures 18 within the changed program 14. The plug-in 16 would iterate through the program until the end is reached. Control would return to the editor, compiler or IDE 10.

It will be clear to one of ordinary skill in the art that all or part of the method of the preferred embodiments of the present invention may suitably and usefully be embodied in a logic apparatus, or a plurality of logic apparatus, comprising logic elements arranged to perform the steps of the method and that such logic elements may comprise hardware components, firmware components or a combination thereof. It will be equally clear to one of skill in the art that all or part of a logic arrangement according to the preferred embodiments of the present invention may suitably be embodied in a logic apparatus comprising logic elements to perform the steps of the method, and that such logic elements may comprise components such as logic gates in, for example a programmable logic array or application-specific integrated circuit. Such a logic

arrangement may further be embodied in enabling elements for temporarily or permanently establishing logic structures in such an array or circuit using, for example, a virtual hardware descriptor language, which may be stored and transmitted using fixed or transmittable carrier media.

It will be appreciated that the method and arrangement described above may also suitably be carried out fully or partially in software running on one or more processors (not shown in the figures), and that the software may be provided in the form of one or more computer program elements carried on any suitable data-carrier (also not shown in the figures) such as a magnetic or optical disk or the like. Channels for the transmission of data may likewise comprise storage media of all descriptions as well as signal-carrying media, such as wired or wireless signal-carrying media.

A method is generally conceived to be a self-consistent sequence of steps leading to a desired result. These steps require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, parameters, items, elements, objects, symbols, characters, terms, numbers, or the like. It should be noted, however, that all of these terms and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.

The present invention may further suitably be embodied as a computer program product for use with a computer system. Such an implementation may comprise a series of computer- readable instructions either fixed on a tangible medium, such as a computer readable medium, for example, diskette, CD-ROM, ROM, or hard disk, or transmittable to a computer system, via a modem or other interface device, over either a tangible medium, including but not limited to optical or analogue communications lines, or intangibly using wireless techniques, including but not limited to microwave, infrared or other transmission techniques. The series of computer readable instructions embodies all or part of the functionality previously described herein.

Those skilled in the art will appreciate that such computer readable instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including but not limited to, semiconductor, magnetic, or optical, or transmitted using any communications technology, present or future, including but not limited to optical, infrared, or microwave. It is contemplated that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation, for example, shrink-wrapped software, pre-loaded with a computer system, for example, on a system ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, for example, the Internet or World Wide Web.

In one alternative, the preferred embodiment of the present invention may be realized in the form of a computer implemented method of deploying a service comprising steps of deploying computer program code operable to, when deployed into a computer infrastructure and executed thereon, cause said computer system to perform all the steps of the method.

In a further alternative, the preferred embodiment of the present invention may be realized in the form of a data carrier having functional data thereon, said functional data comprising functional computer data structures to, when loaded into a computer system and operated upon thereby, enable said computer system to perform all the steps of the method.

It will be clear to one skilled in the art that many improvements and modifications can be made to the foregoing exemplary embodiment without departing from the scope of the present invention.