Information Systems: Khubaib Amjad Alam, Rodina Ahmad, Adnan Akhunzada, Mohd Hairul Nizam MD Nasir, Samee U. Khan

Information Systems 54 (2015) 43–73
Contents lists available at ScienceDirect
Information Systems
journal homepage: www.elsevier.com/locate/infosys
Impact analysis and change propagation in service-oriented

enterprises: A systematic review
Khubaib Amjad Alam a, Rodina Ahmad a, Adnan Akhunzada b,n,
Mohd Hairul Nizam Md Nasir a, Samee U. Khan c
a
Department of Software Engineering, Faculty of Computer Science and Information Technology, University of Malaya, Kuala Lumpur,
Malaysia
b
Centre for Mobile Cloud Computing Research (C4MCCR), Faculty of Computer Science and Information Technology, University of Malaya,
50603 Kuala Lumpur, Malaysia
c
Department of Electrical and Computer Engineering, North Dakota State University, Fargo, ND 58108-6050, United States
a r t i c l e i n f o abstract
Article history: Context: The adoption of Service-oriented Architecture (SOA) and Business Process
Received 27 April 2015 Management (BPM) is fairly recent. The major concern is now shifting towards the
Received in revised form maintenance and evolution of service-based business information systems. Moreover,
3 June 2015
these systems are highly dynamic and frequent changes are anticipated across multiple
Accepted 4 June 2015
levels of abstraction. Impact analysis and change propagation are identified as potential
Recommended by: D. Shasha
Available online 16 June 2015 research areas in this regard.
Objective: The aim of this study is to systematically review extant research on impact
Keywords: analysis and propagation in the BPM and SOA domains. Identifying, categorizing and
SOA
synthesizing relevant solutions are the main study objectives.
BPM
Method: Through careful review and screening, we identified 60 studies relevant to 4
Web service
CIA research questions. Two classification schemes served to comprehend and analyze the
Dependency analysis anatomy of existing solutions. BPM is considered at the business level for business operations
Semantic annotation and processes, while SOA is considered at the service level as deployment architecture. We
MSR focused on both horizontal and vertical impacts of changes across multiple abstraction layers.
Change propagation Results: Impact analysis solutions were mainly divided into dependency analysis, traceability
SOC analysis and history mining. Dependency analysis is the most frequently adopted technique
Systematic literature review (SLR)
followed by traceability analysis. Further categorization of dependency analysis indicates that
graph-based techniques are extensively used, followed by formal dependency modeling.
While considering hierarchical coverage, inter-process and inter-service change analyses have
received considerable attention from the research community, whereas bottom-up analysis
has been the most neglected research area. The majority of change propagation solutions are
top-down and semi-automated.
Conclusions: This study concludes with new insight suggestions for future research. Although,
the evolution of service-based systems is becoming of grave concern, existing solutions in this
field are less mature. Studies on hierarchical change impact are scarce. Complex relationships
of services with business processes and semantic dependencies are poorly understood and
require more attention from the research community.
& 2015 Elsevier Ltd. All rights reserved.
n
Corresponding author.
E-mail addresses: khubaibalam@siswa.um.edu.my (K.A. Alam), rodina@um.edu.my (R. Ahmad), a.adnan@siswa.um.edu.my (A. Akhunzada),
hairulnizam@um.edu.my (M.H.N.M. Nasir), samee.khan@ndsu.edu (S.U. Khan).
http://dx.doi.org/10.1016/j.is.2015.06.003
0306-4379/& 2015 Elsevier Ltd. All rights reserved.
44 K.A. Alam et al. / Information Systems 54 (2015) 43–73
Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2. Research method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.1. Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.2. Data sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.3. Search terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4. Study selection procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.5. Inclusion and exclusion criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.6. Quality assessment criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.7. Data extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.8. Demographic data and overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3. Discussion and results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1. Change impact analysis in service-based systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1.1. Dependency-based impact analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1.2. History mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.3. Traceability analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2. Change propagation in service-based systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3. Order processing scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4. Hierarchical coverage of change analysis and propagation techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.5. Changes across business and service levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.5.1. Business level changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5.2. Service level changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.6. Dependencies across the business process and service level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.6.1. Business level dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.6.2. Service level dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.7. Change analysis and propagation techniques at the business level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.7.1. Inter-process impact analysis and propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.7.2. Top-down impact analysis and propagation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.8. Impact analysis and propagation techniques for service level changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.8.1. Bottom-up impact analysis and propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.8.2. Inter-service impact analysis and propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.9. Analysis of service-based CIA and propagation techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.10. Principal findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.11. Future research implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.12. Threats to validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Conflict of interests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
1. Introduction
anomalies [72]. Therefore, process flexibility and change are
The complementary relationship between Service- deemed of crucial concern in the Business Process Manage-
Oriented Architecture (SOA) and Business Process Manage- ment (BPM) domain [15]. Adaptive business process man-
ment (BPM) has paved the way for organizations to agement systems [67] and version management of business
become more competitive while automating processes processes [92] are relevant areas of change management in
and systems across business lines. Services and supporting this regard; however, our focus is specifically on impact
business processes are inherently dynamic. Therefore, analysis and propagation of business process changes. From
flexibility to accommodate different functional, structural, Service Oriented Architecture (SOA) point of view, services
regulatory and technological changes is considered crucial are also subject to constant changes and modifications.
in business environments.
Change management in service-based environments and
Business Process Models is an emerging research area Table 1
entailing numerous nontrivial issues and problems [77,81]. Electronic databases.
Process models are mainly used in the earlier system
development stages and are equally clear to both software Identifier Database URL
engineers and the business community. These models are ED1 ACM http://dl.acm.org/
always prone to different kinds of changes, such as new ED2 IEEE Xplore http://ieeexplore.ieee.org/
regulatory laws, changes in business policies or strategies, or ED3 Science Direct http://sciencedirect.com/
emerging technologies. Without proper control, such ED4 Springer Link http://link.springer.com/
ED5 Wiley http://onlinelibrary.wiley.com/
changes to process models may have disruptive effect on
ED6 Emerald Insight http://www.emeraldinsight.com/
the overall system due to structural, functional or qualitative
K.A. Alam et al. / Information Systems 54 (2015) 43–73 45
Changes can originate from functional requirements, policy (e) Identifying particular areas of research that lack atten-
constraints, and behavioral attribute alterations, and can lead tion from the scientific research community.
to exhaustive service redesign and improvement. Without
adequate control, such changes can also disrupt overall This paper is organized as follows. Section 2 describes the
system functionality and performance [1]. A change in a review strategy and process. Section 3 provides detailed
business process would cause changes in underlying services discussion and results. Finally, the paper is concluded in
supported by that business process. Similarly, a change in a Section 4 followed by a list of acronyms in Section 5.
service would lead to changes in its supporting business
process and other services supported by that business
process [79]. Therefore, it is important to estimate the effect 2. Research method
of a proposed change on the overall system (CIA) and how
that change can be propagated efficiently to transfer its effect A systematic literature review (SLR) is aimed at identi-
with minimum disruption to the system (change fying, evaluating and interpreting all available research
propagation). related to a particular field of interest. An SLR must be
This study contributes in the following ways: accomplished with a rigorous search plan that is fair and
unbiased. The search strategy or plan must ensure the
(a) A comprehensive systematic review on change analy- completeness of the search for assessment [20]. At the
sis and propagation in service-oriented enterprises. time of this report, there was no systematic study that
(b) Identifying changes and dependencies across different provided a rigorous review and analysis of most existing
abstraction layers. research in this domain. Our aim is to fill this gap by
(c) Classifying change analysis and propagation techni- conducting an SLR using Kitchenham's methodology [20].
ques in two dimensions. The current systematic review process comprises several
(d) Analyzing and synthesizing existing research works in steps that must be performed in a systematic and disciplined
this domain. way, including developing a review protocol, conducting a
Fig. 1. Study selection procedure.

Table 2
Inclusion and exclusion criteria for SLR.
Inclusion and exclusion criteria
Inclusion criteria
IC1 Articles that are peer reviewed
IC2 Articles introducing any procedures/techniques for change impact analysis or propagation in context of business processes or web services
IC3 Articles identifying dependencies in the context of business processes or web services
IC4 Novelty and total relevance will be considered in case of no validation.
IC5 Inclusion of most recent article in case of multiple studies on same theme
IC6 Inclusion of Automated or semi-automated techniques only
Exclusion criteria
EC1 Studies other than English language
EC2 Articles proposing CIA techniques for traditional systems and Environments
EC3 Studies with no validation of proposed techniques or validation solely through expert opinion
EC4 Articles providing unclear results or findings
Table 3 2.2. Data sources

Quality assessment criteria for SLR.
Six electronic databases were considered as primary
QC1 Context and environments are specific and clearly stated
data sources for potentially relevant studies. Google Scho-
QC2 Research design support aims and contexts of study lar was not included in the list due to low precision results
QC3 Goals and objectives are clearly defined and overlapping of results from other data sources. The
QC4 Contributions and limitations are clearly stated electronic databases used in the search process are listed
QC5 There is a minimal biasness in the study
in Table 1.
2.3. Search terms
The following search terms are based on major terms

identified from research questions and relevant literature.
These terms were defined to search relevant articles from
the electronic databases listed in Table 1. A combination of
different search terms was used in an effort to obtain all
available research in this area. Several concepts interrelate,
e.g. change impact analysis, dependency analysis and
change propagation. Because these represent interrelated
activities, all of these terms must be used.
Fig. 2. Proportion of selected studies.
(1) “Change analysis” OR “Impact analysis” OR “depen-

dency analysis” OR “traceability analysis” OR
systematic review, analyzing the results, reporting and
propagation
visualizing the results, and discussing the findings.
(2) Change
(3) Dependenc*
(4) “Business process” OR “Process model” OR workflow
2.1. Research questions
(5) Service-oriented OR service-based OR service-centric
OR “Service Oriented”
The primary research question of this SLR is: “What is
the state-of-the-art in change analysis and propagation in
SOA and BPM-based environments?” This primary ques- These search terms were combined into a search string
tion is divided into four RQs. using the conjunction (AND) and disjunction (OR) opera-
tors. The resulting search string for the automated search
RQ1: What type of changes can be anticipated at the is given below:
business process or service level?
RQ2: What kinds of dependencies are found at the ((“Change analysis” OR “Impact analysis” OR “depen-
business process and service level? dency analysis” OR “traceability analysis” OR propaga-
RQ3: What are the available impact analysis and tion OR change OR dependenc*) AND (“Business
propagation solutions at the business level? process” OR “Process model” OR workflow OR
RQ4: What are the available impact analysis and Service-oriented OR service-based OR service-centric
propagation solutions at the service level? OR “Service Oriented”))
Table 4
Demographic data and overview of the selected studies.
Identifier Reference Citation count Avg. citations count/year RQ1 RQ2 RQ3 RQ4
S1 [81] 12 4 ✗ ✗ ✓ ✗
S2 [10] 9 1.5 ✓ ✓ ✓ ✗
S3 [17] 1 0.5 ✓ ✗ ✗ ✗
S4 [25] 5 1 ✗ ✗ ✓ ✗
S5 [30] 0 0 ✗ ✓ ✓ ✗
S6 [18] 1 0.16 ✗ ✗ ✓ ✗
S7 [31] 1 0.5 ✗ ✓ ✓ ✗
S8 [35] 7 2.33 ✗ ✓ ✓ ✗
S9 [51] 2 1 ✗ ✗ ✓ ✗
S10 [55] 14 3.5 ✗ ✗ ✓ ✗
S11 [85] 32 4 ✗ ✗ ✓ ✗
S12 [43] 3 1.5 ✗ ✗ ✓ ✗
S13 [19] 17 2.4 ✗ ✓ ✗ ✗
S14 [88] 3 3 ✗ ✓ ✗ ✗
S15 [73] 14 3.5 ✓ ✓ ✓ ✗
S16 [22] 11 2.75 ✗ ✗ ✓ ✓
S17 [64] 14 2.33 ✗ ✗ ✓ ✗
S18 [49] 23 7.6 ✗ ✗ ✓ ✗
S19 [11] 7 1.4 ✗ ✗ ✓ ✗
S20 [32] 1 0.5 ✗ ✗ ✓ ✗
S21 [42] 22 11 ✓ ✗ ✗ ✗
S22 [44] 4 2 ✗ ✗ ✓ ✗
S23 [60] 13 1.8 ✗ ✗ ✓ ✗
S24 [79] 7 2.33 ✓ ✗ ✓ ✓
S25 [9] 2 1 ✗ ✗ ✓ ✗
S26 [14] 9 2.25 ✗ ✗ ✓ ✗
S27 [63] 11 2.2 ✗ ✗ ✗ ✓
S28 [41] 7 1.75 ✓ ✗ ✗ ✓
S29 [46] 1 0.25 ✓ ✗ ✗ ✓
S30 [59] 0 0 ✗ ✗ ✓ ✓
S31 [24] 2 1 ✗ ✗ ✗ ✓
S32 [54] 54 13.5 ✓ ✗ ✗ ✗
S33 [61] 2 0.5 ✗ ✗ ✗ ✓
S34 [65] 15 1.87 ✗ ✗ ✗ ✓
S35 [69] 0 0 ✗ ✗ ✗ ✓
S36 [70] 22 3.66 ✓ ✗ ✗ ✓
S37 [75] 38 6.33 ✗ ✓ ✗ ✓
S38 [76] 4 1 ✗ ✗ ✗ ✓
S39 [57] 5 1.6 ✗ ✗ ✗ ✓
S40 [82] 11 2.2 ✗ ✓ ✗ ✗
S41 [62] 91 13 ✗ ✗ ✗ ✓
S42 [80] 344 49.1 ✓ ✗ ✗ ✗
S43 [91] 0 0 ✗ ✓ ✗ ✓
S44 [7] 0 0 ✗ ✓ ✓ ✗
S45 [93] 24 3.42 ✗ ✓ ✗ ✗
S46 [52] 13 2.16 ✗ ✓ ✗ ✓
S47 [12] 0 0 ✗ ✗ ✓ ✗
S48 [45] 15 2.5 ✗ ✗ ✓ ✗
S49 [13] 21 5.25 ✗ ✗ ✓ ✗
S50 [16] 1 1 ✗ ✗ ✓ ✗
S51 [89] 23 2.87 ✗ ✗ ✗ ✓
S52 [86] 12 4 ✗ ✗ ✗ ✓
S53 [33] 4 0.5 ✗ ✗ ✗ ✓
S54 [28] 0 0 ✗ ✗ ✗ ✓
S55 [74] 5 1 ✗ ✗ ✗ ✓
S56 [3] 38 5.42 ✗ ✗ ✗ ✓
S57 [71] 0 0 ✗ ✗ ✓ ✗
S58 [90] 2 0.33 ✗ ✗ ✓ ✗
S59 [8] 1 0.5 ✗ ✗ ✓ ✗
S60 [29] 13 6.5 ✗ ✗ ✓ ✗
Data Dependency
Analysis
Dependency Control Flow

