# Source Codes Oriented Software Trustworthiness Measure Based on Validation

Authors: Hongwei Tao; Jie Zhao
Journal: Mathematical Problems in Engineering
 (2018)

---

## Abstract

Validation is critical to the success of software trustworthiness measurement. A large number of software trustworthiness measures are proposed; however, most of them are not validated from a theory perspective. Therefore, they lack theoretical foundation and will induce unnecessary cost and useless calculation. In this paper, we bring measurement theory into software trustworthiness measurement, construct a source codes oriented software trustworthiness measure based on extensive structure in the measurement theory, and validate the developed measure by use of axiomatic approaches. Compared with some software trustworthiness measures that are already presented, this measure can evaluate software trustworthiness better from a theory perspective.


---

## Body

## 1. Introduction

Because of the outstanding problems with software trustworthiness, people pay more and more attention to the research into trustworthy software. One of the core scientific problems in this research is the software trustworthiness measurement [1]. However, few research works carry out theoretical validation for their measures. It is important that the measures we use are valid. That is, measures must measure what they are supposed to measure. Theoretical validation is a required activity for using or defining measures that make sense and is a necessary step for the empirical validation of measures [2]. On the other side, many researches do not present the methods to translate the measure results back to the empirical world. Then it is difficult to use the measure results to provide guidance for the improvement of software trustworthiness. Meanwhile, most researchers in software trustworthiness measurement area do not address scale types. Scale types are very important for meaningful statistical operations. Because many empirical and numerical conditions are not covered by a certain scale type, for example, comparisons of arithmetic means are not a meaningful statistic [3, 4].There are two main approaches in theoretical validation and they are measurement theory and axiomatic approaches [5, 6]. In measurement theory, the empirical understanding of an attribute is formalized through the definition of an empirical relational system and a numerical relational system is defined to provide measure values for that attribute and relations among these values [7]. Measurement theory presents a clear definition of a measure under the assumption of a homomorphism from the empirical world into the numerical world and gives the conditions for the use of measures on certain scale levels. The major advantage of measurement theory is the representational condition, which attests that the properties of the attributes in the empirical world should be preserved by the measures in the numerical world and vice versa. Part of the empirical understanding of a software attribute may be formally defined as desirable properties of the measures for that attribute. Axiomatic approaches are used with a number of properties for theoretical validation [8, 9]. A property is a condition or a basic assumption of reality. The measure’s properties in axiomatic approaches must be seen as properties that characterize the numerical world. However, they indirectly affect the empirical world. Therefore, properties in axiomatic approaches can be used as guidelines for the definition of a measure.Software trustworthiness measures based on measurement theory and axiomatic approaches are appropriate methods to deal with problems, like theoretical validation of measures, measurement scales, the empirical interpretation of numerical results, and properties of measures. However, measurement theory and axiomatic approaches are mostly applied to measure internal attributes such as size, complexity, and cohesion or used to validate the software internal attributes measures from theory [2, 9–13]. The fundamental problem of the application of measurement theory or axiomatic approaches in software external attributes measurement is that, for many software external attributes, it is not known what the empirical relational system looks like. In order to make software trustworthiness measurement more rigorous, we used axiomatic approaches to measure software trustworthiness and presented some desirable properties of the measures for software trustworthiness in the view of trustworthy attributes [8], including monotonicity, acceleration, sensitivity, and substitutivity. In this paper, we construct a source codes oriented software trustworthiness measure based on extensive structure in the measurement theory, present four desirable properties of the measures for software trustworthiness from the standpoint of module, and carry out theoretical validation for the developed measure by use of axiomatic approaches.The rest of this paper is organized as follows. In Section2 we review some related works. We describe some basic definitions and notations from measurement theory and present extensive structure based software trustworthiness measures in Section 3. In Section 4 we introduce four desirable properties of software trustworthiness measures from the standpoint of module and validate the nonadditive software trustworthiness measure based on extensive structure established in Section 3 by use of axiomatic approaches. The measurement procedure based on the measures built in Section 3 is presented in Section 5. We make a case study in Section 6. Section 7 contains the comparative study. The conclusion and future work come in the last section.


## 2. Related Works

