[ieee 2006 sixth international conference on quality software (qsic'06) - beijing, china...

A Framework for Extensible Component Customization for

Component-based Software Development

Stephen S. Yau, Choksing Taweponsomkiat, and Dazhi Huang Computer Science and Engineering Department

Arizona State University Tempe, AZ 85287, USA

Email: {yau, choksing}@asu.edu

Abstract Component-based software development (CBSD)

increases productivity of software developers and improves overall software quality due to high de-gree of reusability. To achieve the full potential of CBSD, it is necessary for software developers to be able to customize components because it is rare to find the components completely matching their functional and non-functional requirements in the new applications. Existing customization approaches can be used to address this problem only in a narrow set of application domains. Addressing customization in a wide range of application domains is highly desirable, but very challenging because there are usually a number of different ways to customize a component. Different application domains can require vastly different customizations on the same component. In this paper, a framework for extensible component customization, which is independent of any run-time system or platform and can be used in a wide range of application domains, is presented.

Keywords: Component-based software development (CBSD), software reuse, component customization framework, extensible component, application domains.

1. Introduction

Although component-based software

development CBSD [1, 2] has great potential in software reuse, it is still very difficult to use suitable software components in software development. Ideally, software developers should be able to find components that fully match the functional and non-functional requirements in the new applications. In reality, the match is often partial [2] because components are developed based on requirements

and assumptions different from those for the new applications. Hence, it is important that software developers are able to customize components to resolve various mismatches [2 – 5].

Both component providers and software developers play important roles in CBSD. Component providers (also called component developers) develop components, while software developers (also called integrator) construct application software using existing components as much as they can. Component providers have access to the source code of components and have deep understanding of the components. Although component providers would like to maximize the reusability of their components, they normally do not customize or integrate the components on software developers’ behalf, unless they are required to do so. In addition, software developers may not want to have the component developers to do the component customization because it may involve software developers’ confidential information or intellectual properties. However, software developers often need the selected components to be customized before the components can be integrated to create the software systems. Although technically competent, software developers usually do not have access to source codes and in-depth understanding of the components. Hence, they need certain support from component providers to achieve the desired customization of the components.

Existing component customization approaches cannot be used in a wide range of application domains due to various limitations. Binary customization [6] relies on special features of Java virtual machine bytecode, and hence its usage is limited to such a platform. Wrapper-based approaches [3, 7, 8] customize components from the outside by bridging interface mismatches, adding new methods, enhancing existing methods, and

Proceedings of the Sixth International Conference on Quality Software (QSIC'06)0-7695-2718-3/06 $20.00 © 2006

mediating interactions between components. Because of encapsulation, properties and behavior that are internal to components remain inaccessible in such approaches. Component parameterization [9-11] allows software developers to customize components’ internal properties and behavior by choosing proper parameters from a set of available options embedded inside components. The main problem of this approach is that customization choices are predetermined, and hence the reusability of components is limited.

In this paper, we will present a framework for extensible component customization, which is independent of any run-time system or platform and can be used in a wide range of application domains. Our framework will facilitate the customization of the internal properties and behavior of components with little interactions between component providers and software developers. Our framework includes a language for component providers to specify the internal points of the components where the required changes can be made. Using our framework, software developers, without extensive knowledge of the components and access to the source code of the components, can customize the components to their requirements.

2. Overview of our framework

The component customization supported by our framework involves two types of activities: component modification by software developers and component extension by component providers.

Component modification is performed by a software developer to implement the required changes of the component as separate code modules, following the corresponding special code structures generated by the component provider. The code modules developed by the software developer are called customcodes, and the corresponding special code structures are called customcode skeletons. A customcode skeleton serves as an interface between the corresponding customcode and the component. The detailed design of customcode skeleton will be discussed in Section 3.2.

Component extension is performed by a component provider using our framework to generate customcode skeletons and the corresponding extension ports in the component. An extension port is a piece of code that enables the interactions between the component and the corresponding customcode skeleton for the changes to take effect in runtime. Our framework provides a language for component providers to specify what changes can be made to the component, and where the extension ports should be generated. Such specifications are called customspecs, and the location of an extension port is called a custompoint. Our framework provides a customspec compiler to automatically generate extension ports and their corresponding customcode skeletons. We will discuss customspec, custompoint and customspec compiler in detail in Section 3.1.

To facilitate component customization, our framework also provides services for software developers to retrieve customspecs and customcode skeletons of a component, and to link customcodes

Customcode implementation

Change requirement can be satisfied?

YES

NO

Change requirement

Componentextension

Test and debug the customcode with the

component

YesSucessful?

No

Find an alternative

customspec oranother

component

Compare customspec with change requirement

Customspec

C1

C3

C4

C5C2

Software DeveloperComponent Provider

Figure 1. Overall component customization process using

our framework


with the component. These services are called customization services.

The overall component customization process using our framework is shown in Figure 1. Suppose a software developer wants to use a component in developing a software system. However, the component only satisfies part of the requirements for the target software. We assume that the provider of this component has prepared the component for customization by performing domain analysis [12] to identify the potential changes frequently required by software developers, and specifying the custompoints for these potential changes. Using domain analysis techniques [12], the component provider analyzes applications, which have already utilized this component or other components with similar functionality, in the same domain to identify the variation in the ways that these applications use these components, or the differences in the functionality of these components. These identified variations and differences are considered potential changes to the component. The component provider can specify the custompoints for these potential changes following a process similar to Step C2) in the overall customization process. The overall customization process can be presented as follows: C1) A software developer compares all the

customspecs written by the component provider with the change requirements of the component. If the required changes are allowed according to the customspecs, go to C3). Otherwise, go to C2).

