The specifics of describing architecture and its changes is in the fact that as opposed to a program code it has no evident representation, except for those cases when it is clearly documented. However, even in this case it is hard to guarantee the correspondence of documented architecture to the factual high-level logical structure which in reality exists in the system.

Structural models can become means of describing architecture and its changes. There are currently a large number of notations and tools supporting structural modeling of software. The possibility of the automatic extraction of models from a code guarantees their precision and allows for their timely updating. This possibility becomes crucial for choosing the necessary tools as the compliance of the model with the factual structure of the existing code in the process of modeling the architecture and its changes happens to be exceptionally important for securing a precise and manageable process.

For the further study of program systems architecture we will use a notation of structural modeling accepted in KLOCwork Architect tool which allows for the automatic extraction of models from a program code and their editing. Here is a brief review of the notation:

Program system models utilized by KLOCwork Architect are somewhat similar to Entity-Relation models. They belong to a class of container models. The model’s basic elements are as follows:

Architecture Block.KLOCwork Architect model consists of so called architecture blocks. Architecture blocks introduce into models structural elements of a program system irrespective of the level of abstraction in which the modeling takes place. Architecture blocks have at least two major attributes, such as name and type. Names of architecture blocks are predetermined by the names of those structural elements of the system which they introduce into models. Types of architecture blocks substantially depend on the level of abstraction where modeling takes place, and a concrete task within which the research of the architecture is carried out. For example, to model systems built within any component technologies “components” will be the type of architecture blocks used. For modeling systems of building software the chiefly used types will be “folders” and “files”.

Relation. In the model KLOCwork Architect relation means a one-way relation between a pair of architecture blocks. Just like architecture blocks, relations can be of various types. The following types of relations can be used as an example:

Instancing: A instances B (block A is a function, block B is a class).

Access to data: A reads data from B (block A is a function, block B is a class or a class attribute).

Between any pair of blocks there can be a random number of differently directed relations. Their types can also be differentiated at the same time.

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