There are three kinds of software trustworthiness measurements: attribute-based software trustworthiness measurement, behavior-based software trustworthiness measurement, and process-based software trustworthiness measurement [14].The general framework for the attribute-based software trustworthiness measurement is as follows. The attributes that affect software trustworthiness are firstly selected. Then, measurement models are built to measure these selected attributes. Finally, models and methods are presented to measure software trustworthiness based on measurement results of the selected attributes. Typical models and methods include axiomatic approaches [8, 15–20], fuzzy comprehensive evaluation method [21, 22], rough set theory [23], Bayesian Networks [24–26], evidence theory [27, 28], weakness analysis [29], questionnaire survey and statistical analysis [30–33], and dynamic system [34–36].The software normal behavior model is firstly built under trustworthy environment in the behavior-based software trustworthiness measurement. Then, the software actual behavior is extracted based on the monitored actual operating statuses of the software at the checkpoint. Finally, the actual behavior is compared with the normal behavior to evaluate software trustworthiness. Typical comparison methods include program slicing [37, 38], data mining [39, 40], and concurrency theory [41–46].Process-based software trustworthiness measurement uses the collected data describing the behaviors and attributes of the process as evidence to measure software trustworthiness. Classic methods contain Trusted Software Methodology [47, 48], Trustworthy Process Management Framework [49, 50], and so on.


## 3. Software Trustworthiness Measure Based on Extensive Structure

