Restructuring And Simplifying Class Hierarchies In Software Reengineering

Software reengineering is check-up, analyze, subrogation and realization by new formal restructuring。Class hierarchies restructuring in software reengineering is to split class and move operations up or down。Class hierarchies restructuring is an important step and a key in software reengineering。Formal concept analysis essentially describes objects, attributes and the relation between objects and attributes. It is corresponding to objects, members and their transfer relation. Concept lattices, which is the core data of Formal Concept Analysis, essentially describe the relation between objects and attributes, and it is view data through showing by Hasse picture。So it is very natural to apply concept lattices for building class hierarchy in software reengineering. Frame of class hierarchies restructuring is brought forward based on formal concept analysis 。There are five steps to restructure class hierarchy by Hasse picture。First, we must analysis client's program and input to extract static information and dynamic information. Static analysis relies on program alone, and does not run it. We need to abstract class information, members and methods information. Second, we should build objects, attributes and their relation based formal concept analysis. Program's information is transformed table showing the relation between objects and attributes by Java formal arithmetic. It has main steps as follows, confirming program's objects and attributes, getting table entries showing the relation of call, appending and amending table entries, delete assistant entries. Third, we should do with the table by Ganter's arithmetic. There will be a concept lattice showing program's class hierarchy. Forth, class hierarchies predigest. For using class hierarchy well, restructuring and predigest class hierarchies is necessary. The result of restructuring and predigest class hierarchies is again a class hierarchy, which is guaranteed to be behaviorally equivalent to the original hierarchy, but in which each object only contains the members that are required. There are some ways to predigest class hierarchies in this paper, such as delete empty node, delete this pointer, delete object pointer, and predigest redundant inheritance. In this paper the way to deal with the members that is not called by objects is put forward. If there is only members and no objects and object pointers in lattice elements, predigest ion is needed. The simple way is to delete the members. But this way is unreasonable. We will ameliorate this way. (1) If the member that no objects and object pointers call is private, delete the column that the member lays. (2) If the member that no objects and object pointers call is not private, there are two different ways. (a)If the node has only the member that no objects and object pointers call, we should move the member up to its father node, and delete this node. (b)If the node has still other members that objects and object pointers call, we should move the uncalled member up to its father node. Last, showing class hierarchy. It is a key that layout show class hierarchy well readably. In this paper mapping rules denoting lattice elements and table entries, showing rules of lattice elements and disposal rules of class hierarchy is presented.