Software Evolution by Using Fuzzy Logic

8/3/2019 Software Evolution by Using Fuzzy Logic

1/13

Addressing Uncertainty in Software Evolution by using Fuzzy Logic(TECHNICAL REPORT 001-04)

Luigi Cerulo, Raffaele Esposito, Maria Tortorella, Luigi Troiano

RCOST Research Centre on Software Technology

Department of Engineering - University of Sannio

Viale Traiano - 82100 Benevento, Italy

{lcerulo, r.esposito, tortorella, troiano}@unisannio.it

Abstract

In literature there are many approaches for supporting legacy software system evolution. They provide to analyze and as-

sess legacy software system in order to identify the most suitable strategy to be applied. The main limitation of these ap-

proaches consists of the lack of strategies for the management of uncertainty, traditionally considered as unscientific and

as a source of errors. The first source of uncertainty regards the confidence of answers provided by respondents, which of-

ten are not fully confident in their judgments. In this paper, an approach previously proposed is analyzed and extended with

fuzzy logic concepts. The approach uses a measurement framework based on the Goal-Question-Metric (GQM) paradigm

and a set of critiquing tables, both collecting and/or using data gathered by interviewing the knowledge owners. In the ex-

tended proposed approach, fuzzy logic principles have been introduced in both components, in order to obtain a better insight

of the analyzed software system quality and an indication of the risks to be assumed when one selected strategy is adopted in-

stead of another.

1. Introduction

The evolution of existing legacy applications is strictly connected to presence of new business requirements. They re-

quire new technologies for supporting eBusiness initiatives [5]. Existing approaches for evolving legacy software systems

aim to understand which kind of approach should be adopt. This decision does not depend just on the legacy system sta-

tus but also on additional aspects, such as the technology to be introduced, the organization and business processes embody-

ing the legacy system and so on. Therefore, before applying a specific approach, it is necessary to choose the most suitable one

to the specific improvement requirements. Decisional supports are needed for better performing this task. To fulfil this pur-

pose, many decisional approaches have been proposed [2, 5, 11, 17].

Their limitation refers to the lack of strategy for the management of uncertainty.

The research presented in this paper considers a strategy presented in a previous work [2] for identifying the most suit-able approach for evolving an existing software system after assessing it, and extends it for the management of the uncer-

tainty. The previously proposed strategy comprises a first stage aimed at the creation of a baseline of the system by analyzing

and assessing its current business and technical values. The data of the baseline are used in a second stage for identifying crit-

ical aspects to be investigated and devising a suitable evolution approach. In order to address the existence of uncertainty

in the collected data, this paper introduces fuzzy logic concepts [10]. They are also used together with critiquing techniques

[15], in order to map the actual assessment values to the specific actions for changes. In particular, critiquing tables are de-

fined for assisting software engineers and managers to formulate critiques on an existing software system and derive actions

to be performed. In this paper, the critiques are inferred by a fuzzy rule base engine, and capture heuristic rules that link de-

ficiencies in the baseline of the system, as expressed by critiques, to approaches to be applied to overcome them. The case

study, conducted for evaluating the first version of the approach has been reanalyzed with the new rules introduced by the

fuzzy logic.


2/13

Research Centre on Software Technology TR 001-04

The following Section 2 gives some background information on approaches previously proposed for assisting software

system evolution. Section 3 briefly presents the strategy for supporting the identification of an evolution approach and that

will be extended with the introduction of fuzzy logic concept; Section 4 puts in evidence some drawbacks that will be faced

by the use of fuzzy logic and introduces the adopted fuzzy model; Section 5 illustrates the case study and discusses the resultsobtained by the extended framework; concluding remarks and future works are discussed in Section 6.

2. Background

Many approaches have been proposed for managing the evolution of legacy systems, and several authors have proposed de-

cision frameworks to select among a set of alternatives. In general, decision frameworks are required to assess a legacy sys-

tem from two points of view: a business dimension and a technical dimension [5, 11, 17].In particular, in [5], Bennett et

al. identify 6 strategies to deal with a legacy system: discard, wrap, outsource, freeze, carry on with maintenance and sup-

port, and reverse engineering. They base their decision on the modelling of the business strategy of an organization from a

top-down perspective in order to make informed decisions regarding the legacy system. They introduce a two-phase model,

called SABA, Software As a Business Asset, that uses an organizational scenario tool to generate scenarios for the organiza-

tions future and a technology scenario tool to produce a prioritized set of solutions for the legacy system. Prioritization of so-

lutions is achieved by comparing the current legacy system with the systems required by each generated scenario. In [17],

Sneed identifies five steps to be taken in consideration when a re-engineering project is planned. The strategies are: project

justification, to determine the degree to which the business value of the system will be enhanced; portfolio analysis, to prior-

itize the applications to be re-engineered based on their technical quality and business value; cost estimation, to estimate the

costs of the project; cost-benefit analysis, to compare costs and expected returns; and contracting, to identify tasks and dis-

tribution of effort. The Options Analysis for Reengineering (OAR), presented in [16], is a systematic, architecture-centric,

