Enhancing Software Architecture Adaptability: A Comprehensive Evaluation Method

Abstract

The field of self-adaptive software is becoming increasingly crucial because software has to adapt its behavior at runtime to keep up with dynamic and constantly evolving environments. The ability of software to modify and adjust itself is known as adaptability, which has been acknowledged as an important quality attribute. As software architecture development represents the initial stage of the design process, architectural design has emerged as a critical development activity. The degree to which the architecture can adapt to changes will be the key factor in determining the adaptability of the software ultimately released to users. Existing metrics for software architectural adaptability typically view adaptability as a positive attribute, meaning that any possibility of change in architectural elements is perceived as an improvement in adaptability. However, the application of adaptability that leads to increased costs or complexity can only be seen as a negative attribute. In other words, the side effects brought about solely for the purpose of achieving adaptability are greatly overlooked; that is, the impacts caused by adaptability exhibit both symmetry and asymmetry for software architectural adaptability. On the other hand, the existing measures of adaptability only define it from the perspective of whether a module will change, without considering changes beyond the topological structure under multiple strategies. In this paper, we propose a comprehensive assessment approach to measure software architecture adaptability. Multiple factors are considered, including the number and types of strategies employed, the cost of completing the adaptation, the extent of changes made to the architectural elements, and the overall impact of the adaptation on the architecture. An extended UML (e-UML) component diagram is presented to model software architectural changes under various types of strategies. Finally, an experiment on the znn.com software is conducted to validate the practical feasibility of our proposed method. Our approach can assist software architects in making informed decisions regarding software architecture design options to improve the adaptability and longevity of their software systems.

1. Introduction

With the development of network and computing technology, an increasing number of software applications, such as systems-of-systems (SoS), cyber-physical systems (CPSs), and distributed systems [1], have appeared in the world. Moreover, today’s dynamic and ever-changing environment presents many new challenges for self-adaptive software [2]. For example, many cloud-based applications need to modify their behavior at runtime to cope with increasing events, such as resource outages, peak loads, and infrastructure changes [3]. A dual-mode phone can independently detect whether any of the two wireless standards it supports are available at its current location. If available, it will start using that standard without external intervention [4]. Therefore, self-adaptation has become an inevitable demand for modern software systems to address the challenges of meeting dynamic requirements [5,6].

Software adaptability has been recognized as an increasingly important quality attribute (QA) and a part of standardized software quality models, e.g., it is defined as a subcharacteristic of portability in ISO/IEC standards [7]. It is also defined as the fundamental organization and behavior of a system in terms of components and connectors [8,9]. It has a profound impact on the software lifespan and has become one of the most common means to handle adaptive system complexity from a high-level system perspective [10]. It is an artifact in the early software development process, containing almost complete software information [11]. The software adaptability of adaptive software systems should be flexible enough to allow components to change their behavior based on changes in the environment and stakeholders, as well as the system goals. As architecture development is the first stage of the design process, evaluating adaptability at the architecture level to identify weaknesses and further improve adaptability is a very important task for software architects today. Early assessments of software adaptability in architecture can effectively identify deficiencies in the architecture, thereby aiding in modifying the architecture design [12]. A large amount of work has proven that when adaptive software is actually running online, the adaptability of the architecture directly determines its adaptability [13,14].

Subramanian and Chung [15] first introduced indicators for quantifying software architecture adaptability, which inspired subsequent definitions in this way. They defined three generic adaptability indices for software architecture, namely the element adaptability index (EAI), architecture adaptability index (AAI), and software adaptability index (SAI). They also proposed a framework called process-oriented metrics for software architecture adaptability (POMSAA), aimed at providing numerical scores representing architecture adaptability and the intuition behind these scores [16]. Their method can identify some weaknesses in the architecture, but it relies too heavily on intuition and expert expertise, which leads to considerable uncertainty. Liu et al. proposed a quantitative evaluation approach for architecture adaptability based on scenario introduction and impact analysis [12]. Zhang et al. proposed a method for connector reuse and reconfiguration using an aspect-oriented (AOP) mechanism considering environmental changes [17]. Tarvainen employed an evaluation method that defines how to negotiate adaptability requirements and map them to the architecture before system implementation, how to represent these requirements at the architecture level, and how to evaluate and analyze the architecture to verify whether the requirements are met [18]. Ding et al. adopted a framework that supports online reconfiguration in the adaptation loop of sensing, decision, and execution for adaptive software. Their framework supports encapsulating adaptation concerns into a dynamically reconfigurable architectural style [19]. Perez et al. suggested indicators that take into account the number of components that provide services to form the software architecture [20]. The weighted adaptability index of each service is aggregated to obtain the overall system adaptability. Furthermore, due to some possible tradeoffs, they suggested monitoring adaptability based on other QAs, such as availability, cost, and response time. Their views help to select the most adaptable architecture to meet the required QA. They also implemented a tool for automated analysis [20,21]. Kaddoum et al. measured the number of elements inserted into the adaptive part and the number of functional elements that are dependent on the adaptive part, as well as the minimum and average number of elements needed for each adaptive function [22].

Although the indicators proposed in the above studies can quantify the adaptability of software architecture through numerical scores, they have the following disadvantages. First, most existing studies view adaptability as an adjustment ability of the architecture and the degree of satisfaction with adaptation goals. They view adaptability as a beneficial attribute of architecture, meaning that regardless of what changes it causes, adaptability will be seen as positive growth. However, the impact caused by architectural adaptability is both symmetrical and asymmetrical. That is, there are two aspects to the effects of architectural adaptability, both positive and negative. Positive impacts are those that have a positive impact on the adaptability of the system, i.e., increased adaptability. On the other hand, negative impacts refer to those that negatively affect the adaptability of the system. For example, removing one component may lead to poor variability in the function of other components. Second, existing studies mostly focus on the changes in the structural elements of the architecture, namely the changes in components and connectors, while ignoring the changes in parameters. However, there are two adaptive methods for adaptive software, namely structure adaptation and parameter adaptation. Therefore, both adaptation methods should be considered simultaneously, and only considering changes in components or connectors cannot fully evaluate the adaptability of the entire architecture.

To address the aforementioned issues, we have made several contributions to our work, including the following:

• Our method considers both the positive and negative impacts on adaptability and proposes a multifactor architecture adaptability evaluation method. This method takes into account various aspects, such as the number and type of adaptive strategies used, the adaptive cost, and the degree of change to architecture elements.
• To further enhance our approach, we categorize adaptation strategies into different categories, including component structure change strategies, component parameter change strategies, and connector parameter change strategies. For each category, we also measure the degree of change in software architecture elements, including component changes, component function changes, and connector changes.
• We propose an extended UML component diagram to model the changes in software architecture driven by adaptive strategies.
• We conduct an experimental study on the znn.com software system to demonstrate the practical application and effectiveness of our proposed method. This study validates the effectiveness of our multifactor evaluation method and provides evidence for its potential to improve software architecture adaptability.

