WO2008015110A2

WO2008015110A2 - Methods, apparatus and computer programs for modelling computer programs

Info

Publication number: WO2008015110A2
Application number: PCT/EP2007/057505
Authority: WO
Inventors: Rajini Sivaram
Original assignee: International Business Machines Corporation
Priority date: 2006-07-29
Filing date: 2007-07-20
Publication date: 2008-02-07
Also published as: WO2008015110A3; GB0615181D0

Abstract

Provided are methods, apparatus and computer programs for model-driven development of computer programs, which enables multiple versions of program code to be generated from a single model(500)for different API versions. API-version-specific information is encapsulated within extensions (500)to the model of the API. The extensions are implemented as UML stereotypes encapsulating version-specific information such as a set of code templates or a set of alternative method names for the set of API versions. When transforming UML behavioural diagrams to generate source code, the API-version identifiers within the UML version stereotypes are compared (520)with a required API version and the identified matching version-specific information is transformed (530) together with other elements of the computer program model.

Description

METHODS, APPARATUS AND COMPUTER PROGRAMS FOR MODELLING COMPUTER PROGRAMS

FIELD OF INVENTION

The present invention relates to model driven software development.

BACKGROUND

In known model driven software development, different API versions are not handled efficiently. An application programming interface (API) is an interface to a computer program or library. An API defines how other computer programs can invoke functions of the first program or library, and how they can exchange data with the first program, without requiring detailed knowledge of the source code and internal structures of that first program.

When new versions of an API are released, the differences from the existing interface version tend to be minimal. It is often possible to perform all of the functions of a new API version using combinations of functions in the old API version. Changes typically include addition of new parameters to interfaces or changes to class hierarchy caused by addition or removal of interface features. When interface methods are made obsolete, there will typically be other ways of exercising this functionality in the new API.

However, despite the changes between successive API versions typically being small, migrating an application program such as a test program or suite to a new API version can be very time consuming - sometimes requiring thousands of lines of code to be transformed to take account of small API changes. For this reason, API version management and code migration is currently inefficient and costly.

Because of the migration problem, server computer systems may be given the capability to support multiple API versions, such that client systems supporting different single versions of the API can communicate with the server. This avoids having to simultaneously switch all clients and servers to the new API version (which is impractical if not impossible in many systems). Secondly, an intermediate mapping capability may be provided, to replace an API call for a first API version with the equivalent call for the new API version, such as described in US Patent Application Publication No. 2006/0080676 (assigned to the assignee of the present application). Although such mapping and transformation of API calls can achieve interoperability, the run-time transformations may impact the performance of the data processing system. Where the program that needs to be run against a new API version is a test program, intermediate mapping of calls may compromise the test program's ability to perform comprehensive testing.

In model driven software development, a program developer uses models to describe a solution and these models are transformed to generate computer program source code. In a model driven development system, an API can be modelled using class diagrams, with operations in the classes representing methods in the API. For example, application programs using the API can be modelled using Unified Modeling Language (UML) behavioural diagrams which access the classes and operations of an API model. A transformation used to convert the modelled application to source code uses the definitions of the API model to generate code which can invoke functions of the API. Current model driven development systems do not handle API versions efficiently, because an API version change requires the new API to be modelled using new classes or operations. If using UML, a new set of UML behavioural diagrams need to be modelled for each new version.

SUMMARY

Methods, apparatus and computer programs according to various aspects of the present invention provide model-based generation of computer programs in which

API-version-related information is implemented within a model of a computer program, to enable program code to be generated automatically for different API versions from a single model.

This enables application program development to be performed without requiring an application program to be rewritten by a programmer to customize the application program for each different API version, and without an application modeller having to create a new set of behavioural diagrams for each new API version. This can significantly reduce the programming effort involved in migrating test programs and other application programs to a new API version.

In a first embodiment of the invention, API-version-related information is implemented within a 'version stereotype' of a modelling language such as the Unified Modeling Language (UML). Stereotypes are a known type of extension or refinement of a modelling language, for adding new properties or modifying the behaviour of elements of the underlying language. Use of stereotypes has been described in the art for object-oriented modelling languages including UML and the Open Modeling Language (OML). However, stereotypes have not been used in the past to encapsulate differences between API versions.

According to this first embodiment of the invention, stereotypes comprising extensions to a modelling language (such as UML) can be used to describe the changes introduced to the API in different versions and to describe the consequent changes to applications that are required to take account of the API changes. Stereotypes can be applied to any operations defined by the API. The invention enables an abstract model to be used for automated generation of multiple versions of a computer program corresponding to multiple API versions.

Test programs and other application programs, when generated using a model that includes version stereotypes according to the present invention, can use the operations of the corresponding API version directly - without requiring programmers to add separate code blocks for each version of the API.

