The Trustworthiness Measurement Model of Component Based on Defects

. In modern software engineering, the component-based development approach has become one of the important trends in software development technology. Te trustworthiness of components plays a vital role in developing component-based trustworthy software. If there exist defects in components, then the trustworthiness of the component will be reduced, and the trustworthiness of the software system will be infuenced. In this case, it is necessary to measure the trustworthiness of the component in terms of the defect. In this paper, a trustworthiness measurement model of components will be proposed based on defects. Firstly, the defect types are formalized according to the component specifcation. Secondly, the weight allocation method of defect types is designed based on the correlation between defect types and experts’ evaluation. Te value of the trustworthiness attribute is estimated by using the risk value of the defect and the weight of the defect type. Furthermore, the trustworthiness measurement model of the component is proposed, the corresponding algorithm is designed, and some algebra properties are proved. Finally, a case study is used to illustrate the application of the model.


Introduction
As software grows in complexity with many subsystems and components, measuring software quality in multiple dimensions is a challenging task [1]. Te concept of trustworthiness appeared in software engineering in the 1990s, which was proposed and distinguished from reliability by Laprie [2]. As a comprehensive concept, software trustworthiness means that the software system operates according to the user's operational requirements [3].
Te study of software trustworthiness mainly includes the evaluation and measurement of software trustworthiness, as well as the requirement analysis of trustworthy software, the assurance methods, techniques of development [4], and so on. As one of the core issues of software trustworthiness, software trustworthiness measurement is a quantitative evaluation of software trustworthiness, which can provide a quantitative evaluation basis for software design and development [5]. Software trustworthiness, as a complex and comprehensive concept, involves many quality attributes, including correctness, privacy, reliability, security, and so on. Stephen et al. proposed that software trustworthiness can be described by attributes [6], and some remarkable results about software trustworthiness have been achieved by scholars from attributes [7][8][9][10]. Software trustworthiness can also be measured based on trustworthy evidence. For example, these models in [11][12][13] efectively measured software trustworthiness through evidence. Based on the software life cycle process of service use, development, deployment, and operation process, Cerbo et al. collected the credibility evidence at diferent stages and proposed diferent development methodologies [14]. Tao et al. constructed the software trustworthiness measure from the source codes view based on the extensive structure in the measurement theory, presented four desirable properties of the measures from the standpoint of the module, and carried out theoretical validation for the developed measure by the use of axiomatic approaches [15]. Wang et al. developed a trustworthiness evidence set to support the hierarchical evaluation, and a quantitative model of software development process trustworthiness was proposed for the frst time, which can efectively support the objectivity and comprehensiveness of software process credibility evaluation [16]. Due to the increase in software size, the volume of software fles and data has increased dramatically, which makes collecting positive data difcult. Terefore, the researchers started to collect and analyze the data from the perspective of defects to measure software trustworthiness laterally. For example, Li and Chen mapped the defect evidence to trustworthy attributes and proposed a trustworthiness measurement model by combining the complexity of program slicing [17]. Li et al. evaluated and predicted trustworthy attributes in software trustworthiness from the perspective of software defect prediction [18]. Te authors of [19] established a trustworthy evidence specifcation of aerospace model software, which distinguished between critical, positive evidence, and negative evidence, and proposed a trustworthy measurement model and a trustworthy grading model for aerospace software based on source code trustworthy evidence. As an efective way to improve software productivity and quality, component-based software development has become one of the research hotspots in the feld of software [20,21]. Because the development method of component-based software is diferent from the classical software, which emphasizes the reuse of components, it is necessary to study the trustworthiness of component-based software [22]. Tere exist many research results for component-based software. For example, Wang et al. proposed a component-based trustworthiness measurement model based on component relationships. Te logical relationships among components were analyzed, and the corresponding computational model was established to calculate the software trustworthiness through the trustworthy attributes of the components [23]. Wang et al. rationalized the trustworthiness of each component to optimize the software trustworthiness [24].
However, components are assembled to form component-based software, and the trustworthiness of individual component produces a vital impact on the trustworthiness of the software. Terefore, the trustworthiness of components should be researched to achieve the trustworthiness of the whole software. Te research on component trustworthiness has become an important branch of trustworthiness research. For example, Dimriet al. proposed a path-based trustworthiness estimation method according to the usage coefcient of components [25]. Based on the performance specifcation, Wang and Chen gave two kinds of matching, Boolean matching and quantitative matching, and presented a performance-based component matching method to study component trustworthiness [26]. Meyer established fve classifcations called ABCDE, which can be used to evaluate the components [27]. In the reference [28], a trustworthiness model based on components is proposed, and by evaluating the associated trustworthiness model, the method can predict the trustworthiness of component-based software. Mohammad and Alagar proposed an architecture description language TADL for trustworthy component-based software systems, and a formal approach for the development of trustworthy component software systems has been presented in [29].
Considering the subjective factors of users, Zhou et al. combined the initial trustworthiness of components with the user feedback to assess the fnal trustworthiness of components [30].
However, as the size of the component increases, it becomes more and more difcult to collect trustworthy evidence. Terefore, many researchers have started to collect untrustworthy evidence to study component trustworthiness. Te defect is an important part of untrustworthy evidence. For component-based software, if there exists a defect in the component, then the trustworthiness of the component will be decreased, and the trustworthiness of the software will be afected. So, it is key to research the trustworthiness of components based on the defect. In this paper, a formal description of the defect types of components will be proposed, and the trustworthiness measurement model of components will be established based on defects.
Tis paper is organized as follows: Section 2 introduces the fuzzy analytical hierarchy process (FAHP) method and the Pearson correlation coefcient (PPCs) method that will be used in this paper. Section 3 gives the formalization description of defect types. Section 4 presents the trustworthiness measurement model of components based on defects in detail. In Section 5, the computation of the model is illustrated with a case study. Section 6 shows the conclusion.