The remainder of this paper is structured as follows. In Section 2, we outline the background and related works in the field of software architecture adaptability. Then, we describe the redefinition of software architecture adaptability metrics under different types of strategies, extend the UML component diagram to model software architecture changes, and present the metrification method and key procedures in Section 3. In Section 4, we demonstrate the practical application of our method through a case study of the znn.com software system. In Section 5, we analyze the threats to validity. Finally, in Section 6, we identify potential future research directions aimed at further improving the adaptability of software architecture.

2. Related Works

The aim of our work is to propose a comprehensive evaluation approach for the metrics of software architectural adaptability. Thus, we review related works in the literature that address (i) metrics for the evaluation of adaptability and (ii) measurement methods.

2.1. The Definitions of Metrics for Software Architecture Adaptability

Metrics for software architecture adaptability have been proposed in the literature, including the work of Raibulet et al., who proposed a set of metrics for information system adaptability. These metrics were grouped into six categories as follows: architecture, structure, performance, interaction, documentation, and miscellaneous. These categories covered various aspects related to software architecture adaptability, such as the system’s ability to modify its behavior or structure, its ability to effectively interact with other systems, and the quality and usefulness of its documentation [23]. Pimentel et al. proposed two architecture adaptability metrics derived from i* models. These metrics utilize goal-based models to describe the software architecture and consider the additional information provided by i* models to offer a more comprehensive evaluation of software architecture adaptability. The goal-based models provide a richer architecture model, which can help to provide rationales for architectural decisions. While this approach offers promising results, it is limited by its focus on i* models and goal-based models, which may not be applicable to all software systems [24]. In addition, there are other studies related to specific application domains and/or considering a particular perspective on adaptability, e.g., web service business process execution language (WS-BPEL) is strongly supported by the industry and the open-source community, whereas a number of BPEL engines have been developed, such as Oracle’s BPEL Process Manager, Microsoft’s BizTalk Server, IBM’s WebSphere Process Server, SAP’s Exchange Infrastructure, and the Apache ODE. However, the actual portability of process code written in process languages, such as the business process model and Notation 2.0 or the web services business process execution language, is often difficult to achieve due to the natural imperfection and different priorities of runtime environments. Lenhard et al. proposed a method to determine the level of structural adaptability in BPMN processes, which measures how easily a process can be transformed into a different form while maintaining the same runtime behavior. This is particularly relevant because process languages are commonly used in service-oriented systems, and there are numerous specifications available for this purpose [25]. Afterwards, they theoretically validated their metrics using two different measurement frameworks to ensure their accuracy and reliability [26]. Rather than measuring the adaptability of a static process structure, Botangen et al. adopted metrics to assess how well an AO4BPEL process could adapt to highly dynamic contexts. By taking this perspective, they were able to gain insights into how systems perform under constantly changing conditions [27]. They extended their study in several aspects, including metric definitions based on two dimensions as follows: structural variability and binding variability. They utilized these metrics to evaluate the adaptability of processes defined by various BPEL-based frameworks, regardless of their implementation mechanisms. When comparing specification frameworks, their maximum adaptability for a given process is often used as a key metric [28]. Masciadri et al. assessed the flexibility of development frameworks for adaptive systems using a range of metrics. These metrics were grouped into two categories—personalization and documentation—with the goal of establishing a shared vocabulary for evaluating and comparing adaptability [29]. In addition, they provided 21 metrics to measure the dynamic adaptability of adaptive systems, which are categorized into four groups as follows: architectural, structural, interaction, and performance. These metrics primarily assess the design quality of adaptive systems, with interaction and performance metrics serving as indicators of their functional quality [30].

2.2. Metrification Methods

Regarding measurement methods, previous research has primarily focused on three approaches, namely process-oriented measurement, target problem measurement, and scenario-based measurement. Among them, scenario-based measurements are the most commonly used. Kaddoum et al. employed the traditional brainstorming approach to generate adaptation scenarios [22]. Once the adaptive scenario has been developed, stakeholders proceed to analyze the weight of each scenario and calculate its significance. The weight assigned to each scenario reflects its importance or likelihood of occurrence. This process enables stakeholders to prioritize their focus and allocate resources accordingly, ensuring that they are well prepared for any potential challenges or opportunities that may arise. Yang et al. proposed a method to ensure that runtime-dependent QAs are identified by leveraging existing architectural analysis techniques, such as the architecture-based tradeoff analysis method (ATAM). This approach helps to identify QAs that cannot be guaranteed during the design phase. After that, an adaptive strategy is designed and incorporated into a traditional architectural model, thus becoming an adaptive architectural model described by extended ABC/ADL. Following this, an adaptive strategy is developed and integrated into a conventional architectural model, transforming it into an adaptable architectural model that is described using extended ABC/ADL. Subsequently, the adaptable architectural model is deployed in reflective middleware, which is responsible for monitoring runtime systems and environments, interpreting criteria for selecting strategies, and implementing appropriate adaptive strategies to ensure the desired quality attributes at runtime [31]. Aleti et al. explored automatic search methods that aim to find the best architecture design for multiple QAs, such as performance, cost, scalability, security, reliability, availability, and dependability [32]. Sara et al. conducted a systematic review of methods for architecture-based self-adaptive systems that consider these QAs and tradeoff analyses [33]. Peng et al. proposed a quantitative measurement technique for aspect-oriented software architecture adaptability based on class point (CP) and AC2-ADL features [34]. Tarvainen introduced the adaptability evaluation method (AEM) and validated it using an actual wireless environmental control system, which is an integral part of the quality-driven architecture design and quality analysis methodology, specializing in adaptability-related aspects [35]. Briones et al. reused existing modeling languages and tools, combined them, and created new modeling languages and tools to address the adaptability and composability of quality of service (QoS), with the ultimate goal of evaluating architecture models to predict the behavior of systems [36].

In summary, dissimilar to the existing works, this paper presents the following:

• Software architecture adaptability metrics are redefined to consider the negative effects of adaptation.
• Changes outside of the topology structure under multiple strategies are considered.
• The consideration of a visual modeling language to represent possible dynamic changes.
• Multiple factors, including the number and type of strategies, the cost of completing the adaptation, the extent of changes to architectural elements, and the overall impact of the adaptation on the architecture, are considered.

3. Proposed Methods

This paper is mainly divided into five parts as follows: the identification and classification of adaptation strategies, the modeling of architectural changes taking into account both the structure and parameters, the modeling of the domain and extent of the change, modeling based on the e-UML component diagram, and the evaluation algorithm. Figure 1 illustrates the research framework of this paper. From this section onwards, the comprehensive evaluation method will be studied according to the research ideas shown in the framework.

