Impact Analysis using Class Interaction

Prediction Approach
Nazri KAMA a,1, Tim FRENCH b and Mark REYNOLDS b
a
University Teknologi Malaysia, Malaysia
b
University of Western Australia, Australia

Abstract. Impact analysis is an activity of assessing the effect of making a set of

changes to a software system. Many approaches have been developed include
performing impact analysis on a high level model that reflects to low level analysis
using class interaction prediction. However, analysis from the model contains false
results due to not all interactions between classes have impact to one another. In
this paper we introduce a new impact analysis approach that is able to filter some
false results using a set of impact prediction filters. The contributions of the paper
are: (1) a new impact analysis approach; (2) a new set of impact prediction filters
and; (3) evaluation results that show the new impact analysis approach improves
the accuracy of the prediction results.

Keywords. impact analysis, requirement interaction, class interaction, requirement,

class

1. Introduction

Impact analysis has been defined as the activity of assessing the effect of making a set
of changes to a software system [1]. It has also been defined as the effect or result of
making a change to all system-related documents [2]. Generally, the motivation behind
the impact analysis activity is to estimate the impact of a change to a software system’s
artifacts.
There are two approaches for impact analysis which are high level analysis and
low level analysis. The high level analysis uses high level artifacts such as requirement
artifact or a high level model that is developed based on requirement artifacts as the
source of analysis. The results of the analysis will be used to determine other impacted
artifacts such as design, class or test artifacts. Conversely for the low level analysis, the
source of analysis is based on low level artifacts and most researchers use class artifacts
as the source of analysis [3-6].
Each impact analysis approach is used in different contexts of software phases i.e.
software maintenance and software development. For the software maintenance phase,
the most reasonable approach is the low level-based analysis. This is because the class
artifact represents the final user requirements which make this artifact the most reliable
source of analysis. On the other hand for the software development phase, the most
reasonable approach is the high level analysis. This is because requirement artifacts is
considered the most completed and stable artifact compared to the other artifacts such

1
Nazri Kama.
as design, class and test artifacts [7]. This indirectly makes this artifact the most
reliable source of analysis.
A closer look at the impact analysis approach from the software development
phase context, there are two techniques of high level artifacts analysis which are direct
analysis and indirect analysis. The direct analysis technique [7] uses requirement
document as a source of analysis whereby the indirect analysis technique uses a high
level model that is developed based on requirement document [8-11]. The effectiveness
of the indirect analysis technique depends on the accuracy of reflection between the
high level model analysis and the class artifact analysis.
Many researchers have developed the high level model for example Use Case
Maps (UCM) [8], Formal Concept Analysis (FCA) [9] and class interaction prediction
[10,11]. We have selected the class interaction prediction model as this model does not
involve any new notations and rules which indirectly contribute to simplicity of usage.
This model is developed based on a reflection analysis of object interactions in
requirement documents to actual class interactions.
However, the impact analysis results generated by the model contain false results.
This is due to not all interaction links between classes in this model have change
impact to one another. The change impact means if change happens to one side of two
interacting classes, the other class will be impacted as well. Given an example of two
interacting classes where C1 interacts with (or requires) C2 through a one-way
communication. If change happens to C1, it will not affect C2 even they have
interaction between them. This is due to C2 does not require C1 for its implementation.
Conversely if change happens to C2, C1 will be affected.
Therefore, it is important considering these two reasons in order to improve the
accuracy of the impact analysis results. This paper proposes a new impact analysis
approach that that is able to filter out some false results using a new set of impact
prediction filters. Two filters were introduced which are invalid interaction flow
filtration and imported class filtration. These filters will be comprehensively described
later.
This paper is laid out as follows: Section II describes related work. Next, Section
III elaborates a new impact analysis approach. Thereafter, Section IV and Section V
explain evaluation strategy and evaluation results. Finally, Section VI presents
conclusion and future work.

2. Related Work

This research work brings together two research areas which are: class interaction
prediction and; requirement level impact analysis.

2.1. Class interaction prediction

There has not been much work related to the generation of class interaction from
requirement artifacts [11-13]. Some researchers use the term object model development
instead of class interaction prediction.
Liang [12] proposes a use case goal approach to develop class interaction. This
approach defines a use case goal as a collection of interactions between use case
entities and external use case environment. A use case entity reflects to a class in which
the interaction between the use case entities indirectly reflects to the class interactions.
 Sharble and Cohen [13] develop a grammatical analysis approach for developing a
