[ieee fourth international conference on information technology (itng'07) - las vegas, nv, usa...

Enhanced Component Reuse with Atomic Domains: Application Scenarios

Hisham M. Haddad and Mauricio Jose Ordoñez CSIS Department

Kennesaw State University Kennesaw, Georgia 30144

Abstract The implementation of component-based development has reached an era of success yet still is facing issues where local component models are concerned. Some issues from the programmer’s perspective are not only the ease and amount of reuse but also implementing a reuse solution that self-selects the best component. Building on previous work, this paper focuses on a general-model framework for developing domain-specific reusable components. The paper illustrates the application of the Atomic Domains methodology of the general-model framework to specific scenarios of component-based software engineering in an attempt to show a normalized or enhanced local component model. The application of the framework is illustrated as a mapping of its Atomic Domains methodology to each selected scenario, thus increasing the possibility for ease of reuse and promoting higher reuse for the programmer and the domain of application.

Keywords: Atomic Domain, Wrapper, Reusable Domain, Domain-Specific Reuse. 1. Introduction The ultimate goal of Component-Based Software Engineering (CBSE) is to achieve cost effective and efficient software development through component reuse. However, for effective CBSE implementation, there is an investment that takes on a number of different forms. For today’s industry the implementation of CBSE is becoming more prevalent to stay competitive, and it ranges from the use of isolated solutions such as using languages [1], wrapping legacy components [2], refactoring [3], product line technologies [4], and product populations [5] to the use of distributed component technologies. Of the many CBSE approaches above, components that are distinct at runtime and do not exhibit themselves at the development level are not the approach of this work.

In previous work, the general-model framework for

developing domain-specific reusable components [6,7] has evolved as a CBSE tool that targets specific domains

to promote and facilitate effective reuse of code components. The components are source code and are grouped into Atomic Domains, whose subsequent selections are based on analysis of new source code in which they are to be reused. This is noticeably different approach to CBSE when compared to some local component models, but more so when compared to distributed component models which typically are, and rightly so, of a more generic domain.

In the Atomic Domain methodology, each atomic domain (collection of related reusable components) has a wrapper. Each wrapper has a taxonomy, manager components, API component, communications component, and control component. Figure 1 illustrates an integrated development environment and compiler that have been modified with a Wrapper PreProcessor (WPP) to allow for component control through one or more wrapper APIs. A single command in the source code references the whole atomic domain through its wrapper. For example, when the command sort() is sent to atomic domain Sort (a collection of different sort methods), the associated wrapper manager selects that call with the appropriate component in the atomic domain (e.g., bubble sort, quick sort, merge sort, etc.). This approach allows dissociating the programmer from the selection process of the component in the atomic domain and the nuances that often differentiate command use. The programmer intention is inferred by analyzing the source code surrounding and including the single command line and comparing it to the application domain rules which have been learned from past component use within the domain. Thus, the general-model framework hides the fact that complexity is found not in the atomic domain wrapper’s APIs but in the wrapper’s manager. In the following sections, the Atomic Domains methodology and its Wrapper concept are applied to selected CBSE cases to illustrate a normalized or enhanced local component model. The application of the general-model framework is illustrated (verbally or graphically) as a mapping of the framework’s Atomic Domain methodology to each scenario, resulting in the

International Conference on Information Technology (ITNG'07)0-7695-2776-0/07 $20.00 © 2007

Figure 1. General-model framework – an IDE, compiler, and WPP with three Atomic Domains

possibility for increasing the ease of reuse for the programmer and the application domain. It should be noted that the general model could not be mapped to all scenarios researched as some of them include the use of special languages or the prescription of specific APIs. It should also be noted that while some cases were less structured and easily lent themselves to the full application of the general model, others proved more difficult to determine an exact mapping as they provide only a detailed, coded, working example of component reuse. Only scenarios where adequate mapping could be applied are discussed in the following sections. 2. Device Drivers as a Product Line

This first CBSE scenario is the development of device drivers as a product line made up of reusable components [8] with the application of a reuse framework. This is a case study in the implementation of a wireless PCMCIA card driver by reusing and/or modifying components from existing drivers. Figure 2 shows the re-organization of software architecture for component-level reusability, and the application of the general-model framework (using atomic domains). In the Figure, components are represented as modules A through L, renamed here for ease of illustration (actual module names are shown in Table 1).

As alternative solution for this CBSE scenario, three

atomic domains and their wrappers are utilized, denoted by A-Domain A through A-Domain C. Atomic domain A consists of Module A (init-module()). It is called from the application source code via the a single command (single_command_A(*)). Atomic domain B is composed of modules B and C, which are related to devise drivers. Being OS dependent functions, they specify device driver interfaces with the operating system. Therefore, this atomic domain facilitates the selection of best driver for the device. Atomic domain C

is composed of the remaining models that represent the main functions of a selected driver.

Each atomic domain is called from the application

source code via a single command as shown in the Figure (source code section). The Figure shows arrows representing the resultant relationships between components as determined by each wrapper’s manager based on a single command’s parameters, denoted by star symbol (*), as well as the analysis of the rest of the

IDE / Compiler

API

Manager Atomic Domain

Atomic Domain

/* Source Code

*/

API

API Manager

Manager

Future Atomic Domains

Atomic Domain

Reuse Framework

W

P

P

Wrapper Preprocessor

A module

B module C module

D module E module F module

G module H module I module

J module K module

L module

A_Domain C

A Domain B

/* Source Code */

Single_Command_A(*) A_Domain A

Unused module (typical)

Single_Command_B(*)

Single_Command_C(*)

Wrapper Manager

……

…

Wrapper Preprocessor call

Figure 2. Component-level reusability with general-model reuse framework


Table 1. PCMCIA card driver reusable components Module

(Figure-2) Wireless PCMCIA card driver

modules A init_module() B add_drivers()

C register_device_driver() D wvlan_attach() E wvlan_event() F wviso_hw_lock() G wvlan_open() H wvlan_config() I wvlan_hw_config() J wvlan_release() K wvlan_detach() L Clean_module()

source code, denoted by‘…’. The arrows can be function call, dependency, control, data flow, etc. It should be noted that a complete solution would base real component similarities and relations. Thus the atomic domain, into which each component belongs, is determined by thorough domain analysis, a crucial steps in domain engineering.

To successfully create device drivers using CBSE,

the authors contend that a broad component library is required. The authors also indicated that modules F, H and I had required reconfiguration. This is typical of source code reuse and can represent a significant amount of implementation and testing time. Therefore, the use of atomic domains could minimize the difficulty in managing and implementing such a library not only by grouping related components but also by controlling component selection and reconfiguration as determined by domain analysis of past use of such components. The authors hinted the possible atomic domain categories including Driver interface functions, OS dependent functions, Card/System bridge functions, and Device dependent functions. Table 2 shows these categories.

Although Figure 2 shows three atomic domains, it is

possible to group modules D and K into a fourth atomic domain representing Card/System bridge functions category. The authors also provide a list of characteristics, along with some variations of each including examples, which could provide a starting point for constructing the source code search, selection, and insertion trees that form the basis of each atomic domain wrapper’s manager. These characteristics include: • Data-Transfer mode (Character / Block) • Access method (Sequential / Random) • Transfer schedule (Synchronous / Asynchronous) • Sharing (Dedicated / Sharable) • Device speed (Latency / Seek time / Transfer rate /

Delay between operations)

• I/O direction (Read only / Write only / Read-Write)

Table 2. Categories of reusable components Driver Module Name Category

init_module() Interface function add_drivers()

register_device_driver() OS dependent

function wvlan_attach() wvlan_event()

wviso_hw_lock() wvlan_open()

wvlan_config() wvlan_hw_config()

wvlan_release() wvlan_detach() Clean_module()

Device dependent functions

Past use of prospective components for an atomic

domain must be well understood if not logically deduced and tested before they can be made a viable tool in CBSE. If characteristics are considered incomplete or the too complex, defaults can be assigned or temporary control handed over to the programmer for input into the proper component selection (effectively similar to a typical software installation).

The authors indicate a lack of CBSE in the area of

device drivers and embedded systems in general. Nonetheless, device drivers are prime candidate for CBSE with the application of atomic domains because the software characteristics of device drivers are well defined, as they must match an equally well-defined set of hardware standards. Also, it is a growing industry with years of past source code, which could be analyzed, much of it progressing less radically than in other software sectors. In addition, the source code would be shorter compared to the typical application making the domain analysis that elicits similar and related components not only shorter but possibly simpler, lending itself to the application of atomic domains.

3. Building Product Populations with

Software Components

This scenario is that of building product populations with software components [9]. It is based around the use of a CBSE tool called Koala, built in-house at Phillips, a producer of consumer electronics. The tool is used to set up product line architecture for their products in 1998 and has since been used in real production for some of their embedded software. Figures 3 and 4, respectively, show a generic Koala component and Koala’s basic forms of binding one component to another. In Figure 3, a single typical Koala component has two interfaces called ‘requires’ and ‘provides’. The requires interface is an input while the provides interface is an output. New


components can be created from code or by connecting one or more components using fundamental connections illustrated in Figure 4.

Features not shown include ‘notification’ interfaces used in asynchronous callbacks, ‘diversity’ interfaces used to handle the many possible component uses as well as higher-level component connections such as ‘decoupling’ notifications used in multithreading. With these Koala assets on top of the standard C language, programmers can create numerous embedded applications. It must be noted that with the use of Koala, programmers must design by component composition rather than by decomposition from the overall system specifications, accepted software engineering practice.

Koala is a C compiler written in C++ (13 KLOC) that can accomplish both early and late binding as well as the simplification of Koala expressions, a subset of C. All component definitions and interface definitions are located in a repository, whose structure is based on

‘packages.’ A single package is illustrated in Figure 5. While a number of implementation details concerning compound components, testing, and approaches to reuse are not discussed in this paper, the main features of Koala can be mapped to their atomic domain model equivalents as shown in Table 3.

Table 3. Mapping of Koala features to Atomic Domain model equivalents

Koala Feature

Atomic Domain Model Equivalent

Component definition

Component (Atomic unit)

Interface definition

Incorporated in Wrapper Manager

ADL

Single command call to wrapper manager

Package Atomic Domain(s) Product population Application domain

Koala compiler General Model compiler

There are some unapparent differences in Table 3 between Koala and the atomic domains model, most notably in terms of the limits of use. Table 4 highlights the differences in terms of generic CBSE concepts, relative to the end programmer since implementing reuse is ultimately the programmer’s burden. It’s debatable whether or not the extensive efforts into creating an atomic domain outweigh the burden required to design by composition. The author claims that Koala can be taught to new programmers in only a day. However, the implementation of Koala had required a shift in development processes as well as changes in the organization. This compares to the general model that is designed not to introduce new programming paradigms but to reduce similar and related source code components to a single command (atomic domain). While Koala is a reuse framework by definition, the

p:I1 q:I2

r:I3 s:I4

Koala Component m

Interface (provides) Type

Interface (requires)

Instance name

Figure 3. A Koala component [9], the basic Building block for component design

Basic Forms of Binding

Straight Connection Switch

Glue Module

Figure 4. Koala’s basic forms of binding [9], the fundamental connections between components

Component Definitions

Private

Repository Interface

Definitions

Public

Figure 5. Koala component and interface repository [9], the concept of a single package


application of the atomic domain model may partially be enabled to enhance Koala’s capabilities by the exploitation of diverse interfaces in light of past component and interface use by Koala programmers.

Table 4. Differences in limits of use between Koala and atomic domain model in terms of CBSE concepts CBSE

Concept Koala Limits

General Model Limits

Component Selectable by programmer at compile time (compiler directive) or runtime (dynamic)

Selectable by atomic domain wrapper’s manager source code analysis at compile time (static) or runtime (dynamic)

API Constrained to a defined Interface (Never changes)

Determined by atomic domain wrapper’s manager at compile time (static)

Implement. Language

Koala ADL and expressions

Single command per atomic domain wrapper (processed by the wrapper’s manager)

Application Subset(s) of repository (packages)

Reference to one or more atomic domains (similar to add-ins)

Approach Start at component level (composition)

Start at system specifications level (decomposition)

Domain Repository (product population)

Sum of all atomic domains

Compiler Koala compiles C and Koala expressions

Commercial C/C++ compiler integrated with WPP and menu

4. Enhancing Design Reusability by

Clustering Specifications

This scenario focuses on enhancing design reusability by clustering specifications [10]. This is one of the few cases studied where emphasis is placed on reuse of existing software systems in terms of code fragments. This is a scenario of a methodology into component categorization by conducting ‘cluster’ analysis for the purpose of better reusability. For the analysis, the authors define a cluster as a group of objects that are “more homogeneous” compared to other groups, where an object is “anything that could be represented as a point in a multi-dimensional measurement space.” This measurement space allows representation, and thus analysis, of the objects by using distance functions to reduce component categorization

to a simple task of comparing numbers. Although this is a prerequisite for the atomic domain model, it is not part of the general-model framework itself. Still, the authors provide an appropriate reuse model, which illustrates what a wrapper’s manager is tasked to accomplish.

In Figure 6, the application of the atomic domain methodology is seen as the addition of underlined phrases and dashed outlines depicting the IDE boundaries (outer), the WPP / single wrapper, and its atomic domain (inner). The full domain analysis would likely elicit numerous atomic domains. It should be noted that the terms “cluster” and “object” are analogous to the terms “atomic domain” and “component”, respectively.

Barring domain analysis, the application of the atomic domains could further enhance reuse by not only capturing but also automating the manual tasks of engineering, querying, mapping, component selection, and component integration. With atomic domains, these tasks become part of the wrapper’s manager. In addition, because a single command represents an entire atomic domain, it would relax the efforts required for the programmer to incorporate exacting component reuse. The main features of the clustering specifications approach can be mapped to their atomic domain methodology equivalents as shown in Table 5.

5. Conclusion and Future Work

Reusable Components

Requirement engineering

reverse engineering mapping

query requests

integrating

Wrapper Manager

(operations)

Source code with Wrapper Single

command (before)

Wrapper

Component selected and full

compile (after)

Atomic Domain

Compiler / IDE

Domain Analysis of Existing Software

Specification Library

Requirement Specifications

New System Target Software

WPP (call)

Figure 6. Clustering specifications in software reuse with application of one atomic domain


As illustrated in the discussion of selected scenarios, the purpose of the Atomic Domain methodology is to reuse components within an application domain not only more efficiently but also more intelligently, lessening the programmer’s requirements to differentiate calls to specific components. Instead, the wrapper’s manager of an atomic domain selects the specific component out of a group of similar and related components based on past use (knowledge obtained through domain engineering). This posteriori approach to CBSE implies both an adequate domain analysis of ample source code as well as the ability to create logical search and selection and insertion trees that the wrapper’s manager makes use of.

Table-5. Mapping of Clustering Specifications features to Atomic Domain equivalents.

Clustering Specifications Approach Atomic Domain Model

Equivalent

Domain Analysis Taxonomy Description Requirement Specifications Taxonomy Description Requirement Engineering Taxonomy Description Reusable Components Atomic Domain Specification Library API Integration to Target Manager Operation Query Request Manager Operation Mapping Manager Operation Reverse Engineering Manager Operation The whole flow inside the wrapper. Control Mechanism

Other mappings Existing Software Existing System

New System Source code with a single wrapper command

Target Software Selected components with full compile

A desired goal for CBSE may tie to a seemingly

unrelated potential paradigm shift where programming environments, IDEs, and their compilers are more intelligent and can learn what programmers intend to do. This goal has far reaching implications. The Atomic Domain methodology is viewed as a step in that direction. In fact, work has been underway [12] to create a programming environment where “everyone is a programmer”, and other commercial diagrammatical programming environments requiring little to no coding such as Tridium [13] and LabView [14]. The beta of such an intelligent tool that anyone can use is said to be less than a decade away.

Research continues in this area of more intelligent CBSE implementation within specific domains. A prototype of a Wrapper PreProcessor and wrapper integration system has been implemented using a C/C++ compiler’s source code (commercial turned open-source). The task of extending the prototype to a

working model is a significant undertaking with the requirement of testing and reverse engineering of significant amount of source code. Given adequate resources, the success of the prototype model from prior work proves that such a task can indeed be successful.

7. References [1] Vugranam C. Sreedhar. “Mixin’Up Components”,

Proceedings of ICSE’07, Orlando, FL, May 2002, pp. 198-207.

[2] Jiang Guo and Yuehong Liao. “Integrating Software Components through Wrapper Technologies.” Proceedings of IASTED International Conference, Software Engineering and Applications, Marina Del Rey, CA, November 2003, pp. 441-446.

[3] Rodrigo E. Caballero and Steven A. Demurjian. “Towards the Formalization of a Reusability Framework for Refactoring”. ICSR-7, pp. 293-308.

[4] Colin Atkinson and Dirk Muthig. “Enhancing Component Reusability through Product Line Technology”, ICSR-7, 2002, pp. 93-108.

[5] Rob van Ommering. “Building Product Populations with Software Components”, Proceedings of ICSE’02, Orlando, FL, May 2002, pp. 255-265.

[6] Hisham Haddad and Ying Xie. “Wrapper-Based Framework for Domain-Specific Software Reuse”, Journal of Information Science and Engineering (JISE), Institute of Information Science, Academia Sinica, Taiwan, Editors: Sung Shin, Stefan Gruner, and Tei-Wei Kuo, March 2006, Vol. 22, No. 2, pp. 269-282.

[7] Hisham Haddad and Walter Fortner. “A Wrapper Pre-Processor for Implementing Domain-Specific Reusable Components”, Proceedings of the International Conference on Software Engineering Research and Practice (SERP 2004), Las Vegas, NV, June 2004, pp. 748-752.

[8] Andy Ju An Wang and Jorge L. Diaz-Herrera. “Device Drivers as Reusable Components”, Proceedings of IASTED International Conference, Software Engineering and Applications, Marina Del Rey, CA, November 2003, pp. 396-401.

[9] Rob van Ommering. “Building Product Populations with Software Components”, Proceedings of ICSE’02, Orlando, FL, May 2002, pp. 255-265.

[10] Youwen Ouyang and Doris L. Carver. “Enhancing Design Reusability by Clustering Specifications”, ACM, 0-89791-820-7 96 0002, 1996, pp. 493-499.

[11] Ronald Owens. “Development and Implementation of a Domain-Specific Reuse Plan”, ACM, 0-89791-609-3/93/0006-31, 1993, pp. 31-42.

[12] Claire Tristram. “Everyone’s a Programmer”, Technology Review, November 2003, pp. 34 - 41.

[13] http://www.tridium.com/products/niagara.asp cited September 2006.

[14] http://www.ni.com/labview/ cited September 2006.


[ieee fourth international conference on information technology (itng'07) - las vegas, nv, usa...

Documents