by Donatella Castelli, Elvira Locuratolo, Mario Loffredo and Oreste Signore
A reengineering formal method which ensures both a reliable, high level documentation of database code developed with obsolete technologies and its reusability is now being defined in collaboration at two CNR Institutes in Pisa: CNUCE and IEI.
Reengineering is a process comprising both a "reverse engineering" phase which aims at constructing a reliable and high level representation of code developed with obsolete technologies and a "forward engineering" phase directed at refining the representation obtained from the previous phase in order to develop new code. So that we can use the same formal framework to support both reengineering phases, one of our project goals has been that of defining a process which inverts the formal database design methodology employed within the forward engineering process. The choice of the methodology has fallen on ASSO, a formal database design methodology defined at IEI in order to produce db systems with the following high quality attributes: high level specification, reliability and efficiency.
ASSO makes it possible to construct a conceptual schema in which both the structural and the behavioural requirements of the database are specified at a high level of abstraction, i.e. independently of implementation details, and then to transform this schema correctly into a logical schema supported by an efficient database system. The conceptual schema is modelled by an extended semantic model in which each object instance can belong simultaneously to any intersection of subclasses and a pre-conditioned, partial and non-deterministic transaction specification can be given. The logical schema is an object model and thus no object instance can belong simultaneously to two subclasses if one of them is not a subclass of the other. Correct transformation from the semantic model to the object model enables ASSO to ensure achievement of all the quality attributes listed.
In order to invert ASSO, the objects within a software module must be selected and the object classes must be defined. This means that the reverse engineering phase will first consist of an "oo-reengineering" process which is then followed by the "re-ASSO" process which inverts ASSO.
The oo-reengineering process is performed by a tool named TROOP, under development at CNUCE, which deals with both data and procedures. The whole process starts with source code static analysis. All the information extracted from the code and other informal sources is stored in a repository. The various modules of the TROOP tool will subsequently access this information and add new data. The potential objects are the data structures used by different modules of the existing programs (e.g. global variables, record structures). A specialised tool performs the task of reconstructing the database schema. A set of metrics evaluates size, depth in calling tree, reuse frequency, coupling and cohesion of the modules. Subsequently, the procedures are analysed on the basis of the data they access and manipulate, as a first criterion for the identification of "tentative" methods. From the variables hypothesised in the object identification phase, it is possible to proceed to the slicing of the modules: for each connected graph resulting from the slicing process, we consider the possibility of identifying the corresponding code as a method. In the last step, the analysis of the similarities between the potential objects and between the potential methods leads to the identification of the classes and their hierarchies. In all steps, human intervention is involved when taking crucial decisions. The hierarchies obtained are finally formalised in order to define the re-ASSO process.
The re-ASSO process is based on a stepwise approach consisting of two stages:
The first stage starts with an object schema where each object instance belongs to one and only one class. A new schema, equivalent to the previous one, is defined at each step until a model in which each object instance can belong to any class intersection is obtained. The stage is performed automatically, while equivalence guarantees reliability step by step.
The second stage transforms the object methods into a high level behavioural specification in which transactions can be specified in a pre-conditioned, partial and non-deterministic way. At each step, the designer proposes a behavioural specification which is at a higher abstraction level than the previous one and proves first order formulas to guarantee reliability. Once a reliable, high level description of the considered database code has been obtained, it can be reused to complete the reengineering process employing the ASSO methodology.
cnuce.cnr.it