Chapter 8
Component Composition and Program Publication

8.1 PROCESS OF COMPONENT COMPOSING
8.2 DOCUMENT STRUCTURE AND GENERATION METHOD OF RUNNING SCRIPT
8.3 INTERPRETATION AND EXECUTION OF THE RUNNING SCRIPT
8.4 PUBLISHING THE RESULTS OF PROGRAM MINING
8.5 EXAMPLES OF COMPOSING AND PUBLISHING
REFERENCES

The task of Component Composition is to compose a set of components, which are retrieved from the local component resource warehouse (LCRW) to satisfy or nearly satisfy the user requirements, into a new executable component according to the order given by the function order table. The execution of the new component would provide the service required by the user.

8.1 PROCESS OF COMPONENT COMPOSING

As indicated in Chapter 5, the user requirements analysis and functional decomposition will generate keyword tables and subfunction sequence tables. Keyword tables are used to search for components, and subfunction sequence tables are used to assemble the components found.

According to the function order lists and the interface descriptions of the components (in UCDL), Component Composing in program mining is to establish the calling relations among the components and, consequently, coordinate their interface acts into an organic entity. In Component Composing, we use the script language to define a section of the “main program” to call and execute the components by way of sequence, selection, loop, etc. This is what we call Running Script. The running script is generated

according to the subfunction sequence tables and the UCDL interface description files of the components.

Meanwhile, to make it easy for the user to generate such a running script according to the subfunction sequence tables and the UCDL interface description files of the components, we provide a graphic Component Composing tool. This tool visualizes the association relation of the components and their exterior interfaces to the user by graphs, and via interaction, users can select, adjust, and eventually settle Component Composing relations. After the confirmation of the user, the composing tool further transforms the graphic composing scheme into an XML-based running script.

In the interpretation and execution of the running script, we adopt the UCDL agent mechanism. According to the component composing relation defined in the running script, the interface descriptions of the components in UCDL and calling conditions are extracted, and then corresponding UCDL component agencies are started to call the component entities. When the calling results of UCDL component agencies are returned, a complete application program is composed according to the composing relation defined in the running script and then submitted to the users to complete the component composing task.

The process of Component Composing in program mining is illustrated in Figure 8.1.

In Figure 8.1, the Component Composing module is composed of three main parts: graphic Component Composing tool, generating module of running script and the interpretation and execution module of running script. The details of Component Composing are as follows:

1. Graphic-based modeling. According to the component searching results, the UCDL interface descriptions of corresponding components are extracted, and the components with their exterior interfaces are displayed in the graphic-based composing tool using graphic-based mode. Meanwhile, the links among exterior interfaces of the components are pre-generated according to the Component Composing defined in the component subfunction sequence tables.
2. Confirming the graphic-based composing scheme. Supported by the graphic-based composing tool, the user would select and adjust the linking relations among exterior interfaces of the components, and finally confirm the graphic-based composing scheme.
3. Generating the running script. According to the Component Composing scheme, the generating module of running script is called and the running script is generated.
4. Initializing the UCDL component agents. The UCDL component agent is responsible for interpreting the running script, recording the executing process of the script, and controlling and managing the links and callings among different components. First, the UCDL component agent calls corresponding components according to the Component Composing relation defined in the running script and the recorded relating experiences, and then completes and confirms the connections between them.
5. Generating the execution code. After the UCDL component agent generates the links of the corresponding components, the system will further map the running script into the code realization frame according to the control flow defined in the running script, and then generate the execution code, which is executable in the supporting platform of the component.

8.2 DOCUMENT STRUCTURE AND GENERATION METHOD OF RUNNING SCRIPT

The running script plays a significant role in Component Composing. It is responsible for controlling the composing process of the components, and executes composing components in the execution environment.

8.2.1 DOCUMENT STRUCTURE OF THE RUNNING SCRIPTS