decision-making method for mining existing components for new software architecture, by identifying potential compo-

nents, estimating the mining cost, and evaluating the effort required to reuse legacy components. In [1, 2] an approach was

presented that exploits these concepts. The approach includes a measurement framework, aiming at evaluating the busi-

ness and technical values of the software system, and critiquing tables [8, 11, 15], aiming at translating the evaluation results

in order to provide suggestions for the typology of strategies to be adopted for evolving the software system. The defini-

tion of the measurement framework is based on the Goal-Question-Metrics (GQM) paradigm [4, 5, 3], and it includes the

goals to be reached by the evaluation task, the questions to be answered for reaching the goals, and the metrics to be mea-sured for answering the questions. A more precise description of the measurement framework will be provided in the next

section.

In the approaches proposed above, a problem may arise when measures have to be assigned to the considered metrics and

the source of information is the interviews with the knowledge owners. They very often express their opinions by means of

linguistic labels on ordinary scales. This kind of labels cannot be precisely quantified. Moreover, the respondent may not be

able to provide a precise value, as he/she is not fully confident in their judgment. All these aspects entail uncertainty, which

needs to be managed.

The main limitation in the previous approach regards exactly the management of uncertainty. In decision-making prob-

lems, uncertainty was traditionally considered as unscientific and as a source of errors. Therefore, techniques are needed for

identifying the sources of uncertainty in the problem and removing them. Traditional numeric techniques provide an erro-

neous sense of confidence in the result. This is even true in software engineering decision-making problems, even if, in this

case, evaluation of software artifacts is made by means of numeric techniques, that reduce the uncertainty and, consequently,

the risk to capture the information richness of human communication and cognition. There are several ways to model the re-

spondents level of confidence [6, 14]. A known solution to deal with uncertainty is represented by Fuzzy Logic [19, 20, 21].

A fuzzy number is a quantity whose value is imprecise, differently from ordinary numbers whose value is exact, and the num-

ber is univocally determined.

The aim of this paper is to introduce fuzzy logic principles in the approach proposed in [2]. In fact the use of these prin-

ciples should provide a better insight of the business and technical values of a software system and of the strategies to be ap-

plied for evolving it. In addition, the fuzzy evaluation should also provide information about the risks to be considered when

a strategy is adopted instead of another, and the opportunity to use it by the software engineer.

3. A strategy for supporting software evolution

The strategy proposed in [2] consists of two components:

2


3/13


a methodological approach, which drives the software system evolution;

a supporting toolkit, composed of the measurement framework, supporting the assessment activities, and a set of cri-tiquing tables, supporting the identification of the typology of the evolution approach to be adopted;

The methodological approach is composed of the following four main phases:

Requirements definition, which identifies the requirements for the evolution process and performs the tailoring of the

toolkit components to the specific context. To reach its aim, the phase considers various aspects such as the software sys-

tem to be evolved, the business processes adopting it and technological and business trends.

Software System assessment, aiming at gaining a quantitative knowledge of the software system by applying the mea-

surement framework. In particular, the characteristics and attributes of the Business and Technical quality of the software

system are assessed. Therefore, their values are compared with the target business and technical qualities in order to iden-

tify gaps to be considered during the identification of the evolution approach.

Identification of the evolution strategy, which aims at defining the most suitable approach for the evolution of the software

system. The critiquing tables tailored in the first phase are used in this phase in order to extract critiques on the software

system on the basis of the evaluation results obtained. The critiques represent suggestions on the possible strategies to be

applied and are a useful mean for addressing the evolution task. The strategies identified need to be later customized to the

characteristics of the software to be evolved.Software system evolution, which entails the implementation of the legacy system evolution by applying the selected and

customized strategy.

As previously stated, the measurement framework based on the GQM paradigm [4, 5], aims at supporting the assess-

ment of the software system. The specific framework, that is described has to be considered as an example of tailoring of a

generic measurement framework. Indeed, each application of the strategy may require changes of the framework for mak-

ing it suitable for the specific context.

The quality model, used in the definition of the measurement framework for evaluating software systems, is based on

the identification of the technical and business quality profiles. Consequently, the framework considered the Business value,

representing the system value from the points of view of its direct and indirect users, and the Technical value, representing

the system value from the points of view of technical users.

On the basis of these choices and the guidelines of the GQM paradigm, the following two goals were defined:

GOAL 1: Analyze a software system with the aim of evaluating its Business value.

GOAL 2: Analyze a software system with the aim of evaluating its Technical value.

Table 1 lists the characteristics and quality attributes considered for achieving each of the goals. The characteristics and re-

lated attributes have been used for defining the questions and identifying the metrics to be assessed on the analyzed software

system.

The values assumed by the considered metrics are normalized in order to make them comparable. They are later aggre-

gated for evaluating the attributes and the correspondent characteristics. For example, if X1, X2, ..., Xn are the values as-

sumed by the M1, M2, ..., Mn metrics related to the generic attribute WM. WM is evaluated through a weighted average by

