Dependability (the degree of reliance that can be justifiably placed on software-intensive systems) is characterized by several attributes, including availability. In this chapter, we refer to network availability as the “network readiness for correct service” and model various network availability aspects such as resource accessibility, network nodes readiness, and replication. Moreover, we put forward our approach of embedding these aspects onto a specification of a distributed application for whom the network is generic. In this way, we adapt the application to a specific network. Our approach is based on a formal method (topological action systems) and its refinement notion, while our presentation in this chapter is example-based.
TopIntroduction
The concept of dependability refers to the degree of reliance that can be justifiably placed on software-intensive systems (Laprie, 1985; Avizienis, Laprie, Randell & Landwehr, 2004). In this context, availability is the attribute of dependability that describes the ‘readiness of correct service’, including the absence of system failures when the system is needed. A failure describes a situation when the system does not behave according to its specification, so that this misbehavior is observable by users of the system. System failures are overcome by recovering the system and can be prevented by scheduling downtime for maintaining the system.
Checking the degree of availability of an application implies measuring the actual time the application is running, denoted as MTBF (Mean Time Between Failures), i.e., the average time the application is running between failures against the sum of this running time and the application downtime, denoted as MTBF+MTTR, where MTTR (Mean Time To Repair) denotes the average downtime of the application due to (recovering from) failures. Both MTBF and MTTR figures are measured quantities. This approach to availability, as a measurable figure, is specific to the dependability view (Laprie, 1985; Avizienis, Laprie, Randell & Landwehr, 2004).
A compatible approach to availability is provided by the software architecture view (Bass, Clements & Kazman, 2007). In this setting, we distinguish between the system’s functionality and its non-functional properties, such as availability, security, modifiability, etc. While functionality refers to the system services, capabilities, and behavior, the non-functional properties refer to how well, from a given point of view, the system functionality is implemented. Functional and non-functional qualities are not depending on each other. For instance, a system can be implemented as a monolithic structure with only one huge module as long as the required functionality is achieved. Typically though, by implementing the system as a set of communicating modules, the same functionality can be achieved with better system availability, security, and modifiability.
The software architecture view promotes a constructive – as opposed to measuring – approach to availability and the other non-functional properties. To ensure this, various tactics are employed for each property. The availability tactics include fault detection, recovery-preparation and repair, recovery-reintroduction, and fault prevention. These tactics are illustrated in Figure 1, initially published in (Bass, Clements & Kazman, 2007).
Figure 1. Availability Tactics (Adapted from [Bass, Clements & Kazman, 2007])
In this chapter, we put forward a constructive approach to availability and we ensure that the corresponding availability constructions correctly integrate onto the application. More precisely, we are concerned with investigating the network availability features needed for a distributed application. We employ a language named MIDAS (Petre, Sere & Waldén, 2006), introduced for modeling middleware aspects for network computing. The fundamental feature of MIDAS is the proposal of a separation of concerns with respect to functional and non-functional aspects. We observe that this is a different approach with respect to a development process in which the non-functional requirements, for instance a system specified to be 99.9% available, are included in the initial system model. In our approach we separate the functional and non-functional properties and study how the latter properties can be embedded onto the system, once the former properties are specified.