C2) The component provider extends the component to allow the required changes as follows:

a. Identify all the custompoints based on the change requirements.

b. Write customspecs for the required changes at the custompoints.

c. With the customspecs, the customspec compiler automatically generates the customcode skeletons and corresponding extension ports in the component, and go to C3).

C3) The software developer implements the customcodes based on the change requirements with the support of customization services in

our framework. Go to C4).

C4) The software developer tests and debugs the customcodes with the component. If successful, the overall process is completed. Otherwise, go to C5).

C5) Find alternative customspecs in the component for the required changes, or find a new component from the component repository when there are no alternative customspecs, and go back to C1).

C1) is performed by the software developer with the support from information retrieval techniques such as [13]. In C2.a), the component provider can use techniques, such as program slicing [14,15] to identify the custompoints. For C4), component testing and debugging techniques in [16-19] can be used. For C5), software component retrieval techniques in [20,21] can be used. The details of C2.b), C2.c) and C3) will be discussed in Section 3. 3. Detailed design of our framework

In Section 2, we have presented an overview of

our framework, and the overall component customization process using our framework. In this section, we will discuss the custompoint specification language, the implementation of customcodes based on customcode skeletons, and the supporting customization services. 3.1. Custompoint specification language

As discussed in Section 2, a component provider uses the cutompoint specification language to write customspecs for a component. A software developer acquires the information about the changes allowed to be made to a component by reading customspecs of the component.

The customspecs for the allowed changes to a component include the following parts: i. Overview of the allowed changes. ii. The postconditions that must be satisfied after

the execution of extension ports to be generated for the allowed changes.

iii. Specification of custompoints for the allowed changes.

The following is an example of a customspec: <overview> Allow customization of priorities of task0-task3. </overview> <post-condition> Priority must not be set higher than 50. </post-condition> <matching-expression> CUSTOM_POINT prioritySet { CALL : EPC::"taskPrioritySet" (int threadID, int

priority) } </matching-expression>

Figure 2. The designator format


Similar to crosscutting concerns in Aspect Oriented Programming (AOP) [22], a certain change required by a software developer may correspond to a set of custompoints scattered in various functions of a component. Instead of enumerating these custompoints, regular expressions are used in our language to describe the patterns of the custompoints for a required change. Such regular expressions are called designators in our language. A designator matches a set of custompoints based on the designator type, component name, function name pattern and parameter list pattern. The format of a designator is shown in Figure 2.

The type of a designator is based on the locations of extension ports for the required change. Extension ports can be located at places where function calls are made, or functions are defined. Hence, two designator types are used in our language: call designator (signified by the keyword CALL) and definition designator (signified by the keyword DEF).

A regular expression based matching method [23] has been incorporated in the customspec compiler to locate custompoints in the component code during the generation of extension ports and customcode skeletons. For example, the designator shown in Figure 2 will match all the “setPriority”