using the following formula:

W M =

n

i=1

wiXi (1)

where w1, w2, ...,wn add to 1, and each wi represents the weight the enterprise assigns to the related metric Mi on the

basis of the relevance that it attributes to that metric for the evaluation of WM. Similar formulas are used for aggregating the

values of the attributes and evaluating the values of the characteristics, and, therefore, for assessing the Business Value and the

Technical Value by aggregating the values of the related characteristics. The various values thus obtained are later compared

with given thresholds representing the satisfaction expressed by the enterprise with reference to each metric, attribute and

characteristic. Major details on the framework and examples can be found in [2]. Once the data are collected, the critiquing

tables, the second component of the toolkit, represents a support for assigning critique to the software system. The critiques

helps to interpret the obtained results in terms of the evolution approach to be applied to the software system. The structure

of a generic critiquing table is shown in table 2.

The headings of the rows of the table are the assessed attributes. The critiques used as column headings represent possi-

ble comments on the assessed object. A critique is made active if the gap analysis activity reveals a negative value assumed

3


4/13


Characteristics Attributes

Businessvalue

Economic valueRedevelopment costMaintenance costFuture utility

Data valueData criticismData dependance

Quality in use

Functional adequacyAccuracyInteroperabilityUsabilitySatisfactionSafety

Specialization Specialization level value

Technicalvalue

Maintainability

SizeComplexityAnalyzabilityStructuredness

DegradationResponsiveness degradationReliability degradationMaintainability degradation

ObsolescenceSoftware obsolescenceDatabase obsolescenceOperating System obsolescenceHW/SW infrastructure obsolescence

Reliability SW reliability

Table 1. Quality model used in the measurement framework

critique 1 critique 2 critique ... critique n

attribute 1attribute 2 Xattribute ...attribute n X X

Table 2. Generic critiquing table

by an attribute with reference to a given threshold. The thresholds are identified with reference to the characteristics and re-

lated attributes by interviewing software engineers and enterprise managers, during the tailoring activities of the first phase of

the methodological approach. If a critiquing table is well defined, after the assessment task, the cell in correspondence of cri-

tique i and attribute j indicates ifcritique i has to be considered when attribute j assumes an unsatisfying value with reference

to the given threshold. In this case, critique i is considered active. It can represent a simple comment or, even, a sugges-

tion regarding the actions to be executed on the assessed system. In the approach proposed in [2], the headings of the rows

in the table were the attributes of the characteristics considered in the framework, while the headings of the columns in-

dicated the possible evolution intervention to be considered, such as reverse engineering, redocumentation, data migration,

language migration, and so on. All the considered interventions are those listed as heading of the columns in 5. In the pre-

vious approach an X in correspondence of an attribute and an evolution intervention indicated that the second should be

executed on the analyzed software system for improving the attribute value. The obtained critique, together with the sys-tem evolution requirements, permitted the definition of which approach or set of approaches could be applied for evolving

the software system.

4. Managing uncertainty by using fuzzy logic

This section introduces the fuzzy logic concepts that are applied to the approach, presented above, in order to manage the

uncertainty. In particular, the first subsection describes how the metrics values can be expressed as fuzzy numbers and how

this aspect can be managed in the aggregation operations; the next subsection describes how fuzzy predicates can be used to

model the concepts of satisfaction level and how satisfactory is a collected measure; the third subsection describes the fuzzy

rules applied for translating the collected measures in actions to be performed; the last subsection describes how to transform

quantitative measures in qualitative judgement by introducing the concept of fuzzy threshold.

4


5/13


4.1. Fuzzy numbers

This section illustrates how the fuzzy numbers can be introduced in data gathering required by the measurement frame-

work, in order to manage the confidence of the answers provided by respondents.

A fuzzy number can be regarded as a distribution of possible values [7], defined as:

A : R [0, 1] (2)

Each value x ofR has an associated membership degree A(x), so that some values are more representative than others. Thus,a fuzzy number is a convex and normalizedsubset ofR [9]. A fuzzy number is unimodal when:

A(x) =

l(x) x < a1 x = ar(x) x > a

(3)

where l(x) (r(x)) is a non-decreasing (non-increasing) monotonic function, left (right) continuous, and l(x) < 1 x < a(r(x) < 1 x > a). a will be indicated as xM and will be referenced as prototypic. Moreover, l(x) and r(x) can be linear. In

that case, fuzzy numbers are triangular, as depicted in Fig.1. Therefore, a triangular fuzzy number can be fully described by

Figure 1. Triangular fuzzy numbers

triple (xL, xM, xR), where xL and xR represents the intersection of l(x) and r(x), respectively, with the x-axis. Unimodalfuzzy numbers describe the concept of around.

Respondents confidence can be modeled by dispersion, given by the function support, supp, defined as:

supp(A) = {x|A(x) > 0} (4)

It can be shown that supp(A) is always defined in an interval [xL, xR] [10]. The less confidence is expressed, the more spread