Preliminaries
In this section, we will review some existing methods that will be used in this paper.

FAHP Method.
Te weight often is used to describe the importance of some elements, and there exists the weight of some elements during some models [22,24]. It is necessary to fnd a method to obtain the weight of elements in the model. Te weight usually comes from the expert's experience and cognition. However, there exist some uncertainty and ambiguity in experts' evaluations. To solve this problem, the fuzzy analytical hierarchy process (FAHP) method is used to allocate weights. Because the FAHP method is more conducive to solving the fuzzy data that is difcult to quantify, it can reduce the data errors caused by the uncertainty and ambiguity in the expert's evaluation and make the evaluation more practical and accurate. Te calculation process of the FAHP method is shown as follows, and for the detailed content, we can refer to [31].
Generally, the triangular fuzzy number is defned as N � (l, m, u), where l ≤ m ≤ u. Let U be the domain. If u N (x): U ⟶ [0, 1] exists, then u N (x) is the degree of afliation of x ∈ N. Te values of l, u determine the degree of fuzziness, and the larger u − l is, the greater the degree of fuzziness.

2
Mathematical Problems in Engineering Te triangular fuzzy numbers N 1 (l 1 , m 1 , u 1 ), N 2 (l 2 , m 2 , u 2 ) satisfy the following rules: Suppose that there are n attributes. Let h ij � (l ij , m ij , u ij ) be the relative importance of attribute i to attribute, where Referring to the [1,9] evaluation scale method proposed in the FAHP method [31], the evaluation standards of the triangular fuzzy numbers are given in Table 1. Experts compare the importance of trustworthy attributes two-by-two through their experience and knowledge and give the value of h ij .
Step 1. Suppose that there are n elements that need to allocate the weight. Experts compare the importance of the n elements by using triangular fuzzy numbers and construct the fuzzy judgment matrix H � (h ij ) n×n , where h ij is the relative importance of ith element and jth element, h ij � (l ij , m ij , u ij ), where l is the lower bound of experts' evaluation, u is the upper bound of experts' evaluation, and m is the evaluation coefcient favored by experts. h ji � (h ij ) − 1 � (1/u ij , 1/m ij , 1/l ij ), i ≠ j, i, j � 1, . . . 9. And the value of h ij takes a value between 1-9 and it's reciprocal.
Step 3. Te subjective weight w � (w S 1 , . . . , w S n ) is obtained by defuzzifying the fuzzy weight.

