Feature-Oriented Modelling in BIP: A Case Study

Transcription

1 Feature-Oriented Modellg BIP: A Case Study Cecylia Bocovich Joanne Atlee University of Waterloo {cbocovic, jmatlee}@uwaterloo.ca Abstract In this paper, we vestigate the usage of Behaviour- Interaction-Priority version 2 (BIP2), a component-based modellg framework, for specifyg feature-oriented systems. We evaluate BIP2 the context of the Feature Interaction Problem and quantify the amount of work needed to add features to an existg system (i.e., terms of rework to existg features, and work to identify and specify teractions). We present the results of a case study on a telephony system with five optional features where we found that the amount of work depends heavily on how features are terconnected. We identify a number of different strategies for terconnectg features, and propose one that reduces the amount of work and rework needed to add new features to an existg system. I. INTRODUCTION In software engeerg, an creasgly popular strategy to decompose a complex system to smaller subproblems is to perform feature-based decomposition, which is a type of functional decomposition of the system. A feature is a unit of functionality that can be developed and evolved dependently. Although the practice of treatg features as separate concerns eases the task of feature development, complexities arise the tegration of features to a fal product. The composition of separately designed features often leads to unexpected or undesirable behaviours. A feature teraction occurs whenever one feature alters the behaviour of another. For example, a user may subscribe to a telephony feature that automatically forwards calls that are received when she is on the phone; she may also subscribe to a second feature that automatically screens calls agast a list of blocked numbers. If each feature is specified and developed with knowledge or consideration of the other feature, the come is not clear if both are activated the same scenario. To be safe, a developer must consider how a new feature might teract with existg features. To be thorough, all combations of existg features need to be considered, as some cases an teraction occurs only when multiple features are active at the same time. As the number of features grows, the number of feature combations that must be analyzed for possible teractions grow exponentially until the tegration of a new feature is domated by the analysis and resolution of these feature teractions. In systems with high variability, the Feature Interaction Problem becomes tractable with existg methods [1]. Many techniques and tools have been developed to address the Feature Interaction Problem by mimizg the work of the developer discoverg and resolvg feature teractions [2]. One such strategy is the use of specialized modellg languages for the design and verification of composed systems. Behaviour-Interaction-Priority version 2 (BIP2) [3], [4] is a framework for the design of component-based systems. BIP allows the designer to decompose a complex system to a collection of terconnected components, each describg orthogonal and dependently executg behaviour. A component can modify other components through explicitly defed communications and synchronizations called teractions, which may cause transitions with the affected components or updates to the values of component variables. Nondetermism and conflicts among concurrent transitions and variable assignments can be resolved usg priorities. Given that the BIP2 formalism is designed to support component-based modularity, and given that BIP2 has explicit language constructs for specifyg how feature combations ought to synchronize and how conflicts and nondetermism ought to be resolved, we set to vestigate how to use BIP2 to address the Feature Interaction Problem. We performed a case study which we use BIP2 to model a telephony system with five features. Telephony is an example of an extreme product le, with many optional features that extend the functionality of a shared basic service. Each user subscribes to a subset of available features, and establishes voice connections with one or more other users, each of who turn has subscribed to her own subset of available features. We aim to answer the followg questions our vestigation: (1) Is it possible to model features dependently and tegrate them to the system with changg existg features? (2) How much work (and rework) is required to tegrate a new feature to an existg system model? (3) How much work is required to specify teractions among features, and what is the overall complexity of the resultg system model? Is feature-oriented specification BIP2 feasible? Answers to these questions depend heavily on the design methodology used to defe component terfaces and to terconnect components. We identify three distct design methodologies for modularizg and composg features, and we evaluate the amount of developer work that is needed to tegrate new features and resolve feature teractions. Given how the term teraction is overloaded, we want to distguish between traditional feature teractions (which refer to any difference feature behaviour, tended or not, due to the presence of other features) from BIP2 teractions (which refer to explicitly specified communications and synchronizations among connected components, and are by defition designed and desired teractions). We use the acronym FIs to refer to the former and the qualified term teractions to refer to the later.

