micro and macro workflow variability design techniques of component

Available online at www.sciencedirect.com

www.elsevier.com/locate/infsof

Information and Software Technology 50 (2008) 259–279

Micro and macro workflow variability design techniques of component

Chul Jin Kim a, Hyun Sook Chung b, Eun Sook Cho c,*

a Architecture Group, Software Engineering Part, Digital Solution Center, Samsung Electronics Co., Ltd., 12th Floor,

Union Steel Building 890, Daechi4-dong, Gangnam-gu, Seoul 135-524, Republic of Koreab Chosun University, Department of Computer Engineering, 375 Seosuk-dong, Dong-gu, Gwangju 501-759, Republic of Korea

c Seoil College, Dept. of Software #49-3, Myeonmok-8 Dong, Jungnang-Gu, Seoul 131-702, Republic of Korea

Received 4 June 2006; received in revised form 8 January 2007; accepted 24 January 2007Available online 31 January 2007

Abstract

Components should provide variability in satisfying a variety of domains [C. Szyperski, Component Software: Beyond Object-Ori-ented Programming, Addison-Wesley, 2002.], but it is not easy to develop components which can be applied to all domains. Althoughcomponents are developed by analyzing many different requirements, developing components that satisfy all requirements is difficultsince unexpected requirements occur during the utilization of components. Hence, providing the variability of components becomesan important prerequisite for a successful component-based application development.

In this paper, we propose a variability design technique that can satisfy the business workflow requirements of many different kinds ofdomains. The technique addresses a method for designing the variability of the workflow in a more detailed method and uses an object-oriented mechanism and design patterns. One of the most important goals of this technique is to provide a practical process can be effec-tively applied in component-based application development.� 2007 Elsevier B.V. All rights reserved.

Keywords: Component variability; Micro/macro workflow; Reusability

1. Introduction

Component technology is widely accepted in both acade-mia and industry. Since object-oriented technology did notimprove software development progressively [2], componenttechnology came to its rescue. One of the main reasons forthis was that objects have limited coverage in a typical devel-opment process. Components significantly decrease the bur-den of development because they provide workflow and areoffered as functional units composed of objects. The conceptof components regards software development as an assemblyprocess which can rapidly and easily satisfy the requirementsof different domains [3]. Components provide diversity tofulfill various domain requirements using componentinterfaces [4]. However, it is not easy to design variabilityto provide diversity. Furthermore, procedural techniquesfor variability design have not been exhaustively studied.

0950-5849/$ - see front matter � 2007 Elsevier B.V. All rights reserved.

doi:10.1016/j.infsof.2007.01.001

* Corresponding author. Tel.: +822 490 7562; fax: +822 490 7398.E-mail address: [email protected] (E.S. Cho).

Accordingly, we propose a variability design technique thatcan accommodate a variety of domain requirements.

In this paper, we propose process for designing theworkflow variability of a component. The design tech-niques for workflow variability consist of techniques fordesigning variable message flows between classes withina component and between components in the complexcomponent. We propose the mediator technique ofdesign pattern for variable message flows within a com-ponent and the connector technique, which plays the roleof coordinator, for variable message flows in the complexcomponent.

The paper is organized as follows: Chapter 2 introduceshow to design variability in component based development(CBD) methodology. In chapter 3, as the core of thispaper, we propose the design technique for workflow vari-ability. Chapter 4 assesses the practicality of our techniquesthrough case studies. Chapter 5, conclusion, summarizesthe proposed variability design techniques and describesthe underlying goal of this paper.

mailto:[email protected]

260 C.J. Kim et al. / Information and Software Technology 50 (2008) 259–279

1.1. Variability

Variability is the difference between members of a prod-uct family [5] such as the difference between components,and the difference between component frameworks. Thetarget of variability may be the classes of product familiesand their operations [6,7]. In this paper, the classes of prod-uct families are operations of a component interface, oper-ations of the classes in a component, and componentswithin a component framework. Types of variabilityinclude attributes, behaviors, and workflows.

1.1.1. Attribute variability

Attribute variability is the difference between attributesthat have the same role among members of a product fam-ily. Elements of the attribute variability are the same attri-butes existing in the different classes of the same productfamily such as attributes in a component interface andattributes of classes within the same component.

1.1.2. Behavior variability

Behavior variability is the logic difference between behav-iors that process the same function among members of thesame product family. Elements of the behavior variabilityare operations among classes in the same product family[8]. In this paper, they are operations of a component inter-face and operations of classes within the same component.

1.1.3. Workflow variability

Workflow variability is the difference between messageflows that process the same function among members of thesame product family. Elements of the workflow variabilityare message flows of the operations among classes in the sameproduct family. In this paper, they are message flows of acomponent interface within the same component frameworkor message flows of the class operation within the component.

1.2. Variability realizations

Variability can be realized using the followingtechniques.

1.2.1. Parameterization

Parameterization provides the configuration of parame-ters for customizing the behaviors of components [9]. Thevariability of components can be designed with parametersthat can customize the variation points of components. Ifthe variability technique provides the variety of selectionsthrough parameters, the reusable range of components willbe extended. However, the disadvantage of this method isthe increasing size of the components as the variationpoints are extended.

1.2.2. Inheritance

Inheritance is a technique primarily used in object-ori-ented frameworks. The hot spots of object-oriented frame-works can be customized to inherit from a variable class

[10]. The variability design using inheritance defines anabstract class for variation points and also defines thesub-classes corresponding to the variants.

1.2.3. Plug-In

Plug-In is a technique that can plug components into acomponent framework to customize the behavior [11]. Acomponent framework resembles object-oriented frame-works, but object-oriented frameworks rely on inheritancewhile component frameworks rely on the interfacesbetween plug-ins and a component framework [12].

1.2.4. Connector

Using connectors is a technique to design the interac-tions among components that mediate the communicationand coordination tasks through different forms of interac-tions such as pipes, procedure calls, and event broadcast.Connectors have interfaces that define the roles of compo-nents participating in the interactions between compo-nents. They have roles such as the caller and callee rolesof an RPC connector, the reading and writing roles of apipe, and the sender and receiver roles of a message passingconnector. Thus, connectors to design the interactionsbetween components can provide a technique for designingvariability in a component framework [13].

2. Related work

2.1. KobrA method

The KobrA method was developed as part of a projectfunded by the German Federal Ministry of Educationand Research (BMBF) known as the Komponentenbasierte

Anwendungsentwicklung or KobrA project [14,15].Variabilities are characteristics that may vary from

application to application. In general, all variabilities canbe described in terms of alternatives. At a coarse-grainedlevel, one artifact can be seen as an alternative to anotherartifact. Then during application engineering, the artifactthat best matches the context of the system under develop-ment is selected. Although simple in theory, providing aneffective representation of the variabilities in a productfamily is not only critical but also problematic factors inthe success of a product line engineering project.

While KobrA method addressed the variability extrac-tion, the variability design techniques did not address.The process for variability extraction requires the detailguidance. The notation for variability in KobrA proposesto use the stereotype ‘‘ÆÆvariantææ’’ in models that includethe variability. This notation is insufficient to express avariety of variability design techniques.

2.2. FAST

FAST (family-oriented abstraction, specification, andtranslation) has been introduced to AT&T by DavidWeiss and further developed at Lucent Technologies Bell

C.J. Kim et al. / Information and Software Technology 50 (2008) 259–279 261

Laboratories. FAST is a systematic process for develop-ing a set of systems, which share a majority of commonfeatures. The purpose of FAST is to make software engi-neering process more efficient by reducing multiple works,decreasing production costs, and shortening time-to-market.

FAST uses commonality analysis (SCV analysis) [16] toidentify, formalize, and document commonalities and vari-abilities. SCV (scope, commonality, and variability) analy-sis consists of five main steps.

• Establish the scope: the collection of objects underconsideration.