Correlation.
Tere is a correlation among diferent elements, and it is necessary to master the correlation among these elements to assign weights reasonably. Te Pearson correlation coefcient (PPCs) is used to describe the closeness of the relationship between vector quantities, and samples are used to infer the correlation of vector quantity in the domain. If the correlation of elements is higher and the confict quantity is smaller, the degree of data redundancy is larger, and the amount of information is smaller, so the weight allocation should be reduced [32]. Tere are n vector quantities or elements which need to research for some domain, and the samples are obtained through testing m times, denoted as x i � (x i1 , x i2 , . . . x in ), where i � 1 . . . m. Te calculation process is described as follows, and for the detailed content, we can refer to [32].
Step 1. Calculate the standard deviation for each vector quantity. D j is the standard deviation of the jth vector quantity, and x j is the average of the jth vector quantity, where j � 1, 2, . . . , n.
Step 2. Calculate the correlation coefcient between vector quantities, and r ij is the correlation coefcient between ith vector quantity and jth vector quantity.
Step 3. Te confict quantity of vector quantity is characterized by the correlation coefcient, and R j is the confict quantity of jth vector quantity.

The Formal Model of Defect Type
To overcome the ambiguity of natural languages, formal descriptions have become an inevitable trend in software system development as the size of software systems and the complexity of the code increase. Reference [29] states that a formal description of the software can facilitate development and ditto for components. Component-based software engineering ofers many advantages for software development, including reusability, ease of management, and reduced development time, efort, and cost. Software developers divide the software into multiple components, and diferent components perform diferent functions to achieve the users' requirements. Tey manage components separately to improve management efciency. To improve the efciency of component reuse, components are described formally so that developers can obtain detailed information about the components. Te formal description of components accurately describes the essential characteristics of components, including the structure and behavior of components, standards, and so on. Te authors in [33] presented the specifcation of the component as follows. For a detailed defnition of component type, we can refer to [33]. (1) Σ is a set of events. An event in Σ denotes either a stimulus, a request for service, or a response and service provision, but not both. (2) Π is a set of interfaces. Interfaces are access points to the services provided and requested by components. (3) σ: Π ⟶ PΣ is a function that associates events to interfaces such that ∀π 1 , π 2 ∈ Π, σ(π 1 ) ∩ σ(π 2 ) � ∅. (4) Λ is a set of data parameters, which stores the different data parameters. (5) ξ: Σ ⟶ P: is a function that associates each service request or provision with a set of data parameters. Te formalization description shows detailed information about the component including the event, interfaced, attributes, and contract. Tis information comes from the user's requirements. If the developed component satisfes the specifcation, it satisfes the users' requirements and operates as expected, and to a certain extent, the component is considered trustworthy. But, if the developed component doesn't satisfy the specifcation, that means there exist some elements which are not consistent with the specifcation, such as event or interface type and so on. Tese inconsistent elements can lead to defects happened. When the component is tested, these inconsistent elements can be found. So, we can classify the defect type according to the specifcation.

Te Formalization of Defect Types.
Te defnition of defect data has been given in many references, such as [17][18][19], and the defect data have been classifed into diferent classes. But there is no unifed standard to classify the defect data. Since the reason for the occurred defect is that the implement cannot satisfy the specifcation, so we can distinguish the defect from the specifcation view and produce unifed criteria to diferentiate the defect data. Because there are 9 elements during the specifcation of components, we can classify the defect type into 9 types. Te defect types of the component are summarized, and some defect description information is given, as shown in Table 2. Table 2 shows the description of every defect type. To distinguish diferent defect types, we use a defect identifer to indicate each defect type. However, it is not enough to describe the defect type. If there exists some defect, the trustworthiness of the component will be infuenced. Te impact can be decomposed into the impact on one or more trustworthy attributes [15]. Diferent defect types afect diferent trustworthy attributes, so it is necessary to list the attributes afected by the defect type in a set. Te defect data are collected during testing, and valuable defect data are obtained by removing redundant data through data-processing methods, and these data are classifed into each defect type and recorded in a set. Each piece of defect data causes diferent negative impacts on component trustworthiness, and this impact can be quantifed with risk value. Subsequently, to quantify the degree of infuence of each piece of defect data on the components, a risk value is assigned to each piece of defect data. To facilitate later calculations, we formalize the defnition of defect type as follows.
Defnition 2 (Defect type). For any defect type identifer L ∈ Σ, Π, σ, Λ, ξ, Ξ, A, C, T { }, the defect type DT L can be defned as a tuple DT L � (P L , N L , V L , w L ), which includes the set of trustworthy attributes, the set of defect data, the set of risk values, and the weight of this defect type for L, such that (1) P L is the set of trustworthy attributes for L, which includes the trustworthy attributes afected by L. Let S C stores all attributes related to the component's trustworthiness, and then, P L ⊆ S C , where C expresses the component. (2) N L is the set of all defect data for L, which stores all defect data whose defect type is L. If there is no defect data for L, then N L � ∅. For any z ∈ N L , there exists a risk value v z ∈ 1 . . . (1/7, 1/6, 1/5) Te former is more strongly important than the latter (6,7,8) (1/8, 1/7, 1/6) Between strongly important and extremely important (7,8,9) (1/9, 1/8, 1/7) Te former is extremely more important than the latter (8,9,9) (1/9, 1/9, 1/8) value of the defect data is larger, then the greater the negative impact of the occurrence of the defect on the component's trustworthiness. (4) w L is the weight of this defect type for L, which expresses the importance of this defect type during the trustworthiness of the component.
From this defnition, we can see that when a defect happened, we can collect the valuable defect data and classify these data according to the defect type identifer, and the set of defect data for the defect type identifer can be obtained. Ten, according to the experience of the specialist and developer, the set of trustworthy attributes and the set of risk values for the defect data can be achieved. Since there exists a diferent infuence of the defect type on the trustworthiness of the component, so the weight of the defect type should be given. Next, we will use this information to estimate the trustworthiness of this component.

