Abstract

Abstract A domain model can provide compact information about its corresponding software system for business people. If the software system exists without its domain model and documentation it is time-consuming to understand its behavior and structure only from the code. Reverse Engineering (RE) tools can be used for obtaining behavior and structure of the software system from source code. After that the domain model can be created. A short overview and an example of obtaining the domain model, Topological Functioning Model (TFM), from source code are provided in the paper. Positive and negative effects of the process of TFM backward derivation are also discussed.

Highlights

  • It is difficult to know the software system by its source code without any system skeleton and documentation, because each developer has his own style of and guidelines for programming

  • The authors of [29] consider that ADMTF processes are transformation between models in such a way from legacy source code to Knowledge Discovery Meta-model (KDM) to Business Process Model and Notation (BPMN) and Semantic of Business Vocabulary and Rules (SBVR) to upgraded BPMN and SBVR to UML diagrams to generated source code. In our case both approaches are appropriate, but in this paper we focus only on Topological Functioning Model (TFM) and UML diagrams, because many different tools exist for UML derivation from the legacy source code

  • Visualizations of the UML class and sequence diagrams are discussed in [2]. It helps in understanding the source code, check correctness of it and compare necessary parts of diagrams with the source code

Read more

Summary

Introduction

It is difficult to know the software system by its source code without any system skeleton (model) and documentation, because each developer has his own style of and guidelines for programming. Development and maintenance of such software systems is a time-consuming and costly process. The backward obtaining of the domain model can be used in such situations, e.g., when migrating to a new technology platform or integrating a new software system. It is used when the information about the software system behavior and structure is absent. Legacy software system architecture is more understandable when it is visualized as a graphical model

Objectives
Results
Discussion
Conclusion
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call