the number is, and the larger the number support is. In any case, the values of the support function cannot exceed the interval[0, 1], as values outside that interval are not possible at all. Thus, the support function is defined as triangular fuzzy numbersrestricted to interval [0, 1], as depicted in Fig.2. The notation [A] will be used as a means to express restriction of A to theunary interval.

Lets measure the confidence by means of variable . When the confidence is maximum, then = 1 and the support func-tion is defined in supp(A) = {a} as the value is exactly a. When the confidence is minimum, then = 0 and the extremesof triangle would run to infinitum, as depicted in Fig.2. In this case, the number results in square window, because all val-

ues x [0, 1] are equally possible and A(x) = 1, due to the non-confidence in the result. The confidence level can belinked to angle in Fig.2: when the confidence is maximum (minimum) = 0 ( =

2). Thus, a linear variation can be as-

sumed and = 2

(1 ) by varying [0, 1]. Then extremes are given as

xL = xM tan2 (1 )

xR = xM + tan

2 (1 )

(5)

5


6/13


Figure 2. Fuzzy numbers confidence

Arithmetic of ordinary numbers can be extended to fuzzy numbers by means of Zadehs extension principle [19], as:

C(z) = z=xy

(A(x) B(y)) (6)

where is an arithmetic operator, and and are respectively t-conorm and t-norm operators [10].The extension of the strategy, described in Section 3 with the introduction of the fuzzy logic, requires the possibil-

ity to express the metrics collected through the measurement framework as fuzzy numbers. Therefore, Let Ai(x) =(wixiL, wixiM, wixiR) be the fuzzy evaluation of the generic metric MI. In addition, the weighted mean used in the measure-ment framework (equation 1) requires the definition of the multiplication and the sum of triangular numbers. Multiplication of

the triangular fuzzy number Ai(x) for a crisp ordinary wi 0 value is still a triangular fuzzy number (wixiL, wixiM, wixiR).Moreover, the sum of triangular fuzzy numbers is still a triangular fuzzy number [19]. Therefore, a generic attribute W M

can be evaluated as the following fuzzy number:

W M = (n

i=1

wixiL,

n

i=1

wixiM,

n

i=1

wixiR) (7)

However, in some cases the number Ai could be restricted to interval [0, 1]. It can be proven that the weighted mean of re-stricted triangular numbers is the restriction of the weighted mean of unrestricted numbers [10]. That is:

W M =

ni=1

wi[Ai] =

(

ni=1

wixiL,

ni=1

wixiM,

ni=1

wixiR)

(8)

4.2. Fuzzy predicates

After obtaining a measure for a given attribute, expressed as a fuzzy number, it has to be uses for answering the frame-

work questions, such as: how satisfactory is the Usability? The answer can be given by the a qualitative judgement, such as:

Usability is high. The word high is vague, depending on the organizations standards and values. In any case, there will

be values below a lower limit that will certainly be unsatisfactory, which will assume a zero membership degree, and an up-

per limit above which values are fully satisfactory. Then the satisfaction can be expressed as a membership function H, which

is monotonic and links the lower and upper limits. Examples of membership functions are shown in Fig.3 For each crisp value

x the corresponding degree of truth H(x) provides a value of how satisfactory measure x is. However, as previously pre-sented in eq. 7, the aggregation of the measures could lead to a fuzzy measure A(x) entailing a distribution of values on anx-axis, as depicted in Fig.4. The figure shows that, for each possible index value x supp(A), a corresponding satisfac-tion level H(x) exists.

The distribution of values that are both in A(x) and H(x) can be described by means of t-norms [13]:

(A(x), H(x)) (9)

In particular, a widely used t-norm is:

min(A(x), H(x)) (10)

6


7/13


Figure 3. Membership functions between lower and upper limit

Figure 4. Evaluation of fuzzy predicates

Given the distribution (A(x), H(x)), the second step is to aggregate it into a unique crisp indicator s, highlighting the sat-isfactory level of the measure. This can be computed as:

s =

xsupp(A)

(A(x), H(x))dxxsupp(A)

A(x)dx(11)

which is a generalized form of centroid [10]. In relation to Eq.(10), it becomes:

s =

xsupp(A)

min(A(x), H(x))dxxsupp(A)

A(x)dx(12)

In that case s can be interpreted as ratio of areas as depicted in Fig.5.

Another information useful to decision making is the dispersion d of the values on the y-axis in the distribution(A(x), H(x)). The dispersion can be computed as the distance between aggregations of possible values above the aver-age and possible values below the average:

d = u l (13)

where:

u =

xsupp(A)H(x)m

min(A(x), H(x))dxxsupp(A)H(x)m

A(x)dx(14)

and

l =

xsupp(A)H(x)m

min(A(x), H(x))dx

xsupp(A)H(x)m

A(x)dx(15)

7


8/13


with

m =

maxxsupp(A)

H(x) minxsupp(A)

H(x)

2(16)

It is easy to verify that d = 0 when the distribution A(x) is crisp. Fig.5 provides a graphical interpretation of Eq.(16).

Figure 5. Aggregation areas

