INTERACTION AND INTEGRATION COMPLEXITY

METRICS FOR COMPONENT-BASED SOFTWARE

Lecture 8
Tiwari,Uk and S. Kumar.Component based software engineering methods and
metrics (chapter 5)
INTRODUCTION
Integration and interactions among the components follow a well-defined architectural
design and should occur according to the user’s requirement specification. Components
interact with each other for two basic reasons:
1. To access the services and functionalities of other components, and
2. To provide services and their own functionalities to other components.
 These interactions among various components generate complexity in component-based
software.
 In general, the term complexity is defined as the assessment and calculation (sometimes
prediction) of resources required to resolve a problem.
 In the domain of software development, complexity is an attribute which cannot be
measured directly, that is, complexity is an indirect measure.
 In general terms, complexity is the assessment of hardware and software resources
needed by software. In software development, complexity is treated as an indirect
measurement, unlike direct measurements like lines of code or cost estimation. Internal as
well as external interactions play a major role in software complexity.
 In the context of software development, interaction behavior of various parts
of a program is used to measure complexity. These parts may be single-line
code, a group of lines of code (functions), a group of functions (modules) or
ultimately components.
 As the size of parts of the software increases, the total number of interactions
will also increase, as well as the complexity.
 Software applications are composed of dependent or independently
deployable components. These components are assembled for the purpose of
contributing their functionalities to the system. Technically this assembly is
referred to as integration of and interaction among components. We have a
sufficient number of measures and metrics to assess the complexity of
standalone programs as well as small-sized conventional software, suggested
and practiced by numerous practitioners.
 Two complexity computation techniques are suggested:

1. In-out interaction complexity

2. Cyclomatic complexity for component-based software
IN-OUT INTERACTION COMPLEXITY
 Methods and metrics proposed so far in the literature are defined on the basis of
interactions among instructions, operations, procedures and functions of individual and
standalone programs and codes.
 These metrics are appropriate for small-sized codes. Some measures are also defined
for object-oriented software, but they are not adequate for component- based
applications. In component-based software engineering, components have connections
and communications with each other to exchange services and functionalities.
Interaction edges are to denote the connections among components .
 Metrics defined in this work consider the individual interactions of components as well as
inter-component interactions. These metrics are helpful for exploring the non-functional
attributes of components and component-based software.
 When components in the component-based software interact with each other, they
generate interaction complexities. These complexities are vital not only for designers
and testers but also for maintenance activities.
 As the interaction complexity increases, related factors like usability, reusability,
understandability and similar factors may be affected
IN-OUT INTERACTION COMPLEXITY
GRAPH

 Complexities generated due to in-out interactions are easy to compute and helpful for
designers and developers in terms of keeping track of the complexity level of components
and component-based software.
Notations
 Graph-theory notation is used throughout this chapter to denote all types of interactions
shared among various components.
 Components are shown as vertices, and interactions among components are denoted as
edges. Generally, components make interactions to share and communicate information,
data, control or similar resources.
 For in-out interaction metrics, edges are divided into two categories:

• Incoming interactions
• Outgoing interactions
i. Incoming interactions: Edges in the graph that are coming towards the
component are referred to as incoming interactions. These edges are drawn due
to:
• A request sent by any other component to the receiving component, or
• A response from some other component to the request-sending
component
 Figure 5.1 shows incoming interactions and outgoing interactions. The edge
coming from component C2 in the direction of component C1 is termed
the incoming interaction for component C1 and denoted as Iin.
ii. Outgoing interactions:
The edges in the graph that are going out from the component are referred to as the
outgoing interactions. These edges are drawn due to either:
• A request sent by the component to some other component, or
• A response from the component to the request-sending component.
 In Figure 5.1, the edge going from component C1 in the direction of component C2 is
termed the outgoing interaction for component C1 and denoted as Iout.
 When we assess in-out interaction complexity, all types of edges are considered, both