Code generators or transformation utilities, which transform application models to code for a particular version of the API, can refer to version stereotypes within the API specification model to create optimal code. That is, multiple versions of an API implementation (and hence multiple versions of a program implementing features of the API) can be generated from a single model for multiple versions of an API. If the current API version is not a precise match for any of the API-version-related information within the API specification's version stereotypes, a best possible match can be selected and applied to generate an application program (a test program or any other application program) that is satisfactory for the current API version.

A method for generating a model of a computer program, according to one embodiment of the invention, comprises the steps of: creating a model of at least one computer program component using a modelling language; and extending the model by defining at least one API-version-related extension to the model, such that the extended model represents a set of versions of the computer program component corresponding to a set of

API versions for which at least one API-version-related extension is defined.

A method according to another embodiment of the invention, for generating program code from a model of a computer program, comprises the steps of: identifying a required API version for required program code; in response to the identification of a required API version, identifying at least one API-version-related extension of the model, which extension corresponds to the required API version; and transforming the model to program source code, including transforming the at least one API-version-related extension of the model to generate API-version-specific program source code for the required API version.

A data processing system according to one embodiment of the invention comprises: a data processing unit; a memory; an input device for inputting instructions; and a computer program modeller for generating a model of a computer program in response to input instructions, the modeller comprising means for creating a model of at least one computer program component using a modelling language and means for defining at least one

API-version-related extension to the model, such that the modeller can define an extended model representing a set of versions of the computer program component corresponding to a set of API versions for which at least one API-version-related extension is defined.

A data processing system according to another embodiment comprises: a data processing unit; a memory; and a code generator for transforming a model of a computer program to generate program source code, wherein the code generator is responsive to an identification of a required API version to identify any API-version-related extensions of the model which correspond to the required API version; and wherein the code generator comprises means for transforming the model to program source code, including for transforming an identified API-version-related extension of the model to generate API-version-specific program source code for the required API version.

Another embodiment of the invention provides a program product, comprising computer readable program code recorded on a recording medium, for controlling performance of operations on a data processing apparatus on which the program executes so as to perform a method as described above. Embodiments of the invention provide software-implemented modelling tools and code generation tools for implementing the methods described herein.

BRIEF DESCRIPTION OF DRAWINGS

Embodiments of the invention are described in more detail below, by way of example, with reference to the accompanying drawings in which:

Figure 1 is a schematic representation of a data processing apparatus in which the present invention can be implemented; Figure 2 is a schematic representation of a model-driven application development system according to an embodiment of the invention;

Figure 3 represents components of a code generation system according to an embodiment of the invention;

Figure 4 is a schematic flow diagram representation of the steps of a method of application modelling according to an embodiment of the invention;

Figure 5 is a schematic flow diagram representation of the steps of a method of code generation according to an embodiment of the invention;

Figure 6A shows the relationship between behavioural diagrams and application source code for different API versions, for a system using conventional methods; Figure 6B shows the relationship between behavioural diagrams and application source code for different API versions, for a system according to an embodiment of the present invention; and Figure 7 is a segment of a sequence diagram for a computer program generated according to an embodiment of the invention.

DESCRIPTION OF EMBODIMENTS

An embodiment of the invention is described with reference to data processing systems and methods for modelling computer programs and for code generation from a model, using the Unified Modeling Language (UML) as an example modelling language and using a new type of UML extension referred to herein as a 'version stereotype'. The invention may also be implemented using other modelling languages and using other API -version-specific extensions to a model of a computer program.

UML is a general purpose modelling language for specifying, constructing, visualizing and documenting artifacts within an object oriented data processing system. The UML 2.0 specification (and related documentation) is available from the Object Management Group's

Website www.omg.org . Stereotypes are introduced and classified in the article Berner, S., Glinz, M., Joos, S. (1999), "A Classification of Stereotypes for Object-Oriented Modeling Languages", Proceedings of the Second International Conference on the Unified Modeling Language, Fort Collins, October 1999, Springer-Verlag, pages 249-264. As described in the above-referenced publication, stereotypes provide a mechanism for extending, refining or redefining elements of a language (without directly modifying the metamodel of the language).

However, stereotypes have not previously been used to capture API-version differences or to address problems of migrating an application program or a suite of programs to a new API version.

The present invention can be implemented on a wide range of hardware and software platforms, since the modelling and code generation features of the invention are not limited to any particular system architecture.

Therefore, it is not necessary for conventional system features to be described in great detail herein. An example data processing system for use in model-driven application development is shown schematically in Figure 1. The system 10 comprises a processing unit 20, a network interface 30 and input/output device controller 40, system memory 50 and non-volatile disk storage 60, all connected for communication via a system but 70. A keyboard 80, mouse 90 and display monitor 100 are also shown. When the system is used for model-driven application development, a model generator 110 and a code generator 120 are loaded into system memory 50. The model generator 110 and code generator 120 interact with each other and make use of features of the underlying operating system 140 to generate an application model (or models) 150 and to generate program code 160 from the model(s).