By using the formulas above, it is possible to introduce in the measurement framework the concepts of satisfaction and

dispersion of a measure. These aspects were not considered in the previous version of the strategy illustrated in [2], as it

analyzed only if the measures were above/below a given threshold without considering the degree of their difference.

4.3. Fuzzy rules

In some cases, attributes are not satisfactory and some actions should be put in place by the enterprise in order to im-

prove the quality and performance of the analyzed software systems. Suggested actions can be modeled by means of logi-

cal rules such as:

if functional-adequacy is not satisfied then modularization is fairly recommended and encapsulation is fairly recommended

and evolutive-maintenance is highly recommended.

Premises and consequences of the rules are both fuzzy in nature as they entail fuzzy predicates. In literature, there are ba-

sically two approaches to fuzzy inference calculi: the Mamdamis method [12], and the Sugeno-Takagis method [18]. While

Sugeno-Takagis method is more oriented to control applications because of its efficiency, the Mamdanis method is more ori-

ented to applications for expert systems as it is able to capture the experts knowledge.

Madmanis method considers rules with the general form:

rk : ifx1 is Ak1 and ... and xn is A

kn

then y1 is Bk1 , ... , ym is B

km

The method is composed of four steps: evaluation of fuzzy premises, inference, composition of consequences, defuzzifica-

tion.

Under evaluation of fuzzy premises, each aggregated score is evaluated in respect of fuzzy terms, so that values

Ak1(x1), . . . , Akn(xn) are obtained. Usually the t-norm adopted for anding the predicates is the min operator. Thus, the evalu-

ation of premises results into value

k = min(Ak1(x1), . . . , A

kn(xn)). (17)

If quantities x1, . . . , xn are fuzzy, then we can use Eq.(ref) to evaluate rule premises.

Under the implication value k is used to module consequences. The most common method for correlating the rule con-

sequents to the rule premises is clipping: it slices consequents membership functions by means of

Bk

i (y) = min(k, Bki (y)) (18)

8


9/13


Thus implication results in fuzzy sets Bk

1 , . . . , Bk

m.

Under composition, consequents involved in several rules are unified into one fuzzy set. Usually, this is done by mean of

max operator, as

Bi(y) = max(Bk

1(y), . . . , Bk

m(y)) (19)We notice that, since convexity and normality is not preserved by the method, the result Bi could not be a fuzzy number.

Under defuzzification, the result is reduced to a single crisp number. Two of the more common techniques are the centroid

and maximum methods. In the centroid method, the crisp value of the output variable is computed by finding the variable

value of the center of gravity of the membership function for the fuzzy value, as

i =

Bi(y)ydyBi(y)dy

(20)

The resulting number bi represents the level of recommendation suggested by action i.

These concepts are used for implementing the critiquing tables with the introduction of fuzzy logic concepts. There-

fore the critiquing table does not only indicate the type of the approach to be performed, but it becomes a fuzzy rule engine

inferring both the recommended approach and how successful its application may be for the improvement goal achieve-

ment.

4.4. Assessment of quantitative measures

Quantitative measures are evaluated by the framework against thresholds: an attribute with a quantitative measure is judged

positively or negatively according to the fact that it surpasses or not the threshold.

The threshold is selected by the respondent, thus it is hard to precisely evaluate it. It is more realistic to assume an impre-

cise threshold value T. In particular this value can be expressed as an interval [tL, tR]. The interval threshold value can beexpressed as a fuzzy set by means of a window membership function as depicted in Fig.6. The interval value entails a contin-

Figure 6. Interval threshold

uum of different thresholds which are all equally possible. Thereby, given a quantity x X [tL, tR], this will pass everythreshold t [tL, x), and will not pass any threshold t (x, tR]. If we provide value 1 for passing a threshold t (0 other-wise), the statement x which has passed the fuzzy threshold T(t) can be computed as

K(x) =

xinfX

T(t)dttRtL

dt(21)

This results in a linear ramp which arises within [tL, tR]. At tM =12

(tL + tR), we get K(tM) = 0.5. The ramp is in accor-dance with the meaning that it is not possible to pass sharply from values that do not pass at all the threshold, to values that

fully pass the threshold in presence of uncertainty. The more the uncertainty, the wider the interval [tL, tR], the lesser the in-clination of the ramp.

More in general, we get a non-linear increasing ramp within the interval of uncertainty [tL, tR]. In particular, we couldassume a triangular fuzzy number (tL, tM, tR) to describe a threshold about tM. In this case, K(x) is parabolic within

[tL, tR], as depicted in Fig.7.

9


10/13


Figure 7. Triangular threshold

Original framework Extended framework

Characteristics Attributes Measure Satisfaction Measure Measure Satisfaction Measure

Satisfaction Satisfaction

M T XL XM XR T0.5 s d

Quality in use

Functional adequacy 0.97 0.90 0.07 0.97 0.97 0.97 0.90 0.87 1.00 0.00

Accuracy 1.00 0.90 0.10 1.00 1.00 1.00 0.90 0.87 1.00 0.00