Analysis Dependency Analysis
Component
Dependency Analysis
Change Impact Anlaysis
Requirement
Traceability
Software
Traceability
Documentation
Analysis
traceability
Project Information
Database
Traceability
Fig. 3. Types of change impact analysis in traditional software systems.
In addition, certain keywords have been used to filter number of articles and, final selected articles from each
out results from databases. These keywords include SOA, electronic source listed in Table 3.
BPM, CIA, SOC and Web service.
2.6. Quality assessment criteria
2.4. Study selection procedure
The quality assessment process was performed during
The study selection procedure of our systematic review the 3rd phase of the study selection. The inclusion/exclu-
is visualized in Fig. 1. This process comprises 3 phases, sion along with quality assessment criteria were applied to
each of which was accomplished by a thorough consensus the articles filtered in the 2nd phase. Four researchers
meeting to ensure additional confidence and minimal bias received 104 articles. Each article was scrutinized by 2
in the study selection process. reviewers to remove bias. A scale of 1–5 served as the
quality fulfillment criteria. From a rigorous review and
screening, 60 papers were selected by the joint application
2.5. Inclusion and exclusion criteria
of inclusion/exclusion and QA criteria on the full text of
104 research articles. This ensured additional confidence
Inclusion and exclusion criteria were used to select
in the selected articles. The quality assessment criteria are
potentially relevant studies from data sources to answer
listed in Table 3.
the research questions in our SLR. These criteria were
applied to all studies retrieved in the different phases of
the study selection procedure (Fig. 1). The time period for 2.7. Data extraction
the search was defined from January 2007 to December
2014 to ensure that only recent, up-to-date articles were All articles selected after phase 2 were analyzed by the
included. Early Cite articles were also included, provided review team. The full text of each article was analyzed by
the full text was available. The inclusion and exclusion at least two researchers. Relevant information was
criteria employed in our SLR are listed in Table 2. extracted to a predefined data extraction form. This form
These criteria were applied to the 2nd and 3rd phases comprised of the following list of items.
of the present study selection procedure. The 2nd phase
considered inclusion/exclusion based on the abstracts and (1) Title
conclusions. Finally, 104 out of 225 articles were filtered (2) Publication venue
through the 2nd phase. The 3rd phase considered inclu- (3) Publication year
sion and exclusion of studies on the basis of the inclusion (4) Level (Business Process OR Service Level)
and exclusion criteria in Table 2 and quality attributes in (5) Technique
Table 3. Both criteria were applied in parallel to full texts of (6) Empirical research method (experiment, case study,
all 104 articles. A total of 60 articles were selected for the survey, other)
final list. Fig. 2 shows the proportions between the initial (7) Research questions being addressed
Historical Graph-based
Analysis Analysis
Traceability
Analysis Execution
Trace anaysis
Change analysis
and propagation solutions in
Service-based BPMS
Formal
specification
Change
Propagation
Quantitative
Analysis
Fig. 4. Classification according to the type of analysis and support.
(8) Classification (according to predefined classification response to the changes. Change propagation mechanisms
schema) recommend further changes to affected entities to main-
(9) Focus of study tain overall consistency after actual proposed change
(10) Contribution (Method, Model, Framework, implementation. Change propagation is a labor-intensive
Tool, other) and error-prone process [21]. Inter-related activities of
change impact analysis and propagation have been widely
investigated in the context of traditional software
2.8. Demographic data and overview environments.
Before reporting the results from the analysis and