• Identify the commonalities and variabilities.• Bound the variabilities by placing specific limits-such as

maximum values-on each variability.• Exploit the commonalities.• Accommodate the variabilities.

FAST considers mechanisms, such as procedures, inher-itances, and class templates for commonalities andvariabilities.

FAST addresses the commonality and the variability incommonality analysis step. In this step three mechanismsare introduced to identify commonalities and variabilities,but the detail design techniques for each mechanism arenot addressed.

2.3. FODA [17]

Feature-oriented domain analysis (FODA) is a domainanalysis method based upon identifying the prominent ordistinctive features of a class of systems.

The FODA method applies the aggregation and gener-alization primitives to capture the commonalties of theapplications in the domain in terms of abstractions. Dif-ferences between applications are captured in the refine-ments. An abstraction can usually be refined in manydifferent ways depending on the contexts in which refine-ments are made. Parameters are defined to uniquely spec-ify the context for each specific refinement. The result ofthis approach is a domain product consisting of a collec-tion of abstractions and a series of refinements of eachabstraction with parameterization. Whenever a newrefinement is made, the context in which the refinementis made must be defined in terms of parameters beforeit is incorporated into the domain products. Therefore,in the FODA method, a domain product is not the end-product; it expands and evolves through application.

FODA provides the two modeling concepts for the com-monality and the variability: abstraction and refinement.Using these concepts FODA addresses mechanisms fordesigning the commonality and the variability, but thedetailed design techniques for each mechanism are notprovided. Also, it defines only one kind of variability. Thatis, the behavior variability at the interface or functionlevel.

2.4. CoPAM (component-oriented platform architecting

method)

Software reuse processes are strongly related to non-technical aspects such as the business and the organization-al constraints. America et al. mention the case of thePhilips company, where several product families are devel-oped, ranging from consumer electronics to professionalsystems. For each of these families, a specifically tunedfamily engineering method is necessary because the busi-ness and organization constraints differ. Based on thismotivation, the component-oriented platform architectingmethod (CoPAM) family, for product family engineering,was proposed [18]. Thus, for each product family, theCoPAM approach develops a specific family engineeringmethod from the method family in a step called methodengineering. The CoPAM processes are based on severalapproaches that are described in the literature, such asPULSE, RSEB, RUP, and on authors’ experience in indus-try. The processes have two main subprocesses: platform

engineering and product engineering. Platform engineering

process develops a platform, which consists of a numberof reusable components. A product engineering processdevelops products using these platform components, add-ing new components where necessary. Both of these receiveguidance from and provide feedback to the family engi-neering process [19]. In CoPAM, there is a single familyengineering process per product family, but there can bemore than one platform or product engineering sub-pro-cesses. The family engineering process has seven steps lead-ing to the detailed component architecture for the family.The steps range from informal domain analysis to familyarchitecting and support. However, the details about howto achieve specific tasks, for example, domain analysis orfamily architecting are not presented. In addition, thisapproach only mentioned variability mechanisms, butany guidelines or design techniques for variability designof business logic or workflows are not presented.

2.5. Catalysis [20]

Catalysis was first proposed by Desmond F. D’Souza asa formalization of OMT (object modeling technique) and isa rapidly emerging methodology as a next generationapproach for component-based development with objectsand frameworks.

Catalysis defines plug-points as a mechanism to changecomponents. It also defines parts plugging in a specifiedlogic that is common in many domains. It defines withFig. 1 as a generic component and can change the genericcomponent to plug into plug-ins (modules or components)that are suitable to the requirement of the applieddomain. Plug-point is called the ‘‘Variation-Point’’ as itcan be applied variably to use the application of the spec-ified domain. In short, a generic component is a basicmodule made available before being applied to an appli-cation [5].

GenericComponent

Plug-point

Plug-ins

Fig. 1. Plug-Points and Plug-Ins.

Fig. 2. QADA method.

RequirementSpecification

SoftwareArchitecture

QA-optimizingSolutions

EstimateQuality

Attribute

ArchitectureDecisions

Functionality-basedArchitecture Design

OK

Not OK

• User/Customer• Technological Development• Marketing Department

Fig. 3. QASAR method.


The variability techniques of Catalysis use the object-oriented mechanism and the component framework, tem-plates, inheritance, polymorphism, composition, and con-nectors. The kind of addressed variability in Catalysis isonly a behavior that is the algorithm of a class operation.Hence, workflow variability is not addressed.

2.6. QADA (quality-driven architecture design and qualityanalysis)

This is a methodology that provides a set of methodsand techniques to develop high-quality software architec-tures for single systems and system families [19,21]. Themethodology is first of all targeted at the development ofservice architectures, and then applied in pervasive com-puting environments and other networked systems. Thismethod’s specific goal is to combine quality-drivenapproach with architecture centric approach. In terms ofproduct line aspects, this method extends from process toarchitectural aspects; the method mentions concepts ofcomponents and product line, but specific guidelines arenot presented. Furthermore, variability design techniquesare not considered. The method focuses on requirementengineering and architecture design.

2.7. QASAR (quality attribute-oriented software

architecture)

Quality attribute-oriented software architecture designmethod (QASAR) is a method for software architecturedesign that employs explicit assessment of and design forthe quality requirements of a software system [22]. Thearchitecture design process depicted in Fig. 1 can be viewedas a function that transforms a requirement specification toan architectural design. The requirements are collectedfrom the stakeholders; the users, customers, technologicaldevelopments and the marketing departments. Thesegroups often provide conflicting requirements and haveto agree on a specific set of requirements before the designprocess can start Figs. 2 and 3.

The design process starts with a design of the softwarearchitecture based on the functional requirements.Although software engineers will not design an unreliable

or poorly-performing system on purpose, most nonfunc-tional requirements are, typically, not explicitly defined atthis stage. When applying architecture design solutions,one or more quality attributes are improved in generalwhereas other attributes may be negatively affected. Anew architectural design is created by applying one or morearchitectural design solutions. The design is evaluatedagain and the process is repeated, if necessary, until allnon-functional requirements have been satisfied as muchas possible.

This method provides architecture’s design and qualityattributes systematically. However, items related withvariability are not fully considered; detailed design tech-niques of behavior variability or workflow variability donot exist.


2.8. Research of Michalis and Cristina

This paper addresses the issue of handling product linevariability at the implementation level. This paper’s pur-pose it not to impart profound insights into the technolo-gies, but only to report on the possibilities of their usefor handling code variabilities in a product line. This paperproposes various approaches for coding variabilities suchas aggregation/delegation, inheritance, parameterization,overloading, (Delphi) properties, dynamic class loading,dynamic link libraries, conditional compilation, and soon [23].

This research addressed the several technologies forimplementing variability at the code level, but does notpropose the techniques for designing variability. Also, asthe mentioned approaches are not completed, it mustuse to assemble them. This paper does not distinguish thekind of variability such as attributes, behaviors, andworkflows.

2.9. Research of Dirk and Thomas

‘‘Generic Implementation of Product Line Component’’of Dirk and Thomas proposes a process for implementinggeneric product line components and gives an overview ofvariability mechanisms at the implementation level [24].

Goals of variability mechanisms in this paper are tominimize code duplication and reuse and maintain effort.Variability can be classified into the three types: optional(XOR) and alternative variabilities, and variabilities offer-ing multiple coexisting possibilities (OR). The mechanismsfor controlling behavioral variabilities are conditional com-pilation, polymorphism, defaults and refinements.

The technique proposes the design mechanisms ofbehavior variability, such as conditional compilation, poly-morphism, defaults and refinements. However, it only pro-vides the design mechanisms, not the process in the designlevel. Also, this paper did not propose attribute and work-flow variability techniques.

2.10. Workflow variability design techniques [25]