class interaction. This approach analyzes noun or noun phrase keywords in requirement
specification in which the detected keywords reflect to the class, attribute, and
operation names. The interaction between keywords that reflect to class names
indirectly contributes to class interaction development.
Premerlani et al [14] build an almost similar approach with [12] which is a use
case driven approach. This approach detects objects in requirement specifications and
models the object interactions using sequence diagram. The object interactions in the
diagram are used as a reflection model of the actual class interactions.
Kama et al [10,11] establish another similar concept of class interaction
development through reflection of object interactions analysis in requirement artifact.
A key difference in their approach is the introduction of a modification process after
reflecting the class interactions. They use the modification process to filter out some of
false reflection results and add relevant reflection results according to the design
strategy used by the application.

2.2. High level impact analysis model

Hassine et al [8] propose a requirement level change impact analysis approach using
use case maps (UCM). The UCM is a high level scenario-based modeling technique
that is used to model the functional requirements and high level design artifacts.
Changes that happen to the requirement will be mapped to the UCM model. Impact
analysis is conducted on the model as it reflects to the actual low level model.
Shiri et al [9] introduces an integrated requirement level impact analysis model
using UCM and Formal Concept Analysis (FCA) models. Again, changes that happen
to requirement will be mapped to the integrated model and impact analysis is
conducted on the model.
Yin Li et al [7] develop a requirement centric impact analysis approach that
composes integration between requirement interdependency analysis and dynamic
traceability analysis. For the requirement interdependency analysis, they have used
Dahlstedt’s [15] requirement interaction types and information retrieval technique for
the dynamic traceability analysis. Changes that happen to requirements will be
navigated down to class artifact via dynamic traceability analysis to detect the impacted
classes.

2.3. Remarks on the related work

Looking at the class interaction prediction works most of them are using a similar
concept of developing the class interaction model which is using object interactions
reflection. However, Kama et al [10,11] have introduced a modification process in their
approach in order to ensure high accuracy of reflection results.
On the other hand for the high level impact analysis, most current works focuses
on providing a systematic way of detecting impacted artifacts. However, none of them
filters the results generated by their approach. Therefore, this research believes that
through a combination of an effective class interaction prediction with impact
prediction filters, it may improve the accuracy of the impact analysis prediction results.
3. The New Impact Analysis Approach

There are four assumptions made for the approach to be effectively used by a software
system:
• The approach focuses on changes that happen to functional requirements of a
software system
• The functional requirements are described using use case specification
• All functional requirements are traceable to classes
• The software system employs the Boundary-Controller-Entity (BCE) pattern
of class implementation [14]
There are two main stages of the approach which are: (1) developing class
interaction prediction from object interaction analysis and; (2) predicting impacted
class using the class interaction prediction. This paper focuses on the second stage
implementation as the first stage we utilize our previous work [10,11]. However, we
briefly describe the first stage implementation in order to give a better understanding of
the overall impact analysis approach. The following figure shows the stages of the
approach.

Stage 1: Class Interaction (CI) Reflection Initial CI

Prediction Process Prediction

Requirement Final CI Modification

Artifact Prediction Process

Impact Analysis Initial Impacted

Process Classes

Stage 2: Impacted Class Final Impacted Filtration

Prediction Classes Process

Figure 1. Stages of the Approach

Figure 1 shows there are two processes involved in the first stage which are the
reflection process and filtration process I. The first process focuses on analyzing and
reflecting object interactions in requirement artifact to class interactions. The outcome
of this process is the initial class interaction prediction. The second process
concentrates on modifying the initial class interaction prediction based on the design
strategy used by the application and the outcome is the final class interaction prediction.
For the second stage, there are also two processes involved which are impact
analysis and filtration. The first process focuses on developing an initial set of
impacted classes using the final class interaction prediction analysis and a list of
impacted requirements from requirement artifacts. The second process filters the false
prediction results produced by the first process. We introduce two impact prediction
filters which will be comprehensively described later in this paper.
3.1. Stage 1: Developing a Class Interaction Prediction from Object Interaction
Analysis

3.1.1. Reflection Process

