Choosing a Formal Method Mike Weissert COSC 481

Choosing a Formal Method Mike Weissert COSC 481

Outline Introduction Reasons For Choosing Formality Application Characteristics Criteria For A Successful Application Needs/Constraints Of The Organization Characteristics Of A Formal Method Conclusion Sources

Introduction The choice in using FMs requires the same decision making skills used to make any other decision. l Requirements: l l Clear Objectives Knowledge of Constraints In selecting a method, you will choose one in which the tools, experience, and support most closely meets these requirements.

Reasons for Choosing Formality Improve the Quality of the Entire Development Process l When your goal is for a general improvement of your company’s development process

Reasons for Choosing Formality Improve Integrity, Reliability, and Other Characteristics of a System development can be enhanced parallel with software development l Use when goal is to enhance the system architecture as well as the software l

Reasons for Choosing Formality Reduce Specification Errors l Using FMs, the system specification (in particular the functional specification) can be expressed in a way that greatly reduces errors.

Reasons for Choosing Formality Improvements In the Requirements Definition Requirements are normally expressed in non-formal language l Using formal expressions, omissions and inconsistencies are found more easily then with other techniques l

Reasons for Choosing Formality Improved Documentation and Understanding Present legacy software is undocumented or has very inadequate documentation. l Using FMs in your documentation makes for easier understanding of software and better confidence in its reliability l

Reasons for Choosing Formality Provide a firm foundation for: Maintenance l Enhancement l

Reasons for Choosing Formality Gain Knowledge About the Properties of a Design Architecture l Provides an understanding of the design of the software in terms of: Properties l Limitations l

Reasons for Choosing Formality Acquire a More Rational Basis for Choosing Test Data New techniques developed where test data is being derived from functional specifications of the software components. l These techniques become more systematic if FMs are used in the functional specification. l

Reasons for Choosing Formality To Become as Certain As Possible that the Design and Implementation are Error Free Important in safety-critical fields l Using FMs, one can see “proofs of correctness” during the development cycle l

Reasons for Choosing Formality Customer/Standards Requirement? l Contracts might mandate the use of FMs in the development cycle

Application Characteristics There Are 3 Intrinsic Characteristics of an Application: “Phenomenological Model” l Computational Model l Physical and Societal Environment l

Application Characteristics: Phenomenological Model The mathematics used by the scientific theory of the application to explain its phenomena Examples l The Phenomenological model of: Ballistics & Civil Engineering is Classic Mechanics l Telephony is Traffic and Switching Theory l

Application Characteristics: Computational Model Related to the Phenomenological model, this model relates to the structure of the computations which reflect and model a specific system within the application. Different structures include: l l Sequential Distributed and concurrent Dependent on real time events

Application Characteristics: Physical and Societal Environment Several considerations: Safety system? l Embedded system? l Cost-critical? l High volume cost critical? l Large human interaction? l

Criteria For A Successful Application Customers and users find applications acceptable for different reasons. Rating the following features will help in developing an application: Correct Functioning l High Performance l Ease of Use l

Needs/Constraints Of The Organization Different FMs have different levels of support based upon: Available Literature l Courses l Documented Experience l Tools l

Needs/Constraints Of The Organization Important for an organization to have a reasonably well-developed software engineering discipline already in place. Before engaging in FMs, your organization should have: Good level of engineering experience l In-house working standards l

Needs/Constraints Of The Organization When adopting FMs its good if the staff have either: l l Used FMs previously Understand some of the principles of FMs When adopting FMs for the 1 st time good to adopt a training program in which you will have to consider: l l Available training budget Time scales

Characteristics of a FM If you need to ensure the correctness of your end software product, it may be wise to adopt a method whose tools enables proof of correctness.

Characteristics of a FM: Level of Abstraction Different languages display varying levels of abstraction at which they support discourse: Can be categorized by: l l Language Requirements Functional Specification Design Ability to be Executed “Should choose a method and language whose capability best supports the part of the development process where formalization is going to be most beneficial”

Characteristics of a FM: Computational Model The languages of different methods allow for different kinds of computation. Wise to match the language to the computational model of the application. Several Model Classifications: l l l Sequential Parallel Dynamic Real-time Indifferent

Characteristics of a FM: Supported by Tools Many tools available Differ in: Capabilities l Maturity l Degree of commercial support l Ease of use l

Conclusion When choosing a formal method, there are several steps that should be followed to make an intelligent and beneficial selection for your organization. By following the steps outlined in this presentation, your experience with FMs should go more smoothly.

Sources Formal Methods Europe http: //www. fmeurope. org/fme/choosing. htm Michael G. Hinchey, Jonathan P. Bowen: Applications of Formal Methods. Prentice Hall International (UK), 1995.