function calls inside the component CompA regardless of their parameters.

Our implementation of the customspec compiler uses the combination of lex, yacc and Perl based on the assumption that C++ is used to develop the components. The compiler can be ported to other languages, such as Java, with little effort.

3.2. Implementation of customcodes based on customcode skeletons

Generation of customcode skeleton and

extension port Once the component provider identifies all the

custompoints for the required changes using techniques presented in [14,15], the provider uses our custompoint specification language to write customspecs for the required changes at the custompoints. After that, the customspec compiler will automatically generate the corresponding extension ports and customcode skeleton based on the customspecs.

A customcode skeleton consists of the following four types of functions: (1) Before-custompoint functions. The code inside these functions are executed just before the

execution of the original code, called Co, at the corresponding custompoints. (2) Skip-custompoint functions. If a skip-custompoint function returns true, Co will not be executed. (3) After-custompoint functions. The code inside these functions are executed right after the execution of Co. (4) Plugin functions. Plugin functions serve as the interfaces for the component to invoke the customcode in runtime for the required change to take effect.

The before-custompoint, skip-custompoint, and after-custompoint functions are called hook functions. In general, for each custompoint, a function of each type will be generated. In particular, the generated skip-custompoint function must return false in order to keep the original functionality of the component. The code body of the hook functions needs to be modified by the software developer based on the required change.

The generated plugin function will execute the following steps sequentially: P1) Call the before-custompoint function to execute the code that needs to be inserted, if any, before Co. P2) Call the skip-custompoint function to check whether Co should be executed. P3) Call the after-custompoint function to execute the code that needs to be inserted, if any, after Co.

At each custompoint for a required change, an extension port is generated by replacing Co with an invocation to the generated plugin function in the customcode skeleton. Figure 3 illustrates the generation of an extension port, and Figure 4 shows the corresponding customcode skeleton.

Implementation of customcode Based on the generated customcode skeleton, a

software developer can implement the customcode for the required change as follows: • Remove the entire functionality provided by Co by changing the return value of the skip-custompoint function to true. • Replace the entire functionality provided by Co with some new functionality by adding code for the new functionality in the after-custompoint function and changing the return value of the skip-custompoint function to true. • Extend the functionality provided by Co by adding the part of the customcode for the extension in the before-custompoint function and/or the after-custompoint function.


Negative side-effect Because customcodes have access to internal

implementations of components, if they misbehave, the customized component will have negative side effects. To address this issue, techniques, such as precondition and postcondition assertions [24], can be used to detect occurrences of such negative side effects, and trigger exception handling procedures to take care of the problems. Alternatively, if components are developed with some form of formal model, formal verification techniques (e.g. model checking [25]) can be used to verify the absence of negative side effects. 3.3. Customization services

The following customization services are provided in our framework to facilitate the activities for component customization: • A printCustomSpec service for software

developers to retrieve the customspecs of a

component. The customspecs are embedded in the code of the component to eliminate the dependencies on specific structures of component repositories.

• A printCustomSkeleton service for software developers to retrieve the customcode skeletons of a component. Similar to customspecs, the customcode skeletons are also embedded in the component.

• An attachCustomCode service for software developers to link customcodes to the component in run-time.

• An extensionRequest service for software developers to send change requirements to component providers.

Similar to application plugins [26], the attachCustomCode service support a customcode to register with the component in runtime, and establish a connection between the customcode and the component to exchange data, and transfer controls of executions. Customcodes, like the application plugins, depend on components and cannot function alone. However, components function independently of customcodes. Hence, like the plugins, new customcodes can be linked to components dynamically in runtime.

4. An example

Consider a distributed network management system, which is responsible for monitoring four network events, e1-e4, and keeping track of network status. Each event is processed by an individual thread. The priorities of the events in the network management system are 4 for e1, 2 for e2, 3 for e3 and 1 for e4. The main component of the system, Event Processor Component (EPC), has been developed, and its provider has prepared EPC for customization. It satisfies most of the requirements, such as processing network events, and forwarding network status information to a display console. However, it does not prioritize the events e1-e4 as required.

Using our framework, the software developer of the network management system customizes EPC, with a little help from the EPC’s provider, to prioritize events e1-e4 properly as follows:

