{'fraction_non_alphanumeric': 0.025260170293282876, 'fraction_numerical': 0.0062440870387890255, 'mean_word_length': 4.714054054054054, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 1, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Component Interaction Graph: A new approach to test component composition

The key factor of component based software development is component composition technology. A Component interaction graph is used to describe the interrelation of components. Drawing a complete component interaction graph (CIG) provides an objective basis and technical means for making the testing outline. Although many researches have focused on this subject, the quality of system that is composed of components has not been guaranteed. In this paper, a CIG is constructed from a state chart diagram and new test cases are generated to test the component composition.


INTRODUCTION
Component-based software engineering (CBSE) is increasingly being adopted for software development. This approach, which uses reusable components as building blocks for constructing software, can facilitate fast-paced delivery of scalable, evolvable software systems. It also offers the promise of putting the improvement of software quality and productivity into common practice [1]. A component-based software system often consists of a set of self-contained and loosely coupled components allowing plug-and-play. The components may have been written in different programming languages, executed in various operational platforms, and distributed across vast geographic distances; some components may be developed in-house, while others may be third party or commercial off-the-shelf components whose source code may not be available to developers. These component-based software characteristics facilitate development of complex systems by allowing integration of reusable components from different vendors and by providing flexibility for dynamic software evolution.
The paper is organized as follows: Section 2 describes about the basic concept and introduces the concept of CIG. This section also describe about a state chart diagram. Generation of CIG from a state chart diagram is presented in section 3. We end this paper with our conclusion and future research in section 4.

BASIC CONCEPTS
Component interfaces define all content of interaction with the external and it is the only way that a component communicates with the outside. Component composition can be defined by interface to express the ideal condition, thus we regard the component as a union of interfaces.
There are two kinds of interface: service providing and service required while the services are provided by an environment or other components. In our approach, all components are considered plug-compatible in the sense that a service required interface can be connected to a service providing interface. For simplification, we take the environment as an abstract component [2]. The providing and required services of a component C is denoted by C.P and C.R respectively and C.P∩ C.R=Ф .
There is an interface mapping from required services to providing services of a component that is f : C.R -> C.P. Test case could be produced after the analysis of function f according to the specification of component interfaces [2]. The required services of C1 ℗ C2 are the union of C1.R1 and C2.R2 with the remove of satisfied services in S. With the definition of composition the providing and required services are propagated to the interface of composed component, so the composition could be carried parallel.
After the composition a new test case set for the composed component Tnew could be created. Let T1 is the test case for C1 and T2 for C2, then T C1 ℗ C2= ((T1UT2)/Ts) U Tnew, where Ts are the test cases related to satisfied services in T1 and T2, Tnew are the produced test cases after composition, that is to say, the test cases for composed component are the union of unaffected part of originally test cases and new produced test cases for the matching of required and providing services.
A Component interaction graph is used to describe the interrelation of components. Drawing a complete component interaction graph (CIG) provides an objective basis and technical means for making the testing outline. Generally speaking, a CIG can be obtained from analysis of the requirement and design documents of a system. We simplified the CIG model introduced in reference [1] to describe the interaction of components.
A CIG is a directed graph where CIG = (V, E), V = VI U VC is a set of nodes, VI is the set of interface nodes and VC is the set of component nodes, E represents the set of directed edges. If there is an existing edge form C1.P1 to C2.R1 in the CIG it means the required service R1 of C2 has been satisfied by the providing service P1 of C1, which is C2.R1= C1.P1. In the bottom-up development if all required services of a component are satisfied, then it can be assembled into the realized portion.
We denote an interface with an ellipse and a component with dashed square; the interfaces belong to one component that was drawn in the same square. The interaction among components can be gained from the CIG directly.
There are two kinds of special components, one is the component without the required services, and can be the beginning of composition, the other is the one without the providing services for other components, and can be one end of the composition. According to the fact the numbers of two kinds of components can be one or more.
The CIG illustration is given below: State chart diagrams in UML are used to model the dynamic aspects of a system. A state chart diagram consists of states, transitions, events and actions [Booch, Rumbaugh and Jacobson 1998] and it shows a state machine emphasizing the flow of control from state to state.

GENERATION OF CIG
We model component interactions using a Component Interaction Graph (CIG) which depicts interaction scenarios among components [1]. A component can be represented in the form of a state chart diagram. Here we present a way to convert a statechart diagram to a component interaction graph.
A statechart diagram can be defined as a collection of different state of a component: S={ s1, s2, …, sn} If the machine receives an event while in state si, it reaches state sj, from which an additional event takes it to state sk. Here we can say si is a provided service for sj and in reverse sj requires services from si. At this situation we search the state which triggers an event so that the other component activates and reach at its initial state. Accordingly the state of the second component is a required state or required interface for that component.
To further explain the above concept, let a component C1 has a state S1 and a component C2 has a state S2. Now S2 is said to be a required interface if trigger of an event at S1 automatically activate C2 and reach at a initial state S2.

Example: Vending Machine
The example represents a case in which component A uses a component C. The application models a vending machine. A user can insert coins into the machine, ask the machine to cancel the transaction, which results in the machine returning all the coins inserted and not consumed, or ask the machine to vend an item. If an item is not available, a user's credit is insufficient, or a selection is invalid, the machine prints an error message and does not dispense the item, but instead returns any accumulated coins.   The machine has five states (NoCoins, SingleCoin, MultipleCoins, ReadyToDispense, and Dispensing), accepts five events (insert, cancel, vend, nok, and ok), and produces three actions (setCredit, dispense, and return-Coins). If the machine receives an insert event while in state NoCoins, it reaches state SingleCoin, from which an additional insert event takes it to state MultipleCoins; if the machine receives a vend or cancel event while in state NoCoins, it remains in that state. In states SingleCoin and MultipleCoins, a vend event triggers action setCredit (with different parameters in the two cases: 1 and 2::max, respectively) and brings the machine to state ReadyTo-Dispense. (The notation 2::max is used to indicate that the value of the parameter can vary between 2 and some predefined maximum.) In state ReadyToDispense, the machine produces action dispense and enters state Dispensing, from which it returns to state NoCoins when it receives a nok or ok event; in both cases, any remaining coins are returned through a returnCoins event.  The machine has three states (Empty, Insufficient, and Enabled), accepts two events (setCredit and dispense), and produces two actions (nok and ok). In state Empty, the machine accepts event setCredit and stays in state Empty, reaches state Insufficient, or reaches state Enabled based on the value of the credit, as speci_ed by the guards in the figure. In all three states, the machine accepts event dispense. Events dispense triggers a nok or ok action depending on the availability of the requested item. Now we can generate CIG from the above two state chart diagram by applying the above algorithm. In the component vending machine, the state ready to dispense is switches to the next component Dispenser. So in CIG we can remove the state ready to dispense. In the following figure 3.4, the state single coin and multiple coin causes the component Dispenser to be activated, so this two states can be act as the provided interface and the ready state of Dispenser is act as the required interface. In the same manner Enabled state of the dispenser is act as the provided interface and Dispensing state is the required interface.

Test case Generation
After the composition a new test case set for the composed component Tnew could be created. Let T1 is the test case for C1 and T2 for C2, then T C1 ℗ C2= (( T1UT2) /Ts) U Tnew, where Ts are the test cases related to satisfied services in T1 and T2, Tnew are the produced test cases after composition, that is to say, the test cases for composed component are the union of unaffected part of originally test cases and new produced test cases for the matching of required and providing services.

CONCLUSION
We have presented a new approach for testing component-based software. Our empirical studies show that testing component-based software is necessary yet expensive. The technique we propose includes several criteria for determining test adequacy. Our on-going research directions on this topic are the development of a tool to support automation of the technique, and enhancement of the technique for automated generation of new test cases without modifying the test case library. The future work is going to explain an algorithm to generate the test cases from the generated CIG.