3.1. Redefinition of Software Architecture Adaptability Metrics

In the adjustment of software architecture, there are two main types of strategies: structure adaptation strategies and parameter adaptation strategies.

3.1.1. Redefinition of Adaptability under Structural Adaptation

Among the two types of strategies, structure adaptation adjusts the topology of the architecture by changing the settings of its components. This process includes adding, deleting, and replacing components.

In software architecture, a component is a unit of software that serves a specific function. It acts as an abstraction of a computing or storage unit and can take various forms, such as a subsystem, module, object, or database. Components are self-contained, configurable, and replaceable entities that interact with one another through connectors. Intercomponent interaction refers to the way components communicate with each other, which involves passing messages back and forth. These interactions can be categorized as either dependency or aggregation. Message passing between components can be further divided into two parts as follows: how the message is triggered and how it is delivered. The triggering method can be either synchronous or asynchronous, while the delivery mechanism usually refers to the protocol in use. It is worth noting that, in this paper, the components of software architecture referred to being exclusively related to functional components.

Connectors, on the other hand, describe interactions between components that are dependent on those components. Therefore, the addition, deletion, and replacement of connectors fall outside the scope of architectural configuration in this paper.

3.1.2. Redefinition of Adaptability under Parameter Adaptation

Parameter adaptation for software architecture involves adjusting relevant parameters for components and connectors.

A component’s parameter is a collective term for any variable element that makes up a component. Here, three concepts are introduced as follows: component atomic function, component function mode, and component object node. A component atomic function refers to the smallest unit that implements a component’s function. A component function mode is a collection of component atomic functions. A component object node is a collection of elements within a component that execute atomic functions. Each object node corresponds to an atomic service; that is, each object node is capable of implementing only one atomic service. The parameters are assigned to each object node and can be modified by decision points, which change the function and state implemented by the object node and ultimately complete the adaptation of the component parameters.

Connectors are architectural elements used to establish and regulate interactions between components and may take the form of pipes, communication protocols, or other communication mechanisms. Connector parameters are variables that describe objects that allow for interactions between components. In this paper, the connector parameters specifically refer to the message invocation and transmission mode parameters. The configuration of connector parameters involves adjusting the type of message invocation and transmission mode, which is typically achieved by changing the connector’s parameter settings for message invocation and transmission mode, i.e., the protocol type.

We divide the effects caused by architecture adaptability into two categories as follows: positive effects and negative effects. Positive effects pertain to those that have a positive impact on the system’s adaptability, i.e., improve adaptability. These factors include the number and types of structural support adaptation strategies employed, as well as the amount and type of architectural elements changed. On the other hand, negative effects refer to those that have a negative impact on the system’s adaptability, i.e., the cost of performing the adaptation process and the extent to which the overall architecture reduces adaptability after adaptation. These factors hinder or reduce the system’s ability to adjust and include the difficulty of implementing the architecture adaptation strategy and the degree to which the overall architecture is impacted following adaptation.

Considering the negative effects of adaptation from the perspective of cost and complexity added to the structure and refining the diversity of adaptation from the number and type of strategies, we comprehensively consider the above two kinds of effects and propose a multifactor software architecture adaptability evaluation method, which includes the number and types of adaptation strategies, the cost of performing the adaptation process, the degree of architectural element change, and the extent to which the overall architecture is affected after adaptation.

3.2. Modeling Based on the e-UML Component Diagram

To model the changes in software architecture under different types of change strategies, we extend the UML component diagram, which helps to intuitively show the dynamic changes in the component structure or the component and connector parameters driven by the change strategies, thereby intuitively determining the change domain and change influence domain of the software architecture.

3.2.1. The Principle of UML Extension

UML lacks sufficient mechanisms to address adaptability, such as describing the changes in the architecture under candidate strategies, but we still need to rely on a component-and-connector view of the software architecture to define metrics since this view is commonly used to reason about runtime system quality attributes. Thereafter, we extend the UML component diagram to embody the changes in the architecture under the candidate strategies.

The extensions are shown in

Table 1. Elements of the e-UML component diagram.

Extended Elements	Descriptions
stereotype ≪condition!≫	It is used to denote the relationship between connectors or components, indicating that the initial invocation operation does not occur, and the invocation operation occurs under the drive of the component structure change strategy.
stereotype ≪!condition≫	It is used to denote the relationship between connectors or components, indicating that when the initial invocation operation occurs, the invocation operation does not occur under the drive of the component structure change strategy any longer.
stereotype ≪connect≫	It is used to modify the relationship between connectors or components, indicating that they are the caller and callee between these two components.
stereotype ≪modification!≫	It indicates that the initial modification of component parameters or connector parameters does not occur, and the modification operation occurs under the drive of the component parameter change strategy or the connector parameter change strategy.
tag value StateAttribut	It is used to describe the state of the component, where there are three values, namely the state in use, called occupied, the wait state, called wait, and the active state, called active, which indicate the state transition of the components in the process of binding and unbinding.
tag value FunctionMode	It is used to describe the functional mode of the components; the tag value of FunctionMode has two values, which are the constant value of “invariable” and the variable value of “variable”.
tag value MessageInvokeType	It is used to describe the relationship between connectors or components, indicating the way of message invocation between two components.
tag value ProtocolType	It is used to describe the relationship between connectors or components, indicating the way messages are transmitted between two components.

.

The above extensions to the UML component diagram are based on the following three principles:

(1)

Stereotype refers to adding a new element on the basis of the original model structure so that the model has additional description capabilities. Stereotypes are usually represented by double angle brackets and literals or strings within brackets, such as ≪delete≫, ≪path≫, and so on;

(2)

The tag value uses a pair of strings (a tag string and a value) to describe some values of model elements or new properties of elements. The tag value can be used to record developer information, code information, logs, code templates, etc., and even to add code generation instructions.

(3)

Constraints refer to the use of literal expressions for regulations or restrictions. Constraints can be represented as strings within curly braces and can be attached to elements, dependencies, and annotations.

The invocation between components can be regarded as a process in which a component interacts with other components through its own specifications and interfaces to realize functional requirements or business processes. As shown in Figure 2, Component 1 is the component that initiates the call, and its interface describes the required service, which is marked as R|1; Component 2 is the called component, and its interface describes the service provided, which corresponds to P|2. The interaction between the two components is realized by binding the interfaces of the components.

We defined three states to describe the changes in the state of the component itself during the call process, namely the occupied state (occupied), the waiting state (wait), and the active state (active).

As shown in Figure 2, the interaction between the two components is bound through the interface of the component, and whether the component is called or callee is marked on the interface. The stereotype describing the relationship between the components is marked on the binding connection line of the two interfaces.

3.2.2. Modeling Changes in Architecture through the e-UML Component Diagram