Figure 2 shows the software components of an example model-driven application development system 10 in more detail. A set of software components for model-driven application development are commonly integrated together to form an Integrated Development Environment (IDE). One example IDE is IBM™ Rational™ Software Architect available from International Business Machines Corporation (IBM and Rational are registered trademarks of International Business Machines Corporation). As shown schematically in

Figure 2, an example IDE 200 includes an application modeller 210, a model editor 220, a code generator 230, a source editor 240, a source debugger 250 and a compiler 260. In an IDE such as IBM Rational Software Architect, the code generator 230 may be a plugin component of the IDE and so the code generator is represented as a component of the IDE 200 in Figure 2. In other systems, the code generator 230 may be separate from the program modelling components of the IDE. The application modeller 210 and model editor 220 are used to create application program models and API models 270. These models are inputs to the code generator 230, which transforms the application model to source code 280. The source editor 240 and source debugger 250 are used to identify and resolve errors in the generated program code, and the compiler 260 generates runtime objects 290 for deployment.

Model editor 220 is used to create graphical models using a graphical modelling language like UML. Models typically represent a software system from a particular viewpoint. Different modelling diagrams can be created using the model editor to represent different views of the software at different stages in software development. Application modeller 210 refers to the modelling component that defines the complete software model, where each of the models was created using a model editor. The application modeller typically consists of a model validator and a model explorer which shows the different models that the software system is comprised of, and their relationships. In addition, the application modeller enables the definition of new UML profiles containing stereotypes specific to the application, as well as application-specific transformations for the models.

Code generator 230 implements a transformation which transforms models to code. These transformations access the different elements of one or more models including stereotypes which may contain code generation directives to generate the final source code representing the software system.

Modelling tools which are part of an integrated development environment 200 also contain Source editors 240 which can be used to view and modify source code generated from models. Different source editors are typically provided by IDEs for different programming languages. Compiler 260 is also provided within the example IDE of Figure 2, to convert source code in different programming languages to actual runtime objects. For languages that are not supported by the IDE, it may be possible to invoke an external compiler to compile the source code. During development, the source debugger 250 can be used to debug problems at the source code level.

Figure 3 shows the functional components of an example code generator 230 in more detail. When it is required to generate code implementing a particular UML application model, the model 270 is read from storage 60 into a model reader 300. The model reader 300 interprets the UML model to generate a representation of the model that can be analysed by a model validator 310 and a set of behavioural diagram transformers. The model reader 300 reads the different elements of the model that are required to generate code from the model. For example, to generate code for a particular class, the model reader will traverse the different attributes and operations of the class as well as any behavioural models associated with those operations. The model reader separates the transformation from the format of the model. This separation enables models of different formats to be transformed by the same transformation. The model validator 310 performs validation of the model with respect to code generation. For example, if the target languages do not permit multiple inheritance, the validator can confirm that the models do not require the feature of multiple inheritance in order to generate an implementation. Constraints can also be placed on models which are validated by the model validator. The model validator may also validate the UML stereotypes.

For example, if a method is introduced only in version 2.0 of an API, and no alternatives are provided in the version stereotype for the earlier versions, the validator can reject the model if program code is required for an earlier API version. Alternatively, the model validator may not be involved in any consideration of API versions, leaving this responsibility to the transformation components described below.

If the model is rejected by the model validator 310, the model editor 220 can be employed to edit the model to remove the invalidity, or the user can return to the application modeller 210 to start again with a new model.

If the model is not rejected, the model validator passes responsibility for processing the model to one or more transformation components 320,330,340. Each model may include a combination of sequence diagrams, activity diagrams and state diagrams (these are standard UML behavioural diagrams), and a separate transformer 320,330,340 is provided to transform each type of behavioural diagram to intermediate code. That is, each transformer 320,330,340 interprets information within the UML specification of the application definition that corresponds to a different type of behavioural diagram, and transforms the information for each element of a behavioural diagram into an intermediate source code representation. For example, an alternative block in a sequence diagram is transformed into an 'if statement. In other modelling languages and development systems, such as those which do not employ different types of behavioural diagram, a single transformation component may be adequate.

The source code resulting from processing by the transformation components 320,330,340 is a complete representation of the required computer program, but is represented as an abstract syntax tree that requires an additional simple transformation to generate the final source code in the syntax of a particular programming language. The transformation of API-version- specific UML stereotypes is described in detail below. Sequence transformer 320 transforms UML sequence diagrams to intermediate code, activity transformer 330 transforms UML activity diagrams to intermediate code, and state transformer 340 transforms UML state diagrams to intermediate code. A model may contain one or more of these behavioural diagrams to describe an operation. For example a multi-threaded application may use an activity diagram to visually represent the different threads in different activity partitions. Activities in each of these partitions could be modelled in detail using sequence diagrams.