As described earlier, this process aims to analyse and reflect object interactions in
requirement artifacts to class interactions. There are two situations where the object
interactions could exist in requirement artifacts: (1) interaction in a requirement
description. For example “the student registers course using the student id”. This
requirement description shows three objects that are interacting between them which
are student object interact with course object and the course object interact with student
id object. (2) interaction between interacting requirement descriptions (RD). For
example “RD1- the student must log in to the system using student card information”
and “RD2- the system registers any selected courses by the student”. These two
requirement descriptions are interacting because RD2 requires RD1 prior to its
implementation. These two requirement descriptions show that the student card object
has interaction with the course object. This is because the course object can only add a
new course after verifying the student card information. Based on these situations, we
develop the class interaction prediction through object interactions analysis based on a
requirements description and object interactions analysis based on interacting
requirement descriptions. The term “interacting requirement descriptions” will be used
as requirement interaction henceforth. There are three steps in this process which are:
3.1.1.1. Step 1- Develop a class interactions prediction based on a requirement
description analysis
There are three sub-steps in this step which are to:
• a-1- Identify potential object names in a requirement description: The
identification is done through noun or noun phrase detection in requirement
description.
• a-2: Filter the potential object names using traceability analysis: The
filtration aims to eliminate the potential object names that have no traceability
relationship with actual class name. Those names that have traceability
relationship are considered as the significant object names. We use heuristic
rules traceability technique that can be found in [20].
• a-3: Reflect the significant object name interactions to actual class
interactions: Since the significant object name reflect to the actual class name,
the interactions between the significant object names indirectly reflects to the
interaction between the actual class name interactions.
3.1.1.2. Step 2- Update the class interactions prediction based on requirement
interaction analysis
There are three sub-steps in this step which are:
• b-1- Detect requirement interactions: We use our previous requirement
interaction detection technique using requirement attributes analysis to
develop the requirement interaction. There are two steps in the technique
which are: (1) Restructure requirement descriptions and; (2) Detect
requirement interaction using a set of detection guidelines. In the first step, we
have proposed eight requirement attributes:

ID (Unique Identifier)- A unique identification for every requirement

Pre (Pre-condition)- A list of conditions of the requirement that must be
fulfilled prior to its execution

TrE (Triggering Event)- An action(s) that cause the requirement to be
executed

Sub (Subject)- Actor of the requirement

Act (Action)- Action that the subject performs

Tar (Target)- conceptual object (results from activity) or physical objects

Dir (Direction)- direction or destination of the target to be communicated
and

Post (Post-condition)- A list of outcomes after the requirement has
successfully been implemented
For the second step, two requirement interaction detection guidelines were
used to detect the interaction between requirements (R1 and R2):

Guideline #1- [R1[All Post] OR R1[Part Post]] = R2[[All Pre] OR
[Part Pre]]: R1 and R2 are interacting if All or Part of the Pre-condition
of R2 is similar with All or Part of the Post-condition of R1

Guideline #2- [R1[All Pre] OR R1[Part Pre]] AND R1[TrE] = [R2[All
Pre] OR R2[Part Pre]] AND R2[TrE]: R1 and R2 are interacting if All
or Part of the Pre-condition and Trigger Event of R1 are similar with All or
Part of the Pre-condition and Trigger Event of R2
Detail of the techniques’ implementation can be found in [10].
• b-2- Detect and reflect the significant object name interactions in the
detected requirement interactions to class interaction: Same as the step (a-
3) where the interactions between the significant object names reflects to the
interaction between the actual class names.
• b-3- Update the class interaction prediction: Based on results generated in
step (b-2), the class interactions are updated accordingly.
3.1.1.3. Step 3- Identify class interaction flow
We define two types of class interaction flows which are: uni-directional flow and; bi-
directional flow. The uni-directional refers to an interaction between two interacting
classes where one class requires the other class for its implementation and not vice
versa. Conversely for bi-directional flow, this flow indicates that both classes require
each other for its implementation.

3.1.2. Modification Process

This process aims to filter the initial class interaction prediction based on BCE design
strategy used by the application. Two impact prediction filters were proposed which are
eliminating invalid BCE class interaction pattern and adding relevant Controller class
interaction. There are two steps in this process which are:
3.1.2.1. Eliminate invalid BCE class interaction pattern
The elimination is based on the following BCE interaction rules [14]:
 Table 1. BCE Class Interaction Rules
Boundary Control Entity
Boundary √ √ X
Control √ √ √
Entity X √ √

