Reliability Prediction Evaluation: Input Value Propagation

One of the crucial aspects of our Reliability Prediction approach, distinguishing it from related work, is the input value propagation (also called value passing). Thanks to the value propagation, the input characteristics of the usage profile can be transparently separated from the rest of the system model, and hence facilitate model changes (both manual and automated) in case of new information about system usage.

In most of the related architecture-based reliability approaches, the value propagation cannot be modelled explicitly. However, it can often be encoded into the message names, similarly to the encoding used in process algebra to show that the expressive power of an algebra with and without value passing is identical [1]. On the other hand, one needs to have in mind that the encoding may increase the model size exponentially [1], which is illustrated below.

Example

Consider the model of a very simple library system in Figure 1. The model includes a simple usage scenario of a library visitor and two components with two services, findBook() and archiveSearch(). The usage scenario consists of three subsequent calls to the findBook() service, each with an input parameter X=1 (implying low complexity of the search). FindBook() is modelled as a loop of two call actions to archiveSearch(), where the loop count is given by the parameter X and the parameter also propagated to the called archiveSearch(). The internal behaviour of the archiveSearch() service is again modelled as a loop with a loop count given by the parameter Y.

Figure 1: Example of a Model with Parameters

Encoding of the model in Figure 1 into a model without value propagation is depicted in Figure 2. The model includes one instance of the findBook() service and two instances of the archiveSearch() service, each having the parameter value in its name, i.e. findBook1(), archiveSearch1() and archiveSearch2().

Figure 2: Model from Figure 1 without Parameters

Now consider a simple update of the visitor usage profile, changing the input values of the second and third call action to X=2 and X=3 (implying higher complexity of the search). The difference in model change for the models discussed above (Figure 1 and 2) is demonstrated in Figure 3 and 4. While the change of the model with explicit value propagation (Figure 1 and 3) requires only two parameter changes, the change of the model without explicit value propagation (Figure 2 and 4) requires an introduction of five more service models, with 23 new call actions, comparing to the 5 call actions of the original three services.

Figure 3: Model from Figure 1 after Update (with Parameters)

Figure 4: Model from Figure 2 after Update (without Parameters)

Discussion

Although the example above already gives a good intuition on the model-size increase, it still represents a very simple system, far not demonstrating the worst-case scenario. Note that each service in the example has only a single input parameter. If there were for instance two parameters of the findBook() service ranging from 1 to 2, four possible instances of this service could appear in the model, i.e. findBook11(), findBook12(), findBook21(), findBook22(). In the case of two parameters ranging from 1 to 3, nine instances could appear in the model. Hence already on the level of service instances, a simple increase of parameter range (from 2 to 3) may imply an exponential growth of the model. This can be further strengthen by the presence of loops in the model and parameter changes propagated to the next services (X*2, X*3, etc.), which is already illustrated on the example above.

References

[1] R. Milner, Communication and Concurrency. Prentice Hall, 1989, iSBN 0-13-115007-3.