Family-Based Modeling and Analysis for Probabilistic Systems – Featuring ProFeat

2.1 Feature Modeling

A product line comprises a set of feature combinations, which are defined through a feature model. For the producer-consumer product line, the following figure

Open image in new window

depicts a feature diagram, the standard formalism to define feature models in the software-engineering domain, and a part of its declaration in ProFeat. Similar to feature diagrams, where each feature is represented by a rectangular node, ProFeat uses textual feature-blocks to declare features and also has a tree-like structure. The root feature (denoted by System in the diagram) is a special feature, representing the base functionality on which the product line is built upon. Each feature can be decomposed into one or more sub-features. Here, the System is decomposed into four sub-features. An all of decomposition indicates that all sub-features are required in every feature combination whenever their parent feature is active. As used by the Workers feature, the some of operator implies that at least one of the sub-features has to be active if the parent is active. In addition to the one of operator (which requires exactly one sub-feature), the decomposition can also be given by a cardinality. Optional features are preceded by the optional keyword, indicating that the feature may or may not be part of a valid feature combination, regardless of the decomposition operator. ProFeat has built-in support for multi-features [15], i.e., features that can appear more than once in a feature combination. The number of instances is given in brackets behind the feature name. In the producer-consumer example, the Workers feature is decomposed into three distinct copies of the Worker feature. It is important to note that the decomposition operator ranges over the feature instances. Thus, the some operator could be replaced by cardinality [1..3] in the above listing. Multi-features can be marked optional as well. Then, each individual copy of the multi-feature is an optional feature. Besides multi-features, the ProFeat language supports non-Boolean features in the form of numeric feature attributes [8]. In the example shown above, the Worker has the attribute speed which can take any integer value from 1 to 5. Access to feature attributes is possible regardless of whether the corresponding feature is active or not. The combination of multi-features and feature attributes enables a compact representation of complex product lines.

The introduction of multi-features necessitates the distinction between features and feature instances. In ProFeat, each feature instance is uniquely identified by its fully qualified name. Sub-feature instances as well as feature attributes are addressed using the familiar dot-notation. Instances of multi-features are referred to by an array-like syntax. For example, the fully qualified name of the second worker’s speed attribute is root.Workers.Worker[1].speed. As long as the qualified name is unambiguous, the prefix can be omitted. For instance, the name Worker[1].speed is valid as well.

A feature block may also contain cross-tree constraints over feature instances and feature attributes. In our example, the first constraint given in the root feature expresses that the first two Worker instances must be active whenever the Fast feature is active. The second constraint limits the accumulated speed of the first two workers. A constraint can be preceded by the initial keyword, which only affects the initial set of valid feature combinations. Obviously, this distinction is only relevant for dynamic product lines.

Behavior of Features. In a ProFeat model, the declarative feature model is strictly separated from the operational behavior of features. A feature may be

Open image in new window

“implemented” by one or more feature modules, which are listed after the modules keyword inside the feature block. In our running example, the Worker feature is implemented by the Worker_impl module. The listing on the left shows the feature module and the extended feature declaration of the Worker feature. For the definition of feature modules, we use an extension of Prism’s guarded command language. Besides Boolean or integer variables defined in feature modules as in Prism, ProFeat supports (one dimensional) arrays. A set of commands defines the behavior of the feature module, having the form \(\textit{guard} \rightarrow \textit{stochastic-update}\). If the guard evaluates to true, the module can transition (with some probability) into a successor state defined through the updates of the variables. Consider the following command of the producer feature module.

Open image in new window

Here, the producer enqueues a work package of size 2 with a probability 0.1 if the buffer is not full. The guard expression may reference the local variables of other feature modules. Furthermore, the built-in active function can be used in guards, evaluating to true if applied to a feature which is currently active.