2 II. OVERVIEW OF BIP Behaviour-Interaction-Priority (BIP) is a component-based language for modellg complex systems [3]. In BIP, the behaviour of a system is modelled as a collection of dividual components, each of which is responsible for a subset of the system s behaviour. As the name suggests, BIP provides three layers of specification to the model: the Behaviour of system components, the Interactions between these components, and the Priorities between multiple possible execution paths. In this paper, we use the second iteration of this framework, BIP2 [4], and will refer to this version from this pot forward. In this section, we describe each layer of BIP2, the specification of models the BIP2 language, and how these layers are combed to form a model of a simple system. A. The Behaviour Layer Each component a BIP2 model defes a subset of a system s overall functionality. In this paper, our system consists of a base component that provides basic call-processg functionality (i.e. on-demand voice connections between two users), and a set of optional features that extend or override this functionality. The most basic BIP2 component is an atom. The ternal operation of each atom is modelled as a Petri net. A transition between places the net updates the atom s variables and the set of occupied places. Transitions may be optionally triggered by communications received through the atom s ports. An atom s current state is represented by the set of currently occupied places and the values of the atom s variables. A transition from a set of previously occupied places to a set of newly occupied places may be optionally labelled with a guard, an update function, and a port. A guard is a predicate over the atom s variables, and a transition is enabled and executed only if the system state satisfies the guard. After transitiong, the variables are updated as dictated by the update function. Ports facilitate the synchronization of components transitions, and are used the specification of the teraction layer. Figure 1 shows places and transitions from a partial atom that models the basic-call service that is, a service that allows a user to to place and answer phone calls. The places of the atom reflect the states through which a telephone call can proceed, from (i.e. waitg for a call) to CALLING, to a fully connected call. The teger variables rgs and time keep track of the number of successive rgs and the duration of the call, respectively. When a user itiates a call, her basic-call service eventually enters the CALLING state and remas there until the call is answered or until the call has rung a maximum number of times. The call transition has a guard function [rgs < maxrgs] that ensures the transition will execute only if the maximum number of rgs has not been reached; each execution of the transition crements the rgs variable through an update function {rgs++}. Note that every transition this model has an additional label that is neither a guard nor an update function. These notbusy {time++} INCALL onhook DIALTONE connectg {time := 0} CONNECT answered call [rgs < maxrgs] {rgs++} CALLING Fig. 1: Places and transitions the basic-call service component, simplified for brevity. Guard functions are given square brackets (e.g., [rgs < maxrgs]) and update functions curly brackets (e.g., {rgs + +}). labels correspond to ports and reflect the ways which other components affect the ternal state. Ports restrict transitions similar to guards; a transition labelled by a port relies on an teraction with another component to execute. We will discuss ports and teractions between components greater detail the followg section. We give the full atomic component for the basic-call service Figure 2. B. The Interaction Layer Components terface with each other through ports that are lked together by connectors. A connector lks two or more components: the effect is to synchronize transitions that are labelled with connected port names and to update variables through teractions. Each connector explicitly defes a set of ports that belong to participatg components and the set of teractions that may occur between these components. As stated the previous section, ports may label one or more transitions a component. A port is enabled when one or more of these transitions are enabled. The ports a connector may be either triggerg ports (i.e. senders) or synchronizg ports (i.e. receivers). A triggerg port, denoted by a primed port name (e.g. ), triggers transitions the connected components when it is enabled. A synchronizg port, when enabled, allows its transitions to be triggered by a triggerg port from another connected component. Each teraction a connector consists of the connector s triggerg ports and some subset of synchronizg ports. Interactions may be labelled with guard and transfer functions the same manner as component transitions. The variables these functions are the data variables exported by the components ports. Upon execution, the teraction s transfer function updates the variables participant atoms, allowg components to exchange formation. An teraction a with a set T of triggerg ports and a set S of synchronizg ports is enabled if and only if all of the followg conditions are met: (1) there is at least one enabled transition labelled by each port t T, (2) there is at least

3 notbusy onhook onhook onhook DIALTONE recvnum dialtone DIAL {num = targetnum; rgs := 0;} [rgs ==0], disconnectg answered CALLING rg [rgs < maxrgs] {rgs ++;} callend rgg WAIT FOR ONHOOK callend REMOTE DISCONN disconnected CONNECT FAILED disconnected INCOMING rgtone rgtone connectg {time := 0;} RINGING ANSWER answerg INCALL onhook disconnectg LOCAL DISCONN onhook onhook {time++;} Fig. 2: A complete basic-call service component with all ports, guards, update functions, and data variables. t rgs t targetnum t num t time t maxrgs = 3 A CALLING t mynum = 1 t tarnum = 2 call' Previous state New state call' B rggb C rggc rggb rggc t mynum = 2 t tarnum = 0\ 1 RINGING t mynum = 3 t tarnum = 0 RINGING Fig. 3: Example connector between three basic-call services, simplified for brevity. The connector allows the synchronization between the three components, transitiong a sgle execution step from the state shown green to a new state shown blue. one enabled transition labelled by each port s S, and (3) the guard on teraction a evaluates to true given the current values of all exported variables. A connector with n synchronizg ports has 2 n possible teractions. The modeller must explicitly defe guards and update functions for all possible teractions. Any teractions that she does not wish to execute may be given the guard G a : false. If more than one of a connector s teractions are enabled, the maximal teraction (i.e. the teraction with the most ports) will execute. For example, if there are two enabled teractions a connector C, and one cludes ports {t, s 1 } while the other cludes ports {t, s 3, s 4, s 5 }, the latter teraction will execute as it contas the higher number of ports. This set of implicit priority rules is also known as the maximal progress prciple. After an teraction occurs, the variables exported through the participatg ports are updated as defed by the transfer function. In this way, an enabled teraction changes the ternal state of participant components by (1) executg transitions labelled with the ports the teraction and (2) updatg the values of connected component variables. Figure 3 shows a connector among the basic-call services of three users that enables user A to place a call to user B or user C 1. The ports volved the connector are the call triggerg port from A and the rgg synchronizg ports of BSC B and C. Each ports exports two tegers: the mynum variable that stores the user s unique telephone number, and the tarn um variable that identifies the telephone number of a remote basic-call service. There are four possible teractions with this connector: {call, rggb, rggc} or {call }: Durg a normal call, user A calls the unique phone number of one other user, causg only that user s phone to rg, 1 analogous connectors are needed to enable users B and C to place calls.

