Limits...
Technique for Early Reliability Prediction of Software Components Using Behaviour Models

View Article: PubMed Central - PubMed

ABSTRACT

Behaviour models are the most commonly used input for predicting the reliability of a software system at the early design stage. A component behaviour model reveals the structure and behaviour of the component during the execution of system-level functionalities. There are various challenges related to component reliability prediction at the early design stage based on behaviour models. For example, most of the current reliability techniques do not provide fine-grained sequential behaviour models of individual components and fail to consider the loop entry and exit points in the reliability computation. Moreover, some of the current techniques do not tackle the problem of operational data unavailability and the lack of analysis results that can be valuable for software architects at the early design stage. This paper proposes a reliability prediction technique that, pragmatically, synthesizes system behaviour in the form of a state machine, given a set of scenarios and corresponding constraints as input. The state machine is utilized as a base for generating the component-relevant operational data. The state machine is also used as a source for identifying the nodes and edges of a component probabilistic dependency graph (CPDG). Based on the CPDG, a stack-based algorithm is used to compute the reliability. The proposed technique is evaluated by a comparison with existing techniques and the application of sensitivity analysis to a robotic wheelchair system as a case study. The results indicate that the proposed technique is more relevant at the early design stage compared to existing works, and can provide a more realistic and meaningful prediction.

No MeSH data available.


Scenario preparation: (a) Elicited state variables of each component in the ATM example, (b) Scenario1 of Fig 2 after annotation based on the state variables and propagation.
© Copyright Policy
Related In: Results  -  Collection

License
getmorefigures.php?uid=PMC5036808&req=5

pone.0163346.g003: Scenario preparation: (a) Elicited state variables of each component in the ATM example, (b) Scenario1 of Fig 2 after annotation based on the state variables and propagation.

Mentions: The s-TSs enhance the current triggered scenario languages [27,28] by adding constructs that enable the writing of scenarios in a compact and concise manner in order to enhance the scalability of scenario modeling. At the early design stage when complete information about the behaviour of a system is not available, there is no option other than to leverage the system constraints and their state variables as basic information sources to enrich system scenarios which are already documented using s-TSs as mentioned previously. The constraints and their state variables (held in a system state vector) are elicited as domain knowledge related to the early design’s specifications. In order to prepare scenarios based on these information sources, in Step 1 we elicit a component’s state variables from the system state vector. The component’s state variables are used to define the constraints relevant to the component’s incoming and outgoing messages. In Step 2, the values of the component’s state variables which appear in the constraints table (Fig 2(a)) are used to annotate scenarios as pre- and post-conditions associated with each incoming and outgoing message of the component instance. Each component instance is annotated independently, depending on its own state variables list. The reason for this independence is that the goal is only to construct the behaviour model of the component (not the behaviour of the system that represented through the scenario). The values of some state variables may be marked as missing due to not having specifications. Thus, these missing values in the annotated scenarios need to be propagated in Step 3 of this phase using a propagation technique similar to the work by [29] and [30]. Fig 3(b) shows one of the scenarios in Fig 2 after implementing the scenario preparation steps.


Technique for Early Reliability Prediction of Software Components Using Behaviour Models
Scenario preparation: (a) Elicited state variables of each component in the ATM example, (b) Scenario1 of Fig 2 after annotation based on the state variables and propagation.
© Copyright Policy
Related In: Results  -  Collection

License
Show All Figures
getmorefigures.php?uid=PMC5036808&req=5

pone.0163346.g003: Scenario preparation: (a) Elicited state variables of each component in the ATM example, (b) Scenario1 of Fig 2 after annotation based on the state variables and propagation.
Mentions: The s-TSs enhance the current triggered scenario languages [27,28] by adding constructs that enable the writing of scenarios in a compact and concise manner in order to enhance the scalability of scenario modeling. At the early design stage when complete information about the behaviour of a system is not available, there is no option other than to leverage the system constraints and their state variables as basic information sources to enrich system scenarios which are already documented using s-TSs as mentioned previously. The constraints and their state variables (held in a system state vector) are elicited as domain knowledge related to the early design’s specifications. In order to prepare scenarios based on these information sources, in Step 1 we elicit a component’s state variables from the system state vector. The component’s state variables are used to define the constraints relevant to the component’s incoming and outgoing messages. In Step 2, the values of the component’s state variables which appear in the constraints table (Fig 2(a)) are used to annotate scenarios as pre- and post-conditions associated with each incoming and outgoing message of the component instance. Each component instance is annotated independently, depending on its own state variables list. The reason for this independence is that the goal is only to construct the behaviour model of the component (not the behaviour of the system that represented through the scenario). The values of some state variables may be marked as missing due to not having specifications. Thus, these missing values in the annotated scenarios need to be propagated in Step 3 of this phase using a propagation technique similar to the work by [29] and [30]. Fig 3(b) shows one of the scenarios in Fig 2 after implementing the scenario preparation steps.

View Article: PubMed Central - PubMed

ABSTRACT

Behaviour models are the most commonly used input for predicting the reliability of a software system at the early design stage. A component behaviour model reveals the structure and behaviour of the component during the execution of system-level functionalities. There are various challenges related to component reliability prediction at the early design stage based on behaviour models. For example, most of the current reliability techniques do not provide fine-grained sequential behaviour models of individual components and fail to consider the loop entry and exit points in the reliability computation. Moreover, some of the current techniques do not tackle the problem of operational data unavailability and the lack of analysis results that can be valuable for software architects at the early design stage. This paper proposes a reliability prediction technique that, pragmatically, synthesizes system behaviour in the form of a state machine, given a set of scenarios and corresponding constraints as input. The state machine is utilized as a base for generating the component-relevant operational data. The state machine is also used as a source for identifying the nodes and edges of a component probabilistic dependency graph (CPDG). Based on the CPDG, a stack-based algorithm is used to compute the reliability. The proposed technique is evaluated by a comparison with existing techniques and the application of sensitivity analysis to a robotic wheelchair system as a case study. The results indicate that the proposed technique is more relevant at the early design stage compared to existing works, and can provide a more realistic and meaningful prediction.

No MeSH data available.