The Trustworthiness Measurement Model of Component
In the literature, there are a large number of diferent component defnitions. However, only a few of them have been considered as component models in a taxonomy of software component models, such as SOFA 2.0, Fractal, and Koala [34][35][36][37]. Tese component models provide a wide variety of component defnitions and contributions to the advancement of component-based development. Reference [29] provided an overview of these component models and analyzed their relative merits and then proposed a new model. Based on the component model proposed in [29], we will propose the trustworthiness measurement model of the component as follows.
If the developed component fully satisfes the specifcation of the component, then the component meets the user's needs and expectations at that point, and the component is considered trustworthy. However, in the development process, the component cannot be developed exactly according to the specifcation due to investment, time, and environmental constraints. Terefore, to a certain extent, the component does not fully satisfy the specifcation and has certain defects, so it is necessary to evaluate to what extent the component satisfes the specifcation and establish a trustworthiness measurement model. For the trustworthiness of components, it can be portrayed by values of multiple attributes or by analyzing defect data. Tere are many research results from the attributes to establish the trustworthiness model. However, the defect is a better indicator refecting the trustworthiness of the component. In this section, a trustworthiness measurement model of components will be proposed based on defects. Reasonable weight allocation will produce a direct infuence on the component trustworthiness measurement model. Usually, the weight is given by the experts' subjective evaluation of defect types. But, from the specifcation of the component and the defnition of defect type, we can see that there exists a correlation among diferent defect types, such as the interface type being related to the event type. Terefore, it is necessary to consider the correlation among the defect types when deciding the importance of the defect type.

Te Combination
Firstly, the fuzzy analytic hierarchy process (FAHP) method is used to decide the subjective weights of defect types. According to expert experience, the diferent expert provides their evaluation of the diferent defect types. Ten, according to the steps that are introduced in Subsection 2.1, we can obtain the subjective weights of the 9 defect types, written as w S i , i � 1, 2, . . . , 9. Secondly, considering the interaction among diferent defect types, the correlation among defect types is calculated through the PCCs in Subsection 2.2. Suppose that there are m times tests for the component, then the data that can produce the defect can be obtained for every test. Ten, we can classify these data into 9 diferent classes according to the defect types, denoted as According to the formulas (5)-(7), the confict quantity of the defect type R j , j � 1, 2, . . . , 9 will be obtained.
Finally, the subjective weight and the correlation coeffcient are combined to obtain the combined weight of the defect type, and the combined weight is calculated by performing weight normalization.
During the combination weight, we can see that if the expert evaluation for some defect type is higher, then the Mathematical Problems in Engineering 5 weight of this defect type is larger. And if the confict quantity of the defect type is bigger, then there exists a high correlation to other defect types; therefore, the weight of this defect type is larger, which also shows that this defect type can have an important efect on the trustworthiness of the component.