We first present some basic concepts from measurement theory.Definition 1 (empirical relational system [7]).
Given an attribute, an empirical relational system is an ordered tupleERS=(E,R1,⋯,Rm,o1,⋯,on), where (1)
E denotes a nonempty set of empirical objects for which we want to measure the attribute;(2)
Ri(1≤i≤m) are ki-ary empirical relations on E capturing our intuitive knowledge on the attribute;(3)
oj(1≤j≤n) are empirical binary operations on E, i.e., oj:E×E→E.The empirical relational system is used to model our empirical understanding of the objects’ attributes that we want to measure.Definition 2 (numerical relational system [7]).
Given an attribute, a numerical relational system is an ordered tupleNRS=(V,S1,⋯,Sm,⊕1,⋯,⊕n), where (1)
V is the set of values that we use to measure the attribute;(2)
Si(1≤i≤m) denote ki-ary relations on V;(3)
⊕j(1≤j≤n) denote numerical binary operations on V, i.e., ⊕j:V×V→V.The numerical relational system is purposefully defined to mirror the empirical relational system in the realm of values. The link between the empirical relational system and the numerical relational system is made via measure.Definition 3 (measure [7]).
A functionμ:E→V is said to be a measure.However, with the exception of empirical objects, the empirical relational system also presents information about our empirical understanding of an attribute of a set of empirical objects. If this information is not considered, any function that mapsE into V is a measure according to Definition 3. In order to discard all of those measures that are at variance with our intuition, measurement theory introduces the definition of scale.Definition 4 (scale [7]).
LetERS=(E,R1,⋯,Rm,o1,⋯,on) be an empirical relational system, NRS=(V,S1,⋯,Sm,⊕1,⋯,⊕n) be a numerical relational system, and μ:E→V be a measure. The triple (ERS,NRS,μ) is a scale if and only if for all i∈{1,⋯,m},j∈{1,⋯,n} and for ∀al,⋯,ak,b,c∈E, the following holds: (1)Rial,⋯,ak=Siμal,⋯,μakandμbojc=μb⊕jμc.Extensive structure is one of the most important measurement structures. It is essential in physics and is very important in the area of software measurement too. They are not brought into software external attributes measurement and software trustworthiness measurement. The reason is that it is difficult to build the extensive structure about software external attributes or software trustworthiness. The following is the definition of extensive structure.Definition 5 (extensive structure [7]).
LetA be a nonempty set, R a binary relation on A, and ∘ a closed binary operation on A. The empirical relational system (A,R,∘) is an extensive structure if the following axioms are satisfied: (1)
Weak order:(A,R) is a weak order; i.e., it satisfies transitivity and strong completeness.(2)
Weak associativity:∀a,b,c∈A:(a∘b)∘c≈a∘(b∘c).(3)
Monotonicity:∀a,b,∈A:(a,b)∈R⇔((a∘c),(b∘c))∈R⇔((c∘a),(c∘b))∈R.(4)
Archimedean:∀a,b,c,d∈A: if (a,b)∈Rs, then for any c,d there exists a natural number n, such that ((n.a∘c),(n.b∘d))∈R.
One has(2)a≈b⇔a,b∈R∧b,a∈R,a,b∈Rs⇔a,b∈R∧b,a∉R,1a=a,n+1a=na∘a.The most practical use of measurement is the representation theorem of extensive structure.Theorem 6 (representation theorem of extensive structure [7]).
SupposeA is a nonempty set, ⪰ a binary relation on A, ∘ a closed binary operation on A, and R the set of all real numbers. Then there is a real-valued function μ:A→R satisfying (3)a⪰b⇔μa≥μbμa∘b=μa+μbif and only if (A,⪰,∘) is an extensive structure. If another function μ′ fulfills these properties, then there exists a positive real value α that (4)μ′=αμholds.In order to apply extensive structure in software trustworthiness measurement, the first step is to define an empirical relational system about software trustworthiness. Therefore, the software entity must be represented in one way or another. In this paper, we use the software abstraction presented in [12] and define software as a system. However, we modify the definition of module given in [12].Definition 7 (system [12]).
A systemS is represented as a pair (E,R), where E is the set of elements of S and R represents a binary relation on E(R⊆E×E) expressing the relationships between S’s elements.Definition 8 (module).
For a given systemS=(E,R), a module m=(Em,Rm) is a system such that (5)∀e∈Em⇒e∈E∧Rm⊆R.As an example, E can be defined as the set of code statements and R as the set of data flows from one statement to another. A module m may be a code segment or a subprogram.Given a systemS=(E,R), let MS be the set of all the modules in S. Then MS is the set that are to be measured. Suppose m1=(Em1,Rm1), m2=(Em2,Rm2)∈MS and let (6)Rm1m2=e1,e2∣e1∈Em1∧e2∈Em2∧e1,e2∈R. Then, we define the binary operation on MS as (7)m1∘Tm2=Em1⊎Em2,Rm1∪Rm2∪Rm1m2,where Em1⊎Em2 is a multiset composed of the elements in Em1 and Em2. From the definition of module, we know that m1∘Tm2∈MS.Now we need to define the empirical ordering≿T: equally or more trustworthy than. Software trustworthiness is the ability of software to satisfy user expectation with its behaviors and results. Both the software behaviors and the results are decided by the implementations of software. Then the software trustworthiness can be obtained by computing the quantification of the conformance of the implementations adopted by software with the implementations expected by users. The implementations expected by users are referenced as the properties and functions that the program elements and program unit should carry if a program is trustworthy; for example, a variable should be initialized before used [51]. Moreover, software is composed of the modules through some relations and the module is the collection of program elements. So we let ≿T be determined by the following observation criterion: If m1=(Em1,Rm1),m2=(Em2,Rm2)∈MS, then m1≿Tm2 is observed if and only if when the ratio of the number of program elements with the implementations expected by users in Em1 to the number of program elements in E is greater or equal than the ratio of the number of program elements with the implementations expected by users in Em2 to the number of program elements in E.Claim 1.
( M S , ≿ , ∘ T ) is an extensive structure.Proof.
( 1 ) Transitivity: let m1=(Em1,Rm1), m2=(Em2,Rm2),m3=(Em3,Rm3)∈MS. Suppose the ratios of the number of program elements with the implementations expected by users in Em1,Em2,Em3 to the number of program elements in E are k1,k2, and k3, respectively.
Then, from the definition of≿T, we know that m1≿Tm2 implies k1≥k2 and m2≿Tm3 implies k2≥k3. As the relation ≥ is transitive for real numbers, then it holds that k1≥k3, leading to the observation that m1≿Tm3.
( 2 ) Strong completeness: since any pair of real numbers can be compared using ≥, then strong completeness is shown by the definition of ≿T.
From(1) and (2), we can get (MS,≿) is a weak order.
( 3 ) Weak associativity: because (8)m1∘Tm2=Em1⊎Em2,Rm1∪Rm2∪Rm1m2, therefore (9)m1∘Tm2∘Tm3=Em1⊎Em2⊎Em2,Rm1∪Rm2∪Rm3∪Rm1m2∪Rm1m3∪Rm2m3∪Rm1m2m3.
Similarly, since(10)m2∘Tm3=Em2⊎Em3,Rm2∪Rm3∪Rm2m3, then (11)m1∘Tm2∘Tm3=Em1⊎Em2⊎Em2,Rm1∪Rm2∪Rm3∪Rm1m2∪Rm1m3∪Rm2m3∪Rm1m2m3. Notice that associativity is satisfied by ⊎, therefore (12)m1∘Tm2∘Tm3≈m1∘Tm2∘Tm3.(4) Monotonicity: we first prove that ∀m1=(Em1,Rm1), m2=(Em2,Rm2),m3=(Em3,Rm3)∈MS:m1≿Tm2⇒m1∘Tm3≿Tm2∘Tm3.
The number of program elements with the implementations expected by users inEm1⊎Em3(Em2⊎Em3) is the sum of the number of program elements with the implementations expected by users in Em1(Em2) and that in Em3(Em3). Because m1≿Tm2 implies the number of program elements with the implementations expected by users in Em1 is equal or more than the number of program elements with the implementations expected by users in Em2, therefore, the number of program elements with the implementations expected by users in Em1⊎Em3 is equal or more than the number of program elements with the implementations expected by users in Em2⊎Em3; then it follows that (13)m1∘Tm3≿Tm2∘Tm3.
Likewise, ifm1∘Tm3≿Tm2∘Tm3, we can deserve that m1≿Tm2.
In a similar way, we can prove that∀m1=(Em1,Rm1),m2=(Em2,Rm2),m3=(Em3,Rm3)∈MS:m1≿Tm2⇔m3∘Tm1≿Tm3∘Tm2.
(5) Archimedean: since(MS,≿T,∘T) satisfies monotonicity, then it is easy to get that Archimedean holds for (MS,≿T,∘T).
In summary,(MS,≿T,∘T) is an extensive structure.Definition 9 (an additive module trustworthiness measure based on extensive structure).
For a given software systemS=(E,R), let MS be the set of all the modules in S and R+ be the set of all positive real number. Suppose m=(Em,Rm),m1=(Em1,Rm1),m2=(Em2,Rm2)∈MS. Denote the number of program elements with the implementations expected by users in Em by #(Em)expect and the number of program elements in E by #(E). Then, the additive module trustworthiness measure based on extensive structure T1 is defined as T1:(MS,≿T,∘T)→(R+,≥,+), where (14)T1m=#Emexpect#E.According to the representation theorem of extensive structure and the definition ofT1, it is easy to obtain the following result.Claim 2.
(1)T1 assumes the extensive structure (MS,≿T,∘T).
(2) For∀m1=(Em1,Rm1),m2=(Em2,Rm2)∈MS, (15)T1m1∘Tm2=T1m1+T1m2,
i.e.,T1 is an additive homomorphism from (MS,≿T,∘T) to (R+,≥,+).Definition 10 (a nonadditive module trustworthiness measure based on extensive structure).
For a given software systemS=(E,R), let MS be the set of all the modules in S and R+ be the set of all positive real numbers. Suppose m=(Em,Rm),m1=(Em1,Rm1),m2=(Em2,Rm2)∈MS, 0<ρ<1, 0<β. Then, the nonadditive module trustworthiness measure based on extensive structure T2 is defined as T2:(MS,≿T,∘T)→(R+,≥,⊕), where (16)T2m=1βT1m1/ρT2m1⊕T2m2=T2m1ρ+T2m2ρ1/ρ.Claim 3.
(1)T2 assumes the extensive structure (MS,≿T,∘T), and for ∀m1=(Em1,Rm1),m2=(Em2,Rm2)∈MS, (17)T2m1∘Tm2=T2m1ρ+T2m2ρ1/ρ,
i.e.,T2 is a nonadditive homomorphism from (MS,≿T,∘T) to (R+,≥,⊕).
(2)T2 can be used as a ratio scale.Proof.
( 1 ) Let m1=(Em1,Rm1),m2=(Em2,Rm2),m3=(Em3,Rm3)∈MS. Because (18)T2m=1βT1m1/ρ, then (19)T1m=βT2mρ, and (20)T1m1∘Tm2=βT2m1∘Tm2ρ. From Claim 2, we know that (21)T1m1∘Tm2=T1m1+T1m2=βT2m1ρ+βT2m2ρ. Then we can get (22)T2m1∘Tm2=T2m1ρ+T2m2ρ1/ρ. Because 0<ρ<1, therefore T2 is a nonadditive measure and can be modified to the additive measure T1 by a strictly monotonic function. From the result in [18], it follows that T2 assumes the extensive structure (MS,≿T,∘T) too.
(2) Noticing that(23)αT2m1ρ+αT2m2ρ1/ρ=αT2m1ρ+T2m2ρ1/ρ=αT2m1∘Tm2, it follows that T2 can be used as a ratio scale.
To sum up, the conclusion can be verified.In the following, on the basis of the module trustworthiness measures described in Definitions9 and 10, we present an additive software trustworthiness measure based on extensive structure and a nonadditive software trustworthiness measure based on extensive structure. For a given software system S=(E,R), let M(⊆MS) be a collection of modules of S such that (24)∀e∈E∃m=Em,Rm∈Me∈Emand (25)∀mi=Emi,Rmi,mj=Emj,Rmj∈MEmi∩Emj=∅, i.e, the set of elements E of S is partitioned into the sets of elements of the modules in M. Suppose the number of the module in M is n and denote them by m1,⋯,mn separately.Definition 11 (an additive software trustworthiness measure based on extensive structure).
For a given software systemS=(E,R), an additive software trustworthiness measure based on extensive structure T′(S) is defined as (26)T′S=T1m1∘Tm2∘T⋯∘Tmn=T1m1+T1m2+⋯+T1mn.Definition 12 (a nonadditive software trustworthiness measure based on extensive structure).
For a given software systemS=(E,R), a nonadditive software trustworthiness measure based on extensive structure T(S) is defined as (27)TS=T2m1∘Tm2∘T⋯∘Tmn=T2m1ρ+T2m2ρ+…T2mnρ1/ρ.


