Feature-Oriented Modelling in BIP: A Case Study Cecylia Bocovich Joanne Atlee University of Waterloo Email: {cbocovic, jmatlee}@uwaterloo.ca Abstract—In this paper, we investigate the usage of Behaviour- 2 (BIP2) [3], [4] is a framework for the design of component- Interaction-Priority version 2 (BIP2), a component-based mod- based systems. BIP2 allows the designer to decompose a com- elling framework, for specifying feature-oriented systems. We plex system into a collection of interconnected components. evaluate BIP2 in the context of the Feature Interaction Problem and quantify the amount of work needed to add features to Given that the BIP2 formalism is designed to support an existing system (i.e., in terms of rework to existing features, component-based modularity, and given that BIP2 has explicit and work to identify and specify interactions). We present the language constructs for specifying how feature combinations results of a case study on a telephony system with five optional ought to synchronize and how conflicts and nondeterminism features where we found that the amount of work depends heavily ought to be resolved, we investigated how to use BIP2 to on how features are interconnected. We identify three different design methodologies for interconnecting features, and propose address the Feature Interaction Problem. We performed a one that reduces the amount of work and rework needed to add case study in which we used BIP2 to model a telephony new features to an existing system. system with five features. We aimed to answer the following questions in our investigation: (1) Is it possible to model I. I NTRODUCTION features independently and integrate them into the system In software engineering, an increasingly popular strategy without changing existing features? (2) How much work (and to decompose a complex system into smaller subproblems is rework) is required to integrate a new feature into an existing to perform feature-based decomposition, which is a type of system model? (3) How much work is required to specify functional decomposition of the system. A feature is a unit of interactions among features, and what is the overall complexity functionality that can be developed and evolved independently. of the resulting system model? However, the composition of separately designed features to Answers to these questions depend heavily on the design produce a final product often leads to unexpected or undesir- methodology used to define component interfaces and to able behaviours. A feature interaction (FI) occurs whenever interconnect components. We identify three distinct design the presence of one feature alters the behaviour of another. methodologies for composing features, and we evaluate the For example, a user may subscribe to a telephony feature that amount of developer work that is needed to integrate new automatically forwards her calls to another number; she may features and resolve feature interactions in each approach. An also subscribe to a second feature that screens calls against interesting side effect of this work is that we have shown how a list of blocked numbers. If each feature is specified and BIP2 – whose strength is in modelling components that are developed without knowledge or consideration of the other designed to know about each other and to work together – can feature, the outcome is not clear when both are activated in the be used to model components that do not know about each same scenario. A call could be screened before it is forwarded, other and to compose them so that they can work together. or it could instead be screened against the list of blocked numbers at the forwarding destination. II. OVERVIEW OF BIP To be safe, a developer must consider how a new feature might interact with existing features. To be thorough, all Behaviour-Interaction-Priority (BIP) is a component-based combinations of existing features need to be considered. As language for modelling complex systems [3]. In BIP, the the number of features grows, the number of feature combi- behaviour of a system is modelled as a collection of individual nations that must be analyzed for possible interactions grow components, each of which is responsible for a subset of the exponentially — until the work of integrating a new feature system’s behaviour. As the name suggests, BIP provides three is dominated by the analysis and resolution of feature interac- layers of specification to the model: the Behaviour of system tions. In systems with high variability, the Feature Interaction components, the Interactions 1 between these components, and Problem, the task of analyzing every possible combination the Priorities between multiple possible execution paths. In this of composed features and resolving any discovered feature paper, we use the second iteration of this framework, BIP2 [4], interactions, becomes intractable with existing methods [1]. and will refer to this version from this point forward. Many techniques and tools have been developed to minimize the work of the developer in discovering and resolving feature 1 Given how the term interaction is overloaded, we use the acronym FI to interactions [2]. One such strategy is the use of special- refer to a traditional feature interaction (any difference in feature behaviour, intended or not, due to the presence of other features). We reserve the ized modelling languages for the design and verification of qualified term interaction to refer to a BIP2 interaction (an explicitly specified composed systems. Behaviour-Interaction-Priority version communication and synchronization among connected components). A. The Behaviour Layer C. Priorities Each component in a BIP2 model defines a subset of a To combat nondeterminism and enforce scheduling policies, system’s overall functionality. In this paper, our system con- BIP2 provides priorities as a means to choose between mul- sists of a base component that provides basic call-processing tiple enabled execution paths. Nondeterminism arises when functionality (i.e., on-demand voice connections between two there are multiple simultaneously enabled interactions, each users), a set of optional feature components that extend or leading to a different overall system state. Normally, if there override this functionality, and a component that represents is more than one connector with an enabled interaction, there the system’s environment (i.e., telephone users). are no guarantees about which interaction will execute. We can control the outcome by specifying priorities in one of The most basic BIP2 component is an atom. The internal two ways: (1) at the component level by specifying that port operation of each atom is modelled as a Petri net. An atom’s p1 has a higher priority than port p2 with p1 > p2 , or (2) current state is represented by the set of currently occupied at the interaction level by specifying that interactions in the places and the values of the atom’s variables. Transitions connector C1 have priority over interactions in the connector between places in the net update the atom’s variables and the C2 with the priority C1 : ∗ > C2 : ∗. set of occupied places. A transition from a set of previously The simplest way to resolve all nondeterminism is to define occupied places to a set of newly occupied places may be a complete ordering on the transitions that lead from each optionally labelled with a guard, an update function, and state. Our basic-call service atom requires a total of 26 a port. A guard is a predicate over the atom’s variables, priorities to resolve conflicts from simultaneously enabled and a transition is enabled and executed only if the system interactions and avoid inconsistent states. Priorities play a large state satisfies the guard. After transitioning, the variables role in the resolution of feature interactions. are updated as dictated by the update function. Ports trigger transitions in synchronization with other components, and are III. T ELEPHONY C ASE S TUDY used in the specification of the interaction layer. Ports restrict We conducted a case study on a telephony system to assess transitions similar to guards; a transition labelled by a port the extent to which BIP2 combats the Feature Interaction relies on an interaction with another component to execute. Problem. In this section, we outline the basic structure of our telephony system, the features involved, and the criteria we B. The Interaction Layer used to evaluate the design methodologies we developed. A feature-oriented BIP2 telephony model consists of three Components interface with each other through ports that are parts: (1) a basic-call service (modelled as an atomic compo- linked together by connectors. A connector links at most one nent), (2) a set of optional features to which a user may sub- port from each of the two or more components it connects: the scribe that extend or modify the functionality of the basic-call effect is to synchronize the transitions in each of the connected service (each of which is modelled as an atomic component), components that are labelled with the linked ports. The ports and (3) the user (modelled as an atomic component). in a connector may be either triggering ports (i.e., senders) Each user’s basic-call service (BCS) allows that user to or synchronizing ports (i.e., receivers). When a transition place and receive calls. The places in the BCS component, labelled with a sender (denoted by a primed port name, e.g., together with its variables, reflect the possible states of an busy’) is enabled, a synchronized execution step that involves outgoing or incoming call. The ports of the component reflect a subset of the enabled receiving transitions in the connected the ways in which users and features may interact with or components will execute. The subset of transitions that execute extend the functionality of the BCS (e.g., taking the phone is determined by the guards and the priority ordering of the off the hook, or dialing a number), and the ways in which connector’s interactions. the BCS of one user interacts with the BCSs of other users Each interaction in a connector consists of a triggering (e.g., establishing a connection). Our case study includes five port(s) and some subset of the connector’s synchronizing ports. optional features, taken from the specifications for the Feature Interactions may be labelled with guard and transfer functions Interaction Contest [5]: in the same manner as component transitions, restricting which Call Forwarding (CF): The subcriber may specify a of the components will participate in the synchronized step. forwarding number. All calls to the subscriber will then be The variables in these functions are the data variables exported forwarded to this number. by the components’ ports. Upon execution, the interaction’s Call Forwarding on Busy (CFB): If the subscriber receives transfer function updates the variables in participant atoms, a call when she is involved in another call, the feature will allowing components to exchange information. redirect the new call to a predetermined forwarding number. For example, in a telephony model, the connectors between Call Waiting (CW): If the subscriber receives a call when the basic-call service components of multiple users define the she is involved in another call, she may choose to put the ways in which the services may interact throughout the process original call on hold, answer the new call, and then toggle of a call. Likewise, the connectors between a user component between the two calls. and its basic-call component define how a user interacts with Terminating Call Screening (TCS): This feature allows her own call service. its subscriber to specify a list of blocked numbers. Any call originating from a number on this list will be terminated BCS A BCS B BCS C busy busy busy busy automatically. CALLING CALLING Three-Way Calling (TWC): This feature allows a sub- DIAL DIAL DIAL DIAL scriber to add a third user to an existing call. Once three-way INCALL busy isNotBusy isNotBusy isNotBusy isNotBusy isBusy isBusy isBusy isBusy communication has been established, any user may chose to leave, resulting in a traditional two-way call configuration. INCALL INCALL WAIT WAITFOR FOR WAIT WAITFOR FOR ONHOOK ONHOOK ONHOOK ONHOOK The BIP2 framework claims to support component-based isBusy isBusy busy' busy' isNotBusy isBusy isNotBusy isBusy modelling with an emphasis on inter-component interactions. The primary goal of our case study was to assess these claims callWaitingConnector in the context of feature-oriented modelling and feature inter- busySignalConnector actions (FIs). We evaluated BIP2’s suitability for modelling 2nd HOLD Y feature-oriented systems on three main points: IDLE New Priority: busySignalConnector:* 1) Composed model complexity: The overall complexity 2nd < callWaitingConnector:* HOLD X isNotBusy of a complete model of the telephony system (i.e., the CW BCS together with the user model and optional features for each user). Fig. 1: The integration of CW in the reuse approach (partial 2) New feature integration: The amount of work that models are shown for brevity). The original connector is shown a developer must perform to add a new feature to an in red and dashed, and the new connector, containing the 2nd existing system. We look at the difficulty of design port from the CW component is shown in blue and solid. decisions when composing new features in terms of limitations on the number or type of ports in existing components, transitions within the BCS component, and override: CFB, CW, and TWC override the progression of a the types of existing connectors. We strive to adhere to call when the subscriber is busy, while CF and TCS override the principles of feature-oriented development. That is, the progression of an incoming call. the addition of a new feature to the system should not A call progresses through interactions with other basic-call require the modification of the BCS or existing features. services and users. To integrate a new feature in the reuse 3) FI Resolution: The difficulty of detecting and resolving approach, we first identify the interactions in the existing FIs in terms of how the modeller discovers conflicting components that it overrides. We then expand the connector(s) features and the number of changes they must make in that contain these interactions to include ports in the new the model to resolve these FIs. feature’s component. Interactions that involve the new feature’s Our secondary goal was to identify design methodologies synchronizing or triggering ports are then given higher priority or patterns for modelling and connecting BIP2 components in than the pre-existing interactions. feature-oriented systems. In the next section we present three We show the integration of CW to an existing BIP2 model different feature-oriented modelling strategies and evaluate in Figure 1. If User A is in a call, the (red) interaction normally each of them based on the criteria above. For a more complete terminates subsequent incoming calls by synchronizing the description of our modelling strategies complete with BIP2 busy 0 port of User A’s BCS with the isBusy port of the models and code, see our extended technical report [6]. caller’s BCS, causing the caller to transition to its WAIT FOR ONHOOK place. If User A subscribes to CW, this interaction IV. D ESIGN M ETHODOLOGIES is replaced with a new interaction (blue) that instead allows the Each of our design methodologies approaches the problem caller to proceed to the INCALL state. The CW feature keeps of feature composition and integration with the base system track of which of the subscriber’s calls is currently on hold. in a different way, resulting in different interactions, different The new interaction is given higher priority, thereby replacing degrees of model complexity, and different types of decisions the old functionality. the modeller must make during composition. We give a summary of our evaluations in Table I. B. Rewire Approach A. Reuse Approach While the reuse approach allows for the independent de- In the reuse approach, new features are integrated into velopment of features and resists changes to the BCS com- the base component by reusing existing components and ponents, the design and integration of a feature is limited by expanding the connectors between basic-call services and the ports and transitions of existing components. Furthermore, users to include the new feature component, and replacing a system with many features that override the same function- the default interactions with new ones that slightly alter the alities may result in very large connectors that contain ports progression of a call. The inspiration for this approach stems from many different components. These connectors are more from the idea that a feature overrides existing functionalities difficult to specify and define priorities for, as all combinations provided by the base service. Our case study features can of enabled ports must be considered. We designed the rewire naturally be described in terms of the BCS functionalities they approach to give the modeller more freedom to modify existing We took inspiration for our third approach from the Dis- disconnecting ringing ringTone forwarding allowed check tributed Feature Composition (DFC) architecture developed by Zave and Jackson [7] for the development and composition of IDLE telephony features. In DFC, each user’s features are connected forwarding RINGING sequentially in a pipeline, and communications from one user allowed to another propagate through a sequence of features as a call is placed from one BCS to another. Thus, the execution of ringing ringTone blocked features is serialized, with each feature triggering the next INCOMING feature in the pipeline. As a result, DFC provides a default check resolution of FIs by imposing a priority ordering on the CF blocked execution of features, determined by the feature’s positions LOCAL disconnecting DISCONN in the sequence (e.g., the last feature in the pipeline provides TCS a final response to a user request). In our pipe-and-filter approach, we standardize the trigger- Fig. 2: A BCS component is rewired to support integration ing and synchronizing ports on each feature, making it much with TCS and CF. New transitions and ports for interacting easier to interconnect features without knowledge of their with CF and TCS are shown in blue and purple, respectively. internal structure. Synchronized transitions within components are triggered not just by communications on the ports of connectors, but by the specific data conveyed in the communi- components with the expectations of easier design decisions cations. Specifically, we designed a new BCS that standardizes and simple components and interaction specifications. the messages that are sent among components. Messages fall In the rewire approach, new features may entail new func- into one of three main types: messages that establish a call, tionality (i.e., new ports and transitions) in the pre-existing busy messages that indicate the other service is currently model of the BCS. When integrating a feature, we first decide unavailable, and disconnect messages that indicate one of the the changes the feature makes to the progression of states participants wishes to terminate a call. Every component has inside the BCS, and add new transitions and label them with two ports: a synchronizing port in for receiving incoming new ports that will be connected to the new feature component. messages, and a triggering port out for sending outgoing Finally, we design the feature component, and specify the messages. Every interaction between an out and in port passes interactions of a new connector that synchronizes transitions the following data: (1) The enumerated message type (CONN, in the modified BCS components and the feature component. BUSY, or TERM), (2) the id of the component that sent the In Figure 2, we give an example of the changes made to message, and (3) the id of the component that is the designated a BCS component when integrating CF and TCS, both of recipient of the message. which modify the progression of an incoming call. In TCS, a new call interacts with the TCS feature component through In Figure 3, we show the composition of two BCS com- ports that first check and then allow or block the call. New ponents with a TCS feature component. A user’s features transitions and new ports (shown in purple) are involved in are arranged and connected in a sequence between her BCS new interactions with the connected TCS component. and the feature sequences of other users. Messages “flow” The rewire approach results in feature-specific connectors through the pipeline one component at a time. Each compo- that are small and similar in behaviour. Fortunately, BIP2 nent synchronizes with the previous component in the chain; allows modellers to specify connector types to ease the spec- decides whether to react to the received data by modifying the ification of many, similar connectors. This further reduces the message; and then propagates the message further, either by work of the modeller and the complexity of the overall model passing it to the next feature or back to the previous feature. in the rewire approach. Unfortunately, the advantages of the The standardization of port types and interactions, along rewire approach come at the cost of violating the principles features’ compliance to the rule that all components must of feature-oriented development: existing components must be propagate messages either forward or backward through the extended with new transitions that react to events on new ports. pipeline, allows features and BCS components to be oblivious of the behaviour and existence of other components, while C. Pipe-and-Filter Approach still reacting predictably to received communications. Features The reuse and rewire approaches exemplify the challenge of can be designed independently and in parallel. This provides feature-oriented modelling in BIP. There is a trade-off between a greater degree of modularity than the rewire approach, modelling freedom versus modularity; by refusing to change which requires modifications to existing components, as well existing components, we restrict the ways in which other as the reuse approach, which requires knowledge of existing components can interact with them. To bridge the gap between components. Additionally, every feature has the same ports these two strategies, we adapted an approach that standardizes and is linked to other components with the same connectors, how components interact with each other. further reducing the work of the modeller. BCS A out TCS B in in BCS B out out out {src = myNum; {code := CONN; in dest := targetNum; src := src; code := CONN;} dest := dest;} IDLE IDLE DIAL CALLING out {code := TERM; [code == CONN] dest := src; {targetNum := src;} src := myNum;} ALLOW [code == TERM && [code == CONN && [code == CONN && in src == targetNum] src == targetNum] src != myNum ] BLOCK WAIT INCOMING [src not in blocklist] FOR ONHOOK CONNECT [src in blocklist] CHECK num = 100 num = 101 Data: tarNum = 0 tarNum = 101 myNum in out in Fig. 3: A partial model of two BCSs and TCS connected in the pipe-and-filter approach. Components are connected sequentially, with interactions that carry connection and tear-down messages as data. Each feature in the pipeline has the ability to modify the messages that pass through it, changing the progression of the call. D. Discussion require significant knowledge of, and possible modifications to, existing components. In feature-oriented systems with a We performed a case study to evaluate each strategy on continuously evolving set of features, it is advantageous for three main points: the complexity of the overall model (in a feature developer to not know about the other features in terms of the number of feature places and transitions, as well the model. It is this obliviousness and separation of concerns as modifications to the BCS and the number and complexity that allows features to be developed in isolation and by third of connectors used to compose the overall model), the work parties, and to be more easily integrated into an existing sys- of integrating a new feature into the existing model (in terms tem without requiring significant rework of existing features of additional feature components, connectors, priorities, and or their connectors. The pipe-and-filter strategy is the most design decisions that require knowledge of existing compo- effective in supporting feature obliviousness. Not only does nents), and the difficulty of detecting and resolving feature every feature have the same interface, but the connector types interactions (in terms of analyzing existing components and and their interactions are standardized. What is left to the the rework required to remove undesired behaviour). We sum- modeller is to determine the order of connected features in marized our quantitative data from the case study in Table I. the pipeline, and to instantiate the connectors to realize this We found that each approach exhibits complexity in a pipeline. As a result, the composition of features and resolution different aspect of the modelling process, as shown in Table I. of FIs was almost trivial. The reuse approach has more complex connectors and inter- We have shown that in BIP2, where specifications of action specifications, whereas the rewire approach adds model ports, connectors, and interactions require some knowledge complexity in the form of monolithic implementations of of the internal workings and ports of other components, features in the BCS component, which violates the principles feature-oriented modelling is possible with the pipe-and-filter of feature-oriented design and increases the chance of intro- approach. In this approach, individual features may remain ducing errors in BCS behaviour. The pipe-and-filter approach agnostic to other features, only requiring knowledge of the introduces complexity in yet another area, requiring more com- base component during their development and composition. plex feature components to formulate specialized behaviour in response to standardized messages. Feature components in V. R ELATED W ORK the pipe-and-filter approach require more data variables, and Since the framing of the Feature Interaction Problem in transitions require guard and update functions that react to and 1989 [1], there have been myriad attempts to minimize the modify the component and message data variables. effort of the developer in composing systems that are prone The integration and resolution of new features require to a large number of FIs [2], [8]. Off-line techniques aid the varying amounts of knowledge, work, and design decisions developer during the design and development of the system. in each of the three approaches. The reuse approach requires • Techniques for detecting FIs reduce the effort of the the modeller to design new features within the constraints developer in discovering problematic compositions of of existing ports and transitions in the BCS. In contrast, the features and pinpointing the sources of undesired be- rewire approach affords the modeller more freedom, yet com- haviour that need to be resolved [9], [10], [11], [12]. plicates the BCS model and violates the principles of feature- • Filtering approaches limit the variability of a system oriented design. In fact, both of our first two approaches by removing problematic or unlikely combinations of TABLE I: Comparison of the overall complexity of a fully-composed BIP2 model in each of the three approaches. A fully- composed model has three users, each with a basic-call service, where one user has subscribed to all five optional features. Original BCS Reuse approach Rewire approach Pipe-and-filter approach feature places and transitions 0 29 33 63 BCS transitions 39 39 75 43 BCS data variables 5 5 5 8 defined interactions 6 66 6 6 connectors 16 22 33 16 priorities 19 26 48 0 reworked transitions, interactions, or priorities 0 8 5 0 features from analysis, thereby reducing the number of in Proceedings of the 7th International Conference on Software Engi- FIs a developer needs to consider to those in a small set neering for Telecommunication Switching Systems (SETSS), 1989, pp. 59–62. of feasible products [13], [14], [15]. [2] M. Calder, M. Kolberg, E. H. Magill, and S. Reiff-Marganiec, “Feature On-line techniques for coordinating feature execution re- interaction: a critical review and considered forecast,” Computer Net- solve FIs as they occur at runtime. Hay and Atlee proposed a works: The International Journal of Computer and Telecommunications Networking, vol. 41, no. 1, pp. 115–141, 2003. specification and composition model that uses feature priority [3] A. Basu, S. Bensalem, M. Bozga, J. Combaz, M. Jaber, T.-H. Nguyen, to automatically resolve FIs during composition [16]. Dis- and J. Sifakis, “Rigorous component-based system design using the bip tributed Feature Composition (DFC) developed by Zave and framework,” IEEE Software, vol. 28, no. 3, pp. 41–48, 2011. [4] Verimag, “Bip2 documentation, release 2015.04 (rc7) [online],” Avail- Jackson [7] connects features in a pipe-and-filter architectures, able: http://www-verimag.imag.fr/TOOLS/DCS/bip/doc/latest/pdf/BIP2. avoiding FIs architecturally by serializing the features’ execu- pdf (accessed November 5, 2015), Tech. Rep., 2015. tions. In contrast, BIP provides modellers with the flexibility [5] M. Kolberg, E. H. Magill, D. Marples, and S. Reiff-Marganiec, “Sec- ond feature interaction contest,” in Proceedings of Feature Interaction to specify how features are connected and prioritized. Workshop, M. Calder and E. H. Magill, Eds. IOS Press, 2000, pp. There have been previous case studies to evaluate the 293–310. modelling capabilities of BIP. Basu et al. performed a case [6] C. Bocovich and J. M. Atlee, “Feature-oriented modelling in BIP: A case study,” cs.uwaterloo.ca/∼cbocovic/bip.pdf, Tech. Rep. CS-2016-04, study on wireless sensor networks [17] to assess the suitability 2016. of BIP2 in modelling distributed systems with heterogeneous [7] M. Jackson and P. Zave, “Distributed feature composition: a virtual components. Bourgos et al. conducted a case study on the architecture for telecommunications services,” IEEE Transactions on Software Engineering, vol. 24, no. 10, pp. 831–847, October 1998. modelling of a MJPEG decoder [18] to test the use of BIP2 [8] D. Keck and P. Kuehn, “The feature and service interaction problem in in analyzing the performance of embedded applications on telecommunications systems: a survey,” IEEE Transactions on Software different hardware platforms. While these case studies provide Engineering, vol. 24, no. 10, pp. 779–796, October 1998. [9] K. H. Braithwaite and J. M. Atlee, “Towards automated detection of evidence for the flexibility of BIP and its applicability to feature interactions,” in Feature Interactions in Telecommunications a wide variety of hardware and software systems, to our Systems. IOS Press, 1994, pp. 36–59. knowledge, there are no existing studies that analyze the use [10] C. Prehofer, “An object-oriented approach to feature interaction,” in Feature Interactions in Telecommunications Systems IV. IOS Press, of BIP in the context of the Feature Interaction Problem. We 1997, pp. 313–325. provide both an analysis of its use to compose and analyze [11] B. Stepien, “Feature description and feature interaction analysis with features and a comparison of design strategies for specifying use case maps and lotos,” in Feature Interactions in Telecommunications Systems VI. IOS Press, 2000, pp. 274–289. feature-oriented systems in BIP. [12] S. Apel, A. von Rhein, T. Thüm, and C. Kästner, “Feature-interaction detection based on feature-based specifications,” Computer Networks, VI. C ONCLUSION vol. 57, no. 12, pp. 2399 – 2409, 2013. In summary, we investigated the effectiveness of BIP2 for [13] M. Heisel and J. Souquieres, “A heuristic approach to detect feature interactions in requirements,” in Feature Interactions in Telecommuni- modelling feature-rich systems, with particular attention to the cations Systems V. IOS Press, 1998, pp. 165–171. amount of work needed to compose features, the amount of [14] J. Bredereke, “Families of formal requirements in telephone switching,” re-work needed to evolve a model to integrate new features, in Feature Interactions in Telecommunications Systems VI. IOS Press, 2000, pp. 257–273. and the degree of complexity of the resulting model. Each [15] D. O. Keck, “A tool for the identification of interaction-prone call of the three strategies that we studied has its advantages and scenarios,” in Feature Interactions in Telecommunications Systems V. its weaknesses. Ultimately, when considering which strategies IOS Press, 1998, pp. 276–290. [16] J. Hay and J. Atlee, “Composing features and resolving interactions,” help to address the Feature Interaction Problem, the pipe-and- in Proceedings of ACM SIGSOFT Foundations of Software Engineering filter approach is the more effective design methodology: (1) (FSE), 2000, pp. 110–119. it supports and preserves feature modularity, even when new [17] A. Basu, L. Mounier, M. Poulhiès, J. Pulou, and J. Sifakis, “Using BIP for modeling and verification of networked systems - a case study features are added to the system, and (2) the amount of work on Tiny OS-based networks,” in Proceedings of the Sixth IEEE Interna- and re-work needed to add a new feature is substantially less tional Symposium on Network Computing and Applications, Cambridge, than in the other two strategies. USA, July 2007, pp. 257–260. [18] P. Bourgos, A. Basu, S. Bensalem, K. Huang, and J. Sifakis, “Integrating R EFERENCES architectural constraints in application software by source-to-source transformation in BIP,” Verimag Research Report, Tech. Rep. TR-2011- [1] T. Bowen, F. Dworack, C. Chow, N. Griffeth, G. Herman, and Y.-J. 1, January 2011. Lin, “The feature interaction problem in telecommunications systems,”