An intermediate code traverser 350 enables the intermediate code to be traversed to generate the final source code (i.e. the traverser provides a common way of traversing the intermediate code, separating source code generators from the format of the intermediate code). Since the intermediate code is stored as an abstract syntax tree, as mentioned above, the intermediate code traverser traverses this tree to enable code to be generated in different programming languages. The use of an object-oriented abstract syntax tree as an intermediate step in the transformation process simplifies the actual source code generation for object-oriented languages.

A different source code generator 360 is implemented for each supported programming language, and the source code generators convert the intermediate code to the final implementation source code. For non-object-oriented languages, code is generated in object oriented style to simplify the transformation. In all cases, the transformation of the abstract syntax tree representing the intermediate code to actual source code is a straightforward transformation, which only differs in terms of the syntax of the source code in different languages.

The description above identifies a number of functional components of an example application development system, including modelling components that can be used by a program developer to describe a software system and components that can transform the models to generate program source code. A number of alternatives to the above-described development system architecture are within the scope of the present invention. For example, in one alternative embodiment of the invention, a single transformation component 230 may be provided for source code generation instead of the multiple transformation components 320,330,340, intermediate code traverser 350 and multiple source code generators 360 described above.

A number of method steps for modelling and code generation according to embodiments of the invention are described below with reference to Figures 4 and 5. The developer first creates 400 a structural design for the application program using UML class diagrams. With the development of UML stereotypes (and equivalent extensions for other modelling languages), the developer has the option to extend the model by adding 410 one or more UML stereotypes. The UML classes (including UML stereotypes) then form the basis of the classes and their hierarchies and dependencies in the generated final code. UML stereotypes are stored in UML profiles, which provide an extension mechanism for extending the UML language. The UML profiles contain a collection of stereotypes and tagged values.

In model-driven development, an API can be modelled using class diagrams, with operations in the classes representing methods of the API. A modelled application program includes the set of classes required to enable the application program to use some (or all) of the functions of the API. To avoid having to generate a new model for each API version, an application modeller using a model-driven development system according to an embodiment of the present invention defines 410 API -version-specific information within a version stereotype of the model element. The version stereotype is implementable as a data structure comprising a set of API version identifiers and a set of code templates or identifiers of operations.

Stereotypes can be applied to any UML element, and so version stereotypes can be applied to any of the elements of an API model referenced within a model of an application program. The most common use of version stereotypes is for operations, since operations from the API model are directly used in behavioural models of applications such as tests. However, version stereotypes can also be applied to attributes, to specify getter and setter operations for attributes; and to associations, to specify class hierarchies and dependencies to be used when an API specification is generated for each version.

Each version stereotype applied to an operation may specify either (a) the code to be used to express the operation for each respective known API version, or (b) the name of one or more methods of specified classes to be used for each respective known API version, or (c) a helper library which supports the operation for each known API version, or (d) a helper library which chooses the appropriate operation depending on the API version at runtime, or (e) attribute names when version stereotypes are applied to attribute getters and setters.

Helper libraries can be useful where there are a large number of potential implementations of an operation or set of operations that differ between different API versions.

Each version stereotype applied to an attribute may specify either (a) the attribute name to use for each respective known API version, or (b) the code to replace the getter or setter of the attribute operation for each respective known API version, or (c) the name of getter and/or setter methods to be used for each respective known API version, or (d) a helper library which contains the getter and/or setter operation for each known API version, or (e) a helper library which chooses the appropriate getter and/or setter operation for each known

API version at runtime.

Version stereotypes applied to associations and dependencies specify alterative generalizations or abstractions to be used when API documentation is generated for different versions. Version stereotypes can also be applied to UML comments to specify different documentation for different API versions.

In the examples given below, a transformation specifies a UML profile that contains the version stereotype. The profile can also be separate from the transformation. The transformation uses the qualified name of the version stereotype which contains the profile name and the stereotype name to determine if version-specific code is to be generated.

A first example version stereotype for use with three known API versions 1.0, 1.1 and 2.0 has the structure: <version>

</version>

where xxxx, yyyy and zzzz represent differences between program code implementations relating to a particular function of the API for the three API versions.

A second example version stereotype has the structure:

<method version=" 1.1 " method="newMethodName"

/>

<override version="1.0" selector="this" class=' 'fϊrstClassName' ' method="firstMethodName"

/>

< override version="1.0" selector="this" class=' 'secondClassName' ' method="secondMethodName"