4 not both. We add a guard on these teractions to prevent this teraction from occurrg: G a : false. {call, rggb} or {call, rggc}: The first teraction occurs if and only if the number that user A calls matches the phone number rggb s component: G a : call.tarnum == rggb.mynum. If this teraction is enabled, B s tarnum must be updated to reflect the fact that it is now teractg with A. This is done with the transfer function F a : rggb.tarnum := call.mynum. We use analogous guards and transfer functions for an teraction with user C. We give a full teraction model of our basic call service Figure 4. The connectors between basic-call services show the ways which users services may teract through the process of a call. Likewise, the connectors between a user component and its basic-call service model how a user may teract with the system. In this manner, the modeller can use connectors, teractions, guards, and transfer functions to control the ways which components synchronize with each other and modify each others data variables. C. Priorities To combat nondetermism and enforce schedulg policies, BIP2 provides priorities as a means to choose between multiple enabled execution paths. Nondetermism arises when there are multiple simultaneously enabled teractions, each leadg to a different overall system state. In Figure 1, when the CALLING place is occupied, all transitions leadg from CALLING are enabled. This potentially enables teractions the connectors that connect the basic-call service through the, call, and answered ports to the user component and the call-service components of other users. As discussed the previous section, BIP2 will execute the maximal enabled teraction with each connector, but if there is more than one connector, there are no guarantees ab which teraction will execute. In this case, we want the answered signal to have the highest priority; when another user answers the call, the basiccall service should progress to the CONNECT state stead of contug to call the other user s through the call port. We can control the come by specifyg priorities one of two ways: (1) at the component level by specifyg that port answered has a higher priority than port call, or (2) at the teraction level by specifyg that teractions the answered connector have priority over teractions the call connector. At the component level, we clude onhook > our specification of the basic-call service atom. At the teraction level, we denote the connector that connects onhook with the user atom as onhook connector and the connector that connects the port with other basic-call services as the connector. The priority onhook connector : > connector : dicates that all teractions onhook connector should execute before teractions connector. The simplest way to resolve all nondetermism is to defe a complete orderg on the transitions that lead from each state. Note that not all pairs of transitions with the same itial state require a priority. In the DIAL state, isn otbusy and will not be enabled simultaneously. This would require the target basic-call service to be two places at once: and one of the places that are volved a call. Our basic-call service atom requires a total of 26 priorities to resolve conflicts from simultaneously enabled teractions and avoid consistent states. We will see priorities play a large role the resolution of feature teractions Section IV. III. TELEPHONY CASE STUDY We conducted a case study on a telephony system to assess the extent to which BIP2 combats the Feature Interaction Problem by reducg the work a developer must perform when designg, composg, and resolvg teractions between features. In this section, we le the basic structure of our telephony system, the features volved, and the criteria we used to evaluate design strategies BIP2. A feature-oriented BIP2 model consists of three parts: (1) a base service (modelled as one or more atomic components), (2) a set of optional features to which a user may subscribe that extend or modify the functionality of the base service (each of which is modelled as an atomic component), and (3) the system environment (modelled as one or more atomic components). A telephony model consists of a basic-call service, a set of optional features, and a user environment. Each user has a unique phone number. A user A may dial the unique number of another user B order to itiate a call (i.e. voice connection) to user B. Each user subscribes to a basic-call service (). This service allows the user to place and receive calls; the places the component, together with its variables, reflect the possible states of an gog or comg call. The ports of the component reflect the ways which users and features may teract with or extend the functionality of the (i.e. takg the phone off the hook, or dialg a number), and the ways which the of one user teracts with the s of other users (i.e. establishg a connection). A BIP2 model is a closed-world model, meang that it cludes a representation of the system s operatg environment. The environment of a telephony system comprises the human user and each user teracts with his or her. We model a user s behaviour as an atomic component, as shown Figure 5. A user may also subscribe to one or more features. Each feature is modelled separately as an atomic component. Our telephony case study cludes five common telephony features, taken from specifications for the Feature Interaction Contest [5]: Call Forwardg (CF): The subcriber may specify a forwardg number to which all calls to the subscriber will be redirected.