The specific operations under the component structure change strategy include the addition, deletion, and replacement of components. Although these operations ultimately change the topology of the architecture, they also involve changes in the state of the components and changes in the interaction behavior during the execution process.

• Condition 1: component addition operation

Figure 3 shows the changes under component addition operations through an e-UML component diagram. The prototype ≪condition!≫ indicates that when a component is added, the initial invocation operation between Component 1 and Component 2 will not occur. Component 2 is a newly added component, with a label value StateAttribut equal to occupied, indicating that after calling Component 2, Component 1 changes its state to “occupied”.

The entire change process can be described as follows:

(1)

Due to environmental changes, the analyzer and planner in adaptive logic need to add a new component to the architecture after analysis.

(2)

The executor of the adaptation logic imposes a component structure change strategy on the architecture, and the specific execution action of the strategy is the component addition operation.

(3)

Under the operation of this strategy, Component 1 releases the call requirement through its interface, and then the component manager finds a suitable component according to the requirement published by Component 1 and the description of idle components in the component pool providing services to the outside Component 2.

(4)

Components 1 and 2 complete the calling and being called through the binding of the interface. During the binding process, the state of Component 2 changes from “wait” to “active”. After binding is completed, the state of Component 2 changes from “active” to “occupied”.

b.

Condition 2: component deletion operation

Figure 4 describes the change in the architecture under the component deletion operation, where the stereotype ≪! condition≫ indicates that the initial invocation operation between Component 1 and 2 occurs, and the invocation operation no longer occurs when the component is deleted. Component 2 is a deleted component, and the tag value StateAttribut equals to wait indicates that after Component 2 stops being called by Component 1, its own state changes to “wait”.

The entire process can be described as follows:

(1)

Due to changes in the environment, the analyzer and planner in adaptive logic need to delete a certain component in the architecture after analysis.

(2)

The executor of the adaptation logic imposes a component structure change strategy on the architecture, and the specific execution action of the strategy is to delete the component operation.

(3)

Under the action of this strategy, Component 1 and 2 are unbound through the interface.

(4)

After unbinding, the state of Component 2 changes from “occupied” to “wait”.

c.

Condition 3: component replacement operation

Figure 5 describes the change in the architecture under the component replacement operation, where Component 2 is replaced by Component 3. Stereotype ≪! condition≫ indicates that the initial call operation between Component 1 and 2 occurs, and the call operation no longer occurs under the replacement component operation. The flag value StateAttribut equals to wait indicates that after Component 2 stops being called by Component 1, its own state changes to “wait”. The stereotype ≪condition!≫ indicates that the initial invocation operation between Component 1 and 3 does not occur, and the invocation operation occurs under the action of the component replacement operation. The component replacement operation is equivalent to performing the component deletion operation first and then completing the component addition operation.

The entire change process can be described as follows:

(1)

Due to changes in the environment, the analyzer and planner in adaptive logic need to replace a component in the architecture after analysis.

(2)

The executor of adaptive logic imposes a component structure change strategy on the architecture, and the specific execution action of the strategy is the component replacement operation.

(3)

Under the action of this strategy, Component 1 and 2 are unbound through the interface.

(4)

After unbinding, the state of Component 2 changes from “occupied” to “wait”.

(5)

Unbound Component 1 publishes the calling requirements through its interface, and then the component manager finds the appropriate Component 3 according to the requirements published by Component 1 and the description of the services provided by the idle components in the component pool.

(6)

Component 1 and 3 complete the calling and being called through the binding of the interface. During the binding process, the state of Component 3 changes from “wait” to “active”. After binding is completed, Component 3 changes from “active” to “occupied”.

d.

Condition 4: modifying component parameter operation

Among the software adaptive adjustment methods, component parameter adjustment is a lightweight adjustment method. Our approach considers that the parameter adjustment of the component does not change the topology of the architecture, but only changes the functional mode of the component.

Therefore, the architecture adaptation method corresponding to the component parameter change strategy is mainly the change in the component function mode. When modeling the component parameter change strategy, the component diagram is used to describe the calling relationship between the two components, the stereotype ≪modification!≫ is assigned to the component with parameter change, and the component tag value FunctionMode is assigned accordingly.

As shown in Figure 6, the parameter mode of Component 2 is changed, and the binding connection line between Component 2 and 1, which already has a calling relationship, is marked with the stereotype ≪connect≫, which indicates that there is a calling relationship between the components. Then, the stereotype ≪modification!≫ is set on Component 2, and the stereotype ≪modification!≫ indicates that the operation of initially modifying the parameters of Component 2 in the process of invoking Component 2 by Component 1 does not occur; then, the operation of modifying the parameters of Component 2 occurs under the drive of the component parameter change strategy. Then, the flag value FunctionMode is set on Component 2, and the flag value FunctionMode indicates that the function mode of Component 2 has changed under the action of the component parameter change strategy. In Figure 6, the attribute value of the tag value FunctionMode of Component 2 is variable.

e.

Condition 5: modifying message calling mode operation

There are two types of operations involved in the connector parameter change strategy, namely changing the message calling mode and changing the transmission mode. The model for changing the message calling mode is shown in Figure 7 and Figure 8, and the model for changing the message transmission mode is shown in Figure 9.

As shown in Figure 7, there is a message calling between Component 1 and 2. The message calling mode is synchronous, where the synchronous message is represented by a call and a return, and the asynchronous message is represented by the keyword invoke. An optional condition is set in the sequence diagram describing the message calling of Component 1 and 2. The optional condition is to modify the message calling mode MessageInvokeType, which indicates the change operation of the message calling mode in the connector parameter change strategy. The parameter is marked as the changed message calling method between components, and the parameter MessageInvokeType = asynchronous is set, indicating that the message calling method between Component 1 and 2 is changed from the original synchronous call to the asynchronous call.

As shown in Figure 8, there is a message calling between Component 1 and 2, and the message calling mode is asynchronous. The optional condition is to modify the message calling mode MessageInvokeType, which indicates the change operation of the message calling mode in the parameter change strategy of the connector. The parameter MessageInvokeType = synchronous of the optional condition indicates that the message invocation method between Component 1 and 2, called by the original asynchronous call, is changed to a synchronous call.

f.

Condition 6: modifying message transmission mode operation

The change in the way of message transmission is mainly realized by changing the protocol type. The four most commonly used protocol types are TCP, UDP, HTTP, and HTTPS.

As shown in Figure 9, there is a message call between Component 1 and 2, and the message transmission mode is the HTTP protocol. The condition for setting the optional segment to change ProtocolType indicates the change operation of the message transmission method in the connector parameter change policy. The parameter of the optional segment is the modified message delivery method. That is, setting the parameter ProtocolType = HTTPS means that the message transmission method between Component 1 and 2 is changed from the original HTTP protocol to the HTTPS protocol.