CompA

CompA

taskPrioritySet(threadID, 100);

CustomCode->fw_taskPrioritySet(this, threadID, 100);

Customspec Compiler

CustomspecCALL : CompA::taskPriority*

(threadID, priority)

Original function at custompoint

Customspec

Customcode skeleton

Plugin function

Generated extension port

Figure 3. Generation of an extension port

fw_taskPrioritySet(void *comp, int threadID, int priority) before_taskPrioritySet(comp, threadID, priority); if(!skip_taskPrioritySet(comp, threadID, priority)) { taskPrioritySet(threadID, priority); } after_taskPrioritySet(comp, threadID, priority);}

void before_taskPrioritySet(void* comp, int threadID, int priority) {};

void after_taskPrioritySet(void* comp, int threadID, int priority) {};

boolean skip_taskPrioritySet(void* comp, int threadID,int priority){

return FALSE;};

Customcode skeleton

1

3

2

Plugin functionOriginal

function at custompoint

Hook funtions

4

Figure 4. Customcode skeleton


C1) The software developer invokes the printCustomSpec service to retrieve the customspecs specified by EPC’s provider previously. Assume EPC’s provider only specified the following customspec:

<overview> Allow customization of processing functions.

The variable “port” is the network port number of the network event to be processed.

</overview> <post-condition> N/A </post-condition> <matching-expression>

CUSTOM_POINT processingEventFunctions { DEF : void EPC::"processE[0-9]+" (int port) }

</matching-expression>

Based on the overview of the allowed change in this customspec, the software developer finds that this customspec does not satisfy the required change of prioritizing the network events e1-e4. Hence, the software developer uses the extensionRequest service to send the following change requirement to the componenet provider:

EPC.extensionRequest(“Need to customize the EPC’s internal threads’ priorities.”);

C2.a) Upon receiving the extension request, the component provider first identifies the custompoints for the required change based on his experience with EPC: • Custompoints are the places where the function

calls are made to the system function “taskPrioritySet(int threadID, int priority)”, which set thread priorities. Furthermore, the component provider knows that

the priority of each thread has to be set lower than 50 for the component to function correctly, which must be specified as a postcondition in the customspec for the identified custompoints.

C2.b) Based on the results of C2.a), the component provider writes the following new customspec for the required change:

<overview> Allow customization of priorities of the

processing threads of network events e1-e4. The variable “threadID” is the ID of the thread for which the priority is set. The variable “priority” is the new priority.

</overview> <post-condition>

The priority of any thread must be set lower than 50.

</post-condition> <matching-expression> CUSTOM_POINT prioritySet {

CALL : EPC::"taskPrioritySet" (int threadID, int priority)

} </matching-expression>

C2.c) After specifying the above new customspec, the component provider uses the compiler to generate the following customcode skeleton:

//Plugin function for taskPrioritySet

void customCode::fw_taskPrioritySet(void * obj0, int threadID, int priority) {

before_taskPrioritySet(obj0, threadID, priority); if(!skip_taskPrioritySet(obj0, threadID, priority)) { taskPrioritySet(threadID, priority); } after_taskPrioritySet(obj0, threadID, priority); }

//Before-custompoint function for taskPrioritySet void customCode::before_taskPrioritySet(void * obj0,

int threadID, int priority) { };

//Skip-custompoint function for taskPrioritySet boolean customCode::skip_taskPrioritySet(void * obj0,

int threadID, int priority) { return false;

}; //After-custompoint function for taskPrioritySet

void customCode::after_taskPrioritySet(void * obj0, int threadID, int priority) {

}; The corresponding extension ports are also

generated by the compiler by replacing the code at the custompoints in the EPC with the invocations of the plugin functions in the skeleton. For example, a generated extension port at a custompoint “taskPrioritySet(tid1, 100);” is shown as follows:

((customCode*)custom)

->fw_taskPrioritySet(this,tid1, 100); After this step, the component provider ships the

extended EPC to the software developer to continue the customization process.

C3) Upon receiving the extended EPC, the software developer makes the following changes to the customcode skeleton generated in C2): • The return value of the function

skip_taskPrioritySet is then changed to true to skip the original priority assignments.

• The following code is added to the body of the function after_taskPrioritySet to change internal