3.1. Change impact analysis in service-based systems
synthesis of data from the selected studies, the demo-
graphic information and an overview of these studies are
Traditional source code and model-based CIA techni-
initially reported. Table 4 provides an overview of each
ques for centralized applications are not compatible with
selected study along with demographic information.
distributed systems. The recent widespread adoption of
BPM and SOA-based systems demand a focus shift towards
3. Discussion and results
heterogeneous distributed environments, which have
unique requirements for their maintenance and evolution.
Change impact analysis (CIA) is performed to analyze
Specialized impact analysis techniques are necessary in
and assess the ripple effect of a change in software
this regard. We have identified recurring use of certain CIA
systems. CIA techniques are used to predict such ripple
techniques (Fig. 4), which are briefly discussed next.
effects before initiating or implementing a proposed
change. They help evaluate how far a planned change
can reach, and how other system components will be 3.1.1. Dependency-based impact analysis
affected. Significant literary work in this area was pre- Dependency analysis is an effective technique in soft-
sented by Bohner [5], who classified CIA techniques into ware change impact analysis (CIA). Dependency relation-
two main categories: dependency analysis and traceability ships among artifacts are typically depicted as dependency
analysis (Fig. 3). graphs or tables. Dependency graphs typically consist of
Dependency analysis concerns the automatic detection nodes and edges, where nodes represent entities (artifacts)
of dependency information by utilizing dependency ana- while edges represent relationships among those entities
lysis tools. This activity is usually performed at the source [5]. Identifying dependencies in service-based systems is
code level, while traceability analysis involves manual essential for adequate system management. Poor under-
work, e.g. dependency modeling and documentation. standing of such dependencies may lead to higher main-
Traceability analysis is usually performed at the require- tenance costs and catastrophic effects on business
ment and design level. operations. On the other hand, dependency analysis in
Change propagation addresses the issue of how to workflow and service-oriented environments is challen-
effectively transfer the effect of a change with minimal ging, as dependency relationships exist in a distributed
ripple effect on other entities, or what additional changes and heterogeneous environment. The identification and
will be required for a software system to maintain con- analysis of dependencies became more challenging in such
sistency. Whenever some new features are added or environments compared to traditional monolithic soft-
modified in software systems, developers must ensure ware systems. Dependency analysis approaches in
that other system entities are updated and consistent in service-based systems can be further categorized into
graph-based analysis, formal specification, quantitative on change impact metrics is confined to object oriented
analysis, or execution trace analysis. (OOP), aspect oriented (AOP), software product lines (SPL)
and model driven development (MDD) paradigms. Ripple
3.1.1.1. Graph-based analysis. Directed graphs are exten- effect metric which measures the impact of changes to the
sively used for dependency analysis in traditional software rest of the system, is undoubtedly one of the most famous
systems. However, if extended, they are equally effective in metrics in context of change impact analysis [4]. In addi-
capturing dependencies in service-based systems. These tion to basic object oriented change impact metrics,
graphs generally consist of nodes and edges that represent method impact level (MIL), class impact level (CIL) and
artifacts and their dependencies. Graph traversal (reac- system impact level (SIL) metrics have been proposed to
hability analysis) is performed in order to compute the quantify the impact of changes at method level, class level
impact set on these dependency graphs [40]. and system level [37]. A metric suit extension of famous
Control Flow Graphs (CFG) and call graphs are the most C&K metrics, aims at quantification of attributes related to
commonly adopted graphical tools used for impact analy- change implementation in software systems [47]. The four
sis. A CFG visualizes all traversal paths that may be subsets of this extension include complexity, impact, depen-
adopted during the execution of the program [7]. Call dence and inheritance metrics to quantify and measure
graphs visualizing the calling behavior of the system, are change implementation attributes. Concentration (C), Dis-
generated by extracting method calls through Static code persion (D) and Inclusion (I) metrics have also been used to
analysis techniques [38]. In traditional software environ- quantify the change impact at architectural level [27].
ments, we observe extensive use of CFGs and their variants However, as mentioned earlier, service oriented appli-
including control call graphs (CCG), component control cations have their unique requirements for impact analy-
flow graphs (CCFG), and Inter-procedural component con- sis; we cannot simply map existing metrics of other
trol flow graph (ICCFG) [23]. However simple directed paradigms to these applications. Only few studies have
graphs need to be extended to represent different kinds emphasized on quantification of change impact in context
of dependencies in BPM, SOA environments. So in these of SOA and BPM environments. For business process
domains different variants of directed graphs have been changes, a basic change impact metric [85] tries to
used e.g. process graph [7], data and control dependency quantify the impact of proposed changes. Priority, execu-
graph [84], message dependency graph [3,61], trust tion frequency and invocation frequency metrics have been
dependency graph [59], directed hypergraph [91] etc. used by [30] to calculate impact weighted factor (IWF) for
dependencies between business processes and service
3.1.1.2. Formal specification. Formal mathematical foun- layer entities. A set of three metrics by [59] tries to
dations are essential for dependency analysis of service- quantify the impact of evolutionary change to the trust
based systems. Change identification and modeling must of composite services. Another set of five change impact
be backed by formal methods for adequate understanding metrics by [75] consists of Intra-Relation, Intra-
and processing. Through formal modeling, semantics can be Dependency, Inter-Relation, Inter-Dependency and cohesion
added to the description of changes in a machine- metrics to quantify web service change impact. They have
processable way [78,87]. Ontologies and semantic ann- also used symmetrical effect [76] to estimate the disorder
otations help in capturing semantics of process models caused by changes to model elements. Finally, business
and Web services [87]. This formalization is essential for impact of web service changes is quantified in terms of
further validation of changes. financial loss [63].
Conventional process modeling languages such as Busi-
ness Process Model Notation (BPMN), activity diagrams 3.1.1.4. Execution trace analysis. Execution trace analysis
and Event-driven Process Chains (EPCs) are largely being mainly relies on information retrieved during program
used by enterprises. However these specifications suffer execution. This type of analysis falls under dynamic
from lack of analytical capabilities [73]. To bridge this gap, change impact analysis (CIA), which can be performed
various tools for formal specification of business processes on-the-fly (online) or after program execution (offline)
and services have been utilized including petri nets [40]. Execution trace analysis is significant, as it can reveal
[19,41,66], regular tree grammar [49], metagraphs [2], actual dependencies between artifacts, from real world
ontological specifications and semantic annotations data. Unlike other dependency analysis techniques, this
[8,12,29,31,33,36,41], Kleen algebra [18], first order logic approach focuses on dynamic dependencies existing
[73,91], PI Calculus [58], finite state machine [62], alloy between artifacts of service-based systems. This type of
[11], prolog [10,48] and process algebra [83]. analysis is mostly used in conjunction with graph-based
analysis and formal descriptions to represent and visualize
3.1.1.3. Quantitative analysis. Change impact quantification dynamic dependencies among artifacts.
utilizes metrics to quantify the depth of change. Such The dynamic behavior and dependencies of SOA artifacts
analysis can be invaluable for decision-making and can be unfolded by execution trace analysis. In business
problem solving in service-based systems [34]. These process execution logs, each trace provides a sequence of
approaches are mostly used in conjunction with other events related to a specific execution case [16]. Service
dependency analysis approaches. execution data is crucial as it can reveal message exchange
Although there exists a plethora of research studies on correlations among services. However execution trace ana-
software metrics, but change impact metrics have received lysis in service-based systems is extremely challenging due
lesser attention in this regard. Most of the existing work to the distributed and heterogeneous nature of such systems
Fig. 5. Order processing process.
Fig. 6. Business process model of order processing.
Waive
shipment
fee
Reduce
Check
Amount
voucher
Payable
Get Include
Shipment shipment
address fee
Fig. 7. Sub-process to calculate total amount.
involving different software, hardware architectures, proto- techniques identify processes or services that have been
col implementations and unstructured service execution frequently changed simultaneously. Such information from
data [3]. change logs or version histories is used to predict the
impact of future changes.
3.1.2. History mining Although MSR techniques for traditional software sys-
History mining leverages Mining Software Repositories tems have demonstrated significant potential as an appli-
(MSR) techniques to uncover historical co-change depen- cation for impact analysis [26], we have seen very few
dencies [12,40,94]. This approach primarily focuses on studies utilizing them in service oriented environments. In
version histories of process models and Web services. this context, MSR techniques have been applied for pro-
Co-change patterns exist in the version histories of process cess model repositories [12], Web service ecosystems [28]
model repositories and Web service ecosystems. These and process choreographies [16]. Several process model
repositories utilize traditional version control systems 3.3. Order processing scenario
(Subversion, CVS) for versioning. In such case, co-change
patterns are identified through commit logs of these A realistic order processing scenario (Fig. 5) of an online
systems. However in the absence of these version control store is used as an example to elaborate dependencies
systems, Dam and Ghose [12] has suggested to use sliding across different layers, including higher-level business
windows mechanism, or examination of release logs to processes to component services at the application level.
identify the simultaneously changed processes. In fact, changes may occur at any level with effects
potentially confined to the same hierarchy or which may
propagate to all abstraction layers.
At higher levels, a business process model in BPMN 2.0
3.1.3. Traceability analysis defines the execution order of different activities involved
Traceability helps track the relationships between busi- in this business process (Fig. 6). Different modeling lan-
ness requirements and underlying solution artifacts, e.g. guages can be used to model this higher-level abstraction;
source code [68]. The relationships between design and however, Business Process Model Notation (BPMN) is the
solution artifacts can be tracked both automatically and prevailing standard in industry. Business processes can
manually. Traceability links are often used to capture the also be visualized through event-driven process chain
relationships among artifacts across multiple abstraction (EPC) diagrams, UML activity diagrams and petri nets.
layers [38]. The scope of this study allows only for automated Several types of dependencies may exist between ele-
or semi-automated impact analysis approaches, thus manual ments of a single process model or between multiple
traceability mechanisms are not considered. Existing litera- models in a process model repository. In a broader sense,
ture categorizes traceability into vertical and horizontal control flow and data flow dependencies exist between
traceability [6,56]. Vertical traceability refers to the relation- various process model elements. RQ2 provides a detailed
ships between artifacts at distinct levels of abstraction and description of the dependency relationships. Activity
can be further categorized into forward traceability, back- dependencies within this process are easy to figure out,
ward traceability and bi-directional traceability [68]. Trace- e.g. the “receive payment” activity is directly dependent on
ability analysis in service-based systems is a challenging task the “check credit” activity. Similarly, “verify payment
due to the distributed nature of SOA and loose coupling method” depends on the sub-process “calculate final
among artifacts. As changes are likely to emerge from both amount”. This sub-process is further elaborated in Fig. 7.
business and service provider ends, bi-directional traceability All activities in this process must be executed prior to
solutions are desirable in such systems. However, very few executing “verify payment method”. This sub-process com-
studies have addressed traceability in service-oriented envir- prises five activities; however, there is an exclusive gate-
onments. Selected primary studies on traceability-based way, which means control flow will follow one particular
impact analysis have been analyzed in Table 7. direction depending on condition fulfillment. For example,
the store's policy is to waive the shipping fee if the order
amount exceeds 75$. However, if the order is below the
prescribed amount, a shipping fee will be added to the
3.2. Change propagation in service-based systems total amount. This shipping fee depends on the delivery
location, so “include shipment fee” activity is directly
Change propagation is widely considered a major dependent on the “get shipment address” activity.
application of change impact analysis (CIA). These two Suppose that initially, the store had a fixed cost for
activities are inter-related, as impact analysis is done prior shipping across Malaysia, but shipping partners have
to implementation while propagation is done during the increased shipment fees to East Malaysia. This new busi-
implementation of incremental changes [40]. Change pro- ness requirement must be accommodated in the existing
pagation is viewed as a critical issue in the evolution of process model. For this purpose, a new activity, “get
service-based systems. Propagation solutions mainly sug- shipment address” is introduced in the sub-process “calcu-
gest what additional change implementations are needed late final amount” (Fig. 7). This activity, determines
as a result of a primary change [11]. Consistency preserva- whether a particular order belongs to East Malaysia or
tion across different levels of Business Process Manage- Peninsular Malaysia. Then the shipment fee is included as
ment (BPM) and Service-oriented Architecture (SOA) can a per-new-shipment policy. This change in business
be regarded as the prime objective of change propagation. requirement only affects a particular sub-process. How-
These solutions can provide automated or semi-automated ever, business process changes are not always simple. As
support for change propagation. Semi-automated solu- another example, if a particular item is out of stock in the
tions require interaction with maintainers, while auto- company's warehouse, the company decides to arrange
mated solutions do not require manual help to propagate items for a buyer through a third party supplier. Third
changes. Change propagation support can either be for- party suppliers require advance payments for item deliv-
ward (higher-level design elements, requirements for eries, so cash-on-delivery is no longer an option for buyers.
lower-level design elements, implementations), backward In this case, the company must update multiple business
(lower-level models, implementations to higher-level rules and activities to accommodate the new requirement.
design element requirements) and bi-directional change In addition to adding new activities to interact with
propagation. These solutions support different kinds of suppliers, existing activities would also need to reflect this
change operations or patterns. change, e.g. the “verify payment” activity will direct buyers
Fig. 8. Abstract services and their relationships at composite service level.
Fig. 9. Component services and their relationships at component service level.
in a fixed direction. Moreover, third party suppliers may and shipment services. These services integrate sets of com-
not be willing to accept discount vouchers, so “check ponent services to accomplish certain business tasks, such as
voucher” and “reduce amount payable” would also need payment processing [53]. Service interaction is realized
to be changed in this scenario. This example signifies how through a message-passing mechanism, whereby a message
a change in business or regulatory requirements may have flow from an abstract service to another highlights the
a chain effect on other dependent activities. dependency relationship between them. As highlighted in
To execute this business process, five composite services Fig. 8, an order service is invoked by customer service, which
have been defined, including customer, order, payment, invoice further invokes payment service after performing certain
Fig. 10. Classification according to hierarchical coverage.
order processing tasks. These dependencies can be deemed three incoming inter-dependence relationships with the
direct dependencies, and changes in a particular service may user account management, cash-on-delivery and internet
lead to further changes required to other dependent services. banking services. Here, the check credit service and E-
The correlation between such services is defined through receipt invoicing service have intra-dependence relation-
process description using particular service standards, e.g. ships. This example signifies that complex service relation-
Web Services Business Process Execution Language (WSBPEL) ships may exist in a service composition. The larger the
and Electronic business Extensible Markup Language (ebXML). dependence degree of a service is, the harder the change
Semantic correlation or mapping between services can also be would be. Moreover, a service change with a high depen-
defined through different standards like Web Ontology Lan- dence degree makes many dependent service operations
guage for Services (OWL-S) and Semantic Web Services unstable or obsolete. Knowledge about dependence rela-
Description Language (WSDL-S). tions helps quantify the impact of change and cost asso-
Services are the basic units of logical solutions and can ciated with a particular service change.
be defined and implemented as service components, Now we analyze how atomic service changes may
Representational State Transfer (REST) or Web services affect other services and business processes at higher
[61]. At the component service level, numerous services levels. In other words, Inter-Service and Bottom-Up change
are responsible for performing a specific task. Component effects are analyzed. Suppose Internet banking services are
services are autonomous components, either developed suspended daily from 12:00 A.M to 12:30 A.M for neces-
in-house or outsourced by third party solution providers sary maintenance operations, a phenomenon called service
[53]. However, these services have intra- and inter- outage. During such periods, service outage affects forth-
dependence relationships while part of a service composi- coming operations of dependent activities e.g. payment.
tion. Inter-dependence can be regarded as the basic Consequently, no payments are received through Internet
dependency relationship existing between a requested banking during this time, compelling buyers to use alter-
service and a service receiver of that request [50]. On the native channels of cash on delivery services. However,
other hand, intra-dependence relations of component significant disadvantages are associated with alternative
services are far more complex, with incoming inter- options, like promotional price deductions from the total
dependence relations of a service to outgoing inter- amount will not be available with cash on delivery. In the
dependence relations. worst case, if a third party supplier is providing items, cash
Fig. 9 illustrates the inter-dependence relations of on delivery will not be available and consequently, the
different component services involved in the service user will be unable to place an order until the service
composition of order processing business process. Here, outage is over.
the arrow represents the dependence directionality from Now, a question arising is what kind of impact analysis
source to target services. For instance, “Internet banking” solutions may be suitable in a particular scenario? As
service has an incoming inter-dependence relation with highlighted in Fig. 4, we have identified recurring use of
“check credit” service. The E-receipt invoicing service has specific CIA techniques for service-oriented architectures.
For changes across different SOA layers, there are be used for impact quantification in service-based systems.
various solutions ranging from graph-based dependency Very few change impact metrics have been identified in
analysis (S05, S09, S10, S11, S24, S30, S33, S37, S39, S43, this regard. However, metrics identified in Section 3.1.1.3
S44, S46, S47, S48, S55, S56), to formal modeling (S02, S06, can be used for specific types of changes across different
S07, S15, S18, S23, S27, S31, S34, S40, S41, S53, S59, S08), layers of abstraction.
quantitative analysis (S10, S11, S37, S38, S52), execution The majority of existing work on traceability-based
trace analysis (S33, S34, S35, S39, S41, S56) and traceability impact analysis attempts to establish and locate traceabil-
analysis (S04, S16, S17, S22, S57, S58, S60). ity links between some elements in one layer of abstrac-
Dependency-based impact analysis techniques have tion and corresponding elements from other abstraction
been more widely adopted for service-based systems layers [40]. Such an analysis employs traceability links
compared to traceability analysis or historical co-change among system artifacts at different abstraction layers.
analysis. Different variants of dependency analysis solu- These links can be aggregated in the form of a traceability
tions may be suitable for different types of dependencies. graph that can serve to facilitate change propagation [38],
Graph-based approaches and formal dependency model- for example, traceability between higher-level models to
ing have been widely utilized in this regard. Dependency lower-level models, or traceability between business pro-
analysis solutions have been successfully implemented for cesses and corresponding services. In this sense, trace-
both process level dependencies (inter-process, intra-pro- ability analysis is feasible for inter-layer relationships
cess) and service level dependencies (inter-dependence, among asymmetrical artifacts. CIA for symmetrical arti-
intra-dependence). However, most of these solutions only facts along a single layer of abstraction can be facilitated by
capture execution order dependencies involving control dependency analysis techniques.
and data flow [7]. Semantic dependencies are not depicted
explicitly in such solutions. Semantic annotations and 3.4. Hierarchical coverage of change analysis and
ontologies are used to add semantics into existing process propagation techniques
models. However, semantically annotating each activity
with its immediate effect is very time consuming making Research work on impact analysis and propagation in
it infeasible for large process model repositories where service-oriented environments may either be seen as top-
hundreds of process models have thousands of constituent down or bottom-up analysis. A top-down approach ana-
activities [12]. Other formal modeling techniques like Petri lyzes the change impact originating from changing busi-
nets and their variants also suffer from certain short- ness processes all the way down to the services and their
comings. For example Ordinary petri nets or colored petri implementation. On the other hand, a bottom-up approach
nets have no ability for dynamic change modeling [41]. For analyzes the change impact originating from the service or
such changes we have to use reconfigurable petri nets. its implementation into business processes and other
Another setback of dependency based impact analysis is service consumers [39]. As we are addressing the conver-
that, these solutions consider all possible behaviors of gence of Business Process Management (BPM) and Service
entities involved, consequently producing large and com- Oriented Architecture (SOA), additional aspects must be
plex impact sets [28]. considered besides the Top-Down and Bottom-Up
Execution trace analysis cannot be used at the process approaches. Therefore, a classification scheme is provided
schema level because the availability of execution logs is a for change analysis and propagation across business and
pre-requisite in this regard. However, at the process service layers in Fig. 10.
instance (service) level, execution trace analysis can be BPM is related to the organization of business capabil-
used for impact analysis. Due to the fact that actual ities, while SOA refers to the organization of technical
dependencies between system artifacts can be unfolded capabilities. BPM and SOA work hand-in-hand as natural
by analyzing execution logs, this type of analysis has high partners.
precision rate. However, execution trace analysis can be Business processes in organizations are always prone to
significantly complex and daunting in case of large process different kinds of changes. Without proper control,
models [43]. changes in process models may have a disruptive effect
Similarly, historical co-change analysis, which utilizes on the overall system [72]. Thus, it is very important to
MSR techniques over revision (change) logs of business analyze Inter-Process dependencies and the impact of
processes and Web service ecosystems, is subject to changes on business process models. Changes in business
revision log availability. This type of analysis is significant process models due to changes in business requirements,
in terms of accuracy, but revision (change) logs may not be policies, and regulations are reflected at the business level.
available in many situations. Moreover, in case of small From an SOA point of view, despite its loosely coupled
version archives, this analysis may exhibit low precision architecture, various types of dependencies can exist
and recall rate due to limited learning abilities from the within SOA-based systems, e.g. semantic, business process,
archive [12]. message dependencies, etc. In a service composition, the
Quantitative analysis techniques are used in conjunc- execution of one service is dependent on other services
tion with other dependency analysis techniques, because due to collaboration [82]. Service level changes can lead to
traditional dependency analysis tools only emphasize on exhaustive service redesign and improvement. Without
how far the ripple effect of change may propagate. Thus, adequate control, changes can also disrupt overall system
quantifying change impact may be very useful in this functionality and performance [1]. Therefore, analyzing
regard. However, traditional change impact metrics cannot Service level dependencies is significant.
Changes in Service Based

Business Processes
Business Process Composite Service Component

Changes changes Service changes
Process Schema Process Instance Non- Non-

Functional Functional
changes changes functional functional
Exception
QoS
Innovation Optimization Handling Structural Behavioral
changes
changes
Maintenance,
Business Compliance / Abstract Service
Repair, Overhaul Refactoring Context Quality
Requirement regulatory service composition
(MRO)
Fig. 11. Types of changes in service-based systems.
3.5. Changes across business and service levels in terms of control flow and data flow changes [10,73]. Control
flow changes refer to changes in the execution order of tasks
Organizations continuously improve, adapt and change and activities. Data flow changes describe changes to data
their business processes to stay competitive. Business items being consumed, transferred or produced by the tasks
processes evolve to meet certain conditions such as evol- and activities. Process instance changes are ad hoc in nature
ving customer requirements, rapidly changing market and are usually performed to cope with unanticipated
trends, changes in internal policies, new regulatory situations and exceptions.
requirements introduced by regulatory bodies, and so on. A taxonomy of the evolution of service-based systems
An organization's ability to quickly respond and adapt to [17] classifies several types of changes in terms of change
changing requirements is considered a critical success motivation, location, time and support mechanism.
factor in competitive business environments. However, Change location is particularly important from the per-
changes are not straightforward to implement. Without spective of the current study. Change location considers 3
proper control, they may have a disruptive effect on the dimensions of change in service-based systems, including
overall system. Changes can occur in any lifecycle phase of artifact, transparency and abstraction degree. The artifact
business processes, for instance the design, re-engineering dimension addresses changes in SOA artifacts ranging
or redesign, or maintenance phases. from abstract business processes and requirement docu-
ments to executable and client code artifacts. Transparency
3.5.1. Business level changes refers to two service perspectives: service interface and
Business process changes can be categorized mainly into internal business processes. Service interface changes
process schema evolution and process instance changes represent modifications to Web Services Description Lan-
[30,80]. Process schema evolution represents higher level guage (WSDL) documents, while internal business process
changes in process models. These changes can be described changes refer to changes in business process patterns.
Fig. 12. Types of dependencies existing across layers of abstraction.
Abstraction degree represents process schema evolution be regarded as Business level changes as these changes
and process instance changes. emerge from service integrators to satisfy new business
Top-down changes in service-based environments are requirements or optimize existing processes. For instance,
either functional or non-functional changes. Functional the addition of store credit functionality will change the
changes refer to modifications of functionality provided existing functionality of the order service, which can be
by composite services, while non-functional changes refer regarded as abstract service change. To realize this new
to modifications of non-functional attributes including requirement, service integrators need to add, “manage
context and quality changes [42]. Changes to abstract store credit” service in exiting order service, which can be
services and service composition are important from a regarded as service composition change.
functional change perspective. Abstract service changes
represent the addition, removal or replacement of a 3.5.2. Service level changes
specific functionality from the composite service. On the Service level changes have been described in terms of
other hand, service composition changes refer to the shallow and deep changes [54]. Shallow changes include
addition or removal of a component service from the structural or protocol changes and have small-scale disruptive
composite service. Fig. 11 depicts the types of changes effects on a service or consumers of that service. Deep changes
occurring across multiple layers of abstraction. include policy, operational behavior and non-functional
For example, in the order processing scenario, a new changes. These large-scale changes extend towards end-to-
business requirement demanding buyer's location to end service networks and are hard to tackle as compared to
determine shipping charges, changes the existing process shallow changes. Change management of protocols and
model in Fig. 6. A new activity “get shipment address” is policies associated with services is also considered a key
introduced in the sub-process “calculate final amount” in concern; however, very few studies have addressed this issue.
Fig. 7. The Inclusion of this new activity is part of process A taxonomy of service and business process changes [79]
schema evolution, as induction of this activity affects the classifies service changes into operation and transition changes.
execution order of tasks and activities in the existing Operation changes are primitive changes to operations and
process model. Changes to composite services can also are further classified into operation existence changes, which
Inventory check service

