Essay: FORMAL METHODS: BENEFITS, CHALLENGES AND FUTURE DIRECTION

1. Abstract:
Now a days the demand for the current information system is increasing so to cope with that formal methods are used to slot in the use of higher degree of formalism in the development process.Formal methods are a particular kind of mathematically based techniques for the specification, development and verification of software and hardware systems. Detail analysis of goals, benefits and limitations are discussed in this paper. This paper helps the engineers to formally identify the different stages of development phases.
2. Introduction:
In today’s digital era, businesses are facing a challenge of releasing commercial software projects of quality on time and within budget. Many companies are facing the problem of releasing a quality software in time and on budget that fulfills the user’s needs. Most of the software is delivered with some errors, with lack of complete functionality and sometimes with cost overrun that effects the software metrics. If The problems are detected in the earlier phase i-e. development phase that will helps in reducing the project budget.
When the errors are detected in the requirement phase during testing then the developers must fix those errors and then check the results through design and implementation and then at the end the product is retested. In order to make software product secure and to overcome the problem of budget that occurs due to errors in requirement specifications that can cost up to a hundred times to correct, when detected later in the development life cycle. To tackle this problem the cost effective methods and techniques are required to deal with the major risks that ensures the evidence of trust worthiness.
Formal methods are one of the feasible solutions to the above stated problems to reduce the number of errors in the delivered product and are a cost-effective way of developing high integrity software. Formal methods can be applied at various phases of development process such as at requirement specification phase (eliciting, articulating and representing requirements), software design phase, implementation phase (code verification), testing and software maintenance phase. The representation used in formal methods is called a formal specification language. The formal specification languages are based on set theory and first order predicate calculus, but this mathematical background was initially not fully formalized. A formal specification language can be used to model the most complex systems using relatively simple mathematical entities, such as sets, relations and functions.
This paper describes different kinds of formal methods in requirements engineering. Beyond this introduction, the organization of paper is as follows: Section 2 presents a brief discussion on the existing formal methods, whereas in Section 3, detailed study of formal methods is done. Section 4 presents ‘Strengths and Weaknesses’ of each one and in Section 5, a ‘Comparative Study’ is done on the basis of the critical review. Section 6 presents ‘Future Research Directions’ in the area. ‘Conclusion and Future Work’ is reported in Section 7.
3. Related Work:
For accomplishing a comparative study of the aforementioned methodologies, some attributes have been identified based on the well known practices with similar cases. These are described as follows:
I. Concurrency Control: Concurrency is a property used in distributed system that enables software systems to be served in large-scale distributed systems. This property allows several computations to execute simultaneously, and potentially interact with each other.
II. Supporting Tools: It helps in automation of any process. Supporting tools makes the steps easier; therefore, tools support is highly recommended.
III. Support for Abstraction: Abstraction is the process by which data and programs are defined with a representation similar in form to its meaning (semantics), while hiding away the implementation details. Abstraction captures only essential details about an object that are relevant to the current perspective.
IV. Object Oriented Concept: The object oriented concepts such as inheritance, polymorphism, and encapsulation are supported by some formal specification languages. Object oriented programming is an approach for developing software system based on the concepts of classes and objects.
V. Structuring: It is a mechanism for combining specifications, for example, to handle error handling or status information.
VI. Requirements Phase Perspective: Requirements phase is the backbone of any software to be developed [18]. As it is well accepted by the research community, it is necessary for any methodology to consider this perspective
4. Methodology:
a) TYPES OF FORMAL SPECIFICATION STYLES:
4.1 Model- Based Languages :
The languages used for this class of specifications are characterized by the ability to describe the notion of internal state of the target system, and by their focus on the description of how the operations of the system modify this state. The underlying foundations are in discrete mathematics, set theory, category theory, and logic.
Abstract State Machines Proposed by Gurevich [58], abstract state machines (ASM), also called evolving algebras, form a specification language in which the notions of state and state transformation are central. A system is described in this formalism by the definition of states and by a finite set of (possibly non-deterministic) state transition rules, which describe the conditions (also called guards) under which a set of transformations (modifications of the machine’s internal state) take place.
There are three major model based language reported in the literature, which are given as follows:
i. Z-method
Pronounced “Zed”, developed in 1977 by Jean-Raymond Abrail, Steve Schuman and Betrand Meyer; it was later further developed at the programming research group at Oxford University. This is a model based language used in requirement specification and verification phase, based on Zermelo-Frankel set-theory, lambda-calculus and first-order predicate logic.
ii. VDM
The Vienna Development Method (VDM) is a formal language developed at the IBM laboratories in Vienna in the mid-1970s. It is a collection of techniques for the modeling, specification and design of computer-based system. It is a model based language used in specification phase. The most popular tool for VDM today (VDMTools) is a rather useful tool for development of formal models in VDM++ or VDM-SL.
VDM describes software systems and other systems as models [12]. Models are described as objects and operations on objects. The objects represent input, output and internal state of the system. It is based on abstraction to develop top-down development of systems. Requirement specification is typically given as a rather abstract model. The objects capture only necessary properties for expressing the essential concepts of the operation of the intended software system.
A VDM model has a specific role in application areas, such as semantics of programming language, databases and construction of compilers. For expressing the models Meta-IV, which is the specification language of VDM, is used. The models are defined using a number of type definitions (for the objects) and function definitions (for the operations). Meta-IV is aimed at supporting abstraction in writing specifications. Abstraction is obtained through mathematical concepts, such as sets and functions. The abstraction provided by Meta-IV offers a set of mathematically based primitives that allow the construction of application-specific models.
When using VDM, an abstract model traditionally contains the following components [12]:
• Semantic domains: These types describe the objects to be operated on.
• Invariants: Invariants are the Boolean functions that define a set of condition on the objects that is described by semantic domains.
• Syntactic domains: Types that define a “language” in which to express commands for manipulating the objects defined by the semantic domains.
• Well-formedness conditions: These are the functions that define when the commands, which is defined by the syntactic domains have a well-defined effect.
• Semantic functions: These functions provide the effect of commands on the objects defined by the semantic domains.
iii. B-method
The B method is developed by Jean- Raymond Abrail in 1985. It is based on Abstract Machine notation. This method is basically used for specifying, refining and implementing software [13]. A tool set is available supporting specification, design, proof and code generation [4].
The main concept follows in B- method is to initiate with an abstract model of the system under development, which roughly corresponds to the modules in many programming languages. A development process creates a number of proof obligations, which guarantee the correctness. Proof obligations can then be proven by automatic or interactive prover [14].
An abstract MACHINE of a given name contains information of CONSTANTS that describe the structure of the problem [14]. It includes PROPERTIES that describe the constants and ASSERTIONS which are the list of theorems that help in proving. The machine also includes VARIABLES, their INITIALIZATION and an INVARIANT, which describe the unchanging properties of one or more variables. A variable in an abstract machine is defined to be a variable passed into the machine from outside and which the machine modifies. The OPERATIONS clause depicts the procedures which the machine is intended to perform. The format for a machine can be described as follows:
MACHINE m
CONSTANTS k
PROPERTIES T
VARIABLES v
INVARIANT I
INITIALIZATION L
OPERATIONS
PRE P THEN S
END;
…
END
When the machine is a refinement of the original abstract machine, then a new clause is introduced called REFINES [10]. The refined abstract machine very closely follows the original machine; however it adds more details to the design. It takes the specifications through a sequence of design steps towards implementation. The most important step in the B method is proving that the algorithm in the refined machine is correct.
4.2 Algebraic Specification:
Algebraic specification, is a software engineering technique for formally specifying system behavior. Algebraic specification seeks to systematically develop more efficient programs by:
i. formally defining types of data, and mathematical operations on those data types
ii. abstracting implementation details, such as the size of representations (in memory) and the efficiency of obtaining outcome of computations
iii. formalizing the computations and operations on data types
iv. Allowing for automation by formally restricting operations to this limited set of behaviors and data types.
An algebraic specification achieves these goals by defining one or more data types, and specifying a collection of functions that operate on those data types. These functions can be divided into two classes:
i. constructor functions: functions that create or initialize the data elements, or construct complex elements from simpler ones
ii. Additional functions: functions that operate on the data types, and are defined in terms of the constructor functions.
There are two basic languages relating to ‘Algebraic Specification’, which are given as follows:
I. OBJ
OBJ is an algebraic programming and specification languages family introduced by Joseph Goguen in 1976. Object-oriented specification languages are those which provide at least the three basic object-oriented features (i.e. objects, classes and inheritance) and are based on a semantic model that allows formal manipulation of the specification [11]. The OBJ languages are based on algebra, first-order logic, temporal logic and set theory etc [15]. In most cases variations of different formalisms are used.
Object-oriented specification approaches have been classified in two main groups. These are classified as follows:
A) The first one is formed by new languages that have been designed from inception following the paradigm.
B) Incorporation of object orientation into existing languages.
II. Larch:
The Larch family of languages supports a two-tiered, definitional style of specification. One language that is designed for a specific programming language, Larch Interface Language (LIL) and another language that is independent of any programming language, Larch Shared Language (LSL).
4.3 Process Oriented:
Specification languages for describing concurrent systems are sometimes implicitly based on a specific (though perhaps implicit) model for concurrency. In these languages expressions denote processes, and are built up from elementary expressions which describe particularly simple processes by operations which combine processes to yield new potentially more complex processes.
Possibly the best know process modelling languages are CSP and CCS.
5. Limitations:
• Correctness of Specifications
• Correctness of Implementation
• Correctness of Proofs
Other Limitations:
 Limitations in refinement:
• The refinement standards are not adequate to ensure that a refined particular (or solid determination) fulfill the client’s genuine necessities in the event that it fulfills the theoretical detail.
• The existing refinement standards are not generally appropriate in principle amid the progressive refinements.
• Complete convention
• Abstract machine and target machine
• Practical limits
• Dealing with complex language
6. Future Work:
Formal Methods is a very lively research area with a broad variety of methods and mathematical models. In this state of affairs, there is not accessible any one method that fulfills all the protection related needs of building a secure formal specification. Researchers and practitioners are regularly working in this area and thus gaining the benefits of using formal methods.
Work may be initiated to build up a formal method that combines a variety of remuneration of other methods that centers in building secure formal specification.
Additional research is required to make use of abstraction in combining numerous mathematical theories.
It is needed to expand the notations of formal methods and the tool support to make it easy to use
Work may be commenced on optimizing methods and tools for ruling errors so that rightness to the system is recognized.
7. Conclusion:
The paper presented strengths, weaknesses preceded by a comparative study of the existing formal methods along with the future research directions. Decision making for selecting a formal method can be easily done by the senior IT personnel by going through the results derived in the paper. Researchers have made significant progress in the area of formal methods but still improvement is needed. We presented a number of research areas, based on the existing published work in which further work is required such as composition, decomposition, abstraction, combinations of mathematical theories, reusable models and theories. Among all, major need is to make the methods to be more specific for the requirements phase because requirements are considered as foundation stone on which the entire software can be built. This work may help provide effective and efficient ways to incorporate formal methods in requirements phase so that appropriate level of security can be achieved.