The running script is described by an XML file, as shown in Figure 8.2. As regulated in XML description, the whole running script described by XML is called the root element. In running script, the root element is defined as RunningScript, which consists of three parts:

• Components statement (<Components> section). It describes the components to be composed, including component ID, component name, and the component exterior interface. The interpreting program of component entity address will load the corresponding components according to this component entity address statement to prepare for the execution of the script action.
• Definition of interface link relation (<Links> section). It defines the links between the interfaces of different components in the composing, including the source component interface and target component interface. The interpretative program of the running script will decide whether the interfaces match or not according to the definition in this section, and establish the message channel. During the Component Composing process, messages are delivered in corresponding message channels according to the definition in this section.
• Definition of control process of component composing (<Process> section). This section defines the execution process of the components and describes the composing relation of the components, including definition of component calling sequence and message delivery among components.

The XML tags and their meanings corresponding to each section are as follows:

1. <Components> tag. The <Components> tag consists of one or more <Component> tags. Each <Component> tag marks a component statement, including two attributes: ID and name. The former attribute is the unique identification of the component, according to which the script interpretative program can acquire the component in the LCRW. The latter attribute is the name of the component, which can be used to refer the component all through the running script.
   The <Component> tag contains one or more Interface tags. The <Interface> tag identifies the interface statement to be used by the component in the composing. The Name attribute in the <Interface> tag marks the name of the interface. Its subtags <InputMessage> and <OutputMessage> mark the input and output messages of the interface, respectively. The detailed definition of the messages can refer to the UCDL description of the component.
2. <Links> tag. The <Links> tag contains one or more <Link> sub-tags. Each <Link> tag identifies the interface links between two components. The Name attribute in the <Link> tag is the unique identifier to quote the link in the running script. In each <Link> tag, there are two subtags: <From> and <To>, which identify the source interface and target interface of the link respectively, and each interface consists of interface name attribute and component name attribute.
   
   
3. <Process> tag.<Process> tag describes the composing relations of the components by defining the execution process of the components. This execution process is similar to the flowchart of an algorithm. Each step in the process is termed as an action. The <Process> section mainly describes the following basic actions:
   1. <Invoke> calls upon the exterior interface of a component. Two attributes of <Invoke> tag—Component and Interface—further indicate the name of the component to be called and its interface.
   2. <Terminate> terminates the call to a component.
      Based on the above basic actions, the running script forms a more complex flow by defining the control flow mode of the component execution. The control flow includes the following modes:
   1. <Sequence> defines the sequential execution relation among a set of components. A Sequence control flow contains one or more sequential execution actions. During the composing process, the script interpretative program will execute these actions according to the order of these actions listed in the <Sequence> elements.
   2. <Switch> defines the branch execution relations among a set of components. A Switch control flow contains one or more ordered lists formed by Case elements and a final default branch. Each Case element defines a conditional branch. In the process of execution, each case condition is tested one by one, and the first matched branch will be executed. If none of the Case branch conditions is satisfied, the default branch will be executed. The Switch control flow will end when the actions in the selected branch are completed.
   3. <While> defines the loop execution relation among a set of components. The While control flow realizes loop. It implements repetitive actions until the specified While condition is no longer satisfied.
   4. <Flow> defines a parallel execution relation among a set of components. The set of actions contained in Flow control will be executed in parallel in the execution of running scripts. The whole flow control will end only when all actions in it have been completed.
      The above tags can be mutually nested. For example, a Flow structure may contain a Switch structure whose different branches correspond to different Invoke structures.

8.2.2 GRAPHIC COMPONENT COMPOSING TOOLS AND THE GENERATION OF RUNNING SCRIPTS

To facilitate the generation of the running script, we use graphic Component Composing tools to provide users with direct operational interface for defining Component Composing relations. These tools also provide the automatically generating function of the running script, converting the user confirmed graphic-based composing scheme into XML-based running script.