Inter-dependence
Order handling service
Inter-Dependence
Check credit Card Service

Intra-dependence
Fig. 13. Inter- and intra-dependence at between services.
focus on the addition and removal of certain operations, and on a system due to the existence of dependency relation-
operation granularity changes, which focus on the modification ships among artifacts across different layers of abstraction.
of existing operations. Modifications to service transitions are Although SOA is a loosely coupled architecture, dependen-
referred to as transition changes. Web service changes have cies can still exist at different levels, i.e. the business
also been classified into requirement, interface, implementation process level and service level.
and QoS changes [70]. Each type of change may trigger other
changes as well, for instance requirement changes may lead to 3.6.1. Business level dependencies
changes in service interface and implementation. Changes introduced to a business process may affect
Bottom-up changes can be seen as triggering and reactive other dependent activities or business processes. For exam-
changes [41]. Triggering changes occur at the service level ple, a primary change in a sub-process like the removal or
while reactive changes occur at the business level. Reactive addition of an activity may lead to further secondary
changes happen in response to triggering changes. Triggering changes to the processes containing this sub-process. These
changes can be classified into functional and non-functional secondary changes may lead to more changes to other
changes. Functional changes refer to structural or behavioral dependent processes. Therefore, knowledge about inter-
changes to services, while non-functional changes refer to process dependencies is important for proper management
changes in non-functional attributes, e.g. availability, reliabil- and monitoring of business processes.
ity, trust, privacy, response and security. Another classification Existing studies mainly categorize business process
scheme categorizes bottom-up faults into physical and logical dependencies into control and data dependencies
faults. Physical faults are related to underlying infrastructure, [7,10,31,84,93]. Control dependencies affect the sequential
thus they are out of the scope of our study. Logical faults execution of business processes through conditions and
originate from service providers and are further divided into iterations. These dependencies refer to the sequential
status change, policy change and participation refusal change. order of activities so they are attributed as activity depen-
Status change refers to a condition when service availability is dency relationships. Data dependencies consider data
explicitly modified by the service provider. Policy change associated with each activity, because activities take some
refers to updates to service policies by the service provider, input data and generate output data accordingly. These
while participation refusal change occurs when a service dependencies usually exist between data producer and
denies to be part of the service composition. consumer activities within business processes [84].
An example of bottom-up changes has been discussed in Dai et al. [10] categorized business process dependen-
Section 3.3, where the service outage makes Internet banking cies into routing, data and role dependencies. Here, routing
service unavailable during midnight hours. Such changes are dependencies refer to control dependencies. Role depen-
usually part of regular maintenance activities by service dencies refer to different roles that execute process activ-
providers. Bottom-up effect of a service outage propagates ities. A taxonomy of dependencies in business process
to composite service layer and affects abstract service “pay- models classify them as structural, semantic, direct and
ment”. This affects payment related business operations indirect dependencies that have significance for change
defined in BPMN at business process layer. This change is impact analysis [30]. Structural dependencies are syntactic
related to service availability, which is a non-functional dependencies among two entities of business process
attribute. However, changes to service operations (structural) models, i.e. change in one activity of a process model
and interaction (behavioral) are also likely to occur fre- may have structural impact on other related activities of
quently during a service life cycle. For example, changing the process model. Semantic dependencies refer to
input parameters of “Transaction Authorization code” by changes in the semantics of related entities. Direct depen-
Internet banking service is considered as an operational dencies refer to control flow among two neighboring
change, while addition of new message exchange port to entities. Lastly, indirect dependencies represent an inter-
this service is considered as behavioral change. These func- mediate or transitive relation among two entities.
tional and non-functional changes may severely affect ser- Inter-process dependencies have been classified into
vice compositions and business processes at higher levels. enabling, triggering, disabling and canceling dependencies
[19]. Enabling dependencies involve the external enabling
3.6. Dependencies across the business process and service of some target task, e.g. during a travel booking process, an
level optional car reservation task is enabled. Triggering depen-
dencies occur when invoking some source task triggers a
Organizational business processes and services are target task. Disabling dependencies involve disabling of a
subject to changes. Changes may have disruptive effects target task when a source task is invoked. Canceling
Fig. 14. Impact of business level changes in order processing scenario.
dependencies invoke target task cancelation. A require- between these activities, no matter how many intermedi-
ment dependency model by Zhang et al. [88] categorizes ate activities exist between them.
requirement dependencies into intrinsic and additional
dependencies at a higher level. The initial set of this 3.6.2. Service level dependencies
proposed model comprises nine generic dependency Dependencies among artifacts at the service level have
types. This study also classified dependencies into direct been identified by [52,75,82]. Four major service depen-
and indirect propagation for change propagation analysis. dency types have been identified by [75] including process,
These dependencies can be included in requirement mod- semantic, message and non-functional dependencies. Process
els for change impact analysis and propagation at the dependencies exist at higher abstraction levels, where
modeling layer. Fig. 12 depicts different kinds of depen- process descriptions are used to define dependencies
dencies across multiple layers of abstraction. among Web services. Semantic dependencies refer to
For example, in Section 3.3 “check credit” and “receive relationships of Web services via a common upper ontol-
payment” activities have routing/control dependency. The ogy. Semantic annotations are used to define such depen-
dependencies between elements of the same business dencies between Web services. Message dependencies
process can be regarded as intra-process dependencies. refer to input and output messaging relationships among
In this case “check credit” and “receive payment” have intra- Web services. Finally, non-functional dependencies refer to
process dependencies. Similarly, the “verify payment security, constraint requirement policies or QoS attributes.
method” depends on the sub-process “calculate final Service level dependencies can also be seen as resource
amount”. This sub-process is further elaborated in Fig. 7. dependencies occurring between services handling a sin-
Another example of routing/-control dependency lies in a gle resource, time dependencies occurring between two
sub-process where “include shipment fee” activity is time-bound interacting services, and price dependencies
directly dependent on the “get shipment address” activity. occurring between a composite service and its component
Such kinds of relationships between two activities have services [82]. Resource and time dependencies can be
both the control and data flow dependencies. Here generalized into horizontal dependencies, while price
“include shipment fee” apparently has a control flow dependencies occurring across hierarchal levels can be
dependency with “get shipment address”. A data flow regarded as vertical dependencies. Omer and Schill [52]
dependency also exists between these two activities as categorized service dependencies into input/output, con-
“include shipment fee” is the consumer activity of the data straint and cause and effect dependencies. The first type of
produced by the “get shipment address” activity. Data flow dependencies is part of message dependencies. Constraint
relationships must be consistent with control flow rela- dependencies occur due to user constraints and can be
tionships [42]. In other words, a data flow between any realized through semantic annotations. Cause and effect
two activities can exist if there is a control flow path dependencies are based on the pre-conditions for a
Table 5
Business level change analysis and propagation solutions according to hierarchical coverage.
Reference Publication Publication Emp. research Contribution Focus

channel year method
Inter-process change analysis and propagation

S01 Journal 2012 Experiment Method Process model change propagation
S02 Journal 2009 Case study Model Process dependency analysis
S04 Conference 2011 Survey Framework Process change traceability
S06 Conference 2009 Experiment Method Process element CIA
S07 Conference 2013 Experiment Framework Process dependency analysis
S08 Conference 2012 Experiment Framework Process model change propagation, process dependency
formalism
S09 Journal 2013 Experiment Method Process model change propagation
S10 Journal 2010 Case study Model þ Tool Software process CIA
S11 Workshop 2013 Experiment Method Multi-level business requirement CIA
S12 Conference 2013 Experiment Framework Process views change propagation
S15 Journal 2011 Experiment Framework Work-flow constraints CIA
S16 Conference 2011 Case study Framework Multi-level traceability based CIA
S44 Conference 2014 Case study Tool Process dependency analysis
S47 Journal 2014 Experiment Method Inter-process dependency and co-change analysis
S48 Conference 2009 Experiment Method Process dependency analysis
S49 Conference 2011 Experiment Model Process model change propagation
S50 Conference 2014 Experiment Algorithm Process choreography propagation
S57 Conference 2014 No Tool Process model traceability
S59 Journal 2013 Case study Method Event type dependency analysis in process choreography
S60 Journal 2012 Experiment Framework Ontology change traceability
Top-down change analysis and propagation

S17 Conference 2009 Case study Framework Higher to lower level models traceability
S18 Journal 2012 Case study Tool Higher to lower level models propagation
S19 Conference 2010 Experiment Framework Higher to lower level models propagation
S20 Conference 2013 Experiment Method Higher to lower level model traceability
S22 Conference 2013 Experiment Method Higher to lower level models propagation
S23 Conference 2008 Experiment Frameworkþ tool Multi-level top down change propagation
S24 Journal 2012 Experiment Method Multi-level structural CIA
S25 Conference 2013 Experiment Framework Higher to lower level models propagation
S26 Conference 2011 No Method Composite to component service change propagation
S30 Conference 2012 Experiment Model Multi-level trust CIA for composite services
S58 Conference 2009 Case study Method Higher to lower level models traceability
service. Component services involved in a service compo- 3.7. Change analysis and propagation techniques at the
sition exhibit intra- and inter-dependence relationships. business level
Inter-dependence relationship represents the basic depen-
dency relationship existing between a requested service Changes introduced at the business process level may
and a service receiver of that request. Intra-dependence have both horizontal and vertical effects on other compo-
exists between two component services when there is an nents. Horizontal effect is confined to related business
incoming inter-dependence and one outgoing inter- processes at the same hierarchy while the vertical effect
dependence relationship for a component service [50]. propagates all the way down to lower level models and
For example, in order processing scenario, business component services. Inter-process and top-down change ana-
process has been realized through 16 component services. lysis, both cater to changes introduced at the business level.
These services integrate into five composite services to For example, in the order processing scenario, new
perform certain business tasks. At the component service business requirements may emerge. Suppose that business
level, these services exhibit both inter-dependence and owners want to award store credits on every purchase, so
intra-dependence relationships. For example, in Fig. 13 that potential buyers may be facilitated by reduced prices.
Inventory check and Order handling services have an inter- This new business requirement may affect several activ-
dependence relationship with each other where Order ities and sub-processes involved in the business process.
handling service is invoked by Inventory check service To accommodate this change, a new activity “check store
through message passing. Similarly, order handling and credit” will be added to the sub-process “calculate final
location map services have inter-dependence relationship. amount”. It means activities involved in a sub-process may
Now as we have discussed order handling service is get affected by the introduction of a new activity. This
exhibiting incoming and outing inter-dependence rela- effect may not only be confined to this sub-process, but it
tionships. In this case, the inventory check and location will propagate to other activities of the order processing
map services have an intra-dependence relationship with business process. Additionally, a new activity “Update store
other. It means they do not have a direct relationship but credit” will be added after “approve order”. This activity
service invoked by Inventory check, further invokes the will update the store credit of buyer, depending upon the
location map service. purchasing amount. Moreover, the induction of this
Fig. 15. Impact of service level changes in order processing scenario.
activity will affect several more activities. This effect of analysis. Formal specifications are considerably important
change may be regarded as an inter-process change impact. in capturing deeper semantics of inter-process relation-
However, the impact of such change will also affect under- ships. Semantic annotations and ontology trees are used for
lying composite and component services. Specifically, relationship mapping between process model elements.
order and payment services will need to add or replace However, approaches based on change history mining,
existing services in the composition. In the above case, a traceability analysis, and inter-organizational dependency
new component service “Manage store credit” will be analysis are rarely found in the context of inter-process
added at a component service level to satisfy the new relationships. A detailed analysis of these solutions is
business requirement. Inclusion of this new service in presented in Tables 5 and 7.
service composition will affect existing services and their Both the directed graph based dependency analysis,
interactions. This effect of change may be regarded as Top- and formal dependency modeling are effective to capture
down change impact. Fig. 14 illustrates the effect of a inter-process dependencies at this level. The control flow
change at a business process level. graph (CFG) and Data Flow Graph (DFG) have capabilities
to capture dependencies at business process level [7,45].
3.7.1. Inter-process impact analysis and propagation However, the formal modeling is more effective especially
Changes introduced to one business process may affect petri nets based formalism, semantic annotations and
other organizational processes. For example, a primary ontological specifications have largely been used at a
change in a sub-process like the removal or addition of an business process level. The inter-process dependencies
activity may cause further secondary changes to the pro- can be formally specified in greater detail using these
cesses containing this sub-process. Secondary changes may tools. Moreover, the formal logic and process algebra based
lead to additional changes to other dependent processes. formalism have also been used in context of business
The prediction and effective propagation of the impact of process level changes [73].
these changes is extremely important. Inter-process change
management has received significant attention from the 3.7.2. Top-down impact analysis and propagation
research community. Existing research provides a sound Business process changes are not only confined to
basis for change propagation [13,16,36,43,51,81], depen- business, but their impact can also penetrate to lower
dency analysis [7,8,10,12,30,31,36,45] and traceability analy- modeling layers and service implementations. Similarly,
sis [22,25,71] for business process level changes. Most CIA changes in composite services at the business level may
approaches for inter-process impact analysis utilize graph- affect component services at the service level. However,
based or formal specification approaches for dependency this kind of impact is non-trivial as business analysts are
Table 6
Service level change analysis and propagation solutions according to hierarchical coverage.
Reference Publication Publication Empirical research Contribution Focus

channel year method
Bottom up change analysis and propagation

S24 Journal 2012 Experiment Method Multi-level structural CIA
S27 Journal 2009 Experiment Model Service outage impact analysis
S29 Conference 2011 Experiment Model Component to composite service propagation
S30 Conference 2012 Experiment Model Multi-level trust CIA for composite services
S51 Conference 2007 No Framework Service CIA over business Processes and consumers
S52 Conference 2012 Experiment Framework Service CIA over client applications
Inter-service change analysis and propagation