incoming and outgoing interactions.
 From Figure 5.1 we can observe that component C1 contains one outgoing interaction (I )
out
as a requesting-edge from C1 to C2 and one incoming interaction (Iin) as a response-edge
coming from C2 to C1.
 As components C1 and C2 are both inter-dependent for requests and responses, evaluation
of the in-out interaction complexity must also consider complexities produced by both
components C1 and C2.
Total Interactions of a Component
 For a particular component “C,” total interactions can be defined as the
summation of the total number of incoming interactions (Iin) and total number of
outgoing interactions (Iout):

where Iin is the incoming interaction and Iout is the outgoing interaction of
component “C.”
Total Interactions of Component-Based Software
 Component-based software consists of a number of components interacting with
each other through various incoming and outgoing interactions. the total
interactions of component-based software is defined as the summation of the
total number of incoming interactions (Iin) and total number of outgoing
interactions (Iout) of all the contributing components:
Interaction Ratio of a Component
 The interaction-ratio metric represents the amount of dependency of
individual components that are making interactions in the software. The
interaction ratio of a component can be defined as the ratio between the
total outgoing interactions (Iout) and the total incoming interactions (Iin). It
is defined as:
We can verify that
• If IRCi = 1 when Iin = Iout, the total number of incoming interactions is equal
to the total number of outgoing interactions. We can conclude that there is
equivalent dependency among contributing components.
• If IRCi < 1 it means that Iout < Iin, that is, the total number of incoming
interactions is greater than the total number of outgoing interactions. We
can infer the result that there is high dependency on the responding
component.
• If IRCi > 1 it means Iout > Iin, implying that there is high dependency on the
responding component.
Interaction Ratio of Component-Based Software
 The interaction-ratio metric of component-based software (IRCBS) denotes
the amount of inter-dependency among contributing components that are
making interactions. The interaction ratio of component-based software can
be defined as the ratio between the total number of outgoing interactions
(Iout) and the total number of incoming interactions (Iin) made by all the
contributing components of the software. It is given as:

 where n is the total of all contributing components in the component-based

software
Average Interactions Among Components
 The average-interaction metric represents the amount of connectivity among
participating components. The average interaction among contributing components is
defined as the ratio of the summation of incoming interactions (Iin) and outgoing
interactions (Iout) to the total contributing components in the component-based software.
The total of contributing components is denoted Cn. Average interactions is defined as:

We can verify that,

• If AICn< ½, it implies that at least half of the interacting components are disjoint,
• If AICn = 1, it denotes that there is at least one interaction among components, and
• If AICn > 1, then it is concluded that components are highly coupled.
Interaction Percentage of a Component
 The interaction-percentage metric is used to represent the degree of underflow or
overflow of interactions amongst contributing components. The interaction percentage of
a component IPCnis the ratio of the summation of in interactions (Iin) and out interactions
(Iout) made by the particular component, to the total interactions made by all the
contributing components. The interaction percentage of a component is defined as:

We can verify that

• If IPCn < 1, it implies an underflow situation, that is, more interactions are possible among
the components,
• If IPCn = 1, it shows a balanced situation, and
• If IPCn > 1>, it shows an overflow situation, that is, components are sharing heavy
interaction, which will increase the complexity.
 CASE 1: IN-OUT INTERACTION COMPLEXITY GRAPH WITH TWO COMPONENTS
 This is the simplest case, when the in-out interaction graph consists of only two
components, C1 and C2, as shown in Figure 5.1.
 Total Interactions of a Component Ci (TICi): Applying the values of Table 5.1 in Equation
(5.1), we get total interactions of component C1 and component C2 as,

 Total Interactions of Component-Based Software (TICBS): This software consists of two components
only, C1 and C2. Applying the values given in Table 5.1 in Equation (5.2), we get,
 Interaction Ratio of a Component “Ci” (IRCi): Applying the values of Table 5.1 in Equation
(5.3), we get the interactions ratio of component C1 and component C2. For component
C1:

 For component C2, there are no incoming-outgoing interactions. Hence the interaction ratio is not