Another means for communication besides shared variables is synchronization between feature modules. A command can be labeled with an action that is placed between the square brackets preceding the guard. If two or more modules share an action, they are forced to take the labeled transitions simultaneously. However, if any of those modules cannot take the transition (because its guard is not fulfilled), then the action is blocked, so that none of the modules can take the transition. In our running example, a worker synchronizes with the feature module implementing the FIFO buffer over the dequeue action to obtain a new work package (line 11). In ProFeat, action labels can be indexed using an array-like syntax. In case of multi-features, the implicit id parameter evaluates to the index of the feature instance. Thus, there exist three distinct dequeue actions in our model. By default, feature modules of inactive features do not block actions. Thus, with regard to synchronization, deactivating a feature has the same effect as removing it entirely from the model. This is useful if the model is fully synchronous, i.e., if there is a global action that synchronizes over all transitions. However, in some cases it is crucial that an inactive feature hinders active features to synchronize with its actions. In the producer-consumer example, an inactive worker should not take a work package out of the queue (line 11). Therefore, its dequeue action is modeled as blocking using the block keyword inside the feature module (line 3).

Specification of Costs and Rewards. As in Prism, states and transitions in ProFeat can be  augmented  with  costs  and  rewards. This allows reasoning

Open image in new window

about quantitative measures, such as energy consumption, performance and throughput. Costs and rewards are defined as a part of feature declarations using the keyword rewards. In the listing on the left, the energy consumption of a worker is specified depending on its processing speed.

Feature Controller. In a ProFeat model, the feature combination is not necessarily static, but may also change over time. The feature controller is a special module that defines the rules for the dynamic activation and deactivation of features, whose declaration we exemplify within our producer-consumer model:

Open image in new window

Essentially, a controller is a module, which can modify feature combinations using the activate and deactivate updates. In the controller shown above, the third worker is activated to speed up processing whenever the buffer is full. Once the buffer is nearly empty, the worker is deactivated. The definition of a feature controller is optional. If no controller is given, the defined product line is assumed to be static. Feature modules can synchronize with the controller over the activate and deactivate actions, which enables them to react or even block the activation or deactivation of their corresponding feature. For instance, by adding the following line to the Worker_impl module, the deactivation of the worker is blocked as long as it is still processing a work package:

Open image in new window

Templates and Metaprogramming.ProFeat also provides constructs commonly found in template engines but not included in Prism’s input language. Commands can be generated at translation time by using for loops. Furthermore, feature blocks as well as feature modules can be parametrized, which, in turn, allows for parametrization of guards, probabilities and costs/rewards. These feature and module templates are instantiated by referencing them in a decomposition or using the modules keyword, respectively. Consider the following excerpt of the feature module implementing the FIFO buffer:

Open image in new window

The module is parametrized over the capacity of the buffer (line 1). The for loop stretching from line 3 to 7 generates a dequeue labeled command for each worker. The inner loop (lines 6) shifts the buffer entries to remove the first element from the buffer.

2.2 Parametrization

While ProFeat provides special support for feature-oriented modeling, families can also be formed by ranging over system parameters. In our running example,

Open image in new window

such a parameter might be the FIFO buffer size. Parameters are declared in a family block, as shown on the left. Similar to feature attributes, system parameters can be constrained as well. Furthermore, a family declaration can be combined with a feature model, resulting in a family that is both defined by system parameters and all valid initial feature combinations. To declare subsets of valid feature combinations as initial ones, ProFeat provides the initial constraint keyword (see line 3 of the listing). Valid feature combinations not fulfilling the listed constraints are still possible during runtime by dynamic feature switches.

System parameters can be used anywhere in the model description, including guards, probabilities and costs/rewards. In contrast to feature attributes, system parameters are constant for each instance of a family. This has an important consequence: parameters can be used to specify the range of variables, the size of arrays, the range of for loops and even the number of multi-feature instances. Thus, system parameters can directly influence the structure of the system.

3.1 Translation of Feature-Specific Constructs

In ProFeat, the access to the feature combination is provided through the use of the active function and the activate and deactivate updates of the feature controller. We encode feature combinations by a set of integer variables with range [0..1], which simplifies the handling of feature cardinalities (compared to a Boolean encoding). Instead of creating one variable per feature instance, the tool generates one variable per atomic set to reduce the number of variables: An atomic set is a set of features that can be treated as a unit as they never appear separately in a feature combination [38]. Given this representation, the translation of the active function is simple: The call to active is replaced by a check testing whether the atomic-set variable evaluates to 1. Analogously, the activate and deactivate updates assign a 0 or a 1 to the corresponding variable, respectively. However, the feature controller cannot change the feature combination arbitrarily: As an update has to yield a valid feature combination, the translation has to add a guard to commands containing atomic-set variable updates. This guard is synthesized from the feature model and evaluates to false if the transition described by the command would result in an invalid feature combination.

