Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Safety Critical Systems are life saving systems consistently used by engineers and commoners. Examples of safety critical systems vary from high budget systems like nuclear power plants and airplanes to low budget yet life critical systems like fire alarms, railway signaling and traffic control. Their failure may lead to death, damage to an equipment or environmental harm [1]. For example, Therac-25 [2, 3] was a medical equipment whose malfunctioning gave massive overdoses of radiation to patients. This can be overcome by writing specifications for a system.

Specifications are required to analyze a system and to aid its design by verifying the key properties of interest [4]. Specification languages namely, ASLAN [5] and Prototype Verification System (PVS) [6] can be used to achieve this goal. Although, specifications are not readily used in software development(in spite of the presence of advanced language like PVS), [7] gives an example of a system that is critical to the safety of an animal keeper and proposes specifications for the system.

This research focuses on formally specifying a multi-window user interface in PVS which has already been specified in ASLAN [8]. PVS system is based on the idea of a window manager used for control and monitoring of a critical system such as NASA’s space shuttle [9].

The ASLAN specification has a limitation as it does not elaborate on issue of losing input focus [10] but the resulting PVS specification has been modified to include input focus functionality. In addition, this research incorporates the differences between PVS and ASLAN. [11] contains detailed description of PVS and ASLAN codes.

This paper is structured as follows: Sect. 2 describes the system being used for writing specifications, Sect. 3 contains the results and additions made in the previous specification along with the differences in ASLAN and PVS specification [12] languages. Section 4 concludes the paper.

2 PVS System Description

Figure 1 gives a basic flow chart of PVS system displaying blocks of types, variables, constants, definitions, invariants, transitions and initial state of the system with an overview of their contents. The fundamental parts of PVS specification are explained further. There are three main states of windows namely, OPEN, CLOSED and UNUSED. All the windows are accessible to the user except one SPECIAL window. SPECIAL window has imperative critical programs running in it and thus, cannot be closed (iconified), moved or covered by other windows or icons. A structure has been defined with Locations, Sizes and Representations to keep a track of Layout of a window [8]. Constant functions like OVERLAPS deduce if a windows is at the front of another window. BACKGROUND gives information about the layouts of background windows and SPECIAL returns a boolean value if the window is a SPECIAL window. Variable functions like input_focus and output_focus take window as the argument and return the Layout of the open or close window. The specification has a set of functions that update the display when a window is opened, closed, created, destroyed or moved.

Initially, all the processes in the system are set to UNUSED state and input focus of all the states is FALSE. There are a few critical correctness criteria that have to be true at all times in the system e.g. if the window is in OPEN or CLOSED state then it should have open or closed layout. Also, SPECIAL window should not be overlapped at any time in the system.

In the PVS system, each user has a powerful display processor (DP) as their interface to the system. DP is capable of multiple sessions with remote applications and supports a mouse and window (direct manipulation) environment. This system is also required to use commercial off the shelf (COTS) [13] hardware and software wherever feasible.

Fig. 1.
figure 1

Block diagram of PVS Specification

Full size image

3 Results

The new system designed in this research, implements the functionality of input focus. Input focus concept is an important part of multi-window user interface because it determines which window is active when the user has not explicitly selected any window. This section also briefs the main differences between ASLAN and PVS as inferred from the translation.

3.1 Input Focus

A process is said to have input focus [10], if it is active and data can be read from and written to it. The formal specification in ASLAN, partially handles the focus by shifting it.

figure a

This transition states that for a window w1 that has input focus, make the input focus of window w, the same. The previous state of the window to which the focus has been shifted was open or closed. Focus is being handled here by shifting from all the windows to the entry window/input window that is given as argument. This transition does not completely control input focus. For example, assume that the user is working in window w1 and clicks outside of the window boundary. In that case, it is hard to determine the focus of window unless shift_focus is explicitly called to shift the focus to a particular window.

There are two cases to be taken care of:

  • When focus is lost e.g. user clicked out of the window

  • When a function changes focus from a window to another

The proposed solution to the first problem is that whenever the user clicks out of the window, the focus should be transferred to the most recent open window where the user was working unless he explicitly clicks on another window.

figure b

It checks if the focus was not true for any of the windows i.e. the user clicked out of the window and a window has previous layout open then the focus is set to that open window. ELSE part of this assertion handles UNUSED and performs the same function of setting the focus to previous open layout. Special windows are usually the UNUSED ones but there could be other windows with UNUSED status in the system.

Below function handles the transitions from one state to another. It sets the input focus to calling window depending on its state. If the state is UNUSED i.e. the window could be a special window, then it’s focus is handled by set_focus function.

Here, it has been assumed that closed windows may have input focus. update_focus works on this assumption as it gives input focus to closed window in Case 2.

figure c

3.2 ASLAN V/s PVS

PVS and ASLAN have a significant difference in their formal foundations [5], structure, backend development, and logic. Figure 2 lists the main differences between ASLAN and PVS.

Fig. 2.
figure 2

Differences between ASLAN and PVS

Full size image

4 Conclusion

This research specifies the concept of input focus in a multi-window user interface and provides differences between ASLAN and PVS specification languages. It can be concluded that PVS is practically more powerful than ASLAN with robust techniques to verify specification. PVS is easy to understand and can be readily applied for verifying and formulating safety critical system prototypes. PVS is very close to any other programming language like Java or C++. Features like allowance of partial implementation play as an advantage, giving user the power of abstraction. Since PVS has in built functions it reduces the lines of specification unlike ASLAN which operates on the concept of state machines and thus becomes un-manageable for declaring complex functions.