5 User A ' isdialtone dialnum' connected rgtone callended dialtone' recvnum connectg' rgtone' A disconnectg' answerg' answered callend' disconnected notbusy' rgg call' ' call' answerg' notbusy' ' C dialtone' recvnum connectg rgtone' ' isdialtone dialnum' connected rgtone User C rgg call' ' disconnectg' callend' callended User B ' isdialtone dialnum' connected rgtone callended dialtone' recvnum B notbusy' disconnected answered answerg' connectg' disconnectg' rgtone' callend' disconnected answered rgg Fig. 4: Complete teraction-layer model of the basic-call service and user components for three users. callended rgtone RINGING rgtone TAKE PHONE INCALL connected isdialtone DISCONN callended DIALTONE WAIT FOR CONNECT dialnum Fig. 5: The user environment, modelled as a BIP2 component. Call Forwardg on Busy (CFB): If the subscriber receives a call when she is volved another call, the feature will redirect the new call to a predetermed forwardg number. Call Waitg (CW): If the subscriber receives a call when she is volved another call, she may choose to put the origal call on hold, answer the new call, and then between the two calls. Termatg Call Screeng (TCS): This feature allows its subscriber to specify a list of blocked numbers. Any call origatg from a number on this list will be termated automatically. Three-Way Callg (TWC): This feature allows a subscriber to add a third user to an existg call. Once threeway communication has been established, any user may chose to leave the call, resultg a traditional two-way call configuration. The BIP2 framework claims to support component-based modellg with an emphasis on ter-component teractions. The primary goal of our case study was to assess these claims the context of feature-oriented modellg and feature teractions (FIs). We evaluated BIP2 s suitability for feature-oriented systems on three ma pots: 1) The overall complexity of a complete model of the telephony system (i.e., together with the user model and optional features for each user) terms of the number of states, components, transitions, connectors, teractions, and priorities. 2) The amount of work, terms of new and changed BIP2 components, states, transitions, connectors, teractions, and priorities, that a developer must perform to add a new feature to an existg system. We also look at the difficulty of design decisions when composg new features terms of limitations on the number or type of ports existg components, transitions with the component, and the types of existg connectors. We also strive to adhere to the prciples of feature-oriented development. That is, the addition of a new feature to

6 the system should not require the modification of the or existg features. Adherence to this prciple allows for the dependent and parallel development of features. 3) The difficulty of detectg and resolvg FIs terms of which ports, connectors, or transitions the modeller needs to consider to discover conflictg features and the number of changes they must make the model to resolve these teractions. Our secondary goal was to identify design methodologies or patterns for modellg and connectg BIP2 components feature-oriented systems. In the next section we present three different feature-oriented modellg strategies and evaluate each of them based on the criteria above. IV. COMPOSITION STRATEGIES Over the course of our case study, we identified and evaluated three distct approaches to feature-oriented modellg BIP2. In this section we describe these strategies, the thought processes that guided them, and our evaluations of their ability to combat the Feature Interaction Problem. See Appendix A for the full set of models we constructed through the course of this study. Each approach tackles the problem of terconnectg features and the base system a different way, resultg different teractions, different degrees of model complexity, and different degrees of difficulty the type of decisions the modeller makes durg composition. We give a summary of our evaluations of each of these three approaches Table I. A. Reuse Approach Our first approach to modellg and composg features stems from the idea that a feature overrides functionalities provided by the base service. In fact, our case-study features can naturally be described terms of how they override functionalities the. CFB, CW, and TWC override the signal that the subscriber s sends when she is currently occupied with another call by stead frowardg the comg call, placg it on hold, or addg the comg caller to the current call, respectively. CF and TCS both override how the responds to an comg call. When a user places a call to the subscriber, CF forwards the call automatically while TCS allows an comg call to proceed only if the source number has not been blocked by the subscriber. In BIP, the signals that these features override correspond to ports and teractions between s. The signal is sent from a currently occupied user A to an comg caller, user B, when the and ports of their s are enabled, respectively. Likewise, when user A places a call to an unoccupied user B, the call and rgg ports of their respective s are enabled, causg an teraction that triggers a rg tone to user B. To override the above functionalities, a feature must defe a new connector with teractions that will execute place of the existg teractions. The reuse approach takes advantage of the s existg ports and connectors. Specifically, we tegrate a new feature INCALL ' 2nd BSC A 2nd DIAL DIAL CALLING BSC B DIAL DIAL CALLING BSC C WAIT WAIT FOR FOR INCALL WAIT WAIT FOR FOR INCALL ONHOOK ONHOOK ' HOLD X HOLD Y CW callwaitgconnector SignalConnector New Priority: SignalConnector:* < callwaitgconnector:* Fig. 6: The tegration of CW the reuse approach, components simplified for brevity. The origal connector is shown red and dashed, and the new connector, contag the 2nd port from the CW component is shown blue and solid. by first identifyg the set of signals/behaviours it overrides, identifyg the correspondg ports that send those signals, and then designg a new atomic component and teractions that either trigger or synchronize with these ports. We now give an example of how to add the CW feature to an existg system the reuse approach. Example 1. CW overrides the signal sent by the subscriber s. It allows the subscriber to place an comg caller on hold and between the new and existg caller, extendg the behaviour of the INCALL state. When user A is, we want CW to allow a call from user C to progress to the INCALL state, and for the CW feature to dicate that user C is currently on hold, while user B is connected to user A. To accomplish this, we defe a new connector that connects the port of user A to the ports of users B and C and the newcall port of the CW component. This connector overrides the existg connector (shown red) that sends a signal from the of user A to the call services of two other users, B and C. If a new connector is defed durg the tegration of a feature, a priority must be put place to give this connector precedence over the existg functionality. In our example, teractions the new connector have higher priority and therefore execute the place of teractions the origal connector. Note that troducg a new connector often volves defg a new connector type the BIP2 model that cludes an extra port from the feature atom. When we add more features that override the same existg functionality, a sgle connector may conta ports from all s and several feature components. The design of this new connector type must consider all possible combations of enabled synchronizg ports; the number of teractions this connector is then exponential the number of features and s that it connects. The