Another aspect of the translation concerns the synchronization between the feature controller and the feature modules in case of feature activation and deactivation. Implicitly, an \(\textit{activate}_f\) action and a \(\textit{deactivate}_f\) action is created for each feature instance f. In Prism, commands can only be labeled with a single action. However, an update may activate or deactivate multiple feature instances at once, thus requiring multiple action labels per command for synchronization. To circumvent this restriction of the Prism language, the set of action labels is merged into a single action label. This solution requires special care in the translation of feature modules. Let us assume a command C labeled with the action \(\textit{activate}_f\). Then, we collect the action labels of all feature-controller commands that activate the feature instance f. Finally, we create a copy of the command C for each collected action label. This translation realizes the intended synchronization between the feature controller and the feature modules, even in the case of multiple simultaneous feature activations and deactivations.

Lastly, the translation must ensure that feature modules of inactive features do not block actions, i.e., deactivating a feature should have the same effect as removing the corresponding feature modules from the model. To achieve this behavior, we take the following approach. Suppose the feature module M implements the feature instance f. Then, for each command in M that has the form \([\alpha ]~\textit{guard} \rightarrow \textit{update}\), a command \([\alpha ]~\lnot \texttt {active}(f) \rightarrow \textit{true}\) is generated. Thus, if the feature instance f is not active, the translated module does not block the action \(\alpha \). However, this command is not generated if the user explicitly requests the blocking of action \(\alpha \) by using the block keyword in the feature declaration.

3.2 All-in-One and One-by-One Translation

Essentially, there are two different approaches for the analysis of a family of systems described by some ProFeat model: The one-by-one and the all-in-one approach. Within a one-by-one approach, each member of the family is analyzed separately. Differently, within an all-in-one approach, the whole family is encoded into a single Prism model and analyzed in a single run. The result of the all-in-one analysis is then interpreted for each member of the family, providing results as the members would have been analyzed separately. An all-in-one approach can potentially exploit the similarities between the family instances and speed up the analysis, but may require additional memory. However, a big advantage of the one-by-one approach is that it can be easily parallelized. As we illustrate in our case studies (see Sect. 4), it depends on the model as well as the time and memory constraints which approach is appropriate. For this reason, ProFeat supports both, an all-in-one and a one-by-one translation of the family model. Switching from one analysis approach to the other requires no adjustments to the model.

In case of one-by-one translation, ProFeat generates a Prism model for every instance of the family. That is, for each valid valuation of the system parameters and for each initial feature combination, the system parameters are replaced by constants. If no family block is given, then one model for each valid initial feature combination is generated. The all-in-one translation generates a single Prism model with multiple initial states, one for each instance of the family. However, there is a technical difficulty in the translation into an all-in-one model: Array sizes, numbers of multi-features and variable bounds can be defined in terms of system parameters. Hence, these parameters might depend on the initial state and thus are not known at translation time. Therefore, ProFeat instantiates these parametrized structures with their maximal size.

4.1 The Producer-Consumer Example

Figure 1a shows the number of MTBDD nodes for representing the three model variants depending on the family parameter. Within all variants, the number of nodes in the all-in-one model is significantly smaller that the sum of the MTBDD nodes for the separate models, indicating shared behaviors between the family members. We evaluated the quantitative queries stated above using both, the Mtbdd and the Sparse engine of \(\textsc {Prism}\). In general, the Sparse engine turned out to perform slightly better than the Mtbdd engine, especially within expectation queries. The results are illustrated in Fig. 1b–d.

Open image in new window

In some cases, where the number of instances is exponential in the family parameter (cf. Fig. 1c – Best Worker), the all-in-one analysis approach outperforms the one-by-one approach and can even keep up with the parallel computation. In other cases (cf. Fig. 1b – Best Buffer), the all-in-one approach was only superior up to a system size of 14. For the third model variant (cf. Fig. 1d – Distributions), the all-in-one and one-by-one approaches asymptotically displayed similar performance. Overall, there is a no clear trend on which approach is favorable, the one-by-one or the all-in-one analysis.