According to the above table, it clearly shows that the BCE design strategy does not
allow a direct interaction between Boundary class and Entity class. This interaction is
considered as false and will be eliminated. There are two sub-steps in this step which
are:
• Identify Boundary and Entity classes: The identification of the Boundary
class is based on three criteria: (1) a class name that reflects to a significant
object name in requirement description; (2) a class name that has “form” or
“screen” related keyword and; (3) a class name that has no attribute. On the
other hand for the Entity class, there are two identification criteria which are:
(1) a class name that reflects to a significant object name in requirement
description and; (2) a class name that has attribute.
• Eliminate interactions between Boundary and Entity classes: After
identifying the Boundary and Entity classes, any interactions that exist
between them will be eliminated.
3.1.2.2. Add relevant Controller class interaction
Since Controller class name could not be detected as part of the object name in
requirement artifact, the interaction of this class with the other classes (Boundary and
Entity classes) tends to be left undetected. There are three sub-steps in this step which
are:
3.1.2.3. Identify Controller class name in actual class name
a class name that has the following three criteria is considered as Controller class. The
criteria are: (1) a class name that has no attribute; (2) a class name that has controller
related keywords such as “Controller” or “Ctl” and; (3) a class that interacts with
Boundary and Entity classes.
3.1.2.4. Assign the detected Controller class to use case
The assignment is based on similarity analysis between the detected Controller class
name and use case name.
3.1.2.5. Group class names into use case
The grouping is based on two criteria which are: (1) a class name that exists in a use
case- this shows that the class name belongs to the use case where it exists; (2) if the
class name exists in several use cases, the identification of the highest number of
interactions with Controller class will be used. The highest the interaction of the class
name with the Controller class is, the more likely the class name comes from the use
case where the Controller class belongs to.
3.1.2.6. Establish interactions between the detected Controller class name and the
class names
After detecting the Controller class for each use case and grouping the class names into
use case, the interaction between these classes are then established.
3.2. Stage 2: Conducting Impact Analysis using the Class Interaction Prediction

3.2.1. Impact Analysis Process

As described earlier, this process focuses on developing an initial set of impacted
classes based on the final class interaction prediction. There are four new terminologies
developed for this process:
• Primary Impacted Requirements (PIR): A set of requirements that has
direct impact from change request. It contains several classes (Boundary,
Controller or Entity) that are interacting among them to implement the PIR.
• Secondary Impacted Requirements (SIR): A set of requirements that
interacts with the PIR. It contains several classes (Boundary, Controller or
Entity) that are interacting among them to implement the SIR.
• Primary Impacted Classes (PIC): A set of selected classes (Boundary,
Controller or Entity) from the PIR implementation that has direct impact from
a change request.
• Secondary Impacted Classes (SIC): A set of selected classes (Boundary,
Controller or Entity) that are coming either from: (a) a set of classes that
implement the SIR or; (b) a set of classes that interacts with the PIC.
There are two steps in this process which are:
3.2.1.1. Step 1- Detect PIR and SIR:
A detection of PIR is done by reviewing change request form from user. For the SIR,
any requirements that have interaction with the PIR are considered as the SIR.
3.2.1.2. Step 2- Detect PIC and SIC
A detection of PIC is done by performing similarity analysis between all the PIR class
names and object names stated in the change request form. Those similar class names
are considered as the PIC. If there is no similarity, a direct consultation from the
technical team will be used. For the SIC, all the classes that implement the SIR and
classes that interacts with the PIC will be combined. Any redundant classes are then
eliminated.

3.2.2. Filtration Process

This filtration process aims to filter the initial impacted class prediction. We introduce
two impact prediction filters which are: (1) IPF#1: Invalid interaction flow filtration
and; (2) IPF #2: Imported class filtration
3.2.2.1. IPF#1- Invalid interaction flow filtration
This filter aims to eliminate invalid interaction flows from the PIC to the SICs. As
defined earlier, there are two types of class interaction flow which are bi-directional
and uni-directional. All bi-directional flows are considered as valid interaction flow.
However for uni-directional flow, it depends on the direction of the navigation flow.
Those that point to the changed/impacted class are considered as invalid flows,
otherwise they are considered as valid. To explain the invalid interaction flow, an
example of three interacting classes (C1, C2 and C3) and two interaction flows (E1 and
E2) is used (see Figure 1 below).
 E1 E2
PIC SIC1 SIC2

Figure 1. Example of Uni-directional flow

Changes that happen to PIC will not affect SIC1 as the interaction link (E2) is
considered as invalid interaction flow.
3.2.2.2. IPF#2- Imported class filtration
This filter eliminates the imported class in the impacted class prediction generated by
the FG#1. As described earlier, changes are not allowed to the imported class as this
class belongs to the external source. The following figure shows the example of the
imported class elimination.
SIC6 (I)
E8
E1
PIC SIC1 (D)
E7
E2
E6
SIC2 (D) SIC4 (D) SIC5 (D)

E8
E3 E5
SIC3 (I)

Uni-directional D- Developed
Bi-directional I - Imported

Figure 2. Type of class from PIC to SIC

