Using formal methods in distributed system design

Distributed systems are groups of networked computers, which have the same goal for their work. The terms "concurrent computing", "parallel computing", and "distributed computing" have a lot of overlap, and no clear distinction exists between them. The same system may be characterized both as "parallel" and "distributed"; the processors in a typical distributed system run concurrently in parallel. Parallel computing may be seen as a particular tightly coupled form of distributed computing, and distributed computing may be seen as a loosely coupled form of parallel computing. Nevertheless, it is possible to roughly classify concurrent systems as "parallel" or "distributed" using the following criteria. Philosophy is centrally concerned with arguments. The first question to be asked of any argument (or inference) is whether or not it is valid: that is, does its conclusion really follow from the cited premises? Validity of inference is the central problem of deductive logic.


Introduction
Recently, with the increasing demand benefit of using formal methods for modeling, we started seeing large number of applications using formal methods Examples of these methods include ASM (Borger & Stark, 2003), B (Abrial, 1996), and VDM (Jones, 1990).We have choosed Event-B as a formal method to show effectiveness of this method, which has possibility for developing system free of errors by verifying using Rodin model.
Formal verification of a program is the mathematical proof that it does what is expected of it.The 21st century has seen a vast worldwide interest in formal methods [1][2][3][4][5].While Rigorous descriptions promise to improve system reliability, design time and comprehensibility, they do so at the cost of an increased learning curve; the mathematical disciplines used to formally describe computational systems are outside the domain of a traditional engineering education.In addition, the meta-models used by most formal methods are often limited in order to enhance provability.There is a notable tradeoff between the need for rigor and the ability to model all behaviors.

The Event-B formalism
We present our formal development framework -Event-B (see Figure 1).The Event-B formalism is a state-based formal approach that promotes the correct-by-construction development paradigm and formal verification by theorem proving.
Event-B has been specifically designed to model and reason about parallel, distributed and reactive systems.Formal verification involves the application of mathematical proofs to every possible behavior allowed by a specification (Abrial, 1996).In a state-based specification the behavior is a transformation of the system moving from one state to another.Proof obligations are generated using the specification and the language rules These proof obligations then need to be discharged using properties of the specification.Event-B is a mathematical approach for developing formal models of systems (Abrial & Hallerstede, 2006) [11,7].An Event-B model is constructed from a collection of modelling elements.These elements include invariants, events, guards and actions.The modelling elements have attributes that can be based on set theory and predicate logic.Set theory is used to represent data types and the manipulation of data.Logic is used to apply conditions on the data.

The development of an Event-B model
The development of an Event-B model goes through two stages; abstraction and refinement.The abstract machine specifies the initial requirements of the system0 Refinement is carried out in several steps with each step adding more detail to the system, generally, but not exclusively, in a top-down manner Reactive systems (Harel & Pnueli, 1985) are systems that continually respond to changes in their environment.The focus on atomic events in Event-B creates a representation of a reactive system (Jones, 2005).The model transitions are triggered by changes in the state of the model, which can represent the system's environment.The guard on an event will allow or prevent an event from occurring depending on the state of the model.When none of the guards are true the system is deadlocked.Event-B is designed for modelling distributed systems (Abrial & Hallerstede, 2006).It implements the theory of discrete transition systems.Discrete transition systems, or action systems, model atomic actions that can be performed in parallel providing the actions do not affect the same state variables One method for specifying concurrency in Event-B is to model each update as a group of potentially interleaving atomic events (Edmunds & Butler, 2008) [1][2][3][4][5].
This allows the model to specify how concurrent execution can be dealt with by the system being modelled specifying a distributed system in Event-B takes a global approach.Rather than creating a specification for each component of the system it is modelled as a whole along with its environment.The model is closed in that it reacts only to changes in its internal state.Initially states are modelled abstractly with the events that describes the main goal of the system.Detail is added through refinement to describe the final distributed system.The ability to add new events and refine single events into multiple concrete events allows the functionality of the system to expand beyond that modelled in the abstract machine.Refinement ensures that the refined models are consistent with the abstract machine.

Event-B model
In Event-B, a system model is specified using the notion of an abstract state machine (Abrial, 2010) [6,8].An abstract state machine encapsulates the model state represented as a collection of model variables, and defines operations on the state, i.e. it describes the dynamic behavior of the modelled system.A machine may also have the accompanying component, called context (see Figure 2).A context might include userdefined carrier sets, constants and their properties, which are given as a list of model axioms.In Event-B, the model variables are strongly typed by the constraining predicates called invariants.Moreover, the invariants specify important properties that should be preserved during the system execution.A general form of Event-B models is given in (see Figure 3).
The machine is uniquely identified by its name M. The state variables, v are declared in the Variables clause and initialised in the Init event.The variables are strongly typed by the constraining predicates.I given in the Invariants clause.The invariant clause might also contain other predicates defining properties that should be preserved during system execution.
The dynamic behavior of the system is defined by the set of atomic events specified in the Events clause.Generally, an event can be defined as follows introduction to the event-B method and the Rodin [12,13].
We outline the general structure of an Event-B specification.A specification consists of a static part, specified in a context, and a dynamic part, specified in a machine.
An Event-B machine M1 may be declared to be a refinement of some other Event-B machine M0.In this case we refer to M0 as the abstract machine and M1 as the refined machine.Machine M1 is said to be a correct refinement of M0 if any behavior that may be exhibited by M1 is also a possible behavior of M0.Refinement represents our expectation that the behavior of M1 should conform to the behavior of M0.Of course declaring that M1 refines M0 does not on its own guarantee the correctness of a refinement.Rather the declaration gives rise to proof obligations that need to be discharged in order to guarantee the correctness of a refinement.When refining a machine, it is common to specify new types and constants to be used in the refinement.This is achieved by specifying a new context for the refined machine.If the specification of any new types and constants depend on the types and constants used by the abstract machine, the new context is declared to be an extension of the context of the abstract model.The relationships between a machine and its refinement, as well as their respective contexts, is illustrated by Figure 2.This figure shows the refinement declaration from M1 to M0, together with the relationships with their contexts.A refined context C1 is declared as an extension of the abstract context C0 meaning context C1 may refer to types and constants specified in context C0.The dashed line from machine M1 to context C0 indicates that M1 implicitly see definitions in C0 (via C1).An Event-B context contains the following elements: x Sets: Abstract types used in specification to distinguish various entities x Constants: Logical variables whose value remain constant x Axioms: Predicates that specify assumptions about the constants.
An Event-B machine contains the following elements: x Variables: State variables whose values can change x Invariants: Predicates that specify properties about the variable that should always, remain true.x Initialization: Initial values for the abstract variables x Events: Guarded actions specifying ways in which the variables can change.Events may have parameters.
A machine may see the static elements defined in a context meaning that these elements are visible within the machine.The structure of a specification is outlined (see Figure 3).

Our proposed model
Our model represent a client management model verified using Rodin too.

Conclusions
Communication and negotiation are very important characteristics of distributed systems; and in this paper we have presented some of the basic concepts in formal method using Event-B also we have presented verification of protocols in distributed systems., so we can say, event-B allows us to define a kind of modeling methodology by write the correct mathematical notions; wherefore we can apply event-B in modeling many different complex projects, but we should choose carefully invariants and variables to ease effort of proof.
As well as the Rodin tool offers reactive environment for constructing and analyzing models as do most modern integrated development environments, and provides integration between modeling and proving whereas this is important feature for the developers to focus on the modeling task without switch between different tools to check proving in same time.
The intent of this paper to give some insights on modelling and formal reasoning using Event-B method in distributing systems.