Te Trustworthiness Model of Component Based on
Defects. Te trustworthiness of components is an important criterion to guarantee the trustworthiness of componentbased software. If the defect is found when the component is tested, then the trustworthiness of the component will be decreased. At the same time, some defects can lead to the related attribute value being reduced, which also produces the trustworthiness of the component declining. Terefore, in this section, we will try to propose the trustworthiness of components according to the defect and the attributes that are related to the defect.

Te Measurement Model of Trustworthiness for
Component. Firstly, we all know that defective data are not good for the software. If there is a defect in the software, then there exists an unexpected risk for the software, such as the software doesn't run and so on. So, for diferent defect types, we can use the defect value of the defect type to express the risk, the defnition is shown as follows: Defnition 3 (Defect value of defect type). Suppose that L is an identity of defect type, and N L is the set of all defect data for L. Te defect value of L, denoted as DVDT L { }, is defned as the sum of the risk value of all defect data in N L : where z ∈ N L is a piece of defect data for L, and v z ∈ 1, 2, . . . 10 { } is the risk value for z. If a defect has a high value of risk, the greater the negative impact on component trustworthiness when the defect occurs.
Secondly, from Defnition 2, we know that every defect type is related to some attributes. In other words, some attributes can be afected by the diferent defect types. If the defect has a high-risk value, then it may lead to the software which cannot satisfy some attributes. Te larger the defect value of the defect type is, the greater the impact on the trustworthy attributes. Tat means when a defect happened, there exists some risk to make the attribute of trustworthiness which cannot be satisfed. Terefore, we propose the defnition of the defect value of trustworthiness attribute to express the risk.
Defnition 4 (Defect value of trustworthy attribute). Suppose that there is a trustworthy attribute p, the set of all defect types that are associated with p is L p � L p ∈ P L , and the defect value of the attribute p, written as DVTA p , is defned as follows: Defnition 4 shows that there exist some risks that make the system which cannot satisfy the attribute. Because the defect data come from the multiple-time test, and the trustworthy attribute value is negatively correlated with its defect value, so the attribute value can be evaluated through the defect data and the risk value.
Defnition 5 (Attribute value). Suppose that there is a trustworthy attribute p ∈ S C , where S C stores all attributes related to the component C. Te attribute value of p, denoted as y p , is calculated by the following formula: where f ∈ R + is the control parameter.
Te value of f is usually dependent on the typedef structure number of code, the larger the size of the component, the more typedef structures of code, the greater the value of f, and the smaller f is otherwise. In terms of the impact of defects on attributes, the attribute value model should satisfy the following criteria:

Theorem 1
(1) (y p /zDVTA p ) ≤ 0 that means the defect value of a trustworthy attribute is larger, and the value of the trustworthy attribute is lower. Tat also shows the value of the trustworthy attribute which is negatively correlated with the defect value of the trustworthy attribute. (2) 0 ≤ y p ≤ 1 that means the value range of the attribute value which is in the interval [0, 1].

Proof of Teorem 1
(1) In fact, (zy p /zDVTA p ) � (−DVTA p /f) e (− DVTA p /f) ≤ 0 (2) Since 0 ≤ e (− DVTA p /f) ≤ 1, 0 ≤ y p ≤ 1 □ Defnition 6 (Te trustworthiness of component). Suppose that there is a component C, the set of all attributes related to C is denoted as S C , and p ∈ S C is a trustworthy attribute that associates with the component. Let T C be the trustworthiness of the component C. Ten, T C can be calculated by the following formula: where α p is the weight of the trustworthy attribute p, which expresses the importance of the attribute during the trustworthiness of the component. In [10], the author showed that the trustworthiness of software should satisfy some criteria. Since the component can be treated as an independent unit to some extent, which can fnish some special functions, it is necessary to prove the trustworthiness of the component which also satisfes these criteria.

Theorem 2.
Suppose that T C represents the trustworthiness of the component C. Ten, T C satisfes the following criteria: (1) Nonnegativity: nonnegativity means that component trustworthiness is nonnegative, T C ≥ 0. (2) Proportionality: proportionality refers to each value of the attribute which should have an appropriate proportion, which means ∃c 1 , c 2 ∈ R + such that where σ pq is the substitution difculty between attribute p and attribute q.

(7) Stability: stability means that if all the values of attributes meet the users' expectations, the component trustworthiness also meets users' expectations,
Proof of Teorem 2. According to the verifcation method in [10] and the defnition of T C in this paper, it is easy to get the proof.