S16 Conference 2011 Case study Framework SLA violations impact (multi-level traceability based
CIA)
S31 Journal 2013 Experiment Model SLA violations impact (time dimension)
S33 Conference 2011 No Method Service dependency analysis
S34 Conference 2007 Experiment Frameworkþ Service protocol CIA
tool
S35 Workshop 2014 Experiment Method Event based systems CIA
S37 Conference 2009 No Model Service dependency analysis
S38 Journal 2011 Experiment Method Service dependency analysis
S39 Conference 2012 Experiment Method Event based systems CIA
S40 Conference 2009 Experiment Method Service dependency analysis
S41 Journal 2008 Experiment Framework Service protocol CIA
S43 Conference 2012 Experiment Model Service dependency analysis
S46 Conference 2009 No Method Service dependency analysis
S53 Conference 2007 Experiment Model Service dependency analysis
S54 Journal 2014 Experiment Method Inter-service co-change analysis
S55 Conference 2010 No Model Choreography service dependency analysis
S56 Conference 2008 Experiment Tool Service dependency analysis
not usually aware of underlying implementations, and a Changes introduced at the service level may have both
change in an upper business layer can cause complex and horizontal and vertical effects. Horizontal effect is confined
deep effects on its implementation. Thus it is significantly to other services in the same hierarchy while vertical effect
important for business analysts to investigate the impact propagates all the way up to business processes and
of changes on underlying modeling layers and service composite services. Inter-service and bottom-up change
implementations. Tools and techniques for analyzing such analysis cater to changes introduced at the service level.
changes fall under top-down change analysis. Existing work For example, in the order processing scenario, one of the
in this area has multiple facets like business process-to- participating component services may become unavailable
source code and service implementations [60,85], higher due to request overload or network failure. This case has
level models to lower level detailed models [9,11,44,49,64] been discussed in detail in Section 3.3, where a service
and composite services to underlying artifacts [14]. Table 5 outage affects certain business operations during mainte-
provides an overview of the change analysis and propaga- nance hours. There are other examples of component
tion solutions at the business level while considering their service changes in addition to unavailability of service.
hierarchical coverage. These changes may include both structural and behavioral
Most of the solutions have adopted traceability link changes, as well as non-functional changes. In this parti-
analysis to track the effect of business process level changes cular scenario, changes to service operations would repre-
to underlying composite and component service layers sent structural changes. For example, the Internet banking
[32,44,64]. Moreover, formal specifications [42,49,60] have service previously required customers to enter a 6 digit
been used to model Top-down change specifications. Top- “Transaction Authorization code” sent on their mobile
down changes involve many dissimilar artifacts across phones. Now if service providers decide to change the input
different layers of abstraction. Traditional traceability solu- parameters of TAC code, or change the validity time from
tions are mostly manual and ad-hoc in nature; however, three minutes to five minutes, then such type of change
formal change modeling accompanied by traceability links may be regarded as a structural change to service opera-
can facilitate in tracing top-down changes. tions. However, there may be behavioral changes related to
interaction of a particular service with other services.
3.8. Impact analysis and propagation techniques for service Moreover, there are changes related to service availability,
level changes cost, security, trust etc. These changes at a component
service level may not only affect other interacting services
Changes to component services originate from the (inter-service change impact), but they may also ultimately
service provider end. Changes introduced at the service affect service compositions and business operations at
level may affect other services, supporting business pro- higher levels (bottom-up change impact). Fig. 15 illustrates
cesses, composite services and even the entire system. the effect of a change at a service level.
Table 7
Review matrix of CIA techniques for service-based systems.
Ref. Approach Tools Coverage Entities Dependencies/change operations Scope
Formal description
S01 Formal Petri nets Intra-layer BPMN models Correspondence relations of activities Static
specification Behavioral dependencies
S02 Formal Prolog Intra-layer Workflow BP Control, data, role Static
specification Rule based analysis
S06 Formal Kleen algebra with Intra-layer BP elements Direct, indirect Static
specification Tests-KAT Secondary Dynamic
Non-cautionary (priori)
S07 Formal Ontological definition Intra-layer BPMN models Control, data Dynamic
specification rule based analysis (priori)
S15 Formal Formal logic Intra-layer Workflow business Control, data, resource, workflow constraint Static
specification processes
S23 Formal Inference rules Inter-layer Use cases, sequence Design artifact dependencies Static
description diagrams, service
specifications
S27 Formal Dependency model, Inter-layer BP, CS, AS Service outage Dynamic
specification configuration
management DB
S31 Formal Rule-based analysis Intra-layer AS Direct, indirect Dynamic
specification
S34 Formal FSM Intra-layer Security protocol, service Message dependencies Static
specification, instances Dynamic
execution traces
S41 Formal FSM Intra-layer Business protocol, service Message dependencies Dynamic
specification, instances
execution traces,
S40 Formal Dependency meta- Inter-layer CS, AS Time, resource(vertical, horizontal)price, qos Static
specification model, path analysis Intra- (vertical)
layer
S18 Formal Regular tree grammar Inter-layer PIM, PSM models – Static
specification
S53 Formal Ontological definition Intra-layer Service interfaces Interface dependencies Static
specification
S59 Formal Ontological event view Intra-layer Event-based process Event type dependencies Static
specification specification rule inter-org models
based analysis
S08 Formal Semantic effect Intra-layer Semantically annotated Functional dependencies Static
specification analysis BPMN models
CNL, domain Consistency dependencies
ontology
Graph based analysis

S05 Graph based Graph reachability Intra-layer BPMN models service Direct, indirect Static
analysis implementation
Quantitative Impact metrics Inter-layer Structural, semantic Dynamic
analysis (prior)
S09 Graph based Directed graph and Intra-layer Workflow repository Call relationships Static
analysis treemaps, impact
Quantitative metrics
analysis
S11 Graph based Directed graph Inter-layer BP, web services Control, data Static
analysis
S10 Graph based Directed graph Intra-layer BP activities, artifacts and Control, role, assignment and message Static
analysis roles
Quantitative Process slicing
analysis
S24 Graph based Directed graph Inter-layer Single BP, multiple Control, data Static
analysis Impact patterns supporting services
S30 Graph based CFG, TDG Inter-layer CS, AS Trust dependencies Static
analysis
S33 Graph based MDG Intra-layer AS Message dependencies Dynamic
analysis
execution traces
S37 Graph based Directed graph, Intra-layer Service instances Process, semantic, message Static
analysis semantic annotations
Quantitative
analysis
S39 MDG Intra-layer AS Message dependencies Dynamic
Table 7 (continued )
Graph based
analysis
execution traces
S44 Graph based CFG Intra-layer BPMN 2.0 Models Control, data Static
analysis
S46 Graph based Directed graph Intra-layer AS Cyclic dependencies Static
analysis
S47 Graph based Semantic annotations, Intra-layer Process models – Static
analysis Graph traversal (posteriori)
S48 Graph based ECFG Intra-layer BPEL programs Control, data Static
analysis
S43 Graph based Directed hypergraph Intra-layer Service instances Service dependencies(use, reference, Static
analysis instantiation, deployment)
S55 Graph based Dependency matrix Intra-layer Choreography services Process, semantic, message(service level) Static
analysis
S56 Graph based MDG Intra-layer AS Message dependencies Dynamic
analysis
execution traces
Quantitative analysis
S10 Quantitative Directed graph process Intra-layer BP activities, artifacts and Control, role, assignment and message Static
analysis graph slicing roles
based analysis
S11 Quantitative Impact metric Inter-layer BP, web services Control, data Static
analysis graph Directed graph
based analysis
S37 Quantitative Directed graph, Intra-layer Service instances Process, semantic, message Static
analysis semantic annotations
Graph based
analysis
S38 Quantitative Link analysis Intra-layer Service instances Process, semantic, message Static
analysis
S52 Quantitative Usage profiles Inter-layer Service versions Interaction dependencies Static
analysis interaction logs
Execution trace analysis

S27 Formal Dependency model, Inter-layer BP, CS, AS Service outage Dynamic
specification configuration
management database
S33 Execution traces, MDG Intra-layer AS Message dependencies Dynamic
graph based
analysis
S34 Execution traces, FSM Intra-layer Security protocol, service Message dependencies Static
formal instances Dynamic
specification
S35 Execution traces, Trace semantics Intra-layer AS Message dependencies Dynamic
formal
specification
graph based
analysis
S41 Execution traces FSM Intra-layer Business protocol, service Message dependencies Dynamic
formal instances
specification
graph based
analysis
History mining
S47 History mining Co-variation patterns Intra-layer Process models Co-change relationships Static
(posteriori)
S54 History mining Co-variation patterns Intra-layer Web services Co-change relationships Static
(posteriori)
S50 History mining Memetic mining Intra-layer Cross-organizational Co-change relationships Static
algorithms process Models (posteriori)
Traceability analysis
S04 Horizontal Change tracking Intra-layer Business process model Serialinsert, delete, serialmove, replace, PM–PM
graphs changes swap, and parallelize process fragment traceability
S20 Vertical Evolution capturing Inter-layer SOA system model Creation, removal, modification of SOA HLM–LLM
model artifacts (BP, services, system model artifacts traceability
Traceability links service operations etc.)
Table 7 (continued )
S16 Vertical Traceability links, Inter-layer SOA solution artifacts Sla violation, KPI conformance failure of BP SOA solution
Business process or activity, new or changed goals, KPI artifacts-
change patterns changes, SOA-infrastructure changes KPI's
traceability
S17 Vertical Rule based approach Inter-layer Business, service, design Add, delete, change process Inter-model
models Add, delete, change entity traceability
S57 Horizontal BP change patterns Intra-layer Process model versions Authorization differences PM–PM
Activity difference control flow traceability
differences
S58 Vertical Event driven Inter-layer SOA solution artifacts, – Model-
traceability, model/ patterns pattern
artifact-pattern traceability
matching
S22 Vertical Traceability links Inter-layer Software design model, Add, remove, move model elements SModel–
performance model (refactoring primitives) PModel
traceability
S60 Horizontal Change log based Inter-layer Ontology repository Create, update, delete (ontology changes) Ontology-
traceability ontology
traceability
CFG, MDG, TDG, ECFG refer to control flow graphs, message dependency graph, trust dependency graph, extended control flow graph respectively.
MDG, FSM, CNL refer to message dependency graphs, finite state machine and controlled natural language.
PM, HLM,LLM refer to process model, higher level model, lower level model respectively.
BP, CS, AS refer to business process, composite service, and atomic service respectively.
3.8.1. Bottom-up impact analysis and propagation have not been employed for bottom-up changes, and it can
Bottom-up changes originate from the service provider be regarded as a significant research gap. As discussed
end, e.g. service replacement, outage, change in service earlier, traditional traceability solutions may involve sig-
operations, etc. Such changes may have severe impact on nificant manual effort. However formal change modeling
related business processes and composite services at higher accompanied by traceability links can also facilitate in
levels. Surprisingly, very few studies [46,59,63,79,86,89] have tracing bottom-up changes.
focused on the bottom-up impact of service changes. In the
context of bottom-up change propagation, the lazy and strict 3.8.2. Inter-service impact analysis and propagation
change propagation methods have been discussed but Changes to component services and messaging proto-
bottom-up impact analysis techniques focused on specific cols may affect other dependent services in the composi-
kinds of changes and dependencies, i.e. service outage [63], tion. Mainly, there are three aspects of service changes
binding changes or service replacement [59], and many-to- including interface changes, protocol changes and QoS
one relationships between services and business processes changes. Existing research addresses inter-service depen-
[79]. Other studies have emphasized specific operations like dency analysis [3,33,52,61,75,76], SLA violations [22,24,63]
fault management [46], change feature versioning [86] and and protocol changes [62,65] at the service level. Graph-
variation analysis [89]. Bottom-up change propagation can based dependency analysis and formal specifications also
be viewed as lazy and strict propagation [41]. Lazy propaga- dominate inter-service dependency analysis. Service ontol-
tion as a default policy works only when a composite service ogies and semantic annotations have been largely
is unable to locate a selected Web service, while strict employed to explore and verify service-level changes
propagation ensures that a change in underlying Web service [33,41,75]. An SLA violation of a service may have potential
will be conveyed to the composite service in the next impact on dependent services. Therefore, mechanisms for
execution. No bottom-up change analysis approach exists, handling SLA violations are considered an essential
which considers data dependencies. Moreover, no bottom- requirement for adaptive service-based systems. CIA tech-
up approach has been identified that supports multiple niques for event-based systems [57,69] are closer to
business processes supported by a network of services. service-based systems, as SOA artifacts follow an event-
Studies on the bottom up changes are rather scarce and based communication style. These techniques are only
multi-faceted at the same time. Currently, there exist no relevant to service level dependency and impact analysis.
concrete solutions to support impact analysis of service Protocol changes are another important aspect of changes
level changes to all artifacts at higher levels. Existing at the service level. These protocols provide means for
studies have used graph based techniques to analyze the interaction between services and their clients. In dynamic
effect of service level changes. Formal methods have been service-oriented environments, service providers must
used for bottom-up change specifications [41]. The quan- constantly adapt business protocols due to changing
titative analysis has also been used in conjunction with requirements. Table 5 provides an overview of change
graph based techniques [86] and formal methods [63]. analysis and propagation solutions at the service level
Backward tracability solutions are desirable in such situa- while considering their hierarchical coverage. These stu-
tion, but unlike top-down changes, traceability solutions dies address changes introduced at the service level and
Table 8
Review matrix of change propagation solutions for service-based systems.
Reference Classification Technique Support Scope Change Op./patterns
S01 Bi-directional Behavioral profiles, Petri net – Inter- ADD, REMOVE node
process ADD, REMOVE transition
S08 Forward CSP Automated Inter- Add, delete an activity
process
S12 Bi-directional Consistency constraints, Petri net Semi Add node, Remove node (Control Flow)
(automatic) Add, remove (Data Flow)
S17 Forward Inference rules Semi- HLM– Add, Delete, Change Process
automated LLM Add, Delete, Change Business Entity
S18 Bi-directional Schema mapping Semi- HLM– Create, Remove, Update, synchronize(Atomic
automated LLM Operations)
Composite Operations
S22 Forward Trace Links, MARTE annotations Automated HLM– Add, remove, Move Model Elements (Refactoring
LLM primitives)
S23 Forward Inference rules, Semantic specification and Semi- HLA– Add, Modify Use Cases
traversal of design artifacts automated LLM Add, Modify Sequence Diagrams
S25 Forward in-place model update translation, Automated HLM– Create, Destroy, Update, undo(primitive Update
incremental synchronization LLM operations)
S28 Backward Mapping rules Semi- AS–CS Add, Remove(Namespace, Type, Message,
automated Operation,Location,PortType,Binding)
Non-Functional (Trust, usability, dependability)
S26 Forward Fragment partitioning, PST Semi- CS–AS Insert, Update, Delete
automated
S29 Backward Soft state signaling – AS–CS Freeze, Stop (Status Change)
participation refusal
Update policy
S49 Bi-Directional Storage structure Semi- Inter- Label change
automated process INSERT serial, parallel Node
DELETE node
S19 Forward Consistency constraints Semi- Inter- ADD, DELETE, MODIFY, CREATE
automated layer
HLM, LLM, HLA refer to higher level models, lower level models and higher level artifacts respectively.
PST, CSP refer to process structure tree, constraint satisfaction problem respectively.
AS, CS refer to atomic service and composite service.
Table 9
Synthesis of CIA and propagation techniques in service-oriented enterprises.
Dimension Classification Studies
Hierarchical Inter-Process Change Analysis and S01, S02, S04, S06, S07, S08, S09, S10, S11, S12, S15, S16, S44, S47, S48, S49, S50,
coverage Propagation S57, S59, S60
Top-Down Change Analysis and S17, S18, S19, S20, S22, S23, S24, S25, S26, S30, S58
Propagation
Bottom-Up Change Analysis and S24, S27, S29, S30, S51, S52
Propagation
Inter-Service Change Analysis and S16, S31, S33, S34, S35, S37, S38, S39, S41, S43,S46, S53, S55, S56
Propagation
Type of Analysis/ Graph-Based CIA S05, S09, S10, S11, S24, S30, S33, S37, S39, S43, S44, S46, S47, S48, S55, S56
support Formal Specification based CIA S01, S02, S06, S07, S15, S18, S23, S27, S31, S34, S40, S41, S53, S59, S08
Quantitative CIA S10, S11, S37, S38, S52
Execution Traces-Based CIA S33, S34, S35, S39, S41, S56
History mining-based CIA S47, S50, S54
Traceability Analysis S04, S16, S17, S22, S57, S58,S60
Change Propagation S01, S08, S12, S17, S18, S19, S22, S23, S25, S26, S29, S49
analyze both horizontal and vertical effects of component matrices have also been used to capture intra- and inter-
service and protocol changes. component dependencies at service levels [52,57,91]. How-
Similar to inter-process changes, we have seen extensive ever, the message dependency graphs have been identified
use of the directed graph based dependency analysis and as the most obvious and feasible choice among directed
formal dependency modeling techniques in the context of graph based approaches. Although, ontological specifications,
inter-service dependencies. Message dependency graph trace semantics, and state machines have been used to
(MDG), direct dependency graph (DDG), direct dependency describe formal semantics, graph based techniques are
acyclic graph (DDAG), directed hypergraph and dependency comparatively more viable for service level dependencies.
8
7
6 Inter Process CIA & Propagation
5 Top Down CIA & Propagation