7 disconnectg rgg rgtone forwardg allowed check CF TCS rgg forwardg INCOMING disconnectg allowed check blocked rgtone RINGING LOCAL DISCONN blocked Fig. 7: A component is rewired to support tegration with TCS and CF. New transitions and ports for teractg with CF and TCS are shown blue and purple, respectively. modeller may have to troduce further priorities with the connector to resolve any undesired FIs. We found that while the fully composed model may conta connectors with ports from several features, the modeller may still design these features dependently. In the event that the new connectors of two or more features share the same ports from the s of the subscriber and other users, the modeller may replace these connectors with a new connector that cludes the ports and the ports from all participatg features. At this pot, the modeller may resolve any resultg FIs with the troduction of additional priorities. B. Rewire Approach The reuse approach relies on existg ports and transitions the and prerequisite features to tegrate new functionalities. As a result, the design of a new feature is limited by the structure of existg components. Furthermore, the reuse of ports results connectors with a large number of ports and teractions, complicatg the detection and resolution of FIs. The rewire approach explores a different method for tegratg new features and gives the modeller a greater degree of flexibility by permittg modifications to existg components. In this approach, we relax our goal of adherg to the prciples of object-oriented design to evaluate whether modellg freedom results a reduction the complexity of feature design and the detection and resolution of FIs. In the rewire approach, we add a new feature to an existg system by first identifyg the signals the feature sends or receives from the s of the subscriber and connected users. For each signal, we add a correspondg port to the component. Second, we decide the changes to the ternal state of the upon sendg or receivg these signals, and add new transitions or places, accordgly. Fally, we design the feature component to trigger and synchronize with transitions the and connect it to the s of the subscriber and connected users. The followg example illustrates the process of addg TCS to an existg system. Example 2. TCS screens all comg calls agast a list of blocked numbers. In order to do so, the TCS component communicates with existg components through the followg signals: The of the subscriber alerts TCS of an comg call. TCS advises the subscriber s to allow a call. TCS advises the subscriber s to block a call. We defe three ports the subscriber s to send and receive the signals mentioned above: check, allowed, and blocked, respectively. Figure 7 shows the modifications to the component. The origal transitions are shown black and the new transitions for TCS are given purple. Fally, we need to add priorities to ensure that the transitions of the new feature will execute. As stated Section II, every place with more than one gog transition requires a priority orderg on these transitions. In this example, we troduce the priorities check > blocked > allowed > rgt one to ensure that a number is first checked, and then allowed to proceed if and only if it has not been blocked. Note that we are not replacg or modifyg connectors this approach. As a result, each of the connectors we troduce will only connect the feature component and the existg components, reducg the size of the connectors and the number of teractions the modeller needs to specify and consider when defg priorities. In the reuse approach, the maximum number of ports a connector is lear the number of features, resultg an exponential number of possible teractions. In addition to beg small, the connectors the rewire approach are also very similar structure. Every connector that lks a feature component with existg s belongs to one of two connector types: 1) A connector with two ports: trig and sync. One port belongs to the feature component and the other belongs to the of the subscriber or caller. This connector has two teractions: one where only trig is enabled, and one where both trig and sync are enabled. The former should never execute and is given the guard G a : false. The latter is given the guard G a : true. 2) A connector with one triggerg port, trig, and n synchronizg ports, {sync 1,..., sync n }, where n is the number of s that lks all BSCs and the new feature component. There are 2 n teractions this connector, but only n are allowed to execute with the guard G a : trig.targetnum == sync i.num. The BIP2 language allows the specification of parameterized connector types. When modellg our telephony system this approach, we only need to defe the teractions for the two generic connector types above. These connector types are later stantiated with specific port names, reducg the amount of work that goes to the specification of a BIP2 model.

