AN APPROACH TO ANALYSIS OF ARCHIMATE APPLICATION ARCHITECTURE MODELS USING THE SOFTWARE COUPLING METRIC

modeling language, since it can be used not only to represent applications architecture, but is connection to business and technology layers. In order to evaluate applications architecture models, respective ArchiMate metamodel is considered and represented as labeled directed graph, and coupling software metric is selected for analysis. Sample calculations are demonstrated, obtained results are discussed, conclusion and future work directions are formulated.

Introduction. Application architecture designs can be evaluated to ensure that quality attributes are met. Preimplementation architectural approaches are used by system architects during the initial design and preparation stages before actual implementation begins. In contrast to implementation-oriented architecture compliance approaches, it is assessed whether the implemented system architecture matches the intended system architecture. Architectural conformance approach evaluates whether the implemented architecture is consistent with the proposed architecture specification and the objectives of the proposed architecture [1].
Architectural styles, approaches, or techniques are used within the software system design process to evaluate the software architecture in the pre-implementation phase. Approaches or techniques are design decisions that affect the control of the quality attribute response. Architectural styles or patterns describe the structure and interactions between system components [1].
There are software architecture methods in the systems design based on their quality attributes, such as Attribute Driven Design (ADD) [2] (see fig. 1). Fig. 1. ADD method steps [9].
The ADD method is an approach to the definition of software architecture, in which the design process is based on software quality attributes. ADD complies with the recursive design process that decomposes the system or system element by applying the architectural tactics and models that satisfy its driving requirements. As shown in fig. 1 above, adding essentially follows the "plan, do, and check" cycle [3]:  plan: quality attributes and design constraints are considered to select which types of elements will be used in the application architecture;  do: elements are instantiated to satisfy quality attribute requirements (also referred as nonfunctional requirements) as well as functional requirements;  check: the resulting design is analyzed to determine if the requirements are met.
This process is repeated until all architecturally significant requirements are met.
Also there are methods for assessing the conformity of quality attributes to software architecture design, such as the Architecture Tradeoff Analysis Method (ATAM) [4] (see fig. 2). ATAM is a method for evaluating architecture-level designs that considers multiple quality attributes such as modifiability, performance, reliability and security in gaining insight as to whether the fully fleshed out incarnation of the architecture will meet its requirements. The method identifies trade-off points between these attributes, facilitates communication between stakeholders (such as user, developer, customer, maintainer) from the perspective of each attribute, clarifies and refines requirements, and provides a framework for an ongoing, concurrent process of system design and analysis [5].
Problem statement. It is well known that different architectural solutions have their strengths and weaknesses, which may affect development, testing, and maintenance stages of a software system. Therefore, the problem of applications architecture models analysis become relevant, since designed blueprints of the software system should be carefully checked for all presumable inefficiencies in order to avoid extra efforts and related costs for defects fixing in the later project stages.
Вісник Національного технічного університету «ХПІ». Серія: Системний аналіз, управління та інформаційні технології, № 2 (6)'2021 69 This study aims on detection of strong and weak spots of software design solutions by analyzing applications architecture models. Research objective includes the process of applications architecture models analysis. Research subject considers the method for applications architecture models analysis. In order to achieve research goal, there should be selected applications architecture modeling language, defined its metamodel, and proposed measures for structural analysis of designed models.
Materials and methods. Methods ADD and ATAM follow a recursive process based on the quality attributes that the system must meet. At each stage, techniques and architectural patterns (or styles) are selected in case they satisfy certain qualities [1].
More holistic approach to architecture design and analysis ( fig. 3) is proposed by the TOGAF (The Open Group Architecture Framework) [6]. The Architecture Development Methodology (ADM) is used to develop enterprise architecture (EA), which meets the needs of the organization of business and information technologies (IT). Fig. 3. TOGAF ADM method steps [13].
TOGAF is a mature approach for enterprise architecture and framework used by leading world organizations to improve business efficiency. This is the most outstanding and reliable architecture of the enterprise to ensure consistency of standards, methods and communications between professionals of the enterprise of architecture. Professionals working in TOGAF standards enjoy a higher sectorial reputation, efficiency and career capabilities. TOGAF helps practitioners, avoid entering patented methods, achieve more efficient use of resources and achieve a higher return on investment [6].
IT (Information Technology) architecture should carefully reflect the business goals of the organization. In fact, specific technologies (business scenarios) should be used to ensure that it is to correctly understand the business goals and are reflected in the IT architecture designed using TOGAF [6].
ADM is the result of a constant contribution of a large number of practicing architecture in the following goals [6]:  it describes a method for developing and managing the life cycle of EA and forms the TOGAF core;  it can be configured in accordance with the needs of the organization, and then used to implement measures for planning the management system structure.
Even though TOGAF ADM is not that different from the previously considered ADD and ATAM approaches, especially considering the cyclic nature of all of referred methods including ADM, it has significant advantages:  ADM considers business architecture, strategy, and implementation activities, focusing not only on the software quality and functional attributes, but also taking into account the real business needs of customers therefore providing more holistic and reliable approach to application and IT architecture development;  ADM could be formalized using the architectural modeling language proposed by TOGAF -ArchiMate [7].
In order to ensure a single presentation of architectural descriptions, the ArchiMate modeling language was developed, offering an integrated approach to the description and visualization of various organizational regions, their relationships and dependencies. The aim of the ArchiMate project is to provide architects to support tools and improve the process of developing an enterprise architecture. Currently, ArchiMate is the Open Group standard. Organizational areas in ArchiMate are associated with the help of a service-oriented paradigm, where each layer provides the functionality of the preceding layer in the form of services. As a formal language of visual design, ArchiMate supports different points of view for individual stakeholders, and is quite flexible for subsequent expansion. For example, for a more complete covering of the TOGAF methodology, in the second version of the ArchiMate language, were introduced new viewpoints -Motivation Extension and Implementation and Migration Extension (see fig. 3) [7].
Metamodel of ArchiMate active structure applications architecture elements, as well as their interrelationships are demonstrated in fig. 4. All of the proposed elements and relationships are sufficient to design application and IT architectures. In general ArchiMate metamodel [8] includes two main types of elements:  structure elements that can be subdivided into active structure elements and passive structure elements: active structure elements can be further subdivided into external active structure elements (also called interfaces) and internal active structure elements;  behavior elements that can be subdivided into internal behavior elements, external behavior elements (also called services), and events.
Let us clarify on this ArchiMate behavioral and structural building blocks [8], [9]:  active structural elements to which interfaces as external active structure elements (e.g. application and generic or domain-specific internal active structure elements (e.g. application components) belong;  behavior elements include services as external behavior elements (e.g. application services) and generic or domain-specific internal behavior elements (e.g. application functions);  passive structure elements are structural elements that cannot perform behavior, they are often information or data objects, but they can also represent physical objects.
Results. Since ArchiMate language has its own specification and metamodel, architectures of application and IT systems described using this language could be formally described.
Generic framework for EA modeling [9] focused on behavior, active structure, and passive structure elements demonstration is shown in fig. 5. Outlined reference model demonstrates not only elements of different prospects (passive structure and behavior) together with active structure elements mentioned in fig. 4 earlier, but also possible types of relationships between such elements (e.g. composition, assignment, realization, and access) [8], [9].
In general ArchiMate model could be formally described using the following tuple [10]: hereis the set of vertices (define and describe architectural elements of applications and IT); ⊂ ×is the set of edges (define and describe relationships between architectural elements); is the set of types of architectural elements defined by the ArchiMate metamodel; is the set of types of relationships between architectural elements; : →is the function that maps types of architectural elements to the vertices of the graph (1); : →is the function that maps types of relationships to the edges of the graph (1). Hence, using this reference model (see fig. 5) and equation (1) for the first time shown in [10], we can easily apply software metrics to evaluate applications architectture models given in ArchiMate language.
A software coupling measure reflects the strength of interconnection between modules by considering incoming and outgoing connections [11]. As we know from software engineering basics [12]:  "weak" or "low" coupling is a feature of software components that have small amount of external connections (both incoming and outgoing), since they autonomously solve distinct tasks, being efficient for modification, re-using, and testing; "low" coupling is a property of well-structured and properly designed system;  "strong" or "high" coupling in contrast could be considered as a serious shortcoming; "high" coupling is a of bad-structured and poorly designed systems, which are hard for understanding and modification, while distinct components cannot be autonomously tested and re-used.
Therefore, we can formulate the following equation in order to calculate coupling of each applications architecture components: here d ( )is the number of incoming connections of a certain architecture component ∈ ; d ( )is the number of outgoing connections of a certain architecture component ∈ .
Let us also provide the following generalized metric that could be used in order to measure coupling of the whole applications architecture rather than for a distinct software component at is done by (2): here is the generalized coupling measure that can be used if compensation of certain poor-structured application components of "high" coupling by other wellstructured application components of "low" coupling is allowed; is the generalized coupling measure that can be used if compensation of bad applications architecture decisions by good ones as it is mentioned above for is denied to achieve modifiable, maintainable, and reusable software systems.
As well as (2), proposed generalized metric (5) ranges approximately from 0 for "weak" coupling to 1 for "strong" coupling of the whole applications architecture.
In order to verify proposed coupling metrics, let us analyze web presentation patterns presented in Martin Fowler's "Catalog of Patterns of Enterprise Application Architecture" [13]: Results obtained for each of these web presentation enterprise application architecture patterns are shown in table 1 below.  (see table 1 above), the "Model View Controller" web presentation pattern demonstrates the "highest" coupling, while the "Front Controller" web presentation pattern (which is considered as implementation of MVC pattern) shows the "lowest" coupling among application architecture components. Therefore, the "Front Controller" pattern could be recommended as the best solution for enterprise web application architecture design because of its low coupling and, hence, better modifiability, maintainability, and reusability.
Obtained results are proved by almost twenty years of MVC and, in particular, FC dominance in enterprise applications development (see table 2) thank to its concept of never mixing data with presentation. Conclusion and future work. In order to summarize, we need to state that ADM and ArchiMate language are more preferable ways to describe and analyze software application and IT system architectures rather than ADD and ATAM methods, since the TOGAF baseline of ArchiMate considers all of the valuable aspects of customer's business giving more holistic description that takes into account not only software attributes, but also their connections to the goals and strategy of a particular organization, which requires improvement through IT services implementation.
Introduced formalisms (1), (2), and (5) could be used to process ArchiMate models metadata in order to analyze applications architecture domain models, identify poorlydesigned architecture fragments, and resolve inefficiencies in order to avoid further software implementation, testing, and maintenance errors, as well as related expenses caused by "strongly" coupled application components that cannot be properly modified, tested, and re-used [12].
Moreover, graph-based description of applications architecture models allows to use propagation cost analysis (i.e. which percent of all IT landscape will be affected by error fixing or other re-design efforts) used earlier in [15] for business architecture.
Future work in this field includes extension of the proposed approach in order to consider other ArchiMate enterprise architecture domains, such as business and technology layers, as well as information technology design and development in order to implement proposed approach as a tool for practicing system and software architects, researchers, and other stakeholders.