Interoperability 0.75 0.90 -0.15 0.75 0.75 0.75 0.90 0.76 0.00 0.00

Usability 0.78 0.90 -0.12 0.56 0.72 0.88 0.90 0.66 0.32 0.36

Satisfaction 0.76 0.80 -0.04 0.44 0.69 0.94 0.80 0.87 0.26 0.86

Safety 0.91 0.90 0.01 0.83 0.86 0.90 0.90 0.87 0.58 0.38

Degradation

Responsiveness degradation 1-0.00 1-0.33 0.33 -0.12 0.00 0.12 0.33 0.66 0.55 0.00

Reliability degradation 1-0.34 1-0.33 0.00 -0.42 0.36 1.15 0.33 0.66 0.36 0.06

Maintainability degradation 1-0.66 1-0.33 -0.33 0.02 0.72 1.42 0.33 0.66 0.20 0.00

Obsolescence

Software obsolescence 1-0.40 1-0.30 -0.10 -0.07 0.40 0.87 0.30 0.66 0.43 0.03

Database obsolescence 1-0.66 1-0.33 -0.33 -0.04 0.66 1.36 0.33 0.66 0.25 0.13

Operating System obsolescence 1-0.66 1-0.33 -0.33 -0.08 0.66 1.40 0.33 0.66 0.25 0.13

HW/SW infrastructure obsoles-

cence

1-0.66 1-0.33 -0.33 -0.04 0.66 1.36 0.33 0.66 0.48 0.69

Table 3. Results of the measurements frameworks

5. Case study

In [2], a system for the management of the activity of the local Public Administration of Maddaloni (a town in the district

of Caserta in Italy) was evaluated. The name of the system is SGC-OPEN (Software per la Gestione Comunale - OPEN). It is

a client/server application developed in 1992 and since 1998. It supports a large part of the activities performed by the Public

Administration, and it is composed of the three following subsystems:

Population, which includes functionalities for the management of information regarding the registry, electorate, recruit-

ment, marital status, commerce, municipal library, and municipal police force.

Resources, which includes functionalities for the management of the accounting, protocol and tax payment office.

Territory, which includes functionalities for the management of the activities of the municipal technical office and the

geographic information system.

The previous evaluation brought unsatisfying values for the Obsolescence and Quality in Use characteristics. The sug-

gested evolution strategies were System Migration, for improving the Obsolescence, and Evolutive Maintenance, for improv-

ing the Quality in Use.

SCG-OPEN is evaluated in this paper by considering the fuzzy logic extension, in order to manage the presence of uncer-

tainty in the measurements. Table 3 shows the results obtained by applying both methods on a restricted set of characteristics

concerning Quality in use, Degradation, and Obsolescence. In particular, columns Original frameworkrefer to the results pre-

viously obtained, and Extended framework concerns the new experience. In both cases, the table shows the measures of the

attributes, the desired satisfaction expressed by the enterprise using the software system, and the satisfaction level of the ob-

tained measures.

The values appearing in the three columns concerning the original framework are crisp numbers. In particular, the mea-

sures are crisp numbers as they do not carry information about uncertainty. Likewise, the desired satisfaction levels, given

by the organization, are also expressed as crisp threshold values indicating the frontier beyond which each measure should

be considered satisfying. The satisfaction level of an attribute measure is given by the difference between the value mea-

10


11/13


sured, M, and the desired threshold, T. A negative value of indicates a measure that is unsatisfactory for that attribute.Viceversa, a positive difference denotes that the attribute is satisfactory. The measure and the threshold are complemented

for the Degradation and Obsolescence, as, in these case, an evaluation is satisfactory if it is below the threshold. This hap-

pens, for example, to the Obsolescence whose value has to be kept low.In Table 3, each value appearing in the three columns referring to the extended framework is a triangular fuzzy Num-

ber, and, therefore, is a triple (xL, xM, xR). The most important value XM (possibility = 1) coincides, in most cases, withthe correspondent crisp value of the original framework. This means that the measured value is preserved but further en-

riched by the spread XR XL of the fuzzy number, that is a uncertainty indicator. In this case, the desired satisfaction isa membership function that should be defined by the enterprise by using two parameters: T0.5 and . The first is the mea-

sure at a satisfaction level of 0.5 (i.e. the possibility of the membership function in correspondence of T0.5 is 0.5), while

the second, represents the confidence of the threshold. For example, =0.87 for Functional Adequacy means a low uncer-

tainty for the threshold level, while =0.66 for Usability, means a higher uncertainty. The same value of threshold defined in

the original measurement framework has been used in the extended one. Furthermore, the confidence parameter has been cho-

sen by taking into account the responses of the enterprise. The concepts introduced in section 4.2 have been used for evalu-

ating if the measure is satisfactory. The last column in 3 indicates the satisfaction level s and the dispersion d, which are in-

dicators regarding, respectively, how satisfactory the measure is and which is its dispersion. On the same satisfaction level, a