thread priorities of the EPC to properly prioritize the processing of network events e1-e4.

void customCode::after_taskPrioritySet(void * obj0, int

threadID, int priority) { if(threadID == e1) {

taskPrioritySet(threadID, 4); } else if(threadID == e2) {



taskPrioritySet(threadID, 1); }

}; After making these changes, the software

developer uses the attachCustomCode service to link the above customcode with EPC.

Note that the above customcode affects multiple custompoints, which are all function calls in EPC to taskPrioritySet function. This shows that our framework allows the reuse of the same customcode for many custompoints. C4) After testing the customcode with EPC, the software developer concludes that the customization of EPC has been completed successfully.

5. Performance and overhead of our framework

In this section, we will discuss the overhead and

performance of our framework using the distributed network management system described in Section 4. We selected WindRiver VxWorks embedded real-time operating system as our target platform. The customization services were implemented using GNU C++.

In addition to the EPC described in Section 4, two other components were also customized using our framework for developing the system. As shown in Table 1, the code generated by our framework increases the size of each component. The increased size of each component, in terms of the number of lines of code (LOC), is proportional to the number of custompoints in the component. Hence, for

components with the same number of custompoints, the percentage of the overhead to the original size of a component should be smaller for the larger components.

From performance perspective, the generated code does not incur any significant penalty in terms of execution time. In our experiments of components with 5, 10, 50 and 150 custompoints, there is no significant increase of the execution time.

6. Summary

In this paper, we have presented a framework,

which includes a language for specifying custompoints for required changes, a customspec compiler and customization services, for extensible component customization in a wide range of applications. Our framework allows software developers, with a little help from component providers, to change internal properties and behavior of the components. Our framework also allows component providers to use their in-depth understanding of the components to extend the components to allow the required changes without implementing the actual changes. The performance and overhead of our framework have been demonstrated by an example, and the results show that although the increased size of a customized component is proportional to the number of custompoints in the component, no significant performance penalty has incurred.

The capability of our framework to address complex customizations is similar to how cross-cutting concerns are captured in Aspect Oriented Programming (AOP). However, AOP assumes that the software developers using AOP have in-depth knowledge of the source code, which is usually not the case with software developers in CBSD.

Since our goal is to develop a flexible and general customization framework, it may not be the most efficient way of customizations in a particular application domain. A domain specific solution could be easier to use and have lower overhead. One way to address this issue is to use the idea of

Table 1. Comparison of the size of components before and after customizations

Component # of custompoints LOC Object size (KB) LOC after

customization Object size after

customization (KB)

Event Processor 17 179 75 298 127

Event Dispatch 10 126 73 193 123

Central Processing 3 26 67 93 116


customization patterns. Based on the concept of design patterns [27], customization patterns describe distilled and proven solutions of frequent customization problems. The customization patterns will make identifying and specifying custompoints, and developing customcodes easier.

In our current framework, no supporting mechanisms are provided for selecting the most suitable customspec for a certain change requirement. Arbitrarily selecting custompoints from customspecs satisfying the change requirement to perform the customizations may result in low-quality designs of customized components. Future research in this area includes development of techniques for evaluating and specifying the quality of changes, improvement of our specification language, and development of automated methods for selecting custompoints, as well as techniques for detecting and avoiding negative side effects caused by misbehaving customcodes.