The architectural adaptation method corresponding to the connector parameter change strategy is mainly the change in the interaction between components. As shown in Figure 10, the stereotype ≪modification!≫ is marked on the binding connection line of Component 1, called Component 2, indicating that the operation of initially modifying the parameters of the connector does not occur during the process of calling Component 2, and that when the parameters of the connector are changed, the operation of modifying the parameters of the connector occurs under the policy’s drive; the tag values MessageInvokeType and ProtocolType are added to the interface of Component 1 to describe the changes in the message invocation mode and message transmission mode between components under the action of the connector parameter change strategy.

3.3. Method of Software Architecture Adaptability Metrification

3.3.1. Overview

Figure 11 provides an overview of our approach, where there are six steps in total. First, the adaptation strategy for the software architecture is obtained from documents such as design documents and requirements specifications, and then the following steps are performed for each adaptation strategy.

Step 1: Classify the candidate strategies.

The candidate strategies for adaptation can be divided into three categories as follows: the component structure change strategy, component parameter change strategy, and connector parameter change strategy.

There are five types of operations, namely adding components, deleting components, replacing components, changing component parameters, and changing connector parameters. When components are added, deleted, or replaced, the topology of the software system will be adjusted, which is called the component structure change strategy. When the component parameters are changed, the functional state of the component will be adjusted, which is the component parameter change strategy. When the connector parameters are changed, the message invocation or transmission method, which is part of the connector parameter change strategy, will change.

Step 2: Measure the change degree.

The change degree of software architectural elements for the adaptive strategy, including component change, component function change, and connector change, is measured.

For the component structure change strategy, the component change rate is measured through calculating the ratio of the number of software architecture components that change to the total number of components after the change driven by the adaptive strategy. For the component parameter change strategy, we measure the component function change rate, specifically calculating the ratio of the number of components whose functions are changed due to the adjustment of component parameters and the total number of software architecture components driven by the strategy.

Step 3: Model the changes in architecture.

An e-UML component diagram is used to model the changes in architecture. At the software architectural level, the relationship between two components is represented by binding the interface of the component, marking whether the component is called or calling on the interface, and marking the UML structure describing the relationship between the components on the binding connection line of the two interfaces.

When the component parameters change, the UML stereotype element used to describe the modification operation will be marked on the component; when the connector parameters change, the component interface for a UML tag value element that describes a change in the way that a piece of message is invoked or how the message is delivered is added.

All changes continue until no new changes become available.

Step 4: Assign the weight for the implementation difficulty.

Based on the component graph, under the drive of the adaptation strategy, the weights for the implementation difficulty of each type of change in the adaptive strategy are assigned.

The larger the weight is, the easier it is to implement.

Step 5: Determine the degree of change impact.

Based on the component diagram model established in Step 3, determine the degree of change impact under each change in the adaptive strategy. For each change driven by the adaptive strategy, the following steps are repeated for all alternative strategies and all elements of the architecture.

(1) Determine the change domain and change impact domain of the software architecture by the component diagram model, where the change domain is a collection of components and connectors that change under the drive of the change strategy, and the change impact domain has a direct interaction relationship with the change domain. In the set of components that are still in the active state after the change is made, the component that changes, driven by the connector parameter change strategy, is the component that initiates the call and belongs to the component in the change domain, and the called component belongs to the component in the change impact domain.

(2) Calculate the impact of change

$$AED=\frac{{\displaystyle \sum _{r=1}^{N}CI{D}_r{\lambda }_r}}{N}$$

(1)

where N represents the number of components in the change impact domain, $CI{D}_r$ represents the importance of the rth component in the change impact domain, and ${\lambda }_r$ represents the coefficient between the rth component and the impacted component.

If the adaptive strategies include $n$ component structure change strategies, $m$ component parameter change strategies, and $l$ connector parameter change strategies, the adaptability AA of the software architecture is calculated as follows:

$$AA={\displaystyle \sum _{j=1}^n\left[P{a}_{j}C{a}_{j}AED\left(a_j\right)\right]}+{\displaystyle \sum _{i=1}^m\left[P{b}_{i}C{b}_{i}AED\left(b_i\right)\right]}+{\displaystyle \sum _{k=1}^l\left[P{c}_{k}C{c}_{k}AED\left(c_k\right)\right]}$$

(2)

where $P{a}_j$, $C{a}_j$, and $AED\left(a_j\right)$ represent the component change rate, implementation difficulty weight, and impact degree of the $j\mathrm{t}\mathrm{h}$ component structure change strategy, respectively. $P{b}_i$, $C{b}_i$, and $AED\left(b_i\right)$ denote the $i\mathrm{t}\mathrm{h}$ component function change rate, implementation difficulty weight, and impact degree of the component parameter change strategy, respectively. $P{b}_k$, $C{b}_k$, and $AED\left(b_k\right)$ indicate the connector change rate, implementation difficulty weight, and impact degree of the $k\mathrm{t}\mathrm{h}$ connector parameter change strategy, respectively.

Step 6: Calculate the overall adaptability.

The overall adaptability of the software architecture driven by all the adaptive strategies is calculated.

3.3.2. Important Steps

Elicit Adaptation Strategies

An adaptation strategy can be regarded as a set of tactics that will trigger a collection of operations, which can be denoted as a triplet $\langle EnvChange,Condition,Operate\rangle$, where $EnvChange$ refers to the change in the environment, $Condition$ is the condition that must be satisfied to trigger adaptation, and $Operate$ describes a set of specific actions to change the behavior of the target system.

Changes in the environment refer to changes in the computing environment and user environment. The trigger condition can be taken as a kind of guard condition preset in the adaptive mechanism; that is, when the change in the environment reaches a certain threshold, the trigger condition of the strategy is satisfied.

An operation can be described as a two-tuple $\langle Object,Action\rangle$, which includes an object and an action. The object refers to the components and connectors at the software architecture level and the parameters contained in the components and connectors. There are five types of operations for the adaptive strategy as follows: adding components, denoted as Add_Comp; deleting components, denoted as Del_Comp; replacing components, represented as Rep_Comp; changing component parameters, shown as Change_CompPar; and changing connector parameters, denoted as Change_ConnPar.

Structural adaptation and parameter adaptation can adjust the architecture in the following three ways:

(1)

Adjustment of the topology structure. This is mainly completed by adjusting the components and connectors, including the addition, deletion, and replacement of components or connectors.

(2)

Adjustment of the functional state mode. This refers to changing the functional state mode of the component by changing the component parameters.

(3)

Adjustment of the interaction between components. This refers to changing the way of message calling or transmission between components by changing the parameters of the connector.

An adaptive strategy may correspond to changes in many modules, connectors, and parameters. Therefore, according to the operations involved, strategies are divided into three types, as described in

Table 2. Correspondence between adjustment forms, adaptation strategies, and operations.