difference in dispersion means that the higher the dispersion, the higher the risk in choosing that level of satisfaction as for ex-ample for Software obsolescence and HW/SW infrastructure obsolescence. They have almost the same satisfaction level (0.43

and 0.48) but very different dispersion (0.03 and 0.69).

In Table 5 we show the application of the critiquing table introduced in [2] by using the extended framework. In the pre-

vious application, an X in correspondence of an attribute and an evolution strategy indicated that the strategy should be

applied for improving the value of the attribute. It was not considered how negative the attribute measure was with refer-

ence to the given threshold. In the new version, the X has been substituted by a number considering also how much neg-

ative the attribute measure is and helping to prioritize the evolution interventions. In fact, by applying the fuzzy rules de-

scribed in section 4.3, the set of recommended actions have been obtained for each attribute. They are weighted by indexes

representing their application strengths. In particular, the indexes are useful for indicating if an evolution intervention is rec-

ommended and how successful it can be for improving a certain attribute. For example, the measure satisfaction of the us-

ability attribute in Table 3 is just 0.32 and it can be considered low. Table 5 indicates the actions that should be performed to

resolve the attribute deficit. In particular, User Interface Migration and Evolutive Migration are suggested as the stronger ac-tions to be performed for improving the Usability value, while other actions have a lower strength, or no strength at all, in-

dicating that they are not suggested as strategies. This can be interpreted in the following way: if the Usability value is to be

improved, Evolutive Maintenance and User Interface Migration can be considered the more successful strategies for achiev-

ing this goal, than the other listed ones, such as, for example, Redocumentation or Control Restructuring. Using one of the

less recommended strategies is more risky for the goal achievement than using one of the most recommended ones. As ad-

ditional example, another attribute that, in Table 1, exhibits an unsatisfying value (0.25) is the Database Obsolescence, and

also the dispersion of the measure is enough low (0.13) reinforcing the unsatisfactory value of this attribute. From Table 5,

the strategy that is most recommended for improving this measure is the Data Migration as the indicated weight is enough

high (0.80). Other evolution interventions, such as Evolution Maintenance, Architecture Migration, and so on, can influ-

ence only slightly the improvement.

An aggregation of all attributes can be computed by combining the action strengths on each column. This is made by

making a fuzzy union of inference rule outputs and, then, defuzzifying the aggregated membership function. Table 4 lists the

considered typologies of approaches with a score indicating their strength for achieving the evolution goals for the assesed

software system. The table indicates which are the strategies that can be applied for improving successfully all the attributes

measures, instead of paying attention to just one attribute. The most recommended strategy is Reverse Engineering. In fact, it

can be observed from 5 that this strategy is considered very relevant for improving the unsatisfying values of many attributes.

While, the less suggested strategy is Corrective Maintenance as, even impacting on many attributes, its scores are enough

low.

6. Conclusion and future works

Evolving software systems requires the analysis and assessment of their business and technical qualities. Regrettably, the

methods, strategies, and tools supporting the software system evolution still present some limitations. One of them is the lack

of management of the uncertainty in the respondents answers to the questions of a measurement framework. The aim of the

11


12/13


Activity Recommendationlevel

Reverse engineering 0.605User interface migration 0.558

Evolutive maintenance 0.556Data migration 0.545Redocumentation 0.544Reformatting 0.544Platform migration 0.521Security management 0.516Architecture migration 0.504Reengineering 0.504Language migration 0.477Data restructuring 0.475Control restructuring 0.465Encapsulation 0.454Modularization 0.453Corrective maintenance 0.167

Table 4. Overall activity recommendation

Reverseengineering

Userinterfacemigration

Evolutivemaintenance

Datamigration

Redocumentation

Reformatting

Platformmigration

Securitymanagement

Architecturemigration

Reengineering

Languagemigration

Datarestructuring

Controlrestructuring

Encapsulation

Modularization

Correctivemaintenance

Functional adequacy 0.83 0.50 0.50

Accuracy 0.50 0.83 0.50 0.17

Interoperability 0.77 0.77 0.77 0.77 0.50

Usability 0.79 0.79 0.50 0.50

Satisfaction 0.81 0.81 0.50 0.50

Safety 0.50 0.50 0.83 0.17 0.17 0.50

Responsiveness degradation 0.83 0.83 0.83 0.17 0.50 0.17 0.17

Reliability degradation 0.82 0.50 0.50 0.82 0.18 0.18 0.50 0.18

Maintainability degradation 0.80 0.50 0.50 0.80 0.80 0.50 0.50 0.80 0.50 0.80 0.80 0.20 0.80 0.20

SW obsolescence 0.82 0.50 0.50 0.82 0.50 0.82 0.18 0.18 0.50 0.50 0.18

DB obsolescence 0.50 0.20 0.80 0.20 0.20 0.50 0.20 0.50 0.20 0.20

OS obsolescence 0.50 0.50 0.81 0.19 0.19 0.50 0.19

HW/SW infrastr. obsolescence 0.50 0.50 0.82 0.18 0.82 0.50 0.18

Table 5. Level of activity recommendation for each attribute