## 4. Numerical Relational System Based on Axiomatic Approaches

There may be many nonadditive software trustworthiness measures that assume the extensive structure(MS,≿T,∘T) and can be used as a ratio scale. Now the problem is how to prove T is a proper software trustworthiness measure. Axiomatic approaches have already been used to check if the existing measures comply with a specific set of properties for the attribute that they purport to measure. We once used axiomatic approaches to measure software trustworthiness and presented some desirable properties of software trustworthiness measures from the standpoint of trustworthy attributes [8]. Consulting the properties given in [8], in this section we give four desirable properties of software trustworthiness measures in the view of module and prove that T complies with these four properties.For generality, let(28)Ty1,y2,⋯,yn=y1ρ+y2ρ+⋯+ynρ1/ρ,where(i)
0<ρ<1: a parameter related to the substitutivity between module trustworthiness(ii)
0≤yi: the module trustworthiness obtained through T2 with i=1,⋯,nThe desirable properties of software trustworthiness measures in the view of module are depicted below.(1) Monotonicity (29) T y 1 , ⋯ , y i + Δ y i , ⋯ , y n - T y 1 , ⋯ , y i , ⋯ , y n ≥ 0 , where 1≤i≤n. It means that the increment of a module trustworthiness leads to software trustworthiness increase.(2) Acceleration (30) Δ T y 1 , ⋯ , y i + Δ y i , ⋯ , y n - Δ T y 1 , ⋯ , y i , ⋯ , y n Δ y i ≤ 0 , where 1≤i≤n. It states that the increase of the module trustworthiness leads to their utilization efficiency to decrease.(3) Sensitivity (31) 0 ≤ Δ T Δ y i y i T ,  1 ≤ i ≤ n . Sensitivity is used to describe the percentage changes of software trustworthiness caused by the percentage changes of module trustworthiness. They should be positive.(4) Substitutivity (32) ∃ c 1 , c 2 ∈ R +  c 1 ≤ σ i j ≤ c 2 ,where(33)σij=Δyi/yjΔΔyi/Δyj×Δyi/Δyjyi/yj,1≤i,j≤n,i≠j.σij(1≤i,j≤n,i≠j) are used to express the difficulty of the substitution between module trustworthiness. Substitutivity implies that the module trustworthiness can substitute each other to some extent.Claim 4.
Monotonicity holds forT.Proof.
From the definition ofT, we know that T is a continuously differentiable function. By solving the partial derivatives of T with respect to yi(1≤i≤n), we can obtain (34)∂T∂yi=y1ρ+y2ρ+⋯+ynρ1/ρ-1yiρ-1. Since 0≤yi(1≤i≤n). Then (35)∂T∂yi≥0,1≤i≤n.
Therefore, the conclusion can be verified.Claim 5.
T satisfies the acceleration.Proof.
By computing the second order partial derivatives ofT with respect to yi(1≤i≤n), we get that (36)∂2T∂yi2=1-ρy1ρ+y2ρ+⋯+ynρ1/ρ-2yiρ-2yiρ-y1ρ+y2ρ+⋯+ynρ. Because 0<ρ<1 and 0≤yi(1≤i≤n), therefore (37)∂2T∂yi2≤0,1≤i≤n.
Then we can obtain the conclusion that the acceleration is satisfied byT.Claim 6.
Sensitivity is satisfied byT.Proof.
For1≤i≤n, by calculating it is easy to get that (38)∂T∂yiyiT=yiρy1ρ+y2ρ+⋯+ynρ. Due to 0≤yi(1≤i≤n), then (39)∂T∂yiyiT≥0,1≤i≤n. In summary, T is sensitive to module trustworthiness.Claim 7.
T complies with substitutivity.Proof.
SinceT is a continuously differentiable function, and (40)∂T∂yi=y1ρ+y2ρ+⋯+ynρ1/ρ-1yiρ-1. Then, for 1≤i,j≤n,i≠j, we can get (41)d∂T/∂yj∂T/∂yi=dyjρ-1yiρ-1=1-ρyi-ρyjρdyiyj.
According to (33), it follows that (42)σij=dyi/yjd-∂T/∂yj/∂T/∂yi×-∂T/∂yj/∂T/∂yiyi/yj=11-ρ,1≤i,j≤n,i≠j.
Since0<ρ<1. Then substitutivity holds for T.