/> </version> where version 1.0 of the API requires use of method name "fϊrstMethodName" for an object of class "fϊrstClassName" and requires use of method name "secondMethodName" for an object of class "secondClassName", whereas version 1.1 of the API requires use of method name "newMethodName" for both objects. The version stereotype enables appropriate program code to be generated for each API version from the same API model.

Behavioural diagrams are then used 420 to add detail to the design model and these diagrams describe the actual objects in the software system and their interactions. Application programs such as test programs using the API are modelled using UML behavioural diagrams, which access the classes and operations of the API model. When satisfied with the behavioural diagrams, the developer saves 430 the generated model for use in a subsequent code generation.

When code implementing the model is required, a code generator 230 is used to transform the model into source code, as mentioned above. The behavioural diagram corresponding to each operation of a class is transformed into the method body in the final program source. The transformations used to convert the modelled application to source code use the definitions from the API model to generate code which invokes functions of the API. Since the API model implementing the present invention includes one or more version stereotypes, the information used to generate source code includes the API-version-specific information specified within the version stereotypes.

Referring to Figure 5, the inputs to the code generator 230 include the previously generated model 500 and an identification 510 of the required API version. This identification of an API version may be entered manually by a human program developer, who may also manually select an application program model.

The operations of the model reader 300 and model validator 310 are described in detail above (and so will not be repeated here), together with an overview of the functions of the transformation components. When the transformation components 320,330,340 are employed to transform the model to program code, the required API version is compared 520 with any API-version-specific extensions to the model to identify matching version numbers. The comparison of version numbers conforms to conventional numbering of software versions in which a unique numeric identifier follows the structure:

major.minor[.revision[.build]]

As is known in the art, the major version number for a computer program is typically set to 1 for the first release, and the minor version number is initially set to 0. The major version is incremented whenever there is a major change in functionality, whereas the minor version number is incremented when minor features are added. The revision number is typically incremented when minor defects are fixed. Some but not all computer programs use a fourth digit to identify the exact build level.

Changes to APIs are typically made only when adding new features to the software, which means that API changes are typically only introduced as part of a major or minor version change. API changes are rarely implemented between different builds at the same revision level, or even in different revisions within the same minor version. Therefore, the API version identifier referred to above and included within API -version-specific stereotypes may be implemented using 2 numbers (typically one digit for the major version number and one for the minor version number, except that a major or minor version number need not be a single digit number), or more flexibility may be provided using additional numbers (such as to allow for version numbers of the form major. minor.revision.build, where any one of the four elements of the version number need not be limited to a single digit).

The version numbers specified in the API model refer to the lowest version at which a particular function was introduced. To generate optimal code for a particular API version, a version number of a required API version is matched with a version identifier within a stereotype, starting with the major version and followed by the minor version (and the optional revision or build if specified). For example, consider an operation in the API which has different code associated with version 1.0, version 1.2 and version 2.1. The model of the computer program including its API model extensions (stereotypes) specifies program code for version 1.0, version 1.2 and version 2.1. This means that the operation in the API was introduced in the first release, and then modified at versions 1.2 and 2.1 and the API model has been extended to represent these changes.

If the required API version is API 1.0 or 1.0.1 or 1.0.1.23, the application code generated for that API version will use the code specified in the stereotype for API 1.0. Code generated for version 1.1 will also use the API 1.0 code since the operation was not modified until version 1.2. Code generated for version 1.2, 1.3 or even 2.0 will use the API 1.2 code because that is the best match. Code generated for versions 2.1 and above will use API 2.1 code.

Thus, a comparison 520 of version numbers by the transformation components identifies API-version-specific extensions to the model (implemented as UML stereotypes) that are required for application programs that are being developed for particular API versions. The transformation components transform 530 the identified stereotypes for the current API version into intermediate code together with other elements of the model.

The transformations described herein can be implemented, for example, using IBM Rational Software Architect, by defining a transformation which converts UML behavioural diagrams into code. UML behavioural diagrams such as sequence diagrams, activity diagrams or state diagrams are first converted 530 into an intermediate code representation. The syntax tree of this intermediate code representation is traversed 540 (as described above) and the intermediate code is then converted 550 to code in one of the supported programming languages. This latter conversion 550 is a simple transformation to conform to the syntax requirements of a chosen programming language (as described above).

Modelling tools such as IBM Rational Software Architect support model driven development by providing a framework for implementing user-defined transformations which transform models into other artifacts which may be other models, code or deployment scripts. IBM Rational Software Architect is based on the Eclipse framework. Eclipse provides a universal platform for development tool integration with an extensible plugin-based architecture. Apart from an integrated development environment for editing and debugging program source, IBM Rational Software Architect provides modelling support which includes editing of models. Built-in transformations convert UML interfaces and classes into interfaces or abstract class code containing method definitions.