4
Inter Service CIA & Propagation
3
Bottom Up CIA & Propagation
2
1
0
2007 2008 2009 2010 2011 2012 2013 2014
Fig. 16. Chronological distribution of studies over the years.
3.9. Analysis of service-based CIA and propagation Fig. 17. CIA solutions according to analysis type.
techniques
A set of different impact analysis and propagation

solutions have been identified as a result of this systematic
review. Tables 5 and 6 provide an analysis of these
solutions according to their hierarchical coverage across
different layers of abstraction. This section provides a
detailed analysis of these solutions through review
matrices. Table 7 gives a detailed analysis of all identified
CIA techniques and categorizes them according to classi-
fication scheme in Fig. 4. Table 8 provides a detailed
analysis of change propagation solutions, while consider-
ing the same classification scheme presented in Fig. 4.
Fig. 18. Dimensional correlation of CIA and propagation solutions.
3.10. Principal findings
Service-oriented architecture (SOA) and Business Pro- service change analysis and propagation solutions. On the
cess Management (BPM) have emerged as promising other hand, the hierarchical impact of changes across
technologies and are receiving significant attention from different layers of abstraction has received lesser attention
the software engineering and information systems despite its significance. Top-down change analysis has
domains. System maintenance and evolution based on been highlighted in 18.33% of the selected studies,
these technologies have become of crucial concern to whereas bottom-up analysis has been identified as the
enterprises. However, there are some areas in which very most neglected dimension with only 10% of selected
little research work exists. studies. Fig. 16 depicts the chronological distribution of
Change impact analysis techniques in service-based selected studies over the years, from 2007 to 2014.
systems are mainly divided into dependency analysis, While considering the second dimension, dependency-
traceability analysis and history mining. Dependency ana- based impact analysis solutions clearly dominate. Graph-
lysis techniques have been further categorized into graph- based dependency analysis is one of the most frequently
based analysis, formal specification, quantitative analysis adopted CIA techniques (31%) followed by formal model-
and execution trace analysis. Table 9 presents selected ing of dependencies (29%). Execution trace-based analysis
studies classified into two dimensions. The first dimension is unique in nature, as it focuses on dynamic dependencies.
highlights coverage of change analysis and propagation Graph-based or formal modeling techniques have been
solutions while the second dimension highlights the type used for visualizing and specifying such dependencies.
of analysis performed for service-based BPM systems. However, fewer studies have focused on dynamic depen-
Table 9 synthesizes impact analysis and propagation solu- dency analysis by utilizing execution traces (12%). Quanti-
tions according to the classification schema presented in tative analysis has been employed in numerous studies in
Figs. 4 and 5. conjunction with formal modeling or graph-based app-
From a coverage point of view, the results reveal that roaches. Only 10% of the CIA techniques have provided
inter-process change analysis and propagation have been quantification of change impact through certain metrics.
emphasized in the majority of studies. Out of 60 selected Histories mining of change, version logs and trace-
studies, 49 are relevant to RQ3 and RQ4. Inter-process and ability enablement in service-based systems have
inter-service change analysis and propagation have widely received little attention. Although CIA based on mining
been focused on in previous literature. Table 9 indicates software repositories (MSR) is frequently applied in
that 33.330% of selected studies concentrate on inter- traditional software systems, only 6% of the CIA techni-
process change analysis and propagation solutions, ques have used mining techniques for CIA in service-
whereas 23.33% of selected studies emphasize on inter- oriented environments. Traceability analysis has also
Table 10
Synthesis matrix for impact analysis techniques in service oriented environments
Technique Tools Pre-requisite Merits De-merits Applicable

artifacts dimensions
Graph based Control flow, extended – Depiction and visualization of Large and complex impact Intra and inter-process
approaches Control flow graphs (CFG, all execution order and sets dependencies, intra
ECFG), Call graph, Data Flow message exchange Low precision. and inter-dependence
Graphs (DFG), Process graph relationships among artifacts No explicit depiction of service relationships,
(PG), Message dependency Dependency graphs semantic dependencies process schema change
graph (MDG), Directed generation and traversal analysis
hypergraph, Trust through automatic tools
dependency graph (TDG) Dependency graphs are
useful input for other
types of analysis
Formal Specifications Petri Nets (PNs), – Inclusion and verification Dynamic change modeling
process algebra, of semantics through difficult through
formal logic, various tools, Strong conventional formal
state machines, support for knowledge modeling tools
Intra and inter-process set theory, management, Rich Hard to understand by
dependencies, intra and inference rules, analytical capabilities, business professionals
inter-dependence ontologies and Increases efficiency of
service relationships, top semantic other impact analysis
down and bottom-up annotations, techniques
Requires change specifications
signifi-
cant
manual
effort
Quantitative Ripple effect, symmetrical Input through Use of metrics to quantify the Inability to quantify all Intra and Inter-Process
analysis effect, priority, execution other impact impact of change types of change impacts dependencies
frequency, invocation analysis due to very basic sets of Intra- and inter-
frequency, intra-, inter- techniques. e.g. existing metrics dependence service
relation, intra-, inter- input through Inability to map relationships
dependency, cohesion dependency traditional impact Bottom-up change
graphs metrics to service impact analysis
oriented environments
Execution Data and process mining Event logs, Ability to capture dynamic Complex in case of large Process instance
trace techniques, trace semantics, Process dependencies process models, Can only change analysis
analysis spectral graph analysis, execution logs, High precision be used for post-analysis,
vector clocks, concept execution Used in conjunction with Cannot be performed in Intra and inter-
analysis, path impact coverage graph-based analysis and absence of execution or dependence service
analysis, dynamic information formal descriptions event logs relationships
programming
Traceability Trace links, change tracking – Can be used for asymmetrical/ Significant Manual Effort Inter-layer (Higher-to
analysis graphs dissimilar artifacts, can be required to maintain lower level artifacts)
used across different layers of traceability links across BP–CS (CS–BP), CS–AS
abstraction multiple layers (AS–CS)
History MSR techniques, co-change Revision logs, High accuracy Low precision and recall Intra and inter-process
Mining patterns change logs rate in case of small dependencies
(CVS, SVN) version archives, cannot be Web service
performed in absence of ecosystems
revision logs
received little attention from the scientific community Finally, we synthesize our findings on impact analysis
with only 14% of change analysis techniques. Fig. 17 techniques for service based systems. Table 10 shows a
illustrates how often these techniques have been synthesis matrix which provides a list of supporting tools,
employed in service-based environments. merits, demerits and applicability of each CIA technique
Change propagation solutions had a 20% share of the along particular dimensions.
selected studies. Most change propagation solutions are Identification of publication venues of a specific topic/
semi-automated in nature, meaning manual help and field can be very useful for researchers who are interested
decision making are essential by a maintainer. A significant in conducting research in the relevant field. Table 11
portion of these propagation solutions emphasizes on illustrates how selected studies are distributed across
change propagation from higher to lower level models. below mentioned publication venues. Books are excluded
Fig. 18 illustrates the correlation of classification schemas from this list. JSS, SCC, ICSOC, APSEC, SOCA and ICWS have
presented in Figs. 4 and 10. been identified as leading venues for relevant studies.
Table 11
Publication venues.
Venue Publisher Studies Count
Int. Conference on Services Computing (SCC) IEEE S23, S25, S43, S51, 6
S53, S56
Journal of Systems and Software Elsevier S01, S02, S10, S18, S315
International Conference on Web Services(ICWS) IEEE S09, S37, S52, S58 4
International Conference on Service Oriented Computing (ICSOC) Springer S36, S40, S50 3
Asia Pacific Software Engineering Conference (APSEC) IEEE S19, S30 2
International Conference on Software Engineering (ICSE), ICSE Workshop on Systems Development in SOAIEEE, ACM S11, S34 2
Environments
On The Move Federated Conferences Springer, S12, S49 2
ACM
Knowledge-based Systems Elsevier S60 1
Service Oriented Computing and Applications Springer S24 1
Asia-Pacific Conference on Conceptual Modelling (APCCM) ACM S13 1
Information and Software Technology Elsevier S14 1
Decision Support systems Elsevier S15 1
IEEE Software IEEE S32 1
IEEE Transactions on Network and Service Management IEEE S27 1
IEEE Transactions on Services Computing IEEE S21 1
ACM transactions on the Web ACM S41 1
Data & Knowledge Engineering Elsevier S42 1
International Journal of Web Information Systems Emerald S54 1
Computers in Industry Elsevier S47 1
Concurrency and Computation: Practice and Experience Wiley S59 1
Business Process Management (BPM)Workshops Springer S08 1
International Conference on information integration & Services (iiWAS) ACM S45 1
International Conference on Next Generation Web Services (NWESP) IEEE S46 1
Int. conference on Service-oriented Computing (SOCA) IEEE S48 1
Web Information Systems Engineering (WISE) Springer S03 1
Int. Conference on Conceptual Modeling ACM, S04 1
Springer
International Workshop on Quality Assurance for Service-Based Applications ACM S33 1
International Conference on Performance Engineering ACM S22 1
World Congress on Services IEEE S16 1
International Conferences on Web Intelligence and Intelligent Agent Technology IEEE S38 1
United Information Systems Conference Springer S06 1
Collaborative Computing: Networking, Applications and Worksharing IEEE S26 1
Int. Conference on Advanced Information Systems Engineering (CAiSE) Springer S29 1
International Conference on Frontiers of Information Technology (FIT) IEEE S07 1
International conference on Dependability and Complex Systems Springer S20 1
SIGPLAN Object oriented programming systems languages and applications ACM S17 1
ACM International Conference on Distributed Event-Based Systems ACM S39 1
International Multitopic Conference IEEE S05 1
Symposium On Applied Computing (SAC) ACM S35 1
Int. Conference on Computer Supported Cooperative Work in Design (CSCWD) IEEE S55 1
Advanced information Networking & Applications (AINA) IEEE S44 1
Int. Multi- Conference of Engineers & Computer Scientists (IMECS) Springer S57 1
There are a few studies on change quantification in

3.11. Future research implications (3) service-based systems. Impact metrics should accom-
pany impact analysis techniques in future. Moreover,
Important research directions have been listed below, hybrid CIA techniques prove to be effective in tradi-
after analyzing the selected study results. tional software systems, but combinations of different
CIA techniques need further investigation for
(1) Effects of service outage, modification, and replace- improvement.
ment on organizational business processes have not (4) In traditional software systems, MSR-based impact
yet been fully covered. There is a need for impact analysis has received significant attention from the
analysis techniques to measure the extent of the ripple research community, but there are only a few exam-
effect on business processes. ples of such techniques being applied in service-based
(2) Complex relationships between services with support- systems. Recently, large process model repositories
ing business processes and semantic dependencies are have got significant attention from the research com-
poorly understood. There is a need for tools to provide munity. History mining needs to be further explored
end-to-end support for hierarchical change impact. for such repositories.
Table 12
List of acronyms and their full forms.
SOA Service oriented architecture AS Atomic service (component service)
BPM Business Process Management MSR Mining Software Repositories