Figure 8.3 illustrates the process using the graphical Component Composing tool to generate the running script.

As illustrated in Figure 8.3, the process of using graphical Component Composing tools to generate running scripts comprises the following steps.

Step 1: According to the user requirement analysis and the component searching results, the composing tools load the components to be composed and read their UCDL description files.

Step 2: According to the component UCDL description, the components and their interface are interpreted and displayed in graphic mode.

Step 3: The composing tool pre-generates the exterior interface links among the components in graphic mode according to the subfunction sequence table decided during the user requirements analysis phase.

Step 4: Users select and adjust the link relations among the component exterior interfaces, and finally confirm the calling and interaction relations among the components to produce the graphic component composing scheme.

Step 5: The running script generation module is called to convert the graphic Component Composing scheme into the running script.

In the following, we will first introduce the definition of the meta-graph in the graphic Component Composing scheme. Then we will go on with the generation algorithm of the running script based on this meta-graph definition.

Definition of the Graphic Component Composing Scheme

The graphic Component Composing tool adopts a directed graph model to define the calling relation and composing process between the components, and designs the meta-graph with reference to UML view.

The UML language has a graphical representation, which is easy to understand, and a semantic set to describe the key features of object system and component system. It is widely used in component-based software development, business flow modeling, system design, etc. See Booch (1998) for more details of UML.

Corresponding to the document structure of the running script, the meta-graph in the graphic Component Composing scheme is classified into two classes: component statement meta-graph and Component Composing control process meta-graph. The interface link relation definition part of running scripts is mainly used to judge the matching relations of interfaces in the composing process. Therefore, there is no corresponding meta-graph definition in the graphic Component Composing scheme.

1. Component statement meta-graph definition. In the graphic Component Composing scheme, the component meta-graph definitions and corresponding examples of the running script are illustrated in Table 8.1.
2. Component Composing control process meta-graph definition. In the graphic Component Composing scheme, the definitions for the actions in the Component Composing control process and corresponding examples of the running script are illustrated in Table 8.2.

Generating Algorithm of the Running Script from the Graphic Component Composing Scheme

With the support of the graphic Component Composing tool, the final graphic Component Composing scheme will be created after the selection and adjustment of the exterior interface links. Subsequently, the system will call the running

script generating module to convert the graphic Component Composing scheme into running scripts. The algorithm runs as follows:

Step 1: Writing the head information of the running script.

Step 2: Traversing the graphic Component Composing scheme, and extract the UCDL description document of the components to be composed.

Step 3: Extracting the component ID, component name, and the interface information in the UCDL document, and filling them into the corresponding document structure <Components> tag of the component statement in the running script according to the structure defined by the running script.

Step 4: According to the component interface links in the graphic Component Composing scheme, establish connections between component interfaces with links, and fill them into the corresponding <Links> tag according to the structure defined by the running script.

Step 5: Traversing the graphic Component Composing scheme in depth, separate each Sequence meta-graph, converting them into a set of sequential executed actions, and changing the calling to each component into an invoke action.

Step 6: Each Switch meta-graph in the graphic Component Composing scheme corresponds to a Switch structure in the running script, in which each case branch corresponds to an action.

Step 7: If a While meta-graph appears in the graphic Component Composing scheme, it corresponds to a While structure in the running script.

Step 8: Add the Flow control structure at both ends of the sequence appearing parallel phenomenon in the graphic Component Composing scheme.

8.3 INTERPRETATION AND EXECUTION OF THE RUNNING SCRIPT

When the running script is generated, the system completes the Component Composing by interpreting and executing the running script. The interpretation and execution of the running script is illustrated in Figure 8.4.

According to the document structure of the running script, the interpreting program of the running script is divided into three parts to interpret and execute the running script.

