Model-based design of reverse engineering tools

✍ Scribed by Jarzabek, Stan; Wang, Guosheng

• Publisher: John Wiley and Sons
• Year: 1998
• Tongue: English
• Weight: 222 KB
• Volume: 10
• Category: Article
• ISSN: 1040-550X
• DOI: 10.1002/(sici)1096-908x(199809/10)10:5<353::aid-smr178>3.0.co;2-#

✦ Synopsis

Tools built in an ad hoc way and without proper models often display problems for both tool users and designers. Firstly, without systematic analysis and good understanding of the underlying software process model, we have little chance to design a tool that will adequately address users' needs. Next, because one tool is often used in many different situations and by people who have different working habits, tools should be flexible and allow a user to customize tool functionalities. Ad hoc built tools usually are not flexible enough, as possible variations in tool functions have not been incorporated into the tool architecture to make future customizations possible. Finally, ad hoc design practice does not lead to accumulating the tool design knowhow, making it difficult to repeat successful solutions and slowing down the process of understanding and improving tool design methods. We applied conceptual modelling in design of tools for software maintenance to alleviate some of the above problems. In this paper, we describe a model-based method for designing reverse engineering tools. The design starts by modelling low-level source program design models, higher-level design models to be recovered, and heuristic rules a reverse engineering tool uses to recover higher-level designs from lower-level designs. On one hand, conceptual models lead to better understanding of tool requirements. On the other hand, a model-based approach leads to the design of a generic design abstractor, a component of a reverse engineering tool that evaluates reverse engineering heuristics. A generic design abstractor adds flexibility to reverse engineering tools in two ways: (1) we can customize the generic design abstractor to meet the requirements of a reverse engineering project in hand, and (2) a programmer (an end-user of a reverse engineering tool) can define new reverse engineering heuristics and tune-in recovered designs.