Workflow variability is designed within the componentarchitecture using only the provided interface of compo-nents. Connector manages a semantic (configuration) ofworkflow and the semantic is used to call service of compo-nents when applications are developed or customized ser-vices. Generally, the semantic can be configured usingXML.

Workflow variability design process consists of steps todesign the connection contract, workflow and dataflow.

– Define Connection Contract. This step defines the con-nection contract that works as the interaction standardamong components. The connection contract definesthe three contracts for operations of the provided inter-face consisting of the workflow.

– Define Workflow. This step designs the workflowthrough mapping among the connection contracts. Themapping among contracts is accomplished only betweentwo operations because workflow is the flow of sequen-tial operation.

– Define Dataflow. Dataflow means that connecting oper-ations which provide data to input parameters withinone operation. These data connection makes a dynamicdependency among components.

3. Workflow variability design techniques

The workflow is classified into the (1) micro workflow,the message flow among objects within a component, andthe (2) macro workflow, the message flow between compo-nents within a component framework. The variability ofthe workflow is designed during the development of a com-ponent or component framework. The workflow variabilitydesign may be further customized according to the specifi-cation of the micro workflow for an internal component.The workflow based on a component framework may befurther customized according to the specification of themacro workflow. We propose the variability design andcustomization techniques for the workflow of the internaland external components in the following sections.

3.1. Micro workflow variability design

The variability design of the micro workflow uses theselection and plug-in techniques. This variability designtechnique provides the same basic workflow as the selec-tion technique. It can also provide a variety of workflowswithin the basic workflows.

As shown in Fig. 4, in case the workflow ‘‘O1 fi O2 fiO3’’ is designed as the variation point, the concrete work-flow can be made available by selecting one of the variants,such as ‘‘Ox’’, ‘‘Ox’’, and ‘‘Ox’’.

Contrary to the selection technique, variability designtechnique can plug in the new variant of the workflow out-side a component or can select one among the variantsalready designed within the component.

The variability design process of the micro workflow isshown in Fig. 5. This process is similar to that of the behav-ior variability design. However, there is a difference in thatthe micro workflow design process addresses the steps fordesigning several variation points, which is due to the pos-sibility of the workflow having several variation points.The process consists of defining a delegation class, realizingvariation points, defining the manager for variants anddefining a required interface.

The design steps of the micro workflow are as follows.

3.1.1. Defining delegation classes for variation pointsThis step defines the delegation classes for the variation

points of the micro workflow. Each delegation class defines

PP

RR<<Object>>

O1<<Object>>

O1

Component

<<Object>>

O3<<Object>>

O3

<<Object>>

O2<<Object>>

O2

<<Object>>

O4<<Object>>

O4

Application

<<Concrete>>Ox

<<Abstract>>AOx

<<Concrete>>Ox’

<<Concrete>>Ox”

Variation Points

Fig. 4. Micro workflow variability design (Selection and Plug-In).

DefineDelegation Classes

RealizeVariation Points

DefineManager forVariants

DefineRequired InterfaceDefineRequired Interface

Fig. 5. Micro workflow variability design process.


the abstract classes or the interfaces containing abstractoperations for the variable workflows.

The provided interfaces of the component or the classeswithin the component invoke the workflows containing thevariability. As shown in Fig. 6, the provided interface andclass ‘‘O3’’ depend on the abstract class ‘‘AO1’’, which isone of the delegation classes. Classes depending on the var-iation points are not affected when the variants are modi-fied because they are subsumed by the delegation classesof the variation points.

PP

RR

<<Component>>

Micro Workflow

<<Abstract>>AO1

<<Concrete>>O1

Depend

<<Concrete>>O1’

<<ConcrO1”

<<ConcrO2

Fig. 6. Delegation class

3.1.2. Realizing variation pointsVariants are implemented to inherit from the variation

points of the workflow. When implemented, the abstractoperation of the delegation class invokes the other varia-tion point within the workflow. All variation points withina workflow are designed in this way. The plug-in techniqueis similar to the selection technique in selecting a requiredone among multiple permissible workflows. However, theplug-in technique is much more flexible than the selectionsince it can plug in a new variant outside a component.

3.1.3. Defining the manager for variants

This step defines a factory class to manage the variantsfor variation points. Managing variants is selecting oneamong multiple variants for the variation points existingwithin a component and plugging a new variant conform-ing to the specification of the variation point outside of thecomponent.

As shown in Fig. 7, the ‘‘Factory’’ class selects the vari-ants ‘‘O1’’ and ‘‘O2’’ for the variation points ‘‘AO1’’ and

ete>>

<<Abstract>>AO2

ete>> <<Concrete>>O2’

<<Concrete>>O2”

O3

Depend

of variation points.


‘‘AO2’’ within the component, and plugs the variant ‘‘O3’’for the variation point ‘‘AO3’’ when the application usesthe component.

The factory class provides functions which can select orplug in a variant of the variation points. It selects the classof the variant through the class name or the service name.In addition, the factory class plugs in a concrete class inher-ited from the delegation class of the variation point outsidethe component.

3.1.4. Defining a required interface

This step defines a required interface for selecting orplugging in the variants of a workflow. The required inter-face must be designed to handle multiple configurations forone workflow because the workflow has multiple variation

PP

RR

Component

Application

<<Abstract>>AO1

<<Concrete>>O1

Select

Plug-In

Select

<<Concrete>>O1’

<<Concrete>>O1”

<<AbstAO

<<Concrete>>O2

<<ConcO2

Factory

Fig. 7. Micro workflow variability

PP

RR

Component

Application

<<Abstract>>AO1

<<Concrete>>O1

Select

Plug-In

Select

<<Concrete>>O1’

<<Concrete>>O1”

<<AbstrAO

<<Concrete>>O2

<<ConcO2

Factory

O1O2O3” DB or XML

Fig. 8. Required interface

points. The configuration for the workflow is defined interms of the collection type. Fig. 8 represents selecting classof component or plugging class in component forcustomization.

As shown in Fig. 8, the multiple variation points are‘‘AO1’’, ‘‘AO2’’, and ‘‘AO3’’ and the configurations foreach are ‘‘O1’’, ‘‘O2’’, and ‘‘O3’’. Analogous to this exam-ple, the configurations of multiple variation points are per-sistently saved in a component by the required interface.When the provided interface invokes the workflow, the fac-tory class loads configurations.

3.1.5. Customizing a micro workflow

The customization of the micro workflow modifies aworkflow through the configurations for multiple variation

ract>>2

rete>>’

<<Concrete>>O2”

<<Abstract>>AO3

<<Concrete>>O3

<<Concrete>>O3’

<<Concrete>>O3”

design (Selection and Plug-In).

act>>2

rete>>’

<<Concrete>>O2”

<<Abstract>>AO3

<<Concrete>>O3

<<Concrete>>O3’

<<Concrete>>O3”

for variation points.


points. A newly entered configuration replaces the previ-ously configured variants with new variants, and an accom-panying factory class provides the workflow, which iscustomized by the configuration, to an interface. Theparameters of the required interface consist of the classnames for the selection, or the classes for the plug-in.

As shown in Fig. 9, the configuration values are the classnames of the ‘‘String’’ type for selecting a variant classinside the component and the object type for plugging inthe variant class outside the component. These configura-tion values are entered through the required interface.The factory class sequentially reconfigures the workflowusing its configuration when the provided interface invokesthe workflow.

3.2. Macro workflow variability design

The macro workflow means a flow as the result of theinvocation between components within a componentframework, so its variability is designed through a connec-tor which delegates the invocation between components.The motivation for defining a connector between compo-nents is to decrease the coupling between components sothat the components are not affected by the modification

Component Framework

<<Connec

T1<<Component>>

C1<<Component>>

C1PPRR

C2 c2;