Looking at Figure 2, SIC3 and SIC6 are eliminated as they are imported classes. Due to
the elimination of the SIC3, the SIC4 and SIC5 are also eliminated as E8 and E5
interaction links are no longer valid.

4. Evaluation strategy

There are three strategies were used to evaluate the new impact analysis approach
which are case study, evaluation process and evaluation metrics.

4.1. Case Study

Three software projects were selected which were developed by group of final year
post-graduate students of software engineering course at the Centre for Advanced
Software Engineering, Universiti Teknologi Malaysia. They developed the projects
using object-oriented approach. In addition, all the projects employed BCE for its
design strategy.
The technical profiles of the projects are shown in Table 2 below:
Table 2. Projects Technical Profiles
Project # of Reqts # of use # of # of
ID cases Components Classes
PI 68 7 8 36
PII 60 6 7 38
PIII 65 7 7 40
4.2. Evaluation Process

There are two steps in the evaluation process which are: evaluating class interaction
prediction capability and evaluating impact analysis capability.

4.2.1. Evaluating class interaction prediction capability

This evaluation did not require involvement from the development teams. Three
software artefacts were reviewed from each case study: Software Requirement
Specification (SRS); Software Design Document (SDD) and; Software Development
Files (SDF). The SDF document consists of source code or class implementation
structure. Using these software artefacts, class interaction prediction were then
developed using the proposed approach. Finally, the developed class interaction
prediction was compared from each case study with actual class interaction to identify
level of agreement between them.

4.2.2. Evaluating impact analysis capability

For this evaluation, the evaluation process was divided into two cycles. For the first
cycle, three change requests were issued to each development team. Next, each of the
development team was asked to implement those change requests and produced a list of
impacted classes. In the following cycle, a list of impacted classes using the proposed
approach was developed. The results from these two cycles were then compared to
each other in order to identify level of agreement between them.

4.3. Evaluation Metrics

To evaluate the accuracy of the class interaction prediction and the impact analysis
prediction, a set of evaluation metrics from [16] was adopted. The application of the
metrics had not only been amended from evaluating the accuracy of the impact analysis
prediction but to evaluating the accuracy of the class interaction prediction as well [3,4].
The predictions of the impact analysis and class interaction were categorized into
four different groups. The groups of impact analysis prediction are:
• Not predicted and unchanged (correct prediction)
• Predicted but unchanged (false prediction)
• Not predicted but changed (false prediction)
• Predicted and changed (correct prediction)
The groups of class interaction are:
• Not predicted and not interacting (correct prediction)
• Predicted but not interacting (false prediction)
• Not predicted but interacting (false prediction)
• Predicted and interacting (correct prediction)
Based on the above groups, a 2X2 contingency table was constructed as below:
 Table 3. Contingency Table
Predictive Results
Not Predicted Predicted
Actual Unchanged/Not A B
Results Interacting (correct) (error)
Changed/Interacting C (error) D
(correct)

There are three main questions regarding the accuracy of the class interaction
prediction and the impact analysis prediction:

4.3.1. Question 1: Were the: (a) actual impacted classes predicted or; (b) interacting
classes predicted (completeness of the prediction)?
The ratio of the actual impacted classes or class interactions that were predicted is
measured in terms of completeness. The following formula was used:
D
Com : x 100
C +D
D value represents the number of impacted classes that are predicted and changed or
class interaction that are predicted and interacting. For C+D value, it represents the
number of impacted classes that actually were changed or the number of interacting
class that actually were interacting.

4.3.2. Question 2: Were the predicted: (a) impacted classes actually changed; or (b)
interacting classes actually interacting? (correctness of the prediction)
The ratio of the predicted impacted classes or that was true impacted or class
interactions that were true interacting is measured in terms of correctness.
D
Corr : x 100
B +D
D value represents the number of impacted classes that are correctly predicted to be
changed or the number of interacting classes that are correctly predicted to be
interacting. For B+D value, it represents the number of impacted classes predicted to be
changed (correctly or otherwise) or the number of interacting classes predicted to be
interacting.
The combination of the correctness and completeness value can be further used to
identify the pattern of the impacted class prediction and the class interaction prediction
results. This study uses Murphy and Notkin [17] work to describe the pattern of
prediction:
Table 4. Pattern of Prediction
Pattern of Prediction
Value
Optimistic Conservative Approximative Ideal
Corr High Low Low High
Com Low High Low High

According to Table 4, there are four patterns of prediction which are:

• Optimistic: (1) Impact analysis prediction: set of predicted impacted classes
comprises all impacted classes and miss some of the actual impacted classes
(false negatives); (2) Class interaction prediction: set of predicted interacting
 classes comprises all interacting classes and miss some of the actual
interacting classes (false negatives)
• Conservative: (1) Impact analysis prediction: set of predicted impacted
classes comprises all impacted classes, but also includes some of not impacted
classes (false positives); (2) Class interaction prediction: set of predicted
interacting classes comprises all interacting classes, but also includes some of
not interacting classes (false positives)
• Approximative: (1) Impact analysis prediction: set of predicted impacted
classes comprises not all impacted classes but also includes some of not
changed classes as well; (2) Class interaction prediction: set of predicted
interacting classes comprises not all interacting classes but also includes some
of not interacting classes as well
• Ideal: (1) Impact analysis prediction: set of predicted impacted classes
comprises all actual impacted classes; (2) Class interaction prediction: set of
predicted interacting classes comprises all actual interacting classes

4.3.3. Question 3: How good was the overall prediction on: (a) the actual impacted
classes or; (b) the actual interacting classes?
The completeness and correctness values are suitable for evaluating one relatively
small example at a time. For the purpose of comparing several evaluation results, a
single value to indicate the overall goodness of the results is required. Therefore, the
Cohen’s kappa (κ) [18] was selected as a value to represent the overall goodness of the
prediction result. The content of the κ value is defined as:
Po: proportion of units in which there is an agreement:
A+D
PO :
N
A+D value represents the number of correct predictions. N value represents the total
number of classes for impacted class prediction whereby for class interaction prediction,
the value represents the total number of interacting classes.
Pc: proportion of units for which agreement is expected by chance:
A+B A+C B+D C+D
Pc : x + x
N N N N
κ value is then calculated as:
Po - Pc
κ : 1 - Pc
To describe the relative strength of the κ value, Table 5 from [19] was used.
Table 5. Strength of Agreement Metric
No κ Value Strength of Agreement
1 < 0.00 Poor
2 0.00 – 0.20 Slight
3 0.21 – 0.40 Fair
4 0.41 – 0.60 Moderate
5 0.61 – 0.80 Substantial
6 0.81 – 1.00 Almost perfect
 5. Evaluation Results

There are two categories of results that reflect to the evaluation process: class
interaction prediction results and impact analysis results.

5.1. Class Interaction Prediction Results

The following table shows the class interaction prediction results for the projects.
Table 6. Class Interaction Prediction Results
No Attributes PI PII PIII
1 Not Predicting and Not Interacting 232 213 280
2 Predicting but Not Interacting 22 36 34
3 Not Predicting but Interacting 33 46 52
4 Predicting and Interacting 274 335 375
5 Completeness (%) 93 90 92
6 Correctness (%) 89 88 88
7 Kappa (κ) 0.838 0.802 0.816

Looking at the above results, the correctness and completeness values across three
projects indicate a high prediction value where more than ninety percent of class
interactions were predicted. The combination of the correctness and completeness
values indicates an ideal pattern of prediction (see Table 4). Through the κ value, the
overall class interaction prediction results produced by the approach show an almost
perfect strength of agreement (see Table 5) with actual class interactions for all projects.

5.2. Impact Analysis Results

There are two groups of impact analysis prediction results which are: prediction
without using impact prediction filters and; prediction with impact prediction filters.
Table 7 and Table 8 below show the prediction results.
Table 7. Impact Analysis without Impact Prediction Filters
PI PII PIII
No Attributes
CR#1 CR#2 CR#3 CR#1 CR#2 CR#3 CR#1 CR#2 CR#3
1 Not Predicting and Not Changed 21 12 16 11 20 15 20 22 19
2 Predicting but Not Changed 7 11 10 13 8 11 8 10 10
3 Not Predicting but Changed 0 0 0 0 1 0 0 0 1
4 Predicting and Changed 8 13 10 14 9 12 12 8 10
5 Completeness (%) 53.3 54.2 50 51.9 52.9 52.2 60.0 44.4 50.0
6 Correctness (%) 100 100 100 100.0 90.0 100.0 100.0 100.0 90.9
7 Kappa (κ) 0.470 0.497 0.444 0.463 0.427 0.474 0.575 0.343 0.399
 Table 8. Impact Analysis with Impact Prediction Filters