8 Unfortunately, the advantages of the rewire approach come at the cost of violatg the prciples of feature-oriented development. The new feature components teract with components through new ports. This means that the s need to be extended with transitions that react to events on these ports. Thus, the addition of new features causes changes to the Petri nets of existg components. A feature s behaviour is no longer encapsulated the feature component and new connectors. C. Pipe-and-Filter Approach The reuse and rewire approaches exemplify the challenge of feature-oriented modellg BIP. There is a trade-off between modellg freedom and modularity; by treatg components as black boxes, we restrict the ways which other components can teract with them. In an effort to bridge the gap between these two strategies, we adapted an approach that standardizes how feature components teract with other features and the. Interactions BIP2 can be thought of as messages between components. Each component specifies the messages that it can receive (via synchronizg ports), and the messages it can send (via triggerg ports). These messages may optionally carry data, such as the number of the synchronizg component and the target number of the triggerg component. However, if we stead standardize the types of messages that features are allowed to send and receive, we make it much easier to terconnect features with knowledge of their ternal structure. In the pipe-and-filter approach, components rely on the data passed through the ports of connectors to determe changes their ternal state, rather than on the names of ports and connected features. We took spiration for our third approach from the Distributed Feature Composition (DFC) architecture developed by Zave and Jackson [6] for the development and composition of telephony features. In DFC, feature components are connected sequentially between the s of subscribg users. In DFC, formation is piped through sequences of features as calls are placed from one to another. The execution of features is serialized, with each feature triggerg the next feature the pipele. A feature or service itiates or termates a call by sendg a setup or teardown message, respectively. Other messages such as quick and reserve dicate that the target user is volved a call and that the attempted connection has failed or succeeded, respectively. DFC provides a default resolution of FIs by imposg a priority orderg on the execution of features that determes which features will react first to messages passed through the pipele and which features are a position to specify the system s fal response to a user request. We made major changes to the origal BSC to standardize the messages that are sent among components. We analyzed the communications between call services and grouped them to three ma types of messages: messages that establish a call, messages that dicate the other service is currently unavailable, and disconnect messages that dicate one of the participants wishes to termate the connection. We standardized messages and ports by encodg the type of message the data that is exported through each port. Every teraction between an gog and comg port passes the followg data: (1) The enumerated message type (CONN, BUSY, or TERM), (2) the source number of the message, and (3) the target number of the message. The origal BSC components communicate and synchronize with each other through a number of different connectors, each representg a different step the process of settg up, matag, and tearg down a call. The origal has a unique port for each kd of message (to setup and tear down connections, issue signals, or accept comg calls). For each message, there are one or more transitions between places that keep track of the current state of he call. In the pipe-andfilter approach, each and feature component has exactly two ports labelled and. These ports import and export data that specify the rg formation of the call and the message type. Example 3. Figure 8 shows the tegration of TCS the pipeand-filter approach. The TCS component is placed between the of the subscriber and the caller. In this position, it responds first to comg calls. The caller attempts to establish a connection by triggerg a transition the TCS component and exportg the src, dest, and code variables to dicate where the message is comg from, that the message is tended for the subscriber, and that the caller wishes to establish a voice connection. TCS will relay this message to its subscriber if and only if the caller, as dicated by src, has not been blocked. In the event that the call is blocked, TCS will stead send a message back to the caller dicatg that the call has been termated. The standardization of messages allows features and call services to be oblivious to other components, while still reactg predictably to received formation. Features can be designed dependently and parallel. This provides a greater degree of modularity than the rewire approach, which requires modifications to existg components, as well as the reuse approach, which requires modifications to existg connectors and teractions. Additionally, every feature has the same ports and is lked to other components with the same connectors, allowg us to make heavy use of parameterized connectors and further reducg the work of the modeller. D. Evaluation of Approaches We collected quantitative data on the complexity of our three approaches and give the results Table I. We measured the work of the modeller to express and compose the features terms of the number of additional places, transitions, data variables the feature atoms, the number and complexity of the connectors needed to compose features, and the number of priorities troduced to mitigate FIs. We also measured the amount of rework to existg transitions, teractions, and priorities needed to properly compose a full model and resolve any unwanted FIs.