BPMN Business Process Model Notation XML Extensible Markup Language (XML)
EPC Event-driven Process Chain ebXML Electronic business Extensible Markup Language
SOC Service Oriented Computing OWL-S Web Ontology Language for Services
CIA Change impact analysis REST Representational State Transfer
CFG Control Flow Graph BPEL Business Process Execution Language
DFG Data Flow Graph WSDL Web Services Description Language
BP Business Process WSBPEL Web Services Business Process Execution Language
CS Composite Service WSDL-S Semantic Web Services Description Language
(5) Refactoring is a significant activity that concerns hinder automatic search coverage. The manual search
changing the internal structure of a process model identified relevant studies from potential publication
while preserving its external behavior. Change impact venues covering BPM and SOA. The selected studies were
analysis at the business process level can be used to also backward reference searched to ensure the inclusion
ensure safe refactoring of process model repositories. of relevant studies. However, still this study may suffer
(6) Traditional software systems utilize CIA techniques for from selection bias, as other libraries like Citeceerx and EI
regression testing. Regression testing of Web services Compendex were not considered. Timeline restrictions
is challenging compared with traditional software may also cause bias because we only included the most
systems. CIA techniques must be leveraged for multi- recent studies. The justification for the timeline restriction
perspective regression testing. Other applications of is that initial research on the topic revealed that potential
CIA in service based systems include process model work in this area started during and after 2007.
refactoring at the business level and fault localization An internal threat to validity may concern data extrac-
at the service level. tion, as the main author solely performed data extraction,
(7) Most propagation mechanisms require substantial thus potentially posing a risk of bias to some extent.
manual help from maintainers. There is a need of Although four researchers participated in the study eva-
more rigorous automated propagation solutions. luation phase, they were not involved in the data extrac-
(8) The majority of studies have used small-scale experi- tion step. Finally, although we ensured the search process
ments and examples for proposed technique valida- can be replicated by other researchers, certain factors may
tion. Industrial case studies are necessary in this hinder the guarantee that others could produce exactly the
domain. same results. The factors include manual inclusion of
(9) Most CIA techniques have focused on static change relevant studies in the initial phase and considering
analysis. Dynamic change analysis requires further subjective factors during data extraction.
investigation. Dependency analysis before business
process enactment cannot reveal certain types of 4. Conclusion
dependencies. Moreover, large impact sets generated
by such poor analysis hinder understandability. Execu- Change management in service-oriented enterprises
tion trace analysis needs further investigation in this has emerged as a new research area entailing numerous
regard. Process mining techniques can be used to nontrivial issues and problems. Impact analysis and
explore inter-process dependencies from actual change propagation activities in service-oriented environ-
event logs. ments are more complex and challenging than traditional
software systems. This study was intended to system-
atically review available literature on change analysis and
3.12. Threats to validity propagation in service-based BPM systems. As SOA and
BPM are becoming dominant technologies and their nat-
For a comprehensive analysis of the results acquired ural alliance is a desirable solution for business agility and
from this systematic review, limitations of this review robustness, significant research work is necessary in this
must be considered. The main threats to this systematic domain. We considered the convergence of SOA and BPM
review's validity are selection bias, data extraction and across different layers of abstraction. A classification
analysis, and reliability. scheme was proposed in this regard, that covers both
To ensure that all potential studies in the prospective horizontal and vertical effects of changes across multiple
area have been covered, we performed extensive searches layers. Business processes, policies, process models and
on six main digital libraries. A manual collection of articles composite Web services were considered at the business
from other databases (Scopus, Web of Science) was also level, while component services and messaging protocols
added in the initial phase to ensure that highly relevant were considered at the service level. Another classification
articles are not excluded due to automatic search limita- scheme reflects the type of impact analysis and propaga-
tions that can emerge from alternative and ambiguous tion solutions. We have identified 60 articles relevant to
terms. Moreover, different names in publication titles may the 4 research questions. Results from the first
classification scheme revealed that dependency analysis [9] K. Dahman, F. Charoy, C. Godart, Alignment and change propagation
techniques followed by traceability analysis have largely between business processes and service-oriented architectures, in:
Proceedings of the 2013 IEEE International Conference on Services
been used for change impact analysis. Graph-based and Computing, 2013, pp. 168–175, doi:10.1109/SCC.2013.101.
formal dependency modeling techniques have widely [10] W. Dai, D. Covvey, P. Alencar, D. Cowan, Lightweight query-based
been adopted in the context of dependency analysis. The analysis of workflow process dependencies, J. Syst. Softw. 82 (6)
(2009) 915–931, http://dx.doi.org/10.1016/j.jss.2008.12.050.
findings revealed that research work in this area is in the
[11] H.K. Dam, A. Ghose, Supporting change propagation in the main-
early stages, and there are no mature tools and techniques tenance and evolution of service-oriented architectures, in: Proceed-
to provide end-to-end change analysis and propagation ings of the 2010 Asia Pacific Software Engineering Conference, 2010,
support. Particularly, the hierarchical effect of changes pp. 156–165, doi:10.1109/APSEC.2010.27.
[12] H.K. Dam, A. Ghose, Mining version histories for change impact
needs attention from the research community. Inter- analysis in business process model repositories, Comput. Ind. (2014),
process change analysis and propagation can be regarded http://dx.doi.org/10.1016/j.compind.2014.10.005.
as an established research area within our scope. However, [13] C Ekanayake, C. Rosa, M. La, A.H.M. Hofstede, M. Fauvet, Fragment-
Based Version Management for Repositories of Business Process
change assessment and propagation support across multi- Models, 2011, pp. 20–37.
ple businesses remains unexplored. Most studies focus on [14] W. Fdhila, A. Baouab, K. Dahman, C. Godart, O. Perrin, F. Charoy,
control and data flow aspects of business process change, Change propagation in decentralized composite web services, in:
Proceedings of the 7th International Conference on Collaborative
but neglect other important aspects. Bottom-up analysis is
Computing: Networking, Applications and Worksharing, 2011,
the most neglected area of research with very few studies pp. 508–511, doi:10.4108/icst.collaboratecom.2011.247097.
and no developed solution. Moreover, existing works [15] W. Fdhila, C. Indiono, S. Rinderle-Ma, M. Reichert, Dealing with
highlight specific types of service and business process change in process choreographies: design and implementation of
propagation algorithms, Inf. Syst. 49 (2015) 1–24, http://dx.doi.org/
dependencies. Research efforts must concentrate in these 10.1016/j.is.2014.10.004.
areas to effectively tackle the challenges of maintenance [16] W. Fdhila, S. Rinderle-ma, C. Indiono, Memetic Algorithms for
and evolution in service-based environments. Mining Change Logs in Process Choreographies, 2014, p. 62.
[17] Z. Feng, P.K. Hung, K. He, Y. Ma, M. Farwick, B. Li, R. Peng, Towards a
taxonomy framework of evolution for SOA solution: from a practical
5. Acronyms point of view, in A. Haller, G. Huang, Z. Huang, H. Paik, Q. Sheng
(Eds.), Web Information Systems Engineering – WISE 2011 and 2012
Workshops SE – 28, Springer Berlin Heidelberg, vol. 7652, 2013,
To improve the readability, Table 12 enlists acronyms pp. 261–274, doi:10.1007/978-3-642-38333-5_28.
used in this study along with their full forms. [18] J.A. Ginige, A. Ginige, An Algorithm for Propagating-Impact Analysis
of Process Evolutions, 2009, pp. 153–164.
[19] G. Grossmann, Modelling Inter-Process Dependencies with High-
Conﬂict of interests Level Business Process Modelling Languages, (Apccm), 2008, pp. 89–
102.
[20] S.E. Group, Guidelines for performing Systematic Literature Reviews
The authors declare that there is no conflict of interest in Software Engineering, 2007.
regarding the publication of this article. [21] A.E. Hassan, R.C. Holt, Predicting change propagation in software
systems, in: Proceedings of the 20th IEEE International Conference
on Software Maintenance, 2004, pp. 284–293, doi:10.1109/
ICSM.2004.1357812.
Acknowledgment [22] M.A. Hirzalla, A. Zisman, J. Cleland-Huang, Using traceability to
support SOA impact analysis, in: Proceedings of the 2011 IEEE World
Congress on Services, 2011, pp. 145–152, doi:10.1109/
This work is fully funded by Bright Spark Unit (BSP- SERVICES.2011.103.
1632-13), University of Malaya, Malaysia. [23] T.U. Ilmenau, S. Lehnert, Steffen Lehnert: A Review of Software
Change Impact Analysis.
[24] A. Ismail, J. Yan, J. Shen, Incremental service level agreements
References violation handling with time impact analysis, J. Syst. Softw. 86 (6)
(2013) 1530–1544, http://dx.doi.org/10.1016/j.jss.2013.01.052.
[1] V. Andrikopoulos, S. Benbernou, M.P. Papazoglou, S. Member, On the [25] S. Kabicher, S. Kriglstein, S. Rinderle-ma, Visual Change Tracking for
evolution of services, IEEE Trans. Softw. Eng. 38 (3) (2012) 609–628. Business Process Models, vol. 3, 2011, pp. 504–513.
[2] A. Basu, R.W. Blanning, A formal approach to workflow analysis, Inf. [26] H. Kagdi, M.L. Collard, J.I. Maletic, A Survey and Taxonomy of
Syst. Res. 11 (1) (2000) 17–36. Approaches for Mining Software Repositories in the Context of
[3] S. Basu, F. Casati, F. Daniel, Toward web service dependency Software Evolution, 2007, 77–131, doi:10.1002/smr.
discovery for SOA management, in: Proceedings of the 2008 IEEE [27] S.S. Khan, P. Greenwood, A. Garcia, A. Rashid, On the Impact of
International Conference on Services Computing, pp. 422–429, Evolving Requirements – Architecture Dependencies: An Explora-
doi:10.1109/SCC.2008.45. tory Study, n.d..
[4] S. Black, Computing ripple effect for software maintenance, J. Softw. [28] H. Khanh Dam, Predicting change impact in Web service ecosys-
Maint. Evol.: Res. Pract. 13 (4) (2001) 263–279, http://dx.doi.org/ tems, Int. J. Web Inf. Syst. 10 (3) (2014) 275–290, http://dx.doi.org/
10.1002/smr.233. 10.1108/IJWIS-03-2014-0006.
[5] S.A. Bohner, Impact Analysis in the Software Change Process: A Year [29] A.M. Khattak, K. Latif, S. Lee, Change management in evolving web
2000 Perspective, vol. 703, 2000, pp. 42–51. ontologies, Knowl.-Based Syst. 37 (2013) 1–18, http://dx.doi.org/
[6] C. Boldyreff, E.L. Burd, R.M. Hather, M. Munro, E.J. Younger, Greater 10.1016/j.knosys.2012.05.005.
understanding through maintainer driven traceability, in: Proceed- [30] O.M. Kherbouche, A. Ahmad, M. Bouneffa, H. Basson, Analyzing the
ings of the WPC'96, 4th Workshop on Program Comprehension, ripple effects of change in business process models, Inmic (2013)
pp. 100–106, doi: 10.1109/WPC.1996.501125. 31–36, http://dx.doi.org/10.1109/INMIC.2013.6731320.
[7] O. Bouchaala, M. Yangui, S. Tata, M. Jmaiel, DAT: Dependency [31] O.M. Kherbouche, A. Ahmad, M. Bouneffa, H. Basson, Ontology-
Analysis Tool for Service Based Business Processes, in: Proceedings based change impact assessment in dynamic business processes, in:
of the 2014 IEEE 28th International Conference on Advanced Proceedings of the 2013 11th International Conference on Frontiers
Information Networking and Applications, 2014, pp. 621–628, doi: of Information Technology, 2013, pp. 235–240, doi:10.1109/
10.1109/AINA.2014.76. FIT.2013.50.
[8] J. Cao, J. Wang, H. Zhao, M. Li, An Event View Specification Approach [32] S. Kijas, A. Zalewski, New Results in Dependability and Computer
for Supporting Service Process Collaboration, February, pp. 1943– Systems, vol. 224, 2013, pp. 255–273, doi:10.1007/978-3-319-00945-
1966, doi:10.1002/cpe. 2.
[33] L. Kuang, J. Wu, Y. Li, S. Deng, Z. Wu, Exploring Dependency between Springer, Berlin Heidelberg, 2005, pp. 153–168, http://dx.doi.org/
Interfaces in Service Matchmaking, 2007, 60603025. 10.1007/11538394_11.
[34] P. Kumar, A Review on Dependency Analysis of SOA based System, [59] S. Qi, B. Li, C. Liu, X. Wu, R. Song, A trust impact analysis model for
2014. composite service evolution, in: Proceedings of the 2012 19th Asia-
[35] T.A. Kurniawan, A.K. Ghose, H.K. Dam, Relationship-Preserving Pacific Software Engineering Conference, 2012, pp. 73–78,
Change Propagation, 2012, pp. 63–78. doi:10.1109/APSEC.2012.30.
[36] T.A. Kurniawan, A.K. Ghose, On Formalizing Inter-process Relation- [60] R. Ravichandar, N.C. Narendra, K. Ponnalagu, D. Gangopadhyay,
ships, 2012, pp. 75–86. Morpheus: semantics-based incremental change propagation in
[37] M.L. Lee, L. Li, Change Impact Analysis Of Object-Oriented Software, SOA-based solutions, in: Proceedings of the 2008 IEEE International
Technical Report ISE-TR-99-06, December 1998. Conference on Services Computing, 2008, pp. 193–201, doi:10.1109/
[38] S. Lehnert, A taxonomy for software change impact analysis, in: SCC.2008.16.
Proceedings of the 12th International Workshop and the 7th Annual [61] D. Romano, M. Pinzger, Using vector clocks to monitor dependencies
ERCIM Workshop on Principles on Software Evolution and Software among services at runtime, in: Proceedings of the International
Evolution – IWPSE-EVOL'11, vol. 1, 2011, p. 41, doi:10.1145/ Workshop on Quality Assurance for Service-Based Applications –
2024445.2024454. QASBA'11, 2011, p. 1, doi:10.1145/2031746.2031748.
[39] G.A. Lewis, D.B. Smith, A Research Agenda for Service-Oriented [62] S.H. Ryu, F. Casati, H. Skogsrud, B. Benatallah, R. Saint-Paul, Support-
Architecture (SOA): Maintenance and Evolution of Service-Oriented ing the dynamic evolution of Web service protocols in service-
Systems, March 2010. oriented architectures, ACM Trans. Web 2 (November) (2008) 1–46,
[40] B. Li, X. Sun, H. Leung, S. Zhang, A Survey of Code-based Change http://dx.doi.org/10.1145/1346337.1346241.
Impact Analysis Techniques, 2012, 10.1002/stvr. [63] T. Setzer, K. Bhattacharya, H. Ludwig, Change Scheduling Based on
[41] X. Liu, S. Akram, A. Bouguettaya, Change Management for Semantic Business Impact Analysis of Change-Related Risk, X, 2009 March,
Web Services, 2011, pp. 101–113, doi:10.1007/978-1-4419-9329-8. pp. 1–14.
[42] X. Liu, A. Bouguettaya, J. Wu, L. Zhou, Ev-LCS: a system for the [64] R. Sindhgatta, B. Sengupta, An extensible framework for tracing
evolution of long-term composed services, IEEE Trans. Serv. Comput. model evolution in SOA solution design, in: Proceedings of the 24th
6 (1) (2013) 102–115. ACM SIGPLAN Conference Companion on Object Oriented Program-
[43] S. Mafazi, G. Grossmann, W. Mayer, M. Stumptner, On-the-Fly ming Systems Languages and Applications – OOPSLA'09, 2009, p.
Change Propagation for the Co-evolution of Business Processes, 647, doi:10.1145/1639950.1639960.
2013, pp. 75–93. [65] H. Skogsrud, B. Benatallah, F. Casati, F. Toumani, Managing impacts
[44] N. Mani, D.C. Petriu, M. Woodside, Propagation of incremental of security protocol changes in service-oriented applications, in:
changes to performance model due to SOA design pattern applica- Proceedings of the 29th International Conference on Software
tion, in: Proceedings of the ACM/SPEC International Conference on Engineering (ICSE'07), 2007, pp. 468–477, doi:10.1109/ICSE.2007.49.
International Conference on Performance Engineering – ICPE'13, [66] P. Sun, C. Jiang, Analysis of workflow dynamic changes based on
2013, p. 89, doi:10.1145/2479871.2479887. Petri net, Inf. Softw. Technol. 51 (2) (2009) 284–292, http://dx.doi.
[45] C. Mao, Slicing Web Service-based Software, vol. 00(c), 2009, pp. 0– org/10.1016/j.infsof.2008.02.004.
7. [67] I. Systems, G. Email, ADEPT Flex – Supporting Dynamic Changes of
[46] B. Medjahed, Z. Malik, Bottom-up fault management in composite Workflows Without Loosing Control, 1997.
[68] F. Traceability, B. Traceability, Bidirectional Requirements Traceabil-
web services, in: H. Mouratidis, C. Rolland (Eds.), Advanced Informa-
ity By Linda Westfall, 2009.
tion Systems Engineering SE – 44, vol. 6741, Springer, Berlin
[69] S. Tragatschnig, H. Tran, U. Zdun, Impact Analysis for Event-based
Heidelberg, 2011,
Systems using Change Patterns, 2014.
pp. 597–611, http://dx.doi.org/10.1007/978-3-642-21640-4_44.
[70] M. Treiber, H. Truong, S. Dustdar, On Analyzing Evolutionary
[47] J. Michura, M.A.M. Capretz, S. Wang, Extension of Object-Oriented
Changes of Web Services, vol. 215483, 2013, pp. 284–297.
Metrics Suite for Software Maintenance, 2013(i).
[71] W. Uronkarn, T. Senivongse, Change Pattern-Driven Traceability of
[48] G. Monsieur, M. Snoeck, W. Lemahieu, Managing data dependencies
Business Processes, I, 2014.
in service compositions, J. Syst. Softw. 85 (11) (2012) 2604–2628,
[72] W.M.P. Van der Aalst, Business process management: a comprehen-
http://dx.doi.org/10.1016/j.jss.2012.05.092.
sive survey, ISRN Softw. Eng. 2013 (2013) 1–37, http://dx.doi.org/
[49] M. Nečaský, J. Klímek, J. Malý, I. Mlýnková, Evolution and change
10.1155/2013/507984.
management of XML-based systems, J. Syst. Softw. 85 (3) (2012)
[73] H.J. Wang, J.L. Zhao, Constraint-centric workflow change analytics,
683–707, http://dx.doi.org/10.1016/j.jss.2011.09.038.
Decis. Support Syst. 51 (3) (2011) 562–575, http://dx.doi.org/
[50] P. Novotny, B.J. Ko, A. Wolf, On-demand discovery of software
10.1016/j.dss.2011.03.001.
service dependencies in MANETs, IEEE Trans. Netw. Serv. Manag. [74] M. Wang, L. Cui, An impact analysis model for distributed Web
4537 (c) (2015) 1, http://dx.doi.org/10.1109/TNSM.2015.2410693. service proces, in: Proceedings of the 2010 14th International
[51] G.A. Oliva, M.A. Gerosa, D. Milojicic, V. Smith, A Change Impact Conference on Computer Supported Cooperative Work in Design,
Analysis Approach for Workflow Repository Management, in: Pro- 2010, pp. 351–355, doi:10.1109/CSCWD.2010.5471950.
ceedings of the 2013 IEEE 20th International Conference on Web [75] S. Wang, M.A.M. Capretz, A dependency impact analysis model for
Services, 2013, pp. 308–315, doi:10.1109/ICWS.2013.49. web services evolution, in: Proceedings of the 2009 IEEE Interna-
[52] A.M. Omer, A. Schill, Dependency based automatic service composi- tional Conference on Web Services, 2009, pp. 359–365, doi:10.1109/
tion using directed graph, in: Proceedings of the 2009 Fifth Inter- ICWS.2009.62.
national Conference on Next Generation Web Services Practices, [76] S. Wang, M.A.M. Capretz, Dependency and entropy based impact
2009, pp. 76–81, doi:10.1109/NWeSP.2009.20. analysis for service-oriented system evolution, in: Proceedings of
[53] M.P. Papazoglou, Service-Oriented Computing: Concepts, Character- the 2011 IEEE/WIC/ACM International Conferences on Web Intelli-
istics and Directions, 2003. gence and Intelligent Agent Technology, 2011, pp. 412–417,
[54] M.P. Papazoglou, V. Andrikopoulos, S. Benbernou, Managing evol- doi:10.1109/WI-IAT.2011.196.
ving services, IEEE Softw. 28 (3) (2011) 49–55, http://dx.doi.org/ [77] Y. Wang, Y. Wang, A survey of change management in service-based
10.1109/MS.2011.26. environments, Serv. Orient. Comput. Appl. 7 (4) (2013) 259–273,
[55] S. Park, D.-H. Bae, An approach to analyzing the software process http://dx.doi.org/10.1007/s11761-013-0128-4.
change impact using process slicing and simulation, J. Syst. Softw. 84 [78] Y. Wang, J. Yang, W. Zhao, J. Su, Change impact analysis in service-
(4) (2011) 528–543, http://dx.doi.org/10.1016/j.jss.2010.11.919. based business processes, Serv. Orient. Comput. Appl. 6 (2) (2011)
[56] S.L. Pfleeger, S.A. Bohner, A framework for software maintenance 131–149, http://dx.doi.org/10.1007/s11761-011-0093-8.
metrics, in: Proceedings of the Conference on Software Mainte- [79] Y. Wang, J. Yang, W. Zhao, J. Su, Change Impact Analysis in Service-
nance, 1990, pp. 320–327, doi:10.1109/ICSM.1990.131381. based Business Processes, 2012, pp. 131–149, doi:10.1007/s11761-
[57] D. Popescu, J. Garcia, K. Bierhoff, N. Medvidovic, Impact analysis for 011-0093-8.
distributed event-based systems, in: Proceedings of the 6th ACM [80] B. Weber, M. Reichert, S. Rinderle-Ma, Change patterns and change
International Conference on Distributed Event-Based Systems, ACM, support features – enhancing flexibility in process-aware informa-
New York, NY, USA, 2012, pp. 241–251, doi:10.1145/ tion systems, Data Knowl. Eng. 66 (3) (2008) 438–466, http://dx.doi.
2335484.2335511. org/10.1016/j.datak.2008.05.001.
[58] F. Puhlmann, M. Weske, Using the π-calculus for formalizing work- [81] M. Weidlich, J. Mendling, M. Weske, Propagating changes between
flow patterns, in: W.P. van der Aalst, B. Benatallah, F. Casati, aligned process models, J. Syst. Softw. 85 (8) (2012) 1885–1898,
F. Curbera (Eds.), Business Process Management SE – 11, vol. 3649, http://dx.doi.org/10.1016/j.jss.2012.02.044.
[82] M. Winkler, T. Springer, E.D. Trigos, Analysing Dependencies in analysis, Inf. Softw. Technol. 56 (1) (2014) 40–53, http://dx.doi.org/
Service Compositions, 2010, pp. 123–133. 10.1016/j.infsof.2013.07.001.
[83] P.H. Wong, J. Gibbons, A process-algebraic approach to workflow [89] L. Zhang, A. Arsanjani, A. Allam, D. Lu, Y. Chee, Variation-Oriented
specification and refinement, in: M. Lumpe, W. Vanderperren (Eds.), Analysis for SOA Solution Design, (Scc), 2007.
Software Composition SE – 5, vol. 4829, Springer, Berlin Heidelberg, [90] L.-J. Zhang, Z.-H. Mao, N. Zhou, Design quality analytics of trace-
2007, pp. 51–65, http://dx.doi.org/10.1007/978-3-540-77351-1_5. ability enablement in service-oriented solution design environment,
[84] Q. Wu, C. Pu, A. Sahai, R.S. Barga, Categorization and optimization of in: Proceedings of the 2009 IEEE International Conference on Web
synchronization dependencies in business processes, in: BT – Services, 2009, pp. 944–951, doi:10.1109/ICWS.2009.145.
Proceedings of the 23rd International Conference on Data Engineer- [91] D. Zhao, S. Liu, L. Wu, R. Wang, X. Meng, Hypergraph-based service
ing, ICDE 2007, The Marmara Hotel, Istanbul, Turkey, April 15–20, dependency resolving and its applications, in: Proceedings of the
2007, doi:10.1109/ICDE.2007.367876.
2012 IEEE Ninth International Conference on Services Computing,
[85] H. Xiao, J. Guo, Y. Zou, Supporting change impact analysis for service
2012, pp. 106–113, doi:10.1109/SCC.2012.25.
oriented business applications, in: Proceedings of the International
[92] X. Zhao, C. Liu, Version management for business process schema
Workshop on Systems Development in SOA Environments,
evolution, Inf. Syst. 38 (8) (2013) 1046–1069, http://dx.doi.org/
SDSOA'07: ICSE Workshops 2007, 2007, p. 6, doi:10.1109/
SDSOA.2007.11. 10.1016/j.is.2013.03.006.
[86] M. Yamashita, B. Vollino, K. Becker, R. Galante, Measuring change [93] Z. Zhou, S. Bhiri, M. Hauswirth, Control and data dependencies in
impact based on usage profiles, in: Proceedings of the 2012 IEEE business processes based on semantic business activities, in: Pro-
19th International Conference on Web Services, 2012, pp. 226–233, ceedings of the 10th International Conference on Information
doi:10.1109/ICWS.2012.35. Integration and Web-Based Applications & Services – iiWAS'08,
[87] Q. Yu, X. Liu, A. Bouguettaya, B. Medjahed, Deploying and managing 2008, p. 257, doi:10.1145/1497308.1497356.
web services: issues, solutions, and directions, VLDB J. 17 (3) (2006) [94] T. Zimmermann, S. Member, P. Weißgerber, S. Diehl, A. Zeller, I.
537–572, http://dx.doi.org/10.1007/s00778-006-0020-3. C. Society, Mining version histories to guide software changes, IEEE
[88] H. Zhang, J. Li, L. Zhu, R. Jeffery, Y. Liu, Q. Wang, M. Li, Investigating Trans. Softw. Eng. 31 (6) (2005) 429–445.
dependencies in software requirements for change propagation

Information Systems: Khubaib Amjad Alam, Rodina Ahmad, Adnan Akhunzada, Mohd Hairul Nizam MD Nasir, Samee U. Khan

Uploaded by

Copyright:

Available Formats

Information Systems: Khubaib Amjad Alam, Rodina Ahmad, Adnan Akhunzada, Mohd Hairul Nizam MD Nasir, Samee U. Khan

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Information Systems: Khubaib Amjad Alam, Rodina Ahmad, Adnan Akhunzada, Mohd Hairul Nizam MD Nasir, Samee U. Khan

Uploaded by

Copyright:

Available Formats

Information Systems 54 (2015) 43–73

Contents lists available at ScienceDirect

Impact analysis and change propagation in service-oriented

Fig. 1. Study selection procedure.

Inclusion and exclusion criteria

Table 3 2.2. Data sources

2.3. Search terms

The following search terms are based on major terms

(1) “Change analysis” OR “Impact analysis” OR “depen-

Dependency Control Flow

Change Impact Anlaysis

Fig. 3. Types of change impact analysis in traditional software systems.

Fig. 4. Classification according to the type of analysis and support.

Before reporting the results from the analysis and

Fig. 5. Order processing process.

Fig. 6. Business process model of order processing.

Fig. 7. Sub-process to calculate total amount.

Fig. 8. Abstract services and their relationships at composite service level.

Fig. 9. Component services and their relationships at component service level.

Fig. 10. Classification according to hierarchical coverage.

Changes in Service Based

Business Process Composite Service Component

Process Schema Process Instance Non- Non-

Fig. 11. Types of changes in service-based systems.

Fig. 12. Types of dependencies existing across layers of abstraction.

Inventory check service

Check credit Card Service

Fig. 13. Inter- and intra-dependence at between services.

Fig. 14. Impact of business level changes in order processing scenario.

Reference Publication Publication Emp. research Contribution Focus

Inter-process change analysis and propagation

Top-down change analysis and propagation

Fig. 15. Impact of service level changes in order processing scenario.

Reference Publication Publication Empirical research Contribution Focus

Bottom up change analysis and propagation

Inter-service change analysis and propagation

Ref. Approach Tools Coverage Entities Dependencies/change operations Scope

Graph based analysis

Ref. Approach Tools Coverage Entities Dependencies/change operations Scope

Execution trace analysis

Ref. Approach Tools Coverage Entities Dependencies/change operations Scope

Reference Classification Technique Support Scope Change Op./patterns

Dimension Classification Studies

5 Top Down CIA & Propagation

Fig. 16. Chronological distribution of studies over the years.

A set of different impact analysis and propagation

Technique Tools Pre-requisite Merits De-merits Applicable

Venue Publisher Studies Count

There are a few studies on change quantification in

SOA Service oriented architecture AS Atomic service (component service)

BPM Business Process Management MSR Mining Software Repositories

You might also like