Refactoring is one of the most successful approaches to changing existing software. It is the approach based on systematic transformations of the initial code. Refactoring is the change in the internal structure of software aimed at facilitating the understanding of how it works and simplifying the modification without tackling the observed behavior. It is commonly understood that during a software development process the system design is created first and only then is its code is written. In the course of time the code is modified and the system wholeness, i.e. the correspondence of its structure to the initial design slowly gets worse. The further development of the system gradually shifts from a directed, guided activity to hacking. Refactoring appears to be quite the opposite practice. With its help any chaotic and misguided project can be transformed into a well-designed code. Each step of the process is quite simple. For example, one of the steps involves transferring the field or method from one class into another, class separation, etc. However, the total effect of such minor and seemingly insignificant changes proves to be cumulative and can radically change a project for better. The process of refactoring is a direct opposite to a gradual system code degradation.

For documenting and cataloguing refactoring methods, one uses semiformal notation in which every method is described by means of a so-called pattern. Any pattern describes and names typical tasks which constantly appear in the process of work, and also the principle of their solution. As a result, such solutions can be used over and over again. Patterns name, demarcate and identify key aspects of a general solution structure. Patterns also form the dictionary of solutions to a certain problem area and allow two specialists in that field to name typical solutions and understand each other without explaining the core of solutions.

The refactoring of an object-oriented code has proved to be an efficient means of solving tasks of program evolution and support. However, presently there are practically no studies dealing with refactoring at a higher level of abstraction – the level of software architecture. Correspondingly, the transfer of this methodology to a higher level of abstraction is interesting.

Recently a tendency has arisen towards lifecycle growth of successful program projects. As a result, the volume of the ancestral code supported by the community of developers also grows. This fact helps explain the exceptional importance of tasks related to facilitating the development of the existing program code. At the same time, these tasks receive little attention from the scientific community and tool developers. As a result, contemporary methodologies overestimate the significance of the initial stage of a program system’s life cycle and practically neglect its further evolution. Therefore, there is currently an apparent lack of methodologies and efficient tools for supporting work with a corresponding code.

The situation changes when the question of how transformations can be used systemically as a centrally organizing principle in the process of the development and support of the existing software arises. However, the majority of researchers study transformations at a very narrow angle: as transformations at the level of the initial code, refactoring. Meanwhile, there are practically no studies dealing with transformations at a higher level of abstraction, i.e. at the level of software architecture. At the same time, many scenarios of the support and development of the existing code presuppose a change in the architecture of the existing system. Therefore, the development of the methodology and supporting tools aimed at the organization of a foreseeable and manageable process of changing software architecture is very interesting.

See Softage case study on phone number recognizer refactoring here: Phone Number Recognizer refactoring