CONVENTIONAL TO COMPONENT-BASED SOFTWARE: A CRITICAL SURVEY ON INTERACTION AND INTEGRATION COMPLEXITIES

: There are various standard paradigms of software development including conventional, modular, object-oriented and component-based software engineering (CBSE). Interaction and integration complexities of various piece of code play a vital role in the overall behavior of software. As the code count increases the interaction level of software also increases as per the requirements of the software. In this paper we perform a critical literature survey on the works of eminent researchers and practitioners. In this work we analyze three paradigms of development, namely, conventional software, object-oriented software and component-based software (CBS). In this survey, we have considered three parameters of comparison: measures and metrics used, key findings, and factors affecting the interaction and integration behavior of software.


I. INTRODUCTION
In general, complexity is termed as the assessment of hardware and software resources needed by software. In software development, complexity is treated as an indirect measurement unlike the direct measurements like lines-ofcode or cost-estimation [1]. Internal as well external interactions contribute a major role in software complexity. In the context of software development, interaction behaviour of various parts of program is used to measure the complexity. These parts may be single line code, a group of line of codes (functions), a group of functions (modules) or ultimately components. As the size of parts of s software increases, the count of interactions will also increase, as well as the complexity.
Software Engineering principles are applicable on the applications developed through either development paradigm. Component-based software development (CBSD) emphasizes "development with reuse" as well as "development for reuse". Development with reuse focuses on the identification, selection and composition of reusable components. The property of reusability is not applied only to develop the whole system but also to develop the individual components. The development for reuse is concerned with the development of such components that may be used and then reused in many applications, in similar and heterogeneous contexts.
After discussing the introduction of work in section 1, we have summarized the interaction and integration issues in section 2. In section 3, we have performed the survey on the literature available. Finally section 4 concludes this work.

II. INTEGRATION AND INTERACTION ISSUES
Software applications are composed of dependent or independently deployable components. Assembling of these components has a common intension to contribute their functionalities to the system. Technically this assembling is referred to as integration of and interaction among components. We have sufficient number of measures and metrics to assess the complexity of stand alone programs as well as small-sized conventional software, suggested and practiced by numerous practitioners [2,3,4,5,6,7,8]. In literature, complexity of programs and software is treated as a "multidimensional construct" [3,9].