PI PII PIII
No Attributes
CR #1 CR #2 CR #3 CR #1 CR #2 CR #3 CR #1 CR #2 CR #3
1 Not Predicting and Not Changed 26 20 23 21 26 23 26 30 28
2 Predicting but Not Changed 2 3 3 3 2 3 2 2 1
3 Not Predicting but Changed 0 0 0 0 1 0 0 0 1
4 Predicting and Changed 8 13 10 14 9 12 12 8 10
5 Completeness (%) 80.0 81.3 76.9 82.4 81.8 80.0 85.7 80.0 90.9
6 Correctness (%) 100.0 100.0 100.0 100.0 90.0 100.0 100.0 100.0 90.9
7 Kappa (κ) 0.785 0.821 0.768 0.832 0.734 0.806 0.863 0.773 0.830

5.2.1. Prediction results without filtration guideline

Looking at the prediction results in Table VII, the correctness values indicate that all
the predicted actual interacting classes were actually interacting. For the completeness
values, it shows that more than half of the actual interacting classes were predicted. The
combination of the correctness and completeness values indicates an ideal pattern of
prediction (see Table 4). Through the κ value, the overall impact analysis prediction
produced by the approach has fair and moderate strength level of agreements (see
Table 5).

5.2.2. Prediction results with filtration guideline

Looking at the prediction results in Table 8, the correctness values indicate that almost
all the predicted impacted classes were actually changed (except CR#2 in P2 and CR#3
in P3). For the completeness values, it shows that more than half of the actual impacted
classes were predicted. The combination of the correctness and completeness values
indicates an ideal pattern of prediction (see Table 4). Through the κ value, the overall
impact analysis prediction produced by the approach shows a substantial and almost
perfect strength level of agreements (see Table 5).

5.3. Remarks

5.3.1. Class interaction prediction results

Looking at the prediction results in Table 6, the class interaction prediction stage gives
a substantial level of agreement between the prediction results and the actual results.
However, the results show there are still some false negative (Predicting but Not
Interacting) and false positive (Not Predicting but Interacting attribute) predictions. We
have conducted further analysis and found that there are two reasons for that. The first
reason is the inconsistency of BCE design strategy implementation by the software
developers. Even the basic rule says that there is no direct interaction or relationship
between boundary class and entity class, but we found that some of the interactions are
still against the rule. This could due to the massive amount of interactions that the
software developers have to deal with. The second reason is that the involvement of
technology-based class such as built-in library in the system implementation. Some of
these classes are required by the BCE classes in order to perform system functionalities.
The interaction between these classes has indirectly disturbs the implementation of
BCE class implementation pattern. Therefore, the false negative and false positive
results exist in our prediction results.
5.3.2. Impact analysis results
Looking at the prediction results in Table 7 and 8, it clearly shows that the impact
analysis with impact prediction filters improves the accuracy of the impact analysis
without the impact prediction filters. This situation clearly shows that the improvement
is made by the impact prediction filters through elimination of some false results. The
elimination of the false results can be seen through the decrement in the number of
Predicting but Not Changed value (false-positive) and increment in the number of Not
Predicting and Not Changed value (correct prediction).
A closer look at the number of Predicting but Not Changed values in Table 8 (all
change requests across three projects), it is visible that there are still some false results.
We have conducted further analysis and found that those false results are due to
inconsistency of BCE design strategy implementation by software developers. Even the
basic rule says that no interaction between boundary class and entity class is allowed,
but still some of the interactions are against the rule. The inconsistency interactions
were not detected by the approach which indirectly leads to the inaccurate results of
impact analysis.

6. Conclusion and Future Work

We have presented a new impact analysis approach that utilizes class interaction
prediction as a reflected model. There are two main stages of the approach which are:
(1) developing class interaction prediction from object interaction analysis and; (2)
conducting impact analysis using the class interaction prediction.
Also, we have introduced a new set of impact prediction filters as one of the main
element in the new approach. These filters aim to rule out some false prediction results
generated by the new approach. The filters are: (1) IPF#1: invalid interaction flow
filtration and; (2) IPF#2: Imported class filtration.
Three software projects were selected to provide an initial demonstration on the
practicality of the new approach. Evaluation results show that the new approach using
the impact prediction filters improves the accuracy of prediction results.
As for the future work, a comprehensive and thorough evaluation on the
application of the new approach in various software projects will be conducted.
Furthermore, this study also aims to develop supporting tools to facilitate the
implementation of the new approach in area of future work.

References