4.2 Feature-Aware Case Studies

The development of \(\textsc {ProFeat}\) has been first and foremost motivated by several studies from the domain of feature-oriented systems such as product lines, where all-in-one analysis approaches turned out to outperform the traditional one-by-one analysis approach. In this section, we demonstrate how (probabilistic) versions of classical product lines can be modeled and analyzed with \(\textsc {ProFeat}\).

Body Sensor Network Product Line. A Body Sensor Network (BSN) system is a network of connected sensors sending measurements to a central entity which evaluates the data and identifies health critical situations. In [37], a BSN product line with features for several sensors has been introduced. The approach presented in [37] follows the ideas by [23] towards parameterized DTMC models: For each feature, a Boolean parameter f is 1 if the feature is active and 0 otherwise. A factor p is multiplied to the probability of every transition, where \(p{=}f\) in case the feature enables the transition and \(p=1{-}f\) otherwise. Parametric model checkers are then used to compute a single formula which for each feature combination evaluates to the probability of reaching a successful configuration, i.e., the reliability of the BSN. The authors of [37] report that the parametric approach using \(\textsc {Param}\) can be seven times faster, a novel symbolic bounded-search approach can be eleven times faster, and a handcrafted (model dependent) compositional parametric approach can even be 100 times faster than a \(\textsc {Prism}\)-based one-by-one analysis. For obtaining the results, three different model-checking tools have been used. Furthermore, special tailored scripts were required to perform the one-by-one analysis and to evaluate the formulas returned by the parametric model checkers. With \(\textsc {ProFeat}\) the feature model of the BSN product line can be directly incorporated into the parametric model specified by [37], as \(\textsc {ProFeat}\)’s representation of features as Boolean parameters is compatible with the approach by [23]. Thus, \(\textsc {ProFeat}\) allows for an all-in-one approach on the same model as of [37] and simplifies the comparison to one-by-one analysis also concerning different model-checking engines such as the explicit or symbolic engines of \(\textsc {Prism}\).

In the first line of Table 1, we show the results of our experiments for computing the same reliability probability as in [37]. The all-in-one approach turns out to be \(\approx \)100 times faster than the one-by-one approach, independent of the chosen engine. Hence, \(\textsc {ProFeat}\) directly enables a speed up of the analysis time in the same magnitude as handcrafted decomposition optimizations by [37].

Elevator Product Line. A classical (non-probabilistic) product line considers an elevator system, introduced by [36] for checking feature interactions. It has been then considered in several case studies issuing family-based product-line verification (see, e.g., [4, 15]). An elevator system is modeled by a cabin which can transport persons to floors of a building. The persons first have to push a button at the floor and then in the cabin for calling the elevator and defining a direction where to ride, respectively. In its basic version [36], the product line comprises 32 products built by five features, not changeable after deployment. We extend this product line in various aspects. First, we resolve some non-deterministic choices by probabilities when appropriate, e.g., modeling the request rate of a person and introducing a probability of failure. Second, we add a service feature, which enables to call technical staff repairing the elevator or change feature combinations. As a consequence, our elevator system is a dynamic product line where features can be changed during runtime. Third, we modeled dynamic feature changes as non-deterministic choices in the feature controller. This yields an MDP model for which a strategy-synthesis problem can be considered: Compute best- and worst-case strategies on how to activate or deactivate features to reach certain goals [21]. We deal with a simple instance of the elevator which can transport one person and where at most two persons act in the system. Our product lines have 64 feature combinations each, parametrized over the number of floors (2-4) in the building. We finally consider the family of the three product lines, containing 192 single instances of the elevator system. We asked for the minimal probability that if the cabin is on the ground floor and the top floor is requested, the probability to serve the top floor within the next three steps is greater than 0.99. Our analysis results are depicted in Table 1, where especially for larger instances the Mtbdd all-in-one analysis outperforms other approaches and engines. Notice that the number of MTBDD nodes of the family model containing all three elevator product lines (cf. the row above the double rule) is greater than the sum of nodes of the family models for each product line. Possibly, other MTBDD variable orderings, e.g., provided by methods presented in [31], could yield smaller model representations and faster all-in-one analyses.

4.3 Benchmark Suite Examples