Please use this identifier to cite or link to this item:
|Title:||Model-based design of reverse engineering tools|
|Authors:||Jarzabek, S. |
|Source:||Jarzabek, S.,Wang, G. (1998). Model-based design of reverse engineering tools. Journal of Software Maintenance and Evolution 10 (5) : 353-380. ScholarBank@NUS Repository.|
|Abstract:||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 know-how, 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. © 1998 John Wiley & Sons, Ltd.|
|Source Title:||Journal of Software Maintenance and Evolution|
|Appears in Collections:||Staff Publications|
Show full item record
Files in This Item:
There are no files associated with this item.
checked on Feb 22, 2018
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.