Te Algorithm of Trustworthiness Measurement Model of Component.
To implement the automated calculation of the measurement model, it is indispensable to design the algorithm of the model. From the above discussion, we know that the trustworthiness of a component can be achieved by trustworthy attributes. According to formula (12), the values of trustworthy attributes can be obtained by analyzing defect data. Next, we will try to design the algorithm to implement the automated computation of the trustworthiness of the component. Given the component C, we defne the set of all trustworthy attributes related to C, S C , and the importance weight of every attribute α p . After the software is tested, the defect data are collected. According to the defect type, the defect data are classifed into diferent classes N L , L ∈ Σ, Π, σ, Λ, ξ, Ξ, A, C, T, and the weight of every defect type can be achieved based on the formula (8). Because every defect data can afect some attributes, the set of attributes related to the defect type is collected. And, every defect data exist the risk for the software, so the set of the risk value of every defect data is given. Furthermore, the control parameter is defned. Ten, the calculation processes are shown as follows: (1) Based on Defnition 3 and formula (9), the defect value of every defect type is calculated by the risk value of every defect data in diferent defect types (2) According to the classifcation of defect data and the set of attributes related defect types, the set of defect types that are associated with every attribute is established (3) According to the weight of every defect type, the defect value of every attribute is determined based on the formula (10) (4) Based on the control parameter, the value of the trustworthy attribute is calculated according to the defect value of the trustworthy attribute and formula (11) (5) Te trustworthiness of component C can be obtained by the formula (12) To design the algorithm of trustworthiness of component in detail, some declarations should be given as follows: During this algorithm, S C , P L , N L , V L , w L , f, and α p are the input data, and the target data are T C . To obtain T C , some intermediate variables are necessary, such as DVTA p , L p , DVDT L . In the beginning, these variables should be initialized. Since T C is calculated by the iteration of itself, so the initial value is defned as T C � 1. For every defect type L ∈ Σ, Π, σ, Λ, ξ, Ξ, A, C, T { }, the initial value of DVDT L is 0. For every attribute p ∈ S C , DVTA p and L p are initialized as DVTA p � 0, L p � ∅. Te algorithm includes four subroutines: the frst subroutine between line 8 and 12 shows the defect value of the defect type; the second subroutine from line 13 to 19 fnds the set of defect types that are associated with the attribute; the third subroutine between line 20 and 25 computes the value of the attribute; the last subroutine from line 26 to 28 gives the trustworthiness of the component.

Time Complexity.
Tere is a loop from line 2 to 4 and from line 5 to 6, respectively. Suppose that there are n attributes considered for the component. Ten, the number of executions for the frst loop is n. For the loop between line 5 and line 7, Table 2 shows that there are 9 defect type identifers, so the number of executions is 9. And from line 8 to line 12, there is a loop nesting, the number of executions for the external loop is 9, and the number of executions for the internal loop depends on the amount of defect data. Generally, the amount of defect data is fnite, denoted as m.
Since the computation of line 10 is the basic operation that needed constant time, so the number of executions for line 8 to line 12 is 9m. Tere is also a loop nesting between line 13 and line 19. Since the maximal cardinality of the set S C is n, so the number of executions for the loop nesting is 9n. Similarly, the number of executions from line 20 to line 25 is also 9n. It is easy to know the number of executions for the last loop is n. Generally, the number of defect data m is larger than the number of attributes n. Terefore, the time complexity of this algorithm is polynomial time.
To clarify the detailed process of the algorithm, the fowchart can be shown in Figure 1.
Te authors in [17,19] also proposed the model of the trustworthiness of software from the evidence. Tey divided the evidence into positive and negative evidence. Te positive evidence cannot lead to the failure of software, which plays a role in protecting the system to some extent. Te number of positive evidence is larger, and the trustworthiness of the software is higher. But, the number of negative evidence is larger, and the trustworthiness of the software is lower. Te trustworthiness of software based on the positive evidence was calculated by the product of attributes. Te trustworthiness of software based on the negative evidence was calculated by a monotone decreasing function. Te fnal trustworthiness of the software was obtained by combining the two trustworthiness metrics. Te diferences between [17] and [19] were the method of classifying the evidences and the fnal combining model. During their models, they only showed the model from the mathematical perspective and didn't give a detailed algorithm design. Analyzing their models, the complexity of trustworthiness based on the positive evidence is polynomial time by [38]. Te efciency of calculating trustworthiness from the negative evidence is dependent on the number of negative evidence.
In our model, we only focus on the defect data which can produce the failure of the component, i.e., the negative evidence. Te main reason is to characterize the user's strict requirement specifcation for trustworthiness. Especially, for some vital systems, the failure of a software system will produce a great loss for human lives and the economy. Terefore, defect data are not allowed during these systems. If there exists some defects in the system, then the trustworthiness of the software is lower, which will lead to the system that cannot satisfy the requirement. Trough the above analysis, we know that the efciency of our model is also polynomial time, depending on the number of defect data.
Terefore, if we only consider the amount of defect data, then the complexity in our model is the same as [17,19]. But, in [17,19], they have to spend some time calculating the trustworthiness based on the positive evidence. Terefore, our model is prior to the method in [19] to some extent.
Tough the efciency of our method is the same as [17,19] from the perspective of defect, our method not only details the defect data according to the specifcation and considers the risk value of defect type but also the relationship between defect data and attribute is researched, which can pay more attention to the detail of defect data and help the developer and tester to fnd the reason defect happened. To state the reasonability of our method, a case will be shown in the next section.

