Prioritization of Component-to-Component Links for Testing ...
Transcript of Prioritization of Component-to-Component Links for Testing ...
Prioritization of Component-to-Component Links for Testing in Component Based
Systems
By Subash Kafle
B.S. in Aerospace Engineering, May 2009, Virginia Tech
M.S. in Aerospace Engineering, May 2011, Virginia Tech
A Dissertation submitted to
The Faculty of
The School of Engineering and Applied Science
of The George Washington University
in partial fulfillment of the requirements
for the degree of Doctor of Philosophy
August 31, 2015
Dissertation directed by
Shahram Sarkani
Professor of Engineering Management and Systems Engineering
Thomas A. Mazzuchi
Professor of Engineering Management and Systems Engineering
ii
The School of Engineering and Applied Science of The George Washington University
certifies that Subash Kafle has passed the Final Examination for the degree of Doctor of
Philosophy as of July 2nd, 2015. This is the final and approved form of the dissertation.
Prioritization of Component-to-Component Links for Testing in Component Based
Systems
Subash Kafle
Dissertation Research Committee:
Shahram Sarkani, Professor of Engineering Management and Systems Engineering,
Dissertation Co-Chair
Thomas Mazzuchi, Professor of Engineering Management and Systems Engineering & of
Decision Sciences, Dissertation Co-Chair
Timothy Blackburn, Professorial Lecturer in Engineering Management and System
Engineering, Committee Member
Paul Blessner, Professorial Lecturer in Engineering Management and System
Engineering, Committee Member
E. Lile Murphree, Professor of Engineering Management, Committee Member
iv
DEDICATION
Dedicated to my parents and to my lovely wife for everything they have done to
support me throughout the program.
v
ACKNOWLEDGEMENTS
I would like to thank Dr. Shahram Sarkani and Dr. Thomas Mazzuchi for their
immeasurable guidance and support to complete this research. I am also grateful to Dr. J.P.
Blackford for his support and feedback for the completion and approval of this research.
vi
ABSTRACT
Prioritization of Component-to-Component Links for Testing in Component Based
Systems
In recent years, with budgetary constraints and ever-changing mission
requirements, the government and private industries have shifted their focus towards
component based system development. The development of systems with commercial
off-the-shelf components expedites the development process and improves the
interoperability and reusability benefits, resulting in significant cost savings. However,
integrating the commercial off-the-shelf products and testing of the integrated system is
challenging. Correctly identifying dependencies between components and identifying
which dependencies to test is particularly difficult for large systems. Testing every
dependency is cost and time prohibitive, and budget limitations often lead to insufficient
resource allocation for testing, particularly for integration testing. The key to cost-
effective integration testing is identifying the type and significance of component
dependencies. This dissertation proposes the use of the multi-dimensional dependency
analysis to identify system components’ critical dependency, their interrelationships, and
their priority based on their computed dependency strengths.
This dissertation discusses the multi-dimensional dependency (MDD) analysis, a
method proposed by Kafle, Sarkani, and Mazzuchi (2015) for prioritization of
component-to-component links for testing based on interdependency analysis between
vii
the links. A structure matrix combined with network analysis and organizational
communication analysis is used to solve complex interdependency problems without
requiring previous knowledge of the dependency strength. The methodology is
demonstrated through a simple application to a component based system involving a
series of interdependency coefficients’ calculations to predict the critical dependency
during integration and testing activities. The methodology is then validated through
Markov chain analysis. Testing links are prioritized based on their interdependencies’
strengths and this is demonstrated through three case studies. The results show that the
MDD method correctly identifies link priorities and is easier to use than the weighted
model.
These results motivate further research in the area of interdependency analysis on
component links using network analysis and organizational communication analysis for
the prioritization of component-to-component links in large systems.
viii
TABLE OF CONTENTS
DEDICATION ............................................................................................................... iv
ACKNOWLEDGEMENTS ............................................................................................. v
ABSTRACT ................................................................................................................... vi
TABLE OF CONTENTS ............................................................................................. viii
LIST OF FIGURES ....................................................................................................... xii
LIST OF TABLES ..................................................................................................... xviii
1. INTRODUCTION ....................................................................................................... 1
1.1. Research Questions ........................................................................................................ 5
1.2. Research Methodology .................................................................................................. 6
1.3. Organization of Document ............................................................................................ 8
1.4. Significance and Research Contributions .................................................................... 8
2. LITERATURE REVIEW ............................................................................................ 9
2.1. What Is Component Based System Development? .................................................... 9
2.1.1. System Components....................................................................................... 10
2.1.2. Component Development ............................................................................... 11
2.1.3. Component Based Software System ............................................................... 12
2.1.4. Component Based Software System Development ......................................... 13
2.1.5. Component Integration within a CBS ............................................................. 16
ix
2.1.6. Component Dependency within a CBS .......................................................... 17
2.2. Component Dependency Analysis Methods ............................................................. 20
2.2.1. Component Dependency Graph...................................................................... 20
2.2.2. Design Structure Matrix ................................................................................. 21
2.2.3. Component Based or Architecture DSM ........................................................ 27
2.3. Component Dependency Analysis Challenges ......................................................... 31
2.4. Component Dependency Analysis Solutions ............................................................ 33
2.4.1. Source Code Based Dependency Analysis Solutions ...................................... 34
2.4.2. Description and Model Based Dependency Analysis Solutions ...................... 37
2.5. Component Dependency Solutions Application Areas ........................................... 38
2.5.1. Change Impact Analysis ................................................................................ 38
2.5.2. Integration and Testing .................................................................................. 41
2.6. Why is Components’ Links Prioritization Important? ............................................. 42
2.7. Related Work ................................................................................................................ 44
3. METHODS ............................................................................................................... 46
3.1. Examination of System Architecture ......................................................................... 47
3.1.1. System Adjacency DSM (P) .......................................................................... 48
3.1.2. System Affiliation Matrix (A) ........................................................................ 49
3.2. Investigation of Dependencies between Links ......................................................... 52
3.2.1. Explicit Dependency between Links ............................................................. 53
x
3.2.2. Implicit Dependency between Links ............................................................. 54
3.3. Analysis of Link Priorities .......................................................................................... 57
4. EMPIRICAL EVALUATION THROUGH CASE STUDIES .................................... 60
4.1. Hypotheses .................................................................................................................... 60
4.2. Design of the Evaluation Approach ........................................................................... 60
5. CASE STUDY ANALYSIS – I ................................................................................. 63
5.1. Step 1: Examination of System Architecture. Identification of P and A ............... 64
5.2. Step 2: Investigation of Dependencies between Links. Derivation of E and I ..... 65
5.3. Step 3: Analysis of Link Priorities ............................................................................. 70
5.4. Theoretical Validation using Markov Chain ............................................................. 71
5.5. Case Study I Results Analysis .................................................................................... 75
6. CASE STUDY ANALYSIS – II ................................................................................ 78
6.1. Step 1: Examination of System Architecture ............................................................ 79
6.2. Step 2: Investigation of Dependencies between Links ............................................ 79
6.3. Step 3: Analysis of Link Priorities ............................................................................. 80
6.4. Theoretical Validation using Markov Chain ............................................................. 82
6.5. Case Study II Results Analysis ................................................................................... 87
7. CASE STUDY ANALYSIS – III............................................................................... 92
7.1. Step 1: Examination of System Architecture ............................................................ 93
7.2. Step 2: Investigation of Dependencies between Links ............................................ 94
xi
7.3. Step 3: Analysis of Link Priorities ............................................................................. 97
7.4. Theoretical Validation using Markov Chain ........................................................... 101
7.5. Case Study III Results Analysis ............................................................................... 107
8. SUMMARY OF RESULTS .................................................................................... 112
8.1. Discussion .................................................................................................................... 112
8.2. Possible Future Improvements .................................................................................. 116
8.3. Validity Analysis ........................................................................................................ 117
9. CONCLUSIONS ..................................................................................................... 119
REFERENCES............................................................................................................ 124
APPENDIX A. Flowcharts for the MDD and Markov Chain Methods ......................... 136
APPENDIX B. Matlab Code Used for MDD Method .................................................. 138
APPENDIX C. Excel Calculation Used for Markov Chain Method ............................. 142
xii
LIST OF FIGURES
Figure 1-1. Increase in US technology market due to the increase in technology
purchases by government and business (Bartles, 2013) ............................................ 2
Figure 1-2. System recovery state after a disaster with newly established links,
which require testing (Kafle, Sarkani, and Mazzuchi, 2015) ..................................... 4
Figure 1-3. Methodology used in this research to answer the research questions .............. 7
Figure 2-1. Component based systems. (a) System consisting of subcomponents,
modules, and components. (b) System consisting of modules and components
(Yu, Mishra, & Ramaswamy, 2010)....................................................................... 11
Figure 2-2. Component model development environment with its major elements
identified (Abdellatief et al., 2012) ........................................................................ 12
Figure 2-3. Component development lifecycle and component forms in each phase
in the development lifecycle (Crnkovic et al., 2011) .............................................. 15
Figure 2-4. Component-component interface types. (a) Operational-based interface.
(b) Port-based interface (Crnkovic et al., 2011) ...................................................... 17
Figure 2-5. Representation of dependencies within a system with multiple
components (Yu, Mishra, and Ramaswamy, 2010) ................................................ 19
Figure 2-6. Component dependency graph (CDG) describing a system with
components, connection between components, and components’
reliabilities (Yu, Mishra, and Ramaswamy, 2010) .................................................. 21
Figure 2-7. A design structure matrix displaying the relationships between the
components of a system (Browning, 2001) ............................................................ 25
xiii
Figure 2-8. A design structure matrix capturing the dependency relationship
between components (C1, C2, C3 . . .) and attributes (r1, r2, r3 . . .)
(Browning, 2001) .................................................................................................. 26
Figure 2-9. A component based DSM showing materials’ interactions for
climate control system (Pimmler and Eppinger, 1994) ........................................... 28
Figure 2-10. Coupling values resulting from cluster analysis showing the
connection between components (a, b, c…) that are context-dependent
(Li, 2011) .............................................................................................................. 30
Figure 2-11. Coupling measures between columns representing components.
Columns 8 and 9 have 1–1 match for row 5, 0–1 match for row 3, and
1–0 match for row 9 (Adapted from Chen and Li, 2005) ........................................ 31
Figure 2-12. System architecture that consists of directed links representing
information flow between components .................................................................. 39
Figure 2-13. Design structure matrix showing (a) connectivity matrix and
(b) reachability matrix ........................................................................................... 40
Figure 3-1. High-level overview of the MDD method used in this research to
prioritize critical links in a CBS (Kafle, Sarkani, and Mazzuchi, 2015) .................. 47
Figure 3-2. System architecture used to examine the applicability, usability,
and effectiveness of the MDD method ................................................................... 48
Figure 3-3. System components’ architecture matrix representing relationships
and information exchanged between components ................................................... 49
Figure 3-4. Process used in this research to collect dependency information
for a system architecture ........................................................................................ 50
xiv
Figure 3-5. System components’ affiliation matrix used to capture
dependency and information exchange between components and links .................. 52
Figure 3-6. Explicit dependency between two links due to a common component
affiliated with the links .......................................................................................... 52
Figure 3-7. Implicit dependency between two links due to common link
between adjacent components ................................................................................ 53
Figure 3-8. System explicit dependency matrix showing dependencies
between links due to a common component affiliated with links ............................ 54
Figure 3-9. System implicit dependency matrix showing dependencies
between links due to common link between adjacent components .......................... 56
Figure 3-10. Total link dependency matrix, which is the result of both explicit
and implicit dependencies ...................................................................................... 58
Figure 3-11. Priority mapping based on the dependency strength captured in link
dependency matrix ................................................................................................. 58
Figure 3-12. Prioritized critical links based on the dependency strengths.
The higher the dependency strength, the higher the priority ................................... 59
Figure 4-1. Graphical representation of the evaluation approach high-level
activity steps used in the research .......................................................................... 62
Figure 5-1. System architecture being evaluated for case study I:
6 components and 7 links ....................................................................................... 63
Figure 5-2. Matrix capturing relationships between components. System
components adjacency DSM .................................................................................. 64
Figure 5-3. Matrix mapping relationships between components and links ...................... 65
xv
Figure 5-4. Dependency between links due to common components.
Explicit dependency matrix ................................................................................... 66
Figure 5-5. Number of instances a component is used as data flow between
components that are one link apart. PactualI ............................................................. 66
Figure 5-6. Number of instances a component is used as data flow between
components that are three links apart. PactualIII ........................................................ 67
Figure 5-7. Dependency between links due to a common link between
adjacent components. Implicit dependency matrix ................................................. 67
Figure 5-8. Demonstration of link priority calculation using the MDD
method for the example application ....................................................................... 69
Figure 5-9. Dependency strengths as a result of both explicit and implicit
dependencies. Total link dependency strength matrix (LDM) ................................. 70
Figure 5-10. Priority of links translated from the dependency strengths ......................... 71
Figure 5-11. Priorities of links mapped in the system architecture ................................. 71
Figure 5-12. Initial state diagram displaying initial uniform Markov chain;
(a) Initial state diagram; (b) Initial state matrix ...................................................... 72
Figure 5-13. Probability of the data being in a component ............................................. 73
Figure 5-14. Expected number of times data are in transient components ...................... 74
Figure 5-15. Probability that data will be absorbed in absorbing states........................... 74
Figure 5-16. Transition probabilities for the data being in a component ......................... 74
Figure 5-17. Markov transition probabilities results for links for case
study I system ........................................................................................................ 75
Figure 5-18. MDD transition probabilities results for case study I system ...................... 75
xvi
Figure 5-19. Comparison of dependency strength with respect to link 1 (d1)
obtained from Markov chain and MDD for the case study I system........................ 77
Figure 6-1. System architecture for case study II: 8 components and 9 links .................. 78
Figure 6-2. System adjacency matrix (P) ....................................................................... 79
Figure 6-3. System affiliation matrix (A) ....................................................................... 79
Figure 6-4. Explicit dependency matrix (E) ................................................................... 80
Figure 6-5. Implicit dependency matrix (I) .................................................................... 80
Figure 6-6. Link dependency matrix (LDM) representing the dependency strength
between links ......................................................................................................... 81
Figure 6-7. Priorities of links based on the dependency matrix ...................................... 81
Figure 6-8. Prioritized component links based on the MDD method for case study II .... 82
Figure 6-9. Initial state matrix ....................................................................................... 83
Figure 6-10. Initial probability of data being in a state ................................................... 83
Figure 6-11. Expected number of times data are in transient states................................. 84
Figure 6-12. Transition probabilities for the data being in a component ......................... 85
Figure 6-13. Markov transition probabilities results for links for case study II system ... 86
Figure 6-14. MDD transition probabilities results for case study II system..................... 88
Figure 6-15. Comparison of dependency strength with respect to link 1 (d1)
obtained from Markov chain and MDD for case study II system ............................ 90
Figure 7-1. Systems architecture for case study III – one-third of dependencies
containing double or triple links ............................................................................. 92
Figure 7-2. System adjacency matrix (P) ....................................................................... 93
Figure 7-3. System affiliation matrix (A) ....................................................................... 93
xvii
Figure 7-4. Explicit dependency matrix (E) for case study III system ............................ 95
Figure 7-5. Implicit dependency matrix (I) for case study III system.............................. 96
Figure 7-6. Link dependency matrix (LDM) representing the dependency strength
between links for case study III system .................................................................. 98
Figure 7-7. Priorities of links based on the dependency matrix .................................... 100
Figure 7-8. Prioritized component links based on the MDD method ............................ 101
Figure 7-9. Initial state matrix ..................................................................................... 102
Figure 7-10. Initial probability of data being in a state ................................................. 102
Figure 7-11. Expected number of times data are in transient states............................... 103
Figure 7-12. Transition probabilities for the data being in a component ....................... 104
Figure 7-13. Markov transition probabilities results for links for case study II
system ................................................................................................................. 106
Figure 7-14. MDD transition probabilities results for case study III system ................. 108
Figure 7-15. Comparison of dependency strength with respect to link 1 (d1)
obtained from Markov chain and MDD methods for case study III system ........... 110
xviii
LIST OF TABLES
Table 2-1. Major dependency types in a component based system (Li, 2003)................. 18
Table 2-2. Dependency analysis solutions for CBS, popular approaches used
in the solutions, and solutions’ application areas (Adapted from Arias, 2011) ........ 36
Table 2-3. Previous research and major publications in the areas of dependency
analysis, network analysis, and organizational communication analysis, and
identified research gaps in those areas .................................................................... 45
Table 3-1. Total number of instances of data flow through link d3 as data
originate at link d1 ................................................................................................. 56
Table 5-1. MDD method and Markov chain method transition probabilities
and link priorities for the case study system ........................................................... 76
Table 6-1. Probability table showing probability of data being absorbed in
absorbing states as they originate from transient states ........................................... 84
Table 6-2. MDD method and Markov chain method transition probabilities
and link priorities for the case study II system ....................................................... 89
Table 7-1. Probability table showing probability of data being absorbed in
absorbing states as they originate from transient states ......................................... 103
Table 7-2. MDD method and Markov chain method transition probabilities
and link priorities for case study III system .......................................................... 109
Table 8-1. High priority and low priority links summary for the MDD method
for the three case studies ...................................................................................... 113
Table 8-2. Dependency strengths average difference and standard deviation
results summary ................................................................................................... 114
xix
Table 8-3. Dependency strengths average difference and standard deviation
results summary ................................................................................................... 115
Table 8-4. Pearson chi-square test results on priority of links results summary ............ 116
1
1. INTRODUCTION
Significant research and activities by government and private industries targeted
the test and evaluation (T&E) phase due to its resource intensive nature. This phase plays
an important role in ensuring a system’s high quality and reliability (DAU, 2012). A
component based system (CBS), popular in research and commercial system
development, allows the reuse and easy replacement of components, creating the need for
extensive T&E effort. The efficient use of resources and reduced delivery and upgrade
time are advantages of component based development (Brereton and Budgen, 2000;
Crnkovic et al., 2005), provided an effective and efficient T&E process is in place.
Due to improved delivery time and resource use efficiency, CBS architecture has
gained popularity in research and commercial system development. A CBS allows the
reuse and easy replacement of components, which not only has increased the
effectiveness of the system but has also enabled the successful long life of the system
(Crnkovic and Larsson, 2002; Huang, Tsai, and Huang, 2009). A report published by
Forrester Research in 2013 predicted that the US technology market that incorporates
information technology purchases by government and business would grow by 6.2% in
2013 and by 6.8% in 2014 (Figure 1-1) (Bartles, 2013). According to the same source,
improvements in areas such as SaaS (Software as a Service) and component based
software enabled analytical and collaboration systems, leading to significant growth
(Bartles, 2013).
2
Figure 1-1. Increase in US technology market due to the increase in technology
purchases by government and business (Bartles, 2013)
In a CBS, engineering components are put together and assembled in a
specialized form so that they interoperate. A component’s parameters carry the physical
properties whereas the attributes describe the behavioral properties of a system (Chen and
Li, 2005). Increasing the systems’ reliability involves the use of “high quality, pre-tested
and trusted software components” (Yacoub, Cukic, and Ammar, 2004; Jin and
Santhanam, 2001). As the systems developed are becoming increasingly more complex,
developers are adopting the idea of using and reusing component based technologies.
Thus, avoiding to “reinvent the wheel” enables developers to produce more functionality
with the same amount of resources and reduces development costs (Larsson, 2000).
System components that interact with one another exert dependencies between
them. These dependencies give rise to components’ “co-evolution,” i.e., changing one
component results in changes required to other components it is linked with. The higher
the number of dependent components in a complex system, the higher the component co-
evolution will be. An insufficient and incorrect co-evolution of system components not
only increases the programmer’s effort in testing but may also introduce errors, leading to
3
system failure (Yu, Mishra, and Ramaswamy, 2010). During the design of a new system
and redesign of an existing one, the management of design changes and iterations has
always been challenging in system development (Eppinger et al., 1994; Sosa, 2008).
When independently deployed components are brought together through
integration, they form component based system (Abdellatief et al., 2012). Integration
testing accounts for a large part of the T&E effort. In addition, efficient and effective
integration testing heavily relies on proper T&E strategy and planning. Focusing on
identifying and prioritizing the links between system components is important while
carrying out integration testing (DAU, 2012). For instance, in the case of disaster
recovery planning, it is vital to identify the priority of the links between a system’s
components. During the recovery phase following a disaster, components can be
recovered and the links between them can be established; however, testing of the links is
important to ensure the successful operation of the recovered system. This is particularly
important when the recovery state does not match the pre-disaster state (Figure 1-2). In
this case, identifying the high priority links for testing would enable the timely recovery
of the system. Current methods for prioritization of links for testing are neither sufficient
nor proven.
4
Figure 1-2. System recovery state after a disaster with newly established links,
which require testing (Kafle, Sarkani, and Mazzuchi, 2015)
The co-evolution behavior of system components imposes constant monitoring of
the system during its upgrade, update, and repair, as it results in changes in components
and ripple effects on others (Eppinger et al, 1994; Yu, Mishra, and Ramaswamy, 2010).
To address these scaling challenges, various dependency analysis methods and
techniques have been developed (Brown, Kar, and Keller, 2001; Arias, 2011). Many of
these methods, based on the design structure matrix (DSM), only identify the critical
components of a system and not the critical links between them.
Jungmayr (2002) mentions that just by looking at the coupling values between
components is not enough to predict test-critical links in a CBS. Our effort with this
research is to develop an approach to identify test-critical dependencies during regression
or integration testing.
This research proposes a method to identify link priority by investigating link
dependency. Using network analysis and organizational communication analysis as the
5
basis for solving complex interdependency problems, the multi-dimensional dependency
(MDD) method for prioritizing component-to-component links during testing was
developed (Kafle, Sarkani, and Mazzuchi, 2015). The analysis of dependencies between
component links involves the investigation of component-to-component relationship and
of component-to-link and link-to-link relationships. By using the DSM and modified
organizational communication and relationship analysis techniques, we can identify the
dependency between one link and the other links. Hence, it is possible to calculate the
priority of the links relative to each other based on the strength of their dependency. First,
the approach relies on the DSM, the existing dependency analysis method, to identify the
links between system components. Second, these links are further investigated using
modified organizational communication and relationship techniques to determine the
strength of their dependency. Third, analysis is performed to identify the link priorities.
Subsequently, the designed method is evaluated for improved accuracy in prioritization.
The proposed method is demonstrated through an application to a CBS. In
addition, the dependency analysis results obtained from applying the MDD method are
theoretically validated using Markov chain analysis. The results show that the MDD
method is effective, applicable, and easier to perform than the Markov chain method is
(Kafle, Sarkani, and Mazzuchi, 2015). The findings also demonstrate the potential
benefits of using network analysis and organizational communication analysis to
prioritize component-to-component links for a CBS.
1.1. Research Questions
As components are upgraded and updated in a CBS, their integration and testing
is crucial for the successful implementation of the system. For instance, let us assume
6
that the system shown in Figure 1-2 experiences a component failure. As the failed
component is repaired and reintroduced to the system, the links that connect it to the rest
of the systems’ components need to be tested to ensure successful operation. Therefore,
prioritizing the links to be tested becomes critical. As link prioritization applies to system
integration and testing, the following research questions are proposed:
RQ1: Is it possible to find a method to effectively prioritize links in a CBS based
on their importance?
RQ2: Is it possible to leverage component coupling and information flow analysis
in the method to identify critical links?
RQ3: Can the method be applied to complex system where there exist two or
more links between two components?
RQ4: Can the proposed method be easily compared with the existing methods?
1.2. Research Methodology
The MDD method is used to answer the research questions mentioned above.
After identifying the problem related to component link testing (Figure 1-3), the MDD
method is introduced and then evaluated through three applications that are progressively
more complex. Next, the data are collected and analyzed. To understand the significance
of the data collected from the MDD method, the system architecture used for an
application is analyzed using theoretical Markov chain analysis. Next, the dataset results
are compared, analyzed, and discussed in the context of the research questions.
7
Figure 1-3. Methodology used in this research to answer the research questions
Identify Problem
Introduce MDD
method as proposed
solution to address
the problem
Evaluation of MDD
method through case
studies
Data Collection and
Analysis
Theoritical
Validation of MDD
using Markov Chain
Discussion of the
Results
8
1.3. Organization of Document
This dissertation comprises six chapters. Chapter 1 introduces the research
problem. Chapter 2 presents the literature review and lists the current challenges of
requirements prioritization. The MDD method is introduced and explained step by step in
Chapter 3, while the planning, design, and execution of the evaluation approach for MDD
method is presented in Chapter 4. Evaluation of the method through multiple case studies
is carried out in Chapters 5–7. The data collected from the case studies are analyzed,
discussed, and summarized in Chapter 8, which also provides a detailed analysis of the
experiment validity. Finally, Chapter 9 presents the conclusions of this research and
reiterates the significance of the MDD method.
1.4. Significance and Research Contributions
The major contributions of the research are: (1) the introduction of the MDD
method for quantifying the dependency strengths between a systems’ component links;
(2) the application of the DSM and organizational communication analysis to identify
critical components’ links in a system; (3) the implementation of the MDD method
through the evaluation of multiple case studies; and (4) the evaluation of the effectiveness
and usability of the MDD method for CBS integration and links prioritization (Kafle,
Sarkani, and Mazzuchi, 2015). The calculation used in the research and the
demonstration steps is made available in the Appendix.
9
2. LITERATURE REVIEW
2.1. What Is Component Based System Development?
Systems built with architecture elements such as components and connectors as
their major elements enable the execution of some preliminary analysis that helps to
locate any defects or problems with the system design early in the development process
(Vestal, 1993; Shaw and Garlan, 1996; Allen and Garlan, 1997; Bass and Kazman, 1998;
Yacoub and Ammar, 2002). Component based system (CBS) development separates the
development of components from the development of the system, identifying them as two
separate activities and treating them accordingly. The conventional system development
process well known to engineers does not necessarily address all the aspects and needs of
component based system development (Mubarak and Alagar, 2012).
The component lifecycle, such as that of commercial-off-the-shelf components,
begins with defining component specification and transition over to system lifecycle with
integration where the components are continually operated and maintained (Crnkovic et
al., 2011). Because a CBS offers greater efficiency, reliability, and maintainability than
traditional systems development, many researchers agree that using a CBS is the best
practice toward time and cost effective development approach for systems (Bass et al.,
2000; Councill and Heineman, 2001; Crnkovic and Larsson, 2002; Aziz, Kadir, and
Yousif, 2012). These researchers also emphasize that the future shift towards
development of systems using the CBS practice is inevitable, as the complexity of the
systems developed is continuously increasing, so developers are adopting the idea of
using and reusing component based technologies. Compared with traditional systems
10
development, a CBS offers a shorter development lifecycle and quicker deployment
along with the ability to reuse the components (Sattar and Zang, 2014). Therefore, more
functionality is possible with the same amount of resources, and the development cost
and schedule are reduced (Abdellatief et al., 2012).
2.1.1. System Components
A component in a system can be defined as a relatively independent entity
representing a class, a number of functional modules, architecture, a source file or a
package, and so on (Mei, Zhang, and Yang, 2001; Yu, Mishra, and Ramaswamy, 2010;
Liu, 2012). A CBS comprises a set of independent components integrated to perform
specific functions, where performing a task involves interactions between components,
which result in their component links. Treated as a single unit in CBS development,
components could contain modules and sub-components (Figure 2-1). Guidelines,
models, methods, and so on are enabled for the development of a CBS (Larsson, 2000).
Figure 2-1a represents the subcomponents, modules, and components, and Figure 2-1b
represents only modules and components (Yu, Mishra, and Ramaswamy, 2010).
11
Figure 2-1. Component based systems. (a) System consisting of subcomponents,
modules, and components. (b) System consisting of modules and components (Yu,
Mishra, & Ramaswamy, 2010)
2.1.2. Component Development
Component development refers to the production of a functional independent
component that is then envisioned to be integrated with other components of a system
(Carnegie Mellon, 2012). The development of components for reuse and the development
of a software system using reusable components are two major elements of component
based software engineering (Abdellatief et al., 2012). Time and cost effective
development of software systems using component based software development is the
best practice (Councill and Heineman, 2001; Crnkovic and Larsson, 2002; Abdellatief et
al., 2012).
From developers’ perspective, the development of components involves design,
implementation, and maintenance, whereas users only require to know the right
components that fit their need and how to integrate these components into their CBS
Component
11
Component
2
Component
3
Component
4
Component
10
Component
9
Component
8
Component
6
Component
5
Component
7
module
1
Component 1
module
2
module
3
module
4
Component
11
Component
2
Component
3
Component
4
Component
10
Component
9
Component
8
Component
6
Component
5
Component
7
module
1
Component 1
Sub-Component 1
module
2
module
3
module
4
(a) (b)
12
(Abdellatief et al., 2012). Figure 2-2 shows a component model with its major elements
identified (Abdellatief et al., 2012).
Figure 2-2. Component model development environment with its major elements
identified (Abdellatief et al., 2012)
For a component based software system, the measurements of its associated
components should be based on its defining characteristics such as interface, methods,
properties, signatures, events, and dependencies (Han, 1998; Gill and Grover, 2004;
Sharma, Grover, and Kumar, 2009). For our research, components are treated from a
consumer perspective, i.e., internal code metrics and underlying developmental
methodology are ignored, and the focus is on interfaces, testability, suitability, and
dependencies.
2.1.3. Component Based Software System
“Object-oriented design, software architectures and architecture definition
language” (Crnkovic et al., 2011) are some of the techniques and technologies that
contribute to the existence of component based software engineering. A software system
integrates individually tested fully functional components (Carnegie Mellon, 2012).
Component Developers
Component
Specification
Component Based
Software System
Developers
Component
Interface
{Method Event Property}Body
Visible to
Visible to
Defines
Visible to
Visible to Visible to
Implements
13
Traditional engineering such as civil, mechanical, and electrical has a long history of
developing physical systems using hardware components. Software engineering, on the
other hand, is very different in its nature and principles. The development approach of
physical systems does not translate directly to the development of software systems.
Defining the components has never been an issue with traditional hardware-based
systems engineering, but there is an ongoing debate on the concept of components with
software systems (Crnkovic et al., 2011).
Several attempts have been made to define a software component. It was called a
composition unit which may be deployed independently and holds dependencies and
interfaces with other components and environments (Szyperski, 2002). Councill and
Heineman (2001) defined it as an element of software composed in accordance with
certain standards, independently deployable, and which can fit in to a system without any
major modification. A component which could be in a form of a software module that
consists of “execution code and machine-readable metadata” interacts with other
components in a system with the help of predefined rules (Crnkovic et al., 2011).
2.1.4. Component Based Software System Development
Component based system development comprises the same processes as the
traditional system development lifecycle: requirements, design, implementation,
deployment, and execution (Figure 2-3). The fundamental difference is that the
component based software system is not a programmed set of codes but an integrated set
of components. Each individual set of components serves a kind of functionality for a
service; hence, the component based software system is also known as service oriented
software system (Carnegie Mellon, 2012). The concept of a component starts with a set
14
of requirements and, as it moves to the design or modeling phase, the same set of
requirements morphs into a set of models. The set of models is then converted to source
code and metadata during the implementation phase. These components are integrated or
installed into a system during deployment and are executed in the form of executable
codes (Crnkovic et al., 2011). Depending on the need and requirement of the system
architecture, the components can either be built inside or outside system architecture.
Components built inside system architecture are governed by the granularity and
interconnection constraints of the architecture. For components built outside the system
architecture, the system architecture needs to accommodate the interconnection and
granularity requirements of the components (Carnegie Mellon, 2012).
15
Figure 2-3. Component development lifecycle and component forms in each phase in the development lifecycle (Crnkovic et
al., 2011)
requirements modeling implenentation packaging executiondeployment
Specification
- interface
-models
-meta data
Code
-source code
-executable code
-executable models
Storage
-repository
-package
-meta data
Installed files Executable code
Component Lifecycle
Components forms in a component lifecycle
16
Models designed during the modeling stage are used for the modeling and design
of components, and represent the architectural description of components and interfaces
between them. These models help generating the code with the use of programming
language and specified rules, and prior to their use, are stored in a repository with a set of
metadata. When a system is ready, the stored component is integrated and hence is ready
for execution (Crnkovic et al., 2011).
2.1.5. Component Integration within a CBS
The integration of components takes place as they are coupled to form subsystems
or subsystems and are brought together to form a product. In reference to the component
lifecycle seen in Figure 2-3, the integration of components happens toward the end of the
lifecycle between deployment and execution, followed by integration testing (Carnegie
Mellon, 2012). A component interface represents the significant characteristics of a
component, and can be specified by a set of functions and lists of associated parameters
through which a provider component communicates with the user component or system
(Crnkovic et al., 2011). There are various types of component interface. One type
involves the use of operations with parameters (Figure 2-4) (Crnkovic et al., 2011) as in
Java Beans (Oracle, 2014) and Open Services Gateway Initiative (OSGi Alliance, 2014).
Another type of component interface is port-based interface (Figure 2-4) (Crnkovic et al.,
2011), where data and events are received and sent using ports as in IEC61131 (Lydon,
2012) and SaveCCM (Mikael et al., 2007). Binding or wiring, also called component
composition, is a commonly used term in component based systems and represents the
interface and interactions (Councill and Heineman, 2001; Crnkovic and Larsson, 2002).
17
Figure 2-4. Component-component interface types. (a) Operational-based interface.
(b) Port-based interface (Crnkovic et al., 2011)
2.1.6. Component Dependency within a CBS
Wayne Stevens was one of the first to define dependency of components in a
software system (Arias, 2011). He defined component dependency as the degree to which
components in a software system are connected to one another. The connected
components are easier to understand if there are fewer connections (Stevens, Myers, and
Constantine, 1974).
For a system with components and modules, performing a task involves
interactions between those components and modules (Yu, Mishra, and Ramaswamy,
2010). These interactions establish dependencies: either cohesion or coupling between
them (Bieman and Ott, 1994; Bieman and Kang, 1998). Bixin Li (2003) categorized these
dependencies between components into eight categories (Table 2-1).
18
Table 2-1. Major dependency types in a component based system (Li, 2003)
Dependency Definition (Li, 2003)
Data dependency
“data defined in one component and being used by
another component”
Control dependency “produced by control integration of CBSs [component
based systems]”
Interface dependency
“when one component needs another component to do
something, it first sends a message to trigger an event
through its interface, then the event activates another
component to respond the message through interface of
another component”
Time dependency “the behavior of one component precedes or follows the
behavior of another one”
State dependency
“the behavior of basic component will not happen unless
the system, or some part if the system, is in a specified
state”
Cause and effect
dependency
“the behavior of one component implies the behavior of
another component”
Input/Output dependency “a component requires/provides information from/to
another component”
Context dependency “a component runs must be under special context
environment”
Used widely to measure software design qualities, cohesion dependency is
defined as dependency within a component, whereas dependency across components is
called coupling (Pressman and Darrel Ince, 1992; Schach, 2002; Yu, Mishra, and
Ramaswamy, 2010). In an effort to streamline the definition of dependency in a system
(Podgurski and Clarke, 1990; Loyall and Mathisen, 1993; Stafford and Wolf, 1998;
Mehta, Medvidovic, and Phadke, 2000; Cox, Delugach, and Skipper, 2001) agreed that
dependency is simply a relationship between components of a system, and these
dependencies establish a mechanism through which data and control information such as
function calls and other commands can be exchanged between the components. When
19
changes are made to a component or system, the necessary changes will be required to
one or more related components and systems (Arias, 2011).
For a dependent component, classes, functions, methods, and variables defined in
other components are crucial for it to function as specified in a system (Yu, Mishra, and
Ramaswamy, 2010). In Figure 2-5, the arrows pointing from a component indicate that
the component is dependent on other components. For example, an arrow is pointing
from Component 1 to Component 4 but not to Component 9; hence, Component 1 is
dependent on Component 4 and not dependent on Component 9 (Yu, Mishra, and
Ramaswamy, 2010).
Figure 2-5. Representation of dependencies within a system with multiple
components (Yu, Mishra, and Ramaswamy, 2010)
Component
11
Component
2
Component
3
Component
4
Component
10
Component
9
Component
8
Component
6
Component
5
Component
7
module
1
Component 1
module
2
module
3
module
4
20
2.2. Component Dependency Analysis Methods
2.2.1. Component Dependency Graph
Commonly used for the analysis of system reliability using architecture
information, the component dependency graph (CDG) describes a system, its
components, the connection between components, and components’ reliabilities
(Qingquan and Yang, 2012). For an architecture, CDG represents components using
nodes and the relation between the components through edges (Yoon et al., 2013).
Yacoub, Cukic, and Ammar (1999) defined CDG as a probabilistic model to analyze the
reliability of distributed component based system architecture. Through control flow
graph CDG models a component based system as a combination of subsystems,
components, and connectors between components (Yacoub and Ammar, 2002).
Developed from interactions triggered by a specific input stimulus, CDGs are directed
graphs that represent components and connectors, and their reliabilities and transition
probabilities (Weidenhaupt et al., 1998).
As a reliability analysis model, a CDG displays the dependencies between system
components and incorporates component and interaction execution probabilities (Yacoub,
Cukic, and Ammar, 2004) (Figure 2-6).
21
Figure 2-6. Component dependency graph (CDG) describing a system with
components, connection between components, and components’ reliabilities (Yu,
Mishra, and Ramaswamy, 2010)
In software systems, control flow graphs are considered a popular approach
followed to reveal the structure, decision points, and branches in program code
(Medvidovic and Taylor, 2000). A CDG is an extension of control flow graphs and
represents the architectural dependencies in component based systems between
components and their execution paths or interfaces (Yacoub, Cukic, and Ammar, 2004).
2.2.2. Design Structure Matrix
Browning (2001) defined a design structure matrix (DSM) as a “simple, compact
and visual representation of a complex system.” The design structure matrix is also
commonly called dependency structure matrix (Srour et al., 2013). Product development,
<Component 1, RC1 = 0.2, EC1 = 3>
<Component 4, RC4 = 0.8, EC4 = 3>
<Component 3, RC3 = 0.7 EC3 = 6><Component 2, RC2 = 0.4, EC2 = 4>
<T12, RT12=1, PT12=0.8> <T13, RT13 = 1, PT13=0.2>
<T24, RT24=1, PT24=1><T34, RT34=0.9, PT34=1>
<T43, RT43=1, PT43=0.7>
S
t
PT4t=0.3
22
project planning and management, systems engineering, and organizational design are
some of the many areas where the DSM stands out as an effective dependency analysis
technique compared to its alternatives (Browning, 2001). Using a matrix to perform
analysis on complex projects has been done since the 1960s when the use of a DSM was
proposed to help analyze interrelationships between activities involved in system design
(Steward, 1965; Srour et al., 2013). Many research studies have been published in recent
years in areas of DSM application, such as manufacturing, construction, and project
management (Ramadan, 2011; Sharman, 2007; Browning, 2001; Srour et al., 2013).
Industries such as building construction (Huovila et al., 1997; Baldwin et al., 1998;
Austin et al., 2000), electronics (Osborne, 1993; Carrascosa, Eppinger, and Whitney,
1998), automotive (Sequeira, 1991; Smith and Eppinger, 1997; Malmström and
Malmqvist, 1998; Rushton and Zakarian, 2000), photographic (Ulrich, Eppinger, and
Goyal, 2011), and aerospace (Grose, 1994; Browning, 1996; Clarkson and Hamilton,
2000; Ahmadi, Roemer, and Wang, 2001) have immensely benefited from the
implementation of the DSM as an analysis tool.
A DSM distinguishes itself from other network modeling methods through the
graphical nature of the matrix display format, which is concise, easily scalable, and easy
to read (Eppinger and Browning, 2012). The representation of component dependencies
and interfaces in a large system comprised of a large number of interrelated components
using the CDG is challenging and hard to follow. The DSM offers an accurate
representation of information exchange between system components in a matrix form
and, hence, is a popular dependency analysis technique (Srour et al., 2013).
23
The functional dependency matrix, design decomposition matrix, and design
schedule matrix are some of the many matrix-based models that designers and engineers
use in architectural decomposition (Kusiak and Wang, 1993; Michelena and
Papalambros, 1995; Altus, Kroo, and Gage, 1996; Browning, 2001). The DSM provides a
systematic and innovative framework for a complex system development process. The
framework primarily consists of the basic fundamental phases of decomposition into
elements, understanding of the interfaces between the elements, and analysis of potential
integration of the elements through clustering (Pimmler and Eppinger, 1994; Browning,
2001). The DSM is mainly used to capture the information flow of a directed graph in a
square matrix form, with each cell of the matrix recording the relationship between the
entities of the graph such as component–component or element–element (Chen and Li,
2005).
The DSM is applicable to capture critical interfaces between components of a
system; it is also an effective tool to map the technical communication patterns between
the teams that are involved with the architecture design for the system being developed
(Sosa, 2008). Steward (1981) named the time-based matrix “design structure matrix”
while analyzing the structure of a system design process (Browning, 2001). Before the
introduction of the DSM, engineers and developers had been using the “precedence
diagram” to facilitate the task of managing system development projects (Fernando,
1969; Hayes, 1969). Browning (2001) echoed that the use of matrix during the design of
products, process, and organizations enables visibility of the interdependencies and
interrelationships between components and structural elements.
24
Static and time-based are two design structure matrix types. A static DSM
represents simultaneously the existing system elements, and a dynamic DSM represents
time-dependent process activities (Browning, 2001). Systems engineers have been using
static DSMs to represent simultaneously existing architectural component interfaces,
which are commonly known as architecture DSM and are usually analyzed with
clustering algorithms (Browning, 2001). Similarly, organization designers have been
using static DSMs, also called organization DSMs, to manage communication networks
and interactions between individuals, groups, or teams in an organization and their
relationships (Lorsch and Lawrence, 1972; Lano, 1979; Kockler et al., 1990; Becker,
Asher, and Ackerman, 2000). Time-based DSMs represent activities that are dependent
through time. When a downstream activity depends on the execution of an upstream
activity, the interfaces between these activities are represented by time-based DSMs and
are analyzed using sequencing algorithms (Browning, 2001). Depending on the
application, systems engineers, project managers, project planners, and developers use
the four most popular DSM applications (Browning, 1999):
Component based or architecture DSM
Team based or organization DSM
Activity based or schedule DSM
Parameter based or low-level schedule DSM
Introduced as a matrix-based analytical tool (Steward, 1981), DSMs are used in
the complex product development world to represent and organize design tasks (Eppinger
et al., 1994). DSMs are also used to represent interactions between hardware and
software components of a product being developed (Pimmler and Eppinger, 1994;
25
MacCormack, Rusnak, and Baldwin, 2006; Sharman and Yassine, 2007; Lai and
Gershenson, 2008). With the use of matrix based analysis, the architecture of a product
being developed, its interconnected processes, and dependent teams and organizations
can be analyzed (Sosa, 2008).
The triangularization algorithm (Kusiak and Wang, 1993), genetic algorithm
(Altus, Kroo, and Gage, 1996; Rogers, McCulley and Bloebaum, 1996), tearing and
partitioning (Steward, 1981), and cluster analysis (Chen & Lin, 2003) are some DSM
based decomposition algorithms used in project management (Brady, 2002), process
planning (Kusiak and Wang, 1993), and product development (Eppinger, 2002).
The DSM, a widely used approach in analysis of decomposition and integration,
is a compact visual aid that displays relationships between the components of a system in
a square matrix (Browning, 2001) (Figure 2-7).
Figure 2-7. A design structure matrix displaying the relationships between the
components of a system (Browning, 2001)
The square matrix consists of identical rows and columns with off-diagonals cells
representing the dependency of one element on another. If an element provides
information to another element, it is represented by a filled cell across a row. Similarly, if
A B C D E F G H I
Element A 0 0 0 0 0 0 0 0
Element B 1 1 1 0 1 0 1 1
Element C 1 1 0 1 1 0 1 1
Element D 1 1 0 1 0 1 1 1
Element E 1 0 1 1 0 1 1 1
Element F 0 1 1 0 0 0 0 0
Element G 0 0 0 1 1 0 0 0
Element H 0 1 1 1 1 0 0 0
Element I 1 0 1 0 1 0 0 0
26
an element depends on another element, it is represented by a filled cell down a column
(Browning, 2001).
Let us consider a component based system architecture with 7 components and 6
attributes (Figure 2-8). Each component in a CBS has its associated characteristics, also
called attributes. Let C = {C1, C2, . . . , Cm} be the set of m components and R = {r1, r2,
r3, ……., rn} be the set of n attributes (Chen, Ding, and Li, 2005). Each attribute is
associated with a number of components. To capture the dependency relationship
between the components and their attributes, a rectangular matrix as seen below is
created; in this matrix, the columns represent the components and the rows represent the
attributes (Li, 2011). Let mij represent each entry on the matrix. The value of mij can be
positive if there is dependency between the component and the attribute, and 0 if there is
no dependency. For simplicity, the value of mij is either used as 1 or 0, i.e.,
[M] = [mij], mij = 1 if dependency exists
mij = 0 if no dependency exists
i = 1, 2, . . . , m; j = 1, 2, . . . n
Figure 2-8. A design structure matrix capturing the dependency relationship
between components (C1, C2, C3 . . .) and attributes (r1, r2, r3 . . .) (Browning,
2001)
C1 C2 C3 C4 C5 C6 C7
r1 1 1 0 0 0 0 0
r2 0 0 1 0 0 1 1
r3 0 0 1 1 0 1 0
r4 1 0 1 0 1 0 0
r5 0 0 0 1 0 0 1
r6 0 1 0 0 1 0 0
27
2.2.3. Component Based or Architecture DSM
A component based DSM is used to model the architecture of a CBS and the
interrelationships between components. The DSM represents the relationships between
the components and the elements of an architecture (Eppinger and Browning, 2012).
Team based DSMs are used to model the interactions of people or groups within an
organization. An activity based DSM models the dependencies and information flow
between processes and activity networks. Parameter based DSMs are used to model
design parameters, system equations, and their relationships (Browning, 1999).
The system architecture of a CBS holds information such as dependency and
relationships between system components. An architecture DSM helps in modeling of
these dependencies and relationships (Browning, 2001). A component based DSM is
commonly used to simplify the coordination demands between system components and
sub-components during product design and, hence, improve the quality (Pimmler and
Eppinger, 1994). In a component based large system, not every element of the system
interacts with every other element, as seen in the climate control system DSM in Figure
2-9, but all the interactions that exist in the system are essential to the successful
development and implementation of the system (Browning, 2001).
28
Figure 2-9. A component based DSM showing materials’ interactions for climate control system (Pimmler and Eppinger, 1994)
A B C D E F G H I J K L M N O P
Radiator A A 2
Engine Fan B 2 B 2
Heater Core C C 2
Heater Hoses D D
Condenser E 2 E 2 2
Compressor F 2 F 2 2
Evaporator Case G G 2
Evaporator Core H 2 2 H 2 2
Accumulator I 2 2 I
Refrigeration Controls J J
Air Controls K K
Sensors L L
Command Distribution M M
Actuators N N
Blower Controller O O 2
Blower Motor P 2 2 2 2 P
29
The interactions between the elements of a CBS can include energy, information,
material, etc. Energy interaction involves the need for energy transfer or exchange
between two elements; information related interaction comprises data or signal exchange
between two elements; and material interaction deals with material exchange between
two elements (Pimmler and Eppinger, 1994).
As seen in Figure 2-9, a DSM is a square matrix where the entries of the matrix
signify the dependency between any two elements of a system (Danilovic and Browning,
2007). Once entries are made into a DSM, there are two algorithms, namely clustering
algorithms and sequencing algorithms, that can be followed to further simplify the matrix
(Browning, 2001). In clustering algorithms, the elements are grouped based on their
attributes, and, hence, the architecture containing the number of elements is converted to
architecture with fewer groups of elements. Sequencing algorithms involve re-ordering of
activities in the matrix to a more arranged form, which enables the effective management
of process iterations (Li, 2011).
Cluster analysis is one of the mathematical techniques performed on the entries of
DSMs to analyze product architecture (Pimmler and Eppinger, 1994) and team
organization (McCord and Eppinger, 1993). Applied to classify one set of objects from
another by comparing their attributes (Romesburg, 2004), cluster analysis takes into
account the coupling values between any two objects (Kaufman and Rousseeuw, 2009).
In Figure 2-10, the coupling values show the connection of two objects that are context-
dependent and explain how the two objects should be clustered (Chen and Li, 2005; Li,
2011).
30
Figure 2-10. Coupling values resulting from cluster analysis showing the connection
between components (a, b, c…) that are context-dependent (Li, 2011)
Figure 2-11 shows the coupling measure between two columns, 8 and 9, which
depends on the number of common elements being shared (Chen and Li, 2005). The
coupling values are higher for columns that share more common elements (Chen and Li,
2005). Several clustering algorithms and techniques have been used by experts to carry
out cluster analysis in the context of matrix-based decomposition (Michelena and
Papalambros, 1995; Fernandez, 1998; Kusiak, 1999; Chen and Li, 2005). Connectivity
based (Hartuv and Shamir, 2000), centroid based (Zhang, Ramakrishnan, and Livny,
1996), distribution based (Romesburg, 2004), and density based (Ester et al., 1996) are
some popular clustering algorithms.
Jaccard’s resemblance technique is an example of connectivity based clustering
algorithm where the strength of coupling is measured between the two elements. element
i and element j, using the following equation (Chen and Li, 2005):
𝑟𝑐𝑜𝑙_𝑖𝑗 =∑ min(𝑚𝑘𝑖,𝑚𝑘𝑗)𝑚𝑘=1
∑ max(𝑚𝑘𝑖,𝑚𝑘𝑗)𝑚𝑘=1
𝑖, 𝑗 ∈ [1, 𝑛](2.1)
Here, 𝑟𝑐𝑜𝑙_𝑖𝑗 is the strength of the connectivity between the ith column and jth
column (Figure 2-11). A similar equation, given in Chen and Li (2005), is used to
measure the coupling strength between the rows. In the equation, the numerator is the
sum of instances where there occur 1–1 matches between the two columns and the
a b c d e
a X 0.86 0.28 0.68 0.22
b X 0.74 0.46 0.63
c X 0.15 0.71
d X 0.33
e X
31
denominator is the sum of total instances of 0–1, 1–1, and 1–0 matches (Chen and Li,
2005).
Figure 2-11. Coupling measures between columns representing components.
Columns 8 and 9 have 1–1 match for row 5, 0–1 match for row 3, and 1–0 match for
row 9 (Adapted from Chen and Li, 2005)
2.3. Component Dependency Analysis Challenges
As a system is repaired, replaced, modified, or upgraded, the relationships
between the components and links change. Keeping track of the relationships and
interrelationships between the system components and their links is challenging. When
managing component based system development efforts, system development managers
(Sosa, 2008) face two key challenges: identifying components’ interdependencies and
answering questions related to dependencies such as Which component needs to talk to
which component? or Which interfaces should components give priority to?
A user of a component based software system that is built via the dependency
inversion principle has to manage not just the components but also the interfaces (Huang,
Tsai, and Huang, 2009). Analysis techniques such as dependency analysis are usually
used to deal with these challenges (Larsson, 2000).
1 2 3 4 5 6 7 8 9 10
1
2
3
4
5
6
7
8
9
10
32
The dependency inversion principle, a widely used industrial standard design
principle, introduces the concept of interfaces in component based software systems
(Martin, 1996; Larsson, 2000; Fowler, 2004).
Dependency that exists between the structural components of a system is usually
referred to as structural dependency (Allen and Garlan, 1997; Stafford and Wolf, 1998).
Content dependencies, common dependencies, external dependencies, control
dependencies, stamp dependencies and data dependencies are some widely discussed
subcategories of structural dependencies (Stevens, Myers, and Constantine, 1974;
Podgurski and Clarke, 1990; Allen and Garlan, 1997; Stafford and Wolf, 1998; Balmas et
al., 2005). For a software system, structural dependencies exist in architecture and source
codes (Arias, 2011).
The analysis of component dependencies can also be defined as the study of the
mutual dependent relations of events in a system or coexisting systems (Chen, Tsai, and
Chao, 1993). For a system to work, its components interact through component links.
Various efforts have been made in producing methods, tools, and techniques to prioritize
components and identify the critical ones (Arias, 2011). Our research primarily focuses
on links between components that result from structural dependencies.
System components exhibit co-evolution behavior, i.e., changing one component
results in changes required to the other components that it is linked with, during its
upgrade, update, and repair (Eppinger et al., 1994; Yu, Mishra, and Ramaswamy, 2010).
To address these scaling challenges, various dependency analysis methods and
techniques have been developed (Brown, Kar, and Keller, 2001; Arias, 2011). Many of
these methods, based on the DSM, only identify the critical components of a system and
33
not the critical links. Prioritizing component dependency links is necessary to conduct
well-organized testing. Integration testing accounts for a large part of the test and
evaluation (T&E) effort. In addition, efficient and effective integration testing heavily
relies on proper T&E strategy and planning. Focusing on identifying and prioritizing the
links between system components is important while carrying out integration testing
(DAU, 2012). However, prioritizing the links is possible only with a method that
distinguishes links based on their dependencies. Testing of component links is a major
area of system testing in CBS. The analysis of these dependencies and their priorities
helps in planning the testing of these component links.
2.4. Component Dependency Analysis Solutions
Various efforts have been made to produce methods, tools, and techniques in
order to support the dependency analysis for software systems. During the design and
development phase, components are designed with a particular application in mind
(Arias, 2011). However, as these components are integrated into a system during
deployment in the field, the intended use of the components could change depending on
the end-user need (Brown, Kar, and Keller, 2001). An end-user might emphasize on
“performance, availability, and other visible metrics” (Brown, Kar, and Keller, 2001) of a
deployed system. The investigation of a deployed system from the end-user perspective is
commonly called “application level analysis and management” (Brown, Kar, and Keller,
2001).
In an effort to identify the effects and spread of failure in a system, information
about the structural and behavioral dependencies of a system’s major subsystems,
components, application, services, data repositories etc. is obtained through various
34
dependency analysis solutions (Arias, 2011). The analysis solutions benefit analysts in
managing system failures in the areas such as change impact management of component
based systems (Zhao, 2002; Hassan and Holt, 2004), change prediction (Kagdi and
Maletic, 2007), and prediction of defects and failures.
During the dependency analysis process, the source of information from a system
acts as input data. The high-level abstract information is the output, which is eventually
used by analysts to solve issues in various application areas. Information output and the
required interaction, or the degree of intervention, are some of the criteria of various
dependency analysis solutions (Arias, 2011). Based on the source of information, the
dependency analysis solutions are categorized into two major categories: source code
based and description and model based. Table 2-2 lists the dependency analysis
approaches and common application areas for source code based and description and
model based solutions.
2.4.1. Source Code Based Dependency Analysis Solutions
Source code describes the operation and assembly of a software system and is
widely used by practitioners to perform a dependency analysis on a system. Source code
includes the relationship evidence between “semantic and syntactic” code information
such as variables, operators, methods, and classes (Arias, 2011). Source code based
dependency analysis solutions are often used to identify structural dependencies of a
system. Based on the analysis approach, these solutions can be distributed into two major
groups: static and dynamic (Arias, 2011).
In regards to source code-based solutions, both static and dynamic analysis
approaches make use of the program dependency graph to recognize data and control the
35
relationship between variables, operators, objects, methods, etc., and identify the
traceability between code related artifacts, system features, and execution scenarios
(Ferrante, Ottenstein, and Warren, 1987; Podgurski and Clarke, 1990; Baah, Podgurski,
and Harrold, 2010; Arias, 2011). Static analysis techniques such as approximation
algorithms (Zhang and Ryder, 2007), search based slicing (Jiang, Harman, and Li, 2008),
or topology analysis (Robillard, 2008) reveal and organize dependency information.
Static analysis solutions are commonly used to retrieve system architecture information
(Chen and Rajlich, 2000). This information is then stored in graphs such as the program
dependency graph and matrices such as the DSM (Arias, 2011).
Dynamic analysis solutions are used to examine the behavior of components and
their interactions (Chen and Rajlich, 2000). Footprint graph analysis (Egyed, 2003;
Sundaram et al., 2010), object flow analysis (Lienhard, Greevy, and Nierstrasz, 2007),
and clustering (Beck and Dieh, 2010) are some dynamic dependency analysis techniques.
Application areas for dynamic analysis solutions include change impact analysis,
traceability, and others (Arias, 2011) (Table 2-2).
36
Table 2-2. Dependency analysis solutions for CBS, popular approaches used in the
solutions, and solutions’ application areas (Adapted from Arias, 2011)
Solution Approach
Application
Areas
References
Source code
based
Static
Change impact
analysis
Bohner, 2002; Orso,
Apiwattanapong, and Harrold,
2003; Hassan and Holt, 2004;
Maule, Emmerich, and
Rosenblum, 2008; Robillard,
2008
Architecture
analysis
Tran et al., 2000; Sangal et al.,
2005
Quality assurance
and testing
Beizer, 1984; Podgurski and
Clarke, 1990; Zhang and
Ryder, 2007
Dynamic
Change impact
analysis
Law and Rothermel, 2003;
Huang and Song, 2007;
Tallam and Gupta, 2007
Traceability and
feature analysis
Greevy and Ducasse, 2005;
Lienhard, Greevy, and
Nierstrasz, 2007; Cornelissen
et al., Koschke, 2009
Description
and model
based
Analysis of
diagrammatic
descriptions
Architecture
analysis
Vieira and Richardson, 2002;
Mancinelli et al., 2006
Change impact
analysis
Mao, Zhang, and Lu, 2007;
Khan et al., 2008; Zhang et
al., 2014
Analysis of
semi-formal
descriptions
Testing Chen, Probert, and Ural, 2007
Architecture
analysis
Stafford and Wolf, 1998;
Vieira and Richardson, 2002;
Stafford, Wolf, and
Caporuscio, 2003
37
2.4.2. Description and Model Based Dependency Analysis Solutions
Designers and researchers describe systems with the use of diagrammatic
descriptions such as chart, unified modeling language diagrams, and drawings with
blocks and arrows, and semi-formal descriptions such as architectural description
languages and interface description languages (Arias, 2011). Behavioral and structural
dependencies identified as dependency analyses are performed on these systems at
architectural level instead of source-code (Arias, 2011). Performing dependency analysis
using architectural models is detailed; however, there are significant challenges while
integrating formal descriptive architecture and semi-formal descriptive architecture
(Brøndum, 2012).
Table 2-2 lists dependency analysis solutions based on description and model
based architecture consisting of two major approaches, namely the analysis of
diagrammatic descriptions and the analysis of semi-formal descriptions (Arias, 2011).
Dependencies within a system architecture can be described with various
diagrammatic techniques, such as component based models (Vieira and Richardson,
2002), chart diagrams (Ryser and Glinz, 2000; Garousi, Briand, and Labiche, 2006),
business process models (Vasilache and Tanaka, 2005; Ivkovic and Kontogiannis, 2006),
top-down models (McComb et al., 2002), and matrix models (Xing and Stroulia, 2006;
Mao, Zhang, and Lu, 2007; Khan et al., 2008). These techniques have their unique way
of representing a system. For example, component based models describe direct and
indirect dependencies between system components (Vieira and Richardson, 2002), matrix
models focus on the design-level structural changes (Khan et al., 2008), and top-down
models emphasize application level analysis (McComb et al., 2002). During the analyses
38
of architecture or change impact, architects and designers use these techniques to identify
dependencies between system components (Arias, 2011).
Semi-formal descriptions of the components, connectors, and ports of a system
are written using architectural description languages (Arias, 2011). Dependency analysis
solutions such as the chaining analysis (Stafford and Wolf, 2001; Stafford, Wolf, and
Caporuscio, 2003) and architectural dependency graphs (Zhao, 2001) use syntactic and
structural information of the architectural description language to identify behavioral and
component–component dependencies during architecture analysis or testing (Arias,
2011).
2.5. Component Dependency Solutions Application Areas
Change impact analysis, and integration and testing are some major applications
of the architectural descriptions dependent dependency analysis techniques (Arias, 2011).
2.5.1. Change Impact Analysis
When a component based system (CBS) is upgraded or updated, a small change
in a component or relationship between components may affect other components and
their respective relationships, and, hence, may result in a ripple-effect throughout the
system (Bohner, 2002). A change impact analysis involves a detailed analysis of
component co-evolution of a system. Component co-evolution, where changes made to a
component trigger corresponding changes to its dependent component(s) is hence an
important piece in conducting dependency analysis in a CBS (Yu, Mishra, and
Ramaswamy, 2010). During a system’s component update, co-evolution analysis is very
difficult to perform and may lead to system crash (Larsson, 2000). The cost of
development, maintenance, and evolution of a system might be very high and
39
unpredictable when there is insufficient and unreliable component dependency and
interconnection information (Arias, 2011). Challenges in determining the effects of
modifications made to a component in a system during the maintenance process exist
even for well-structured systems with minimal interconnections and dependencies
(Moriconi and Winkler, 1990; Loyall and Mathisen, 1993).
A design structure matrix (DSM) capturing connectivity and reachability
information for an architecture is widely used to capture and visualize the impact of a
change in a system. For the system in Figure 2-12, the DSM that captures connectivity
and reachability information is shown in Figure 2-13. As seen in Figure 2-13b, the
change in one component of the system has a potential impact on the other components
of the system, and the DSM helps to visualize the effect.
Figure 2-12. System architecture that consists of directed links representing
information flow between components
Component 2
Component 1
Component 7
Component 6
Component 5
Component 4
Component 3
40
Figure 2-13. Design structure matrix showing (a) connectivity matrix and (b) reachability matrix
Component 1 Component 2 Component 3 Component 4 Component 5 Component 6 Component 7
Component 1 X
Component 2 X
Component 3 X X
Component 4
Component 5 X
Component 6 X
Component 7 X
(a)
Component 1 Component 2 Component 3 Component 4 Component 5 Component 6 Component 7
Component 1 X X X X
Component 2 X X X
Component 3 X X X X
Component 4
Component 5 X X
Component 6 X X X X
Component 7 X
(b)
41
Compatible components do not necessarily always guarantee upgradability for a
CBS (Huang, Tsai, and Huang, 2009). Identification of the constraints preventing the
upgrade through trial and error takes a lot of time without guaranteeing the success.
Change impact analysis enables faster and low cost investigation of design change
propagation through the analysis of system architecture (Jarratt and Clarkson, 2005), and
predicts how change in one part of the system may result in the change in other parts
(Clarkson, Simons, and Eckert, 2004). System architects, designers, developers, and
testers use change impact analysis during system development and maintenance to
investigate the modifications required in certain parts of a system due to changes made in
other parts (Arias, 2011).
Various types of systems such as aspect-oriented systems (Zhao, 2002),
component based systems (Mao, Zhang, and Lu, 2007), and object-oriented systems
(Huang and Song, 2007) benefit from change impact analysis to discover dependencies in
the system (Arias, 2011). Change prediction (Huang and Song, 2007), change impact of
component based systems (Law and Rothermel, 2003), and dynamic impact analysis in
object-oriented programs (Xing and Stroulia, 2006) are some popular solutions to aid
change impact analysis.
2.5.2. Integration and Testing
The dependency analysis aids engineers assess the impact of design change on the
integration and testing of the system. With the help of DSM and other available
dependency analysis tools and techniques, engineers carry out quality assurance, testing,
and debugging processes (Arias, 2011), prediction of defects and failures (Zimmermann
and Nagappan, 2008), interclass testing (Zhang and Ryder, 2007), model based
42
regression testing (Korel, Tahat, and Vaysburg, 2002), aspect oriented debugging (Ryser
and Glinz, 2000), test suite reduction (Jourdan, Ritthiruangdech, and Ural, 2006), and
scenario based testing (Ryser and Glinz, 2000).
The analysis of behavioral dependencies on the system components permits
developers and system implementers to identify components and parts that are more
vulnerable to defects, and, hence, helps to boost the quality of the system. Having this
dependency information early in advance, the time and cost for the design and execution
of testing activities can be estimated, and this allows for proper integration and testing
resource management (Arias, 2011).
2.6. Why is Components’ Links Prioritization Important?
When managing component based system development efforts, identifying
components’ interdependencies and answering key questions related to dependencies
such as, Which component needs to talk to which component? or Which interfaces
should components give priority to? are key challenges that system development
managers face (Sosa, 2008). Organizations that develop component based systems have
proposed strategies to improve the management of the interdependent components links
(Sanchez and Mahoney, 1997; Baldwin and Clark, 2000; Terwiesch, Loch, and De
Meyer, 2002) because they all agree that coordination associated with synchronizing the
links between the system components has been one of the major challenges among
developers (Allen, 1977; Henderson and Clark, 1990; Mihm, Loch, and Huchzermeier,
2003). To this date, the challenge of predicting dependency patterns between
interdependent components based on systems architecture still exists (Sosa, 2008).
43
When a component in a system is replaced, modified, or upgraded, keeping track
of the components and its interrelationships is a challenging and daunting task.
Dependency analysis, a well-known configuration management technique, is commonly
used to overcome the challenges (Larsson, 2000). When changes are made to a
component or system, necessary changes will be required to one or more related
component and system (Arias, 2011). Managing dependency and impact analysis during
system failure or upgrade using traditional processes such as a component dependency
matrix is not very helpful because this matrix only analyzes the relationship between
components but not between components and interfaces (Larsson, 2000; Huang, Tsai,
and Huang, 2009).
Prioritizing component links is necessary to conduct well-organized testing.
However, prioritizing the links is possible only with a method that distinguishes links
based on their dependencies. Testing of component links is a major area of system testing
in a CBS. Analysis of these dependencies and their priorities helps in planning the testing
of these component links. Changes in component link properties are inevitable as a
system goes through upgrade or modification. Prioritizing these links helps in performing
an efficient amount of testing (i.e., testing the minimum number of links while satisfying
the risk management requirements). Therefore, testing of these component links is
necessary to ensure their proper functioning in the system. To this date, the challenge of
identifying the critical component links in a system still exists.
This research contributes to the existing literature in the following ways. First, it
provides insight into various research efforts that have contributed toward the
dependency analysis on CBS. Second, it addresses the issue of lack of interdependency
44
analysis on component links, and introduces a dependency analysis that predicts the
relationship strength between existent dependencies. The strengths are then translated
into link priorities.
2.7. Related Work
Browning (2001), Sharman (2007), and Ramadan (2011) are just a few notable
researchers that have investigated dependency analysis solutions and design structure
matrices. As the interrelationship of components in a system is effectively captured by
the DSM, it is widely used by industry. However, the DSM does not address
interdependencies between components links in a CBS. Table 2-3 lists previous research
and major publications in the areas of dependency analysis, network analysis, and
organizational communication analysis, and identified research gaps in those areas.
Lorsh and Lawrence (1972), Lano (1979), Kockler et al. (1990), Becker, Asher,
and Ackerman (2000), and Sosa (2008) have done research on organizational
communication and relationship analysis (Table 2-3). These researchers investigated the
communication links between organizational entities and used the DSM to identify the
critical communication links. There are key differences between the communication links
within an organization and the links between system components. Within an
organization, a communication link can connect more than two organizations with each
other. However, within the context of a system link analysis, links connect two
components. This dissertation contributes to the existing literature by addressing the issue
of lack of dependency analysis on component links, and introduces a method that
calculates the priority of links based on the strength of dependencies to other links.
45
Table 2-3. Previous research and major publications in the areas of dependency
analysis, network analysis, and organizational communication analysis, and
identified research gaps in those areas
Research Solution
Implemented
Major Research
Publication
Research Gap
Dependency
analysis
solutions
DSM-adjacency
matrix (P)
Browning, 2001;
Sharman and Yassine,
2007; Zhao et al., 2009;
Tang, Xu and He, 2010;
Ramadan et al., 2011
DSM does not
address
interdependencies
between the links of
a CBS
Network
analysis
Affiliation
matrix (A)
Wasserman, 1994;
Anderson and
Vongpanitlerd, 2006;
Scott and Carrington,
2011
Affiliation matrix
captures how a
dependency is
related to a
component. It lacks
the analysis of
links’ priorities
based on
dependencies.
Organizational
communication
analysis
Technical
communication
patterns
identification
Lorsch and Lawrence,
1972; Lano, 1979;
Kockler et al., 1990;
Becker, Asher, and
Ackerman, 2000; Sosa,
2008
The organizational
communication
analysis technique
identifies
dependencies of
communication
relationships in an
organization. It
lacks the
implementation of
the techniques in a
CBS.
46
3. METHODS
This research proposes a method to identify link priority by investigating link
dependency (Kafle, Sarkani, and Mazzuchi, 2015). The research uses the design structure
matrix (DSM) to identify the relationship between the system components, and
introduces the multi-dimensional dependency (MDD) analysis, a method for identifying
the critical component links in a component-based system (CBS). The analysis of
dependency between component links involves investigating the component-to-
component relationship and component-to-link and link-to-link relationships. By using
the DSM and modified organizational communication and relationship analysis
techniques, it is possible to identify the dependency between one link and the other links.
Hence, it is possible to calculate the priority of the links relative to each other based on
the strength of their dependency.
Figure 3-1 displays the high-level three-step process of the MDD method. First,
the approach relies on the DSM, the existing dependency analysis method, to identify the
links between system components. Second, these links are further investigated using
modified organizational communication and relationship techniques to determine the
strength of their dependency. Third, analysis is performed to identify the link priorities. A
detailed flowchart of the MDD method is provided in Appendix A.
47
Figure 3-1. High-level overview of the MDD method used in this research to
prioritize critical links in a CBS (Kafle, Sarkani, and Mazzuchi, 2015)
3.1. Examination of System Architecture
The first step in the application of the MDD method is to understand the
architecture of a system by examining its components and component links. For
demonstration, let us consider an example of system architecture with 8 components and
7 component links (Figure 3-2).
The architecture is examined and the collected information is then captured in the
system adjacency matrix DSM (P) and the system affiliation matrix (A).
Capture
Adjacency DSM
(P)
Capture Affiliation
Matrix (A)
Derive Explicit
Dependency (E)
Derive Implicit
Dependency (I)
Analyze Priorities to determine Critical
Component Links
Step 1
Step 2
Step 3
Examination of System Architecture
Investigation of Dependencies between Links
Analysis of Link Priorities
48
Figure 3-2. System architecture used to examine the applicability, usability, and
effectiveness of the MDD method
3.1.1. System Adjacency DSM (P)
P identifies how components are linked with one another and captures the
information exchanged between system’s components. The information on the
Component
1 (C1)
Component
2 (C2)
Component
4 (C4)
Component
5 (C5)
Component
6 (C6)
Component
3 (C3)
d1 d2
d5d4
d3
Component being upgraded
Component
7 (C7)
d7
Component
8 (C8)
d6
49
components and their links is discovered using system architecture diagrams and other
related artifacts.
The matrix P for the system with 8 components (Figure 3-2) can be seen in Figure
3-3. Component C1 provides information to component C2; hence, in the P matrix, cell
p12 has the value of 1. Similarly, component C3 does not provide any information to
component C2; hence, in the P matrix cell, p32 has the entry value of 0.
C1 C2 C3 C4 C5 C6 C7 C8
C1 0 1 1 0 0 0 0 0
C2 0 0 0 1 0 0 0 0
C3 0 0 0 0 0 0 0 1
C4 0 0 0 0 1 1 0 0
C5 0 0 0 0 0 0 1 0
C6 0 0 0 0 0 0 0 0
C7 0 0 0 0 0 0 0 0
C8 0 0 0 0 0 0 0 0
Figure 3-3. System components’ architecture matrix representing relationships and
information exchanged between components
3.1.2. System Affiliation Matrix (A)
In order to capture the dependencies of the components in a system, it is
important to identify the types of dependencies one component has with another. In a
CBS, there could be many types of dependencies as components interact, communicate,
and coordinate with one another (Li, 2003). Depending on the nature of a system, some
or all of the dependencies identified in Table 2-1 may apply to a system.
Identifying and collecting dependency information between components requires
thorough efforts such as an in-depth analysis of system architecture diagram and
interviews with system architects (Figure 3-4).
50
Figure 3-4. Process used in this research to collect dependency information for a system architecture
Capture
Dependency
Information
Dependency
Information available in
Systems Architecture
Artifacts?
Yes
Interview with
Subject Matter
Experts (System
Architects
No
Validate
Dependency
Information
Dependency
Information
Valid?
No
EndYesStart
51
As the dependency information is collected, the system architecture diagram is
updated by labeling the type of dependency a component has with another. The collected
dependency information data are then documented into a DSM, which we call a system
components affiliation matrix (A).
A identifies and captures the types and level of information exchanged through a
system’s component links.
For a system with n components and m numbers of identified links between
components, Am,n is a rectangular matrix where m rows represent the number of links and
n columns represent the components. The value of each matrix entry aij can be 1 or 0. An
entry value of 1 indicates that link i provides information to component j; an entry value
of 0 indicates that link i has no association with component j. The P and A matrices are
used to derive dependency strengths.
For the system (Figure 3-2) with 8 components and 7 dependency links, A is a
matrix with 6 rows and 6 columns (Figure 3-5). Dependency d1 is affiliated with
component C1 and component C2, and is providing information to component C2; hence,
in the A matrix, cell a12 has the value of 1. Similarly, dependency between component C2
and component C4 is possible through dependency link d3. Dependency d3 is providing
information to component C4; hence, cell d34 has the value of 1 in the A matrix.
52
C1 C2 C3 C4 C5 C6 C7 C8
d1 0 1 0 0 0 0 0 0
d2 0 0 1 0 0 0 0 0
d3 0 0 0 1 0 0 0 0
d4 0 0 0 0 1 0 0 0
d5 0 0 0 0 0 1 0 0
d6 0 0 0 0 0 0 0 1
d7 0 0 0 0 0 0 1 0
Figure 3-5. System components’ affiliation matrix used to capture dependency and
information exchange between components and links
3.2. Investigation of Dependencies between Links
In the second step of the application of the MDD method, the dependency
strength between component links is calculated using the organizational communication
and relationship identification technique. Dependencies between links can be either
explicit or implicit. Two links are explicitly dependent if one or more common
components are affiliated with the links (Figure 3-6).
Figure 3-6. Explicit dependency between two links due to a common component
affiliated with the links
Two links are implicitly dependent if there is a link between the affiliated
components and their respective neighboring components (Figure 3-7). The strength of
dependencies between component links is calculated by factoring in both explicit and
implicit dependencies.
Component
kComponentlink i link jComponent
Explicit dependency between link i and link j
53
Figure 3-7. Implicit dependency between two links due to common link between
adjacent components
3.2.1. Explicit Dependency between Links
If two links are associated with a common component (Figure 3-4), this is
captured in matrix A. For an explicit dependency, the value of the A matrix entry in the
same column will be 1, i.e., aik = ajk = 1, where i and j represent the links shared by
component k. A is used to calculate the total number of common components associated
with any pair of links. Hence, the system explicit matrix (E) is defined as follows:
𝑬 = 𝑨 × 𝑨𝑻, (3.1)
where AT is the transpose of A. For a system with n components, En,n is a square,
symmetric matrix with n rows and n columns identically labeled. Entries made in E can
be non-binary; hence, they can be any whole number.
An off-diagonal cell eij in E represents the number of common components to
which link i and link j provide information.
𝒆𝒊𝒋 = ∑ 𝒂𝒊𝒌𝒂𝒋𝒌𝒎𝒊=𝟏 (3.2)
For a system shown in Figure 3-2 with 7 dependency links, the system explicit
dependency matrix (E) is represented in Figure 3-8. Looking at the matrix, the off-
diagonal cell values are all 0 because none of the dependency pair provides to one
Component
k
Component
lComponentlink jlink iComponent
Implicit dependency between link i and link j
54
common component. The diagonal element e22 has the value of 1 because dependency d2
provides to one component.
d1 d2 d3 d4 d5 d6 d7
d1 1 0 0 0 0 0 0
d2 0 1 0 0 0 0 0
d3 0 0 1 0 0 0 0
d4 0 0 0 1 0 0 0
d5 0 0 0 0 1 0 0
d6 0 0 0 0 0 1 0
d7 0 0 0 0 0 0 1
Figure 3-8. System explicit dependency matrix showing dependencies between links
due to a common component affiliated with links
3.2.2. Implicit Dependency between Links
3.2.2.1. Implicit Dependency between Links (One link apart)
Two links are implicitly dependent if there is a common link between their
affiliated components (Figure 3-7). The implicit matrix (I) records the dependency
strength between links that are implicitly dependent. I is defined as follows:
𝑰 = 𝑨 × 𝑷 × 𝑨𝑇, (3.3)
where each entry of matrix (I) is defined as
𝑰𝒊𝒋 = ∑ 𝒂𝒊𝒌𝒑𝒍𝒌𝒂𝒋𝒍𝒎𝒊=𝟏 ,
(3.4)
where a and p are elements of A and P, respectively. For example, in Figure 3-7,
component k has a link established with component l (plk > 0). Component k receives
information through link i (aik > 0), and component l receives information through link j
(ajl > 0). Therefore, link i is implicitly dependent on link j. This means Iij > 0 if plk > 0
and ajl > 0. With this information, it is possible to calculate the number of links for which
55
link i and link j need to exchange information or need to be dependent when aik = plk = ajl
= 1.
3.2.2.2. Implicit Dependency between Links (Multiple links apart)
Equation 3.4 considers components that are next to each other and are one link
apart. P captures the relationship between components that are one link apart. In a
system, a relationship exists between components that are one link apart and between
components that are two, three, or n links apart (Kubat, 1989). As information flows from
a component to another component that is n links apart, Pactual records the number of
instances a component falls in such information flow path. To calculate Pactual, the
components that are n links apart from other components are identified by using power
derivations of P.
𝑷𝑰 = [𝑷]𝟏
𝑷𝑰𝑰 = [𝑷]𝟐
𝑷𝑰𝑰𝑰 = [𝑷]𝟑
𝑷𝒏 = [𝑷]𝒏, (3.5)
where PI, PII, PIII, and Pn are matrices that represent one, two, three, and n links between
components, respectively. [P]1, [P]2, [P]3, and [P]n are the first, second, third, and nth
power derivations of P, respectively. In the next step, Pactual is calculated. Hence,
equation 3.4 is revised as follows:
𝑰 = ∑ 𝑨 ×𝑷𝒂𝒄𝒕𝒖𝒂𝒍𝝀 × 𝑨𝑻𝒏
𝝀=𝟏 , (3.6)
where n is the number of total components of the system and 𝑷𝑎𝑐𝑡𝑢𝑎𝑙𝜆 is the DSM
capturing the number of instances a component is used during information flow between
components that are λ links apart.
56
For a system with m links, Im,m is a square matrix with m rows and m columns
identically labeled. An off-diagonal cell Iij indicates that link i can provide information
to link j. The diagonal cells on I indicate the number of components with which a link is
associated. For a system with 7 dependency links, the implicit dependency matrix (I) is
represented in Figure 3-9.
d1 d2 d3 d4 d5 d6 d7
d1 0 0 7 1 1 0 1
d2 0 0 0 0 0 1 0
d3 0 0 0 5 2 0 1
d4 0 0 0 0 0 0 3
d5 0 0 0 0 0 0 0
d6 0 0 0 0 0 0 0
d7 0 0 0 0 0 0 0
Figure 3-9. System implicit dependency matrix showing dependencies between links
due to common link between adjacent components
Looking at the matrix in Figure 3-9, the cell value for I13 is 7, which indicates that
as information flows from d1, there are 7 instances when data flows through d3. Details
on the actual steps and total number of instances where d3 is used are shown in Table 3-
1.
Table 3-1. Total number of instances of data flow through link d3 as data originate
at link d1
Step d3 Used
2 3
3 3
4 1
5 0
6 0
7 0
Total 7
57
The diagonal cell values in Figure 3-9 represent the number of instances a
dependency is involved with a dependency that provides information to itself as the
information flows in a cyclic pattern and passes through other dependencies. All the
diagonal values are 0, indicating that the information flow is linear and non-cyclic.
3.3. Analysis of Link Priorities
The objectives of the third and final step in the application of the MDD method
are to calculate the total dependency strength between component links and to use it to
assign priorities to the links. The total link dependency strength matrix (LDM) is based
on the explicit and implicit dependency strengths:
𝑳𝑫𝑴 = 𝑬 + 𝑰, (3.7)
where LDM is a square matrix with m rows and m columns identically labeled. Each off-
diagonal cell ldmij represents the dependency strength of a link i with link j. The
dependency strength is directly proportional to the link priority.
For the example system shown in Figure 3-2, the LDM is shown in Figure 3-10.
The cell values represent the dependency strength between the two links. The higher the
value of the cell, the higher the dependency strength between the links. For the example
system shown in Figure 3-2, as data flow through d1 to the rest of the system, d3 has the
highest dependency strength value (first row), and, hence, is the highest priority link with
respect to d1. Similarly, d4 is the highest priority link and d7 is the lowest priority link
with respect to d3. The complete priority mapping for all the component links is recorded
in a matrix shown in Figure 3-11.
58
d1 d2 d3 d4 d5 d6 d7
d1 1 0 7 1 1 0 1
d2 0 1 0 0 0 1 0
d3 0 0 1 5 2 0 1
d4 0 0 0 1 0 0 3
d5 0 0 0 0 1 0 0
d6 0 0 0 0 0 1 0
d7 0 0 0 0 0 0 1
Figure 3-10. Total link dependency matrix, which is the result of both explicit and
implicit dependencies
d1 d2 d3 d4 d5 d6 d7
d1 1 0 1st 2nd 2nd 0 2nd
d2 0 1 0 0 0 1st 0
d3 0 0 1 1st 2nd 0 3rd
d4 0 0 0 1 0 0 1st
d5 0 0 0 0 1 0 0
d6 0 0 0 0 0 1 0
d7 0 0 0 0 0 0 1
Figure 3-11. Priority mapping based on the dependency strength captured in link
dependency matrix
Using the first and third row, the diagram in Figure 3-2 is updated to highlight the
priority of the links relative to link d1 (Figure 3-12).
59
Figure 3-12. Prioritized critical links based on the dependency strengths. The higher
the dependency strength, the higher the priority
Component
1 (C1)
Component
2 (C2)
Component
4 (C4)
Component
5 (C5)
Component
6 (C6)
Component
3 (C3)
d1 d2
test 3rdtest 2nd
test 1st
Component being upgraded
Component
7 (C7)
test 4th
Component
8 (C8)
d6
60
4. EMPIRICAL EVALUATION THROUGH CASE STUDIES
This chapter describes in detail the application of the multi-dimensional
dependency (MDD) method and its validation. The motivation for developing MDD was
to create a dependency analysis technique that could prioritize components’ links in
component based system (CBS). The Markov chain method was chosen to compare and
evaluate the MDD method results. This method has been popular among the experts
because of its applicability.
4.1. Hypotheses
MDD method was developed to identify component link priorities used during
integration and testing. In order to test its accuracy, the MDD method is demonstrated
through application to multiple case studies and validated through Markov chain analysis.
The null hypotheses for the research are the following:
HO1. The identified link priorities are identical for both methods, MDD and
Markov chain.
HO2. The MDD method is able to prioritize links even when there exist two or
more links between two components.
The alternative hypothesis for the research is the following:
Ha1. The identified link priorities are not identical for both methods, MDD and
Markov chain.
4.2. Design of the Evaluation Approach
Three different component based system architectures were chosen for the case
studies to evaluate the MDD method. The first case study architecture is a simple CBS
61
consisting of 6 major components and 7 major component links. The second architecture
is a more complex CBS, consisting of 8 components and 9 links. The third and more
complicated system consisting of 10 components and 18 links, with one-third of those
links having double or triple links, was analyzed with the goal of identifying links’
priorities. The proprietary information related to components and links was removed, and
the system was sanitized in order to be able to share it publicly.
The MDD and Markov chain methods were implemented in the case studies
architecture with the goal of calculating the components links’ dependency strengths as
shown in Figure 4-1. The Markov chain method involved the assumption and assignment
of probability weights in an initial state diagram. The dependency strengths were
calculated, compared, and analyzed.
62
Figure 4-1. Graphical representation of the evaluation approach high-level activity steps used in the research
Identify
Data Flow
Pattern
Perform Dependency
Analysis (Explicit and
Implicit)
Calculate Links
Dependency Strengths
Establish
Initial State
Diagram
Determine Initial State
Matrix
Calculate
Transient State
Calculate
Absorbing State
Calculate
Transition
probabilities
Dependency Strengths
based on Transition
probabilities
Markov Chain Method
MDD Method
Need to
Prioritize
Links
MDD
Markov Chain
Compare
and
Analyze
63
5. CASE STUDY ANALYSIS – I
This chapter describes in detail the application of the multi-dimensional
dependency (MDD) method and its validation. A case study example is used to
demonstrate the step-by-step application of the MDD method; the Markov chain method
is used for validation. Figure 5-1 represents a component based system (CBS)
architecture. Components (C1, C2, …, C6) are represented by boxes, and component
links (d1, d2, …, d7) are represented by edges connecting the components. Let us assume
that C1 is being upgraded. Retesting after the upgrade involves testing the links. The
analysis of dependency between links is carried out and the priority of the links is
calculated using the MDD method.
Figure 5-1. System architecture being evaluated for case study I: 6 components and
7 links
C1C2C4
C5 C6C3
d1
d2
d5 d4
d6
d3
d7 upgraded component
component
link
upgraded link
64
5.1. Step 1: Examination of System Architecture. Identification of P and A
The first step in the process is to identify how components and links are
interdependent and capture the types and level of information exchanged between them.
The system adjacency matrix DSM (P) for the system can be seen in Figure 5-2. C1
provides information to C2; hence, cell p12 has the value of 1. C3 does not provide any
information to C2; hence, the cell p32 has the entry value of 0.
Figure 5-2. Matrix capturing relationships between components. System
components adjacency DSM
The system affiliation matrix (A) for the system is shown in Figure 5-3.
Dependency d1 is affiliated with C1 and C2, and is providing information to C2; hence,
the cell a12 has the value of 1. Similarly, dependency between C2 and C5 is possible
through dependency d6. Dependency d6 is providing information to component 2; hence,
cell d62 has the value of 1.
C1 C2 C3 C4 C5 C6
C1 0 1 0 0 0 0
C2 0 0 1 1 0 0
C3 0 0 0 0 1 1
C4 0 0 0 0 0 0
C5 0 1 0 1 0 0
C6 0 0 0 0 0 0
65
Figure 5-3. Matrix mapping relationships between components and links
5.2. Step 2: Investigation of Dependencies between Links. Derivation of E and I
The second step of the MDD method is to calculate the dependency strength
between the links using the information previously identified. The process of calculating
the implicit and explicit dependency strengths between links discussed in Chapter 3.2 is
automated by using MATLAB. The inputs for the MATLAB program are P and A. The
program automates the identification and calculation of the link dependency strength
matrix (LDM) matrix.
For the system architecture diagram shown in Figure 5-1, the system explicit
dependency matrix (E) is represented in Figure 5-4. Looking at the matrix, the value of
cell e16 is 1, meaning that the dependency pair d1 and d6 provides information to one
common component, which is C6.
d1 d2 d3 d4 d5 d6 d7
d1 0 0 0 0 1 0
d2 0 0 0 0 0 0
d3 0 0 0 0 0 1
d4 0 0 0 0 0 0
d5 0 0 0 0 0 0
d6 1 0 0 0 0 0
d7 0 0 1 0 0 0
C1 C2 C3 C4 C5 C6
d1 0 1 0 0 0 0
d2 0 0 1 0 0 0
d3 0 0 0 1 0 0
d4 0 0 0 0 1 0
d5 0 0 0 0 0 1
d6 0 1 0 0 0 0
d7 0 0 0 1 0 0
66
Figure 5-4. Dependency between links due to common components. Explicit
dependency matrix
It is assumed that dependency pairs that provide or receive information to or from
common components are likely to be interacting. The E matrix only identifies a pair of
dependency that interacts with a certain number of components; however, it does not
capture the interactions that would need to take place between specific dependencies to
coordinate the interactions captured in P in step 1 (Sosa, 2008). P captures the
relationship between components that are one link apart. In a system, a relationship exists
between components that are one link apart and between components that are two, three,
or n links apart. In order to get a complete relationship measure between components, the
number of instances an interface is used during information flow between components is
recorded in Pactual. As information flows from a component to another component that is
n links apart, Pactual records the number of instances a component falls in such
information flow path. To calculate Pactual, the components that are n links apart from
other components are identified by using power derivations of P. Figure 5-5 shows the
power matrix for the components that are one link apart.
C1 C2 C3 C4 C5 C6
C1 1 0 0 0 0
C2 0 1 1 0 0
C3 0 0 0 1 1
C4 0 0 0 0 0
C5 0 1 0 1 0
C6 0 0 0 0 0
Figure 5-5. Number of instances a component is used as data flow between
components that are one link apart. PactualI
C1 is connected with C2 through one link; C4 and C2 are one link apart from C5.
Similarly, Figure 5-6 is the Pactual for third power (PIII) matrix.
67
C1 C2 C3 C4 C5 C6
C1 2 2 2 0 1 1
C2 0 1 2 1 2 0
C3 0 2 1 1 2 0
C4 0 0 0 0 0 0
C5 0 2 2 0 1 1
C6 0 0 0 0 0 0
Figure 5-6. Number of instances a component is used as data flow between
components that are three links apart. PactualIII
The cell value of pactualIII 1,2 is 2, which means that the interface between C1 and
C2 is used twice: once during information flow from C2 to C5 and once during
information flow from C1 to C6. The cell value of pactualIII 2,3 is 1, which indicates that the
interface between C2 to C3 is used once during the information flow indicated in the
third power (PIII) matrix. The diagonals cell pactualIII 5,5 has the value of 1 because
information flows from C5 through C2 and C3 and back to C5 in three steps.
Pactual matrices are calculated using equation 3.5, and the implicit matrix (I) is
calculated using equation 3.6. I records the number of interfaces between components to
which a component link would need to provide information. For the system architecture
diagram shown in Figure 5-1, I is represented in Figure 5-7.
d1 d2 d3 d4 d5 d6 d7
d1 12 4 11 2 7 4
d2 12 4 16 4 12 4
d3 0 0 0 0 0 0
d4 16 12 4 2 16 4
d5 0 0 0 0 0 0
d6 7 12 4 11 2 4
d7 0 0 0 0 0 0
Figure 5-7. Dependency between links due to a common link between adjacent
components. Implicit dependency matrix
The complete mapping of the power matrices and the implicit and explicit
dependency calculation are shown in Figure 5-8.
68
The cell values for I represent the dependency strengths that are results of the
implicit dependency between links occurring due to neighboring components. Higher
values correlate to higher dependency strengths. The first row represents the dependency
strengths between link d1 and the other links.
69
Figure 5-8. Demonstration of link priority calculation using the MDD method for the
example application
70
5.3. Step 3: Analysis of Link Priorities
After calculating the explicit and implicit dependency strengths (E and I) between
the links, the final step in the MDD method is to calculate the priority of the links based
on their calculated dependency strengths. The total dependency strengths are calculated
using equation 3.7. The total LDM for the system is shown in Figure 5-9.
d1 d2 d3 d4 d5 d6 d7
d1 12 4 11 2 8 4
d2 12 4 16 4 12 4
d3 0 0 0 0 0 1
d4 16 12 4 2 16 4
d5 0 0 0 0 0 0
d6 8 12 4 11 2 4
d7 0 0 1 0 0 0
Figure 5-9. Dependency strengths as a result of both explicit and implicit
dependencies. Total link dependency strength matrix (LDM)
Each off-diagonal cell value represents the dependency strength between two
links. The higher the value of the cell, the higher the dependency strength between the
links. We assumed that for the analyzed system, component C1 is being upgraded. Link
d1 is responsible for carrying information from C1 to the rest of the system. For this
example application, the goal is to determine the priority of links that are dependent on
d1. Looking at the highlighted first row in the LDM, component link d2 has the highest
dependency strength value; hence, d2 is the highest priority link with respect to d1. On
the other hand, link d5 has the lowest dependency strength value; hence, it is lowest
priority. The complete priority mapping for all component links is recorded in a matrix as
shown in Figure 5-10.
71
d1 d2 d3 d4 d5 d6 d7
d1 1st 4th 2nd 5th 3rd 4th
d2 2nd 3rd 1st 3rd 2nd 3rd
d3 0 0 0 0 0 1st
d4 1st 2nd 3rd 4th 1st 3rd
d5 0 0 0 0 0 0
d6 3rd 1st 4th 2nd 5th 4th
d7 0 0 1st 0 0 0
Figure 5-10. Priority of links translated from the dependency strengths
Using the first row, the system diagram was updated to highlight the priority of
the links relative to link d1 in Figure 5-11.
Figure 5-11. Priorities of links mapped in the system architecture
5.4. Theoretical Validation using Markov Chain
To validate the dependency analysis results obtained from applying the MDD
method, the Markov chain analysis was used for theoretical validation. The case study I
system outlined in Figure 5-1 can be modeled as an absorbing Markov chain (Kemeny
and Snell, 1976). The detailed flowchart for the Markov chain method is provided in
Appendix A.
C1C2C4
C5 C6C3
d1
test
1st
test
5th
test
2nd
test
3rd
test
4th
upgraded component
component
link
upgraded link
test
4th
72
The initial state can be identified, and the number of transition states is calculated.
In a Markov chain, initial probabilities are associated with the initial state of the
architecture. As information flows through the architecture, the transition probabilities
and number of transition steps can be calculated based on the initial state diagram (Figure
5-12a). The initial state probabilities for each of the links are displayed and captured in
the matrix form in Figure 5-12b.
(a)
(b)
Figure 5-12. Initial state diagram displaying initial uniform Markov chain; (a)
Initial state diagram; (b) Initial state matrix
73
For an absorbing Markov chain, if K is an r-by-r identity matrix, Q is a t-by-t
matrix, R is a nonzero t-by-r matrix, and O is an r-by-t zero matrix, then the probability
of being in the state Sj after n steps, when the chain is started in state Si (Pn), is
𝑃𝑛 =𝑇𝑅𝐴𝐵𝑆
(𝑄𝑛 𝑅𝑂 𝐾
), (5.1)
where TR and ABS indicate transient and absorbing states, respectively. Hence, the
expected number of times (N) the data are in the transient state Sj after n steps, when the
data started in state Si, is
𝑁 = (𝐾 − 𝑄)−1 (5.2)
In addition, the probability (B) that data will be absorbed in absorbing state Sj if data start
in the transient state Si is
𝐵 = 𝑁 ∗ 𝑅 (5.3)
For the example problem in Figure 5-1, the probability (B) of data being in a component
is shown in Figure 5-13.
Figure 5-13. Probability of the data being in a component
Hence, the expected number of times (N) data are in the transient components as data
originate from respective components (C1, C2, C3, C5) is shown in Figure 5-14.
74
Figure 5-14. Expected number of times data are in transient components
In addition, the probability (B) that data will be absorbed in absorbing states (C4 and C6)
as data originate from transient states (C1, C2, C3, C5) is shown in Figure 5-15.
Figure 5-15. Probability that data will be absorbed in absorbing states
Therefore, the calculated transition probabilities that data will be in a component are shown
in Figure 5-16.
Figure 5-16. Transition probabilities for the data being in a component
The computed transition probabilities are then transformed to their associated
links (Figure 5-17). The transformation is carried out using matrix multiplication with
adjacency matrix.
C1 C2 C3 C4 C6 C5
C1 1 1.7143 0.8571 0.7143 0.2857 0.4286
C2 0 1.7143 0.8571 0.7143 0.2857 0.4286
C3 0 0.4286 1.7143 0.4286 0.5714 0.8571
C5 0 0.8571 0.4286 0.8571 0.1429 1.7143
C4 C6
C1 0.7143 0.2857
C2 0.7143 0.2857
C3 0.4286 0.5714
C5 0.8571 0.1429
C1 C2 C3 C5 C4 C6
C1 0.2500 0.4286 0.2143 0.1071 0.7143 0.2857
C2 0 0.5714 0.2857 0.1429 0.7143 0.2857
C3 0 0.1429 0.5714 0.2857 0.4286 0.5714
C5 0 0.2857 0.1429 0.5714 0.8571 0.1429
C4 0 0 0 0 0 0
C6 0 0 0 0 0 0
75
Figure 5-17. Markov transition probabilities results for links for case study I system
5.5. Case Study I Results Analysis
For the case study I system seen in Figure 5-1, MDD results shown in Figure 5-9
are used to calculate transition probabilities to be able to compare the MDD results with
the Markov chain results. The transition probabilities are shown in Figure 5-18.
Figure 5-18. MDD transition probabilities results for case study I system
The dependencies of links with respect to d1 are displayed on the first row. For
comparison with the Markov chain results, the transition probabilities as a fraction of the
total are calculated and presented in Table 5-1. The fraction of the total is considered as
dependency strength between the link 1 (d1) and the other links.
The transition probabilities of component links from both MDD and Markov
methods are listed in Table 5-1.
d1 d2 d3 d4 d5 d6 d7
d1 0.2857 0.1429 0.3571 0.0714 0.1429 0.2857 0.3571
d2 0.0714 0.2857 0.2143 0.1429 0.2857 0.0714 0.2143
d3 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d4 0.1429 0.0714 0.4286 0.2857 0.0714 0.1429 0.4286
d5 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d6 0.2857 0.1429 0.3571 0.0714 0.1429 0.2857 0.3571
d7 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d1 d2 d3 d4 d5 d6 d7
d1 0.1633 0.2449 0.0816 0.2245 0.0408 0.1633 0.0816
d2 0.1967 0.1475 0.0656 0.2623 0.0656 0.1967 0.0656
d3 0.0000 0.0000 0.5000 0.0000 0.0000 0.0000 0.5000
d4 0.2540 0.1905 0.0635 0.1429 0.0317 0.2540 0.0635
d5 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000
d6 0.1633 0.2449 0.0816 0.2245 0.0408 0.1633 0.0816
d7 0.0000 0.0000 0.5000 0.0000 0.0000 0.0000 0.5000
76
Table 5-1. MDD method and Markov chain method transition probabilities and link
priorities for the case study system
Link Transition
Probabilities
Fraction of Total
Transition Probabilities Link Priorities
Link Markov MDD Markov MDD Markov MDD
link 2 (d2) 0.1429 0.2450 0.1053 0.2927 3 1
link 3 (d3) 0.3571 0.0816 0.2632 0.0976 1 4
link 4 (d4) 0.0714 0.2245 0.0526 0.2680 4 2
link 5 (d5) 0.1429 0.0408 0.1053 0.0488 3 5
link 6 (d6) 0.2857 0.1633 0.2105 0.1951 2 3
link 7 (d7) 0.3571 0.0816 0.2632 0.0976 1 4
The Markov chain results and MDD results (Table 5-1) are compared in Figure 5-
19, and their difference is calculated for validation purposes. The link priorities’ results
are different for MDD and Markov chain methods. This difference occurs because the
Markov chain method is directional and counts the flow of information between the
components in a directional manner. However, the MDD method considers both the
upstream and downstream flow of information (explicit and implicit dependency effect).
For example, in Figure 5-1, link d6 satisfies the connection between C5 and C2. Link d6
creates a loop. The MDD method is able to capture the upstream flow of information
from d6 in addition to the downstream flow of information. However, the Markov chain
only focuses on the downstream flow of information and does not capture the
dependency developed because of d6. In addition, the results differ because the Markov
chain assigns initial probabilities for the links, whereas the MDD results are computed
without considering link probabilities.
77
Figure 5-19. Comparison of dependency strength with respect to link 1 (d1)
obtained from Markov chain and MDD for the case study I system
On average, the relative value of the link dependency strength for the comparison
of the MDD to Markov chain results is 1.6683, with a standard deviation of 1.9165. To
test the Ho1 hypothesis, a Pearson chi-squared (χ2) test on the priorities of the links was
conducted, resulting in a p value of 0.000486. At a significance level of 0.05, we reject
the null hypothesis Ho1, and we accept the alternative hypothesis. It is concluded that the
MDD method results in different link priorities than Markov chain method. Looking at
Figure 5-1, we see that as data flow from d1 to d2, there are four links downstream that
are dependent on the data flow from d2. The MDD method considers those, and ranks d2
as the most critical and highest priority link dependent on d1.
None of the dependencies between two components in the evaluation application
system consisted of multiple links. Hence, we have not evaluated the second hypothesis.
78
6. CASE STUDY ANALYSIS – II
Further analysis of the MDD method is carried out in case study II system. The
system architecture used for this case study system (Figure 6-1) consists of 8 components
and 9 links. The primary goal for the analysis is to identify the most critical links and
prioritize them using the MDD method as the number of components and links are
increased. The MDD results are then compared with the priorities obtained from the
Markov chain method, and the results are analyzed.
The architecture for the system being analyzed is shown in Figure 6-1.
Figure 6-1. System architecture for case study II: 8 components and 9 links
Component
1 (C1)
Component
2 (C2)
Component
4 (C4)
Component
5 (C5)
Component
6 (C6)
Component
3 (C3)
d1
d2
d8d7
d3
Component being upgraded
Component
7 (C7)d6
Component
8 (C8)
d5
d9d10
d4
79
6.1. Step 1: Examination of System Architecture
In the first step of the method, the system architecture (P) and system affiliation
(A) matrices for the architecture are examined. The P and A matrices are shown in Figure
6-2 and Figure 6-3, respectively.
Figure 6-2. System adjacency matrix (P)
Figure 6-3. System affiliation matrix (A)
6.2. Step 2: Investigation of Dependencies between Links
The second step of the MDD method is to analyze and derive the dependencies
between component links. The explicit (E) and implicit (I) dependency matrices between
links are shown in Figure 6-4 and Figure 6-5, respectively.
C1 C2 C3 C4 C5 C6 C7 C8
C1 0 1 0 0 0 0 0 0
C2 0 0 1 1 0 0 0 1
C3 0 0 0 0 0 0 1 1
C4 0 0 0 0 1 1 0 0
C5 0 0 0 0 0 1 0 0
C6 0 0 0 0 0 0 0 0
C7 0 0 0 0 0 0 0 0
C8 0 0 0 0 0 1 0 0
C1 C2 C3 C4 C5 C6 C7 C8
d1 0 1 0 0 0 0 0 0
d2 0 0 1 0 0 0 0 0
d3 0 0 0 1 0 0 0 0
d4 0 0 0 0 0 0 0 1
d5 0 0 0 0 0 0 0 1
d6 0 0 0 0 0 0 1 0
d7 0 0 0 0 1 0 0 0
d8 0 0 0 0 0 1 0 0
d9 0 0 0 0 0 1 0 0
d10 0 0 0 0 0 1 0 0
80
Figure 6-4. Explicit dependency matrix (E)
Figure 6-5. Implicit dependency matrix (I)
6.3. Step 3: Analysis of Link Priorities
After deriving the dependency matrices, the link priorities are calculated and
analyzed. The total dependency matrix (LDM) (Figure 6-6) represents the dependency
strength between component links. The higher the dependency strength, the higher the
priority.
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10
d1 1 0 0 0 0 0 0 0 0 0
d2 0 1 0 0 0 0 0 0 0 0
d3 0 0 1 0 0 0 0 0 0 0
d4 0 0 0 1 1 0 0 0 0 0
d5 0 0 0 1 1 0 0 0 0 0
d6 0 0 0 0 0 1 0 0 0 0
d7 0 0 0 0 0 0 1 0 0 0
d8 0 0 0 0 0 0 0 1 1 1
d9 0 0 0 0 0 0 0 1 1 1
d10 0 0 0 0 0 0 0 1 1 1
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10
d1 0 5 3 1 1 1 1 2 2 2
d2 0 0 0 3 3 2 0 1 1 1
d3 0 0 0 0 0 0 3 1 1 1
d4 0 0 0 0 0 0 0 1 1 1
d5 0 0 0 0 0 0 0 1 1 1
d6 0 0 0 0 0 0 0 0 0 0
d7 0 0 0 0 0 0 0 1 1 1
d8 0 0 0 0 0 0 0 0 0 0
d9 0 0 0 0 0 0 0 0 0 0
d10 0 0 0 0 0 0 0 0 0 0
81
Figure 6-6. Link dependency matrix (LDM) representing the dependency strength
between links
Based on the dependency strengths, the links in the system architecture are
prioritized and are recorded in the matrix in Figure 6-7.
Figure 6-7. Priorities of links based on the dependency matrix
With the help of the first row of the dependency matrix (Figure 6-7), the system
architecture diagram is updated (Figure 6-8).
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10
d1 1 5 3 1 1 1 1 2 2 2
d2 0 1 0 3 3 2 0 1 1 1
d3 0 0 1 0 0 0 3 1 1 1
d4 0 0 0 1 1 0 0 1 1 1
d5 0 0 0 1 1 0 0 1 1 1
d6 0 0 0 0 0 1 0 0 0 0
d7 0 0 0 0 0 0 1 1 1 1
d8 0 0 0 0 0 0 0 1 1 1
d9 0 0 0 0 0 0 0 1 1 1
d10 0 0 0 0 0 0 0 1 1 1
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10
d1 0 1st 2nd 4th 4th 4th 4th 3rd 3rd 3rd
d2 0 3rd 0 1st 1st 2nd 0 3rd 3rd 3rd
d3 0 0 2nd 0 0 0 1st 2nd 2nd 2nd
d4 0 0 0 1st 1st 0 0 1st 1st 1st
d5 0 0 0 1st 1st 0 0 1st 1st 1st
d6 0 0 0 0 0 1st 0 0 0 0
d7 0 0 0 0 0 0 1st 1st 1st 1st
d8 0 0 0 0 0 0 0 1st 1st 1st
d9 0 0 0 0 0 0 0 1st 1st 1st
d10 0 0 0 0 0 0 0 1st 1st 1st
82
Figure 6-8. Prioritized component links based on the MDD method for case study II
6.4. Theoretical Validation using Markov Chain
The Markov chain method is used to calculate the priorities of the components
links, and the results are compared with those of the MDD method. The initial state for
the system architecture is identified and the number of transition states is calculated.
Next, the initial state probabilities for each of the links are displayed and captured in a
matrix (Figure 6-9).
Component
1 (C1)
Component
2 (C2)
Component
4 (C4)
Component
5 (C5)
Component
6 (C6)
Component
3 (C3)
d1
test 1st
test 3rdtest 4th
test 2nd
Component being upgraded
Component
7 (C7)test 4th
Component
8 (C8)
test 4th
test 3rdtest 3rd
test 4th
83
Figure 6-9. Initial state matrix
As data flow in the architecture, the initial probability of data being in a
component is shown in Figure 6-10. In the architecture seen in Figure 6-1, C6 and C7 are
absorbing components and C1, C2, C3, C4, C5, and C8 are transient components.
Figure 6-10. Initial probability of data being in a state
With the help of initial probabilities, the expected number of times (N) the data
are in the transient components after n steps is calculated using equation 3.2. The N
matrix is shown in Figure 6-11.
C1 C2 C3 C4 C5 C6 C7 C8
C1 0 1 0 0 0 0 0 0
C2 0 0 1/3 1/3 0 0 0 1/3
C3 0 0 0 0 0 0 1/2 1/2
C4 0 0 0 0 1/2 1/2 0 0
C5 0 0 0 0 0 1 0 0
C6 0 0 0 0 0 0 0 0
C7 0 0 0 0 0 0 0 0
C8 0 0 0 0 0 1 0 0
C1 C2 C3 C4 C5 C8 C6 C7
C1 0 1 0 0 0 0 0 0
C2 0 1/4 1/4 1/4 0 1/4 0 0
C3 0 0 1/3 0 0 1/3 0 1/3
C4 0 0 0 1/3 1/3 0 1/3 0
C5 0 0 0 0 1/2 0 1/2 0
C8 0 0 0 0 0 1/2 1/2 0
C6 0 0 0 0 0 0 1 0
C7 0 0 0 0 0 0 0 1
K R Q O
84
Figure 6-11. Expected number of times data are in transient states
In addition, the probability (B) that data will be absorbed in absorbing
components if data start in the transient components is calculated using equation 3.3, and
is shown in Table 6-1.
Table 6-1. Probability table showing probability of data being absorbed in
absorbing states as they originate from transient states
C6 C7
C1 0.8333 0.1667
C2 0.8333 0.1667
C3 0.5000 0.5000
C4 1.0000 0.0000
C5 1.0000 0.0000
C8 1.0000 0.0000
The calculated transition probabilities that data will be in a component are shown
in Figure 6-12.
C1 C2 C3 C4 C5 C8
C1 1.0000 1.3333 0.5000 0.5000 0.3333 1.0000
C2 0.0000 1.3333 0.5000 0.5000 0.3333 1.0000
C3 0.0000 0.0000 1.5000 0.0000 0.0000 1.0000
C4 0.0000 0.0000 0.0000 1.5000 1.0000 0.0000
C5 0.0000 0.0000 0.0000 0.0000 2.0000 0.0000
C8 0.0000 0.0000 0.0000 0.0000 0.0000 2.0000
85
Figure 6-12. Transition probabilities for the data being in a component
The computed transition probabilities for components are then transformed to
their associated links. The transformation is carried out using matrix multiplication with
adjacency matrix, and is shown in Figure 6-13.
C1 C2 C3 C4 C5 C8 C6 C7
C1 0.2143 0.2857 0.1071 0.1071 0.0714 0.2143 0.8333 0.1667
C2 0.0000 0.3636 0.1364 0.1364 0.0909 0.2727 0.8333 0.1667
C3 0.0000 0.0000 0.6000 0.0000 0.0000 0.4000 0.5000 0.5000
C4 0.0000 0.0000 0.0000 0.6000 0.4000 0.0000 1.0000 0.0000
C5 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 1.0000 0.0000
C8 0.0000 0.0000 0.0000 0.0000 0.0000 1.0000 1.0000 0.0000
C6 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
C7 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
86
Figure 6-13. Markov transition probabilities results for links for case study II system
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10
d1 0.1818 0.0682 0.0682 0.1364 0.1364 0.0833 0.0455 0.4167 0.4167 0.4167
d2 0.0000 0.3000 0.0000 0.2000 0.2000 0.2500 0.0000 0.2500 0.2500 0.2500
d3 0.0000 0.0000 0.3000 0.0000 0.0000 0.0000 0.2000 0.5000 0.5000 0.5000
d4 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d5 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d6 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d7 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.5000 0.5000 0.5000 0.5000
d8 0.0000 0.0000 0.0000 0.5000 0.5000 0.0000 0.0000 0.5000 0.5000 0.5000
d9 0.0000 0.0000 0.0000 0.5000 0.5000 0.0000 0.0000 0.5000 0.5000 0.5000
d10 0.0000 0.0000 0.0000 0.5000 0.5000 0.0000 0.0000 0.5000 0.5000 0.5000
87
6.5. Case Study II Results Analysis
For the case study II system seen in Figure 6-1, the MDD results shown in Figure
6-6 are used to calculate transition probabilities to be able to compare the MDD results
with the Markov chain results. The transition probabilities are shown in Figure 6-14.
88
Figure 6-14. MDD transition probabilities results for case study II system
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10
d1 0.0526 0.2632 0.1579 0.0526 0.0526 0.0526 0.0526 0.1053 0.1053 0.1053
d2 0.0000 0.0833 0.0000 0.2500 0.2500 0.1667 0.0000 0.0833 0.0833 0.0833
d3 0.0000 0.0000 0.1429 0.0000 0.0000 0.0000 0.4286 0.1429 0.1429 0.1429
d4 0.0000 0.0000 0.0000 0.2000 0.2000 0.0000 0.0000 0.2000 0.2000 0.2000
d5 0.0000 0.0000 0.0000 0.2000 0.2000 0.0000 0.0000 0.2000 0.2000 0.2000
d6 0.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 0.0000
d7 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.2500 0.2500 0.2500 0.2500
d8 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.3333 0.3333 0.3333
d9 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.3333 0.3333 0.3333
d10 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.3333 0.3333 0.3333
89
The dependencies of links with respect to d1 are displayed on the first row. For
comparison with the Markov chain results, the transition probabilities as a fraction of the
total are calculated and presented in Table 6-2. The fraction of the total is considered as
dependency strength between the link 1 (d1) and the other links.
The transition probabilities of component links from both MDD and Markov
methods are listed in Table 6-2.
Table 6-2. MDD method and Markov chain method transition probabilities and link
priorities for the case study II system
Link Transition
Probabilities
Fraction of Total
Transition Probabilities
Link Priorities
Link Markov MDD
Markov MDD Markov MD
D
link 2 (d2) 0.0682 0.2632 0.0381 0.2778 4 1
link 3 (d3) 0.0682 0.1579 0.0381 0.1667 4 2
link 4 (d4) 0.1364 0.0526 0.0763 0.0556 2 4
link 5 (d5) 0.1364 0.0526 0.0763 0.0556 2 4
link 6 (d6) 0.0833 0.0526 0.0466 0.0556 3 4
link 7 (d7) 0.0455 0.0526 0.0254 0.0556 5 4
link 8 (d8) 0.4167 0.1053 0.2331 0.1111 1 3
link 9 (d9) 0.4167 0.1053 0.2331 0.1111 1 3
link 10 (d10) 0.4167 0.1053 0.2331 0.1111 1 3
The Markov chain results and MDD results (Table 6-2) are compared in Figure 6-
15, and their difference is calculated for validation purposes. The link priorities’ results
are different for MDD and Markov chain methods. This difference occurs because the
Markov chain method is directional and counts the flow of information between the
components in a directional manner. However, the MDD method considers both the
upstream and downstream flow of information (explicit and implicit dependency effect).
90
In addition, the results differ because the Markov chain assigns initial probabilities for
links, whereas the MDD results are computed without considering link probabilities. As
seen in Figure 6-1, the MDD method recognizes link d2 and d3 as being highly critical
links because d2 and d3 are the major paths through which the data flow downstream the
system to other links as the data originate at d1. In contrast, the Markov chain method
assigns higher priorities to links d4 and d5. The difference between the results occurs due
to the ability of MDD to capture the upstream flow of information in addition to the
downstream flow of information. However, the Markov chain only focuses on the
downstream flow of information. In addition, the results differ because the Markov chain
assigns initial probabilities for the links whereas the MDD results are computed without
considering link probabilities.
Figure 6-15. Comparison of dependency strength with respect to link 1 (d1)
obtained from Markov chain and MDD for case study II system
On average, the relative value of the link dependency strength for the comparison
of the MDD to Markov chain results is 1.9909, with a standard deviation of 2.3564. To
test the Ho1 hypothesis, a Pearson chi-squared (χ2) test on the priorities of the links was
91
conducted, resulting in a p value of 0.0111. At a significance level of 0.05, we reject the
null hypothesis Ho1, and we accept the alternative hypothesis. It is concluded that the
MDD method results in different link priorities than the Markov chain method.
None of the dependencies between two components in the evaluation application
system consisted of multiple links. Hence, we have not evaluated the second hypothesis.
92
7. CASE STUDY ANALYSIS – III
In order to study the effect of the existence of multiple links between components,
an additional case study was conducted on a system with architecture consisting of 10
components and 17 links, one-third of those links having double or triple links. The
primary reason to analyze this particular architecture is to demonstrate the ability of the
MDD method to prioritize multiple links between two components. The MDD results are
then compared with the priorities obtained from the Markov chain method, and the
results are analyzed. The architecture for the system being analyzed is shown in Figure 7-
1.
Figure 7-1. Systems architecture for case study III – one-third of dependencies
containing double or triple links
Component
9 (C9)
Component
10 (C10)
Component
1 (C1)
Component
2 (C2)
Component
4 (C4)
Component
5 (C5)
Component
6 (C6)
Component
3 (C3)
d1 d2
d13d12
d4
Component being upgraded
Component
7 (C7)d10
Component
8 (C8)
d8
d18d15
d6d5 d7
d9
d17
d16
d11
d14
d3
93
7.1. Step 1: Examination of System Architecture
In the first step of the method, the system architecture (P) and system affiliation
(A) matrices for the architecture are examined. The P and A matrices are shown in Figure
7-2 and Figure 7-3, respectively.
Figure 7-2. System adjacency matrix (P)
Figure 7-3. System affiliation matrix (A)
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10
C1 0 1 1 0 0 0 0 0 0 0
C2 0 0 0 1 0 0 0 1 0 0
C3 0 0 0 0 0 0 1 1 0 0
C4 0 0 0 0 1 1 0 0 0 0
C5 0 0 0 0 0 1 0 0 0 0
C6 0 0 0 0 0 0 0 0 0 0
C7 0 0 0 0 0 0 0 0 0 0
C8 0 0 0 0 0 0 0 0 1 0
C9 0 0 0 0 0 0 0 0 0 0
C10 0 0 0 0 0 0 0 0 0 0
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10
d1 0 1 0 0 0 0 0 0 0 0
d2 0 0 1 0 0 0 0 0 0 0
d3 0 0 0 1 1 0 0 0 0 0
d4 0 0 0 1 1 0 0 0 0 0
d5 0 0 0 1 0 1 0 0 0 0
d6 0 0 0 0 0 0 0 1 0 1
d7 0 0 0 0 0 0 0 1 1 0
d8 0 0 0 0 0 0 0 1 1 0
d9 0 0 0 0 0 0 1 0 0 0
d10 0 0 0 0 0 0 1 0 0 0
d11 0 0 0 0 1 1 0 0 0 0
d12 0 0 0 0 1 1 0 0 0 0
d13 0 0 0 0 0 1 0 0 0 0
d14 0 0 0 0 0 1 0 0 0 0
d15 0 0 0 0 0 1 0 0 0 0
d16 0 0 0 0 0 0 0 0 0 1
d17 0 0 0 0 0 0 0 0 1 0
d18 0 0 0 0 0 0 0 0 1 0
94
7.2. Step 2: Investigation of Dependencies between Links
The second step of the MDD method is to analyze and derive the dependencies
between component links. Looking at the system architecture in Figure 7-1, it can be seen
that dependencies between C2 and C4 contain triple links and dependencies between C4
and C5 have double links. Similarly, C3 to C8, C3 to C8, C5 to C6, and C5 to C6 contain
either double or triple links. Due to the existence of the double or triple links, some
assumptions were made in order to derive component link dependencies. These
assumptions are the following: d11 depends on data from d3; d12 depends on data from
d4; d13 depends on data from d5; d14 depends on data from d11; d15 depends on data
from d12; d16 depends on data from d6; d17 depends on data from d7; and d18 depends
on data from d8.
The explicit (E) and implicit (I) dependency matrices between links are shown in
Figure 7-4 and Figure 7-5, respectively.
95
Figure 7-4. Explicit dependency matrix (E) for case study III system
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18
d1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d2 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d3 0 0 2 2 1 0 0 0 0 0 1 1 0 0 0 0 0 0
d4 0 0 2 2 1 0 0 0 0 0 1 1 0 0 0 0 0 0
d5 0 0 1 1 2 0 0 0 0 0 1 1 1 1 1 0 0 0
d6 0 0 0 0 0 2 1 1 0 0 0 0 0 0 0 1 0 0
d7 0 0 0 0 0 1 2 2 0 0 0 0 0 0 0 0 1 1
d8 0 0 0 0 0 1 2 2 0 0 0 0 0 0 0 0 1 1
d9 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0
d10 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0
d11 0 0 1 1 1 0 0 0 0 0 2 2 1 1 1 0 0 0
d12 0 0 1 1 1 0 0 0 0 0 2 2 1 1 1 0 0 0
d13 0 0 0 0 1 0 0 0 0 0 1 1 1 1 1 0 0 0
d14 0 0 0 0 1 0 0 0 0 0 1 1 1 1 1 0 0 0
d15 0 0 0 0 1 0 0 0 0 0 1 1 1 1 1 0 0 0
d16 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0
d17 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 1
d18 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 1
96
Figure 7-5. Implicit dependency matrix (I) for case study III system
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18
d1 0 0 8 8 9 1 2 2 0 0 3 3 2 2 2 0 1 1
d2 0 0 0 0 0 1 2 2 1 1 0 0 0 0 0 0 1 1
d3 0 0 5 5 5 0 0 0 0 0 10 10 5 5 5 0 0 0
d4 0 0 5 5 5 0 0 0 0 0 10 10 5 5 5 0 0 0
d5 0 0 5 5 2 0 0 0 0 0 7 7 2 2 2 0 0 0
d6 0 0 0 0 0 0 2 2 0 0 0 0 0 0 0 0 2 2
d7 0 0 0 0 0 0 2 2 0 0 0 0 0 0 0 0 2 2
d8 0 0 0 0 0 0 2 2 0 0 0 0 0 0 0 0 2 2
d9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d11 0 0 0 0 3 0 0 0 0 0 3 3 3 3 3 0 0 0
d12 0 0 0 0 3 0 0 0 0 0 3 3 3 3 3 0 0 0
d13 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
d18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
97
7.3. Step 3: Analysis of Link Priorities
After deriving the dependency matrices, the link priorities are calculated and
analyzed. The link dependency matrix (LDM) (Figure 7-6) represents the dependency
strength between the component links. The higher the dependency strength, the higher
the priority.
98
Figure 7-6. Link dependency matrix (LDM) representing the dependency strength between links for case study III system
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18
d1 1 0 8 8 9 1 2 2 0 0 3 3 2 2 2 0 1 1
d2 0 1 0 0 0 1 2 2 1 1 0 0 0 0 0 0 1 1
d3 0 0 7 7 6 0 0 0 0 0 11 11 5 5 5 0 0 0
d4 0 0 7 7 6 0 0 0 0 0 11 11 5 5 5 0 0 0
d5 0 0 6 6 4 0 0 0 0 0 8 8 3 3 3 0 0 0
d6 0 0 0 0 0 2 3 3 0 0 0 0 0 0 0 1 2 2
d7 0 0 0 0 0 1 4 4 0 0 0 0 0 0 0 0 3 3
d8 0 0 0 0 0 1 4 4 0 0 0 0 0 0 0 0 3 3
d9 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0
d10 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0
d11 0 0 1 1 4 0 0 0 0 0 5 5 4 4 4 0 0 0
d12 0 0 1 1 4 0 0 0 0 0 5 5 4 4 4 0 0 0
d13 0 0 0 0 1 0 0 0 0 0 1 1 1 1 1 0 0 0
d14 0 0 0 0 1 0 0 0 0 0 1 1 1 1 1 0 0 0
d15 0 0 0 0 1 0 0 0 0 0 1 1 1 1 1 0 0 0
d16 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0
d17 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 1
d18 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 1 1
99
Based on the dependency strengths, the links in the system architecture are
prioritized and are recorded in the matrix in Figure 7-7. As data originate from d1 and
flow to other downstream links, the priorities of the links based on the dependency
strengths are indicated in the first row of the matrix in Figure 7-7.
100
Figure 7-7. Priorities of links based on the dependency matrix
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18
d1 1 0 2nd 2nd 1st 5th 4th 4th 0 0 3rd 3rd 4th 4th 4th 0 5th 5th
d2 0 1 0 0 0 2nd 1st 1st 2nd 2nd 0 0 0 0 0 0 2nd 2nd
d3 0 0 7 2nd 3rd 0 0 0 0 0 1st 1st 4th 4th 4th 0 0 0
d4 0 0 2nd 7 3rd 0 0 0 0 0 1st 1st 4th 4th 4th 0 0 0
d5 0 0 2nd 2nd 4 0 0 0 0 0 1st 1st 3rd 3rd 3rd 0 0 0
d6 0 0 0 0 0 2 1st 1st 0 0 0 0 0 0 0 3rd 2nd 2nd
d7 0 0 0 0 0 3rd 4 1st 0 0 0 0 0 0 0 0 2nd 2nd
d8 0 0 0 0 0 3rd 1st 4 0 0 0 0 0 0 0 0 2nd 2nd
d9 0 0 0 0 0 0 0 0 1 1st 0 0 0 0 0 0 0 0
d10 0 0 0 0 0 0 0 0 1st 1 0 0 0 0 0 0 0 0
d11 0 0 3rd 3rd 2nd 0 0 0 0 0 5 1st 2nd 2nd 2nd 0 0 0
d12 0 0 3rd 3rd 2nd 0 0 0 0 0 1st 5 2nd 2nd 2nd 0 0 0
d13 0 0 0 0 1st 0 0 0 0 0 1st 1st 1 1st 1st 0 0 0
d14 0 0 0 0 1st 0 0 0 0 0 1st 1st 1st 1 1st 0 0 0
d15 0 0 0 0 1st 0 0 0 0 0 1st 1st 1st 1st 1 0 0 0
d16 0 0 0 0 0 1st 0 0 0 0 0 0 0 0 0 1 0 0
d17 0 0 0 0 0 0 1st 1st 0 0 0 0 0 0 0 0 1 1st
d18 0 0 0 0 0 0 1st 1st 0 0 0 0 0 0 0 0 1st 1
101
With the help of the first row of the dependency matrix (Figure 7-7), the system
architecture diagram is updated (Figure 7-8). Looking at the first row of the dependency
matrix presented in Figure 7-7, it can be seen that d5 is ranked first, meaning that it is
identified as the highest priority link based on the data originating from d1.
Figure 7-8. Prioritized component links based on the MDD method
7.4. Theoretical Validation using Markov Chain
The Markov chain method is used to calculate the priorities of the component
links, and the results are compared with those of the MDD. The initial state for the
system architecture is identified, and the number of transition states is calculated. Next,
the initial state probabilities for each of the links are displayed and captured in a matrix
(Figure 7-9).
Component
9 (C9)
Component
10 (C10)
Component
1 (C1)
Component
2 (C2)
Component
4 (C4)
Component
5 (C5)
Component
6 (C6)
Component
3 (C3)
d1 d2
4th3rd
2nd
Component being upgraded
Component
7 (C7)d10
Component
8 (C8)
4th
5th4th
5th1st 4th
d9
5th
d16
3rd
4th
2nd
102
Figure 7-9. Initial state matrix
As the data flow in the architecture, the initial probability of data being in a
component is shown in Figure 7-10. In the architecture seen in Figure 7-1, C6, C7, C9,
and C10 are absorbing components, and C1, C2, C3, C4, C5, and C8 are transient
components.
Figure 7-10. Initial probability of data being in a state
With the help of initial probabilities, the expected number of times (N) the data
are in the transient components after n steps is calculated using equation 3.2. The N
matrix is shown in Figure 7-11.
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10
C1 0 1/2 1/2 0 0 0 0 0 0 0
C2 0 1/5 0 3/5 0 0 0 1/5 0 0
C3 0 0 1/5 0 0 0 2/5 2/5 0 0
C4 0 0 0 1/4 1/2 1/4 0 0 0 0
C5 0 0 0 0 1/3 2/3 0 0 0 0
C6 0 0 0 0 0 1 0 0 0 0
C7 0 0 0 0 0 0 1 0 0 0
C8 0 0 0 0 0 0 0 1/4 1/2 1/4
C9 0 0 0 0 0 0 0 0 1 0
C10 0 0 0 0 0 0 0 0 0 1
C1 C2 C3 C4 C5 C8 C6 C7 C9 C10
C1 0 1/2 1/2 0 0 0 0 0 0 0
C2 0 1/5 0 3/5 0 1/5 0 0 0 0
C3 0 0 1/5 0 0 2/5 0 2/5 0 0
C4 0 0 0 1/4 1/2 0 1/4 0 0 0
C5 0 0 0 0 1/3 0 2/3 0 0 0
C8 0 0 0 0 0 1/4 0 0 1/2 1/4
C6 0 0 0 0 0 0 1 0 0 0
C7 0 0 0 0 0 0 0 1 0 0
C9 0 0 0 0 0 0 0 0 1 0
C10 0 0 0 0 0 0 0 0 0 1
K R Q O
103
Figure 7-11. Expected number of times data are in transient states
In addition, the probability (B) that data will be absorbed in absorbing
components if data start in the transient components is calculated using equation 3.3 and
is shown in Table 7-1.
Table 7-1. Probability table showing probability of data being absorbed in
absorbing states as they originate from transient states
C6 C7 C9 C10
C1 0.3750 0.2500 0.2500 0.1250
C2 0.7500 0.0000 0.1667 0.0833
C3 0.0000 0.5000 0.3333 0.1667
C4 1.0000 0.0000 0.0000 0.0000
C5 1.0000 0.0000 0.0000 0.0000
C8 0.0000 0.0000 0.6667 0.3333
The calculated transition probabilities that data will be in a component are shown
in Figure 7-12.
C1 C2 C3 C4 C5 C8
C1 1.0000 0.6250 0.6250 0.5000 0.3750 0.5000
C2 0.0000 1.2500 0.0000 1.0000 0.7500 0.3333
C3 0.0000 0.0000 1.2500 0.0000 0.0000 0.6667
C4 0.0000 0.0000 0.0000 1.3333 1.0000 0.0000
C5 0.0000 0.0000 0.0000 0.0000 1.5000 0.0000
C8 0.0000 0.0000 0.0000 0.0000 0.0000 1.3333
104
Figure 7-12. Transition probabilities for the data being in a component
C1 C2 C3 C4 C5 C8 C6 C7 C9 C10
C1 0.2759 0.1724 0.1724 0.1379 0.1034 0.1379 0.3750 0.2500 0.2500 0.1250
C2 0.0000 0.3750 0.0000 0.3000 0.2250 0.1000 0.7500 0.0000 0.1667 0.0833
C3 0.0000 0.0000 0.6522 0.0000 0.0000 0.3478 0.0000 0.5000 0.3333 0.1667
C4 0.0000 0.0000 0.0000 0.5714 0.4286 0.0000 1.0000 0.0000 0.0000 0.0000
C5 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 1.0000 0.0000 0.0000 0.0000
C8 0.0000 0.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.6667 0.3333
C6 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
C7 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
C9 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
C10 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
105
The computed transition probabilities for components are then transformed to
their associated links. The transformation is carried out using matrix multiplication with
adjacency matrix, and is shown in Figure 7-13.
106
Figure 7-13. Markov transition probabilities results for links for case study II system
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18
d1 0.1875 0.0000 0.1500 0.1500 0.1500 0.0500 0.0500 0.0500 0.0000 0.0000 0.1125 0.1125 0.3750 0.3750 0.3750 0.0417 0.0833 0.0833
d2 0.0000 0.3261 0.0000 0.0000 0.0000 0.1739 0.1739 0.1739 0.2500 0.2500 0.0000 0.0000 0.0000 0.0000 0.0000 0.0833 0.1667 0.1667
d3 0.0000 0.0000 0.2857 0.2857 0.2857 0.0000 0.0000 0.0000 0.0000 0.0000 0.2143 0.2143 0.5000 0.5000 0.5000 0.0000 0.0000 0.0000
d4 0.0000 0.0000 0.2857 0.2857 0.2857 0.0000 0.0000 0.0000 0.0000 0.0000 0.2143 0.2143 0.5000 0.5000 0.5000 0.0000 0.0000 0.0000
d5 0.0000 0.0000 0.2857 0.2857 0.2857 0.0000 0.0000 0.0000 0.0000 0.0000 0.2143 0.2143 0.5000 0.5000 0.5000 0.0000 0.0000 0.0000
d6 0.0000 0.0000 0.0000 0.0000 0.0000 0.5000 0.5000 0.5000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.1667 0.3333 0.3333
d7 0.0000 0.0000 0.0000 0.0000 0.0000 0.5000 0.5000 0.5000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.1667 0.3333 0.3333
d8 0.0000 0.0000 0.0000 0.0000 0.0000 0.5000 0.5000 0.5000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.1667 0.3333 0.3333
d9 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d10 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d11 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.5000 0.5000 0.5000 0.5000 0.5000 0.0000 0.0000 0.0000
d12 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.5000 0.5000 0.5000 0.5000 0.5000 0.0000 0.0000 0.0000
d13 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d14 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d15 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d16 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d17 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d18 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
107
7.5. Case Study III Results Analysis
For the case study III system seen in Figure 7-1, the MDD results shown in Figure
7-6 are used to calculate transition probabilities to be able to compare the MDD results
with the Markov chain results. The transition probabilities are shown in Figure 7-14.
108
Figure 7-14. MDD transition probabilities results for case study III system
d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15 d16 d17 d18
d1 0.0222 0.0000 0.1778 0.1778 0.2000 0.0222 0.0444 0.0444 0.0000 0.0000 0.0667 0.0667 0.0444 0.0444 0.0444 0.0000 0.0222 0.0222
d2 0.0000 0.1000 0.0000 0.0000 0.0000 0.1000 0.2000 0.2000 0.1000 0.1000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.1000 0.1000
d3 0.0000 0.0000 0.1228 0.1228 0.1053 0.0000 0.0000 0.0000 0.0000 0.0000 0.1930 0.1930 0.0877 0.0877 0.0877 0.0000 0.0000 0.0000
d4 0.0000 0.0000 0.1228 0.1228 0.1053 0.0000 0.0000 0.0000 0.0000 0.0000 0.1930 0.1930 0.0877 0.0877 0.0877 0.0000 0.0000 0.0000
d5 0.0000 0.0000 0.1463 0.1463 0.0976 0.0000 0.0000 0.0000 0.0000 0.0000 0.1951 0.1951 0.0732 0.0732 0.0732 0.0000 0.0000 0.0000
d6 0.0000 0.0000 0.0000 0.0000 0.0000 0.1538 0.2308 0.2308 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0769 0.1538 0.1538
d7 0.0000 0.0000 0.0000 0.0000 0.0000 0.0667 0.2667 0.2667 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.2000 0.2000
d8 0.0000 0.0000 0.0000 0.0000 0.0000 0.0667 0.2667 0.2667 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.2000 0.2000
d9 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.5000 0.5000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d10 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.5000 0.5000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
d11 0.0000 0.0000 0.0357 0.0357 0.1429 0.0000 0.0000 0.0000 0.0000 0.0000 0.1786 0.1786 0.1429 0.1429 0.1429 0.0000 0.0000 0.0000
d12 0.0000 0.0000 0.0357 0.0357 0.1429 0.0000 0.0000 0.0000 0.0000 0.0000 0.1786 0.1786 0.1429 0.1429 0.1429 0.0000 0.0000 0.0000
d13 0.0000 0.0000 0.0000 0.0000 0.1667 0.0000 0.0000 0.0000 0.0000 0.0000 0.1667 0.1667 0.1667 0.1667 0.1667 0.0000 0.0000 0.0000
d14 0.0000 0.0000 0.0000 0.0000 0.1667 0.0000 0.0000 0.0000 0.0000 0.0000 0.1667 0.1667 0.1667 0.1667 0.1667 0.0000 0.0000 0.0000
d15 0.0000 0.0000 0.0000 0.0000 0.1667 0.0000 0.0000 0.0000 0.0000 0.0000 0.1667 0.1667 0.1667 0.1667 0.1667 0.0000 0.0000 0.0000
d16 0.0000 0.0000 0.0000 0.0000 0.0000 0.5000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.5000 0.0000 0.0000
d17 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.2500 0.2500 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.2500 0.2500
d18 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.2500 0.2500 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.2500 0.2500
109
Dependency of links with respect to d1 are displayed on the first row. For
comparison with the Markov chain results, the transition probabilities as a fraction of the
total are calculated and presented in Table 7-2. The fraction of the total is considered as
dependency strength between the link 1 (d1) and the other links.
The transition probabilities of component links from both MDD and Markov
methods are listed in Table 7-2.
Table 7-2. MDD method and Markov chain method transition probabilities and link
priorities for case study III system
Link Transition
Probabilities
Fraction of Total
Transition Probabilities
Link Priorities
Link Markov MDD Markov MDD Markov MDD
link 2 (d2) 0.0000 0.0000 0.0000 0.0000 1 6
link 3 (d3) 0.1500 0.1778 0.0695 0.1818 2 2
link 4 (d4) 0.1500 0.1778 0.0695 0.1818 2 2
link 5 (d5) 0.1500 0.2000 0.0695 0.2045 2 1
link 6 (d6) 0.0500 0.0222 0.0232 0.0227 5 5
link 7 (d7) 0.0500 0.0444 0.0232 0.0455 5 4
link 8 (d8) 0.0500 0.0444 0.0232 0.0455 5 4
link 9 (d9) 0.0000 0.0000 0.0000 0.0000 7 6
link 10 (d10) 0.0000 0.0000 0.0000 0.0000 7 6
link 11 (d11) 0.1125 0.0667 0.0521 0.0682 3 3
link 12 (d12) 0.1125 0.0667 0.0521 0.0682 3 3
link 13 (d13) 0.3750 0.0444 0.1737 0.0455 1 4
link 14 (d14) 0.3750 0.0444 0.1737 0.0455 1 4
link 15 (d15) 0.3750 0.0444 0.1737 0.0455 1 4
link 16 (d16) 0.0417 0.0000 0.0193 0.0000 6 6
link 17 (d17) 0.0833 0.0222 0.0386 0.0227 4 5
link 18 (d18) 0.0833 0.0222 0.0386 0.0227 4 5
110
The Markov chain results and MDD results are compared in Figure 7-15, and
their difference is calculated for validation purposes. On average, the relative value of the
link dependency strength for the comparison of MDD to Markov chain results is 1.0388,
with a standard deviation of 1.0305. A Pearson chi-squared (χ2) test on the link priorities
resulted in a p value of 0.000005. At a significance level of 0.05, null hypothesis Ho1 is
rejected, and we accept the alternative hypothesis. It is concluded that for case study III,
the MDD method results in different link priorities than the Markov chain method.
Figure 7-15. Comparison of dependency strength with respect to link 1 (d1)
obtained from Markov chain and MDD methods for case study III system
One of the reasons for the difference in results between the MDD and Markov
chain methods is Markov chain being unable to differentiate priorities between multiple
links in a dependency between two components. As seen in Figure 7-1, case study system
III consists of a dependency between two components that has two or more links. This
enables us to evaluate the second hypothesis. The results from case study III show that
the MDD method can prioritize multiple links existing between two components. on the
111
other hand, the Markov chain method assigns all the links an identical priority. Therefore,
we accept the second null hypothesis (Ho2).
The Markov chain method results in identical dependency strengths for multiple
links between two components. As seen in Figure 7-1, the dependency between
component C2 and C4 consists of three links, namely d3, d4, and d5. Looking at Table 7-
2, Markov chain link priorities for d3, d4, and d5 are identical, whereas the MDD method
is able to assign them different priorities. Therefore, we accept the second null hypothesis
(Ho2), and it is concluded that the MDD method is capable of identifying link priorities
when there are two or more links between components.
The Markov chain method is directional and counts the flow of information
between components in a directional manner. However, the MDD method considers both
the upstream and downstream flow of information (explicit and implicit dependency
effect). In addition, the results differ because the Markov chain method assigns initial
probabilities for the links, whereas MDD results are computed without considering link
probabilities.
112
8. SUMMARY OF RESULTS
8.1. Discussion
The previous chapter presented in detail three case studies along with their respective
results and data analyses. The case studies were tailored to demonstrate the application of
the MDD method in progressively more complex configurations, with the goal of
answering the research questions and evaluating the validity of the research hypotheses.
The research questions that were asked during the earlier phase of the research were
answered as the case studies evaluations results were analyzed.
In response to the first research question (RQ1: Is it possible to find a method to
effectively prioritize links in a component based system based on their importance?), it
was found that the MDD method can effectively identify the priority of links in a CBS
(component based system) based on the calculation of the dependency strengths between
component links. Component coupling and information flow analysis were used in the
MDD method, and these techniques were leveraged with the DSM technique to calculate
the dependency strengths of the links, which then led to calculation of priorities. For the
three case studies, the highest priority links and lowest priorities links identified through
the MDD method are shown in Table 8-1.
113
Table 8-1. High priority and low priority links summary for the MDD method for
the three case studies
Case Study High Priority link
(Critical link)
Low priority link
(Less critical link)
Case Study I link 4 (d4) link 7 (d7)
Case Study II link 2 (d2) link 7 (d7)
Case Study III link 5 (d5) link 18 (d18)
In regards to the second research question (RQ2: Is it possible to leverage
component coupling and information flow analysis in the method to identify critical
links?), component coupling and informational flow analysis with the advantage of DSM
were used to calculate the link dependency strengths using the MDD method. The
dependency strengths were then used to evaluate link priorities.
Our research showed that the MDD method is easily implementable to complex
systems where multiple communication links exist between components. The third case
study contained dependent components’ pairs with two or more links. The MDD method
was able to prioritize these links between two components, as seen in Table 8-2. Each of
the links shown in Table 8-2 is one of the two or more links that exist within a
dependency between a component pair in case study III system. This addresses the third
research question (RQ3: Can the method be applicable to complex system where there
exist two or more links between two components?).
114
Table 8-2. Dependency strengths average difference and standard deviation results
summary
Link Dependency Strength Priority
link 3 (d3) 0.1818 2
link 4 (d4) 0.1818 2
link 5 (d5) 0.2045 1
link 7 (d7) 0.0455 4
link 8 (d8) 0.0455 4
link 9 (d9) 0.0000 6
link 10 (d10) 0.0000 6
link 11 (d11) 0.0682 3
link 12 (d12) 0.0682 3
link 14 (d14) 0.0455 4
link 15 (d15) 0.0455 4
link 17 (d17) 0.0227 5
link 18 (d18) 0.0227 5
Regarding the fourth and last research question (RQ4: Can the proposed method be easily
compared with the existing methods?), the MDD method is compared with the existing
component prioritization method (Markov chain), as seen in Table 8-3. The differences
between the MDD and Markov chain results on dependency strengths are significant. The
difference between the two methods exists due to the ability of the MDD method to identify
the priority of links for a system with multiple links between two components. The Markov
chain results assigns those links identical priority. Because the Markov chain method
requires pre-assignment of probability and weights to the links, calculations are considered
complex and less flexible than those of the MDD method.
115
Table 8-3. Dependency strengths average difference and standard deviation results
summary
Case Study Average
Difference Standard Deviation
Case Study I 1.6683 1.9165
Case Study II 1.9909 2.3564
Case Study III 1.0388 1.0305
In order to validate the MDD method, research hypotheses were established, three
case studies with progressively complex system architectures were used to evaluate the
MDD method, and the results were analyzed. The first null hypothesis Ho1 was formed to
evaluate if the link priorities obtained from the MDD method and Markov chain method
are identical. An alternative hypothesis (Ha1) was proposed to confirm the non-identical
link priorities for the two methods. The second null hypothesis Ho2 was established to
evaluate if the MDD method is able to prioritize links even when there exist two or more
links between two components.
The results from all three case studies were used to answer the first research
hypothesis. A Pearson chi-squared (χ2) test on the link priorities for the three case studies
resulted in p values <0.05, as shown in Table 8-4. At a significance level of 0.05, the null
hypothesis Ho1 is rejected, and the alternative hypothesis Ha1 is accepted. It is concluded
that the MDD method results in different link priorities than the Markov chain method.
116
Table 8-4. Pearson chi-square test results on priority of links results summary
Case Study Statistical Test p-value
Case Study I Chi-squared test 0.000486 (significant)
Case Study II Chi-squared test 0.011187 (significant)
Case Study III Chi-squared test 0.000005 (significant)
Multiple reasons contributed to the results being different. The MDD method
considers both the upstream and downstream flow of information (explicit and implicit
dependency effect). In addition, the Markov chain assigns initial probabilities for links,
whereas the MDD method results are computed without any link probability assignments.
The second hypothesis is about the ability of the MDD to prioritize links when
more than two links exist between two dependent components. Case study III was
designed specifically to test the second hypothesis. The results obtained from this case
study showed that the MDD method is able to assign different priorities to links between
two components, whereas the Markov chain method assigns identical link priorities.
Therefore, we accept the second null hypothesis (Ho2) and conclude that prioritization of
links is possible through the MDD method for those systems whose dependent
component pair consists of two or more links.
8.2. Possible Future Improvements
This section focuses on the interpretation of the results and possible alternative
implementation of the MDD analysis approach. Even though the results indicate that
MDD is a promising method, several assumptions were made throughout the design and
implementation of the approach. In this research study, the MDD was applied to four
117
(one demonstration example and three case studies) component based systems (CBS);
however, the method can be applied to other CBS.
A number of improvements can be made to the implementation, such as
considering a dependency of a component to itself, including not only static dependencies
but also the dynamic relationships between the components, adding weights to the
dependencies so some dependencies are weighted more than others, and considering
adding probabilities of the dependencies with their failure rate. Additional research
should focus on the implementation and testing of the MDD on large CBS.
This method can be tailored for analysis of a system of systems (SoS). As SoS
architecture is represented with nodes and edges as in a CBS, and as the data flow pattern
and relationship between nodes are identified, the MDD method can be implemented in
such architecture to identify critical information flow edges or links between nodes.
Additional research should also look into similarities or differences between CBS and
SoS architectures and how MDD can be tailored to analyze SoS architecture.
8.3. Validity Analysis
Case study I and II systems were used for demonstration purposes of the MDD
method. The results are promising and motivate additional research. Several assumptions
were made throughout the design and implementation of the approach. One assumption is
that link pairs that provide or receive information to or from common components are
likely to be interacting. Additional research should focus on systems where the
interaction between the link pairs is not evident.
For simplification and analysis purposes, the components and links were given
equal weights in Markov chain analysis; hence, there is equal probability between the
118
available directions as data pass through the system’s components and links. In real-
world applications, a system’s components carry different weights. Weights can be added
to the analysis by incorporating the coefficient for each component or link. More
empirical investigation is necessary to assess the actual, practical applicability of the
method to systems with unequal component and links’ weights.
The main threat to validity in the evaluation of the MDD approach concerns
external validity, i.e., the possibility to generalize the findings of link dependency
strengths for other systems with different characteristics, link weights, and probabilities
associated with components and links. Since this method was evaluated in only three
CBS (case studies I, II, and III), in order to extend the findings, additional
implementation of the approach should take place in other real-world systems.
119
9. CONCLUSIONS
This research study reviews problems associated with integrating commercial off-
the-shelf components resulting in complex systems with many links that are difficult to
test. As testing every link is unfeasible, correctly identifying which links to test is
challenging. The key to cost-effective integration testing is identifying the component
links’ priority. Problems associated with prioritization of links for testing, including
dependency analysis for component based systems (CBS), are reviewed. Current methods
for prioritization of links for testing are neither sufficient nor proven.
This dissertation proposes the multi-dimensional dependency (MDD) analysis, a
method consisting of three major steps to calculate the dependency strengths between
links, in order to identify the critical links in a CBS. The MDD method is designed to
provide a dependency analysis approach for the challenging task of critical link
identification during system integration and testing. Based on the latest research, the
MDD method incorporates the design structure matrix (DSM), an affiliation network, and
an organizational communication analysis technique. The MDD method demonstrates
that it is possible to combine these techniques to develop a method that identifies the
critical component links and enables prioritization of these links during testing.
The method is demonstrated through three progressively more complex case
studies with the goal of investigating the research hypothesis. In each case study the
MDD method is applied step by step, and the results and data analyses are explained in
detail. The results obtained from the MDD method enable us to solve the prioritization
120
problem through identification of critical links. This ultimately helps testing as a
component goes through replacement or repair.
This dissertation addresses the issue of prioritization of links for testing for a CBS
by proposing a method that uses components’ coupling and information flow analysis to
calculate dependency strengths between component links, which, in turn are used to
compute the links’ priorities.
The major contributions of the research are the following: (1) the introduction of
the MDD method for quantifying the dependency strengths between a systems’
component links; (2) the application of the DSM and organizational communication
analysis to identify critical components’ link in a system; (3) the implementation of the
MDD method through the evaluation of multiple case studies; and (4) the evaluation of
the effectiveness and usability of the MDD method for CBS integration and links’
prioritization (Kafle, Sarkani, and Mazzuchi, 2015).
The results and the evaluations were used to answer the research questions. In
response to the first research question (RQ1: Is it possible to find a method to effectively
prioritize links in a CBS based on their importance?), it is found that the MDD method
can effectively identify the priority of links in a CBS based on the calculation of the
dependency strengths between component links.
In regards to the second research question (RQ2: Is it possible to leverage
component coupling and information flow analysis in the method to identify critical
links?), component coupling is leveraged through DSM and informational flow analysis
using organizational communication analysis to identify the critical component links in a
system.
121
The research shows that the MDD method is also applicable to a real-world CBS.
This addresses the third research question (RQ3: Can the method be applicable to real-
world component based system?).
Regarding the fourth and last research question (RQ4: Can the proposed method
be used easily compared with the existing methods?), the MDD method is compared with
the existing component prioritization method, i.e. Markov chain, and it is found that the
MDD is easier to implement. Because the Markov chain method must be evaluated with
respect to each link, as probabilities need to be assigned for each link, the method’s
calculations are considered complex and less flexible than those of the MDD method. As
the size of the system and the number of components and links grow, it becomes
increasingly difficult to model correctly the components, their links, and probabilities
using the Markov chain method. In contrast, the MDD method is scalable, as it allows for
input of the data into a matrix, and requires no assignment of probabilities to the links.
Additionally, the MDD method provides results from the perspective of all links.
The results obtained from the example applications were subsequently compared
with Markov chain analysis results. A chi-square test on the links priorities resulted in p
values less than the significance level of 0.05, which resulted in the rejection of the first
null hypothesis Ho1 and acceptance of the alternative hypothesis. It is concluded that the
MDD method results in different link priorities than Markov chain method. In addition,
due to the ability of the MDD method to prioritize multiple links between dependent
component pairs, the second null hypothesis (Ho2) is accepted, and it is concluded that
the MDD method is capable of identifying priorities of multiple links between two
components.
122
The difference between the two methods exists because the Markov chain is
unidirectional and considers the assignment of predefined link probabilities, whereas the
MDD method takes into account both the upstream and downstream flow of information.
In addition, the MDD method does not require pre-assignment of link probabilities.
These findings establish that the MDD method is a promising and feasible
approach to critical link prioritization. This method warrants additional empirical studies
of its applicability and the parameters used in the three case studies. The evaluation
results confirm the research goals targeted toward the usability, effectiveness, and
applicability of the method.
A number of directions for further improvement of the proposed method are
suggested. The implementation of the method can be improved, for example, by
considering the self-dependency characteristics of a component, including not only static
dependencies but also the dynamic relationships between components. Moreover, the
method can be refined by allowing the assignment of non-uniform values to the weight of
the links to increase the method’s applicability. Since links between components in a
CBS can have various degrees of reliability, the MDD method can allow the addition of
failure rate probabilities to links. Inclusion of the failure rate probabilities to links
increases the applicability of the method to a real-world CBS with multiple degrees of
reliability.
Automation is another area for future research. An automatic MDD process
would read the architecture of the system, locate the components and their links, and
analyze them based on the read properties and characteristics of the components and
123
components links. This will help implement the method in a large CBS with hundreds of
interconnected components.
Additional areas of interest for further investigation include but are not limited to
the assessment of a system with multiple types of data flow throughout the system. The
results and the conclusions of this research study are based on the assumption that the
link between two components satisfies a generic dependency. However, as discussed in
Chapter 2 and presented in Table 2-1, dependencies between components are categorized
into eight major categories. These various types of dependencies can be considered for
future research.
A last but not least direction to future work is the implementation and testing of
the MDD method on large-scale systems. This research shows that implementing the
MDD method on a small-scale system is promising. Future work should investigate the
implementation of the method in a large system with multiple components operational in
various environments and analyze the method’s applicability and usability.
124
REFERENCES
Abdellatief, Majdi, Abu Bakar Md Sultan, Abdul Azim Abdul Ghani, and Marzanah A.
Jabar. 2012. "A mapping study to investigate component-based software system
metrics." Journal of Systems and Software, 86, no.3 587-603.
Ahmadi, Reza, Thomas A. Roemer, and Robert H. Wang. 2001. "Structuring product
development processes." European Journal of Operational Research 130, no.3 539-
558.
Allen, Robert, and David Garlan. 1997. "A formal basis for architectural connection." ACM
Transactions on Software Engineering and Methodology (TOSEM) 6, no.3 213-249.
Allen, Thomas J. 1977. "Managing the flow of technology: Technology transfer and the
dissemination of technological information within the R & D organization." MIT Press
329.
Altus, Stephen S., Ilan M. Kroo, and Peter J. Gage. 1996. "A genetic algorithm for
scheduling and decomposition of multidisciplinary design problems." Journal of
Mechanical Design 118, no.4 486-489.
Anderson, Brian DO, and Sumeth Vongpanitlerd. 2006. Network analysis and synthesis: a
modern systems theory approach. Courier Dover Publications.
Arias, Trosky B. Callo, Pieter van der Spek, and Paris Avgeriou. 2011. "A practice-driven
systematic review of dependency analysis solutions." Empirical Software Engineering
16, no.5 544-586.
Austin, Simon, Andrew Baldwin, Baizhan Li, and Paul Waskett. 2000. "Analytical design
planning technique (ADePT): a dependency structure matrix tool to schedule the
building design process." Construction Management & Economics 18, no. 2 173-182.
Aziz, Adil A., Wan MN Wan Kadir, and Adil Yousif. 2012. "An architecture-based
approach to support alternative design decision in component-based system: a case
study from information system domain." International Journal of Advanced Science
and Technology 1-14.
Baah, George K., Andy Podgurski, and Mary Jean Harrold. 2010. "The probabilistic
program dependence graph and its application to fault diagnosis." IEEE Transactions
on Software Engineering 36, no.4 528-545.
Baldwin, Andrew N., Simon A. Austin, Tarek M. Hassan, and Anthony Thorpe. 1998.
"Planning building design by simulating information flow." Automation in
Construction 8, no.2 149-163.
Baldwin, Carliss Y., and Kim B. Clark. 2000. Design rules: The power of modularity. Vol.
1. The MIT Press.
Balmas, Françoise, Harald Wertz, Rim Chaabane, and L. Artificielle. 2005. "Visualizing
dynamic data dependences as a help to maintain programs." International conference
on software maintenance.
125
Bartles, Andrew. 2013. Forrester Research. April 25. Accessed January 01, 2015.
www.forrester.com.
Bass, Len, Charles Buhman, Santiago Comella-Dorda, Fred Long, John Robert, Robert
Seacord, and Kurt Wallnau. 2000. Volume I: Market Assessment of Component-Based
Software Engineering. Internal Research and Development, Carnegie Mellon
University.
Bass, Len: Clements, Paul, and Rick Kazman. 1998. Bass, Len, Paul Clements, and
Software Architecture in Practice. India: Pearson Education.
Beck, Fabian, and Stephan Dieh. 2010. "Evaluating the impact of software evolution on
software clustering." 17th Working Conference on Reverse Engineering (WCRE).
IEEE. 99-108.
Becker, Ofri, Joseph B. Asher, and Ilya Ackerman. 2000. "A method for system interface
reduction using N2 charts." Systems Engineering 3, no.1 27-37.
Beizer, Boris. 1984. Software system testing and quality assurance. Van Nostrand
Reinhold Co.
Bieman, James M, and Byung-Kyoo Kang. 1998. "Measuring design-level cohesion."
IEEE Transactions on Software Engineering, 24, no.2 111-124.
Bieman, James M., and Linda M. Ott. 1994. "Measuring functional cohesion." IEEE
Transactions on Software Engineering, 20, no. 7 644-657.
Bohner, Shawn A. 2002. "Extending software change impact analysis into cots
components." 27th Annual NASA Goddard/IEEE Software Engineering Workshop.
IEEE: 175-182.
Brady, Timothy K. 2002. "Utilization of dependency structure matrix analysis to assess
complex project designs." ASME 2002 International Design Engineering Technical
Conferences and Computers and Information in Engineering Conference. American
Society of Mechanical Engineers: 231-240.
Brereton, Pearl, and David Budgen. 2000. "Component-based systems: A classification of
issues." Computer 33, no.11 54-62.
Brøndum, John. 2012. Architectural dependency analysis and modelling. PhD Thesis,
University of New South Wales.
Brown, Aaron, Gautam Kar, and Alexander Keller. 2001. "An active approach to
characterizing dynamic dependencies for problem determination in a distributed
environment." International Symposium on Network Management. IEEE/IFIP: 377-
390.
Browning, Tyson R. 2001. "Applying the design structure matrix to system decomposition
and integration problems: a review and new directions." Engineering Management,
IEEE Transactions on 48(3): 292-306.
Browning, Tyson R. 1996. Systematic IPT integration in lean development programs. PhD
Thesis, Massachusetts Institute of Technology.
126
Browning, Tyson R. 1999. "The design structure matrix." Technology Management
Handbook, RC Dorf, Ed. Boca Raton, FL: Chapman & Hall/CRCnet-BASE 103-111.
Carnegie Mellon. 2012. "Software Engineering Institute." Carnegie Mellons Website.
Accessed March 30, 2015.
http://www.sei.cmu.edu/productlines/frame_report/comp_dev.htm.
Carrascosa, Maria, Steven D. Eppinger, and Daniel E. Whitney. 1998. "Using the design
structure matrix to estimate product development time." ASME design engineering
technical conferences (design automation conference). ASME: 13-16.
Chen, Kunrong, and Vaclav Rajlich. 2000. "Case study of feature location using
dependence graph." IWPC 2000. 8th International Workshop on Program
Comprehension. IEEE: 241-247.
Chen, Li, and Simon Li. 2005. "Analysis of decomposability and complexity for design
problems in the context of decomposition." Journal of Mechanical Design: 127 545.
Chen, Li, Zhendong Ding, and Simon Li. 2005. "A formal two-phase method for
decomposition of complex design problems." Journal of Mechanical Design: 127 184.
Chen, Shi-Jie Gary, and Li Lin. 2003. "Decomposition of interdependent task group for
concurrent engineering." Computers & Industrial Engineering 44, no.3 435-459.
Chen, Yanping, Robert L. Probert, and Hasan Ural. 2007. "Model-based regression test
suite generation using dependence analysis." 3rd international workshop on Advances
in model-based testing. ACM: 54-62.
Chen, Yigang, W. T. Tsai, and Daniel Chao. 1993. "Dependency analysis-a Petri-net-based
technique for synthesizing large concurrent systems." IEEE Transactions on Parallel
and Distributed Systems, 4: 414-426.
Clarkson, P. John, Caroline Simons, and Claudia Eckert. 2004. "Predicting change
propagation in complex design." Journal of Mechanical Design 126: 788.
Clarkson, Peter John, and James Robert Hamilton. 2000. "‘Signposting’, a parameter-
driven task-based model of the design process." Research in Engineering Design 12(1):
18-38.
Cornelissen, B., A. Zaidman, A. van Deursen, L. Moonen, and R. Koschke. 2009. "A
Systematic Survey of Program Comprehension through Dynamic Analysis."
Cornelissen, B.; Zaidman, A.; van Deursen, A.; Moonen, L.; Koschke, R. "A
Systematic Survey of Program Comprehension through Dynamic Analysis", Software
Engineering, IEEE Transactions on Software Engineering: 684 - 702.
Councill, Bill, and George T. Heineman. 2001. Component-based software engineering:
putting the pieces together. Addison-Wesley.
Cox, Lisa, Harry S. Delugach, and David Skipper. 2001. "Dependency analysis using
conceptual graphs." 9th international conference on conceptual structures. ICCS: 117-
130.
Crnkovic, Ivica, and Magnus Larsson. 2002. "Challenges of component-based
development." Journal of Systems and Software 61, no. 3 201-212.
127
Crnkovic, Ivica, and Magnus P.H. Larsson. 2002. Building reliable component-based
software systems. Artech House Publishers.
Crnkovic, Ivica, Magnus Larsson, and Otto Preiss. 2005. "Concerning predictability in
dependable component-based systems: Classification of quality attributes."
Architecting Dependable Systems III, Springer Berlin Heidelberg: 257-278.
Crnkovic, Ivica, Séverine Sentilles, Aneta Vulgarakis, and Michel RV Chaudron. 2011. "A
classification framework for software component models." IEEE Transactions on
Software Engineering 37, no.5 593-615.
Danilovic, Mike, and Tyson R. Browning. 2007. "Managing complex product development
projects with design structure matrices and domain mapping matrices." International
Journal of Project Management 25, no. 3 300-314.
DAU. 2012. "Test & Evaluation Guide." Acquisition Community Connection.
https://acc.dau.mil/temg.
Egyed, Alexande. 2003. "A scenario-driven approach to trace dependency analysis." IEEE
Transactions on Software Engineering: 116-132.
Eppinger, Steven D. 2002. "Patterns of product development interactions." DSpace@MIT.
Eppinger, Steven D., Daniel E. Whitney, Robert P. Smith, and David A. Gebala. 1994. "A
Model-Based Method for Organizing Tasks in Product Development." Research in
Engineering Design 6: 1-13.
Eppinger, Steven, and Tysons R. Browning. 2012. structure matrix methods and
applications. MIT press.
Ester, Martin, Hans-Peter Kriegel, Jorg Sander, and Xiaowei Xu. 1996. "A density-based
algorithm for discovering clusters in large spatial databases with noise." KDD 96: 226-
231.
Fernandez, Carlos Iñaki Gutierrez. 1998. Integration analysis of product architecture to
support effective team co-location. ME thesis, Cambridge, MA: MIT.
Fernando, E. P. C. 1969. "Use of interdependency matrix for expediting implementation
of an integrated development programme in a developing country." 2nd Int. Congr.
Project Planning by Network Analysis: 76-85.
Ferrante, Jeanne, Karl J. Karl J. Ottenstein, and Joe D. Warren. 1987. "The program
dependence graph and its use in optimization." ACM Transactions on Programming
Languages and Systems (TOPLAS) 9, no. 3 319-349.
Fowler, Martin. 2004. "Inversion of control containers and the dependency injection
pattern." Accessed March 2, 2015. http://martinfowler.com/.
Garousi, Vahid, Lionel C. Briand, and Yvan Labiche. 2006. "Analysis and visualization of
behavioral dependencies among distributed objects based on UML models." Model
Driven Engineering Languages and Systems. Springer Berlin Heidelberg: 365-379.
Gill, Nasib S., and P.S. Grover. 2004. "Few important considerations for deriving interface
complexity metric for component-based systems." ACM SIGSOFT Software
Engineering Notes 29, no. 2 ACM: 4-4.
128
Greevy, Orla, and Stephane Ducasse. 2005. "Correlating features and code using a compact
two-sided trace analysis approach." Ninth European Conference on Software
Maintenance and Reengineering. IEEE: 314-323.
Grose, David L. 1994. "Reengineering the aircraft design process." The fifth
AIAA/USAF/NASA/ISSMO symposium on multidisciplinary analysis and optimization.
AIAA: 7-9.
Han, Jun. 1998. "A comprehensive interface definition framework for software
components." Software Engineering Conference. IEEE: 110-117.
Hartuv, Erez, and Ron Shamir. 2000. "A clustering algorithm based on graph connectivity."
Information Processing Letters 76, no.4 175-181.
Hassan, Ahmed E., and Richard C. Holt. 2004. "Predicting change propagation in software
systems." 20th IEEE International Conference on Software Maintenance. IEEE: 284-
293.
Hayes, M. 1969. "The role of activity precedence relationships in node-oriented networks."
2nd Int. Congr. for Project Planning by Network Analysis: 128-146.
Henderson, Rebecca M., and Kim B. Clark. 1990. "Architectural innovation: the
reconfiguration of existing product technologies and the failure of established firms."
Administrative science quarterly, JSTOR: 9-30.
Huang, Lulu, and Yeong-Tae Song. 2007. "Precise dynamic impact analysis with
dependency analysis for object-oriented programs." 5th ACIS International Conference
on Software Engineering Research, Management & Applications. IEEE: 374-384.
Huang, Shi-Ming, Chih-Fong Tsai, and Po-Chun Huang. 2009. "Component-based
software version management based on a Component-Interface Dependency Matrix."
Journal of Systems and Software 82, no.3 382-399.
Huovila, P., L. Koskela, M. Lautanala, K. Pietiläinen, and V.P Tanhuanpää. 1997. "Use of
the design structure matrix in construction." Lean Construction: 417-425.
Ivkovic, Igor, and Kostas Kontogiannis. 2006. "Towards automatic establishment of model
dependencies using formal concept analysis." International Journal of Software
Engineering and Knowledge Engineering 16, no.4 499-522.
Jarratt, Timothy, and M.A. John Clarkson. 2005. "Engineering change." Design Process
Improvement, Springer London: 262-285.
Jiang, Tao, Nicolas Nicolas Gold, Mark Mark Harman, and Zheng Zheng Li. 2008.
"Locating dependence structures using search-based slicing." Information and
Software Technology 50, no.12 1189-1209.
Jin, HongXia, and P. Santhanam. 2001. "An approach to higher reliability using software
components." 12th International Symposium on Software Reliability Engineering.
Hong Kong: IEEE ISSRE: 2-11.
Jourdan, Guy-Vincent, Panitee Ritthiruangdech, and Hasan Ural. 2006. "Test suite
reduction based on dependence analysis." Computer and Information Sciences–ISCIS
2006. Springer Berlin Heidelberg: 1021-1030.
129
Jungmayr, Stefan. 2002. "Identifying test-critical dependencies." International Conference
on Software Maintenance. IEEE: 404-413.
Kafle, S., Sarkani, S., & Mazzuchi, T. A. (2015). Prioritization of Component-to-
Component Links for Testing in Component Based Systems. International Testing and
Evaluation Association.
Kagdi, Huzefa, and Jonathan I. Maletic. 2007. "Combining single-version and evolutionary
dependencies for software-change prediction." ICSE Workshops MSR'07. Fourth
International Workshop on Mining Software Repositories. IEEE: 17-17.
Kaufman, Leonard, and Peter J. Peter J. Rousseeuw. 2009. Finding groups in data: an
introduction to cluster analysis. Vol. 344. John Wiley & Sons.
Kemeny, J. G., and Snell, L. J. (1976). Finite Markov Chains, Undergraduate texts in
mathematics. Springer New York.
Khan, Safoora Shakil, Phil Greenwood, Alessandro Garcia, and Awais Rashid. 2008. "On
the impact of evolving requirements-architecture dependencies: an exploratory study."
Advanced Information Systems Engineering. Springer Berlin Heidelberg: 243-257.
Kockler, Frank, T. Withers, J. Poodiack, and M. Gierman. 1990. Systems Engineering
Management Guide. Management Guide, FORT BELVOIR VA: DEFENSE
SYSTEMS MANAGEMENT COLL FORT BELVOIR VA.
Korel, Bogdan, Luay Ho Tahat, and Boris Vaysburg. 2002. "Model based regression test
reduction using dependence analysis." International Conference on Software
Maintenance. IEEE: 214-223.
Kubat, Peter. 1989. "Estimation of reliability for communication/computer networks
simulation/analytic approach." IEEE Transactions on Communications 37, no.9 927-
933.
Kusiak, Andrew. 1999. Engineering design: products, processes, and systems. Academic
Press, Inc.
Kusiak, Andrew, and Juite Wang. 1993. "Decomposition of the design process." Journal
of Mechanical Design 115, no.4: 687-695.
Lai, Xiaoxia, and John K. Gershenson. 2008. "Representation of similarity and dependency
for assembly modularity." The International Journal of Advanced Manufacturing
Technology 37 no. 7-8 803-827.
Lano, Ralf J. 1979. A technique for software and systems design. Vol. 3. North-Holland:
North-Holland.
Larsson, Magnus. 2000. Applying Configuration Management Techniques to Component-
Based Systems. Thesis Dissertation, Uppsala, Sweden: Uppsala University Department
of Information Technology.
Law, James, and Gregg Rothermel. 2003. "Whole program path-based dynamic impact
analysis." 25th International Conference on Software Engineering. IEEE: 308-318.
Li, Bixin. 2003. "Managing dependencies in component-based systems based on matrix
model." Net. ObjectDays Conf: 22-25.
130
Li, Simon. 2011. "A matrix-based clustering approach for the decomposition of design
problems." Research in Engineering Design 22, no.4 263-278.
Lienhard, Adrian, Orla Greevy, and Oscar Nierstrasz. 2007. "Tracking objects to detect
feature dependencies." 15th IEEE International Conference on Program
Comprehension. IEEE: 59-68.
Lorsch, Jay William, and Paul R. Lawrence. 1972. Managing group and intergroup
relations. RD Irwin.
Loyall, Joseph P., and Susan A. Mathisen. 1993. "Using dependence analysis to support
the software maintenance process." Conference on Software Maintenance. IEEE: 282-
291.
Lydon, Bill. 2012. InTech. September. Accessed January 13, 2014.
http://www.isa.org/InTechTemplate.cfm?template=/ContentManagement/ContentDis
play.cfm&ContentID=91467.
MacCormack, Alan, John Rusnak, and Carliss Y. Baldwin. 2006. "Exploring the structure
of complex software designs: An empirical study of open source and proprietary code."
Management Science 52(7): 1015-1030.
Malmström, Johan, and Johan Malmqvist. 1998. Trade off analysis in product structures:
A case study at Celsius Aerotech. NordDesign'98.
Mancinelli, F., J. Boender, R. Di Cosmo, J. Vouillon, B. Durak, X. Leroy, and R. Treinen.
2006. "Managing the Complexity of Large Free and Open Source Package-Based
Software Distributions." 21st IEEE/ACM International Conference on Automated
Software Engineering. IEEE: 199-202.
Mao, Chengying, Jinlong Zhang, and Yansheng Lu. 2007. "Using dependence matrix to
support change impact analysis for CBS." International Conference on Computational
Science and its Applications. IEEE: 192-200.
Martin, Robert C. 1996. "The dependency inversion principle." C++ Report 8, no.6 61-66.
Maule, Andy, Wolfgang Emmerich, and David Rosenblum. 2008. "Impact analysis of
database schema changes." ACM/IEEE 30th International Conference on Software
Engineering ICSE'08. IEEE: 451-460.
McComb, Dave, Simon Robe, Simon Hoare, and Stew Crawford-Hines. 2002.
"Dependency analysis and visualization as tools to prolong system life." Computer
Software and Applications Conference, 2002. COMPSAC 2002. Proceedings. 26th
Annual International. IEEE: 463-465.
McCord, Kent R., and Steven D. Eppinger. 1993. Managing the integration problem in
concurrent engineering. PhD Dissertation, Massachusetts Institute of Technology,
Department of Mechanical Engineering.
Medvidovic, Nenad, and Richard N. Taylor. 2000. "A classification and comparison
framework for software architecture description languages." Software Engineering,
IEEE Transactions on 26, no.1: 70-93.
131
Mehta, Nikunj R., Nenad Medvidovic, and Sandeep Phadke. 2000. "Towards a taxonomy
of software connectors." The 22nd international conference on Software engineering.
ACM: 178-187.
Mei, Hong, Lu Zhang, and Fuqing Yang. 2001. "A software configuration management
model for supporting component-based software development." ACM SIGSOFT
Software Engineering Notes 26.2: 53-58.
Michelena, Nestor F., and Panos Y. Papalambros. 1995. "Optimal model-based
decomposition of powertrain system design." Journal of Mechanical Design 117, no.
4 499-505.
Mihm, Jürgen, Christoph Loch, and Arnd Huchzermeier. 2003. "Problem–Solving
Oscillations in Complex Engineering Projects." Management Science 49, no. 6 733-
750.
Mikael, Akerholm, Jan Carlson, Johan Frediriksson, Hans Hansson, John Håkansson,
Moller Anders, Paul Pettersson, and Massimo Tivoli. 2007. "The SAVE approach to
component-based development of vehicular systems." Journal of Systems and Software
80, no. 5 655-667.
Moriconi, Mark, and Timothy C. Winkler. 1990. "Approximate reasoning about the
semantic effects of program changes." IEEE Transactions on Software Engineering on
16, no. 9 980-992.
Mubarak, M., & Alagar, V. (2012). A component‐based development process for
trustworthy systems. Journal of Software: Evolution and Process, 815-835.
Oracle. 2014. Java SE Desktop Technologies. Accessed 01 13, 2014.
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-138795.html.
Orso, Alessandro, Taweesup Apiwattanapong, and Mary Jean Harrold. 2003. "Leveraging
field data for impact analysis and regression testing." ACM SIGSOFT Software
Engineering Notes 28, no.5. ACM:128-137.
Osborne, Sean M. 1993. Product development cycle time characterization through
modeling of process iteration. PhD Dissertation, Massachusetts Institute of
Technology.
OSGi Alliance. 2014. OSGi Alliance Specifications. Accessed January 13, 2014.
http://www.osgi.org/Specifications/HomePage.
Pimmler, Thomas Udo, and Steven D. Eppinger. 1994. Integration analysis of product
decompositions. Alfred P. Sloan School of Management, Massachusetts Institute of
Technology.
Podgurski, Andy, and Lori A. Clarke. 1990. "A formal model of program dependences and
its implications for software testing, debugging, and maintenance." Software
Engineering, IEEE Transactions on 16, no. 9 965-979.
Pressman, Roger S., and Darrel Darrel Ince. 1992. Software engineering: a practitioner's
approach. New York: McGraw-hill.
132
Qingquan, L., & Yang, H. W. (2012). Component-based software system reliability
allocation and assessment based on ANP and petri. International Conference on
Quality, Reliability, Risk, Maintenance, and Safety Engineering (ICQR2MSE).
Ramadan, M., I.M. Srour, M.A. Abdul-Malak, and A.A. Yassine. 2011. "A methodology
for quantifying dependency information among design activities in construction
projects." Proceedings of the Modern Methods and Advances in Structural Engineering
and Construction Research Publishing Services. Singapore.
Ratneshwer, Anil Tripathi. 2011. "Dependence Analysis of Component Based Software
through Assumptions." International Journal of Computer Science, Vol. 8 (4-1) 149-
159.
Robillard, Martin P. 2008. "Topology analysis of software dependencies." ACM
Transactions on Software Engineering and Methodology (TOSEM) 17, no. 4. ACM:
18.
Rogers, James L., Collin M. McCulley, and Christina L. Bloebaum. 1996. Integrating a
genetic algorithm into a knowledge-based system for ordering complex design
processes. Springer Netherlands.
Romesburg, Charles. 2004. Cluster analysis for researchers. Lifetime Learning
Publications. Accessed 02 17, 2014. Lulu. com.
Rushton, G. J., and A. Zakarian. 2000. "Modular vehicle architectures: A systems
approach." 10th Annu. Int. Symp. of INCOSE. INCOSE: 29-35.
Ryser, Johannes, and Martin Glinz. 2000. "Using dependency charts to improve scenario-
based testing." 17th International Conference on Testing Computer Software.
Sanchez, Ron, and Joseph T. Mahoney. 1997. "Modularity, flexibility, and knowledge
management in product and organization design." IEEE Eng Manage Rev 25, no. 4 50-
61.
Sangal, Neeraj, Ev Jordan, Vineet Sinha, and Daniel. Jackson. 2005. "Using dependency
models to manage complex software architecture." ACM Sigplan Notices 40, no. 10.
ACM. 167-176.
Sattar, Abdul, and Haibo Zang. 2014. "Component based Software Development using
Reusability Measurement." Software Engineering and Technology 6.6 174-175.
Schach, Stephen R. 2002. Object-oriented and classical software engineering. New York:
McGraw-Hill.
Scott, John, and Peter J. Carrington. 2011. The SAGE handbook of social network analysis.
SAGE Publications.
Sequeira, Michele Wanda. 1991. Use of the design structure matrix in the improvement of
an automobile development process. PhD Thesis, Massachusetts Institute of
Technology.
Sharma, Arun, P. S. Grover, and Rajesh Kumar. 2009. "Dependency analysis for
component-based software systems." ACM SIGSOFT Software Engineering Notes 34,
no.4 1-6.
133
Sharma, Arun, Rajesh Kumar, and P.S. Grover. 2008. "Empirical Evaluation and
Validation of Interface Complexity Metrics For Software Components." International
Journal of Software Engineering and Knowledge Engineering 18, no.7 919-931.
Sharman, David M., and Ali A. Yassine. 2007. "Architectural valuation using the design
structure matrix and real options theory." Concurrent Engineering 15, no.2: 157-173.
Shaw, Mary, and David Garlan. 1996. Software architecture: perspectives on an emerging
discipline. Prentice Hall.
Smith, Robert P., and Steven D. Eppinger. 1997. "Identifying controlling features of
engineering design iteration." Management Science 43, no.3 276-293.
Sosa, Manuel E. 2008. "A structured approach to predicting and managing technical
interactions in software development." Research in Engineering Design 19, no.1 47-
70.
Srour, Issam M., Mohamed-Asem U. Abdul-Malak, Ali A. Yassine, and Maysaa Ramadan.
2013. "A methodology for scheduling overlapped design activities based on
dependency information." Automation in Construction 29: 1-11.
Stafford, Judith A., Alexander L. Wolf, and Mauro Caporuscio. 2003. "The application of
dependence analysis to software architecture descriptions." Formal methods for
software architectures. Springer Berlin Heidelberg: 52-62.
Stafford, Judith A., and Alexander L. Wolf. 2001. "Architecture-level dependence analysis
for software systems." International Journal of Software Engineering and Knowledge
Engineering 11(4): 431-451.
Stevens, Wayne P, Glenford J. Myers, and Larry L. Constantine. 1974. "Structured design."
IBM Systems Journal 13, no. 2 115-139.
Steward, Donald V. 1965. "Partitioning and tearing systems of equations." Journal of the
Society for Industrial & Applied Mathematics, Series B: Numerical Analysis 2, no. 2
345-365.
Steward, Donald V. 1981. "The design structure system: a method for managing the design
of complex systems." IEEE Transactions on Engineering Management 3: 71-74.
Suh, Eun Suk, Michael R. Furst, Kenneth J. Mihalyov, and Olivier de Weck. 2010.
"Technology infusion for complex systems: A framework and case study." Systems
Engineering 13, no. 2 186-203.
Sundaram, Senthil Karthikeyan, Jane H. Hayes, Alex Dekhtyar, and Ashlee E. Holbrook.
2010. "Assessing traceability of software engineering artifacts." Requirements
engineering 15, no. 3 313-335.
Szyperski, Clemens. 2002. Component software: beyond object-oriented programming.
Pearson Education.
Tallam, Sriraman, and Rajiv Gupta. 2007. "Unified control flow and data dependence
traces." ACM Transactions on Architecture and Code Optimization (TACO) 4, no. 3
19.
134
Tang, Dunbing, Renmiao Zhu, Jicheng Tang, Ronghua Xu, and Rui He. 2010. "Product
design knowledge management based on design structure matrix." Advanced
Engineering Informatics 24, no. 2 159-166.
Terwiesch, Christian, Christoph H. Loch, and Arnoud De De Meyer. 2002. "Exchanging
preliminary information in concurrent engineering: Alternative coordination
strategies." Organization Science 13, no. 4 402-419.
Tran, John B., Michael W. Godfrey, Eric HS Lee, and Richard C. Holt. 2000.
"Architectural repair of open source software." 8th International Workshop on
Program Comprehensio 2000. IEEE: 48-59.
Ulrich, Karl T., Steven D. Eppinger, and Anita Goyal. 2011. Product design and
development. Vol. 2. New York: McGraw-Hill/Irwin.
Vasilache, Simona, and Jiro Tanaka. 2005. "Bridging the gap between analysis and design
using dependency diagrams." Third ACIS International Conference on Software
Engineering Research, Management and Applications. IEEE: 407-414.
Vestal, Steve. 1993. A cursory overview and comparison of four architecture description
languages. Technical Report, Honeywell Technology Center.
Vieira, Marlon, and Debra Richardson. 2002. "Analyzing dependencies in large
component-based systems." 17th IEEE International Conference on Automated
Software Engineering, IEEE: 241-244.
Wang, Hongzhou, and Hoang Pham. 1997. "Survey of reliability and availability
evaluation of complex networks using Monte Carlo techniques." Microelectronics and
Reliability: 187-209.
Wasserman, Stanley. 1994. Social network analysis: Methods and applications. Vol. 8. .
Cambridge: Cambridge university press.
Weidenhaupt, Klaus, Klaus Pohl, Matthias Jarke, and Peter Haumer. 1998. "Scenarios in
system development: current practice." Software, IEEE 15, no. 2 34-45.
Xiao, Yang, and S. Urban. 2008. "Using data dependencies to support the recovery of
concurrent processes in a service composition environment." Cooperative Information
Systems Conference (COOPIS). Monterrey, Mexico: 139-156.
Xing, Zhenchang, and Eleni Stroulia. 2006. "Understanding the evolution and co-evolution
of classes in object-oriented systems." International Journal of Software Engineering
and Knowledge Engineering 16(1): 23-51.
Yacoub, Sherif M., and Hany H. Ammar. 2002. "A methodology for architecture-level
reliability risk analysis." Software Engineering. IEEE Transactions on 28(6): 529-547.
Yacoub, Sherif M., Bojan Cukic, and Hany H. Ammar. 1999. "Scenario-based reliability
analysis of component-based software." 10th International Symposium on Software
Reliability Engineering. IEEE: 22-31.
Yacoub, Sherif, Bojan Cukic, and Hany H. Ammar. 2004. "A scenario-based reliability
analysis approach for component-based software." IEEE Transactions on Reliability,
53(4): 465-480.
135
Yoon, Llchul, Alan Sussman, Atif Memon, and Adam Porter. 2013. "Testing component
compatibility in evolving configurations." Information and Software Technology,
Volume 55, Issue 2 445-458.
Yu, Liguo, Alok Mishra, and Srini Ramaswamy. 2010. "Component co-evolution and
component dependency: speculations and verifications." Software, IET 4(4): 252-267.
Zhang, He, Juan Li, Liming Zhu, Ross Jeffery, Yan Liu, Qing Wang, and Mingshu Li.
2014. "Investigating dependencies in software requirements for change propagation
analysis." Information and Software Technology 56, no. 1. 40-53.
Zhang, Tian, Raghu Ramakrishnan, and Miron Livny. 1996. "BIRCH: an efficient data
clustering method for very large databases." ACM SIGMOD Record 25(2). ACM: 103-
114.
Zhang, Weilei, and Barbara G. Ryder. 2007. "Discovering accurate interclass test
dependences." 7th ACM SIGPLAN-SIGSOFT workshop on Program analysis for
software tools and engineering. ACM: 55-62.
Zhao, Jianjun. 2002. "Change impact analysis for aspect-oriented software evolution."
International Workshop on Principles of Software Evolution. ACM: 108-112.
Zhao, Jianjun. 2001. "Using dependence analysis to support software architecture
understanding." New Technologies on Computer Software: 135-142.
Zhao, Zhen Yu, Qian Lei Lv, Jian Zuo, and George Zillante. 2009. "Prediction system for
change management in construction project." Journal of Construction Engineering and
Management 136(6): 659-669.
Zimmermann, Thomas, and Nachiappan Nagappan. 2008. "Predicting defects using
network analysis on dependency graphs." 30th International Conference on Software
Engineering. ACM: 531-540.
136
APPENDIX A. FLOWCHARTS FOR THE MDD AND MARKOV CHAIN
METHODS
Figure A-1. Flowchart diagram for the MDD method detailing the interaction
between the user and the software (Kafle, Sarkani, and Mazzuchi, 2015)
Input
P
Input
A
Identify the number of
components in System
Architecture
Assumption: Possible
number of steps = total
number of components
Calculate Power
Matrices of P for each
step
Step <= total
number of
components
Yes
For each Power Matrix
Calculate the data flow
frequency
Calculate Explicit
Dependency Matrix
Calculate Implicit
Dependency Matrix
Calculate Total Link
Dependency Strength
Matrix
Calculate Priorities for
each link based on
Dependency Strength
No
Develop
System
Adjacency
Matrix (P)
Develop
System
Affiliation
Matrix (A)
User Software (MATLAB)
137
Figure A-2. Flowchart diagram for Markov chain method detailing the interaction
between the user and the software (Kafle, Sarkani, and Mazzuchi, 2015)
Input
Initial State
Matrix
Calculate
Transient
States
Calculate Transition
Probabilities for the
data being in a
component
Calculate Dependency
Strength based on
Transition Probabilities
Calculate Priorities for
each link based on
Dependency Strength
Assign Initial
Link
Probabilities
Develop
Initial State
Matrix
User Software (EXCEL)
Calculate
Absorbing
States
Calculate Probability of
data being in an
Absorbing State
Calculate Probability of
data being in an
Transient State
Calculate Transition
Probabilities for the
data being in a Link as
it orginates at a
component
138
APPENDIX B. MATLAB CODE USED FOR MDD METHOD
% Subash Kafle
% Multi Dimensional Dependency Analysis
%Case Study III
clear All
clc
tic
% P is matrix that shows what component provides to or receives from other
% component (Component vs Component)
P=[
0 1 1 0 0 0 0 0 0 0
0 0 0 1 0 0 0 1 0 0
0 0 0 0 0 0 1 1 0 0
0 0 0 0 1 1 0 0 0 0
0 0 0 0 0 1 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 1 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
]
% A is affiliation matrix (dependency vs Component)
A=[
0 1 0 0 0 0 0 0 0 0
0 0 1 0 0 0 0 0 0 0
0 0 0 1 1 0 0 0 0 0
0 0 0 1 1 0 0 0 0 0
0 0 0 1 0 1 0 0 0 0
0 0 0 0 0 0 0 1 0 1
0 0 0 0 0 0 0 1 1 0
0 0 0 0 0 0 0 1 1 0
0 0 0 0 0 0 1 0 0 0
0 0 0 0 0 0 1 0 0 0
0 0 0 0 1 1 0 0 0 0
0 0 0 0 1 1 0 0 0 0
0 0 0 0 0 1 0 0 0 0
0 0 0 0 0 1 0 0 0 0
0 0 0 0 0 1 0 0 0 0
0 0 0 0 0 0 0 0 0 1
0 0 0 0 0 0 0 0 1 0
0 0 0 0 0 0 0 0 1 0
]
139
%% Initializing
K=[]; % K is power matrix of P
x=size(P,1); % x measures size of square matrix P
for j=1:x
K(:,:,j)=mpower(P,j); % This calculates power matrices of P
end
M=K; % This stores l power of P into M matrix
KK=eye(size(P))*0;MM=eye(size(P))*0;NN=eye(size(P))*0;TT=eye(size(P))*0; %
Initializing matrices
TT=mpower(P,1); % first power of P
MDDcc=A*transpose(A); % MDDcc is Dependency due to common components
(Explicit Dependencies)
MDDarch=eye(size(MDDcc))*0; % MDDarch= dependency due to neighbouring
elements (Implicit Dependencies)
MDDarchfinal=eye(size(MDDcc))*0;
HH=eye(size(MDDcc))*0; % Intializing
MMsum=eye(size(P))*0;
%% Nested Loop to calculate MDDarch (Implicit Dependencies)
for d=2:x
d;
MM=eye(size(P))*0;
NN=eye(size(P))*0;
LL=M(:,:,d-1); % mpower of P with power of d-1
KK=M(:,:,d); % mpower of P with power of d
TT; % mpower of P with power of 1
for m=1:size(KK)
for n=1:size(KK)
if KK(m,n)==1
if d<3
for i=1:x
if LL(m,i)==1 && TT(i,n)==1
MM(m,i)=MM(m,i)+1;
MM(i,n)=MM(i,n)+1;
MM(m,n)=KK(m,n);
else
MM(m,n)=KK(m,n);
end
end
140
elseif d >= 3
KK;
d;
m;
n;
p=m;q=n;
for j=d-1:-1:1
j;
LL=M(:,:,j);
% p=m
% q=n
for i=1:x
if LL(p,i)==1 && TT(i,q)==1
if j>1
MM(i,q);
MM(i,q)=MM(i,q)+1;
MM(i,q);
q=i;
end
MM;
if j==1
MM(p,i)=MM(p,i)+1;
MM(i,q) ;
MM(i,q)=MM(i,q)+1;
MM(i,q);
end
end
end
MM;
end
end
MM;
end
end
end
d;
if d>2
MM=MM+KK;
end
141
KK;
MM;
MMsum=MMsum+MM;
MDDarch=(1/1)*(A*MM*transpose(A));
MDDarchfinal=MDDarchfinal+MDDarch;
MDDarch;
end
MDDarchfinal;
I=MDDarchfinal %Implicit Dependencies
MDDcc;
E=MDDcc %Explicit Dependencies
MDDtotal=MDDarchfinal+MDDcc;
LDM=MDDtotal
142
APPENDIX C. EXCEL CALCULATION USED FOR MARKOV CHAIN
METHOD
Initial State Matrix
C1 C2 C3 C4 C5 C6
C1 0 1 0 0 0 0
C2 0 1/3 1/3 1/3 0 0
C3 0 0 1/3 0 1/3 1/3
C4 0 0 0 1 0 0
C5 0 1/3 0 1/3 1/3 0
C6 0 0 0 0 0 1
Initial probability of data being in a component
C1 C2 C3 C5 C4 C6
C1 0 1 0 0 0 0
C2 0 1/3 1/3 0 1/3 0
C3 0 0 1/3 1/3 0 1/3
C5 0 1/3 0 1/3 1/3 0
C4 0 0 0 0 1 0
C6 0 0 0 0 0 1
Identity Matrix (K) t by t matrix (Q)
C1 C2 C3 C5 C1 C2 C3 C5
C1 1 0 0 0 C1 0 1 0 0
C2 0 1 0 0 C2 0 1/3 1/3 0
C3 0 0 1 0 C3 0 0 1/3 1/3
C5 0 0 0 1 C5 0 1/3 0 1/3
K-Q N=Inverse(K-Q)
C1 C2 C3 C5 C1 C2 C3 C5
C1 1.0000 -1.0000 0.0000 0.0000 C1 1.0000 1.7143 0.8571 0.4286
C2 0.0000 0.6667 -0.3333 0.0000 C2 0.0000 1.7143 0.8571 0.4286
C3 0.0000 0.0000 0.6667 -0.3333 C3 0.0000 0.4286 1.7143 0.8571
C5 0.0000 -0.3333 0.0000 0.6667 C5 0.0000 0.8571 0.4286 1.7143
Probability that data will be absorbed in absorbing states (B)=N*R
R is nonzero t by R matrix N*R
C4 C6 C4 C6
C1 0 0 C1 0.7143 0.2857
C2 1/3 0 C2 0.7143 0.2857
C3 0 1/3 C3 0.4286 0.5714
C5 1/3 0 C5 0.8571 0.1429
143
Expected number of times data are in transient states(N)
C1 C2 C3 C5
C1 1 1.7143 0.8571 0.4286
C2 0 1.7143 0.8571 0.4286
C3 0 0.4286 1.7143 0.8571
C5 0 0.8571 0.4286 1.7143
Probabilities for data being in transient components Probability that data will be absorbed in absorbing states
C1 C2 C3 C5 C4 C6
C1 0.25 0.428571 0.214286 0.107143 C1 0.7143 0.2857
C2 0 0.571429 0.285714 0.142857 C2 0.7143 0.2857
C3 0 0.142857 0.571429 0.285714 C3 0.4286 0.5714
C5 0 0.285714 0.142857 0.571429 C5 0.8571 0.1429
Total Probabilities for data being in a component
C1 C2 C3 C5 C4 C6
C1 0.2500 0.4286 0.2143 0.1071 0.7143 0.2857
C2 0.0000 0.5714 0.2857 0.1429 0.7143 0.2857
C3 0.0000 0.1429 0.5714 0.2857 0.4286 0.5714
C5 0.0000 0.2857 0.1429 0.5714 0.8571 0.1429
C4 0 0 0 0 0 0
C6 0 0 0 0 0 0
Normalized Probabilities for data being in a component (P)
C1 C2 C3 C5 C4 C6
C1 0.1250 0.2143 0.1071 0.0536 0.3571 0.1429
C2 0.0000 0.2857 0.1429 0.0714 0.3571 0.1429
C3 0.0000 0.0714 0.2857 0.1429 0.2143 0.2857
C5 0.0000 0.1429 0.0714 0.2857 0.4286 0.0714
C4 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
C6 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000