delegat{

c2.f2(}

f1(){

…. T_IF. delegate();

}

// T_IF is the interface of T1 and T2.

<<Connect

T2C3 c3;

delegat{

c3.f3(}

Application

Fig. 10. Conceptual view of mac

Object Instance

StringStringType

Plug-InSelectionSelectionTechnique

…O3”O2O1Configuration

Value

Collection

Fig. 9. Configuration values.

of the related components. Fig. 10 represents using connec-tor among components for macro workflow customization.The connector can be changed for replacing the servicecomponent.

As shown in Fig. 10, in case the component ‘‘C1’’invokes other components within a component framework,the component ‘‘C1’’ invokes the component ‘‘C2’’ notdirectly, but through the connector ‘‘T1’’. When a newrequirement stating that the component ‘‘C1’’ invokes themethod of the component ‘‘C3’’ is added, the workflowcan be customized by defining a new connector ‘‘T2’’ thatconforms to the same interface as the connector ‘‘T1’’.

The variability design process of the macro workflowconsists of designing a connector and component as shownin Fig. 11. It also specifies steps to define a connector forlinking one component to the other, and the delegationclass of the connector. The component design consists ofthe steps for registering a connector to allow the invocationof the components and defining the connection event inorder for the components to be able to invoke the behaviorof the connector.

The detailed steps for designing the macro workflowvariability are as follows.

<<Component>>

C2<<Component>>

C2PPRR

tor>>

e()

);

f2(){

….}

<<Component>>

C3<<Component>>

C3PPRR

or>>

e()

);

f3(){

….}

ro workflow customization.

Define Delegation Class

Define Connectors( Component Registration )

Register Connectors(Define Required Interfaces)

Define Connection Events

Design Connector Design Component(Input-Role of Connector)

Fig. 11. Macro workflow variability design process.

Component Framework

<<Component>>

C2<<Component>>

C2PPRR

<<Connector>>

T1

<<Component>>

C1<<Component>>

C1PPRR

Delegate

<<Interface>>

T_IF

Refer

Fig. 12. Delegation class design.


3.2.1. Defining the delegation classes of connectors

This step defines the delegation class of a connector tomake the input component invoke the behavior of the out-put component. As shown in Fig. 12, the connector isresponsible for a mediator between the required compo-nent and the provided component.

The connector also defines its operations to be delegatedto the provided interface of the registered component. Thedelegation operation of the connector (‘T1.delegate’) isdefined according to the specification of the input compo-nent ‘‘C1’’. Inversely, the specification of the input compo-nent may be defined in accordance with the interface of theconnector when the registering component is developed.

The delegation of the connector sets limits to the behav-ior of the registered components. In case multiple compo-nents are registered, the connector as a hub propagatesan event to the registered components.

3.2.2. Defining connectors

A connector connects the caller component ‘‘C1’’ to thecallee component ‘‘C2’’ and delegates the behavior of thecallee component to the caller component. The component‘‘C2’’ should be registered in the connector ‘‘T1’’ to make itdelegate the behavior of the component ‘‘C2’’.

The type of a component to be registered to a connectoris determined by its navigability. If the navigability is uni-directional, the component corresponding to the output ofthe connector should be registered. And, in case the naviga-bility is bi-directional, both components linking to the con-nector should be registered.

3.2.3. Registering connectorsThis step designs components for connecting to a con-

nector after the design of the connector is completed. The

component ‘‘C1’’ corresponds to the input of a connector.If the navigability is bi-directional, the components have tobe registered to the connector. As shown in Fig. 13, Con-nector Manager can register connector and replace compo-nent through replacing another connector.

As shown in Fig. 13, the component ‘‘C1’’ registers theconnector ‘‘T1’’ through a required interface for connect-ing to the component ‘‘C2’’. The configuration of the con-nector registered through the required interface is managedpersistently within a component framework.

The component framework must have a connector man-ager for registering a connector. The connector managerhas a method to register a connector (called a connectionlistener) to a component.

The code snippet above shows that the connector managerregisters the connector ‘‘T1’’ to the component ‘‘C1’’.

The component registering a connector defines registra-tion operations that have connector interfaces (‘‘T_IF’’) astheir parameters. This interface is referred to as the specifi-cation of a component.

As shown in Fig. 14, the required interface of the compo-nent ‘‘C1’’ defines the interface ‘‘T_IF’’ of the connector asits parameter. So, the component ‘‘C1’’ can be replaced withone of several connectors conforming to the interface ‘‘T_IF’’.

3.2.4. Defining connection events

For a connection event between components, the callercomponent should define the required method of a regis-tered connector (connection listener).

Component Framework

<<Component>>

C2<<Component>>

C2PPRR

<<Connector>>

T1

<<Component>>

C1<<Component>>

C1PPRR

Register T1ConnectorManager

<<Interface>>

T_IF

T1

DB or XML

Fig. 13. Connector registration design.

<<Connector>>

T1…

delegate()

<<Component>>

C1<<Component>>

C1

PP

RR

addConnectionLister (T_IF)

ConnectorManager

<<Interface>>

T_IF

T_IF.delegate()

Register T1

Fig. 14. Conceptual view of connector registration.


When the delegation operation defined in the compo-nent ‘‘C1’’ is invoked, the component ‘‘C1’’ notifies theevents to the connector ‘‘T1’’ as shown in Fig. 15. The codesnippet below shows that the operation ‘‘f1’’ for notifyingan event includes the delegation operation of a connector.The delegation operation ‘‘delegate()’’ of the connectorinvokes the operation of the component ‘‘C2’’.

Component Framework

<<Connecto

T1

<<Component>>

C1<<Component>>

C1PPRR

Notify Event

Fig. 15. Notifica

3.2.5. Customizing a macro workflow

The macro workflow is customized through replacing aconnected component or changing the component inter-face. The component connected to a connector can bereplaced by other components existing within a componentframework. In addition, a new component may be added tothe component framework as a replacement. The change ofan interface means that an existing interface is replaced byanother interface of the same component.

As shown in Fig. 16, the component framework designsa workflow to dynamically modify the connector currentlybeing used when the components ‘‘C1’’ and ‘‘C2’’ of the

<<Component>>

C2<<Component>>

C2PPRR

r>>

tion design.


workflow are used in an application. The components‘‘C1’’ and ‘‘C2’’ are connected to each other through theconnector ‘‘T1’’ configured by a connector managerFig. 17.

When the component ‘‘C1’’ requires using the method ofthe component ‘‘C2’’ instead of the component ‘‘C3’’, themodification procedure is as follows.

• Define a new connector ‘‘T2’’. The new connectorshould be defined using the same interface like the con-nector registered in the component ‘‘C1’’.

• Register the replacing component ‘‘C3’’ in the connector‘‘T2’’.

• Define a delegation operation invoking the behavior ofthe component ‘‘C3’’, newly registered in the connector‘‘T2’’.

• Register a new connector ‘‘T2’’ in the required interfaceof the component ‘‘C1’’ through the connector manager.C1.addConnectionListener(T2).

4. Case study

In this chapter, we evaluate the practicality of our vari-ability design techniques through case studies. We use therequest for quotation (RFQ) system as the domain of ourcase study. RFQ is a procurement system that requests aquote from suppliers in order for a buyer to purchase prod-ucts. In this paper, we only cover the case of a quotationrequest including the process of the resulting supplier selec-tion after requesting the quotation.

The component framework for requesting quotationsconsists of the four components: the RFQ component pro-viding the main logic for requesting quotations, the CMS(catalog management system) component managing acatalogs for products, the UM (user management) compo-nent managing the user information, and the Mail compo-nent submitting quotations to suppliers via electronicmails.

<<Component>>

C1<<Component>>

C1PPRR

Register T2

ConnecManag

<<Connec

T1

<<Interfa

T_IF

Component FrameworkApplication

Fig. 16. Component r

