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.


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

iii

© Copyright 2015 by Subash Kafle

All rights reserved

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


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.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.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


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


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


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


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


and link priorities for the case study II system ....................................................... 89


absorbing states as they originate from transient states ......................................... 103


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


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


Input/Output dependency “a component requires/provides information from/to


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

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


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


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


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

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)


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


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


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

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.


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


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







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.


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

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 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


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 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 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


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

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.


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


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 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 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







priorities for case study III system

Link Transition

Probabilities

Fraction of Total


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.


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


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

prioritization of component-to-component links for testing

Documents