## 5. The Measurement Procedure Based on the Measures Established in Section3

The measures given in this paper are used to measure source codes trustworthiness in the software implementation phase, and the source codes can be written in an imperative language or in an object-oriented language. We have presented specifications for the implementations expected by users of the program elements involved in the imperative languages [51]; if you want to use the measures built in this paper to measure the trustworthiness of source codes written in an object-oriented language, you need to propose the specifications for the implementations expected by users of the program elements involved in the corresponding object-oriented language.The measurement procedure based on the proposed measures in Section3 consists of four steps as shown in Figure 1. For a given software system S=(E,R), we first find a partition M of MS, where MS is the set of all modules in S. Then, for ∀m∈MS, we compute T1(m) according to Definition 9 in Step 2. For ∀m∈MS, based on the results of computation of T1(m), T2(m) are calculated according to Definition 10 in Step 3. In the final step, on the basis of the results of Step 3, the software trustworthiness T(S) is obtained by utilizing Definition 12.Figure 1
The measurement procedure based on the measures established in Section3.


## 6. Case Study

To demonstrate the effectiveness of our measure, we applyT to measure the trustworthiness of quick sort program written in the C language in Algorithm 1. For simplicity, we just consider the program element: variable. Here we use the trustworthy properties of variable given in [51] as variables’ implementations expected by users. Let M={m1=Em1,Rm1,m2=Em2,Rm2,m3=Em3,Rm3}, where(i)
Em1 is composed of the variables in line (1)-(18), i.e., Em1={R,i,j,pivot}(ii)
Em2 consists of the variables in line (19)-(28), i.e., Em2={R,low,high,pivotpos}(iii)
Em3 is made up of the variables in line (29)-(42), i.e., Em3={s[100],i,j}Algorithm 1:Quick sort program written in the C language.
( 1 )  #include ＇＇stdio.h＇＇ ( 2 )  int Partition(int ∗R,int i,int j) ( 3 ) ( 4 )  int pivot=R[i]; ( 5 ) while(i<j) ( 6 ) ( 7 )  while(i<j&&R[j]>=pivot) ( 8 )  j--; ( 9 )  if(i<j) ( 10 )  R[i++]=R[j]; ( 11 )  while(i<j&&R[i]<=pivot) ( 12 )  i++; ( 13 )  if(i<j) ( 14 )  R[j- -]=R[i]; ( 15 ) ( 16 )  R[i]=pivot; ( 17 )  return i; ( 18 ) ( 19 )  void QuickSort(int ∗R,int low,int high) ( 20 ) ( 21 )  int pivotpos; ( 22 )  if(low<high) ( 23 ) ( 24 )  pivotpos=Partition(R,low,high); ( 25 )  QuickSort(R,low,pivotpos-1); ( 26 )  QuickSort(R,pivotpos+1,high); ( 27 ) ( 28 )  //QuickSort ( 29 )  int main() ( 30 ) ( 31 )  int s[100]; ( 32 )  printf(＇＇input 10 number＇＇); ( 33 )  for(int i=0;i<10;i++) ( 34 ) ( 35 )  scanf(＇＇%d＇＇,&s[i]); ( 36 ) ( 37 )  QuickSort(s,0,9); ( 38 )  for (int j=0;j<10;j++) ( 39 ) ( 40 )  printf(＇＇%d ＇＇,s[j]); ( 41 ) ( 42 )Then#(E)=11. From the trustworthy properties of variable described in [51], we know that i,j∈Em1 do not have one and only one purpose, the same identifiers are still used in main function, and then they are not expected by users. Moreover, R∈Em1 and R∈Em2 do not have meaningful names; therefore, they are not expected by users. So, we can get #(Em1)expect=1, #(Em2)expect=3, and #(Em3)expect=1. It follows that T1(m1)=1/11, T1(m2)=3/11, and T1(m3)=1/11.Supposeρ=0.4,β=0.6; then T2(m1)=(5/33)2.5, T2(m2)=(5/11)2.5, T2(m3)=(5/33)2.5, and (43)TS=T2m1∘Tm2∘T⋯∘Tmn=T2m1ρ+T2m2ρ+…T2mnρ1/ρ=0.50.