Fig. 18 shows the structure of classes within the RFQcomponent consisting of the three classes: (1) ‘‘RFQ’’ classencapsulating the header information of a quotationrequester, (2) ‘‘Item’’ class encapsulating the informationof the requested products, and (3) ‘‘Supplier’’ class encap-sulating the supplier information for the requested quota-tion. The ‘‘RFQ_Pv_Inf’’ class is provided as theinterface of the RFQ component.

4.1. Workflow variability design

In this section, we study the practicality of our workflowvariability design techniques using the case studies for theworkflow variability. The workflow variability design tech-niques we use for this case study are the micro workflowand macro workflow.

4.1.1. Micro workflow variability design

We use the methods requesting quotations as our exam-ple for the micro workflow variability design. The methodsrequesting a quotation are those closing and opening RFQ.These methods are applied differently according to theirdomains.

Close RFQ is a method that requests a quotation to thespecial suppliers as shown in Fig. 19. Open RFQ is amethod that submits a quotation to all the suppliers asshown in Fig. 20.

As shown in Fig. 21, there are the variation points of the‘‘createRFQ()’’ operation for suppliers and productselections.

The variation point of the ‘‘Item’’ class is whether theproduct information is received by the CMS componentor the input system. The variation point of the ‘‘Supplier’’class is whether the user information is received by the UMcomponent or the input system.

• Define a Delegation Class For Variation PointsThis step defines a delegation class for the

‘‘RFQ_Pv_Inf’’, ‘‘Item’’, and ‘‘Supplier’’ classes, whichinclude the variation points, within the RFQ component.

<<Component>>

C2<<Component>>

C2PPRR

torer

<<Component>>

C3<<Component>>

C3PPRR

Replaceable Component

tor>>

<<Connector>>

T2

ce>>

eplication design.

RFQ Framework

CatalogManagement

System

RFQ

UserManagement

MailSystem

Fig. 17. RFQ component framework.

+ addRFQ(rfqHeader:RFQ);+ addItem(item:Item);+ addSupplier(supplier:Supplier);+ getCreatorId(rfqId:String):String+ getRequestorId(rfqId:String):String

- rfqId : String- rfqTitle : String- creatorId : String- requestorId : String- createDate : String

RFQ

+ getItem(itemId:String):Item

- itemID : String- supplierID : String

Item

+ selectSupplier(supplierId:String)+ evaluateSupplier(companyRegisterNum:String)

- supplierID : String- companyRegisterNum : String- email : String

Supplier

+ createRFQ(rfqHeader:RFQ,itemIds:String[],supplierIds:String[])

+ getCreatorInfo(rfqId:String):User

-

<<Provided Interface>>RFQ_Pv_Inf

Fig. 18. RFQ components.

Create RFQ Header

SelectItems

SelectSuppliers

SendMail

EvaluateYes

No

Fig. 19. Close RFQ.

Create RFQ Header

SelectItems

Fig. 20. Open RFQ.


‘‘createRFQ()’’ as the operation of the ‘‘RFQ_Pv_Inf’’class has a variation point for customizing the requestmethod such as close RFQ and open RFQ.

‘‘getItem()’’ as the operation of the ‘‘Item’’ class mayhave a variation point for customizing the selection methodof the products information, which uses the CMS compo-nent or input system. ‘‘selectSupplier()’’ as the operationof the ‘‘Supplier’’ class has a variation point for customiz-ing the selection method of user information which uses theUM component or input system Fig. 22.

• Realize Variation Points

This step defines variants for the delegation classes:‘‘RFQ_Pv_Inf’’, ‘‘Item’’, and ‘‘Supplier’’. As shown inFig. 23, the ‘‘createRFQ()’’ operation as the variation pointof a micro workflow is designed in ‘‘RFQ_Pv_Inf_01’’ forclose RFQ and in ‘‘RFQ_Pv_Inf_02’’ for open RFQ.

The sequence diagram of Fig. 24 represents a workflowfor close RFQ. The variant class for the delegation class‘‘RFQ_Pv_Inf_Abst’’ is the ‘‘RFQ_Pv_Inf_01’’ class,which designs the workflow for close RFQ in the ‘‘create-RFQ()’’ operation. This operation includes the ‘‘selectSup-plier()’’ operation for selecting the suppliers.

RFQ.addRFQ()

<<Provided Interface>>RFQ_Pv_Inf

RFQ.addItem()

RFQ.addSupplier()

Mail.sendMail()

Evaluate

createRFQ()RFQ

Item

Supplier

CMS

UM

VP

VP : Variation Point

VP

VP

Mail

getItem()

getSupplier()

Input

Input

Fig. 21. Variation points of micro workflow.

+ createRFQ(rfqHeader:RFQ,

itemIds;String[], supplierIds:String[])

<<Abstract>>

RFQ_Pv_Inf_Abst

Fig. 22. Delegation class of RFQ_Pv_Inf class.


The sequence diagram of Fig. 25 represents the work-flow for open RFQ. The ‘‘RFQ_Pv_Inf_02’’ class designsa workflow for open RFQ in the ‘‘createRFQ()’’ operation.This operation does not include the ‘‘selectSupplier()’’operation for selecting the suppliers.

The variants design for the variation points of ‘‘Item’’and ‘‘Supplier’’ class is done in the same way as the variantdesign of ‘‘createRFQ()’’.

• Define Manager Of Variation PointsThis step defines a manager class to manage the vari-

ants. As shown in Fig. 26, it defines the ‘‘Factory’’ classfor managing the ‘‘RFQ_Pv_Inf’’, ‘‘Item’’, and ‘‘Supplier’’

+ createRFQ(rfqHeader:R

itemIds;String[], su

<<Abstrac

RFQ_Pv_Inf

+ createRFQ(rfqHeader:RFQ,

itemIds;String[], supplierIds:String[])

<<Concrete>>

RFQ_Pv_Inf_01

+

Fig. 23. Variants of variatio

classes as the variation points. The input parameters ofeach set (or mutator) operations are defined in the delega-tion classes, which are the abstract classes, for the variationpoints. Therefore, when the variation points of a workfloware configured by a required interface, the actual inputparameters of the required interface are the sub classes,which are the variants, of the delegation class.

• Define a Required InterfaceThis step defines a required interface (‘‘RFQ_Rq_Inf’’)

to configure variants that are the sub classes of the delega-tion class (variation point).

As shown in Fig. 27, the required interface to customizethe micro workflow within the ‘‘createRFQ()’’ operationprovides two operations.

The customization operation of Code 5 can be used inthe selection method and the plug-in method for configur-

FQ,

pplierIds:String[])

t>>

_Abst

createRFQ(rfqHeader:RFQ,

itemIds;String[])

<<Concrete>>

RFQ_Pv_Inf_02

n point (RFQ_Pv_Inf).

Application

createRFQ(rfqHeader:RFQ, itemIds:String[])

: RFQ_Pv_Inf_Abst : RFQ_Pv_Inf_02 : RFQ : Item : Supplier

createRFQ(rfqHeader:RFQ, itemIds:String[])

addRFQ(rfqHeader:RFQ)

getItem(itemId:String)

Fig. 25. Behavior design of open RFQ.

Application

createRFQ(rfqHeader:RFQ, itemIds:String[], supplierIds:String[])

: RFQ_Pv_Inf_Abst : RFQ_Pv_Inf_01 : RFQ : Item : Supplier

createRFQ(rfqHeader:RFQ, itemIds:String[], supplierIds:String[])

addRFQ(rfqHeader:RFQ)

getItem(itemId:String)

selectSupplier(supplierId:String)

: Mail

sendMail(rfqHeader:RFQ)

Fig. 24. Behavior design of close RFQ.

+ setRFQ_Pv_Inf(rfq:RFQ_Pv_Inf_Abst)

+ setItem(item:Item_Abst)

+ setSupplier(supplier:Supplier_Abst)

+ setRFQ_Pv_Inf(rfqClassName:String)

+ setItem(itemClassName:String)

+ setSupplier(supplierClassName:String)