9 A DIAL num = 100 tarnum = 101 {src = mynum; dest := targetnum; code := CONN;} [code == TERM && src == targetnum] WAIT FOR ONHOOK CALLING CONNECT [code == CONN && src == targetnum] TCS B {code := TERM; dest := src; src := mynum;} mynum BLOCK [src blocklist] [code == CONN && src!= mynum ] CHECK {code := CONN; src := src; dest := dest;} ALLOW [src not blocklist] B num = 101 tarnum = 0 [code == CONN] {targetnum := src;} INCOMING Fig. 8: A partial model of two s and TCS connected the pipe-and-filter approach.components are connected sequentially, with teractions that carry connection and tear-down messages as data. Each feature the cha has the ability to modify the messages that pass through it, changg the progression of the call. TABLE I: Comparison of the overall complexity of a fully-composed BIP2 model each of the three approaches. A fullycomposed model has three users, each with a basic-call service, where one user has subscribed to all five optional features. Origal Reuse approach Rewire approach Pipe-and-filter approach feature places feature transitions transitions data variables connector types defed teractions connectors priorities reworked transitions reworked teractions reworked priorities We evaluated each strategy on three ma pots: the complexity of the overall model ( terms of feature places and transitions as well modifications to the and the connectors used to compose the overall model), the work of tegratg a new feature to the existg model ( terms of additional feature components, connectors, and design decisions that require knowledge of existg components), and the difficulty of detectg and resolvg feature teractions ( terms of analyzg existg components and the rework required to remove undesired behaviour). Composed model complexity As shown Table I, each approach exhibits a different type of complexity. The reuse approach performs the most poorly terms of the number of connector types and the number of defed teractions. The reuse of connectors requires the specification of an extreme number of teractions due to the number of ports and the many varieties of connector types. By contrast, both the rewire and the pipe-and-filter approaches use smaller and more similar connectors, resultg the specification of fewer connector types and fewer defed teractions. In the rewire approach, the simplification of connector defitions comes at the cost of the number of stantiated connectors, which requires the specification of more priorities, and may prove to be problematic for the model-checkg or simulation tools available for BIP2 models. The pipeand-filter approach performs the best terms of connector complexity, with a similar number of defed teractions to the rewire approach and fewer priorities than both of the previous approaches. In the reuse approach, the specification of a new feature component is restricted by the ports of existg features. Although this did not prove to be a significant problem our case study, there may be more complex features that require a transition between places the base service that are far apart. We predicted that the modellg freedom that resulted from allowg changes to existg components would ease the task of feature specification. However, our case study showed that the complexity of each feature component terms of feature places and transitions does not vary significantly from the complexity of feature components the reuse approach. The pipe-and-filter approach shows a small crease model complexity terms of the number of data variables each component. Note that previous two approaches,

10 a component receives only the messages it is terested reactg to. In contrast, every feature the pipe-and-filter approach receives all messages sent and received by the subscriber s. While only a subset of these messages will be of terest to a particular feature, each feature must propagate any message it does not override to the next feature the pipele. This ensures that messages will reach the BSC endpots unless they are explicitly tercepted and overridden by the terveng features, but creases the complexity of the feature components. In the rewire approach, the monolithic implementation of features the creases the chance of troducg errors and complicates the task of debuggg. We almost doubled the number of transitions addg only our five case study features. The advantages gaed by simplifyg the specification of connectors the composed model are completely undone by the complexities troduced from revisg the with each new feature addition and resolvg conflicts the resultg monolithic component. We designed a completely new model for the pipe-and-filter approach to accommodate standardized messages. However, the new component is similar complexity to the origal, with only slightly more transitions and data variables. Integratg a new feature The tegration of a new feature each of the three approaches requires varyg amounts of knowledge and work. In the reuse approach, the modeller requires knowledge of, but does not make changes to, the components of the and existg features. The places, transitions, and variables of the new feature component depend on two factors: (1) the transitions the feature needs to trigger the s of the subscriber and other connected users, and (2) the new states the feature needs to reflect. In the rewire approach, the modeller has the ability to add places and transitions to existg components. While the modeller has complete freedom over the structure of the feature component, all features require changes to the existg model and complex design decisions on how to make these changes with negatively impactg the overall desired behaviour of the system. Changes to the, the form of new transitions and priorities, must reflect desired behaviour, regardless of the combation of features present. Although the essential behaviour of each feature is modularized, the specification of features this approach is spread across multiple possibly unrelated components. The standardization of messages the pipe-and-filter approach allows features to be developed dependently from existg components, relyg only on the data variables passed through teractions to determe how the feature will respond to comg or gog calls. This reduces the work of addg a new feature to specifyg the feature s atomic component given our assumptions on the structure of these messages. The behaviour of a feature is determed by its reaction to the different types of messages sent and received by the s. For example, CFB, CW, and TWC all react to a message of type BUSY issued by the subscriber s. Each feature overrides its by effectively terceptg the signal and replacg it with its own signal: CFB issues a call to a new target and CW issues a connect message. A feature does not need to know which other features it is connected to; each feature only knows that its subscriber s is upstream the pipele, and that the s of other users are downstream. A feature component s design only depends on the type of messages it can receive from either direction. After a feature component has been designed, it must be added to the system. Sce teractions between components are all the same, we make heavy use of BIP2 parameterized connector types. Resolution of FIs In the reuse approach, a FI occurs when the connector(s) of two or more features share the same port(s) an existg component, or a connector contas ports from multiple features. To resolve the former, the modeller must decide a complete orderg on the conflictg features and troduce priorities to allow the teractions of higher priority features to take precedence over the teractions of lower priority features. To resolve the latter, the modeller must decide which teractions the connector produce the desired behaviour, and prohibit all other teractions by settg the guard to false. FIs the rewire approach occur when transitions that leave the same source place a component belong to different features. We partially resolve these teractions by addg priorities when we tegrate the feature to the system. For example, CF and TCS conflict when the is the IN- COMING place, as shown figure 7. Our desired behaviour is to first screen the call agast a list of blocked numbers before forwardg it. However, the resolution is not as simple as givg a complete priority orderg among all transitions from the INCOMING place. We wish both features to execute, not one the place of the other. For this to work, we need TCS to perform the check, and then execute the allowed transition the and return to the state before CF executes and forwards the call. To accomplish this, we need to move the CF f orwardg transition to the destation state of the TCS allowed transition, requirg the rework of the modeller to resolve the FI. Note that modifications to existg components are not necessary to resolve FIs the reuse approach. We allow the modeller to redefe connectors to clude two or more feature components. In this way, features can transition the same execution step (e.g. TCS can return to the state and CF can forward the call the same teraction). The resolution of features the rewire approach is undesirable, as FI resolutions are realized as a monolithic solution the component. FIs the pipe-and-filter approach are resolved by feature placement the pipele between s. The farther a feature is from the subscribg user s call service, the sooner it receives comg messages and the more priority it has over other, closer features. A FI occurs when two or more features react to the same types of messages. For example,