Adjustment Forms	Adaptive Strategies	Operations
Adjustment of topology	Component structure change strategy	Add components
		Remove components
		Replace components
Adjustment of function status	Component parameter change strategy	Change component parameters
Adjustment of interaction between components	Connector parameter change strategy	Change how the message is called
		Change how the message is delivered

. An adaptive strategy consists of three types of strategies or two of them or one of them.

AA is defined as the metric for architecture adaptability, which is expressed as follows:

$$AA=P\times C\times AED$$

(3)

where $P$ represents the degree of the change under the adaptive strategy, whose value equals the change ratio; $C$ denotes the difficulty of implementing the adaptive strategy; and $AED$ represents the extent to which the software architecture is affected after the implementation of the adaptive strategy.

Since the adaptive strategies are divided into three types, in (3), $P$, $C$, and $AED$ are further refined. Let three types of strategies be denoted as a, b, and c. Suppose that there are strategies including n component structure change strategies, m component parameter change strategies, and l connector parameter change strategies, then,

• When implementing the component structure change strategy, suppose the following:

  (1)

  $P{a}_j$ represents an element adaptability value; that is, the architectural component change rate under the jth component structure change strategy.

  (2)

  $C{a}_j$ denotes the weight of the difficulty in implementing the jth component structure change strategy.

  (3)

  $AED\left(a_j\right)$ indicates the degree of impact after executing the jth component structure change strategy.

According to (3), when implementing the component structure change strategy, AA(a) of the architecture can be expressed as follows:

$$AA\left(a\right)={\displaystyle \sum _{j=1}^n\left[P{a}_{j}C{a}_{j}AED\left(a_j\right)\right]}$$

(4)

b.

When implementing the component parameter change strategy, suppose the following:

(1)

$P{b}_i$ represents the component change rate under the ith component parameter change strategy.

(2)

$C{b}_i$ denotes the weight of the difficulty in implementing the ith component parameter change strategy.

(3)

$AED\left(b_i\right)$ indicates the degree of impact after executing the ith component parameter change strategy.

According to (3), when the component parameter change strategy is executed, AA(b) of the architecture is denoted as follows:

$$AA\left(b\right)={\displaystyle \sum _{i=1}^m\left[P{b}_{i}C{b}_{i}AED\left(b_i\right)\right]}$$

(5)

c.

When executing the connector parameter change strategy, suppose the following:

(1)

$P{c}_k$ represents the change rate of the $k$th connector under the connector parameter change strategy.

(2)

$C{c}_k$ denotes the weight of the difficulty in implementing the $k$th connector parameter change strategy.

(3)

$AED\left(c_k\right)$ indicates the degree of impact after executing the $k$th connector parameter change strategy.

According to (3), when executing the connector parameter change strategy, AA(c) of the architecture is shown as follows:

$$AA\left(c\right)={\displaystyle \sum _{k=1}^l\left[P{c}_{k}C{c}_{k}AED\left(c_k\right)\right]}$$

(6)

According to (4) to (6), the architecture adaptability (3) can be expressed as follows:

$$AA={\displaystyle \sum _{j=1}^n\left[P{a}_{j}C{a}_{j}AED\left(a_j\right)\right]}+{\displaystyle \sum _{i=1}^m\left[P{b}_{i}C{b}_{i}AED\left(b_i\right)\right]}+{\displaystyle \sum _{k=1}^l\left[P{c}_{k}C{c}_{k}AED\left(c_k\right)\right]}$$

(7)

Measure Change Degree

For each strategy, the component change rate, component function change rate, and connector change rate are calculated. The component change rate refers to the ratio of the number of architectural modifiable components driven by the adaptive strategy to the total number of components after the change; that is, the metric of the component change ratio (CCR) is shown as follows:

$$CCR=\frac{AddCompNumber+RepCompNumber+delCompNumber}{IniCompNumber+AddCompNumber-delCompNumber}$$

(8)

where $AddCompNumber$ represents the number of added components, $RepCompNumber$ denotes the number of replaced components, and $delCompNumber$ refers to the number of removed components. $IniCompNumber$ is the number of initial components, which is the number of components in the software architecture before the adaptive strategy is implemented.

The component function change rate refers to the ratio of the number of components whose function changes due to the adjustment of component parameters during the adaptation process to the total number of components. The variable component rate (VCR) metric is calculated as follows:

$$VCR=\frac{Function Variable Component Number}{Total Number of Components}$$

(9)

The connector parameter change rate, called the connector parameter change rate (CPCR), refers to the ratio of the number of connectors whose parameters are changed to the total number of connectors during the adaptation process. The CPCR value is defined as follows:

$$CPCR=\frac{Number of Connector with parameter change}{Total Number of Connectors}$$

(10)

Assigning Weights to Implementing Difficulty

An adaptive strategy may correspond to changes in many modules, connectors, and parameters. Suppose that an adaptive strategy includes the following three types of change strategies: a component structure change strategy, a component parameter change strategy, and a connector parameter change strategy. The weight of the difficulty in implementing all strategies needs to be determined. The difficulty of implementing the adaptation strategy in the specific execution process is inversely proportional to the cost required by the system to implement the strategy. Here, we express weight values ranging from 0 to 1. The higher the weight is, the easier it is to implement; that is, the lower the cost is, the higher the weight is, and vice versa.

After Step 3, we can intuitively count the architectural components and their affected components that need to be changed under component structure changes, component parameter changes, or connector parameter changes. The specific weight assignment can be provided via expert experience based on the component diagram.

Generally, an adaptive architecture must be able to support at least one type of change strategy; then, if, and only if, the number of change strategies that an architecture can support is 1 can the difficulty of implementing the strategy be ignored, i.e., in the above case, the weight of the difficulty of implementing the strategy is 1.

However, in more cases, an architecture can support multiple change strategies, and these strategies can be of the same type or of different types. For example, when the number of service requests of an adaptive website continues to increase, a corresponding adaptive strategy will be activated to enhance the website’s processing capacity. Some video rendering rates can be reduced from 1280 P to 720 P. Therefore, it is necessary to consider the ease of implementing adaptive strategies when evaluating the adaptability of a site’s architecture.

Determine the Impact Degree

The degree of impact of changes on the architecture is determined by the scope of the impact, the importance of the affected elements, and the relationship between the affected components and the changed components. The overall impact degree ranges from 0 to 1, expressed in AED (Architecture Effected Degree), which is calculated as follows:

$$AED=\frac{{\displaystyle \sum _{r=1}^{N}CI{D}_r{\lambda }_r}}{N}$$

(11)

where N represents the number of components in the impact domain of the change, $CI{D}_r$ represents the importance of the rth component in the impact domain of the architecture change, and ${\lambda }_r$ represents the coefficient between the rth component and the changed architectural component.

