2.3 An overview of Formal Methods
2.3.1 Classification of Formal Methods
Based of different criteria like syntax, underlying semantics or targeted systems , formal methods could be classified in different classes. A very general classification is presented in [137], which classify formal methods to three main classes, namely Model-oriented, Property-oriented andVisual languages.
• Model-oriented: In model-oriented method, a specifier defines a system’s be-
havior directly by constructing a model of the system in terms of mathematical structures such as tuples, relations, functions, sets, and sequences.
• Property-oriented: Using a property-oriented method, a specifier defines the
system’s behavior indirectly by stating a set of properties, usually in the form of a set of axioms, that the system must satisfy.
• Visual languages:Visual methods include any whose language contains graphical
A more detailed and precise classification of formal methods is presented in [81, 80]which formal methods have been classified into the following five classes or types, i.e. Model- based, Logic-based, Algebraic, Process Algebra and Net-based (Graphical)
methods. In the following subsections we will briefly discuss each of these approaches.
Model-based Methods.
A system is modelled by explicitly giving definition of states and operations that trans- form the system from a state to another. In this approach, there is no explicit repre- sentation of concurrency. Non-functional requirements (such as temporal requirement) could be expressed in some cases. There are three most popular model-based formalisms:
• Z [128].
• VDM [69].
• B-Method [2]
Logic-based Approach.
In this approach logics are used to describe system desired properties, including low-level specification, temporal and probabilistic behaviours. The validity of these properties is achieved using the associated axiom system of the related logic. In some cases, a subset of the logic can be executed, for example the Tempura system [100]. The executable specification can then be used for simulation and rapid prototyping purposes. Logic can be augmented with some concrete programming constructs to obtain what is known as wide spectrum formalism. The development of systems in this case is achieved by a set of correctness preserving refinement steps. Examples of this form are TAM [120] and the Refinement Calculus [119]. Below some popular logic-based formalisms have been listed:
• Hoare Logic [42].
• Modal Logic [104].
• Temporal Logic [90].
• TLA And TLA+ [76, 77].
Algebraic Approach.
In this approach, an explicit definition of operations is given by relating the behaviour of different operations without defining states. This is similar to the model-based approach where there is no explicit representation of concurrency. Below some popular algebraic- based formalisms have been listed:
• OBJ [68].
• LARCH [60].
Process Algebra Approach.
In this approach, explicit representation of concurrent processes is allowed. System be- haviour is represented by constraints on all allowable observable communication between processes. Below some popular process algebra-based formalisms have been listed:
• CSP(Communicating Sequential Processes) [64].
• CCS(Calculus of Communicating Systems) [96].
• ACP(Algebra of Communicating Processes) [19].
• LOTOS [67].
Net-Based Approach.
Graphical notations are popular notations for specifying systems as they are easier to comprehend and, hence, more accessible to nonspecialists. In this approach, graphical languages with a formal semantics are used, which bring special advantages in system development and re-engineering. Below some popular Net-Based formalisms have been listed:
• Petri Net [112].
• Statecharts [133].
Comprehensive comparison of different formal methods has been presented in [81, 80]. The results have been illustrated in the form of some tables which for each specific method shows to what extend it could be suited with respect to some given criteria like automated tool support, reliability, industrial strength and so on. Based on this study the B-Method is very good in the term of automated tool support and reliability with real industrial applications (such as the Paris Metro Line 14). As we consider the use
of B-Method for our system modelling in the next section we present a more in depth discussion about it.
Here we should emphasise that providing a universal classification of formal methods is difficult because there is a wide range of possible criteria upon which the classification could be based. Any analysis may apply a different set of criteria. Possibly one useful criterion is the domain applicability of a method, but the available data on the applica- tion of formal methods is scant and poorly coordinated. Another attempt to provide a classification based on the theoretical basis of methods could be found in [14].
Another common classification of formal approaches from behavioural viewpoint is to partition them into state-based (e.g. B-Method, TLA or Z), usually rooted in logics, and event-based (e.g. CSP, CCS or LOTOS), with algebraic roots [1, 29, 28]. In the following paragraphs definitions of these two different approaches have been provided:
State-based: The focus is on capturing the system state at the right level of abstraction. In a state-based approach, an execution of a system is viewed as a sequence of states, where a state is an assignment of values to some set of components. The model of the system should also include an initial state and a precondition for each operation.
Event-based: The focus is on identifying all the relevant events of the system and then describing in what order these events are allowed to happen. To specify an event- based system, we must determine: the collection of events relevant to the system; the initial enabled events of the system (events which are immediately possible). Event- based approaches are suitable for modeling distributed and concurrent systems such as mail servers, telephony, communication protocols etc. The event-based style has become prevalent for large-scale distributed applications due to the inherent loose coupling of the participants. It facilitates the clear separation of communication from computation and carries the potential for easy integration of autonomous, heterogeneous components into complex systems that are easy to evolve and scale [48].
It is well-known that the two frameworks are interchangeable [1, 29]. For instance, an action can be encoded as a change in state variables, and likewise one can model a state change with different actions to reflect different values of its internal variables. However, converting from one representation to the other often leads to a significant enlargement of the state space. Moreover, neither approach on its own is practical when it comes to modular software, in which actions are often data-dependent: considerable domain expertise is then required to annotate the program and to specify proper claims. In our approach we consider the B-Method as a Model-Based method. Considering the fact that we have two different version of the B-Method known asstandard B and Event-B [8, 38] provides a sound justification for this decision. We will provide more details about these versions in the latter sections.