+ getRFQ_Pv_Inf()

+ getItem()

+ getSupplier()

Factory

Fig. 26. Manager class for variation points.

+ workflowCust_createRFQ_Mi(variants:Class[])

+ workflowCust_createRFQ_Mi(variants:String[])

RFQ_Rq_Inf

Fig. 27. Required interface for a variable micro workflow.


ing the variation points of the workflow. This operation isadded to the variant classes directly.

As shown in Table 1, ‘‘createRFQ()’’, which includes thevariation points of the micro workflow, is configured by theparameters whose type is ‘‘Class’’.

The customization operation of Code 6 can be used inthe selection method for configuring the variation pointsof workflow. The class names of the ‘‘String’’ type areinputted to this operation as the parameters.

As shown in Table 2, the ‘‘createRFQ()’’ including var-iation points of the micro workflow is configured by theparameters of ‘‘String’’ type. These configuration valuesare managed in XML or in a database persistently. Whenthe provided interface related with ‘‘createRFQ()’’ opera-tion is invoked, the variation points of the micro workflowwithin the operation are customized throughconfigurations.

Table 1Configuration values (class [])

Variation points for workflow 1 2 3

Configuration value RFQ_Pv_Inf_01.class Item_01.class Supplier_02.class


4.1.2. Macro workflow variability design

We use the message flows among RFQ component andother components within RFQ framework as the exampleof the macro workflow variability design. In the case ofrequesting a quotation, the workflows among RFQ compo-nent, CMS component, UM component and Mail compo-nent are designed variably.

As shown in Fig. 28, the macro workflow among com-ponents is designed to use the component interface andmust be designed to decrease the coupling amongcomponents.

• Define Delegation Class Of ConnectorsThe first step for designing the variable macro workflow

defines the delegation class of a connector. The delegationclass provides the flexible replacement of the connectedcomponents—CMS component, UM component, andMail component, with RFQ component.

Like Code 7, the delegation classes (interface) aredesigned for connecting with CMS component, UM com-ponent and Mail component. We can define a variety ofconnectors conformed the specification of these delegationclasses.

• Define ConnectorsThis step defines how a connector uses the delegation

class introduced in the previous step. The connectordecreases coupling among components and makes themeasily replaceable.

As shown in Fig. 29, the macro workflows between theRFQ component and the CMS component, between theRFQ component and the UM component, and between

Table 2Configuration values (string [])

Variation points forworkflow

1 2 3

Configuration value ‘‘RFQ_Pv_Inf_01’’ ‘‘Item_01’’ ‘‘Supplier_02’’

the RFQ component and the Mail component are imple-mented by ‘‘T1’’, ‘‘T2’’, and ‘‘T3’’ as connectors.

Like Code 8, the ‘‘T1’’ connector registers the CMScomponent, the ‘‘T2’’ connector registers the UM compo-nent, and the ‘‘T3’’ connector registers the Mail compo-nent. Each of these connectors includes an operation fordelegating the registered components such as ‘‘getItem()’’,‘‘getUser()’’, and ‘‘sendMail()’’.

• Register ConnectorsThis step also registers connectors with the RFQ com-

ponent, which is a caller component. We define a managerclass for registering the connectors. This class can registeror load the connectors.

Like Code 9, the ‘‘createRFQ()’’ operation of the RFQcomponent loads connectors such as ‘‘T1’’ ‘‘T2’’, and ‘T3’’for configuring the macro workflow. The connectors can bemanaged by the ‘‘Factory’’ class. This class uses different

RFQ Framework

Catalog Management

System

RFQ

UserManagement

MailSystem

Fig. 28. Macro workflow within RFQ component framework.

RFQ Framework

CatalogManagement

System

RFQ

UserManagement

MailSystem

<<Connector>>

T1<<Connector>>

T2<<Connector>>

T3

Fig. 29. Macro workflow using connectors.


interfaces for loading connectors. The interface type of theconnectors ‘‘t1’’, ‘‘t2’’, and ‘‘t3’’ are ‘‘T1_inf’’, ‘‘T2_inf’’,and ‘‘T3_inf’’ respectively. Thus, the ‘‘Factory’’ class canmanage a variety of connectors conforming to the differentinterface types.

• Define Connection EventsThis step defines the events to invoke the CMS compo-

nent, UM component, and Mail component that are regis-tered with the RFQ component.

Like Code 10, the ‘‘createRFQ()’’ operation defines anevent for invoking other components using the delegationclasses of connectors such as ‘‘T1_inf’’, ‘‘T2_inf’’, and‘‘T3_inf’’. Although it can be replaced with other compo-nents for changing a workflow, the basic framework ofRFQ component is not affected.

4.2. Variability measurement

This step measures the quality of a component using theproposed variability design techniques in this paper fromthe perspective of reusability.

As shown in Table 3, the measurement metrics are basedon the software quality measurement metrics of ISO 9126[26–28]. We defined understandability, changeability,replaceability, extensibility, and generality metrics as met-rics for measuring the reusability of a component.

Fig. 30 is a list of survey questions used for measuringUnderstandability of variability when components arereused. The survey consists of questions based on ISO9126 and additional questions. Each question is precededby the first character of a metric name next to a sequencenumber. The additional questions begin with ‘‘E’’. The lastdigit ‘‘1’’ or ‘‘2’’ of the sequence number system each rep-resents our technique and an existing CBD method. Also,the surveys for changeability (C), replaceability (R),

Table 3Software quality metrics of ISO 9126

Quality attribute Sub-characteristic

Suitability Accuracy Inter-operability Security

Reliability Maturity Fault tolerance RecoverabilityUsability Understandability Learnability Operability AttractivenessEfficiency Time behavior Resource utilizationMaintainability Analyzability Changeability Stability TestabilityPortability Adaptability Installability Co-existence Replaceability

<Understandability>U1.1 When the variabilit y of component is designed using this technique, can you understand this t echnique ea sily ?

Yes ( ) No ( )U1.2 When the variabilit y of component is designed using the existing method, can you understand the existing method easily ?

Yes ( ) No ( )U2.1 When the component is customized using this technique, can you understand the variab ilit y ?

Yes ( ) No ( )U2.2 When the component is customized using the existing method, can you understand the variabilit y ?

Yes ( ) No ( )U3.1 When the component is c ustomized using this technique, do e xist the required data for variabilit y ?

Yes ( ) No ( )U3.2 When the component is c ustomized using the e xisting method, do exist the req uired da ta for va riability ?

Yes ( ) No ( )EU4.1 When t he c omponent i s cu stomized using this tech nique, c an you understand i npu t an d ou tput ?

Yes ( ) No ( )EU4.2 When the component is c ustomized using the e xisting method, ca n you understand input a nd o utput ?

Yes ( ) No ( )

<Unders tandabilit y>U1.1 When the variability of component is designed using this t echnique, can you understand this technique easily ?

Yes ( ) No ( )U1.2 When the variabilit y of component is designed using the e xisting method, ca n you understand the e xisting method easily ?

Yes ( ) No ( )U2.1 When the component is customized using this technique, can you understand the variabilit y ?

Yes ( ) No ( )U2.2 When the component is customized using the existing method, can you understand the variab ilit y ?

Yes ( ) No ( )U3.1 When the component is customized using this t echnique, do e xist the required data for variab ilit y ?

Yes ( ) No ( )U3.2 When the component is customized using the e xisting method, do exist the required data for variabilit y ?

Yes ( ) No ( )EU4.1 When the component is c ustomized using this t echnique, can you understand i nput a nd o utput ?

Yes ( ) No ( )EU4.2 When the co mponent is c ustomized using the e xisting method, can you understand input a nd o utput ?

Yes ( ) No ( )

Fig. 30. Understandability survey list.

Fig. 31. Metrics measurements.