The change domain of the software architecture refers to the set of components and connectors that change under the operation of the adaptive strategy. The impact domain of the software architecture refers to the set of components that have a direct interaction with the change domain and are still in an active state after the architecture is changed, as denoted as $D_{effected}=\left\{C_1,\dots ,C_h\right\}$, where $D_{effected}$ represents the impact domain of the software architecture, $C_1,\dots ,C_h$ refers to the components that are still active after the architecture is changed, and h is the number of components.

The components in the impact domain can be divided into three categories, where the first category includes the components affected by the operations of component addition, deletion, and replacement under the component structure change strategy, as shown in Figure 12, Figure 13 and Figure 14. The second refers to the components affected by the change in the component parameter, as shown in Figure 15. In Figure 12, Figure 13 and Figure 15, Component 2 is changed under the drive of the adaptive strategy and is used as the change domain, and Component 1 is still active after the change, belonging to the change impact domain. In Figure 14, the replacement operation is regarded as a special component addition and deletion operation, Component 3 is regarded as a component in the change domain, and Component 1 is regarded as a component in the change impact domain. In the third category, the components are affected by the change in the message invocation and transmission mode under the operation of the connector parameter change strategy. As shown in Figure 16, Component 1 is the component that initiates the call, which belongs to the change domain component, and Component 2 is the called component, which belongs to the change impact domain component.

Component importance refers to the importance of a component in the change impact domain for the overall software architecture. The component importance can be determined by the actual function of the component. In this step, the importance level of a component is given according to the importance level of the functions implemented by this component, as shown in

Table 3. Assignment values of component importance.

Importance of Component Function	Importance of Component	Value
Core functions	Very important	0.9
Fundamental functions	Generally important	0.7
Secondary functions	Not so important	0.5

.

The interrelationship between different domain components refers to the relationship between the change domain component and the change impact domain component, which includes dependency and aggregation. Dependency refers to two independent components, one of which depends on the services provided by the other. Aggregation refers to the fact that multiple independent components can work together to form a “bigger component”. Notably, the aggregation relationship is different from the compositional relationship. Although these two relationships are the conceptions of the whole and the part in the compositional relationship, when the local elements are deleted, the compositional relationship also ceases to exist. The aggregation relationship emphasizes that the whole can contain various elements of the part, or it cannot contain a certain element of the part.

After the interrelationships between components in different domains are clarified, the importance of these interrelationships can be judged. To illustrate the closeness of different relationships, we provide the concept of intercomponent relationship coefficients. The relationship coefficient between components is a variable that reflects the strength of the relationship between components.

For the assignment of relationship coefficients between components, it can be considered that the aggregation relationship is stronger than the dependency relationship. Therefore, in this embodiment, the value of the aggregation relationship is 0.8, and the value of the dependency relationship is 0.6. In addition, we provide the following set for the relationships between components in different domains: when analyzing the impact degree of the architecture, no matter what adaptive strategies the architecture implements, it will not affect the relationships between the original components. As shown in Figure 14, Component 1 is the impact component. Although Component 2 performs the deletion operation, the relationship between Component 1 and Component 2 before the deletion operation is still used when calculating the impact degree of Component 1.

Overall Adaptability Calculation

The overall adaptability of the software architecture is calculated by (7), according to which whether the adaptive strategy is feasible can be judged. The adaptability is a value in the interval [0, 1]; the higher the value is, the better the self-adaptive ability of the architecture, which is shown in

Table 4. Correspondence between adaptability values and levels.

No.	Adaptability Values	Adaptability of the Architecture	Adaptability Levels
1	0	no ability to adapt	None
2	(0, 0.3]	Poor	Level 1
3	(0.3, 0.6]	average	Level 2
4	(0.6, 1]	Good	Level 3

:

When the metric of adaptability falls within the interval (0, 0.3], it can be considered that its adaptability is poor, and its adaptation level belongs to Level 1, so the adaptability of the architecture is also poor.

When the metric of adaptability falls within the interval (0.3, 0.6], the adaptability is considered to be general, and the adaptability level is two, such as the specific adaptive strategies or limitations of design methods (modules are not independent enough, loose coupling is not fully considered, etc.).

When the metric of adaptability falls within the interval (0.6, 1], the adaptability is good, so the specific design method is adopted to a certain extent.

Then, the obtained adaptability value can be returned to the designer, and the designer can make a qualitative judgment or suggestion on the design options and then apply it to the specific scheme design or make further adjustments to the scheme.

4. Case Study

4.1. Experimental Setup

