Analysis Of Modules Compatibility Before Upgrading Using Dynamic And Static Tools

Most software is composed of modules nowadays. Many modules cooperate and communicate in a system. Sometimes the developers have to update one or more modules in the system, but can the new modules substitute the old modules? Will the function of the other modules be affected? Will the whole system still work normally? These questions should be solved.We use program invariants to analyze these questions. An invariant is a property that holds at a certain point or points in a program; these are often used in assert statements, documentation, and formal specifications. Examples include being constant (x = a), non-zero (x! = 0), being in a range (a < x < b), linear relationships (y = ax +b), ordering (x < y), functions from a library (x = FN(y)), containment (x is an element of y), sortedness (x is sorted), and so on[2].In this article, we suppose that the new module should provide the same interfaces and functions as the old module. Only the way of coding or the efficiency of each module is different.When it is time to update the software, some of the modules of the software are upgraded, but the others stay unchanged. So we can divide all modules to two parts: the modules that will be upgraded and the modules the stay unchanged.So we use two methods to solve the question, which is"whether the new module can upgrade the old module". First, as to the unchanged modules, before updating there are some invariants in them. Because the new modules provide the same interface and function as the old modules, after upgrading, the invariants in the other modules should still hold. If the invariants in other modules do not hold any more, it means there are some problems about the upgrading. Second, as to the updated modules, the new modules should provide all the service that the old modules can provide. We can use this to deduce whether the upgrade is permissible.We use some new methods in this article. First, we deduce whether the update is permissible from two perspectives: the updated modules and the unchanged modules. Second, we use program invariant to analysis whether the upgrade is permissible. Third, because the invariants produced by Daikon are not sound, we use ESC/Java to verify the invariant produced by Daikon. Forth, we use JMLC/JMLRAC tools to verify that whether the invariants in other modules are violated. Fifth, we solve these questions before the upgrading. By this way, we reduce much loss caused by wrong upgrade. KEY WORDS: Software upgrading, Program invariants, JML, Dynamic...