applicable to component C2.
 Interaction Ratio of Component-Based Software (IRCBS): Case 1 consists of two components, C1 and
C2. Applying the values given in Table 5.1 in Equation (5.4), we get,
 Average Interactions Among Components (AI𝐶𝑛)

In case 1, the number of components is two, hence to find the average interactions, we apply
Equation (5.5) as,

 Interaction Percentage of Component C (IPCn):

We apply the values defined in Table 5.1 to Equation (5.6) to compute the interaction percentage.
 Interaction Percentage of Component C1:

 Interaction Percentage of Component C2:

Note: Check case 2 study on book page # 133 to 136

CYCLOMATIC COMPLEXITY FOR COMPONENT-BASED SOFTWARE

 A cyclomatic complexity metric is easy to compute and maintain, as well

as giving relative complexity of various designs. This method is applicable
to standalone programs and to hierarchical nests of subprograms.
 McCabe used graph-theoretic notations to draw a control-flow graph where
a graph denoted G has n number of nodes, e number of connecting edges
and p number of components.
The cyclomatic complexity, V(G), is calculated as
 where 2 is the “result of adding an extra edge from the exit node to the entry node of
each component module graph” . In a structured program where we have predicate
nodes, complexity is defined as

 where predicate nodes are the nodes having two and only two outgoing edges. In his
implementations, McCabe defined a program cyclomatic complexity value of less than
10 as reasonable. If a program has a hierarchical structure, that is, one subprogram is
calling another, the cyclomatic complexity is the summation of individual complexities
of these two subprograms and is given as
where P1 and P2 are two subprograms and P1 is calling P2.
 Complexity depends not on the size, but on the coding structure of the
program. If a program has only one statement then it has complexity 1.
That is, V(G) ≥ 1. Cyclomatic complexity V(G) actually defines the number
of independent logics/paths in the program.
Flow Graph for Component Integration
 Component-based software applications are composed of independently
deployable components. The assembly of these components has a
common intention to contribute their functionalities to the system.
Technically this assembly is referred to as integration of and interaction
among components. Interaction edges are used to denote the
connections among components, with an edge for each requesting
communication and similarly an edge for each responding
communication. A requesting component sends a “request edge” and the
responding component sends a “response edge.” This metric is based on
the concept of double edges to show the interaction among requesting
and responding components.
 In a flow graph, vertices denote components, and edges between
components are used to denote integrations and interactions among
them. The internal structures of components are also shown in the
control-flow graph. Figure 5.3 shows a flow graph where two components
are integrated.
Cyclomatic Complexity Metric
 Component-based software is complex and includes a large number of independent and
context-free components. Their behavior and nature are different from those of small-
scale applications and software. We cannot simply apply a cyclomatic complexity formula
that was developed for programs, to component-based software. This section sets out two
methods of computing the cyclomatic complexity of component-based software.
Method 1:
 For such multifaceted and multi-component software, cyclomatic complexity is defined
as:

 |E| denotes number of edges, |V| is used to denote total number of vertices,
 |P| is the total of contributing components and
 Constant 2 is used to indicate that “the node V contributes to the complexity if its out-
degree is 2.”
Method 2:
 Another metric for computing the cyclomatic complexity of component-based software is
defined in Equation (5.8) as:

 where
 (IC)i = (IC1, IC2, IC3, …, ICn) denoting cyclomatic complexities of all the contributing
components,
 (CR)j = (CR1, CR2, CR3, …, CRm) denoting the total closed regions found in the
graph, and OR denotes the open region that is always 1.
 SCENARIO 1: INTERACTION SCENARIO BETWEEN TWO COMPONENTS

 Figure 5.3 shows an interaction scenario between two components. The components’ internal
structures are also shown.

Method 1:
From Figure 5.3, it is noted that
Method 2:
From Figure 5.3, it is noted that,

Note: Check scenario 2 on book page # 139to 146