1. Interpretation and execution the component statement part (<Components>). According to the component ID and Name attribute
   
   
   
   specified in the <Components>, the interpreting program of the running script extracts the corresponding components from LCRW and the UCDL descriptions, starts the UCDL agent, and generates the corresponding input and output interfaces according to the component interface description defined in the <Interface> tag.
   When started, the UCDL agent loads the codes of the components, calls the initialization interface to generate the running instance of the component deputized, and begins to listen to the input message. In the subsequent composing, the UCDL agent will be responsible for calling the corresponding components.
2. Interpret and execute the component interface links (<Links>).<Links> tag defines the interface links relations among the components. According to this definition, the interpreting program of the running script checks if the interface links match, and if the message definitions among the interfaces are consistent. If the examination is passed, the interpreting program of the running script will register the interface link as a message channel and go on with next analysis. Otherwise, the interpreting program of the running script will stop and return the error message.
3. Interpretation and execution of the Component Composing control process (<Process>). The <Process> tag defines the Component Composing relations by defining their execution process. In the process of interpreting and executing this part, the interpreting program of the running script generates the input/output messages for the component interaction according to the control process between the components defined in the script, and sends them to the UCDL agent. After analyzing the received input message, the UCDL agent transforms it into the calling parameter formats that is understandable to the components, and sends a call request to the corresponding component interface. When the result is returned, the UCDL agent will “encode” the returned value into the corresponding UCDL output message, and send it to the interpreting program of the running script through a certain output port. Then, the executor will go on the process of component composing according to the defined control flows.

8.4 PUBLISHING THE RESULTS OF PROGRAM MINING

When the composing process ends, the system needs to test and verify the result of the program mining to guarantee that the obtained programs can fulfill the functions required by the user. The verification and test of the

program include those on correctness of function division, on correctness and completeness of the XML description of the function, and on consistency between the execution result of the composed component and the user requirement.

The verification and test of the program mining may adopt methods used in software engineering, e.g., finite state machine, PetriNet, temporal logic, or other testing tools. We will omit the details here.

The program mining system needs to publish the program that has passed the test, which includes the following two subtasks:

1. If the composed new component passes the test, it will be recorded into the LCRW, and the corresponding description information is generated so that similar program mining examples can be retrieved when the user suggests similar request next time.
2. The new composed component is published on the Web as a Web service. Through the human–machine interface of program mining, users will get the corresponding service by accessing the Web service.

8.5 EXAMPLES OF COMPOSING AND PUBLISHING

We take the three ATM associated components in Chapter 4 as examples to illustrate the process of Component Composing and publishing.

Example 8.1 Component Composing and publishing

Suppose that the three components related to ATM are the component ATMGUI, component Transanctions and component DBProcess, which perform the ATM interface function, the ATM transaction processing function, and the account information management function in ATM transaction, respectively.

The function order among the three components is: component ATMGUI invokes component Transanctions, sending the transaction requirements passed from the ATM user interface; component Transanctions finishes the corresponding transactions and invokes component DBProcess to store the data.

Try to assemble the three components as illustrated in Figure 8.1.

Solution: the composing takes five steps, i.e., graphical modeling, confirmation of graphic Component Composing scheme, generation of running script, initialization of the UCDL component agent, and generation of executable code.

1. Graphic-based modeling. In the graphic-based composing tool, we use the physical view of UML view to represent the three components. The component is represented by a big rectangle with two small rectangles fixed at one side, and the circle adjoining it indicates the component interface.
   According to the function order of the three components, the system displays the three components in the graphic Component Composing tool, and pre-generates the links between the component exterior interfaces.
2. Confirmation of graphic Component Composing scheme by the user. The user selects and adjusts the links between the component exterior interfaces, and finally confirms the graphic Component Composing scheme (see Figure 8.5).
   Figure 8.5 is the graphic Component Composing scheme of the three components, in which dashed arrows indicate the calling relations. By combining the three components, a complete ATM application can be easily generated.