References [1] N. Gill, “Importance of software component characterization for better software reusability”, ACM SIGSOFT Software Engineering Notes, vol. 31 (1), 2006, pp. 1-3. [2] B. Morel and P. Alexander, “SPARTACAS: Automating Component Reuse and Adaptation”, IEEE Trans. on Software Engineering, vol. 30 (9), pp. 587-600. [3] P. Inverardi, L. Mostarda, M. Tivoli and M. Autili, “Synthesis of correct and distributed adaptors for component-based systems: an automatic approach”, Proc. 20th IEEE/ACM Int'l Conf. on Automated software engineering, 2005, pp. 405-409. [4] J. Kim, J. Taek and S. Hwang, “Rule-based Component Development”, Proc. 3rd ACIS Int'l Conf. on Software Engineering Research, Management and Applications, 2005, pp. 70-74. [5] B. Wang, X. Liu, J. Kerridge and Y. Li, “Scenario based Generative component Adaptation in .NET framework”, Proc. IEEE Int'l Conf. on Information Reuse and Integration, 2004, pp. 73-78. [6] J. Kim and K. Lee, “Binary Component Adaptation Technique and Supporting Tool”, Proc. 3rd ACIS Int'l Conf. on Software Engineering Research, Management and Applications, 2005, pp. 14-21. [7] G. Gannod, S. Mudiam and T. Lindquist, “An Architectural Based Approach for Synthesizing Wrappers for Legacy Software”, Proc. 7th Working Conf. on Reverse Engineering, 2000, pp. 128–137. [8] S. Yau and N. Dong, “Integration in Component-based Software Development Using Design Patterns”, Proc. 24th IEEE Int'l Computer Software and Applications Conf. (COMPSAC 2K), 2000, pp. 369-374. [9] S. Göbel, “Encapsulation of structural adaptation by composite components”, Proc. 1st ACM SIGSOFT Workshop on Self-managed Systems, 2004, pp. 64-68. [10] C. Oancea and S. Watt, “Parametric polymorphism for software component architectures”, Proc. 20th Annual ACM SIGPLAN Conf. on Object Oriented Programming, systems, languages, and applications, 2005, pp. 147-166.

[11] S. Yau and F. Karim, “Component Customization for Object-Oriented Distributed Real-time Software Development”, Proc. 3rd IEEE Int'l Symposium on Object-Oriented Real-Time Distributed Computing, March 2000, pp. 156-163. [12] R. Prieto-Díaz, “Domain analysis: an introduction”, ACM SIGSOFT Software Engineering Notes, Vol. 15(2), 1990, pp. 47-54. [13] J. Böorstler, “Feature-oriented Classification for Software Reuse", Proc. 7th Int’l Conf. on Software Engineering and Knowledge Engineering, June 1995, pp. 204-211. [14] M. Weiser, “Program slicing”, Proc. 5th Int’l Conf. on Software Engineering, 1981, pp. 439-449. [15] K. Gallagher and J. Lyle, “Using program slicing in software maintenance”, IEEE Trans. on Software Engineering, vol. 17 (8), 1991, pp. 751-761. [16] M. Harrold, D. Liang and S. Sinha, “An approach to analyzing and testing component-based systems”, Proc. 1st Int’l ICSE Workshop Testing Distributed Component-Based Systems,1999. [17] D. Rosenblum, “Adequate Testing of Component Based Software”, Technical Report 97-34, Department of Information and Computer Science, University of California, Irvine, Irvine, CA, 1997. [18] W. Drabent, S. Nadjm-Tehrani and J. Maluszynski, “Algorithmic Debugging with Assertions”, Workshop on Meta-Programming in Logic, 1988, pp. 501-521. [19] H. Agrawal, R. DeMillo and E. Spafford, “Debugging with Dynamic Slicing and Backtracking”, Software - Practice and Experience, vol. 23(6), pp. 589–616, June 1993. [20] H. Guo, M. Liu and J. Pi, “Precise specification matching for automated component retrieval and adaptation”, IEEE Int’l Conf. on Information Retrieval and Integration (IRI 2003), October 2003, pp. 77-84. [21] B. Fischer, “Deduction-Based Software Component Retrieval”, PhD-thesis, Universität Passau, November 2001. [22] T. Elrad, R. Filman, A. Bader, “Aspect-Oriented Programming”, Communications of the ACM, Vol. 44(10), 2001, pp. 9-32. [23] J. Friedl, “Mastering Regular Expressions (2nd Ed.)” O'Reilly, 2002. [24] B. Meyer, “Applying "Design by Contract"”, Computer (IEEE), vol. 25(10), 1992, pp. 40-51. [25] E. Clarke, O. Grumberg, and D. Long, “Verification tools for finite-state concurrent systems”, A Decade of Concurrency - Reflections and Perspectives, Lecture Notes in Computer Science, Springer-Verlag, 1994, pp. 124-175. [26] J. Grundy and J. Hosking, “Engineering plug-in software components to support collaborative work”, Software: Practice and Experience, Vol. 32(10), July 2002, pp. 983-1013. [27] E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1994.


[ieee 2006 sixth international conference on quality software (qsic'06) - beijing, china...

Documents