extensibility (E), and generality (G) metric are based onISO 9126. Developers of the E-Net Corporation (www.e-net.co.kr) and SAMSUNG Electronic Corporation cur-rently using CBD took part in this survey. The numberof developers who participated in our surveys is 64.

Fig. 31 show the survey results of understandability,changeability, replaceability, extensibility, and generalitymetrics for the behavior and workflow variability.

The graphs of Fig. 32a show the difference between ourtechnique and the existing method. Through these results,we can see that the reusability of a component is signifi-cantly improved when our approach is used.

Fig. 32b shows the average value of the measured resultsfrom the five metrics. The measured value closed 1 meansthat the component has high quality in the reusability pointof view. In terms of significance, if the measured value is

larger than 0.5, Null Hypothesis assumes that the reusabil-ity of a component is of high quality; if the measured valueis smaller than 0.5, Alternative Hypothesis assumes thatthe reusability of a component is not of high quality. Asthe measured results regarding our proposed techniqueare mostly larger than 0.5, the reusability of a componentusing our technique is of high quality as stated in NullHypothesis. Our technique can improve the reusabilitymore than twice that of the existing method.

5. Assessment

This chapter compares the variability design techniquesproposed in this paper with other techniques, such asKobrA, FAST, FODA, COPAM, Catalysis, QADA,QASAR, the research of Michalis and Cristina, and the

http://www.enet.co.kr

http://www.enet.co.kr

Measurement Graph of Reusability Sub Metrics Reusability Measurement Graph

Reusability Metrics

0 .076086957

0 0.010869565 0

0.130434783

0.597826087

0.391304348

0.489130435

0.630434783

0.826086957

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Understandability Changeability Replaceability Generality Extensibility

Sub Metrics

Mea

sure

d V

alue

ExistingMethod of This Paper

Significance Level : Measured Value > 0.5

Null Hypothesis : The reusability of component ishigh quality.

Alternative Hypothesis : The reusability of component isnot highquality.

0

0.1

0.2

0.3

0.4

0.5

0.6

Mea

sure

d V

alue

Workflow

ExistingMethod of This Paper

a b

Fig. 32. Comparison between our technique and the existing method.


research of Dirk and Thomas. Comparison is based on avariety of criteria that are generally considered in thesemethodologies and researches. The comparison criteriaconsist of five sorts: variability scopes, variability types[13], variability design techniques [26], applicable compo-nent types, and variability binding time.

5.1. Comparison of variability scopes

Variability scopes are the target of variability design andconsist of attributes, behaviors, and workflows within thecomponent. The behavior variability is evaluated to distin-guish the operation variability within the component andthe component interface variability. The workflow variabil-ity is evaluated to distinguish the macro workflow amongobjects within the component and micro workflow amongcomponents within the component framework. We evalu-ated the supporting area of variability in this techniqueand other methodologies and researches using these vari-ability scopes.

As shown in Table 4, the other methodologies andresearches mainly support the behavior variability design,and do not support attribute and workflow variabilitydesign. Also, only COPAM, Catalysis, QADA, andQASAR support the behavior variability of the component

Table 4Comparison of variability scopes

Variability scopes Methodologies and researches

KobrA FAST FODA CoPAM

AttributeBehavior Internal method M M

Provided interface SWorkflow Micro workflow

Macro workflow

S: supported, M: mentioned only, Blank: not supported.

interface. The proposed variability scopes of this papersupport attributes, behaviors and workflows.

5.2. Comparison of variability types

Variability types are the methods for supporting vari-ants. Generally variability types consist of Selection,Option, Alternative (Plug-In), and Multiple Selection.Selection is the variability type for selecting one amongexisting variants for the variation point. Option is the var-iability type for deciding whether or not to use the variantby mutual exclusive methods. Alternative is the variabilitytype for replacing existing variants with other variants forthe variation point. Finally, multiple selections are the var-iability type for selecting multiple variants. The evaluationfor variability types is compared with other methodologiesand researches to show how many variability types are sup-ported. If they support a variety of variability types, itmeans that they can apply in a variety of variability scoperequirements.

As shown in Table 5, most methodologies or researchesfor variability types use the alternative variability type.This paper supports selection, option, alternative, and mul-tiple selections. Selection is used to select one variant whenseveral variants are provided for the variation point of thebehavior variability. Option is used to decide whether or

Catalysis QADA QASAR Mic00 Dir03 This paper

SS M M SS M M S

SS

Table 5Comparison of variability types

Variability types Methodologies and researches

KobrA FAST FODA CoPAM Catalysis QADA QASAR Mic00 Dir03 This Paper

Selection [1] M SOptional [0..1] M M SAlternative/replace [1] S S S M M M SMultiple selection [1..n] M S



not the variant is used for attribute variability. Alternativeis used to replace the new class from outside the componentusing the plug-in technique, or the new component withinthe component framework. Multiple selections are usedto select multiple variation points of the workflow.

5.3. Comparison of variability design techniques

As shown in Table 6, the methodologies and researchesaddressed a variety of technologies that are necessary in thedesign and implementation level. These technologies areconcepts that are included within object-oriented, designpattern, and component framework. Dynamic manage-ment technologies were addressed at the implementationlevel. Several of the represented technologies are similarto each other, and were not addressed in the detail usagemethod.

Table 6 represents the useful technologies for designingvariability among the variability technologies in Table 6.The evaluation of the variability design techniques repre-sents how many support common techniques. Therefore,this evaluation can represent the supported range of vari-ability techniques.

Table 6Variability technologies

Technologies Methodologies and researches

KobrA FAST FODA CoPAM

Aggregation (delegation) SInheritance S SParameterization S SDynamic class loadingPlug-In MTemplatesOverloading (polymorphism)Dynamic class loadingStatic libraryDLL (dynamic link library)Conditional compilation SReflectionAOP (aspect-oriented prog.)ConnectorAdaptorWrapperMediatorProxyRe-implementation


As shown in Table 7, most methodologies or researchesuse the object-oriented mechanisms as the design tech-niques. In addition, Catalysis and QADA use designpatterns, such as connector, adaptor, and wrapper, asthe variability design techniques. This paper supportsmost variability design techniques except the template tech-nique. Also, we propose the connector technique fordesigning the variability between components in a compo-nent framework.

5.4. Comparison of applicable component types

Applicable component types consist of the in-housecomponent type, which can design the variability whenthe component is developed, and the COTS componenttype, which can design the variability when the applicationis developed.

As shown in Table 8, most methodologies and research-es propose variability design techniques when the compo-nent is designed. COPAM, QADA, and QASAR supportthe COTS component type for designing the variability atthe component interface level. This paper supports either

Catalysis QADA QASAR Mic00 Dir03 This paper

S M M SM M S

M M M SM

M M SM MM M M S

SMMM MMM M

M M SS

SS

Table 7Comparison of variability design techniques

Design techniques Methodologies and researches

KobrA FAST FODA CoPAM Catalysis QADA QASAR Mic00 Dir03 This paper

Aggregation (delegation) S S M SInheritance S S M S SParameterization S S M S M SPlug-In M M M STemplates M MOverloading (polymorphism) M M M SConnector M SAdaptor M SWrapper SMediator SProxy S


Table 8Comparison of applicable component types

Component types Methodologies and researches

KobrA FAST FODA CoPAM Catalysis QADA QASAR Mic00 Dir03 This paper

In-House S S S S S S S S S SCOTS (black-box) S S S S

S: supported, Blank: not supported.

Table 9Comparison of variability binding times

Binding times Methodologies and researches

KobrA FAST FODA CoPAM Catalysis QADA QASAR Mic00 Dir03 This Paper

Compile time S S S S S S S SRun time SUpdate time/post run time S

S: supported, Blank: not supported.


the in-house or COTS component type according to thevariability scopes Table 9.

5.5. Comparison of variability binding time