research described in this paper is the use of the fuzzy logic concepts for managing the uncertainty when applying a strategy,

previously proposed for identifying the typology of the evolution approach to be applied to a certain context. In particular,

the fuzzy logic concepts are specifically adapted for managing the subjective uncertainty introduced when the knowledge

owners are interviewed for collecting the data required by a measurement framework.

The presented strategy has been validated within a case study, regarding a software system used in a local Public Admin-

istration Department. This context has been interesting for applying the proposed strategy, as the Public Administration De-partments need to be evolved on the basis of the directives and initiatives of the Italian Central Public Administration on the

subject of technological innovation. The proposed extension confirms the results obtained with the previous framework un-

derlying its robustness. In addition it gives further indications about the satisfaction of a measure and its dispersion, these

two factors can be successfully used for managing the uncertainty. Likewise, it provides useful information for the man-

agement of risks when decisions in software evolution have to be made. The future work of the authors aims at perform-

ing a deeper analysis of the impact of the actions involved in the software evolution in order to obtain a more reliable rule

base for making the critiquing table more effective and the decisions it supports more objective. Moreover, further investi-

gation will be performed for defining a strategy for the management of the risk to be taken in consideration when a chosen

evolution approach is applied.

12


13/13


References

[1] L. Aversano, R. Esposito, T. Mallardo, and M. Tortorella. Evolving Legacy System towards eBusiness, Managing Corporate Infor-

mation Systems Evolution and Maintenance. Idea Group, 2004.

[2] L. Aversano, R. Esposito, T. Mallardo, and M. Tortorella. Supporting decisions on the adoption of re-engineering technologies. In

8th European Conference on Software Maintenance and Reengineering, Tampere, Finland, 2004.

[3] V. R. Basili, G. Caldiera, and H. D. Rombach. Goal question metric paradigm. In J. J. Marciniak, editor, Encyclopedia of Software

Engineering, volume 1, pages 527532. John Wiley & Sons, 1994.

[4] V. R. Basili and D. M. Weiss. A methodology for collecting valid software engineering data. IEEE Trans. Software Eng., 10(6):728

738, November 1984.

[5] K. H. Bennett, M. Ramage, and M. Munro. Decision model for legacy systemss. In IEEE Proceedings Software, volume 146, pages

153159, 1999.

[6] G. Canfora and L. Troiano. Dealing With the Dont Know Answer in Risk Assessment. In Proc. Int. Conf. on Enterprise Informa-

tion Systems - ICEIS03. to appear.

[7] D. Dubois and H. Prade. Possibility Theory: An Approach to Computerized Processing of Uncertainty. Plenum Press, New York,

1988.

[8] G. Fischer, A. C. Lemke, and T. Mastaglio. Critics: An emerging approach to knowledge-based human computer interaction. In

Conference on Human Factors in Computing Systems , 1990.

[9] A. Kaufmann and M. Gupta. Introduction to Fuzzy Arithmetic: Theory and Applications. Van Nostrand Reinhold, New York, 1985.

[10] G. J. Klir and B. Yuan. Fuzzy Sets and Fuzzy Logic; Theory and Applications. Prentice Hall, Upper Saddle River, N. Y., 1995.

[11] J. L. Kolodner, E. A. Domeshek, and C. M. Zimring. Case-based design critiquing. In AAAI-93 Workshop on Expert Critiquing

Systems, pages 109114, 1993.

[12] E. H. Mamdani. Application of fuzzy logic to approximate reasoning using linguistic synthesis. IEEE Trans. Computers,

26(12):11821191, 1977.

[13] K. Menger. Statistical metrics. In Proc. Nat. Acad. Sci., volume 37, U.S.A, 1942.

[14] Z. Pawlak. Rough set. Bull. Pol. Acad. Sci. Tech., pages 253258, 35.

[15] B. G. Silverman. Survey of expert critiquing systems: Practical and theoretical frontiers. Communications of the ACM, 35(4):106

127, 1992.

[16] D. Smith, L. OBrien, and J. Bergey. Mining selected components: The options analysis for reengineering (OAR). In Proceedings of

the 23rd International Conference on Software Engeneering (ICSE-01) , pages 684684, Los Alamitos, California, May1219 2001.IEEE Computer Society.

[17] H. M. Sneed. Planning the reengineering of legacy systems. IEEE Software, 12(1):2434, Jan. 1995.

[18] T. Takagi and M. Sugeno. Fuzzy identification of systems and its applications to modeling and control. IEEE SMC, 15(116132),

1985.

[19] L. Zadeh. The concept of a linguistic variable and its applications to approximate reasoning - part i. Information Sciences, 8:199249,

1975.

[20] L. A. Zadeh. Fuzzy set theory: A perspective. In M. M. Gupta, G. N. Saridis, and B. R. Gaines, editors, Fuzzy Automata and Decision

Processes, pages 34, New York, 1977. NorthHolland.

[21] L. A. Zadeh. Fuzzy logic = computing with words. IEEE-FS, 4, 103111 1996.

13

Documents

Software Evolution by Using Fuzzy Logic