11 both CF and TCS modify the connect signal sent to their subscriber s. If TCS is farther downstream the pipele, it will be the first to receive a connect message and can check the source number agast a list of blocked numbers before passg the connection request to the CF component. At this pot, CF will forward the call to another target address. If stead TCS blocks the number, CF never receives the connection request. In this manner, the placement of features along the pipele determes the order which they react to signals, thereby usg serialization to defe a default resolution to FIs. The detection and resolution of FIs is reduced to identifyg appropriate feature placement along the pipele. V. DISCUSSION As evidenced by the results shown Table I, each approach exhibits complexity a different aspect of the modellg process. The reuse approach adds features with the limits of existg components and ports, resultg large, complex connectors. In the rewire approach, the modifications to existg components result a large number of connectors and a complex, monolithic that requires further modifications to resolve FIs. The pipe-and-filter approach standardizes component ports and messages to ease the task of feature tegration, at the cost of more complex feature components. It was a major challenge to support the development of features as black-box components. In BIP2, the specification of each component cludes the specification of its ports, deleatg the ways which the component can teract with others. The specifications of ports, connectors, and teractions require some knowledge of the ternal workgs and ports of other components which is the modus operandi BIP2, where the modeller connects and specifies teractions among known components. In contrast, feature-oriented systems have a contuously evolvg set of features. It is advantageous this scenario for a feature developer to not know ab the other features the model. Called feature obliviousness, a feature necessarily knows ab the base system that it is designed to extend or override, but ideally not ab other features the system. It is this obliviousness and separation of concerns that allows features to be developed isolation and by third parties, and to be more easily tegrated to an existg system with requirg significant rework of existg features or their connectors. The reuse approach adheres most faithfully to the BIP2 vision for component-based design. Although the design of new features requires knowledge of existg components, we do not need to make changes to the existg components of the and other features. Furthermore, while the large connectors the reuse approach require an exponential number of specified teractions, FIs are easily detected and resolved by reworkg existg connectors. In contrast, the pipe-and-filter strategy is the most effective supportg feature obliviousness. Not only does every feature have the same terface, but the connector types and their teractions are standardized. What is left to the modeller is to determe the order of connected features the pipele, and to stantiate the connectors to realize this pipele. As a result, the composition of features and resolution of FIs was almost trivial. However, the feature components are more complex, because they need to extract formation from the messages and because they need to process messages that they do not react to (i.e., they need to forward such messages to the next feature the pipele). A. Threats to Validity Although telephony systems provide a rich example of an extreme software product le, it is not representative of all feature-oriented systems. The comparative complexity of our three approaches may be different for other complex systems. In particular, we note that the pipe-and-filter strategy for connectg features works particularly well telecommunications and Web services, where there is already a natural lear message path between communicatg basic-call service components. Such a lear orderg of features may be less appropriate other domas. We chose the five features that constitute our case study based on their varyg complexity and potential for terestg FIs. CW and TWC are among the more complex features telephony, terms of the number of places, transitions, and connectors. With respect to the features prevalence to teract, three of the features override the s signal, and the other two feature react to comg calls. We believe this set of features is representative of end-user telephony features, but acknowledge that other classes of features (e.g. billg features) could produce different results. VI. RELATED WORK Sce the framg of the Feature Interaction Problem 1989 [1], there have been myriad attempts to mimize the effort of the developer composg systems that are prone to a large number of FIs [2], [7]. Off-le techniques aid the developer durg the design and development of the system. Techniques for detectg FIs reduce the effort of the developer discoverg problematic compositions of features and ppotg the sources of unexpected or undefed behaviour [8], [9], [10], [11]. Filterg approaches limit the variability of a system by removg problematic or unlikely combations of features from analysis, thereby reducg the number of FIs a developer needs to consider to those a small set of feasible products [12], [13], [14]. On-le techniques for coordatg feature execution resolve FIs as they occur at runtime. Hay and Atlee proposed a specification and composition model that uses feature priority to automatically resolve FIs durg composition [15]. Distributed Feature Composition (DFC) developed by Zave and Jackson [6] connects features to a network of pipe-andfilter architectures, avoidg FIs architecturally by serializg the features executions. In contrast, BIP provides modellers