Binding time, the time when the designed variability isbound, consists of compile time, link time, run time, andupdate time. Compile time means that the designed vari-ability is applied to the component when it is compiled.Link time means that the designed variability is appliedto the component when the variability is connected to mod-ules or libraries. Run time means that the designed vari-ability is applied to the component while it is in use.Finally, update time means that the designed variabilityis applied to the component when it is updated. We canalso distinguish between static and dynamic binding. Staticbinding means that the designed variability is applied to thecomponent when it is compiled, and dynamic bindingmeans that the designed variability is applied to the compo-nent while it is maintained or operated.

Most methodologies supporting the in-house compo-nent type bind the variability in the compile time. This

paper supports both the in-house and COTS componenttype, and can bind the variability in the compile time orthe run time. Update time is supported because the work-flow variability of this paper can be customized while theworkflow is maintained. The existing methodologies shouldrecompile components after variability is applied to them,but this technique can apply the variability to them in therun time. The behavior variability design technique cancustomize to plug the variable behavior into the compo-nent in the run time, and the macro workflow variabilitydesign technique can dynamically customize to input theredefined workflow information (which is the connectioncontract among components) to the coordinationconnector.

6. Conclusion

This paper proposed the micro workflow variabilitydesign techniques for designing variability in the compo-nent design phase, and proposed the macro workflow var-iability design techniques for designing variability in thesoftware design phase based on components. We per-


formed an experiment to evaluate the reusability of theproposed variability design techniques. In this experiment,we grasped that the reusability of the component, whichapplies to proposed techniques, is improved. Also, we eval-uated the support degree of variability to compare othermethodologies with those of this paper in five views of var-iability. Software development paradigm has been evolvedfrom an object-oriented paradigm to CBD (component-based development), or PLE (Product Line engineering)for improving the productivity of the software develop-ment, but it has not improved the productivity of the soft-ware development innovatively. The reason is that thereusable business components have not been satisfactorilyprovided to developers. In other words, the techniquesfor developing reusable components were not provided tothem.

In this paper, we proposed practical variability designtechniques for improving the reusability of a component.It is our hope for these techniques to ultimately providethe cornerstone for improving the productivity of softwaredevelopment by developing high quality reusable compo-nents through these techniques.

In the future, we will study a technique that can supportthe interaction among components having the differentcomponent model standards, such as EJB, COM, CCM,and incorporate proposed techniques into componentdevelopment tools. Also, we will study the variabilityextraction technique in the analysis phase.

References

[1] C. Szyperski, Component Software: Beyond Object-Oriented Pro-gramming, Addison-Wesley, 2002.

[2] J. Rumbaugh et al., Object-Oriented Modeling and Design, Prentice-Hall, 1991.

[3] K. Kang, Issues in Component-Based Software Engineering, Inter-national Workshop on Component-Based Software Engineering1999.

[4] J. Hopkins, Component primer, Communication of the ACM 43 (10)(2000).

[5] Sterling Software Inc., The CBD Standard Version 2.1, SterlingSoftware, July 1998.

[6] K. Short, Component Based Development and Object Modeling,Sterling Software, Technical Handbook Version 1.0, February1997.

[7] A. Rausch, Software Evolution in COMPONENTWARE UsingRequirements/Assurances Contracts, in: Proceedings of the 22thInternational Conference on Software Engineering, June 2000.

[8] K. Bergner, A. Rausch, M. Sihling, Componentware-The Big Picture,Institut fur Informatik, Technische Universitat Munchen, http://www.sei.cmu.edu/pacc/icse98/papers/p6.html.

[9] K. Bergner, A. Rausch, M. Sihling, and A. Vilbig, AdaptationStrategies in Componentware, 2000 Australian Software EngineeringConference.

[10] W. Pree, Design Patterns for Object-Oriented Software Development,Addison-Wesley, 1995.

[11] C. Jose, Next-Generation Object-Oriented Software Analysis andDesign Methodology, at URL: http://www.hpl.hp.com/fusion/ma_961007.html, 1996.

[12] HP Company, Engineering Process Summary: Fusion 2.0, Hewlett-Packard Company, January 1998.

[13] S. Lee, Y. Yang, E. Cho, S. Kim, S. Rhew, COMO: a UML-basedcomponent development methodology, APSEC (1999) 54–61.

[14] C. Atkinson, J. Bayer, C. Bunse, E. Kamstices, O. Laitenberger, R.Laqua, D. Muthig, B. Paech, J. Wust, J. Zettel, Component-basedproduct line engineering with UML, Addison-Wesley, 2001.

[15] M. Fowler, K. Scott, UML distilled: applying the standard objectmodeling language, Addison-Wesley, 1998.

[16] D.M. Weiss, Commonality Analysis: A Systematic Process forDefining Families, Second International Workshop on Developmentand Evolution of Software Architectures for Product Families,February 1998.

[17] K.C. Kang, S.G. Cohen, W.E. Novak, and A.S. Peterson, Feature-oriented Domain Analysis (FODA) Feasibility Study, TechnicalReport CMU/SEI-90-TR-21, Software Engineering Institute (SEI),November 1990.

[18] P. America, H. Obbink, R.V. Ommering, F.V.D. Linden, CoPAM: AComponent-Oriented Platform Architecting Method Family forProduct Family Engineering, The First Software Product LineConference(SPLC), Kluwer International Series in Software Engi-neering and Computer Science, Denver, Colorado, USA, p. 15,2000.

[19] M. Matinlassi, Comparison of software product line architecturedesign methods: COPA, FAST, FORM, KobrA and QADA, in:Proceedings of the 29th International Conference on SoftwareEngineering, IEEE Computer Society, Washington Brussels Tokyo,Scotland, UK, May 26–28th 2004. pp. 127–136.

[20] D.F. D’souza, A.C. Wills, Objects, Components, and Frameworkswith UML, Addison-Wesley, 1999.

[21] Matinlassi, Mari, Niemela, Eila & Dobrica, Liliana, Quality-drivenArchitecture Design and Quality Analysis Method: A revolutionaryinitiation approach to a product line architecture, VTT publications456, VTT Technical Research Center of Finland, (URL:http://www.inf.vtt.fi/inf/pdf/), January 2002.

[22] E. Folmer, J.V. Gurp, and J. Bosch, Scenarion-Based Assessment ofSoftware Architecture Usability, in: Proceedings of Workshop onBridging the Gaps Between Software Engineering and Human-Computer Interaction, ICSE, Portland, 2003.

[23] M. Anastasopoulos, and C. Gacek, Implementing Product LineVariabilties, Technical Report IESE Report No. 089.00/E, Version1.0, Fraunhofer Institute for Experimental Software Engineering(IESE), Novermber 2000.

[24] D. Muthig, and T. Patzke, Generic Implementation of Product LineComponents, NODe 2002, LNCS 2591, pp. 313–329, 2003, Fraun-hofer Institute for Experimental Software Engineering (IESE),Novermber 2000.

[25] C. Kim, and S. Eun, A Workflow Variability Design Technique forDynamic Component Integration, AIS 2004, LNAI 3397, pp. 460–269, 2005.

[26] ISO/IEC JTC1/SC7 N2419, DTR 9126-2: Software Engineering –Product Quality Part 2 – External Metrics, 2001.

[27] S.P. Jeffrey, Measuring software reusability, IEEE Software (1994).[28] S. Kim, and J. Park, C-QM: A Practical Quality Model for

Evaluating COTS Components, IASTED, SE 2003.

http://www.sei.cmu.edu/pacc/icse98/papers/p6.html

http://www.sei.cmu.edu/pacc/icse98/papers/p6.html

http://www.hpl.hp.com/fusion/ma_961007.html

http://www.hpl.hp.com/fusion/ma_961007.html

http://www.inf.vtt.fi/inf/pdf/

http://www.inf.vtt.fi/inf/pdf/

micro and macro workflow variability design techniques of component

Documents