Case Study
In [19], the authors used the data from the NASA's opensource Core Flight Explosive code (https://github.com/nasa/ cFE) on GitHub. To explain our method, we also use the same data to simulate our model. In this section, the "msg" module of NASA's code will be used as the measurement object to verify the efectiveness and practicability of the trustworthiness measurement method based on the defect proposed in this paper. Te code line of this module is 1256 lines. Suppose that the trustworthiness of the module is afected by seven essential trustworthy attributes: security, correctness, reliability, privacy, antirisk, availability, and performance. Next, the calculation process of this module's trustworthiness will be introduced in detail.

Te Weight of Defect Type
Step 1. Calculate Subjective Weight. In order to obtain the importance of defect type, it is necessary to invite some software test experts to evaluate the signifcance of the above defect types and give a fuzzy judgment matrix. Te fuzzy weight of each defect type is obtained by calculating the fuzzy matrix in the following. Defuzzify the data in Table 3 to obtain subjective weight, as shown in Table 4. Te detailed process of calculation is based on the following formulas (3)-(4): 8 Mathematical Problems in Engineering Begin Input: S C , P L , N L , V L , w L for every L ∈ Σ, Π, σ, Λ, ξ, Ξ, A, C, T { }, f, α p forp ∈ S C . Output: T C .

5.1.2.
Step 2. Calculate the Confict Quantity. Te msg module is tested fve times, collecting test data, and assigning risk value to defect data, and the numbers of defect data are recorded and classifed into the defect type identifer. Subsequently, the correlation coefcient is calculated according to the defect data in Table 5. Ten, the confict quantity of defect types is obtained in Table 6 by correlation coefcient according to the following formula (7).

Step 3. Obtain the Combination of Weight.
Te subjective weight and the confict quantity are combined by formula (8). Te results are shown in Table 7.

Analysis of Defect Data.
Te defect data during every test are collected and classifed into 9 defect types. Ten, the trustworthiness of the module is measured by the defect data. For every test, the trustworthiness of the module can be obtained. Finally, the average of fve metrics is taken as the fnal trustworthiness. Next, we will take the data of test 1 as an example, the number of defect data is 20, the same as the defect data in [19], and the calculation process is detailed. Te defect data are classifed according to component specifcations. For the same defect type, the data with the same risk value are recorded in Table 8. For example, there are 5 defect data with the defect type Σ, and there are two data on the same risk value 3. Te corresponding trustworthy attributes for every defect type identifer are also listed. Te information can be concluded as follows.

Step 1. Calculate the Defect Value of the Defect Type.
Calculate DVDT L for each defect type L. Taking the defect type with the identifer Σ as an example, DVDT Σ is equal to the sum of the product of the defect risk values and numbers of defects according to formula (9), DVDT Σ � 3 × 2 + 1 × 3 � 9. Operations are repeated to calculate the risk value of each defect type as shown in Table 9.