Here, we adopted a “de facto” standard case study from the self-adaptive community (https://www.hpi.uni-potsdam.de/giese/public/selfadapt/ (accessed on 2 April 2022)), znn.com [37], to demonstrate the effectiveness of our approach. Znn.com is a typical infrastructure for a news website and has a hierarchical architecture with a set of web servers that provide text and graphic content from back-end databases to clients through a front-end presentation logic. In addition, it uses a load balancer to reroute requests from clients to server pools. The number of active servers will depend on the selected adaptation required to achieve the goals of the system. It is important to emphasize that znn.com is an actual platform running in a real server using a standard Apache distribution and is not a simulation model. Moreover, while presenting news to users, znn.com is also desirable for meeting other users’ goals, such as performance, reliability, security, and cost.

The architecture of znn.com is depicted in Figure 17, and the main functions of each component are shown in

Table 5. Architectural components and functions of znn.com.

No.	Components	Functions
1	Client data receiving/sending component	Receiving and sending user’s input data, such as a request for certain news content
2	News content presentation component	Serving news content to users
3	Network transmission component	Responsible for communications throughout the website
4	Web service component 1, 2, …k	Responsible for serving news
5	Load balancing component	Responsible for server scheduling

.

4.2. Experimental Procedure

To evaluate the software architecture adaptability of znn.com, we discuss each step of our approach as follows:

Step 1: We determine each adaptation strategy type according to its operation type.

The adaptation strategies can be elicited from the software’s design documents and requirement specifications, which include the following main business goals: users can see the news after the client clicks to perform the corresponding action, and the user can comment on the news. Under the above business concerns, the following subobjectives can be analyzed as follows:

(1)

Provide news content to clients with different requested presentation formats, such as textual and graphical formats.

(2)

Provide news content to clients within a reasonable response time.

(3)

Keep costs below a reasonable budget.

Based on these business goals and subgoals, the designer gives two self-adaptation demands for znn.com as follows:

(1)

As the number of visits increases, the system’s ability to process access requests increases.

(2)

When the number of visits decreases, the system’s ability to process access requests decreases.

To implement the above self-adaptations, the designers proposed the following adaptation strategies shown in

Table 6. Adaptation strategies and types of znn.com.

No.	Adaptation Strategies	Types
1	When the number of visits increases, add the number of web servers, so that the response time can be reduced to a normal state.	Component structure change
2	When the number of visits increases, switch the news contents-presenting format from multimedia to text only, so that the response time can be reduced to a normal state.	Component parameter change
3	When the number of visits increases, replace the original web server ID by another server with stronger processing power, so that the response time can be reduced to a normal state.	Component structure change
4	When the number of visits decreases, reduce the number of web servers to lower overall costs.	Component structure change
5	When the number of visits increases, change the original TCP protocol to UDP protocol.	Connector parameter change

, which show the changes included in the strategies and the types of strategies classified according to the type of operation.

For simplicity, we assume that the number of web servers before adaptation is 1 and that the number of web servers added or removed by the component structure change strategy is also 1.

Step 2: We measure the degree of change in the architectural elements, and the measurement results are shown in

Table 7. Degree of change in the architectural elements of znn.com.

No.	Strategy Types	Metrics for Degree of Change
1	Component structure change	1/6
2	Component parameter change	1/5
3	Component structure change	1/5
4	Component structure change	1/5
5	Connector parameter change	2/4

.

Step 3: We model the architectural changes made to the znn.com software.

First, we model the above five strategies via our proposed e-UML component diagram.

Strategy 1: When the number of visits increases, one web server is added so that the response time can be reduced to a normal state, as shown in Figure 18.

Strategy 2: When the number of visits increases, the news content presentation format is switched from multimedia to text only so that the response time can be reduced to a normal state, as shown in Figure 19.

Strategy 3: When the number of visits increases, the original web server is replaced by another server with stronger processing power so that the response time can be reduced to a normal state, as shown in Figure 20.

Strategy 4: When the number of visits decreases, reduce one web server to lower the overall costs, as shown in Figure 21.

Strategy 5: When the user’s access amount increases, the original TCP protocol is changed to the UDP protocol, as shown in Figure 22.

Step 4: Assign difficulty weights to the strategy implementation.

The difficulty of implementation is inversely proportional to the cost required by the system to implement the strategy. The higher the weight is, the easier it is to implement; that is, the smaller the cost is, the greater the weight. Then, the required costs from high to low are as follows: Strategy 1, 3, 2, 4, and 5. The assignments are shown in

Table 8. Difficulty weight assignment of the znn.com strategy implementation.

No.	Strategy Type	Assignment of Difficulty Weight for Strategy Implementation
1	Component structure change	0.6
2	Component parameter change	0.8
3	Component structure change	0.6
4	Component structure change	0.9
5	Connector parameter change	0.9

.

Step 5: Determine the impact degree of the change.

The impact components of znn.com and the coefficients between the components can be identified after the implementation of the five strategies, which are shown in

Table 9. Impact components of znn.com and the corresponding coefficients.

No.	Impact Components and Their Importance	Relationship between Components and Coefficients
1	Load balancing component, 0.9	Aggregation, 0.8
2	Load balancing component, 0.9	Dependency, 0.6
3	Load balancing component, 0.9	Dependency, 0.6
4	Load balancing component, 0.9	Aggregation, 0.8
5	Load balancing component, 0.9	Dependency, 0.6
6	Web service component, 0.9	Dependency, 0.6

.

Step 6: Calculate the overall adaptability.

The overall adaptability of znn.com can be calculated according to Equations (4) to (7), and the variables involved can be obtained from Table 7 to Table 9. Finally, through calculation, we obtain AA znn.com = 0.854. Therefore, it can be inferred that the current software architecture has good adaptability.

5. Threats to Validity

Here, we follow Runeson and Höst [38], where the following four kinds of threats to validity are presented for discussion: external, internal, conclusion, and construct.

External validity. The threat to external validity for this study refers to the generalization of the findings on other software systems. In this paper, the znn.com software is used as an example application, which has been widely used in previous studies to discuss architectural adaptability and adaptive metrics [37,39]. However, the truth is that we still cannot say that we can achieve the same experimental conclusions using other software. In order to mitigate this threat, it is suggested that the method should be applied to more software objects.

Internal Validity. The threat to the internal validity mainly refers to the implementation of the subjective scoring methodology. Although we have carefully considered the factors that need to be taken into account in scoring, it is not possible to avoid biases that do not include our subjectivity. In order to ensure the reliability of our research, we have disclosed the principles and details of the scoring in the article. To reduce this threat, two authors were independently assigned to perform the experiment and achieve the experimental results. Though we have double checked our experiments, some errors maybe still exist.

Conclusion validity. This approach relies on human capabilities in the analysis step, such as the allocation of costs, the importance level of impact, etc., which poses a threat to the validity of the final results of using the method. This may be because it depends on the experience of the designer/architect and therefore lacks the support of information or expertise. To mitigate this risk, we sought to have the architect perform a practical evaluation in an industrial setting in order to provide more feedback from an independent source.

Construct validity. Although we have fully analyzed the impact of different adaptation strategies on the composition of the architecture, we cannot guarantee that we have fully considered all of the impacts. This could be a threat to the validity of our research.

6. Conclusions and Future Work

The purpose of this paper was to develop metrics to assess software architecture adaptability from the perspective of various strategies and to provide a comprehensive evaluation approach that considers both the positive and negative effects of self-adaptation on adaptability. Several factors were considered in determining the influence of adaptation, including the number and types of strategies employed, the cost of performing adaptations, and the degree of changes made to the architectural elements. With this approach, software architects can evaluate the adaptability of software architecture and modify architecture designs as necessary based on the evaluation results. Our approach encompasses several contributions, which can be summarized as follows:

• We have refined adaptive strategies based on operation type and further provided a calculation method to determine architecture adaptability for each strategy type. Our approach considers various factors, such as structure and parameter adjustments.
• We have provided an e-UML component diagram to model software architectural changes under different types of strategies. This diagram intuitively reflects the dynamic changes in the component structure and parameters for components or connectors driven by the strategies, and also supports the determination of the change domain and change impact domain of the software architecture. Additionally, our approach calculates the importance of components and the coefficient between components to aid in determining the significance of the changes made.
• We conducted an experiment on the znn.com software to validate the practical feasibility of our proposed method.

However, our study has the following limitations:

• The proposed approach has only been applied to one case study. Future work could involve the application of different case studies to demonstrate its broader usability.
• Our metrics are still limited. An extension of this subset of metrics could include more standard software engineering metrics for nonfunctional properties.
• The overhead of the proposal should be evaluated.

Future work should address the limitations of our approach to enhance its effectiveness. Specifically, additional case studies should be conducted to validate the usability of the proposed approach across multiple software systems. Comparative studies should be conducted to effectively compare the indicators proposed by this technology with those proposed by other existing technologies, along with other adaptive evaluation methods. Furthermore, our metrics could be extended to include traditional software engineering metrics for nonfunctional properties to provide a more comprehensive evaluation of software architecture adaptability.