III. LITERATURE SURVEY
Thomas J. McCabe [10] developed a method to assess the Cyclomatic complexity of a program. He used control-flow graph of code to compute the complexity. McCabe used graph theoretic notations to draw the control-flow graph where a graph denoted as 'G' having 'n' number of nodes, 'e' number of connecting edges and 'p' number of components. Cyclomatic complexity V(G) calculated as, V(G) = e -n + 2p, where 2 is the "result of adding an extra edge from the exit node to the entry node of each component module graph" [2]. In control-flow graph, a sequential block of code or a single statement is represented as a node, and control flows among these nodes are represented as edges. Cyclomatic complexity metric is easy to compute and maintenance, gives relative complexity of various designs.
Finally, Halstead's [5] identified a complete set of metrics to measure the complexity of a program considering various factors. These metrics include the program vocabulary, length, volume, potential volume, and program level. Halstead proposed methods to compute the total time and effort to develop the software. These metrics are based on the lines of codes of the program. He defined program vocabulary as the count of distinct operators and distinct operands used in the program. The count of total operators and operands used in a program is proposed as the Program length. The Program volume has been defined as the storage volume required representing the Program, and the representation of program in the shortest way without repeating operators and operands is known as potential volume. Halstead has also defined the relationship between these factors and metrics of programs.
Alan Albrecht [6] proposed Function-point analysis technique to measure the size of a system in terms of functionalities provided by the system. FPA categorizes all the functionalities provided by the software in five specific functional units: External inputs provided to the software, External outputs provided by the software, External inquiries of the system under consideration, Internal logical files presents data and content residing in the system, and External interface files are the data and contents residing with other systems and can be called to system under consideration. Three complexity weights High, Low and Medium are associated with these functional units using a set of predefined values. In function-point analysis, 14 complexity factors have been defined, which have a rating from 0 to 5. On the basis of these factors, Alan calculated the values of unadjusted function-point, complexity adjustment factors, and finally the value of function points [2].
Henry and Kafura [11] proposed a set of complexity computation method for software modules. Author's suggested a "Software Structure Metrics Based on Information Flow that measures complexity as a function of fan-in and fan-out" [12]. Authors proposed the complexity as "the procedure length multiplied by the square of fan-in multiplied by fan-out." This method is used to calculate the count of "local information flows" coming to (fan-in) and going from (fan-out) the module. Henry and Kafura defined a length of the module as the procedure length which calculated with the help of LOC or McCabe's complexity metric. This metric can be computed comparatively early stage of the development.
Kenneth Morris [13] proposed some object-oriented metrics to assess complexity and productivity metrics. Author's identified some complexity factors like Maintainability, Reusability, Extensibility, Testability, Comprehensibility, Reliability and Authorability, that they called "productivity impact variables". Morris proposed a complete set of nine eligible metrics for Methods, Class, Inheritance, Coupling and Cohesion.
Boehm [7] developed the 'object-point' metric through level of complexity of the amount of screenshots, reports and components. The level of complexities is categorized as simple, medium or difficult.
Chidamber and Kemerer's [14] proposed a metric suite for object-oriented software called as CK Metrics-suite. This metric suite is one of the most detailed and popular research works for object-oriented applications. Authors defined metric suite for complexity, coupling cohesion, depth of inheritance, and response set. These metric set are used to asses the complexity of an individual class as well as the complexity of the entire software system. In their metrics, Chidamber and Kemerer used Cyclomatic method for the complexity computation of individual classes.
Abreu and Rogerio Carapuca [15,16,17] proposed a metric set named 'Metrics for Object-Oriented Design'. In this metric suite, two fundamental properties of objectoriented programming are used, attributes and methods. Authors proposed metrics for the basic structural system of object-oriented idea as encapsulation, inheritance, polymorphism, and message passing. This suit consists of metrics for methods and attributes as assessment method for encapsulation.
Cho et al. [18] developed some measure for the quality and complexity of components for CBSE. They used mathematical equations and expressions in their metrics. In their work, authors identified three categories of complexity, quality of component, customizability and reusability. They used size, costs, efforts, and reuse level as the complexity factors.
Narasimhan et al. [19] suggested couple of metrics to assess the complexity of Component-Based Software. The packing density metric maps the count of integrated components, and the interaction density metric is used to analyse the interactions among components. They identified some constituents of the component in their work; these constituents include line of code, operations, classes, and modules. Authors also suggested a set of criticality criteria for component integration and interaction.
Vitharana et al. [20] developed a method for fabrication of components. Authors suggested some managerial factors like cost-efficiency; assembling easiness, customization, reusability, and maintainability. These are used to estimate technical metrics as coupling-cohesion, count, volume and complexity of components. They developed 'Business Strategy-based Component Design' model.
Rashmi Jain et al. [21] assesses the association and mappings of cause-and-effect among the requirements of the system, structural design of the system and the complexity of the procedure of the systems integration. They argued the requirement of fast integration of components so that the complexity impact of integration on architectural design of components can be controlled. Authors identified 5 major factors to analyse the integration complexity of software system. Further these factors are divided into 18 sub-factors including commonality in hardware and software subsystems, percentage of familiar technology, physical modularity, level of reliability, interface openness, orthogonality, testability and so on.
Trevor Parsons et al. [22] proposed some specific dynamic methods for attaining and utilising interactions among the components in component-based development. They also proposed component-level interactions that achieve and record communications between components at runtime and at design time. For their work, authors used Java components.
Lalit and Rajinder [23] proposed a set of integration and interaction complexity metrics to analyse the complexity of Component-Based Software. They argue that complexity of interaction have two implicit features, first within the component, and second interaction from the other components. Their complexity metrics include percentage of component interactions, interaction percentage metrics for component integration, actual interactions, and total interactions performed, complete interactions in a Component-Based Software.
Some complexity assessment techniques for CBSE are on the basis of complexity properties including communication among components, pairing, structure, and interface. The interaction and integration complexity measures available in the literature are explored considering the development paradigms like: Convention Software and Programs, Objet-Oriented Software, and Component-Based Software and summarized in Table 1.

IV. CONCLUSION
After 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 for CBSE applications these methods are not inadequate. In the CBSE, components have connections and communications with each other to exchange services and functionalities. Interaction edges are used to denote the connections among components. So there is an edge for each requesting communication and similarly an edge for each responding communication. But practitioners and researchers have not included both edges in their complexity computations. They have used single edge theory in their graph representations and in all their assessments, which is not true for CBSE.