Step 2. Calculate the Defect Value of the Attribute.
Te calculation process is illustrated by taking "correctness" as an example. Correctness is afected by the two defect types: σ and ξ. Te defect value of correctness is determined by the DVDT σ , DVDT ξ and the weight of the corresponding defect type. By formula (10), DVTA correctness � 4 × 0.06 + 4 × 0.05 � 0.44. By using the same calculation, the defect values of the other trustworthy attributes are shown in Table 10.

Step 3. Calculate the Values of Trustworthy Attributes.
Trough analyzing the module code, we know that there are 26 typedef structure defnitions during the code. Tus, we defne the control parameter f � 26. Te value of correctness is calculated according to formula (11), i.e., Te above calculations are performed to obtain the values of the other trustworthy attributes. And the weights of the trustworthy attributes can be allocated according to the FAHP method, refer to Table 11 for the specifc contents.
Similarly, other test results are analyzed and calculated to obtain credibility, as shown in Table 12. Five tests are subsequently calculated and averaged to obtain a fnal trustworthiness T msg � 0.955.

Comparison.
In [19], the authors presented a method to measure the trustworthiness of software by analyzing the source code-oriented aerospace software, and every defect data can be treated as negative evidence. And, the measurement model is established based on the positive evidence and defect data. In our model, the trustworthiness of the component is measured based on the defect data, and it is stricter to evaluate the trustworthiness. It is more suitable to verify the trustworthiness of some vital components. But during the real practice, we notice that there are some defective data that can lead to the same error. Tese defect data should be considered as a piece of evidence instead of several pieces of evidence. At the same time, the reasons these defect data occurred are diferent, so there are diferent types of defect data. Tese diferent types of defect data can produce diferent infuences on trustworthiness. Terefore, our method is diferent from the method in [19]. Our method considered the important degree of defect type during defect data. Tough our method is focused on the component, if we treated software as the biggest component, then our method is also suitable for the software system. Figure 2 shows the diferent results of our model, and the model in [19] used on the same collected defect data. Te orange block expresses our result, and the blue block is the result in [19]. Te comparison shows that the component trustworthiness calculated with our model is slightly lower than that calculated with the trustworthiness measurement model based on source code in [19]. Te main reason is that the model in [19] included the trustworthiness metric based on positive evidence, which can lead to the trustworthiness being higher.

Conclusions
Component is an important part during the complexity system. Te trustworthiness of component can produce the great infuence for the quality of the system. Terefore, it is necessary to measure the trustworthiness of the component accurately. Te defect data can refect the trustworthiness of the component straightly. Terefore, we established the trustworthiness model based on the defect data. To describe the reason that the defect data occurred, the formal characterization of the defect type is established based on the component specifcation. And, the relationship between defect data and the attributes is established. Te value of the attribute can be obtained by using the defect data. Finally, the trustworthiness model of the component is proposed based on the attributes and weight of attributes. Te corresponding algorithm is designed to realize the automated calculation. Te model proposed in this paper not only considers the defect's efect on trustworthiness but also classifes the defect type based on the formal specifcation of the defect type. Te complexity of the algorithm for calculating the trustworthiness of components is polynomial time, which is easy to implement automation computations. Compared with other related research, the contributions of this paper are shown as follows: (1) From the formalization view, the defect data are graded to diferentiate from diferent defect data (2) Te weight allocation method of defect types is innovated to express the importance of diferent types of defects (3) Te relationship between the defect data and the component trustworthiness attributes is established (4) Te component trustworthiness based on the defect data is measured by combining the value of attributes with the weight of attributes Te model proposed in this paper can efectively measure the trustworthiness of components from the perspective of defects, but the classifcation of defect data in our model is usually based on manual work. Tough there are many tools to fnd the defect data, it is the frst time to classify the defect data from the specifcation. On the other hand, some complex systems are developed by the component-based development process. Tere are much diferent connection structures for the component. But, our model only focuses on the components and does not consider the combination structure among components. Terefore, in future work, we will try to fnd an automated classifed tool in order to expand the scope of our model usage. At the same time, to measure the trustworthiness of the whole component-based software from the perspective of defects, we will try to construct the trustworthiness measurement model from the diferent combinations of components and the interface connection. The trustworhiness meaurement based on source code The trustworthiness measurement based on defect

Data Availability
Te data used to support the fndings of this study are included within the article.

Conflicts of Interest
Te authors declare that they have no conficts of interest.