[1] S. Bohner and R. Arnold, "Impact Analysis - Towards a Framework for Comparison," Proc. of the
IEEE International Conference on Software Maintenance, 1993, IEEE Press, Sep. 1993, pp. 292-301.
[2] R. J. Turver and M. Munro, “An Early Impact Analysis Technique for Software Maintenance,” Journal
of Software Maintenance: Research and Practice, vol. 6, Aug. 1993, pp. 35–52.
[3] B. Breech, A. Danalis, S. Shindo, and L. Pollock, “Online Impact Analysis via Dynamic Compilation
Technology,” Proc. of the 20th IEEE International Conference on Software Maintanence, IEEE Press,
Sept. 2004, pp. 453- 457.
[4] J. Law and G. Rothermel, “Incremental Dynamic Impact Analysis for Evolving Software Systems,”
Proc. of the 14th International Symposium on Software Reliability Engineering, IEEE Press, Nov.
2003, pp 430.
[5] A. Orso, T. Apiwattanapong, and M. J. Harrold, “Leveraging Field Data for Impact Analysis and
Regression Testing,”. Proc. of the 9th European Software Engineering Conference held jointly with
11th ACM SIGSOFT International Symposium on Foundations of Software Engineering, IEEE Press,
Sept. 2003, pp. 128 – 137.
[6] K. H. Bennet and V.T. Rajlich, "Software Maintenance and Evolution: a Roadmap,". Proc of the
International Conference on the Future of Sofware Engineering, ACM Press, June 00, pp. 73-87.
[7] Y. Li, J. Li, Y. Yang and L. Mingshu, "Requirement-centric Traceability for Change Impact Analysis:
A Case Study," in Making Globally Distributed Software Development a Success Story, vol.
5007/2008, Springer Berlin / Heidelberg, 2008, pp. 100-111.
[8] J. Hassine, J. Rilling, J. Hewitt and R. Dssouli, “Change Impact Analysis for Requirement Evolution
using Use Case Maps," Proc. of the 8th International Workshop on Principles of Software Evolution,
IEEE Press, Sept. 2005, pp. 81-90.
[9] M. Shiri, J. Hassine and J. Rilling, “A Requirement Level Modification Analysis Support Framework,"
Proc. of the 3rd International IEEE Workshop on Software Evolvability, Oct 2007.
[10] N. Kama, T. French, M. Reynolds, "Predicting Class Interaction from Requirement Interaction," Proc.
of the 13th IASTED International Conference on Software Engineering and Application, ACTA Press,
Nov. 2009, pp. 30-37. Available at: http://www.csse.uwa.edu.au/~nazri/IASTED-SEA2009.pdf
[11] N. Kama, T. French, M. Reynolds, "Predicting Class Interaction from Requirement Interaction:
Evaluating a New Filtration Approach," The IASTED International Conference on Software
Engineering., in Press. Available at: http://www.csse.uwa.edu.au/~nazri/IASTED-SE2010.pdf
[12] Y. Liang, “From Use Cases to Classes: A Way of Building Object Model with UML”, Journal of
Information and Software Technology, vol 45, Sept 2002, pp. 83–93.
[13] R. C. Sharble and S.S Cohen, “The Object-oriented Brewery: A Comparison of Two Object-oriented
Development Methods,”. Software Engineering Notes, ACM Press, vol 18, Apr 1993, pp. 60-73.
[14] J. Premerlani, J. Rumbaugh., M. Eddy and W. Lorensen, Object-Oriented Modeling and Design.
Englewood Cliffs, NJ, Prentice-Hall, 1991.
[15] A. G. Dahlstedt and A. Persson, “Requirements Interdependencies - Moulding the State of Research
into a Research Agenda”. Proc. of the Ninth International Workshop on Requirements Engineering:
Foundation for Software Quality in conjunction with CAiSE 2003, June 2003, pp. 55-64.
[16] M. Lindvall and K. Sandahl, "How Well Do Experienced Software Developers Predict Software
Changes," Journal of Systems and Software, vol. 43, Oct 1998, pp. 19-27.
[17] G.C. Murphy and D. Notkin, “Alternative Approaches to Software Maintenance,” Tutorial held at
International Conference on Software Maintenance 1996.
[18] J. Cohen, "A Coefficient of Agreement for Nominal Scales," Journal of Educational and Psychological
Measurement, vol. 20, Apr. 1960, pp. 37-46.
[19] J. R. Landis and G.G. Koch, "The Measurement of Observer Agreement for Categorical Data," Journal
of Biometrics, vol. 33, Mar. 1977, pp. 159-174.
[20] G. Spanoudakis, E. P. Minana and P. Krause, "Rule-based Generation of Requirements Traceability
Relations," Journal of Systems and Software, vol. 72, pp. 105–127, 2004.