=Paper=
{{Paper
|id=Vol-1723/1
|storemode=property
|title=Feature-Oriented Modelling in BIP: A Case Study
|pdfUrl=https://ceur-ws.org/Vol-1723/1.pdf
|volume=Vol-1723
|authors=Cecylia Bocovich,Jo Atlee
|dblpUrl=https://dblp.org/rec/conf/models/BocovichA16
}}
==Feature-Oriented Modelling in BIP: A Case Study==
https://ceur-ws.org/Vol-1723/1.pdf
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,”