Patent Application
20050086642
Embodiments of the invention pertain to the fields of software development. More particularly, embodiments of the invention relate to developing backwards compatible software modules.
Complex software systems usually include a variety of components, subsystems, etc. that are updated by developers at different stages of software product development. An interaction between different subsystems of a software product may depend on certain components remaining unchanged, otherwise incompatible changes may introduce a variety of errors into an execution of the software product. For example, changed parameters of a function, which is called by several other software components, may introduce errors into a software system, if the other software components are not changed to reflect the changed function parameters. However, it may be desirable to be able to modify a subsystem of the software product without affecting the performance of other subsystems.
Currently, there are no solutions available in the industry that ensure unchanged software objects of a software product will remain compatible with new versions of other objects of the software product.
What is needed, therefore, is a solution that overcomes these and other shortcomings of the prior art.
A method and apparatus for developing backwards compatible software are disclosed. Embodiments of the invention include identifying a subset of software objects of a first software subsystem and declaring the subset of software objects frozen. Embodiments of the invention further include detecting a change to be introduced into a frozen software object from the subset of software objects, and prior to allowing the change determining whether the change is compatible with a second software subsystem.
The invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
A method and apparatus for backwards compatible software development are described. Note that in this description, references to “one embodiment” or “an embodiment” mean that the feature being referred to is included in at least one embodiment of the invention. Further, separate references to “one embodiment” in this description do not necessarily refer to the same embodiment; however, neither are such embodiments mutually exclusive, unless so stated and except as will be readily apparent to those skilled in the art. Thus, the invention can include any variety of combinations and/or integrations of the embodiments described herein.
It will be appreciated that the term “software”, as used herein, means a software system including independent subsystems, which may or may not be located on several machines, e.g. client machines and server machines. The term “object”, as used herein, means a software object including, but not limited to, function modules, programs, data objects, classes, class components, interfaces, attributes, etc. It will also be appreciated that the term “frozen objects”, as used herein, means software objects of a software subsystem that are used by the objects of another software subsystem and that should not be changed without approval to ensure compatible software functionality.
Exemplary Architecture
Components of a server 100 are illustrated in
Methodology
With these concepts in mind embodiments of the invention may be further described. An exemplary software system including subsystem 1 and subsystem 2, wherein subsystem 1 is located at the server and subsystem 2 is located at the client, is used in the following description for ease of understanding of the invention. However, it will be appreciated that the invention is not limited to the software product with only two subsystems and the software product may include multiple subsystems. Moreover, the invention is not limited to any location of the subsystems of the software product, and all the subsystems may reside, for example, on a single machine.
Development of Frozen Objects
As stated above objects of the software product are declared frozen according to one embodiment of the invention. The software product may include several software subsystems, for example subsystem 1 and subsystem 2, wherein subsystem 2 uses certain objects of subsystem 1. It may be desirable to ensure that changes made to subsystem 1 do not affect subsystem 2. In this situation software objects of subsystem 1 that are used by subsystem 2 are declared frozen. Frozen objects are identified in the frozen objects table 230 at the server, which hosts subsystem 1.
In order to identify the objects of subsystem 1 that are used by the subsystem 2, according to one embodiment of the invention, the object usage monitor 315 at 500 of
In one embodiment the changes monitor 215 ensures that the environment of the identified frozen objects is frozen as well, for example, the data domain of a data object used by the subsystem 2 is declared frozen by the changes monitor 215.
Compatibility Check
In one embodiment the changes monitor 215 monitors and detects changes introduced by the developer to the frozen software objects of the subsystem 1 at 600 of
Upon receiving notification that a change is not allowed, the developer may contact an individual who is an expert in compatibility between subsystems of the software product according to one embodiment of the invention. The expert reviews the change that the developer is proposing to make and analyzes whether the change will introduce incompatibility problems into the software product. If the expert determines that the change will not introduce incompatibility problems, the expert enters an exception into an exception database 240 via the exception interface 225. The exception will be identified by the changes monitor 210 if the developer again tries to introduce the change to the frozen object.
In one embodiment, the function of the expert described above are automated and performed by a software routine implementing an algorithm performing compatibility checks of frozen objects proposed to be changed by the developer.
In one embodiment of the invention, if the expert determines that the change can be predefined as compatible, the expert directs the system to include the change into the compatible changes database 235.
Classification of Frozen Objects
In one embodiment of the invention, the frozen objects include released objects and restricted objects. The released objects are used by objects of the subsystem 2. In addition, the released objects can be used by objects of the subsystem 2 without any restrictions allowing any type of usage of the released objects. Because a large number of objects of subsystem 2 may use the released objects and because any type of potential usage is possible by the objects of the subsystem 2, such as inheritances from a class or usage of a data structure as part of another data structure, rendering manual check for compatibility errors virtually impossible, no changes are allowed to be made to the released objects according to one embodiment. Alternatively, changes may be introduced to the released objects only with permission of the expert.
The restricted objects are used by a relatively smaller group of objects of the subsystem 2. In one embodiment the server includes a restricted objects table identifying objects of the subsystem 2 utilizing the restricted objects. The restricted objects table may be used by the expert to identify objects that may be affected by a proposed change, when determining whether the proposed change will cause compatibility errors.
In one embodiment the classification of the frozen objects is based on a number of times a particular frozen object is used by the subsystem 2. The object usage monitor 315, during the identification process of the objects of the subsystem 1 that are used by the subsystem 2, may also count instances of usage of each identified object. The number of instances may then be transmitted to the server along with the identification of the objects. The changes monitor 215 classifies frozen objects by determining whether the number of instances for each particular object exceeds a predetermined threshold. If the number of instances exceeds the predetermined threshold then the object is classified as a released object, if the number of instances does not exceed the predetermined threshold then the object is classified as a restricted object.
Usage of the Objects
In one embodiment of the invention, the object usage monitor 315 identifies when a developer attempts to add a new usage of a restricted object by an object of the subsystem 2. The object usage monitor 315 informs the developer that prior to allowing the addition of the new usage, the developer needs to submit a request for adding the new usage to the changes monitor 215 at the server. Upon receiving a request for the new usage instance, the changes monitor adds the new object of the subsystem 2 to the restricted objects table. In addition, the changes monitor determines whether any changes were recently made to the restricted object. If the changes to the restricted object were made, then the changes monitor 215 notifies the developer to ensure that the developer is aware of all the recent changes to eliminate any compatibility errors.
In one embodiment, the changes monitor 215, upon receiving a request for a new usage of a restricted object, determines whether the number of instances of usage of the restricted object exceeds the threshold with the addition of the new usage. If the threshold is exceeded the restricted object may be re-classified as released.
In one embodiment, the object usage monitor 315 identifies when a developer attempts to add a new usage of a non-frozen object of the subsystem 2. The object usage monitor 315 informs the developer that prior to allowing the addition of the new usage, the developer needs to submit a request for adding the new usage to the changes monitor 215 at the server. Upon receiving a request for the new usage, the changes monitor 215 freezes the object of the subsystem 2 by declaring it to be a restricted frozen object.
Global Compatibility Check
In one embodiment of the invention, the changes monitor 215 performs a global compatibility check to ensure that no changes have been introduced into the system that may introduce incompatibility errors since the last global compatibility check. At 710 of
Centralized Compatibility Check for Multiple Subsystems
In one embodiment of the invention, the server hosts several subsystems that are used by the objects at the client. In this embodiment the server includes a master system that provides a centralized compatibility check for all the subsystems located at the server. The master system performs all the functions described above for the subsystems at the server.
It will be appreciated that multiple subsystems located at a client may use multiple subsystems located at a server. In one embodiment an interaction between each pair of two subsystems is associated with a declaration of frozen objects, i.e. objects of one subsystem used by the other. Multiple subsystems using objects of a single subsystem may cause the subsets of the frozen objects to overlap as illustrated in
It will be appreciated that physical processing systems, which embody components of the software development tools mentioned above, may include processing systems such as conventional personal computers (PCs), embedded computing systems and/or server-class computer systems according to one embodiment of the invention.
The processor(s) 400 may include one or more conventional general-purpose or special-purpose programmable microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), or programmable logic devices (PLD), or a combination of such devices. The mass storage device 430 may include any one or more devices suitable for storing large volumes of data in a non-volatile manner, such as magnetic disk or tape, magneto-optical storage device, or any of various types of Digital Video Disk (DVD) or Compact Disk (CD) based storage or a combination of such devices.
The data communication device(s) 460 each may be any device suitable to enable the processing system to communicate data with a remote processing system over a data communication link, such as a wireless transceiver or a conventional telephone modem, a wireless modem, an Integrated Services Digital Network (ISDN) adapter, a Digital Subscriber Line (DSL) modem, a cable modem, a satellite transceiver, an Ethernet adapter, Internal data bus, or the like.
Conclusion
It will be recognized that many of the features and techniques described above may be implemented in software. For example, the described operations may be carried out in a processing system in response to its processor(s) executing sequences of instructions contained in memory of the device. The instructions may be executed from a memory such as RAM and may be loaded from a persistent store, such as a mass storage device, and/or from one or more other remote processing systems. Likewise, hardwired circuitry or firmware may be used in place of software, or in combination with software, to implement the features described herein. Thus, the invention is not limited to any specific combination of hardware circuitry and software, nor is it limited to any particular source of software executed by the processing systems.
Thus, a method and apparatus for backwards compatible software development. Although the invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.