3. Generation of running script. According to the graphic Component Composing scheme, we can invoke the running script generation
   
   module to obtain the corresponding, running script, which is illustrated in the following:
   
   
   
4. Initialization of UCDL component agent. Start the UCDL component agent. Then, the agent gets the UCDL interface descriptions of component ATMGUI, component Transactions, and component DBProcess, as well as the composing relation defined in the running script. The
   
   memory and learning function of the UCDL agent will check if there are any links among the three components. If the links exist, then they are returned. Otherwise certain components will be called to generate the links.
5. Generation of executable code. According to the component link relations generated by the UCDL component agent and the component calling relations defined in the running script, the system maps the running script into the code realization frame and generates the component code that could run on the component supporting platform.
   After the Component Composing is completed, we need to publish the composed component, which involves two subtasks. On the one hand, the new component and its service function are provided to the human–machine interface of the program mining system in the Web Service form, and through this interface users are provided with the service needed. On the other hand, the newly generated component and its description are published into the LCRW so that similar program mining examples can be quickly retrieved when the user puts forward a similar request next time.

REFERENCES

Aki, T., and Petri, V. (2001). Speech interface implementation for XML browser. Proc. of the 2001 International Conference on Auditory Display, Espoo, Finland, July 29 to August 1.

Andreas, M., Thomas, M., and Wolfgang, L. (2001). Using XML to semi-automatically derive user interfaces. Second International Workshop on User Interfaces to Data Intensive Systems. May 31 to June 01.

Booch, G., Rumbaugh, J., and Jacobson, I. (1998). Unified Modeling Language user guide. Addison-Wesley.

Borenstein, N., and Freed, N. (1993). MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for specifying and describing the format of Internet message bodies. RFC 1521 September 1993.

Cloud, G. J. http://www.cloudgarden.com/JSAPI/index.html

Fang, C. H., Zhang, Y. X., and Xu, K. G. (2003). A XML-based data communication solution for program mining. Intelligent Data Engineering and Automated Learning, 4th International Conference (pp. 569–575). Hong Kong, Berlin, Heidelberg: Springer-Verlag.

Hai, Z. (2000). A Problem-oriented and rule-based component repository. The Journal of Systems and Software, 50, 201–208.

JavaBeans Development Kit (BDK) Tutorial. http://java.sun.com/products/javabeans/software/bdk_download.html

Marc, A., and Constantinos, P. UIML: an XML language for building device-independent user interface, from http://www.uiml.org

Shi, H. C., Shang, Y., and Ren, F. J. (2001). Using natural language to access databases on the Web. 2001 IEEE International Conference on Systems, Man, and Cybernetics, 1 (pp. 429–434). IEEE (IEEE Press).

Simon, N., and Paul, H. (1999). Teach yourself XML in 21 days. SAMS Publishing.

Stephane, H. M. (2002). A voice XML framework for reusable dialog components. Proc. of the 2002 Symposium on Applications and the Internet (SAINT”02). IEEE (IEEE Press).

Sun Microsystems. JavaTM speech grammar format specification, Version 1.0, October 26, 1998, from http://java.sun.com/products/java-media/speech/forDevelopers/JSGF/

Web Services Description Language(WSDL)1.1 March, 2000. http:///www.w3.org/TR/wsdl

Xia, D. L., Zhang, Y. X., and Fang, C. H. (2003). Design and implementation of an agent-based program mining system. Chinese Journal of Electronics, 31(5), 793–796.

Xu, K. G., Zhang, Y. X., and Fang, C. H. (2003). Introducing XML to program mining. Proc. of the International Conference on Telecommunications (pp. 163–168). Beijing: Publishing House of Electronics Industry.

Yasser, S. Introduction to WSDL, from http://www.devxpert.com/tutors/wsdl/wsdl.asp

Zhang, Y. X., Fang, C. H., and Wang, Y. (2004). A feedback-driven online scheduler for processes with imprecise computing. Journal of Software, 15(4), 616–623.