# Reliability assessment support in UML.

1. INTRODUCTIONThe evaluation and testing of system in early stages of software development lifecycle is becoming important field of software engineering. The research in testing of functional requirements is well developed but the testing of non-functional requirements is still in the beginning. One of the most important non-functional requirements, which cannot be missed out when designing software system, is reliability. There exist several traditional approaches for reliability assessment of software systems but they have these main disadvantages:

1. Assessment of the reliability at the very end of software development lifecycle

2. Reliability evaluation of system as whole

3. Various reliability modelling techniques (reliability block diagrams, fault trees, Markov chains, etc.)

Our research focuses on developing the new reliability assessment approach which will evaluate the reliability of the system in early development stage using UML notations for modelling the assessed software system. First step of the research was to explore the work done in this field and to confirm the hypothesis that UML notations are appropriate for reliability assessment.

2. RELIABILITY ASSESSMENT USING UML MODELS

2.1 Approach Cortellessa et al.

This approach (Cortellessa et al., 2002) can assess reliability from early stage of software development lifecycle. It uses annotated UML diagrams:

1. Use Case diagram

2. Sequence diagram

3. Deployment diagram.

Use Case diagram is annotated as follows:

* [q.sub.1] and [q.sub.2] represent the probabilities of requesting services from system for users [u.sub.1] and [u.sub.2]

* [P.sub.11] and [P.sub.12] represent that user [u.sub.1] requests the functionality [f.sub.1] represented by use case [uc.sub.1] or [f.sub.2] represented by use case [uc.sub.2]

[FIGURE 1 OMITTED]

Then the probability of executing general use case x is:'

P(x) = [m.summation over (i=1) [q.sub.i] x [P.sub.ix] (1)

where m is the number of user types.

Then they assume that for each use case there are specified all relevant Sequence Diagrams representing main scenarios each use case. These sequence diagrams have the non-uniform probability distribution according to following equation:

P([k.sub.j]) = p(j) x [f.sub.j] (k) (2)

where [f.sub.j](k) is the frequency of the k-th overall the sequence diagrams referring to the j-th use case and parameter P([k.sub.j]) represents the probability of a scenario execution.

In sequence diagram, the approach focuses on the interval where the component is busy. For example, in Figure 2 the interval, when component [C.sub.3] is busy, is between the moment when interaction [l.sub.j] enters the component and interaction [l.sub.2] leaves the component. The total number of busy periods of component [C.sub.3] is 2.

[FIGURE 2 OMITTED]

Then the estimate of the probability of failure [[theta].sub.ij] of the component [C.sub.i] in the scenario j represents the next equation:

[MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII] (3)

where [bp.sub.ij] the number of busy periods that component [C.sub.i] has in the scenario j.

[FIGURE 3 OMITTED]

The deployment diagram in Figure 3 includes the same components from the sequence diagram. The subject of failure probability [[psi].sub.i] is every communication between components (l, m) through the connector i. and [absolute value of Interact(l, m, j)] represents the number of interactions between components l and m from the scenario (sequence diagram) j. e.g. there exist 2 interactions exchanged between [C.sub.2] and [C.sub.3] but only 1 interaction between [C.sub.1] and [C.sub.2].

Then the contribute [[psi].sub.imj] to the reliability of communication between all these components over the connector i in the scenario j is:

[[psi].sub.lmj] = [(1 - [[psi].sub.i]).sup.[absolute value of Interact(l,m,j)]] (4)

Finally the reliability of the whole system is combination is combination of equation (3) and (4)

[MATHEMATICAL EXPRESSION NOT REPRODUCIBLE IN ASCII] (5)

2.2 Approach of Rodrigues et al.

This approach can also be used in early stages of software development lifecycle for component-based systems. As basic modelling techniques, the scenarios and a Message Sequence Charts (MSC) are used (Rodrigues et al., 2005). The framework of the approach shows the Figure 5.

[FIGURE 5 OMITTED]

First step is annotation the MSCs with two kind probabilities:

1. Probability of transitions between scenarios [PTS.sub.ij]

2. Reliability of the components [R.sub.C].

PTS is simply the probability that scenario [S.sub.j] will be executed after executing scenario [S.sub.i] which value comes from an operational profile for the system (Musa, 1993). It is annotated on High-level Message Sequence Charts (HMSC).

The component reliability [R.sub.C] is the probability that component C will successfully perform its service which is invocated by message from another component. The execution time of the service is not significant for component reliability assessment. Component reliability is annotated on Basic Message Sequence Charts (BMSC).

Second step is to made synthesis of Labelled Transition System (LTS) from annotated scenarios. This step consists of several sub-steps to construct the architecture model of the system.

In the third step the architecture model is interpreted as Markov model. First the mapping of the probability weights from architecture model into a square transition matrix is constructed.

In the fourth step the Cheung approach (Cheung, 1993) is used to determine the reliability prediction of the whole system.

In last step, the implied scenarios are searching. These scenarios can be found as the result of the fact that in the system there can exist such set of components that don't communicate exclusively through the interfaces described and that can exhibit via unspecified traces when running in parallel (Uchitel, 2004). Founding of these scenarios has impact on step 1 and 2 of the approach's framework.

4. CONCLUSION

The present research made in this area shows that UML modelling techniques are applicable for reliability assessment of software.

We made also some thesis and assumptions:

* Sequence diagrams will be the core modelling technique for system architecture and behaviour

* We assume that developing of new UML extensions will be necessary for reliability assessment

* Our new approach will combine traditional reliability techniques with UML modelling

* The whole process of our reliability assessment approach will be automatic as much as possible

* The new tool which will cover our approach will be developed

* The approach will be developed with focus on control systems software

In this paper we discuss the area of software reliability and its support in UML. We also introduce the today's main approaches and concepts in this area, make the short evaluation of them and outlook the basis of our future work in this area.

5. REFERENCES

Cheung, R. C. (1980) A User-Oriented Software Reliability Model. IEEE Transactions on Software Engineering, vol. 6(2), pp. 118-125

Cortellessa, V., Singh H., Cukic, B. (2002). Early reliability assessment of UML based software models. Proceedings of the 3rd international workshop on Software and performance, Rome, Italy

Musa, J. D. (1993). Operational profiles in software-reliability engineering. IEEE Software, vol. 10, no. 2, pp. 14-32

Rodrigues, G. N., Rosenblum, D. S., Uchitel, S. (2005). Reliability prediction in model-driven development. Proceedings of the 8th international conference MoDELS pp. 339-354, Montego Bay, Jamaica

Uchitel, S., Kramer, J., Magee, J. (2004). Incremental Elaboration of Scenario-Based Specifications and Behavior Models Using Implied Scenarios. ACM Transactions on Software Engineering and Methodologies, vol. 13, pp. 37-85

Printer friendly Cite/link Email Feedback | |

Author: | Jedlicka, Martin; Moravcik, Oliver; Schreiber, Peter; Tanuska, Pavol |
---|---|

Publication: | Annals of DAAAM & Proceedings |

Date: | Jan 1, 2008 |

Words: | 1238 |

Previous Article: | Enterprise learning management system development guidelines. |

Next Article: | Open-loop control and data acquisition of a biomechanical research device using LabVIEW development environment. |