The above-described transformations 530,550 generate the complete and final source code for the required application program. The source code is compiled 560 to generate the runtime objects corresponding to the application. An IDE such as IBM Rational Software Architect typically includes a source debugger 250. If problems are identified while debugging, a developer can return to the model editor 220 to change the model. During the initial debugging stages, the source code can be modified directly to test fixes to the identified defects, and the final fix is applied to the model using the model editor. The modified model is transformed as described above to generate the new source code.

When code is modelled and generated using conventional methods, any API changes between API versions would require the new API to be modelled using new classes or operations. Hence a new set of behavioural diagrams would need to be modelled for each new version - as shown in Figure 6A. Using the present invention, however, changes to an API for different versions are described in the same API model, by using UML version stereotypes to capture API-version-specific information. This extends the conventional API model. Behavioural diagrams using the extended API model do not have to be modified when the API version changes. Transformations of the model to actual code use the information from the version stereotype to generate optimal application source code for the chosen API version. This is represented in Figure 6B.

Example scenario

The example scenario described below relates to an application program that is developed to interoperate with a messaging middleware program, using the example of the WebSphere™ family of messaging products from IBM Corporation (WebSphere is a registered trademark of International Business Machines Corporation). The example relates to the code required to create a connection to a Java Message Service (JMS) provider from a

JMS client (Java is a registered trademark of Sun Microsystems Inc.). Although used for illustrative purposes only, the example code locates a connection factory using a naming service, sets a new client ID for the connection factory, and then creates a connection.