## 7. Comparative Study in Terms of Measurement Theory and the Properties Given in Section4

In this section, we compareT with the decomposition of trustworthy attributes based software trustworthiness measure (DTABSTM) [16], axiomatic approaches based software trustworthiness measure (AABSTM) [17], fuzzy theory based software trustworthiness measure (FTBSTM) [22], and evidence theory based software trustworthiness measure (ERBSTM) [28] through the measurement theory and the properties presented in Section 4. The comparative results are given in Table 1, where √ represents that the measure holds for corresponding property and × expresses that the measure does not comply with the corresponding property. DTABSTM, AABSTM, ERBSTM, and FTBSTM do not build measurement structures in the measurement theory; therefore they do not comply with measurement theory. References [16, 17] have proved that monotonicity, acceleration, sensitivity, and substitutivity hold for DTABSTM and AABSTM separately. ERBSTM and FTBSTM do not satisfy acceleration and substitutivity. The reason is that both of them do not consider the efficiency of using attributes and the quantitative relations between trustworthy attributes, while correlations between trustworthy attributes are the cause that trustworthy attributes can substitute each other to some extent. From Table 1, we can get that T is better than all the four measures in terms of measurement theory and the properties introduced in Section 4.Table 1
Comparative study in terms of measurement theory and the properties given in Section4.
Property T DTABSTM AABSTM FTBSTM ERBSTM Measurement theory √ × × × × Monotonicity √ √ √ √ √ Acceleration √ √ √ × × Sensitivity √ √ √ √ √ Substitutivity √ √ √ × ×


## 8. Conclusion and Future Work

In this paper, we apply measurement theory to measure the source codes trustworthiness, present an extensive structure based software trustworthiness measureT, and validate T with axiomatic approaches from a theory perspective. Compared with some popular software trustworthiness measures, the measure T can evaluate software trustworthiness better in terms of measurement theory and the properties described in Section 4.However, only a small case is given to demonstrate the effectiveness ofT, in order to support T’s practical usefulness, we will experiment T using the real cases and develop a tool based on T. The specifications for the implementations expected by users of the program elements involved in the imperative languages that are given by us in [51] are not complete, and the specifications are only suitable for imperative languages. In the future, we will expand the specifications proposed in [51] and establish specifications for the implementations expected by users of the program elements involved in the object-oriented languages. We do not give methods for computing the values of ρ and β; how to determine the values of ρ and β is an important future work. The set of properties presented in Section 4 should be considered sets of necessary properties that need to be satisfied by a software trustworthiness measure. It is possible that some important properties are omitted due to oversight; extending and refining the set of properties are the future works too.



---

*Source: 6982821-2018-11-19.xml*