Using a first version of a first messaging program (for example, IBM Corporation's WebSphere MQ v6.0 product which is referred to as WMQ hereafter), the code fragment would be:

ConnectionFactory cf =

(ConnectionFactory)initialContext.lookup("jms/CF 1 "); ((MQConnectionFactory)cf).setClientID("newClientID");

Connection connection = cf.createConnection();

Using a second messaging program (such as IBM Corporation's WebSphere Platform

Messaging product (referred to as WPM hereafter)), the code fragment would be:

ConnectionFactory cf =

(ConnectionFactory)initialContext.lookup("jms/CF 1 ");

((JmsConnectionFactory)cf).setClientID("newClientID");

Connection connection = cf.createConnection();

Using a further example of a messaging program (implementing a Common JMS Client for a future version of IBM Corporation's WebSphere MQ product), the code fragment would be:

ConnectionFactory cf=

(ConnectionFactory)initialContext.lookup("jms/CF 1 ");

((JmsConnectionFactory)cf).setStringProperty(JmsConstants.CLIENT_ID,

"newClientID");

Connection connection = cf.createConnection(); Using the earlier versions of IBM's WebSphere MQ for JMS 1.0 product, the code fragment would differ depending on whether the connection is for Point-to-Point or Publish/Subscribe messaging.

QueueConnectionFactory cf =

(QueueConnectionFactory)initialContext.lookup("jms/CF 1 "); ((MQConnectionFactory)cf).setClientId("newClientID"); Connection connection = cf.createQueueConnection(); or TopicConnectionFactory cf =

(TopicConnectionFactory)initialContext. lookup("jms/CF 1 "); ((MQConnectionFactory)cf).setClientId("newClientID"); Connection connection = cf.createTopicConnection();

The examples above illustrate how applications and tests using these APIs have to be rewritten, and separate copies maintained, depending on which version of the same or similar API is being targeted. In this particular example, apparently minor changes have resulted in the need to maintain four completely different code bases for applications using the API.

The solution described herein enables differences in the API versions to be encapsulated within the specification of the API, so that applications and tests using the API do not have to rewritten for each version.

The following version numbers are used for the models described in the rest of the document, for ease of reference only:

• WMQ for JMS 1.0 : Version 1.0

• WMQ for JMS 1.1 : Version 1.1

• WPM (JMS 1.1) : Version 2.0

• Common JMS (1.1) : Version 3.0

Major version 1 refers to WMQ JMS Major version 2 refers to WPM JMS Major version 3 refers to Common JMS client

Versions 1.1 and above support unified messaging domain (JMS 1.1).

Example Scenario - Modeling setClientID

The example above shows two main changes introduced in the API. The first is a difference in the way Client ID is set on a connection factory. With the older versions of WMQ, the method setClientld was defined on the WMQ-specific connection factory class. With the WMQ v6.0, setClientld has been deprecated and replaced with setClientID to be compatible with WPM. WPM uses setClientID on the WPM-specific connection factory class. And finally a new common JMS client for a future WMQ version, a generic API has been defined to set properties, enabling any transport to use the same API.

The solution described herein captures these differences between APIs in the specification model of the API. In the API specification model, setClientID is defined as an operation in the interface ConnectionFactory.The version stereotype for setClientID is given below:

<version> <code version="3.0" template="((JmsConnectionFactory)%this%). setStringProperty(JmsConstants.CLIENTID, %clientID%)"

/>

<code version="2.0" template="((JmsConnectionFactory)%this%).setClientID(%clientID%)"

/>

<code version=" 1.1" template="((MQConnectionFactory)%this%).setClientID(%clientID%)"

/> <code version=" 1.0" template="((MQConnectionFactory)%this%).setClientId(%clientID%)" />

</version>

The code templates for each version shows the code to be used for the different versions. Alternatively, if the transport-specific classes MQConnectionFactory etc. are also modelled, the version stereotype can directly refer to the operations in these classes, instead of specifying the code.

Example Scenario - Modeling createConnection

The second change in the API was introduced due to changes in the JMS specification. JMS 1.0 defined separate domains for Point-to-Point and Publish/Subscribe messaging. JMS 1.1 added support for unified message domains, enabling common API operations like createConnection to be used for both Point-to-Point and Publish/Subscribe messaging. In this particular example, createConnection can be used for all versions after 1.1, but createQueueConnection or createTopicConnection should be used for version 1.0.

A version stereotype for the operation createConnection in the API specification model is given below:

<method version=" 1.1" method="createConnection "

/>

<override version=" 1.0" selector="this" class="QueueConnectionFactory" method="createQueueConnection"

/> <override version="1.0" selector="this" class="TopicConnectionFactory" method="createTopicConnection" /> </version>

This stereotype indicates to code transformers that createConnection method can be directly used from version 1.1 onwards, but for earlier versions, either createQueueConnection or createTopicConnection should be used depending on the type of the connection factory object.

Code transformation using the API specification model

Figure 7 shows the segment of the sequence diagram corresponding to the code segment described in the above-described scenario.

This sequence diagram forms part of the behavioural model corresponding to an application that creates a JMS connection. The sequence diagram shows a call to lookup the connection factory, followed by calls to set the client ID on the connection factory and then create the connection. The operations setClientID and createConnection have the version stereotypes applied as described earlier.

Transformations which support the version stereotype will take the API version as an argument, and use the best match of the API version to generate the most optimal code. So the same sequence diagram can be used to generate code for any of the versions described in the scenario.

If major version is 1, setClientID will be transformed to the appropriate method call in the WMQ-specifϊc connection factory class. MQConnectionFactory. If major version is 2, setClientID will be transformed to the setClientID method in WPM-specific connection factory class. And for major version 3 and above, the generic setStringProperty method will be generated. createConnection method has only two variations. It is directly called on versions 1.1 and above. For versions less than 1.0, either createQueueConnnection or createTopicConnection method will be generated depending on the type of the connection factory object. If the type cannot be determined until runtime, a conditional test is generated to choose the appropriate method at runtime.

Code generated for the WebSphere MQ v6.0 product (specify model version 1.1):

ConnectionFactory cf = (ConnectionFactory)initialContext.lookup("jms/CF 1 ");

((MQConnectionFactory)cf).setClientID("newClientID"); Connection connection = cf.createConnection();

Code generated for WebSphere Platform Messaging (specify model version 2.0):

ConnectionFactory cf =

(ConnectionFactory)initialContext.lookup("jms/CF 1 "); ((JmsConnectionFactory)cf).setClientID("newClientID"); Connection connection = cf.createConnection();

Code generated for the Common JMS client (specify model version 3.0):

ConnectionFactory cf =

(ConnectionFactory)initialContext.lookup("jms/CF 1 "); ((JmsConnectionFactory)cf).setStringProperty(JmsConstants.CLIENT_ID, "newClientID");

Connection connection = cf.createConnection();

Code generated for JMS 1.0 (specify model version 1.0) is shown below by way of example. If cf is declared as QueueConnectionFactory:

QueueConnectionFactory cf = (QueueConnectionFactory)initialContext.lookup("jms/CF 1 "); ((MQConnectionFactory)cf).setClientId("newClientID"); Connection connection = cf.createQueueConnection();

If cf is declared as TopicConnectionFactory:

TopicConnectionFactory cf =

If cf is declared as ConnectionFactory because its type is not known until runtime:

ConnectionFactory cf =

Connection connection = null; if (cf instanceof QueueConnectionFactory) connection = ((QueueConnectionFactory)cf).createQueueConnection(); else if (cf instanceof TopicConnectionFactory) connection = ((TopicConnectionFactory)cf).createTopicConnection();

The above examples show how changes in an API typically require changes to an application program. Conventional solutions involved new programming effort to write customizing code for each application program for each new API version. The result tends to be different code bases for the same application, or a large number of conditional statements which test for the API version. Known modelling technology and behavioural models used for application programs will require different sequence diagrams for each API version.

However, the solution described herein allows the changes to an API between different versions to be encapsulated within the API specification. The application developer can work with operations at an abstract level instead of having to work with the details of each respective version of the API. For this reason, the sequence diagram shown in Figure 5, which describes the logical sequence of events is sufficient to generate code for different versions of the API. Separate sequence diagrams are no longer necessary to model application programs (such as test programs) for each API version. The example also illustrates that the code generated according to the described embodiment provides the most optimal code for each version, and does not result in unnecessary conditional statements, even though the application is modelled to work with different versions of the API.

Claims

1. A method for generating a model of a computer program, comprising the steps of: creating a model of at least one computer program component using a modelling language; and extending the model by defining at least one API-version-related extension to the model, such that the extended model represents a set of versions of the computer program component corresponding to a set of API versions for which at least one API-version-related extension is defined.

2. The method of claim 1, wherein the at least one API-version-related extension comprises at least one stereotype of a modelling language.

3. The method of claim 2, wherein the at least one stereotype comprises at least one UML stereotype.

4. The method of any one of the preceding claims, wherein the step of creating a model of at least one computer program component comprises creating an API specification model.

5. The method of claim 4, further comprising: combining the extended model of an API specification with a model of at least one additional computer program component to form a computer program model.

6. The method of any one of the preceding claims, wherein the step of creating a model of at least one computer program component comprises creating a model of a computer program including features of an API specification.

7. The method of any one of the preceding claims, wherein the at least one API-version-related extension defines an association between a set of specified API versions and a set of API-version-specifϊc extensions to the model for specified elements of the model.

8. The method of any one of the preceding claims, wherein the at least one

API -version-related extension includes a set of API-version- specific code templates that each define elements of program code to be included in a version of the computer program when the computer program is generated, for a specified API version, from the extended model.

9. The method of any one of the preceding claims, wherein the at least one API-version-related extension includes a set of API-version-specific method identifiers corresponding to methods of respective API versions, which method identifiers are each to be included in a respective version of the computer program corresponding to a respective API version when the computer program is generated from the extended model.

10. The method of any one of the preceding claims, wherein the at least one API-version-related extension includes a set of API-version-specific attributes for one or more operations of the computer program, which attributes are each to be associated with an operation of a respective version of the computer program corresponding to a respective API version when the computer program is generated from the extended model.

11. The method of any one of the preceding claims, wherein the at least one API-version-related extension includes a set of API-version-specific associations between identified classes, each association defining a feature of a class hierarchy for a particular version of the computer program corresponding to a respective API version.

12. The method of any one of the preceding claims, wherein the at least one API-version-related extension includes an identifier of a helper library for providing an operation for a particular version of the computer program.

13. A method for generating program code from a model of a computer program, comprising the steps of: identifying a required API version for required program code; in response to the identification of a required API version, identifying at least one

API-version-related extension of the model, which extension corresponds to the required API version; and transforming the model to program source code, including transforming the at least one API-version-related extension of the model to generate API-version- specific program source code for the required API version.

14. A data processing system comprising: a data processing unit; a memory; an input device for inputting instructions; and a computer program modeller for generating a model of a computer program in response to input instructions, the modeller comprising means for creating a model of at least one computer program component using a modelling language and means for defining at least one API-version-related extension to the model, such that the modeller can define an extended model representing a set of versions of the computer program component corresponding to a set of API versions for which at least one API-version-related extension is defined.

15. A data processing system comprising: a data processing unit; a memory; and a code generator for transforming a model of a computer program to generate program source code, wherein the code generator is responsive to an identification of a required API version to identify any API-version-related extensions of the model which correspond to the required API version; and wherein the code generator comprises means for transforming the model to program source code, including for transforming an identified API-version-related extension of the model to generate API-version- specific program source code for the required API version.

16. A computer program comprising a set of instructions for execution by a data processing unit of a data processing system, to control operations within the data processing system to implement a method comprising the steps of: creating a model of at least one computer program component using a modelling language; and extending the model by defining at least one API-version-related extension to the model, such that the extended model represents a set of versions of the computer program component corresponding to a set of API versions for which at least one API-version-related extension is defined.

17. A computer program comprising a set of instructions for execution by a data processing unit of a data processing system, to control operations within the data processing system to implement a method comprising the steps of: receiving as input a model of a second computer program, the model including at least one API-version-related extension to the model, such that the extended model represents a set of versions of the second computer program corresponding to a set of API versions for which at least one API-version-related extension is defined; receiving as input an identification of a required API version for the second computer program; responding to the identification of a required API version by identifying at least one

API-version-related extension of the model, which extension corresponds to the required API version; and transforming the model to program source code, including transforming an identified API-version-related extension of the model to generate API-version- specific program source code for the required API version.